将一个大的整体应用程序拆分为两个应用程序有什么好处？

Question

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

那么，将这样一个现有应用程序分为2个应用程序的潜在主要好处是什么？

Answer 1

大多数应用程序在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方法使您有机会在基础架构和硬件上节省一些钱。 但是它的开发成本会更高。 如果您的系统非常简单，即网吧站点只有几页，则首选整体方法。

Answer 2

如果您不关心可伸缩性，那么我将指出以下好处：

• 增加的变更速度-缩短功能从构思阶段到生产的时间（降低开发人员的复杂性）
• 较低的测试成本（较小的测试范围）
• 质量提高（再次，更小的测试范围）

Answer 3

我们无法权衡利弊，而不必查看该应用程序的全部内容，什么是业务规则，如何划分应用程序以及两个应用程序如何共享业务规则。 将一个应用程序分为两个应用程序不只是将Java类分为两个组。 它需要从不同角度进行深度分析。 希望这可以帮助。