本文探讨了微服务架构中的组织结构，指出传统的职能型组织架构在面对大规模微服务开发时存在沟通成本高的问题。建议采用跨职能产品组织架构，按照微服务进行横向划分，减少沟通障碍，提高开发效率。这种架构下，团队负责微服务的全生命周期，实现'who build it, who run it'的理念。"
113088817,10547076,提升专注力：MySQL找数字训练与儿童注意力培养,"['专注力', '儿童教育', '数学游戏', '学习方法', '家庭教育']
前一篇介绍了微服务的技术架构，这一篇再来介绍微服务的组织架构，
之所以要聊组织架构，是由于著名的康威法则。
设计系统的组织，其产生的架构设计等价于组织间的沟通结构。
康威法则讲的是系统架构需要与开发系统的组织架构相匹配，如果不匹配就会造成沟通成本过高的问题。
例如开发一个单体应用，当参与开发的人员很少时，大家都隶属于一个团队，没有太大的问题。
但是一旦应用的规模很大，需要多个团队开发，大家在组织架构上属于不同团队，系统架构却又属于同一个系统，则会大大增加沟通协调成本。
此时最好的做法是让系统架构与组织架构保持一致，将一个系统按照团队拆分成多个系统。
对应到微服务，则需调整传统的组织架构，以适应微服务小、灵、快的特点，能够在短的时间内快速持续交付。
下面我来对传统组织架构与微服务组织架构进行详细说明，下图展示了两者的区别。
职能型组织架构
传统企业一般采用职能型组织架构。按照职能进行纵向切分，不同职能人员属于不同的团队。例如产品团队、研发团队、测试团队，各团队之间彼此独立。
当需要做某一个项目的时候，临时从各部门抽调人员，项目做完之后，人员再回到各自组织。
这样的组织架构有一个主要的问题：沟通协调成本高。在企业中，跨部门协作是被员工吐槽最多但又是最难解决的问题。传统职能型架构将一个项目中的人员切分到不同的团队，天然会增加人员之间的沟通成本。
沟通成本太高会导致需求推进缓慢。需求从产品团队到运维团队，中间经历了层层关卡。同样反过来看，当生产出现问题时，从运维逐层反馈给产品的过程也很缓慢。
因此职能型组织架构
最低0.47元/天 解锁文章
扫一扫
1044
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
