因此，我开始阅读一些有关不同软件体系结构的内容，并且不可避免地遇到了微服务体系结构。但是，我想知道这些架构彼此之间的差异。在单方面的方法中，我会修改POM.XML以使用我的不同层，并将它们打包到一个应用程序中进行部署。我想说这甚至可能是建立简单应用程序的最常用方法。
现在，据我所了解的微服务，您将每个服务彼此分开，并使它们独立运行。对我来说，这意味着每个服务都是独立部署的（因此您基本上运行了一个tomcat文件，上面运行着很多.war文件。但是我想我忘了单协议的区别）应用。
我将尝试设置一个（非常常见的）示例：
您有一个前端（例如Angular）和一个Spring-Boot后端，它们通过REST-服务进行通信。现在，我使用POM.XML并执行以下步骤：
WAR文件结果，我得到了一个可以部署的WAR文件，但其中包含两个服务：后端和前端。但是，我将其称为“单一方法”。
现在，当我将Angular-应用程序包含到我的tomcat中并部署应用程序的WAR部分的Spring-Boot文件时（不集成前端）。这样，我将在同一服务器上运行两个已部署的服务，彼此交互，可以相互替换而无需替换。根据定义，我不会将其称为单方法（相同的代码，不同的部署），而是微服务架构，对吗？但是事实并非如此，因为我读过的每篇文章实际上都告诉我架构的相同优点和缺点，除了交换前端和后端的可能性外，我看不到任何区别（我在两种情况下都可以互换）首先需要重新部署整个应用程序。
答案 0 :(得分：1)
微服务只是一组指导方针，讨论如何设计应用程序，以使其可扩展，可管理并适应快速的开发速度。这不仅与如何部署应用程序有关。
这些年来，我们了解到，当您尝试将一个大型应用程序作为整体构建时，最初它可以助您一臂之力，整体中的不同模块彼此之间具有完全的可见性，并且可以按需访问，调整事物，即使应该影响一个模块的一项更改也可能会迁移到其他类中，而本来应该没有。虽然它可以帮助您原型化，但是代码变得越来越难以维护。您当然可以尽力确保您的代码保持干净，但是随着应用程序的增加，这种努力也随之增加。
作为开发人员，您也必须了解整个产品，并且很难在孤岛上工作，而不必担心整个体系结构，这使新人很难加入并进行更改。
接下来，当您进行部署时，尤其是今天，规模很重要，并且需要适应流量。您所有的模块都不会期望24/7的高流量。但是，如果您拥有整体，则即使100个用户使用一个模块，您的应用程序也必须扩展为100个用户。
微服务只是从中获取信息，并定义一些准则
您应基于biz域对应用进行细分。每项服务仅负责一个方面。他们通过合同（API或事件）与其他人对话，只要合同有效，您就可以在服务中做您想做的事情。新开发者只需学习一项服务即可。
扩展变得很容易，因为如果您在一项服务上负载，则只能进行扩展。单独部署的其他模块可以根据特定于它们的负载进行扩展。
通过减小体积，您可以快速构建并快速进行更改。没有共享数据库可确保您要调用要保存的内容，要保存的方式以及要更改的方式。
对于您而言，只需以自己认为最佳的方式进行部署即可。但是，如果您开始成长，就会有大约50种零碎服务（或规模如此之大的项目），您将看到分而治之的好处。
答案 1 :(得分：0)
从后端拆分前端不是微服务部署的最佳/规范示例；这相当于在单块中具有层。关于如何将（子）域的整体拆分为模块的事情更好，每个模块都有前端和后端的职责；然后每个模块都可以成为微服务（如果需要）。
基于Web的应用程序的规范MS体系结构是一个网关，该网关汇集（并行！）来自不同MS的HTML响应。因此，单个MS将使用HTML，CSS和JS而不是JSON或其他不完整形式的数据进行响应。这是适用于MS的Tell Don't Ask原则。这为您提供了真正的质谱仪，您可以在其中轻松地将一个质谱仪替换为另一个质谱仪。
如果网关由于彼此依赖而无法并行组合各个响应，则拆分是错误的，您需要重构。
模块化整体与微服务之间最大的显着差异是微服务在单独的流程中运行。
如果使用位置transparency创建整体，则可以将组件部署为微服务而无需接触其他组件的代码。例如，如果您使用CQRS，则只需在代码上使用剪切/粘贴（从整体到微服务）就可以将Readmodel部署为微服务。