monolith_将Java EE Monolith雕刻成微服务

monolith

在介绍了为什么微服务应该由事件驱动的简介博客之后，我想采取一些其他步骤，并在有关博客的同时准备我即将进行的一系列演讲（在jBCNconf和Red Hat Summit上与您见面）。旧金山）。在Twitter @christianposta上关注我，了解该项目的更新。在本文中，我们讨论了雕刻整体的第一部分。

我将在这些文章中深入探讨的整体内容来自Ticket Monster教程，该教程长期以来一直是如何使用Java EE和Red Hat技术构建出色应用程序的典型示例。我们之所以使用Ticket Monster，是因为它是一款写得很好的应用程序，可以很好地跨越“非平凡的”和“示例过于复杂”的界限。出于说明目的，它是完美的，我们可以具体指出它，并使用真实的示例代码讨论某些方法的利弊。请根据进一步的讨论仔细研究领域和当前架构。

看看上面的当前架构，我们可以发现事情已经很好地解决了。我们具有UI组件，业务服务和长期持久性存储，它们之间很好地分离和解耦，但打包为单个可部署文件（在这种情况下为WAR文件）。如果我们检查源代码，就会发现代码具有类似的结构。如果我们要部署它，则对任何组件的任何更改都将要求构建，测试和发布整个可部署组件。进行微服务的先决条件之一是组件的自治性 ，因此可以在不中断系统其余部分的情况下隔离地开发，测试和部署它们。那么，如果我们仅在此处划分不同的层并独立部署，该怎么办？那么我们可以实现某些自主权吗？

过去，我们已经花了很多时间争论这种类型的体系结构，这似乎是有道理的。我们希望能够根据其需求扩展各个组件。如果我们需要处理更多的Web请求，请扩展Web层。如果这些服务开始成为瓶颈，则可以扩展业务服务层。与其余应用程序/服务无关地处理和管理数据库以及数据访问层。将UI逻辑与中间层和数据访问“分离”是一个很好的指导原则，但不要将其与需要的层混淆。

实际上 ，实际发生的是，所有这些“分层的”架构组件，由于其所有关注点分离等，都非常容易屈服于数据和数据库的异想天开。我们可以添加所需的所有CPU，所需的所有中间层和UI层，但是无论我们的网络，计算，内存等发展速度如何，此类系统的瓶颈通常是竞争性的领域模型，最终数据库。这里的“域模型”压力很大……从事微服务的互联网公司可能没有复杂，模棱两可和相互矛盾的域模型，例如FSI或保险公司或零售商……可能没有，例如Twitter的域很简单……发布并显示推文……但是，这在如此大规模的情况下变得复杂起来……企业开始同时遇到这两个问题。.领域模型及其复杂性与如何进行扩展同样重要（并且通常会阻碍扩展工作）。因此，现在您只是想“我们将仅使用像MongoDB这样的NoSQL数据库，以便我们可以扩展后端”……现在您遇到了更多问题。

那我们的团队呢？架构这样的系统的另一部分是，让我们可以让专家团队以不同的速度，不同的位置，不同的工具等独立地在这些层上工作。他们只需要彼此共享一个接口，就可以自主工作。这在某种程度上起到了法律作用：

设计系统……受约束的组织只能产生设计，这些设计是这些组织的通信结构的副本

不幸的是，我觉得事实恰恰相反。 并不是通过这种架构，我们可以为团队和效率的专业化创造机会。因为我们的组织结构迫使我们降低了系统架构。就像我们有独立的数据库团队，UI团队，安全性，操作，QA，构建和发布等一样。这是我们组织数十年来的组织方式。但是，如果您看看实践微服务的公司的成功之处，则它们的组织结构会有很大不同。

让我们看看会发生什么。以Ticket Monster应用程序为例，该业务要求我们更改网站管理的方式。他们要求我们添加一些与跟踪Concert添加到网站的频率有关的额外字段，因为他们希望添加预测性分析，以根据时间，位置，地点，天气等。如果企业希望向管理用户显示此预测分析，则可能涉及UI团队。当然，这将涉及更改应用程序的业务服务层。这肯定会影响数据库的更改。我们想在我们的应用程序中添加一些功能，以在所有层次上甚至在所有涉及的团队中强制施加连锁React。现在，我们必须让项目经理与所有相关团队协调和跟踪会议。我们需要创建票证，以使UI和DB团队做所有事情，而不必说质量保证，安全性，操作等。所有这些都在我们所有团队之间创建了复杂的同步点，现在我们必须协调我们各层的所有更改，构建和发布（并将所有内容一起部署！）。这不是我们想要的自治类型。我们不能彼此独立地进行更改，实际上，我们已经变得非常脆弱。

对于我们的Ticket Monster应用程序，让我们更喜欢将功能分为具有凝聚力的“垂直”，而不是通过技术或组织层面。每个行业都有其自己的“ UI”（或UI组件），“业务服务”和“数据库”，这些特定于网站的管理功能。（但是，对于第一步，我们将UI保留为整体，将其背后的部分分解掉。我们将重新分解UI，尽管这有其自身的挑战）。 Ticket Monster还允许用户查看和预订音乐会的订单。让我们将其拆分为自己的垂直字段。它还可能具有忠诚度，推荐，搜索，广告，个性化等。我们将这些内容划分为各自的垂直领域，每个垂直领域都拥有自己的数据库，UI和集成点（REST服务，后端等）。如果我们需要更改网站的“忠诚度”功能，则无需重新部署整个整体商务服务层或任何与“搜索”相关的内容。我可以将一部分忠诚度从UI部署到所需的数据库，而不会影响其他服务的更改。理想情况下，一个团队也将拥有并运营每项服务。

下一拱

这使我们在代码内的凝聚力更好，服务之间的自治性更高。一旦您开始了解沿着业务功能垂直领域拆分意味着什么，我们就可以为每个垂直领域探索其有限的上下文。或者在有限的上下文中应用CQRS是否有意义。或基于其读/写模式（文档，关系图，数据库）以及您是否赞成一致性还是可以容忍数据丢失/数据不一致，应使用哪种类型的数据库。或交易，补偿，道歉等可能会是什么样子。不断地..现在，我们可以根据最适合我们的单个服务的决策，而不是层或整体的最低公分母来做出这些决策。这就是我们将在下一篇文章中继续探讨的内容！敬请关注！

更新资料

Twitter上的某人（感谢@herrwieger！）向我指出了这一点：自包含系统（SCS）阐明了我在此处写过的这个概念。这一点很准确，完全符合我的意思。当我们在有限的上下文中探索每个“独立系统”时，更有趣的事情发生了，然后只有在必要时，它才分解为更细粒度的微服务。在讨论整体时，边界是重要的考虑因素，这就是我在这里谈到的以及SCS定义的内容。