成功的微服务，需要企业组织架构如何变革？

微服务架构表现为组件化、模块化，
每个组件或模块称为产品中的一个服务，
不同的服务由不同的人员来开发和维护，
从而规避传统单体架构下面临的各种问题，
实现迭代速度快、新人易上手、业务高可用等好处，
也因此，微服务架构成为企业数字化转型升级的必备武器。

需要注意的是，
康威老爷子早已告诫我们：
系统设计等同于组织形式，
即团队要适应业务系统的架构。

由于传统单体应用和微服务架构差异巨大，
传统企业的微服务实践要取得成效，
组织架构的变革当然是必不可少的。
那么，
成功的微服务化改造需要怎样的组织架构呢？

匹配微服务：从中心化到去中心化

首先，我们需要一种去中心化的组织架构， 
因为单个服务的owner需要拥有对该服务的绝对自主权。 
我们知道，微服务降低业务研发难度， 
来自于其分而治之的基本思想， 
一个大型系统分割成多个小而自治的服务， 
支持每个服务采用不同的标准和技术来开发， 
可以独立修改、独立部署而不影响其他服务的运行， 
服务之间采用轻量级的通信机制。 
 
回顾传统单体应用的中心化架构， 
小功能往往要积累到大版本才能上线， 
上线又要开总监级别的大会， 
微服务化之后， 
如果仍然保持这种先请示后上线的组织架构， 
是否上线、何时上线、选择何种数据库都需要高层决策， 
那么服务拆分的粒度越细，决策的瓶颈就越明显。 
采用去中心化的组织架构， 
每一个服务由一个独立、自治的小团队开发和维护， 
小团队负责人自主决定服务的技术选择和开发计划， 
微服务架构快速迭代的能力才能体现出来。 
同时， 建立相应的机制来保证小团队的主动性， 
避免因为小团队责任心不足而影响整个产品发展。 
至于 小团队的终极规模，
可以参考“两个披萨原则”， 
通常是5-7个人， 
超过10人则考虑进一步分散。

 

 

但如同业务拆分很难一步到位，
团队拆分也需要相应地逐步拆分。
需要注意的是，
由于组织架构的变革会涉及各种利益关系，
管理层共识和第一推动力的前提是必不可少的，
可以成立专门的架构师（中间件）团队执行微服务改造。
一来架构组可以劝说业务开发组和运维组实施微服务化，
二来微服务实践是一个渐进过程而非一场运动，
一旦实施了微服务，
业务系统就处于不断更新和迭代的状态中，
也处于不断的拆分和组合中，
架构组可以专心打造适合业务的、可靠的中间件，
比如消息队列、缓存等，
帮助企业更好地hold住这个演进的过程。

 

业务相对简单或者人力不足的企业也可以没有架构组，
不过中间件还要依赖于成熟第三方平台。

搞定微服务：从U型组织到全能小团队

伴随着组织架构的去中心化，
全权负责每一个服务的小团队必须是全能的，
或者说是全栈的， 
搞得定用户交互UI设计、后台服务开发， 
做得了数据库管理、服务运营和运维等， 
惟其如此，才能实现服务自治。 
传统组织往往是一种职能型组织结构， 
也称为U型组织， 
不同职能人员分别隶属于不同的团队， 
比如产品、开发、测试、运维团队之间彼此独立。 
U型组织下跨部门沟通协调成本很高， 
产品需求实现和使用反馈的链路都很长， 
即便管理层把权力下放了， 
迭代效率也不高，还容易出问题， 
对软件交付并不友好。 
所以， 
为每一个服务设置一个专属的全能小团队， 
由产品、开发和测试人员负责服务的迭代开发， 
DBA和运维人员提供平台化的CI/CD、治理等底层支持， 
这是微服务架构的呼唤。 
全能小团队和传统的项目组有聚有散不同， 
因为微服务长久存在而需要长期稳固的合作。 
网易很早就采用一种专人就位的职能支撑模式， 
由各个职能部门培训并安排专人入驻各个产品组， 
同时确保岗位人员的专业性和产品团队的沟通效率， 
通过这种方式成功孵化了大量的互联网产品， 
这是传统企业在服务化改造过程中可以效仿的。 

玩转微服务：从运维背锅到DevOps组织

全能也还不够，微服务还意味着需要组织DevOps化。 
微服务意味着更多的并行开发、更频繁的发布和部署， 
意味着更高的整体复杂度， 
这时候打通组织和流程实现DevOps是不能少的。 
 
开发团队和运维团队如果不能精诚协作， 
还是沿袭传统的工作模式， 
一个只管开发、构建、测试， 
一个只顾提供资源、部署、运维， 
运维团队还是背锅侠， 
微服务业务还是没有办法高效地上线部署运行的。 
组织DevOps化，即需要开发与运维融合， 
不同服务、不同版本的交付环境需要开发来写， 
因为运维对不同模块的不同配置及更新不熟悉， 
很容易出现部署出错的情况，影响业务正常上线； 
而服务注册、发现、治理、配置等， 
每一个业务单独一套框架是不科学的， 
应当下沉成为运维团队统一管理的基础设施。 
所以开发团队和运维团队的工作都有变化， 
好在成熟的容器技术提供了融合的工具。

 

 

组织DevOps化的最大变化，
是开发团队需要完成环境配置的工作，
而运维团队需要将微服务通用能力平台化。

对于开发而言，
写个Dockerfile说明容器内部的运行环境，
仅仅是工作量增加5%的问题，难度不大。
对于运维而言，
灰度发布、自动化测试运维、故障自愈等工作就复杂了，
对于用户众多、功能复杂的大型业务尤其如此，
容器管理编排体系成为了基础，
顺畅的持续集成/持续交付能力是不可或缺的内功，
这些都需要打造给力的工具平台来支持。
满足全能团队需求的当然是完备的微服务平台，
容器化、DevOps、服务治理、监控、自动化测试统统搞定。
举个例子，
网易杭州研究院就是一个典型的DevOps组织，
整个分工界面简化如图，

 

云计算数据中心由运维部门来管理，
上面是云计算平台组，
该组基于OpenStack开发了租户可自助操作的云平台；
云平台包括了PaaS、容器、微服务管理和治理等组件，
PaaS组件点击可得，提供SLA保障；
容器组件提供容器管理、持续集成、持续部署的工具链；
微服务组件支持业务部门进行微服务的开发；
中间件组或者说架构组和云平台组沟通密切，
共同探讨如何以正确的姿势使用云平台组件；
最上面是业务部门的前端组、业务开发组和中台开发组。

享受微服务：构建中台团队

DevOps化、建成微服务平台之后，
大规模的业务中台化便可提上日程。 
大家可能难以理解网易案例中的“中台开发组”， 
其实， 
传统企业也有组件化、模块化开发模式， 
实施应用架构微服务化改造之后， 
可复用的组件就可以变成一个个服务， 
并被注册到微服务平台的注册中心， 
企业可以从业务开发组分离出几个中台开发组， 
负责将可复用的能力和代码做成现成的中台服务， 
提供给业务系统开发团队使用。 
这样操作， 
一来数据模型会统一， 
数据共享和后续分析挖掘都更方便， 
二来业务开发组不需要全部从零开始， 
业务系统开发效率可以再上一个台阶。 
网易最近几年在不同领域迅速推出各种新产品， 
背后的中台能力功不可没。 

总结

企业微服务化改造的收益和挑战都是巨大的， 
组织架构如果能够做出合适的调整， 
走向去中心化、小团队化、全能化和DevOps化， 
以适应微服务架的特点， 
微服务的收益将会大于成本， 
并且收益会逐步递增，而成本会递减。 
相信越来越多的企业都能从微服务架构中获益。

点击了解网易云轻舟微服务，获取方案