将大型单片应用程序拆分为2个应用程序有什么好处？

Question

我们目前拥有一个庞大的整体J2EE应用程序（weblogic / DB2）。它是典型的OLTP应用程序。我们正在考虑将此应用程序拆分为2个应用程序，其中每个应用程序都有自己的数据库，而其他应用程序无法直接访问。这也意味着每个应用程序都需要公开其他应用程序所需功能的接口。

那么将这样的现有应用程序拆分为2个应用程序的主要好处是什么呢？

Answer 1

大多数应用程序在90％的时间内使用10％的代码。

微服务的核心思想是现代SOA。您可以在特定于微服务的特殊云中弹性扩展应用程序的关键部分。云是一个弹性集群，其中每个节点都是虚拟服务器（XEN或VMware等）。云可以根据负载因子自动扩展或缩减节点数，而无需人工关注。

使用经典的单片应用程序，您需要扩展整个单片应用程序。通常这样的应用程序使用大量的RAM，以及需要强大的硬件或强大而昂贵的虚拟服务器。单片的另一个缺点 - 如果您需要发布新的业务功能，发布周期将非常长，因为您已经使用代码熵对庞大而复杂的代码库进行了修改。这将需要时间/预算昂贵的回归测试。但是你有一个好处 - 如果你有很好的应用程序设计，那么与SOA方法相比，可以更容易地集成不同的应用程序部分（子系统和模块）。

另一方面 - 您可以将应用程序逻辑拆分为一组小型应用程序，例如称为微服务的应用程序。例如，您只有一个微服务负责UI - 即只有带有Angluar.js的Spring MVC，另一个用于业务逻辑和持久性的微服务，以及一个用于从社交网络获取数据的微服务。所有这些服务都使用一些Web服务（通常是RestFull）互相连接，但可以是SOAP或类似Google Protocol Buffers RPC等。所以现在你只能自动扩展UI微服务，这应该是性能关键，不涉及业务逻辑和社交网络微服务。而且，即使只是弱点，您也可以更新UI微服务，因为仅UI测试不像业务逻辑测试那么昂贵。但是存在一个缺点 - 集群结构变得更加复杂，并且需要更强大的团队来维护它（通常使用一些基于Chef或Docker的脚本自动化）。实现子系统集成也很难，您需要更仔细地考虑系统设计。

所以，如果你有一个庞大而复杂的高负载系统（如Amazon.com，Ebay，Facebook或stackoverflow）。 SOA方法为您提供了在基础架构和硬件上节省一些资金的机会。但它的开发成本会更高。如果你的系统非常简单，即有几页的网吧网站 - 首选单片方法。

Answer 2

如果您的关注度不是可扩展性，那么我将指出以下好处：

• 提高更改速度 - 功能从构思阶段进入生产的时间更短（开发人员的复杂性更低）
• 降低测试成本（较小的测试范围）
• 提高质量（同样，更小的测试范围）

Answer 3

如果不了解应用程序的全部内容，业务规则是什么，如何划分应用程序以及两个应用程序如何共享业务规则，我们无法权衡利弊。 将应用程序划分为两个应用程序不仅仅是将Java类分成两组。它需要从不同角度进行深度分析。希望这会有所帮助。