文档介绍：微服务落地能力提升方案
Microservices
微服务体系的发展并不是一蹴而就的，经过了 2014年前后的低潮期，微服务概念顶层的泡沫逐渐褪 去,那些真正能够在企业落地的实践在一轮又一轮的大浪淘沙后被甄别、沉淀。这篇文章希望讨论一 些在团队中实行微服务架构时值得考虑的『增值项目』,它们中的一些看起来已经是理所应当的，而 另一些似乎和微服务并没有必然的关联，但许多经验能够证明这些项目都是保障微服务系统长期运作 并最大化发挥其Scale Out能力值得投入的高附加值实践。持续交付
对于微服务的成功实施，团队持续交付能力是至关重要的衡量指标。在由上百个服务组成 的复杂系统中，如果所有服务都按照人为指定发布周期进行整体交付，很容易出现由于细 小的失误导致大面积线上故障。
持续交付实践要求每个独立服务都具有完备的交付流水线，在流水线的末端随时能提供当 时最新的可工作、可交付的产品。持续交付通常会配合自动化的测试和部署手段，从而减 少功能代码提交到上线的端到端时间。这就使得每个独立服务能按照各自不同的节奏进行 发布，并且将自己的发布状态可视化出来。
采用尽可能精简且稳定的分支策略也是使得持续交付流程能够顺利实施的关键，我们提倡 使用单主干的分支策略(Trunk Based Development)。在单主干的开发方式中z除了 一个用于持续开发和集成的『主干分支』(通常即Master分支)和一系列依据发布周期 创建的发布分支以外，应该避免创建其他的Long-lived分支。如果有多个功能需要开发, 则推荐采用特性开关(Feature Toggle )的方法来控制它们的发布时机。当然，单主干 策略是允许存在短生命周期特性分支的(短于一周)，有时这些小分支甚至无需提交到远 程仓库中。下面这是一幅经典的单主干分支策略示意图。
now
0 120
build + release 回 a branch being cut 回 merges to prod
—, z . . v e commit selected for cherry-pick
c commit (developer) l£J 7 r
(release engineer) originally
E commit (release engineer) made by a developer
单主干分支策略
值得指出的是，在划分得当的微服务系统中，同一个服务需要同时进行开发的特性通常不 会多于两到三个（否则应该考虑这个服务是否承担了过多的职责）。因此即使在不需要特 性开关和其他额外开发工作量的情况下，已经可以比较好的实现每个功能点的独立发布和 测试，这反向说明了微服务架构对于持续交付的实施也是十分友好的。
除了严格的单主干，一种常见的变式是多主干策略，典型的是一个开发分支加几个固定的 发布分支，通常用于无需维护多个发布版本的SaaS服务交付。这种模式的优点是能够将 发布流水线目标环境和分支显示的关联起来，例如『Develop分支』对应集成环境，
『Release分支』对应验收环境和正式环境。下图展示了一组与此模式下的持续交付流水 线。
代码仓库■
(Develop)
囂鬻 自动部署 接口测试 集成测试
代码仓库 (Release)
4 单元测试 白ftai空 、灰度环境
‘回丿抑试线上环境
多主干的流水线
保持每个服务高频率的集成和交付，会使得有故障的功能在很短的反馈周期内被发现，在 快速迭代发布的前提下做到整个系统发布井然有序。这样的氛围不仅有利于改善代码的质 量，而且能够提高开发士气，频繁的发布上线也有利于增强团队对产品的荣誉感和自信心。
全功能团队
全功能团队是DevOps运动所倡导的一种产品团队组织结构,通过将不同角色的业务和 技术成员纳入到团队，组成具备端到端交付和运营能力的完整单元。
康威定律阐述了开发团队的组织结构和其设计的产品结构之间具有的相似关系。许多的实 践结果也表明，将全功能团队实践应用在微服务产品中带来的收益，要远远超过它在传统 模块化开发的产品中所带来的收益。这是因为微服务的架构中的所有服务真正具备独立运 行和独立运营的能力，从本质上来说就是一个端到端的子业务产品。
这种架构和团队的影响是双向的。一方面，微服务的运营结构要求团队具有高内聚的自主 管理能力。另一方面，全功能团队也为特定服务进行独立技术选型提供了更灵活的发挥空 间。服务与团队通常是多对一的关系，每个团队管理的是一组相互关联紧密的服务群，并 且可以在必要的情况下对服务进行进一步拆分。在实际的实践中推荐采用例如接口网关 (API Gateway )等方式对一组具有业务意义的服务接口