微服务设计:团队拓扑与SEED(S)流程
1. 微服务团队拓扑设计
1.1 发布团队的引入
在微服务团队拓扑图中,我们在微服务团队框的末端附近添加一个红色方块,代表发布团队。不过,采用发布团队的方式存在协调成本的问题,尤其是在大规模场景下,这可能会成为一个大问题。例如,若要对多个微服务进行每日发布,发布团队将难以协调所有活动。在这种情况下,就需要改变团队设计,将部署职责转移到各个微服务团队。
1.2 消费者团队:API 团队
微服务只有被使用才有价值,因此需要确定微服务的消费者以及他们与系统团队的交互方式。在我们的模型中,微服务系统的主要消费者是 API 团队。API 团队负责将微服务作为应用程序编程接口(API)暴露给其他开发团队。例如,移动应用开发团队将与该团队发布的 API 进行交互,而不会直接调用微服务。
以下是 API 团队的详细信息:
- 团队类型 :流对齐团队
- 团队规模 :5 - 8 人
- 职责 :
- 在系统边界设计、开发和维护 API
- 将 API 连接到内部微服务
在团队拓扑模型中,我们在图的顶部添加另一个与微服务团队颜色相同(黄色)的矩形来表示 API 团队,因为它也是流对齐团队。使用黑色箭头表示微服务团队和 API 团队之间的依赖关系,这表明微服务团队需要确保其服务可以以自助服务的方式被调用和使用。
1.3 团队拓扑总结
通过定义上述团队及其交互方式,我们形成了微服务运营模型。
超级会员免费看
订阅专栏 解锁全文
53

被折叠的 条评论
为什么被折叠?



