毫无疑问，微服务是软件开发界的热门话题。每家组织都在试图分解其应用程序/产品，转变成微服务，以便它们可以以基于微服务的架构这一名义出售产品。然而，它们果真在构建真正的微服务吗?还是说它们对整个微服务架构缺乏了解，只是在构建可以称之为“迷你服务”的另一组服务以满足业务要求?
本文试图区分微服务、迷你服务和宏(整体式)服务。
微服务
只有在以下情况下，才可以将您的服务称为微服务：
- 独立开发、部署和管理，无需对周围的服务有任何了解。
- 通过发布-订阅模式彼此联系。
- 具有单一责任。
- 松散耦合。
图1. 微服务架构
因此，如果您的服务未遵循这些原则中的任何一项，它就不是微服务，您接触的可能是迷你服务，稍后会进行解释。如果服务满足以下条件，它们也不是微服务：
- 共享数据库(物理或逻辑)。
- 以同步方式彼此联系(使用REST的服务到服务调用)。
- 共享基础架构。
- 进一步了解周围发生的一切以便进行交流。
然而在开发过程中，不是所有的开发人员都了解发布-订阅模式或对功能缺乏了解，因此他们犯以下错误：
- 不了解发布-订阅或消息队列集成模式，因此他们迅速切换到REST API，以便服务能进行联系。
- 不了解完整的业务，因此混淆功能，忘记微服务的SRP。
- 不为每个服务物理隔离数据库，而是在同一个数据库和与该同一个数据库进行交互的许多微服务中创建模式(Schema)。
迷你服务
那么什么是迷你服务呢?它好比以一种模式聚起起来的一组微服务，旨在解决业务需求。它是单一的功能即服务。
在以下情况下，可以将您的服务称为迷你服务：
- 如果多个应用程序共享同一个数据库。
- 服务通过REST API相互联系，并不积极采用基于事件的架构用于异步通信。
- 共享基础架构以进行部署。
图2. 迷你服务的架构
现在，如果您服务域的所有服务共享一个数据库和应用程序服务器，并通过直接调用来调用每个服务，因为它们都部署在同一个JVM中，那么您的应用程序就是整体式(宏服务)。
宏服务(整体式)
它只是个整体式程序，其中所有业务服务都作为单个程序包部署在应用程序服务器中，并共享同一个数据库(物理上和逻辑上)。它不太复杂，服务之间奉行紧密耦合。
图3. 整体式架构
何时使用什么哪种服务?
这完全取决于您的业务要求或项目需求。您在多个代码存储库中拥有功能时，创建微服务很有意义。另一方面，如果您在单个代码存储库中有多种功能，或者一个服务有多种功能，那么迷你服务是解决方案。
复杂性增加时，您又不需要与其他服务进行联系，那么可以考虑编写迷你服务。如果您在项目中有独立的功能，它们之间需要异步通信，那么请编写微服务。
迷你服务具有成本效益，而微服务的成本效益较低，因为我们必须实时部署多种功能才能实现业务目标。
结束语
团队和开发人员正在尽其所能地分散应用程序，但编写的微服务可能不如您想象的那么多。许多人仍在编写微服务和迷你服务的组合版。
原文标题：Microservice, Miniservice, and Macroservice，作者：Nitesh Gupta
