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

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

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

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

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

首先，咱们须要一种去中心化的组织架构， 
由于单个服务的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升级的正确姿式以及原理
【推荐】 从需求到数据到改进，如何造成闭环