我们目前拥有一个庞大的整体J2EE应用程序(weblogic / DB2)。它是典型的OLTP应用程序。我们正在考虑将此应用程序拆分为2个应用程序,其中每个应用程序都有自己的数据库,而其他应用程序无法直接访问。这也意味着每个应用程序都需要公开其他应用程序所需功能的接口。
那么将这样的现有应用程序拆分为2个应用程序的主要好处是什么呢?
答案 0 :(得分: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方法为您提供了在基础架构和硬件上节省一些资金的机会。但它的开发成本会更高。如果你的系统非常简单,即有几页的网吧网站 - 首选单片方法。
答案 1 :(得分:1)
如果您的关注度不是可扩展性,那么我将指出以下好处:
答案 2 :(得分:0)
如果不了解应用程序的全部内容,业务规则是什么,如何划分应用程序以及两个应用程序如何共享业务规则,我们无法权衡利弊。 将应用程序划分为两个应用程序不仅仅是将Java类分成两组。它需要从不同角度进行深度分析。希望这会有所帮助。