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