微服务架构设计 第四步: 分析微服务架构依赖与风险; 开发微服务最关键的一步

2016.9.11, 深圳, Ken Fang

当特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员协作, 而可针对特性下的所有微服务 (functional services), 都可分析出大家都一致认可的边界上下文 (Bounded Context) 与架构设计方案时, 特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员应再持续的协作, 根据由分析与设计微服务边界上下文 (Bounded Context) 与架构设计方案时, 所获得的知识, 继续分析出特性下的所有微服务 (functional services) 在架构上的依赖。

这些架构上的依赖, 包括:

1. 微服务 (functional services) 依赖产品外部的哪些产品? 设备?

2. 微服务 (functional services) 依赖外部这些产品或设备的哪些接口? 端口? 数据库?

3. 微服务 (functional services) 依赖自身产品内部的哪些子系统?

4. 微服务 (functional services) 依赖自身产品内部的这些子系统的哪些接口? 数据库?

当特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员分析出特性下的所有微服务 (functional services) 在架构上的依赖后, 特性负责人便以特性上下文地图, 去承载这些微服务在架构上的依赖。

特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员便可根据特性上下文地图中, 所体现出的各微服务 (functional services) 在架构上的依赖, 而识别出哪些依赖会存在著风险, 而使微服务 (functional services) 无法进行集成测试, 或者哪些依赖所造成的风险, 会使微服务 (functional services) 无法进行独立发布、独立部署?

特性负责人必需与架构师, 开发骨干人员, 测试经理, 资深测试人员协作, 认真的分析因架构上的依赖, 对微服务 (functional services) 在执行集成测试或独立发布、独立部署上, 所可能带来的风险为何? 并深度的思考, 应该有怎样的 A 计划? B 计划? 才能消除或降低因为架构上的依赖, 所导致的风险; 这一步真的很关键, 往往会决定微服务开发的成功或失败....