【.com快译】毫无疑问，微服务是软件开发界的热门话题。每个组织都在尝试将他们的应用程序/产品分解为微服务，以便他们可以以基于微服务的架构的名义销售他们的产品。然而，他们真的在构建真正的微服务吗？还是对整体微服务架构缺乏了解，只是另建一套可以称为“小服务”的服务来满足业务需求？本文试图区分微服务、迷你服务和宏（单体）服务。微服务只有在以下情况下，您才能将服务称为微服务：在不了解周围服务的情况下独立开发、部署和管理。通过发布-订阅模式相互通信。有单一的责任。松耦合。图1.微服务架构因此，如果您的服务不遵循这些原则中的任何一条，那么它就不是微服务，您可能接触的是迷你服务，稍后将对此进行解释。服务也不是微服务，如果它们：共享数据库（物理或逻辑）。以同步方式相互联系（使用REST的服务到服务调用）。共享基础设施。详细了解您周围发生的事情以进行交流。但在开发过程中，并非所有开发人员都了解发布订阅模式或对功能缺乏了解，因此会犯以下错误：不了解发布订阅或消息队列集成模式，因此迅速转向RESTAPI使服务可以联系。不了解完整的业务，所以混淆了功能并忘记了微服务的SRP。模式不是在物理上隔离每个服务的数据库，而是在同一个数据库和许多与同一个数据库交互的微服务中创建。迷你服务那么什么是迷你服务呢？它就像一组以某种模式组装起来的微服务来解决业务需求。它是作为服务的单一功能。在以下情况下，您可以将您的服务称为迷你服务：如果多个应用程序共享同一个数据库。服务通过RESTAPI相互通信，并不主动采用基于事件的架构进行异步通信。共享部署基础设施。图2.迷你服务的架构现在，如果您的服务域中的所有服务共享一个数据库和应用程序服务器，并且您通过直接调用来调用每个服务，因为它们都部署在同一个JVM中，那么您的应用程序是单体应用程序（宏服务）。MacroServices(Monolithic)它只是一个单体程序，其中所有业务服务都作为单个包部署在应用程序服务器中，并共享同一个数据库（物理上和逻辑上）。它不太复杂，服务紧密耦合。图3.何时为单体架构使用哪种服务？这完全取决于您的业务需求或项目需求。当您在多个代码存储库中拥有功能时，创建微服务才有意义。另一方面，如果您在单个代码存储库中有多个功能，或者在一个服务中有多个功能，那么迷你服务就是解决方案。随着复杂性的增加，并且您不需要与其他服务进行通信，请考虑编写迷你服务。如果你的项目中有独立的功能，需要它们之间异步通信，那就写微服务吧。迷你服务是划算的，而微服务是划算的，因为我们必须实时部署多个功能来实现业务目标。结论团队和开发人员正在尽最大努力去中心化应用程序，但编写的微服务可能没有您想象的那么多。许多人仍在编写微服务和迷你服务的组合。原标题：Microservice,Miniservice,andMacroservice，作者：NiteshGupta
