微服务敏捷开发模式探索与实践

1 What篇：理解微服务架构及其关键特征
1.1 什么是微服务架构，其关键特征是什么？基层组织与流程如何进行相应调整以适应微服务架构？
1.2 微服务实践来自Amazon、NetFlix、eBay等互联网公司，但概念则是由ThoughtWorks的首席科学家Martin Fowler总结提出，原始描述如下：

微服务的特征可总结为四个字：小、独、轻、松。通过对四个特征的分析可以发现，微服务跟传统单体式应用（Monolithic）、传统SOA架构之间是有明显区别的。

对于“小”这一要求，也许有人持不同看法。为什么一定要小或微呢？也就是说“大拆小”能带来什么好处？互联网提倡“大系统小做”，目的是为了降低海量系统的复杂度，分而治之，通过系统各个小服务的敏捷实现整个系统的敏捷，即所谓“大象也能跳舞”。那么多小算小？Amazon提出以2-Pizza的团队规模来衡量微服务大小是否合适。一方面是为了让各小团队聚焦做好自己的功能单元、尽量重用已有服务能力、不盲目扩大本服务的范围，另一方面也是认为由8~12人负责一个可独立交付单元、管理上是最高效的。反之，传统以大兵团模式投入几十上百人开发一个耦合在一起的大服务，需要大量的沟通、协调与配合，很可能会成为交付的瓶颈、影响整体上线节奏。总而言之，“小”只是手段，“敏捷”才是目的。
关于“独”，要求每个微服务都是单独的进程，这种方式相比传统架构下的模块、组件、插件等而言，边界更加清晰。前者是进程间的调用关系，只能依赖技术无关的服务接口；而后者一般是进程内代码API间的调用关系，技术实现上是相互锁定的。高内聚、松耦合的软件设计原则大家都清楚，往往一开始也是按此进行设计和实现的，但向前演进几个版本之后可能就变得血肉模糊或架构看护成本巨高，就是因为传统架构下较难维持清晰的边界。
对于“松”耦合，首先是软件系统架构的解耦，即每个微服务可独立编译（无二进制接口依赖）、独立部署（无部署顺序依赖）、独立运行（无启动顺序依赖）…，同时也要相应地进行基层研发组织的解耦（从大兵团到2-Pizza Team）、以及面向微服务生命周期的研发流程解耦（从串行到并行）。核心目的是两点：1）微服务自治，让每个微服务成为可独立开发、构建、验证、部署和扩展的最小单元；2）全流程自助Self-service，每个开发者可以自助式开发、构建、验证、部署及监控自己的微服务。尽可能给以微服务为单元的交付件、组织、流程松绑，只有松绑才能快，这是微服务敏捷开发模式的核心理念。

2 Why篇：向微服务架构转型的意义
2.1 为什么微服务模式开发、验证、上线速度更快？
在传统模式下，软件需要各个组件/模块集成构建出一个完整版本之后才能统一安装部署、构造测试数据与环境、启动验证。这个过程涉及大兵团协同作战，相当于造航母，未全部调测好之前不敢下水、一下水就沉，单个开发者很难独立去调测软件修改的效果，必须等到BBIT/TR4A集成好的版本出来后大家一起去验证，验证发现问题刷新后还得等新版本再次集成出来并构造好环境之后才能回归验证，周而复始多轮版本才能稳定下来，这个过程无疑是低效的。
而微服务模式下，相当于造动车，虽然各节车厢提供的能力各不相同（如车头控制方向、餐车仅供就餐、有座位/卧铺车厢之分等），但每节动车自带动力、可以独立跑（自治的概念），只要保证每节动车之间的接口不变、就很容易集成，而合起来就是功能完整而强大的动车组，相当于众多微服务集成后的软件系统。
为什么微服务模式开发、验证、上线速度更快？如下图所示，微服务管控平台（生产装备）及Stage环境（生产车间）是永久在线的，开发者可以全流程自助式完成开发、构建及验证，不需要依赖和等待别人，可以随时随地推送自己的微服务到Beta/Gamma进行集成验证或类生产验证，相当于原来等到BBIT/TR4A/TR5/TR6才能验证的内容现在一天内就可以进行多次验证。因此也就不难理解，为什么传统架构及开发流程下版本发布以“月/季度/半年”为发布周期，而微服务模式下能做到以“天/小时”为上线周期。

各Stage环境的定位如下：
Alpha——针对单个服务的自验环境，可以对接Beta环境进行验证；
eta环境——定位于快速集成验证，部署最新、最全的微服务版本；
amma环境——定位于面向不同客户场景的精准验证，是根据典型组网及部署方案搭建的类生产环境，仅部署客户场景使用到的服务。

3 How篇：如何实施微服务开发模式
微服务在公有云DevOps商业场景（自己开发自己运营）下，互联网的实践经验已经证明是非常高效的。但这不是我司的主流商业模式，我们现阶段仍然是以产品销售为主，微服务是否能发挥威力呢？下面从流水线能力及运作流程角度，详细阐述如何将微服务的敏捷基因融入产品化交付场景，相当于把互联网的敏捷交付能力复制给运营商客户（从1到N）。
3.1 微服务架构及流水线如何应用于产品化交付场景？
面向公有云服务发布场景：使用前述的微服务开发流水线能力（如下图蓝色部分），就能支持按微服务快速开发与上线。各微服务组遵从“You build it, you run it.”的原则，自行负责微服务在各Stage环境的部署升级、并保障其稳定运行。
面向产品化发布场景：在微服务流水线基础上，需要扩展Pipeline工具能力、增加典型的产品化Gamma环境，以实现一键式制作产品化集成版本（如图红框部分）。
完整的产品化集成版本由松耦合的三部分组成：
1)管理面安装包：通过重用管控平台的部署服务能力构建管理面安装包；
2)应用面安装包：通过从产品化Gamma环境导出微服务构建应用面安装包；
3)部署模板：结合客户现网组网及部署方案设计部署模板，如单机部署、6节点分布式部署等。
补丁版本制作过程类似，通过导出Gamma及现网生产环境的微服务版本号列表进行差异比较，提取更新的微服务包制作补丁。

讲到这里可能会有人提出两个问题。
Q：为什么要基于Gamma环境不是基于Beta环境导出应用包？
A：主要基于Stage环境的定位及更新节奏考虑：
1) 看定位：如前所述两者定位不同，Beta定位于快速集成，Gamma定位于精准测试，Gamma环境导出的版本才是经过客户化场景验证的，质量更符合要求；
2) 看节奏：Beta版本更新快，Gamma则保持与局点节奏一致；对于收编节奏比较慢的局点版本，可以跳过Beta、直接从Alpha推送到Gamma进行验证，维持Gamma与客户现网版本一致。Alpha与Gamma可以有多套，Beta尽量只搭建统一的一套。
Q：为什么不先制作安装盘再进行Gamma验证？有些问题需要通过安装盘部署才能发现。
A：安装盘部署阶段引入的问题确实需要考虑，详细解决办法参见3.3小节。这里之所以先Gamma验证再制作安装盘，主要原因是：
1) 保留类似客户生产环境的在线Gamma环境，而不是基于安装盘临时搭建、临时构造测试环境，才能支持新特性或BugFix的快速开发、部署与验证；
2) 基于持续在线稳定运行的Gamma环境反向制作安装盘版本（快照式导出），该版本应用面运行态质量等同于当前的Gamma环境，版本问题明显比传统方式收敛更快。
跟宜家所谓的“体验式营销”类似，也许我们可将这种模式称为“体验式交付”。宜家搭建各好各个场景的家具组合环境供客户体验，就相当于让客户提前验收不同场景下的搭配组合；客户对于满意的组合环境只需记下家具编号（快照）、提货回家就能还原出跟宜家一样的整套组合或局部组合，更易做到一步到位。

3.2 微服务并行开发模式与产品化IPD流程如何结合起来？
在公有云的服务化交付场景下，效率最高的方式是以各个微服务为中心的DevOps持续交付模式，即各微服务独立开发、上线、运维保障。在产品化集成交付场景下，当前IPD仍然是我们的研发主流程。那么两者如何结合，做到既不损失微服务并行开发的敏捷性，又能保证IPD下按合同交付满足客户要求的集成版本的严谨性？具体做法是：
1)各服务组按特定的开发节奏制定迭代计划持续构建和发布微服务版本（各组节奏可以是异步的、不强求拉齐），即按服务化DevOps过程运作；
2)IPD项目立项之后，PM/SE要将项目交付目标、里程碑计划等分解到各服务组，由各组将这些要求纳入迭代计划中（每三个月滚动刷新），然后按既定节奏在流水线上进行开发、验证，迭代完成之后需将微服务包归档到软件仓库（备注：各组迭代出口前需将微服务版本推送到Gamma环境并验证通过）；
3)最后由集成交付组基于流水线Pipeline工具一键式组装稳定的产品化版本，通过集成验证组测试之后对外发布。

我们对上述过程作一个形象的类比，帮助理解和记忆：将项目要求分解给各组的过程相当于“播种”，各微服务独立开发、部署、验证过程相当于“耕耘”，验证充分之后发布稳定的微服务版本到软件仓库相当于“收割”，最后基于Pipeline流水线工具一键式生成产品化版本的过程则等同于“制作面包”。“耕耘”和“收割”过程由各组按微服务DevOps方式持续迭代交付、是最敏捷的（备注：除了公有云生产环境Ops，保障Beta/Gamma稳定运行也可以理解为窄义上的Ops），“播种”和“制作面包”的过程则是确保按IPD交付满足客户要求的集成版本、是最严谨的。
3.3 微服务开发流水线如何支撑版本火车进入高铁时代（当天启动当天发布）？
在流水线基础能力ready、微服务模式与IPD项目关系理顺之后，我们从微观层面描述一次版本从启动制作、验证到发布的全过程。
1. 日常运作：集成验证组每日定时巡检Gamma环境，各组需保障好自己的服务在Gamma环境中稳定运行，巡检发现的问题需及时解决；
2. 启动前检查：版本经理下发版本启动制作的计划之前，需确认当天的巡检用例必须是全部通过的，这是启动Gamma转测的第一条红线；
3. 锁定Gamma环境：启动Gamma环境转测试前，由集成验证组锁定环境，各组不能随意更新该环境的服务版本；
4. Gamma转测试：集成验证组通过自动化验证及手工测试，验收本次集成版本交付的需求，完成问题单回归以及DFx测试等；如果Gamma验证通过则继续向下制作版本，若不通过则针对严重问题进行局部更新（仅向问题相关的服务组单独开放权限）；
5. 制作发布包：产品集成交付组基于Pipeline工具自动化制作版本发布包，制作过程为：自动导出Gamma环境的微服务版本号列表，然后从软件包仓库中获取微服务版本进行打包制作；（备注：如果是公有云微服务应用包发布场景，则直接发布此应用包即可，不涉及下面的安装盘验证环节，END）
6. 安装盘自验：对于产品化版本，基于Pipeline自动化执行安装盘版本静默安装、Gamma环境与安装环境比对、自动化冒烟测试等一系列动作，若不通过则针对严重问题进行局部更新（仅向问题相关的服务组单独开放权限），通过则满足安装盘版本转测入口的第二条红线，交给集成验证组对安装盘进行测试；
7. 安装盘转测试：产品化安装盘的测试重点是验证Gamma环境下无法验证的用例，包括产品手工安装、安装场景下的差异化用例、与安装过程相关的重点问题单二次回归等（备注：因为有些用例需要在安装过程中手工输入参数，Gamma在线环境下是验证不了的，所以这个环节对于保障安装盘质量非常重要）；安装盘测试若发现严重问题进行局部更新（仅向问题相关的服务组单独开放权限）；
8. 解锁Gamma环境、发布版本：如果安装盘转测试通过则解锁Gamma环境、发布版本，END。

在一个成熟运作的版本团队中，整个过程有望控制在8小时以内（8H=Gamma验证3H+产品集成及自动化验证0.5H+安装盘场景差异化验证2.5H+预留局部更新2H），即版本火车真正进入了高铁时代（当天启动当天发布），这不正是我们孜孜以求的“互联网水平”的敏捷交付能力吗？

归纳起来，应用基于微服务架构及平台实现敏捷交付的关键点在于：
1. 验证环境永远在线，可随时随地进行集成验证与类生产验证，真正的“环境零等待”；
2. 每日定时巡检，保障基础验证环境稳定可用，在一个稳定的环境进行增量刷新，比较容易实现“缺陷快速定位和修复”；
3. 哪个环境发现的问题，就在哪个环境及时修复、并完成问题回归，实时保障“代码和环境高度健康”，版本想出就能出。
4. 基于一个已经充分验证的类生产环境“快照式”导出版本，制作的版本“质量一步到位”。

4 总结：微服务开发模式的核心理念
实施微服务开发模式的过程中，最关键的是理解其核心理念：解耦，在线，自治，自助。
解耦：解耦是一切的基础，所以微服务重点突出了一个“微”字。这里解耦的概念，不仅包括软件架构上从单体应用到微服务的解耦，也包含基层开发组织由大兵团到2-Pizza Team的解耦、从开发到上线全流程并行化的解耦；
在线：微服务管控平台和Stage环境要做到永久在线，方便开发者随时随地进行“自助式”集成验证；这就要求各个微服务Owner保障好自己的服务无间断地稳定运行，在升级时要么做到不中断业务，要么选择在无人访问的晚上进行升级；
自治：每个微服务是独立开发、部署、运行的最小单元，各服务只能以技术无关的服务接口方式对外提供能力，也只能通过服务接口调用其他服务提供的能力，这保证了每个微服务在技术实现上的独立性，只要服务接口保持不变就可以独立演进（因为单个微服务体量小，即使用新的语言、新的技术重写一遍，工作量也可以接受，更容易享受新的技术成果）；
自助：各开发者在流水线上就能自行完成微服务全生命周期的活动（从创建、开发、编译、验证、部署、升级、上线到下线，从生到死），不依赖于其他组织与人员；尤其是集成与验证活动的自助化，大大避免了传统大版本模式下“齐步走、相互牵制”的问题。