如果发现有些技术书籍晦涩难懂，满篇的高大上，读完头脑发胀，却无所进益，有时候这可能不是您水平不够，可能只是因为作者故弄玄虚。
同程微服务从立项到实施推广已经走过了整整两个年头，从最初的简单粗糙到今天的精细完善，接入服务数量也实现了从 1 到 10,000+ 的增长。微服务开发团队和大家一起踩过了无数的坑，最终打造了今天的 DSF2.0 平台。
回顾爬坑记录，现整理一些爬坑心得体验供大家参考，也斗胆提出一些最佳实践以抛砖引玉。下文将从开发者角度对微服务如何拆分、版本管理和单体到微服务过渡等方面给出一些建议, 供大家斟酌。
微服务拆分的四个维度
从单体架构到微服务，拆分粒度很难把握。理论方法莫衷一是，我们推荐 快刀斩乱麻，按照如下四个维度做拆分：
团队组织结构
按照康威定律的说法，组织结构一定会反映到系统架构上，同程是 树形结构 + 底层网状结构，那么服务之间一定是每个系统的架构呈明显的树状，但是系统之间会有多重的服务互访。
微服务设计要充分考虑哪些是 自用（inner）、外部访问（outer） 和 混用（mix）服务，并尽可能将其迁移到对应的服务组里。
发布升级频率
新老项目因为处于生命周期的不同阶段，修改和发布频率会有很大的差别。应该尽量 将处于生命周期中不同阶段的接口分割，避免高频更新服务和低频更新服务捆绑，避免向稳定运行的服务组添加新业务接口，而是应该考虑在新的服务组中实现。
服务调用频率
服务组中的不同服务调用频率会有巨大差别，而高频调用肯定会占据更多的资源，会出现个别接口耗尽资源导致同组接口一起失败（资源竞争）。
这就需要对高频访问的服务设置定制的运行策略，如分配更多的 CPU 核心数和内存，调整部署使其尽可能靠近数据源等策略，但是如果将所有服务宿主都做成高配，会造成巨大的资源浪费事实上也没有必要，所以应该将高低频访问的服务分割以使其能为获得更好的性能和可靠性做针对性优化。
数据读写分离
上一维度其实已经涵盖了 读写分离 的一部分，但是为了突出读写分离的必要性，这里单独列出。
一般数据操作模式分为 CQRS 和 CRUD 两种模式，各有优缺点。从操作 是否对数据本身造成影响来看，可以粗略的分为读写两类 ，一般来说写操作的频率会大大低于读操作，写操作经常会有更严格的认证授权机制，一般为内部（inner）调用。这些和读操作都有巨大差异性， 因此建议流量较大或较为核心的服务应该做读写分离，分拆为两个服务组发布。
最后分享一个粒度控制的小技巧，大多数情况下，出现在系统里的每个名词都会在存储层面拥有一席之地，对应一个独立的数据表或库，所以系统里出现的名词都可能是一个潜在的微服务。
微服务应该如何维护版本
微服务治理中维护一个有序、直观的版本会给系统开发过程和服务依赖管理带来巨大的便利，反之无版本或混乱的版本升级策略会迷惑开发和设计人员，并带来意想不到的依赖问题。
良好的微服务治理应该包含一整套完整的版本升级策略，根据我们长期的爬坑实践，我们推荐如下版本策略：
使用标准语义化版本
使用标准的语义化版本能使大家保证对版本有统一的理解，应尽量避免自行定义版本语义。我们 DSF 版本推荐使用 SemVer 约定，具体参见语义化版本 2.0.0。
略有不同的是 DSF 推荐四位版本号（1.2.3.4），前两位作为主版本（1.2）， SemVer 版本一般为三位（x.y.z 对应：主版本号. 次版本号. 修订号）。
面向契约设计
当一个团队选择微服务作为服务化实施平台时，必须明确微服务化有一个较高的门槛，需要团队自身已经是一个较为成熟运作体系，例如有实施前有完善的架构设计，团队成员有明确的职责划分，团队成员对服务内聚和服务耦合有明确的认知。
上述的这些方面都会促成一个结果：使设计开发的服务接口最终具有良好的抽象并体现出规划性，最终能够在服务实施前就能交付有良好兼容性的服务契约。
实践中体现为一个版本迭代新增、修改、删除的任何部分都是经过慎重思考并体现在服务契约里，实际开发不轻易地修改和增添服务接口。
并行开发中版本的维护
微服务化对开发体系的一个重大影响就是开发实践的并行化，微服务使开发者从单体架构的调用丛林摆脱出来，使开发者能够把视野聚焦到调用链中其中一环上而不用过多关心上下游的具体实现。
需要付出的成本就是如何避免重复实现以及代码 Merge 时的更高频的冲突问题，有一个良好的版本管理习惯能够解决绝大部分的 Merge 冲突问题。
我们推荐在面向契约设计的基础上进一步延伸，通过团队内沟通确定不对外暴露的核心部分由谁来负责并约定在特定的版本实现，而负责使用该核心模块的其他开发者在该版本上递增版本。
被其他组件依赖较高且可能频繁改动的内核代码独占一个特定的版本区间 (例如：v1.2.3.0~1.2.3.10 作为核心模块的独占版本，依赖该组件的模块必须大于 v1.2.3.10)，能很好隔离并行开发带来的版本冲突问题。因为引用核心组件的上层实现彼此没有太多联系，总是能够很好处理 Merge 带来的冲突问题。
版本的兼容性
能根据版本号判断服务是否向后兼容是服务依赖管理的一个很重要的方面，大多数时候做一个使服务不再向后兼容的决定是很难的事，但是不断地向后兼容的结果往往是服务体量不可控制的增长和系统复杂度的非线性上升。
开发者需要慎重思考并在合适的时间做出服务不再向后兼容的决定，良好的版本策略能将服务是否向后兼容明确地表达出，显式地告诉调用方这是一个不兼容的升级更新。
请务必确保仔细阅读了新的契约文档并做了足够的测试。对 DSF 来说不兼容升级是很醒目的，只需观察服务组的大版本号（版本号的前两位，如 v1.2.3.4，大版本号为 1.2）是否增加，任何服务契约修改都被认为是不兼容的升级，包括删除接口、修改接口名称 / 参数等，都必须升级大版本号， 而修改小版本号（版本号的后两位，如 v1.2.3.4，小版本号为 3.4）则代表兼容性升级，如新增了服务接口，代码逻辑优化和 Bug fix，但是未修改服务契约。
如何从单体架构平滑过渡到微服务
一旦决定在开发实践引入微服务架构，如何将积累下来的庞大的巨无霸系统润物细无声地过渡到微服务架构将是一个巨大的挑战。
推倒重来激进革命路线是要不得的，架构师们最想通过微服务化取代的部分往往是公司的主要盈利核心，改造难度不亚于飞行中更换引擎。
从业界公开的信息来看还没有哪家做到了完美升级， 更多的可能无外乎两种：第一种改造后苟延残喘，研发疲于奔命； 另一种则是改造中就直接休克。因此为使微服务能顺利地应用，架构师从不应该幻想一蹴而就，无数次的碰壁后我们给出如下的爬坑建议：
培训先行
工作技术人都很善于把面临的问题变成技术问题，然后在自己最擅长的领域里解决掉。这就造成一个悖论：能用技术解决的问题就不是问题，真正的问题在受限的情景下仅靠技术是解决不了的，实施微服务最大的拦路虎也不是技术本身。
从我们的实践来看，最大的问题不是如何做好微服务，而是就 微服务应该是什么 达成一个一致的看法。正所谓林子大了什么鸟都有，对于微服务 100 个人可能就有 100 种理解，这个不是说我们都是用 dubbo 或者都是用 spring boot 就能解决的。
我们的推荐做法就是实施前通过多数人参与的大讨论和培训，让多数人能达成一致的认识，微服务是什么，微服务不是什么？ 运用在哪些场景是适合，应用在哪些场景里是不适合的？ 结果不要跑的太偏就行，和编码规范中命名规范一样，使用哪种命名方法不重要，重要的是大家都使用同一种命名方法。
绞杀者模式
绞杀者模式指对于无法通过修缮者模式改进的系统通过在系统外重新构建新功能的方式逐步剥离重构，对功能服务逐个绞杀。 好处是不影响原来的环境，一旦条件成熟就能快速切换。不好的方面则是可能需要有一段时间同时维护两套系统，付出额外的开发维护成本。
监狱模式
还有一种同程内部称之为监狱模式的做法，允许一些短期无力改动的系统通过监狱窗口（MicroProxy）接入微服务平台并委托 Proxy 将其暴露成微服务， 单体架构往往拥有庞大的服务接口梳理， 往往需要开多个监狱窗口。 每个监狱窗口都会被包装分割成微服务，条件成熟了能很方便的替换成原生微服务，称为刑满释放。
结语
市面上微服务的理论和讨论铺天盖地，其中不乏侃侃而谈的大块文章，深入阅读却常常发现大都是新瓶装旧酒或者拼凑篇幅之作。特点是在务虚处浓墨重彩、高谈理论，于实践处则一笔带过，仔细探究则实无一物。
