前一篇介绍了微服务的技术架构，这一篇再来介绍微服务的组织架构，
之所以要聊组织架构，是由于著名的康威法则。
设计系统的组织，其产生的架构设计等价于组织间的沟通结构。
康威法则讲的是系统架构需要与开发系统的组织架构相匹配，如果不匹配就会造成沟通成本过高的问题。
例如开发一个单体应用，当参与开发的人员很少时，大家都隶属于一个团队，没有太大的问题。
但是一旦应用的规模很大，需要多个团队开发，大家在组织架构上属于不同团队，系统架构却又属于同一个系统，则会大大增加沟通协调成本。
此时最好的做法是让系统架构与组织架构保持一致，将一个系统按照团队拆分成多个系统。
对应到微服务，则需调整传统的组织架构，以适应微服务小、灵、快的特点，能够在短的时间内快速持续交付。
下面我来对传统组织架构与微服务组织架构进行详细说明，下图展示了两者的区别。
职能型组织架构
传统企业一般采用职能型组织架构。按照职能进行纵向切分，不同职能人员属于不同的团队。例如产品团队、研发团队、测试团队，各团队之间彼此独立。
当需要做某一个项目的时候，临时从各部门抽调人员，项目做完之后，人员再回到各自组织。
这样的组织架构有一个主要的问题：沟通协调成本高。在企业中，跨部门协作是被员工吐槽最多但又是最难解决的问题。传统职能型架构将一个项目中的人员切分到不同的团队，天然会增加人员之间的沟通成本。
沟通成本太高会导致需求推进缓慢。需求从产品团队到运维团队，中间经历了层层关卡。同样反过来看，当生产出现问题时，从运维逐层反馈给产品的过程也很缓慢。
因此职能型组织架构不能满足微服务的特点。
跨职能产品组织架构
针对上面出现的问题，解决方法就是采用跨职能产品组织架构，按照微服务进行横向切分。
每一个微服务都有自己专属的产品、研发、测试人员。团队成员围绕微服务进行不断的迭代开发。
微服务不像项目，结束之后人员回到各自组织。微服务是可以一直存在的，因此人员也可以在微服务中长期保持合作关系，跨部门的沟通成本大大降低。
而DBA和运维则组成平台团队，以平台化的方式提供微服务需要底层支撑，例如：持续交付、资源分配、网络、存储等等。
从上面的介绍可以看到，采用跨职能产品组织架构以后，微服务团队可以更加方便、快捷的发布微服务。
总结
为了契合微服务小、灵、快的特点，更提倡大家使用跨职能产品组织架构。
这种组织架构的核心，是开发微服务的团队，应该负责微服务的设计、开发、测试、部署直至运行的全生命周期，形成一个完整的闭环。一句话总结就是who build it , who run it。
