微服务架构三十六计
微服务架构诞生以来，在各种演讲、文章、书籍上所出现的频率之高，足以看出它对软件架构领域带来的巨大影响。经过这两年的快速普及，微服务的实践已经在越来越多的组织和企业内部得以推广和运用。
未来的几年，相信会有更多的企业将目光聚焦在如何有效地将微服务落地这个核心问题上。微服务的概念看似浅显易懂，但实际上却与架构演进、领域建模、持续交付及DevOps等多个维度的方法论与实践密切相关。
在微服务的落地过程中，我们认为如下几点将成为组织实施微服务架构的必备能力。
- 持续交付是内功
十年以前，某个软件在一年内发布的版本数量屈指可数。过去的十年间，交付的过程被不断地优化和改进。从早期的RUP模型、敏捷、持续集成，到近几年的DevOps，都在力图更有效地降低交付过程中所耗费的成本，提高交付效率。
持续交付的提出优化了软件交付的流程，并能帮助企业尽早实现业务价值。对于微服务而言，持续交付机制的顺畅与否，也就决定了微服务架构实施的成本与效率，稳固、可靠的持续交付流水线能让微服务的落地事半功倍。
- 演进式架构是策略
架构是IT领域经久不衰的话题之一。架构的本质是对业务、技术、团队以及可用性、可测试性、可维护性等多个维度的不同因素所做的动态平衡。
在如今市场激烈竞争的环境下，盈利模式的变化、用户体验的变化、竞争对手的变化、行业本身的变化等，都使得业务变化频率不断加快。而随着业务的快速变化，系统对架构变化的诉求越来越强烈。系统的复杂度来源于业务的复杂度，而业务的复杂度会不断驱动架构朝着更易维护、更易应对需求的方向演进。
微服务的实施过程是一个典型的构建演进式架构的过程。它会不断地经历服务的定义、拆分、合并、再拆分、再合并这样的过程，来适应日益增长的需求数量和业务复杂度。因此，不断完善微服务的生态系统，悟透应用背后的行为和模式，寻找基于演进式的动态平衡，才是企业应对业务变化的核心策略。
- 运维能力是动力
运维能力是企业实施微服务的关键动力。相比传统的单体应用，细粒度的可独立部署的服务的上线，大大增加了运维成本。而随着服务规模化的进一步深入，部署、监控、日志收集、告警等的复杂度呈指数级增长。另外，微服务架构对系统的容错性也提出了更高的要求，当某个服务出现故障后，如何避免整个系统的宕机，如何快速恢复，也变得愈发复杂。
因此，在实施微服务的过程中，运维能力决定了微服务化后的端到端价值能否有效产出，是企业实施微服务的关键动力。
- 匹配的组织结构是核心
微服务带来的不仅仅是技术上的变革，也是组织上的变革。传统的按照技能划分部门的模式，将越来越难以适应业务的激烈竞争和市场的快速变化，也无法匹配基于细粒度拆分和独立交付所带来的灵活性。通过构建基于服务的小团队，不仅能提高成员的主人翁精神，在执行层面也更具灵活性，能够帮助组织做到快速调整策略、快速应对变化，而这也成为组织和架构演进过程中可持续发展的核心。
综上所述，对于微服务架构的落地，我们应该客观冷静地对待其带来的益处和存在的挑战，切实结合自身业务场景，循序渐进，提升综合能力，做到事半功倍。
- 入门：微服务架构的本质及特点
第一计 微服务架构是基于细粒度的业务单元构建的现代分布式系统。
第二计 微服务架构的“微”不是指代码数量，而是指业务独立交付的粒度。
第三计 微服务架构源自SOA体系，但它是一种更注重敏捷、持续交付、DevOps以及去中心化实践的架构模式。
第四计 微服务架构是基于 DevOps 的一种演进式架构，架构师的运维意识是演进式架构的关键。
第五计 使用微服务架构，并不意味着完全摒弃单体应用。对于业务价值有待探索的场景，单体应用作为初期的架构模式是不错的选择。
第六计 微服务架构的收益受到团队、流程和技术三方面因素的综合影响。
第七计 SOA应对业务集成，注重架构中心化；而微服务架构应对业务变化后的快速响应，注重架构去中心化，以及去中心化的组织、流程和工具的协同。
第八计 微服务架构的思维与传统的模块化思维的本质区别在于是否能被独立部署并处于运行态。
第九计 理解康威定律与逆康威定律，并将其原则应用到实践中，这是微服务架构实施过程中的必由之路。
- 设计：做好拆分，注重策略
第十计 不要追求服务数量多带来的快感，基于稳定的基础设施与交付流水线进行拆分，快速上线能产生业务价值才是王道。
第十一计 双模IT的运作方式是遗留系统服务化转型的关键策略。
第十二计 服务拆分遵循先少后多、先粗后细（粒度）的原则。
第十三计 服务拆分的形态和粒度随业务发展动态演进，妄图一次将系统拆分完是不现实的。
第十四计 服务拆分的战术涉及多个维度（领域驱动、面向对象、面向资源），团队应该基于原则找到最适合自己的服务拆分方式。
第十五计 数据拆分的战术可以基于图论的依赖最小原则进行逐渐解耦。
第十六计 微服务架构转型过程中，一定要有全力投入的试点团队。聚焦小范围拆分、持续获得反馈、持续上线才有价值。
- 实现：迎接挑战，逐步演进
第十七计 分布式系统的复杂度是其向微服务演进的极大挑战。带宽、延迟、超时带来的问题以及如何有效治理服务是服务化面临的重要挑战之一。
第十八计 微服务架构中，数据的一致性是一个挑战。分布式事务带来的复杂度会导致多元化存储机制的丧失。
第十九计 服务间的通信建议采用轻量级机制（语言无关、协议无关），但这并不意味着只能使用轻量级机制。在注重通信效率的场景中，RPC也是不错的选择。
第二十计 服务间的异步通信，复杂场景用消息队列，简单场景使用后台任务系统处理。
第二十一计 在微服务架构演进的过程中，组织应不断优化服务交付的工具链，并提升工程实践能力。
- 交付：快速交付，完美落地
第二十二计 服务的代码库独立，是保证服务化快速交付的基础。
第二十三计 从代码库迁出服务并能迅速搭建本地开发环境，是服务化快速交付的第一步。
第二十四计 服务应具备自解释的文档，为开发人员提供快速上手的信息。
第二十五计 上述自解释文档应当是内嵌在服务代码库中的，包括服务开发与运维过程的核心信息。
第二十六计 测试金字塔的反馈周期与成本投入是做好微服务集成测试的核心策略。
第二十七计 消费者驱动契约测试能以单元测试的方式，对服务双方接口变化提前发现。
第二十八计 微服务架构的验收测试更关注业务价值高的场景（基于用户画像、使用流程）以及性能、安全等测试。
第二十九计 微服务架构的组件测试是以服务作为黑盒对其进行的接口输入。
第三十计 微服务架构中的API Gateway是为了隔离外部请求，提供统一接口的集中化组件，要避免 API Gateway 承担过多职责，变成另外一个单体应用。
第三十一计 部署的优化策略就是无限逼近一键部署deploy [service-name]、[service-name][service-version]。
第三十二计 每个服务都应该提供健康性检查，并对接监控告警系统。
第三十三计 日志聚合是微服务架构下的重要组件，能帮助团队集中化了解服务/实施的详细信息。
- 再出发：拥抱变化，不断优化
第三十四计 新人需要多久才能开始贡献代码，是检验服务粒度粗细与自解释文档完备与否的好指标。
第三十五计 微服务的静态依赖图能帮助团队在聚焦个体服务的同时，不在全局中迷失。
第三十六计 业务特性的实现需要多个服务依赖是合理的，我们永远不知道未来的业务变化会发生在哪里。所以，独立部署与接口向后兼容是处理服务依赖的有效方式。
- 案例 微服务不只是拆拆拆
- 对原系统进行微服务拆分
一年多以前，微服务开始流行。公司某App的后台虽然一直在做模块拆分，但由于业务沉淀已有些年头，加上没有做好减法，目前几大子系统稍显臃肿，子系统的代码量大且逻辑较为复杂，每次修改都生怕影响到其他功能，而且每次升级也都担心影响一系列功能的使用。在对微服务进行预研后，研发团队内部达成一致意见：需要对现有系统进行微服务升级。那么问题来了：如何升级？
“把平时冲突最多的模块拆出来，避免后面互相影响。” “我建议将广告系统拆分出来。” “既然要分，那么就分得彻底一点。” ……
大家纷纷提出了自己的建议。最终，对现有系统的拆分被分为两个阶段来进行：第一阶段，确定微服务升级的范围，团队全体讨论决定针对所有的子系统进行升级。第二阶段，分工，每个特性组团队针对自己负责的子系统进行微服务升级。
一个月之后微服务升级完成了，原本的几个子系统被拆分成了52个微服务，其中的过程及结果都颇戏剧化，我们来看各部门的反应。
- 研发同学
兴高采烈，每位同学对自己的微服务升级优化作品都很满意，后面再也不需要和某某同学合并代码了（后面证实，这只是一时的幻觉），再也不用担心一个子系统升级影响的范围了；研发主管也挺高兴，因为通过这次微服务升级，大家的技术都有长进，整个研发团队欢天喜地。
- 运维同学
“天啊，今天一天都在申请域名，App后台说是拆分微服务，足足拆了52个出来，原来只需要两三个域名，现在要几十个，真有这样的必要吗？要是出故障了，还得一个一个域名更新指向，想想都觉得可怕！”
“别吵，我在迁移线上数据呢。以前几个实例，现在要拆成十几个，都线上数据呢，万一搞错了你说怎么办！”
- 质量同学
“咦？不是一个版本吗？怎么提测提了六七个？哦，每个微服务提测一次。那每次都得维护一个提测列表，要是哪个微服务漏测了就悲剧了。”
“几个微服务有没有上线先后顺序？哦，这个先上，那个后上？还是给我一份部署文档吧，至少把上线顺序列一下，也把回滚步骤和风险说明清楚哈。”
“运维同学好像漏了这几个微服务的监控了，要让他们补一下。”
- 这样拆，真的好吗
大家发现其中的问题了吗？其实这一次拆分后，微服务并没有带来应有的收益，下面一起分析一下问题出在哪。
- 研发团队在整个拆分的过程中只考虑了业务和技术上的拆分，没有关注到部署、版本流程等相关因素，直接导致了部署及维护成本剧增，版本流程复杂。
- 从技术的角度来看，让不同的特性组针对不同的子系统单独进行拆分的方法欠妥，如果原来子系统的拆分就存在问题的话，就会把问题也带到拆分后的微服务中，导致拆分不合理；同时，两个子系统也可能拆分出功能重复的微服务，如日志微服务、通知微服务等。
- 从几个系统中拆分出几十个微服务，很可能拆分过细，导致每次开发上线都涉及几个微服务，同时也导致微服务之间的调用关系复杂，整体链路过长，影响了排查问题的效率，使原本复杂的架构变得更复杂。
- 还有其他问题，大家可以进一步思考，由于篇幅原因这里就不穷举了。
- 影响微服务收益的关键因素
如前面第六计所述，微服务架构的收益受到团队、流程及技术这三方面因素的综合影响。
- 团队
无论是技术还是流程的实施，其实都和团队脱不了关系。团队的规模、团队的类型和团队的能力模型等，都影响着微服务的实施效果和收益。
比如团队的规模，维护同样的 50 个微服务，对几个人的团队和十几人的团队来说，收益大不相同。每个人维护 1或2个微服务比较合适，达到或超过3个后，每个人的工作负荷就会变得很高，进度的延迟、质量的下降很快就会随之而来。同样，负责质量测试的同学测试的微服务越多，质量测试的效果也会越差，有时候连最基本的问题都无法发现。
再比如团队的类型，大公司的成熟团队更关注的是稳定和扩展性，那么复杂的业务适当地采用微服务，可以带来很好的扩展性及稳定性；创业团队可能更关注研发和上线效率，业务经常变换，人力和服务器资源都受限，采用微服务很可能带来的不是收益，而是负担。
总而言之，团队是微服务实施的基础，不同的团队利用微服务的结果可能不同，需要根据自己的情况具体峰分析。
- 流程
流程改进相信大家都不陌生。微服务是否能给团队和组织带来价值，也和团队的流程密切相关。软件研发流程是怎样的？代码如何管理？测试流程是怎样的？这些极大地影响着微服务的收益。有些团队只看到了微服务拆分在代码层面带来的效益，认为极大地降低了代码的冲突率，却没有看到微服务拆分带来的运维成本和质量测试成本的增加。
例如本案例中，原本只有几个子系统，被拆成了几十个微服务，测试的接口将随着微服务数量的增加而呈指数级增加；同时，每个版本需要更新的服务实例也从原来的几个变成了几十个，所以这种情况下提升的不是效率而是工作量。
再来看一个正面的例子。支付流程一般都非常复杂，这一过程可能涉及很多内部和外部的系统，一次版本可能要经过几个系统的研发、联调及测试，而所有人都需要等到系统验证通过后才能开始下一个版本的研发（因为怕互相影响），效率非常低。这时我们可以考虑把服务按照业务特性来拆分，比如外部的银行交易服务（包含转账、付款等）、内部的虚拟币服务（如淘气值、蚂蚁会员积分）、账户交易服务（指账户的充值及消费等）等微服务，每一类微服务由不同的同学完成研发及测试，每一个微服务可单独完成测试；如果涉及其他微服务，可全部测试通过后再进行全流程验证，这期间不影响某一微服务开发及测试新的版本。这种情况下，微服务把原本串联的流程变成了可并发的子流程，提高了大团队的效率。
- 技术
微服务的实施很依赖于团队或组织现有的技术栈及技术能力。每一项技术的应用都会涉及以下几个方面：研发、部署、运行、监控及扩展。微服务如何治理？如何监控？这都是依赖于现有的基础设施的。同时，微服务如何拆分，也依赖于技术栈，团队使用的是 PHP 还是Java，对拆分和维护的方式是有影响的，因此微服务是否适合实施，能否达到最大的收益，都受到团队技术水平的极大影响。另外，建议团队在有一定的技术预研和沉淀后再具体应用该技术，否则很可能失败了都不知道原因。
- 微服务拆分的通用策略
最后，和大家探讨一下微服务拆分的通用策略。本案例中的后台团队的拆分明显太细了，几个人的团队规模，拆出了几十个微服务，无论研发、质量测试还是运维，工作量都很大。建议采用以下策略来拆分：
- 先从整体来分析业务的特性或者进行大模块切分，比如基础服务模块、社区业务模块、分发业务模块等。
- 可以考虑先针对某些大模块（而不是全部）进行切分，成功后再复用到其他模块。遵循先少后多、先粗后细的原则，千万不要试图一次过拆分完成，那基本是不可能完成的任务。
- 拆分时要考虑的因素至少包括：业务的独立性及发展趋势、微服务的研发维护及质量流程、团队特点及技术因素等。
- 作者简介
王磊，较早倡导和实践微服务的先行者。著有本领域第一本专业书籍《微服务架构与实践》，同时也是《DevOps Handbook》的译者。在服务化演进，持续交付和DevOps领域有丰富的实践经验。
陈俊良，阿里巴巴技术专家，曾参与保险、电信、互联网行业后台系统设计及研发，主导双活中心设计、移动推送系统设计等。主要专注于架构设计、微服务及相关互联网技术。爱好跑步、读书。
————
以上内容节选自《Devops三十六计》一书，点击文末 阅读原文 直达本文作者王磊的微服务成名作。
