成功的微服务，需要企业组织架构如何变革？
微服务架构表现为组件化、模块化，
每个组件或模块称为产品中的一个服务，
不同的服务由不同的人员来开发和维护，
从而规避传统单体架构下面临的各种问题，
实现迭代速度快、新人易上手、业务高可用等好处，
也因此，微服务架构成为企业数字化转型升级的必备武器。
需要注意的是，
康威老爷子早已告诫我们：
系统设计等同于组织形式，
即团队要适应业务系统的架构。
由于传统单体应用和微服务架构差异巨大，
传统企业的微服务实践要取得成效，
组织架构的变革当然是必不可少的。
那么，
成功的微服务化改造需要怎样的组织架构呢？
匹配微服务：从中心化到去中心化
首先，我们需要一种去中心化的组织架构，
因为单个服务的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化，
以适应微服务架的特点，
微服务的收益将会大于成本，
并且收益会逐步递增，而成本会递减。
相信越来越多的企业都能从微服务架构中获益。
相关文章：
【推荐】 关于Runtime.getRuntime().exec()产生阻塞的2个陷阱
【推荐】 windows系统下npm升级的正确姿势以及原理
【推荐】 从需求到数据到改进，如何形成闭环
