本地微服务：分解拼图

这是一个由三部分组成的系列文章的第二部分，该系列文章探讨了以相同过程运行的本地微服务。 第一部分确定了对象定向行为中的耦合问题（在此处找到）。 本文将研究微服务如何帮助减少耦合问题。

第二部分：分解拼图

第一部分确定了对象行为耦合类似于拼图游戏。 这是各种形状的物体的高度耦合的拼图。 这些不同形状的物体使得它们在整体应用中难以重复使用和重构。

因此，您可能会问微服务如何帮助解决此问题？

对我来说，我认为微服务的演进是一种打破由对象方法施加的严格行为耦合的演进。

我们的应用程序变得越来越庞大：

由于所有内容都在刚性拼图中紧密结合在一起，因此无法增强或重复使用。

我们的第一个尝试是尝试通过面向服务的体系结构重用拼图的各个部分。 看起来如下：

在我看来，面向服务的体系结构注定会失败，因为尝试将方法连接器暴露在系统外部以供重用。 是的，我们现在可以调用我们的整体来重新使用它们的各个方面。 哦，等等，与该方法的耦合太多，以至于很难将其与整体组件的其余部分分开。

好的，我们可以采用治理和一些出色的编码实践来避免这种情况。 然而：

• 最后期限
• 捷径
• 新团队成员
• 偶尔的不良设计决策
• 等等

允许耦合随时间增加。 尽管我们想相信理想，但方法的行为耦合刚刚接管了整体拼图。

我们需要分解并保持孤立状态。

因此，我们将拼图分解为较小的拼图。 结果是HTTP请求/队列加入了以下较小的难题：

对我来说，微服务诞生了。

乍一看，这看起来与仅EJB 1.0远程调用的原始规范非常相似。 现在可能有人争辩说，微服务不是像EJB通常那样的单个对象。 但是，这不是为什么我看到微服务比远程EJB有所改进的原因。

EJB使用远程过程调用，该过程允许抛出多个参数和各种异常。 这并没有使您脱离方法调用的各种形状。 EJB仅允许方法被远程调用。 这些远程方法调用继续存在方法调用的所有拼图耦合问题。 除此之外，由于网络故障，它们现在不那么可靠。 因此，EJB遭受方法耦合问题，导致您遇到分布式整体式拼图。

另一方面，微服务通过HTTP请求/队列消息对其他微服务的标准化调用。 查看方法调用的五个耦合方面（ 耦合控制反转 ），HTTP请求/队列消息消除了大多数方法调用耦合：

方法耦合方面	HTTP请求	队列
方法名称	网址 不过，可以通过在服务目录/注册表中进行查找来取消间接耦合	出站队列 提供到目标使用者的解耦间接（通过消息路由）
返回类型	可提供退货实体。 但是，通常这仅适用于用户等待的前端。 注意：注意微服务之间的同步返回，因为它们会创建同步耦合，从而导致分布式整体	N / A，与任何同步返回值解耦
参量	仅单个有效载荷 通常是JSON / XML序列化的对象。	仅单个有效载荷 通常是JSON / XML序列化的对象。
例外情况	标准化的REST状态代码。 注意：小心依赖错误响应有效负载，因为它们可能表明微服务中的内聚性问题	N / A，与任何同步处理分离
穿线	解耦为单独的过程 任何支持同步响应的线程模型	解耦为单独的过程 线程模型无限制

因此，使用HTTP请求/队列，可以有效地标准化微服务调用形状。 给定有效负载通常是序列化的对象（例如JSON / XML），这将消除传递多个参数的能力。 标准化HTTP状态代码不允许出现各种异常。 另外，我最喜欢的队列微服务通信因其本质而分离。

因此，通过发出通信HTTP请求/队列消息，微服务正在消除方法耦合问题。 由于形状只是名称（HTTP URL /队列名称）和单个参数（有效负载），因此它使调用不同的微服务变得更加容易。

实际上，这与第一部分中讨论的对象参考类型和参考形状相似。 但是，现在类型是参数类型（有效负载序列化对象），引用是名称（URL /队列名称）。 这样一来，微服务的行为就可以像第一部分开始时的理想化对象图（标准形状的微服务调用连接器的线）那样来表示。

请继续关注第三部分，我们将进一步将微服务容器与服务方法隔离，以有效地启用本地微服务。

翻译自: https://www.javacodegeeks.com/2019/06/local-microservices-breaking-jigsaw.html