规模化微服务与研发组织管理

最近在工作中遇到很多IT圈的朋友，这些IT圈的朋友大部分都知道微服务，并且有相当的一部分正在参与在企业内部推行微服务的活动。

大家都非常清楚微服务的价值，随便拉一个出来就可以说出微服务的几大优点，高内积低耦合的架构设计、异构的服务带来技术选型的灵活性、独立发布与部署、高效的IT响应力......

大家同时也有很多疑问，微服务如何划分？微服务分到何种粒度合适，不是不是越小越好？微服务架构下，团队如何划分？开发活动如何组织？如何保证服务之间的API的有效集成？如何保证零散的服务最终能够构建成殿堂级的产品？ 如何保证团队之间的高效沟通？如何保证团队的工作效能，会不会有的服务团队的工作量不饱满？
等等一系列问题。

我就这些问题谈一下我的思路与看法。

为什么微服务作为一种系统架构会带来新的挑战？这些挑战在单一结构的系统下是如何被克服的？

其实上规模的系统软件的研发早已经不是什么新鲜事，很多的应用软件，操作系统的研发人员动辄上百、上千。国内有的科技企业某一条产品线的研发人员就会达到上百人的规模。当然对于大型软件，研发方法也分为瀑布式和敏捷式两种，敏捷方法正在逐步的取代瀑布式的开发方式，成为了今天软件开发的主流。对于规模化的软件，敏捷方法给出的建议是对于团队之间的依赖，尽早集成，尽早反馈，从而规避后期的集成风险，因此，自动化测试以及持续集成被作为技术支撑手段被应用的淋漓尽致。
下图是大致的工作流程图。

image.png

当一个软件规模特别巨大的时候，比如说操作系统，这个时候继续集成这种方式就不够了，试想一下一个开发的机器上如何去运行一个操作系统级的软件产品做单元测试呢？ 假如10各团队，100人是持续集成的实践的极限，那么对于1000人的研发队伍，如何管理呢？我没有接触过这么大规模的研发管理，但是我推测是这样的，对于这样的组织，需要增加层级来进行治理，为了避免层级的增加而导致协同成本的上升，根据康威定律的启发，需要建设对应层级的技术支撑，或者叫技术平台，来提高协同的效率。 结构可能是这样的......

image.png

一般的组织都会有一个或者多个层次的协同团队，这种层次的增加是自然而然的事情，但关键的问题是，组织层次的增加不会太来沟通协同效率的提升。敏捷强调组织的自我管理，能够进行自我管理的组织效能是最高的，但是规模化组织的自我管理需要制定标准，而对于研发而言，标准的制定落实到平台上是最切实可靠的，上图中对于coordination team的系统就是一个技术平台，也是一个标准平台，各个group的团队产生的组件都必须要保证能够和标准平台一起运行。使用这种开发模式，就可以进行超大规模的组件式软件开发，因为这个结构是可以扩展的，想象一下每个group的产出物里如果都有一个标准平台呢？是不是很有意思。

对于微服务而言，为什么他会带来新的挑战，为什么大家会不适应？我认为原因是，微服务的系统结构把超大规模软件研发的模式带入到了大规模甚至是一般性规模的软件产品研发中，导致大家手足无措，因为国内的超大规模软件研发的经验比国外少，为什么这么说呢？拿操作系统为例，windows和linux都是国外研发出来的，国内还没见到成功的操作系统。

而寻求解决之道，我认为要参考既有的超大规模软件的研发经验。

微服务研发管理之所以带来困扰，原因可能如下图所示，服务与服务之间有依赖，
对应的团队与团队之间就会有沟通协同的需要，当服务之间相互依赖比较多的时候，就会增加服务之间的耦合性，微服务的价值就会大打折扣。

image.png

有人会有疑问，这样的情况是因为服务拆分的不够合理，没有很好的识别bounded context，其实这也是一个balance，服务之间多多少少都有联系，服务之间耦合度降低到多少，才能够算是低耦合呢？这个没有标准答案。
暂时先搁置耦合度以及微服务个数的问题不谈，反观上图中令人头疼的原因，其实在于服务之间、以及团队之间的沟通没有被有效的管理，让人无处着手。
从组织协同的角度来看，解决此类问题的方法是增加协同机构，按照康威定律，这个协同机构需要技术实践来支撑才能来的高效。

image.png

而正是由于协同机构以及相应的技术支撑的出现，才能让"集市"变成"殿堂", 这里不是要批判《大教堂与集市》这本书里的观点，因为书中提到的linux系统在开源之前，已经有了一个版本，这就代表着本身已经形成了一定的标准。

更复杂的系统结构，更多的协同，更多的烦恼

我们进一步来看真正的系统结构，事情会更加复杂一些，

image.png

看，不光是服务之间有集成，前端和后端的team之间也有复杂的集成，随着前端设备的多样性，前端团队的形态也会随着技术分为多个开发团队。
由于PC前端开发工作量大，团队有可能被分为多个团队，也就是前端开发团队之间也会存在协同。看着是不是很头疼。

通常规避前后端协同复杂度的方式，是把前端开发与后端开发放在一个团队内部，如下图：

image.png

造成的问题是一个团队会有后端产出物和部分的前端产出物，在打包的时候会把前端代码共同打成一个包，因为前端很可能使用相同技术栈（如PC前端），那么不同团队之间的前端开发人员会共享部分的代码库，因此造成了团队之间额外的严重依赖。

如果我们把团队之间依赖分类，主要有：代码库依赖、API依赖，也可以叫做编译时依赖和运行时依赖。代码库依赖往往比API依赖要重，应优先避免。

那么我们假设一个理想的划分是这样的：

image.png

这样的结构可以很好的避免团队之间的代码级依赖以及API级的直接依赖。那么剩下的问题就是，如何实现coordination team 管理的协同标准部件呢？协同团队和协同标准平台如何在项目管理中发挥应有的作用呢？ 这个问题我们要分别从软件研发的价值流以及技术实现两方面来考虑。

未完待续....