微服务架构设计 第三步: 微服务的架构方案

2016.9.10, 深圳, Ken Fang

当特性负责人, 与团队中各不同领域的成员; 架构师, 开发骨干人员, 测试经理, 资深测试人员; 共同的协作, 针对每个 functional services, 反覆的推敲、分析, 直到获得大家都认可的, functional services 这类微服务的边界上下文 (Bounded Context) 后, 特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员应该就会对下列的微服务的信息有所理解与掌握:

1. 特性下的每个 functional services 的业务场景切片。

2. 每个 functional services 间的调用关系。

3. 每个 functional services 间的数据一致性的要求。

4. 每个 functional services 间共享的诉求。

5. 外部的使用者或外部的产品, 对每个 functional services 所提供的信息, 在时延上的限制或要求。

6. 外部的使用者或外部的产品, 对每个 functional services 发生故障时, 其响应 (通知) 故障速度上的要求。

7. 每个 functional services 与第三方软件整合或将既有系统搬迁到微服务架构上的策略。

8. 每个 functional services 对外信息交换的格式。

当特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员对上述的微服务的信息有所理解与掌握后, 特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员, 便应该再度的协作, 针对特性下的每个 functional services, 从附图中选出适当的微服务架构设计方案。

SaveSave