本文主要是介绍微服务架构设计 第一步: 从特性到业务场景，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
2016.9.8, 深圳, Ken Fang
微服务到底应该如何的识别? 微服务的粒度为何? 微服务该如何的分析与设计?
这些问题的答案, 取决于: 为何需要微服务?
为何需要微服务?
目的只有一个: 比竟争对手能更快的响应市场的变化与客户的诉求。
所以, 微服务的分析与设计, 决不是单纯的只考量技术上的解决方案。
微服务的分析与设计, 必需要掌握两个核心的原则:
1. 从外部的业务场景, 驱动微服务的分析与设计。
2. 经由微服务分析与设计出的微服务架构, 必需是能演进与能扩展的架构。
让我们开始探索微服务的分析与设计:
“微服务分析与设计 第一步: 从特性到业务场景”
任何的产品; 不论是与使用者会直接发生互动的应用系统, 或是提供给众多产品使用的平台; 都应该要先有一个完整的产品特性树。
产品特性树将使得我们可以很清楚的知道, 从外部使用者或外部产品的视角, 产品的微服务架构, 最终应提供哪些有价值的服务?
而团队中针对产品特性树中的每一个特性, 都应该要有一个主要的特性负责人; 每一个特性都会有一个主要的特性负责人负责, 每一个特性负责人, 都将负责多个特性。
在微服务分析与设计中, 特性负责人的主要责任便是: 经由与团队中各不同领域的成员; 架构师, 开发骨干人员, 测试经理, 资深测试人员; 共同具体分析出每个特性的业务场景与微服务的边界上下文 (Bounded Context)。
特性负责人与团队成员协作, 分析每个特性业务场景的主要步骤如下:
1. 特性负责人, 分析特性是由哪些业务活动所构成的?
2. 特性负责人, 针对特性中的某个业务活动, 分析出此业务活动的基本流。
3. 团队成员, 以特性负责人所分析出的基本流为基础, 分析出相关的扩展流与异常流。
4. 特性负责人, 决定团队成员所分析出的扩展流与异常流, 哪些是需在这个版本中, 置入到微服务的架构中, 来进行开发的。
5. 特性负责人, 再选取特性中的其他业务活动, 并重复步骤二至步骤五。直到特性中的所有业务活动均已分析完毕为止。
当特性负责人, 将特性的所有业务活动均分析出, 其各自的基本流, 扩展流与异常流之后, 特性负责人便可经由组合基本流, 扩展流与异常流, 而分析出从外部使用者或外部产品的视角, 有价值的端到端的业务场景切片。
特性负责人经由与团队成员的协作:
A. 团队成员, 分析出扩展流与异常流; 团队成员作加法。
B. 特性负责人, 从团队成员所分析出扩展流与异常流中, 删除不需要置入微服务的架构中, 去进行开发的扩展流与异常流; 特性负责人作减法。
团队成员作加法, 特性负责人作减法; 此种团队协作的方式, 不仅使团队成员间, 能对需开发的微服务场景 (需求), 迅速的达成一致的共识, 并且能使得每个微服务, 都能以最少的场景 (需求), 却能对外部使用者或外部产品, 产生最大的正面影响。
这篇关于微服务架构设计 第一步: 从特性到业务场景的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
