微服务架构 (八): 业务驱动与团队协作微服务粒度设计: 微服务内部的世界

2016.8.20, 深圳, Ken Fang

在“微服务架构設計 (七): 微服务粒度设计上的核心设计原则与思考的面向” 的一文中, 探讨了从微服务外部的世界驱动微服务粒度的设计。如文中所描述, 为了保障微服务整体的性能与可靠度, 可能会设计出粒度较大的微服务, 而降低了微服务持续部署的速度。

然而, 架构师也不能光只看到微服务外部的世界, 而轻忽或完全忽略了微服务内部的世界。因为, 当架构师轻忽或完全忽略了微服务内部的世界时, 将可能会使得微服务的粒度过大, 而使得微服务内部世界的复杂度过高, 开发与测试人员了解微服务需求 (场景) 的难度增加, 微服务的缺陷率升高, 微服务修复缺陷的时间增长。最终, 不仅使得微服务持续部署的速度越来越慢, 同时微服务整体的交付与运维的质量也会降低。

架构师需仅记微服务 “外部的世界” 远比 “内部的世界” 要来得重要。但, 并不代表著架构师可轻忽或完全忽略了微服务内部的世界。

架构师如何能避免自身轻忽或完全忽略了微服务内部的世界？

业务驱动与团队协作将能使得架构师, 避免自身轻忽或完全忽略了微服务内部的世界; 使得架构师可在微服务外部的世界与内部的世界中, 取得一较好的平衡点与可落地的实施方案。

I.   业务驱动: 业务驱动指的是, 架构师将微服务需达到的业务目的, 纳入微服务粒度设计的考量。

以不同的业务目的为例子来说明:

II.      团对协作:

对于 Case A: 更快响应市场, 架构师设计了较小粒度的微服务。当然, 这样的设计, 就如在微服务架构設計 (七): 微服务粒度设计上的核心设计原则与思考的面向” 的一文中所提及的, 因微服务粒度小, 可能将使得微服务间的远程调用增加, 而使得整体微服务的性能降低。

此时, 架构师便必需与团队成员协作, 共同探讨出如何解决整体微服务性能降低的问题? 例如: 牺牲些水平扩展的能力; 将会产生互相调用的微服务,部署在同一节点上。

而对 Case B 与Case C, 就如同本文先前所提的: 微服务的粒度过大, 而使得微服务内部世界的复杂度过高, 开发与测试人员了解微服务需求 (场景) 的难度增加。

此时, 架构师、开发人员与测试人员便需经由轻量级, 可视化的工程实践 (注一) , 共同协作, 高效的完成微服务的分析、设计与测试用例的设计。以有效的提升开发与测试人员的效率与质量。

“微服务架构設計 (七): 微服务粒度设计上的核心设计原则与思考的面向” 与 “微服务架构設計 (八): 业务驱动与团队协作微服务粒度设计: 微服务内部的世界”, 分别从微服务外部的世界与微服务内部的世界, 探讨了设计微服务粒度; 边界上下文 (Bounded Context)。

总结这两篇文章, 所得出的: 设计微服务粒度; 边界上下文 (Bounded Context) 的原则:

A.      微服务 “外部的世界” 远比 “内部的世界” 重要。

B.      业务驱动; 在微服务外部的世界与内部的世界中, 取得一较好的平衡点。

C.      协作、协作、协作; 找到最适合市场, 产品与团队现况的微服务实施方案。

注一: 轻量级, 可视化的工程实践, 将在后续探讨: 微服务产品级敏捷时, 再来讨论。