自动化微服务治理

关于『设计一个微服务治理的工具』这个想法，我已经酝酿很久了。但是，你懂的，又是因为种种原因，我搁置了蛮久了。最近，刚好因为在研究『架构适应度函数』，所以，我有了一个新的想法。微服务架构治理，看似和架构适应度函数并没有啥关系。但是，我设想的是一个用于『微服务治理的架构适应度函数』。

你可以把它想象为一个用于帮助更好开发微服务应用的工具。顺便一提，因为手头上并没有这样的场景。所以，我先把我的相关思路记载下来，方便于后续集成。而且大部分功能已经在 Coca 中实现，我会将部分的功能再交由 Coca 来实现。如对于，数据库的自动化分析 —— 已经有 Tequila 进行了大量的自动化。

微服务粒度适应度函数

对于微服务架构来说，最令人头疼的一个问题就是微服务粒度。从最源头上，我们应该遵循『两个披萨团队』这个定律，即：

单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要 2 个披萨就够了。

但是，事实上从国内大中小公司的实践情况来看，并非如此。往往是一个团队维护了超过其自身数量的微服务，即 6 个开发人员可能维护了 8 个微服务。

大家常犯的一个错误是：通过技术维度而非业务维度划分微服务。关于这部分的自动化，我暂时找不到头绪。但是，我们可以判断两个微服务是否可以合并：即基于 Git 日志的微服务粒度合理性分析。

• 服务提交人数。通过 git log 来查看单个微服务的提交情况

• 变更频率。寻找多个模块之间，是否存在大量同时变更的情况

• 需求关联度。通过识别提交信息规范，来识别多个微服务、模块、类是否存在经常同时变更

• 前提：匹配提交规范。

在这个时候，我们只需要使用和 coca git 类似的解析函数，就能达到类似的效果。

API 的适应度函数

在 Coca 中已经内置了 API 分析相关的功能，可以支持识别 Spring 的 API 注解，以及服务声明的 API 方式，同时分析调用关系等等。所以，我就不需要开发一个这样的功能了，只需要稍微完善一下，补充一些分值情况。

对于 API 设计来说，这个工具要做这么几件事：

1. API 命名的规范。如不一致的命名方式

2. 参数合理性。如过多或者过少、是否不应该出现在 URL 中。

3. 是否符合 RESTful 规范。如 URL 中不应该出现 get 和 post 等字眼，是否所有的 API 都是 post。

4. 是否出现跨服务使用相同的资源前缀。

对于大部分的公司来说，要做到 RESTful 的第一级都相当的困难。

数据库表适应度函数

微服务把服务间调用从函数调用变成了远程调用，这也意味着，我们并不能从 A 服务直接访问 B 服务的数据库，而是通过访问 B 服务的接口，借助它去访问数据库。但是，在某些场景下，A 和 B 是需要共用数据库（比如说，收费的 Oracle 数据库实例），但是我们需要强制性的限制 A 和 B 服务对于表的访问。

所以，我们需要分析多个服务之间是否存在对于同一个表的修改，又或者是存在对于多个表的修改。

1. 表和服务关系维护。扫描 MyBatis 等这一类的工具，生成表和服务关系维护

2. 实现『数据库表-映射服务』的快照测试。

简单来说，我们的工具在这一部分所要做的事情是：每次代码提交时，进行自动化地扫描，生成一个快照。刚其与存储的快照进行对比，判断数据库是否有问题。随后设置一个合理的调优公式，也就是这部分的架构适应度函数。

分层架构适应度函数

在解决了表面的问题之后，我们可以尝试达到整洁架构这一目的。对于分层架构来说，我们要做的事情可能会稍微复杂一下。不过，好在复杂的调用关系识别，已经由 Coca 实现了。

于是乎，对于我们的分层架构适应度函数，只需要做到这么一些事情：

1. 微服务之间是否存在函数调用？

2. 单个服务的所有 API 是否在同一个包内，如 controller。

3. 是否存在不合理的 common、util 模块。

4. 对于三层包架构迁移到整洁架构的改进可视化。

简单来说，就是将《系统重构与迁移指南》一书中记载的部分，通过自动化的方式进行识别。

数据结构适应度函数

关于数据结构/数据模型，已经有一些工具可以做类似的事情。对于微服务架构来说，我们所要做的一些判断是：

• 不合理的耦合。如果一个结构体/类同时被大量的其它类调用，必然有一定的不合理之处。

• 过大的模型。值得注意的是，在一些大数据的场景下，这个反而是正确的

• 过于复杂的嵌套。

• 没有行为的模型。

然后，针对于一些不同的使用情况，还存在一些不一样的识别模式。

模型分析

在某些特定的场景之下，团队会将共用的模型抽取到公共的模块中，提供给多个微服务使用。这种模式本身可能是有问题的，因为在不同的限界上下文里，它些模型本身不应该是一致的。

相似度分析

考虑到复用和耦合之间的关系，这里不会建议它们共用的。不同服务之间需要一定的 copy/paste，但是需要考虑更好的方式，如采用类似于 proto 这样的 DSL 生成方式。同时，通过 DDD 的方式进行管理 —— 针对于不同的相似类型，有更好的命名方式。

其它细节

我们还要做好一些基础设施，比如对于模块的处理：

• 模块标志

• build.xml

• gradle

• pom.xml

• bazel

• 模块归属权

• 需求关联

• 提交信息识别（可输入式正则关系，配置化）

• 记录包-需求-服务关系

• 聚类分析

• ……

嗯，这些都不是容易的事。

结论

你的微服务架构适应度函数呢？