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

微服务粒度适应度函数

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

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

但是，事实上从国内大中小公司的实践情况来看，并非如此。往往是一个团队维护了超过其自身数量的微服务，即 6 个开发人员可能维护了 8 个微服务。大家常犯的一个错误是：通过技术维度而非业务维度划分微服务。关于这部分的自动化，我暂时找不到头绪。但是，我们可以判断两个微服务是否可以合并：即基于 Git 日志的微服务粒度合理性分析。

• 服务提交人数。通过 git log 来查看单个微服务的提交情况
• 变更频率。寻找多个模块之间，是否存在大量同时变更的情况
• 需求关联度。通过识别提交信息规范，来识别多个微服务、模块、类是否存在经常同时变更
  • 前提：匹配提交规范。

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

API 的适应度函数

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

• API 命名的规范。如不一致的命名方式
• 参数合理性。如过多或者过少、是否不应该出现在 URL 中。
• 是否符合 RESTful 规范。如 URL 中不应该出现 get 和 post 等字眼，是否所有的 API 都是 post。
• 是否出现跨服务使用相同的资源前缀。

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