17、微服务的分解与基于指标的评估框架

微服务的分解与基于指标的评估框架

1. 架构目标

微服务应尽可能实现高内聚和低耦合，这样做的目的是将维护工作尽可能局限在局部。也就是说，对源代码的修改应仅影响一个微服务。这种松耦合的架构还支持微服务的独立开发和部署。

内聚性与耦合性相关，它衡量某个类的元素之间的关联程度，也衡量不同模块功能之间的关联强弱。通常，高内聚意味着低耦合。如果软件组件具有高内聚性，系统的推理会更容易，进而支持系统的高效开发和维护。

在设计基于微服务的系统时，开发人员通过根据业务流程对功能和组件进行分组，来实现高内聚和低耦合。这样，对某个功能的更改应仅导致一个微服务的变化。

由于内聚性和耦合性是微服务的关键特性，因此在分解过程中需要依赖信息。常用的依赖分析工具（如 Structure 101）基于静态依赖分析，它们无法确定哪些组件间调用实际发生，也无法识别完整的调用路径。我们的方法使用过程挖掘提供的动态依赖信息，挖掘过程会给出建议，分析结果可用于推理。目前，我们并不追求完全自动化的分解。

2. 分解框架假设

我们的方法核心假设是存在在运行时收集的扩展日志跟踪。这意味着任何外部触发后的整个操作链都可以从日志文件中追溯。外部事件包括用户操作（如点击按钮）和其他应用程序的调用（如 API 或命令行）。

日志文件必须包含处理请求时涉及的所有方法和类的信息，完整的执行路径必须从入口点到数据库访问（如果有）以及返回给客户端的结果都能完全追溯，日志还必须包含开始和结束事件。以下是日志文件中数据的一个假设示例：
| 开始时间 | 结束时间 | 会话 ID | 类 | 方法 |
| — | — | — | — | — |