活动主持人

个人签名

169篇博客

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

活动主持人2019-03-22 11:18

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



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

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

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

首先,我们需要一种去中心化的组织架构,
因为单个服务的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化,
以适应微服务架的特点,
微服务的收益将会大于成本,
并且收益会逐步递增,而成本会递减。
相信越来越多的企业都能从微服务架构中获益。


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