微服务架构核心(四)- 微服务组织架构

前一篇介绍了微服务的技术架构,这一篇再来介绍微服务的组织架构。

之所以要聊组织架构,是由于著名的康威法则

康威法则:设计系统的组织,其产生的架构设计等价于组织间的沟通结构。

康威法则讲的是系统架构需要与开发系统的组织架构相匹配,如果不匹配就会造成沟通成本过高的问题。

例如开发一个单体应用,当参与开发的人员很少时,大家都隶属于一个团队,没有太大的问题。

但是一旦应用的规模很大,需要多个团队开发,大家在组织架构上属于不同团队,系统架构却又属于同一个系统,则会大大增加沟通协调成本。

此时最好的做法是让系统架构与组织架构保持一致,将一个系统按照团队拆分成多个系统。

对应到微服务,则需调整传统的组织架构,以适应微服务小、灵、快的特点,能够在短的时间内快速持续交付。

下面我来对传统组织架构与微服务组织架构进行详细说明,下图展示了两者的区别。

职能型组织架构

传统企业一般采用职能型组织架构。按照职能进行纵向切分,不同职能人员属于不同的团队。例如产品团队、研发团队、测试团队,各团队之间彼此独立。

当需要做某一个项目的时候,临时从各部门抽调人员,项目做完之后,人员再回到各自组织。

这样的组织架构有一个主要的问题:沟通协调成本高。在企业中,跨部门协作是被员工吐槽最多但又是最难解决的问题。传统职能型架构将一个项目中的人员切分到不同的团队,天然会增加人员之间的沟通成本。

沟通成本太高会导致需求推进缓慢。需求从产品团队到运维团队,中间经历了层层关卡。同样反过来看,当生产出现问题时,从运维逐层反馈给产品的过程也很缓慢。

因此职能型组织架构不能满足微服务的特点。

跨职能产品组织架构

针对上面出现的问题,解决方法就是采用跨职能产品组织架构,按照微服务进行横向切分。

每一个微服务都有自己专属的产品、研发、测试人员。团队成员围绕微服务进行不断的迭代开发。

微服务不像项目,结束之后人员回到各自组织。微服务是可以一直存在的,因此人员也可以在微服务中长期保持合作关系,跨部门的沟通成本大大降低。

而DBA和运维则组成平台团队,以平台化的方式提供微服务需要底层支撑,例如:持续交付、资源分配、网络、存储等等。

从上面的介绍可以看到,采用跨职能产品组织架构以后,微服务团队可以更加方便、快捷的发布微服务。

总结

为了契合微服务小、灵、快的特点,更提倡大家使用跨职能产品组织架构

这种组织架构的核心,是开发微服务的团队,应该负责微服务的设计、开发、测试、部署直至运行的全生命周期,形成一个完整的闭环。一句话总结就是who build it , who run it

上篇微服务架构核心(五)- 服务发现
下篇微服务架构核心(三)- 微服务技术架构体系