2.5 微服务的设计

在微服务架构应用的设计和实现中，如果要找出最重要的一个任务，那必定是微服务划分。微服务架构的核心是多个互相协作的微服务组成的分布式系统。只有在完成微服务的划分之后，才能明确每个微服务的职责，以及确定微服务之间的交互方式。然后再进行每个微服务的API设计，最后才是每个微服务具体的实现、测试和部署。

在微服务实现的过程中，如果发现之前对微服务的划分有不合理的地方，导致有些功能需要被迁移到其他微服务，那么相关微服务的API和实现都需要进行修改。这会对开发进度造成重大影响。

微服务划分的好坏直接影响整个应用的可维护性。如果划分的微服务的粒度过大，随着微服务的发展，它们的复杂度可能等同于传统的单体应用；如果划分的微服务的粒度过小，数量过多的微服务不但增大了运维的成本，也会影响系统性能，增加开发的复杂度。

在划分微服务时可以采用不同的策略。最简单的策略是从自身积累的经验出发，按照对应用的理解来进行划分。设计微服务的前提之一是对需要解决问题的领域有足够的了解。只有满足这个前提下，才能正确地划分微服务。如果读者和读者的团队面对的是一个全新领域中的项目开发，并没有相关的经验，那么不建议一开始就使用微服务架构。由于不熟悉相关的领域，一开始的微服务划分很可能并不合适，导致功能在不同的微服务之间迁移，还可能需要重新切分与合并微服务。所有这些对微服务的修改，都会产生不必要的时间开销，影响开发的进度。

对于初创企业或是新的项目来说，也不建议一开始就采用微服务架构。这些项目都要求尽快地上线。如果采用微服务架构，会花费大量的时间来处理微服务架构所带来的复杂度，影响项目的开发进度。

当开始新的项目时，最好的选择是从单体应用开始。当单体应用的复杂度增加到某个程度时，再考虑迁移到微服务架构。在这个时候，开发团队已经累积了足够多的经验，并对领域有了足够的了解。只需要从已有的单体应用开始，把其中的组件转换成微服务即可。在迁移的过中，原有的单体应用可以继续运行，以确保服务不中断。

这也是推荐的使用微服务架构的方式。微服务架构并不是软件开发中的“银弹”或是万灵药，盲目使用微服务架构很可能造成项目的失败。在社区中已经有过很多这样的例子。以开源的服务网格实现Istio为例，早期的Istio由多个微服务组成，造成了部署和运维的困难。在后来的版本更新中，Istio把这些微服务整合成了单个可执行文件，大大简化了部署和运维的工作量。

[1] 本书内容基于Quarkus的2.0版本。与1.13版本相比Quarkus 2.0的最大改动是升级到了Vert.x 4和MicroPro-file 4，属于底层库的升级。本书的绝大部分内容对于1.13版本也是适用的。