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)。而使微服持续部署的速度, 获得绝对的提升; 但, 绝对不是现在….