我们目前有一个大型单体 J2EE 应用程序 (weblogic/DB2)。这是一个典型的OLTP应用。我们正在考虑将此应用程序拆分为 2 个应用程序，其中每个应用程序都有自己的数据库，其他应用程序无法直接访问该数据库。这也意味着每个应用程序都需要公开一个接口(interface)来实现其他应用程序所需的功能。
那么，将这样一个现有应用程序拆分为 2 个应用程序的潜在主要好处是什么？
最佳答案
大多数应用程序在 90% 的时间里使用 10% 的代码。
微服务的核心思想是现代SOA。您可以在微服务特定的特殊云中弹性扩展应用程序的关键部分。云是一个弹性集群，其中每个节点都是一个虚拟服务器(XEN或VMware等)。云可以根据负载因子自动扩展或收缩节点数量，无需人工关注。
对于经典的单体应用程序，您需要扩展整个单体应用程序。通常此类应用程序使用大量 RAM，并且需要强大的硬件或强大且昂贵的虚拟服务器。单体的另一个缺点 - 如果你需要发布一个新的业务功能，发布周期会非常长，因为你已经用代码熵对庞大而复杂的代码库进行了修改。这将需要昂贵的时间/预算回归测试。但您有一个好处 - 与 SOA 方法相比，不同的应用程序部分(子系统和模块)可以更容易地集成，如果您有良好的应用程序设计的话。
另一方面 - 您可以将应用程序逻辑拆分为一组小型应用程序，此类应用程序称为微服务。例如，您有一个仅负责 UI 的微服务 - 即仅带有 Angluar.js 的 Spring MVC，另一个负责业务逻辑和持久性的微服务，以及另一个用于从社交网络获取数据的微服务。所有这些服务都使用一些通常为 RestFull 的 Web 服务相互互连，但也可以是 SOAP 或 Google Protocol Buffers RPC 等。因此，现在您只能自动扩展 UI 微服务，这预计会提高性能关键，而不涉及业务逻辑和社交网络微服务。即使 UI 微服务很弱，您也可以更新它，因为仅 UI 测试并不像业务逻辑测试那么昂贵。但有一个缺点 - 集群结构变得更加复杂，并且需要更强大的团队来维护它(通常使用一些基于 Chef 或 Docker 的脚本进行自动化)。实现子系统集成也很困难，您需要更仔细地考虑您的系统设计。
所以，如果您有一个庞大且复杂的高负载系统(例如 Amazon.com、Ebay、Facebook 或 stackoverflow)。 SOA 方法使您有机会在基础设施和硬件上节省一些资金。但开发成本会更高。如果您的系统非常简单，即只有几个页面的网吧网站 - 首选整体方法。
关于java - 将大型单体应用程序拆分为 2 个应用程序有什么好处？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49302010/