微服务架构 (八): 业务驱动与团队协作微服务粒度设计: 微服务内部的世界
2016.8.20, 深圳, Ken Fang
在“微服务架构設計 (七): 微服务粒度设计上的核心设计原则与思考的面向” 的一文中, 探讨了从微服务外部的世界驱动微服务粒度的设计。如文中所描述, 为了保障微服务整体的性能与可靠度, 可能会设计出粒度较大的微服务, 而降低了微服务持续部署的速度。
然而, 架构师也不能光只看到微服务外部的世界, 而轻忽或完全忽略了微服务内部的世界。因为, 当架构师轻忽或完全忽略了微服务内部的世界时, 将可能会使得微服务的粒度过大, 而使得微服务内部世界的复杂度过高, 开发与测试人员了解微服务需求 (场景) 的难度增加, 微服务的缺陷率升高, 微服务修复缺陷的时间增长。最终, 不仅使得微服务持续部署的速度越来越慢, 同时微服务整体的交付与运维的质量也会降低。
架构师需仅记微服务 “外部的世界” 远比 “内部的世界” 要来得重要。但, 并不代表著架构师可轻忽或完全忽略了微服务内部的世界。
架构师如何能避免自身轻忽或完全忽略了微服务内部的世界？
业务驱动与团队协作将能使得架构师, 避免自身轻忽或完全忽略了微服务内部的世界; 使得架构师可在微服务外部的世界与内部的世界中, 取得一较好的平衡点与可落地的实施方案。
I. 业务驱动: 业务驱动指的是, 架构师将微服务需达到的业务目的, 纳入微服务粒度设计的考量。
以不同的业务目的为例子来说明:
| Case |
业务目的 |
部署 |
性能 |
水平扩展 |
可靠性 |
微服务粒度 |
| A |
更快响应市场 |
重要性高 |
重要性低 |
重要性低 |
重要性低 |
小 |
| B |
更快响应速度 |
重要性低 |
重要性高 |
重要性高 |
重要性低 |
大 |
| C |
提升可靠性 |
重要性低 |
重要性低 |
重要性低 |
重要性高 |
大 |
II. 团对协作:
对于 Case A: 更快响应市场, 架构师设计了较小粒度的微服务。当然, 这样的设计, 就如在微服务架构設計 (七): 微服务粒度设计上的核心设计原则与思考的面向” 的一文中所提及的, 因微服务粒度小, 可能将使得微服务间的远程调用增加, 而使得整体微服务的性能降低。
此时, 架构师便必需与团队成员协作, 共同探讨出如何解决整体微服务性能降低的问题? 例如: 牺牲些水平扩展的能力; 将会产生互相调用的微服务,部署在同一节点上。
而对 Case B 与Case C, 就如同本文先前所提的: 微服务的粒度过大, 而使得微服务内部世界的复杂度过高, 开发与测试人员了解微服务需求 (场景) 的难度增加。
此时, 架构师、开发人员与测试人员便需经由轻量级, 可视化的工程实践 (注一) , 共同协作, 高效的完成微服务的分析、设计与测试用例的设计。以有效的提升开发与测试人员的效率与质量。
“微服务架构設計 (七): 微服务粒度设计上的核心设计原则与思考的面向” 与 “微服务架构設計 (八): 业务驱动与团队协作微服务粒度设计: 微服务内部的世界”, 分别从微服务外部的世界与微服务内部的世界, 探讨了设计微服务粒度; 边界上下文 (Bounded Context)。
总结这两篇文章, 所得出的: 设计微服务粒度; 边界上下文 (Bounded Context) 的原则:
A. 微服务 “外部的世界” 远比 “内部的世界” 重要。
B. 业务驱动; 在微服务外部的世界与内部的世界中, 取得一较好的平衡点。
C. 协作、协作、协作; 找到最适合市场, 产品与团队现况的微服务实施方案。
注一: 轻量级, 可视化的工程实践, 将在后续探讨: 微服务产品级敏捷时, 再来讨论。