微服务架构浅谈（二）--团队职能的划分和去中心化治理
1.微服务架构团队职能的划分
传统单体架构将系统分成具有不同职责的层次，对应的项目管理也倾向于将大的团队分成不同的职能团队，主要包括：用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。每个团队只对自己分层的职责负责，并对使用方提供组件服务质量保证。如果其中一个模块化组件需要升级、更新，那么这个变更会涉及不同的分层团队，即使升级和变更的改变很小，也需要进行跨团队沟通：需求阶段需要跨团队沟通产品功能，设计阶段需要跨团队沟通设计方案，开发阶段需要跨团队沟通具体的接口定义，测试阶段需要沟通业务回归等事宜，甚至上线都需要跨团队沟通应用的上线顺序。可见在传统的整体架构下，后期的维护成本很高，出现事故的风险很大。
根据康威定律，团队的交流机制应该与架构设计机制相对应。因此，在微服务架构下，职能团队的划分方法是我们首先要考虑的一个核心要素微服务架构按照业务的功能进行划分，每个单一的业务功能叫作一个服务，每个服务对应一个独立的职能团队，团队里包含用户交互UI设计师、后台服务开发人员、DBA、运营和运维人员。
在传统的整体架构中，软件是有生命周期的，经历需求分析、开发和测试，然后被交付给运维团队，这时开发团队将会解散，这是对软件的一个“放手”。而在微服务架构中，提倡运维人员也是服务项目团队的一员，倡导谁开发、谁维护，实施终生维护制度。
在业务服务的内部实现需要升级或者变更时，团队内的各角色成员进行沟通即可，而不需要进行跨团队沟通，这大大提高了沟通效率。只有服务之间的接口需要变更时才需要跨部门沟通，如果前期在服务之间的交互上定义了良好的接口，则接口变更的概率并不大，即使接口模式有变更，也可以通过一定的设计模式和规范来解决。
2微服务的去中心化治理
笔者曾经在一个互联网平台上工作，平台的决策者倡导建设API网关，所有外部服务和内部服务都由统一的API网关进行管理。在项目初期，中心化的API网关统一了所有API的入口，这看起来很规范，但从技术角度来看限制了API的多样化。随着业务的发展，API网关开始暴露问题，每个用户请求经过机房时只要有服务之间的交互，则都会从API网关进行路由，服务上量以后，由于内部服务之间的交互都会叠加在API网关的调用上，所以在很大程度上放大了API网关的调用TPS，API网关很快就遇到了性能瓶颈。
这个案例是典型的微服务的反模式，微服务倡导去中心化的治理，不推荐每个微服务都使用相同的标准和技术来开发和使用服务。在微服务架构下可以使用C++开发一个服务，来对接Java开发的另外一个服务，对于异构系统之间的交互标准，通常可以使用工具来补偿。开发者可以开发共用的工具，并分享给异构系统的开发者使用，来解决异构系统不一致的问题，例如：Thrift远程调用框架使用中间语言（IDL）来定义接口，中间语言是独立于任何语言的，并提供了工具来生成中间语言，以及在中间语言与具体语言之间的代码转换。
微服务架构倡导去中心化的服务管理和治理，尽量不设置中心化的管理服务，最差也需要在中心化的管理服务宕机时有替代方案和设计。在笔者工作的支付平台服务化建设中，第1层SOA服务化采用Dubbo框架进行定制化，如果Dubbo服务化出现了大面积的崩溃，则服务化体系会切换到点对点的hessian远程调用，这被称为服务化降级，降级后点对点的hessian远程调用时没有中心化节点，整体上符合微服务的原理。
转载博客地址：https://blog.csdn.net/kwame211/article/details/78015601