微服务架构-多团队协同(3.15)

微服务架构在实施的时候一定需要考虑多团队开发的问题，既要保证多团队高效协同，又需要保证多个团队完全做到独立自治相互干扰最小。我们基于上图示例来举例说明，比如一个供应链系统一共分为了20个模块，这20个微服务模块再按照耦合性分离为三个独立的开发包，然后招标三个独立的软件厂商进场进行定制开发。那么基于上面这个场景我们如何来处理。

首先对于单个厂商内部的多模块协同问题，这个实际上属于开发团队内部的集成，只需要启用注册中心即可，不需要使用到微服务网关能力。只有该开发团队提供的接口需要被其它两个开发团队，或者整个供应链域的外部业务系统使用的时候，才需要使用到网关。

对于网关，我们实际上推荐的架构是两层网关模式，即首先是开发团队内部有一个独立的微服务网关，由开发团队自己进行管理，通过网关暴露提供给外部的接口。同时在多个网关之上，为了朝整个供应链域外部提供统一的服务目录，我们需要将这些接口服务再接入上层的API服务网关或轻量的ESB服务总线。

当然另外一种模式就行开发团队内部不启用微服务网关，而将自己的所有微服务模块，全部接入到外部的API服务网关上提供能力。那么这个时候对这块的接口服务监控和管理则不在单纯在开发团队内部完成。 而这个时候的关键问题或者需要验证的就是，能否是多个团队启用了多套微服务注册中心，但是共用一套微服务网关。

考虑到跨团队协同的时候，对于接口服务调用日志的管控治理能力要求更高，其中包括了安全，日志，流控，负载均衡，监控预警等多方面的能力。而这些都不是简单的类似Zuul网关能够满足的，需要进行扩展。因此实际上启用两层网关模块往往更好，开发团队的独立自治性也更强。唯一要考虑就是两层网关模式下对性能的影响。

其次对于DB数据库的拆分问题，在多开发团队模式下，DB数据库实际上完全可以基于底层数据的耦合性来考虑是否需要拆分到微服务模块级别，还是受只拆分到开发团队包级别就够了。总体原则如下：

1. 底层为核心基础数据和共享数据，数据间依赖大的情况，建议底层数据库不再拆分，到开发包级别即可。

2. 各个微服务模块为纵向业务为主，底层数据耦合性小情况，数据库可以拆分到最新的微服务模块粒度。

所以在都开发团队协同下的微服务架构实施，还不是简单的采用类似SpringCloud框架的问题，而是需要有一个统一的集成商的问题，因为对于开发团队间的交互，接口集成，服务对外暴露等，这些是属于跨开发团队外的事情，同时还涉及到外部的类似轻量总线，API网关的部署，服务注册和管理等一系列问题。因此最好方法就是这些要单独进行管控。

当然类似很早前我讲私有云PaaS建设的时候也谈到，这个集成商本身也是基础平台能力建设商，除了接口集成外，还需要提供底层基础技术平台和技术组件服务能力。也就是我们常说的技术中台构建和服务能力暴露也需要独立的平台支撑厂家来完成。