微服务架构设计 第二步: 分析微服务的边界上下文 (Bounded Context)

2016.9.10, 深圳, Ken Fang

当特性负责人, 将特性的所有业务活动均分析出, 其各自的基本流, 扩展流与异常流之后, 特性负责人便可经由组合基本流, 扩展流与异常流, 而分析出从外部使用者或外部产品的视角, 有价值的端到端的业务场景切片后, 特性负责人便可将各业务场景切片中, 共同的场景提取出, 成为所谓的 infrastructure services。

也就是说:

A. 对外部的使用者或外部的产品而言, 有价值的端到端的业务场景切片, 便构成了所谓的 functional services; 可供外部使用者或外部产品经由 api layer 来调用。

B. 各 functional services 中所存在的共同场景, 便构成了所谓的 infrastructure services; 只供 functional services 调用, 外部使用者或外部产品是无法经由 api layer 来调用的。  

现在的问题是:

经由基本流, 扩展流与异常流的组合, 所构成的业务场景切片, 是否就能形成 functional services 这类微服务的最佳边界上下文 (Bounded Context) ?

要能回答这个问题, 需先思考下面的六个问题:

1. functional services 边界上下文 (Bounded Context) 内的业务场景切片是否过于庞大与复杂? 而使开发人员与测试人员不易理解?

2. functional services 边界上下文 (Bounded Context) 内的业务场景切片是否过于庞大与复杂? 而使得在版本开发中, 会产生过多的变更或缺陷, 而使得版本升级的速度与质量因此而下降?

3.  functional services 边界上下文 (BoundedContext) 内的业务场景切片是否过于庞大与复杂? 而使得在版本开发中, 此 functional services 已无法由单一的团队所完成?

4.  functional services 边界上下文 (BoundedContext) 内的业务场景切片, 实际是否仅是能完成某业务活动中的某个功能点? 因而, 使得此 functional services 需要远程调用其他多个的 functional services, 才能完成某业务活动中的某个业务切片; 别忘了, functional services 之间的远程调用, 往往可能会引入性能、可靠性、甚至是安全性等的问题。

5.  functional services 边界上下文 (BoundedContext) 内所包含的数据库是否需与过多; 举例: 超过 7 个; 其他的 functional services 发生数据一致性的问题; 别忘了, 在分布式微服务的架构下, 微服务间的数据是一定会延迟的, 所以,假如, 某个 functional services 边界上下文 (Bounded Context) 内所包含的数据库, 是需要与过多其他的 functional services 维持数据的一致性时, 则将会因过长的数据延迟, 而使得使用者的体验不佳。当然, 要维持众多 functional services 间的数据一致性, 在开发上也不是件容易的事。

6.  是否会因过多的 functional services , 而使得在自动化配置、测试与自动化部署的难度与风险增加?

所以, 当特性负责人, 经由基本流, 扩展流与异常流的组合, 所构成的业务场景切片, 而形成 functional services 这类微服务的边界上下文 (Bounded Context) 后, 便需与团队中各不同领域的成员; 架构师, 开发骨干人员, 测试经理, 资深测试人员; 再共同的协作, 针对每个 functional services, 反覆的推敲、分析、回答上述的六个问题, 直到获得大家都认可的, functional services 这类微服务的边界上下文 (Bounded Context) 为止。