微服务拆分的四个维度
极客时间编辑部
讲述：杜力大小：1.36M时长：02:58
微服务架构是模块化的一种方法，近年来广受欢迎。它把一整块应用拆分成一个个服务，以便于团队在开发复杂的应用时，能够更快地交付出高质量的软件。但有些时候，从单体架构到微服务，拆分粒度很难把握。理论方法莫衷一是，同程旅游架构师谢康回顾了同程微服务的打造历程，他们推荐按照四个维度做拆分，如下。
1. 团队组织架构
按照康威定律的说法，组织结构一定会反映到系统架构上，同程是树形结构 + 底层网状结构，服务之间一定是每个系统的架构呈明显的树状，但是系统之间会有多重的服务互访。
微服务设计要充分考虑哪些是自用（inner），外部访问（outer）和混用（mix）服务，并尽可以能将其迁移对应的服务组里。
2. 发布升级频率
新老项目由于处于生命周期的不同阶段，修改和发布频率会有很大差别。应该尽量将处于生命周期中不同阶段的接口分割，避免高频更新服务和低频更新服务捆绑，避免向稳定运行的服务组添加新业务接口，而是应该考虑在新的服务组中实现。
3. 调用频率
服务组中的不同服务调用频率会有巨大差别，而高频调用肯定会占据更多的资源，会出现个别接口耗尽资源导致同组接口一起失败（资源竞争），需要对高频访问的服务设置定制的运行策略，如分配更多的 CPU 核心数和内存， 调整部署使其尽可能靠近数据源等策略，但是如果将所有服务宿主都做成高配，会造成巨大的资源浪费事实上也没有必要，所以应该将高低频访问的服务分割以使其能为获得更好的性能和可靠性做针对性优化。
4. 数据读写分离
上一维度其实已经涵盖了读写分离的一部分，但是为了突出读写分离的必要性，这里单独列出。一般数据操作模式分为 CQRS 和 CRUD 两种模式，各有优缺点。
从操作是否对数据本身造成影响来看，可以粗略的分为读写两类 ， 一般来说写操作的频率会大大低于读操作，写操作经常会有更严格的认证授权机制，一般为内部（inner）调用。这些和读操作都有巨大差异性， 因此建议流量较大或较为核心的服务应该做读写分离，分拆为两个服务组发布。
最后谢康还分享了一个粒度控制的小技巧，微服务的“微”如何做到足够合适的粒度，是一门艺术。系统里每个名词一般都会在存储层面对应一个独立的实体，如数据库表，所以根据系统中出现的名词来划分微服务，即可做到一定程度的合理性。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论