微服务架构学习与思考(07)：企业团队组织架构如何变革？
- 2021 年 1 月 27 日
- 筆記
- [04]分布式-架构-微服务, 微服务, 微服务架构
康威定律
康威定律 (康威法则 , Conway’s Law) 是马尔文·康威1967年提出的：
设计系统的架构受制于产生这些设计的组织的沟通结构。
康威定律告诉我们，如果我们实施了微服务，那么组织架构的变动也要跟着实施微服务架构而做出相应的调整。这样才有可能适应微服务的发展。
单体架构和微服务架构
先看看传统单体架构和微服务架构，如下图：
左半部分的单体架构图：
单体应用将所有功能放到一个进程中
扩展：通过将整个应用复制到多态服务器实现扩展
右半部分的微服务架构图：
微服务架构将功能分离，放到多个不同的进程中
扩展：通过将不同的服务分布于不同的服务器上，并按需要复制方式进行扩展
组织架构
- 单体应用的组织架构：
它是一个整体式的应用团队，每个团队按照职能来进行划分（图片左半部分），比如：UI团队，中间件团队，DBA团队。
不同职能的人属于不同的团队。做项目的时候就从不同职能部门选出一些人来负责项目。这样的组织架构有一个问题就是：跨职能部门沟通协调问题。这种团队组织形式不能适应微服务架构的特点。
- 微服务应用组织架构
微服务架构特点：每个微服务是独立的，团队可以独立开发，独立测试，独立部署，服务是自治的。相应的团队组成人员也有产品，技术，测试，团队成员在自己内部就可以完整的进行微服务各种功能开发。
这就要打破原先传统的那种按职能划分的组织团队形式，而要把不同职能的人组织在一个团队内，组成一个跨职能的产品组织架构。这样才能把一个微服务功能架构、设计、开发、测试、部署、上线运行，在一个组织内部完成，从而形成完整的业务、开发、交付闭环。
团队组织的变化
一图胜千言：
图片来自：//insights.thoughtworks.cn/management-of-microservices-team/
原先那种职能型的团队，变成了跨职能的小团队，这种团队和微服务架构对齐。
每个团队组织成员多少合适呢？
亚马逊的“两个披萨团队”，6-10人的规模。这个只是一种参考，毕竟每个公司规模、业务、行业、成员等不一样，找到适合自己的团队构成，就是最好的团队组织。
说明： 以上图片侵删，请联系主页邮箱！
