8、微服务架构设计与实现指南

微服务架构设计与实现指南

1. 微服务架构设计

1.1 确定微服务候选者

考虑到相关概念，许可证属于拥有多个资产的组织。基于与客户的交流和数据模型，确定了四个微服务候选者：组织（Organization）、许可证（License）、合同（Contract）和资产（Assets）。

1.2 建立服务粒度

拥有简化的数据模型后，就可以开始定义应用程序所需的微服务。潜在的微服务基于以下元素：
- 资产（Assets）
- 许可证（License）
- 合同（Contract）
- 组织（Organization）

目标是将这些主要功能提取为完全独立的单元，可相互独立构建和部署。这些单元可以共享或拥有各自的数据库。从数据模型中提取服务，不仅要将代码重新打包到单独的项目中，还要梳理出服务将访问的实际数据库表，并仅允许每个服务访问其特定领域内的表。

在将问题域分解为离散部分后，通常会难以确定服务的粒度是否合适。太粗粒度或太细粒度的微服务会有一些明显特征：
| 粒度情况 | 特征 |
| ---- | ---- |
| 太粗粒度 | 1. 服务职责过多，业务逻辑复杂，规则多样。
2. 管理大量表的数据，通常建议一个微服务管理不超过三到五张表。
3. 测试用例过多。 |
| 太细粒度 | 1. 问题域的一部分中微服务数量激增，完成一项工作所需的服务数量大幅增加。
2. 微服务之间高度相互依赖，为完成单个用户请求而频繁相互调用。
3. 微服务仅执行简单的 CRUD 操作，缺乏业务逻辑。 |

微