微服务架构 (七): 微服务粒度设计上的核心设计原则与思考的面向

2016.8.19, 深圳, Ken Fang

架构师在设计微服务时, 需把握一个核心的设计原则:

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

微服务外部与内部的世界是以微服务边界上下文 (Bounded Context) 作划分的。而微服务的接口; 例如: REST 接口; 便是拉通了微服务外部与内部的世界。

微服务外部的世界包括:

A.       微服务外部的 Client; 微服务外部的使用者 (介面), 系统, 设备。

B.       微服务之间外部的数据交易 (Transaction)。

C.       微服务之间外部的远程调用; 在网络上所传递的信息。

微服务内部的世界包括:

A.       微服务内部需处理、运算的业务场景或功能。

B.       微服务内部所需拥有的资源; 例如: 库 (Library), 数据库, 应用伺服器, 网络IP 地址, 网络 Port, 操作系统等等。

架构师设计微服务的粒度; 边界上下文 (Bounded Context); 时, 便需仅记微服务 “外部的世界” 远比 “内部的世界” 要来得重要。也就是说, 架构师应从微服务 “外部的世界” 来界定微服务的粒度; 微服务的边界上下文 (Bounded Context)。

架构师设计微服务的粒度; 边界上下文 (Bounded Context); 时的主要思考的面向便是:

A.       先从微服务外部的 Client, 分析、识别微服务的主要目的、主要需处理、运算的业务场景或功能为何? 而形成微服务的 Pre-Bounded Context。

B.       各微服务的 Pre-Bounded Context 识别后, 便可得知微服务之间外部的数据交易 (Transaction) 是否会因为开发上技术难度的增大, 而对于整体产品架构的可靠性; 例如: 数据的一致性; 产生负面的影响?

假如, 所设计出的微服务的 Pre-Bounded Context 会因为开发上技术难度的增大, 而对于整体产品架构的可靠性; 例如: 数据的一致性; 产生负面的影响, 则架构师便应重新的思考: 将会因微服务之间外部的数据交易 (Transaction) , 而会对整体产品架构的可靠性, 产生负面影响的数个微服务, “合并” 为一个微服务。

C.       各微服务的 Pre-Bounded Context 识别后, 便可得知是否会因为过多的微服务之间外部的远程调用, 所形成的大量网络的延迟, 而使整体产品架构的性能, 产生负面的影响？

假如, 所设计出的微服务的 Pre-Bounded Context 会形成大量网络的延迟, 而使整体产品架构的性能, 产生负面的影响, 则架构师便应重新的思考: 将会因微服务之间外部的远程调用, 而会对整体产品架构的性能, 产生负面影响的数个微服务, “合并” 为一个微服务。

以微服务 “外部的世界” 远比 “内部的世界” 重要的思维的模式, 主要是将整体微服务 (产品) 的可靠性、性能的重要性要高于整体微服务 (产品) 持续部署的速度。

这样的思维最主要的目的便是: 微服务外部的世界, 仍旧是十分的脆弱与不可预期的; 例如:网络的中断、网络的安全性 (犯罪)、网络的延迟等等; 所以, 架构师应从微服务 “外部的世界” 界定微服务的粒度; 微服务的边界上下文 (Bounded Context)。

当然, 假如有一天, 微服务外部的世界已是十分的强壮, 则架构师便可从微服务 “内部的世界” 来界定微服务的粒度; 微服务的边界上下文 (Bounded Context)。而使微服持续部署的速度, 获得绝对的提升; 但, 绝对不是现在….