微服务系列:微服务架构中职能团队的划分

Posted 云时代架构

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务系列:微服务架构中职能团队的划分相关的知识,希望对你有一定的参考价值。

传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证。如果其中一个模块化组件需要升级、更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段需要沟通业务回归等事宜,甚至上线都需要跨团队沟通应用的上线顺序。可见在传统的整体架构下,后期的维护成本很高,出现事故的风险很大。

根据康威定律,团队的交流机制应该与架构设计机制相对应。因此,在微服务架构下,职能团队的划分方法是我们首先要考虑的一个核心要素。

微服务时代的团队沟通方式如图1-9所示。


图1-9


微服务架构按照业务的功能进行划分,每个单一的业务功能叫作一个服务,每个服务对应一个独立的职能团队,团队里包含用户交互UI设计师、后台服务开发人员、DBA、运营和运维人员。

在传统的整体架构中,软件是有生命周期的,经历需求分析、开发和测试,然后被交付给运维团队,这时开发团队将会解散,这是对软件的一个“放手”。而在微服务架构中,提倡运维人员也是服务项目团队的一员,倡导谁开发、谁维护,实施终生维护制度。

在业务服务的内部实现需要升级或者变更时,团队内的各角色成员进行沟通即可,而不需要进行跨团队沟通,这大大提高了沟通效率。只有服务之间的接口需要变更时才需要跨部门沟通,如果前期在服务之间的交互上定义了良好的接口,则接口变更的概率并不大,即使接口模式有变更,也可以通过一定的设计模式和规范来解决。

推荐一起学习《分布式服务架构:原理、设计与实战》一书,它是一本不可多得的理论与实践相结合的架构秘籍,是作者多年工作经验积累的结晶。京东购买请扫描下方二维码。

微服务系列(一):微服务架构中职能团队的划分



如果你想成为优秀的架构师

在【云时代架构】精品群免费进!


我在【云时代架构】技术社区,你在哪里?


还等什么,赶快加入【云时代架构】技术社区!

请猛扫下面二维码。


云时代架构





做互联网时代最适合的架构

开放、分享、协作

快速关注,请猛扫下面二维码!


  

简书博客                      云时代架构



以上是关于微服务系列:微服务架构中职能团队的划分的主要内容,如果未能解决你的问题,请参考以下文章

微服务架构的核心要点和实现原理

微服务干货系列使用微服务架构之前,你必须知道的

分析解剖微服务系列-SOA和微服务异同

微服务实践系列一之微服务架构

微服务实践系列一之微服务架构

微服务如何划分