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