微服务之间的通信

从单服务器方法转向容器并不总是那么容易。但几乎可以将每个系统设置为在容器中运行。例如,标准 Web 托管设置可以让 PHP 和 Nginx 在一个容器中运行,而 MySQL 在另一个容器中运行。

从头开始构建一个充分利用容器的系统完全是另一回事。在使用单一方法这么长时间之后,在精神上和身体上向构建微服务架构的转变并不总是像看起来那么简单。有很多调整需要进行,包括对开发方法本身的调整。

尽管如此,微服务提供的好处还是不容错过。除了更高的灵活性和效率之外,从长远来看,基于微服务构建的应用程序更可持续、更可靠、更易于维护。

最新的 DZone 参考卡

云原生应用安全


使用微服务架构提供的工具和功能可以实现这些好处。我们在微服务:好的、坏的和丑陋的文章中更深入地讨论了这个问题。然而,在本文中,我们将更多地关注微服务之间的通信。

通信和微服务
微服务服务于构建更大的应用程序所必需的特定功能。那么,这样的应用程序中的微服务需要相互通信以完成更大的例程,这是很自然的。有趣的是,在设置微服务如何相互通信时,您有很多选择。

在微服务之间建立正确的通信流之前,需要确定几个因素。这些因素是:

建筑风格
微服务通信可以设置为无状态 或有状态进程。这意味着可以将微服务之间的通信配置为同步和异步过程。我们稍后会讨论这个问题。

关于有效负载的形成方式,也有很多选择,而且您现在还有大量的消息传递格式可供使用。您可以为您的应用程序使用 REST 或 SOAP,或者仅依赖 JSON 来简化管理。您甚至可以将 XML 集成到通信过程中。

传输协议
接下来,您必须确定微服务之间的通信应如何进行。再次,这取决于您想要建立同步通信还是异步协议。

当您使用 HTTP 或 HTTPS 时,您正在利用同步通信。另一方面,AMQP 允许您在整个应用程序中运行异步通信,这给表带来了很多新的好处。

从这个角度来看,您通常最终会结合使用架构风格和传输协议。这正是为什么在微服务被广泛使用之前我们就拥有流行的通信格式的原因。我的意思是,我们对 RPC 都有不同的感受,但即使在今天,它仍然是一种可靠的通信方式。对于 HTTPS 上的 REST 来说也是如此。

现代方法
借助微服务,您可以通过另一种方式来确定设计通信架构的正确方法。首先确定您希望应用程序的设计依赖于同步通信还是异步选项。一旦您根据需要实现的目标确定了正确的方法,您就可以继续寻找最合适的通信协议。

下一步是确定通信流程。在某些情况下,您可能希望多个微服务充当接收者。在其他情况下,您只需要在微服务之间建立一对一的通信。这两种情况需要不同的处理。您还拥有额外的层,例如每个云提供商都有自己的实现的消息传递服务,例如 Azure 服务总线,它可以帮助您设计和维护复杂的通信流。

即使采用这种现代方法,也很容易看出一些现有且非常流行的设计在应用于微服务时仍然可以发挥作用。在许多情况下,使用 HTTPS 作为主要协议的一对一通信是最简单的方法。对于更复杂的用例,使用消息服务 RabbitMQ 等外部服务来简化 AMQP 的使用提供了最高效且有效的方法。

同步与异步
我觉得我们必须更深入地挖掘并更多地讨论同步和异步通信,特别是在微服务中实现时。了解这两者可以让您更好地了解如何最好地设置系统。

当然,同步通信被安排为一个周期,并要求该周期中的每个微服务按顺序工作。当客户端向第一个节点(通信篮)发送请求时,该请求由流程中涉及的微服务一次处理一个,然后通过相同的微服务将响应传回第一个节点。

异步通信不是这样工作的。循环的开始是相同的;客户端向第一节点发送请求。然而,在那之后一切都不同了。通信篮能够识别请求、确定要联系的正确微服务并做出相应反应。

因此,同一个请求可以触发对微服务 A 和 C 的请求,但不能触发对微服务 B 的请求。篮子也可能期望来自微服务 A 的回复,但不会来自微服务 C。它是完全灵活的,并且微服务可以独立于一个服务。其他。

由于周期不再同步,因此可以以更快的速度进行通信。同时,无需等待所有微服务响应即可传递响应。更好的是,您可以添加根本不需要响应的微服务(即处理日志记录或冗余的微服务),使整个系统更精简、更高效。

了解挑战
微服务之间的通信并非没有挑战。异步通信的可能性是无限的,但仍然存在需要减轻的重要风险。这些风险是:

性能:通信架构的设计方式需要考虑需要进行的调用(请求)数量、流程如何影响性能以及是否可以进行改进。
容错:还需要管理微服务在发生错误时如何响应。假设通信篮没有收到微服务应该收到的响应;有什么程序可以处理这种情况?
依赖关系:根据微服务的设置方式,很容易陷入设计建立依赖关系的通信架构的陷阱。如果没有正确缓解,您最终可能会得到一个充满依赖微服务的应用程序,从而完全消除使用微服务的优势。
监控和日志记录:由于微服务之间的通信可以独立发生,因此日志记录和监控变得更具挑战性。根据您的情况,需要一种更好的方法来跟踪任务关键型微服务之间的交互。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

千源万码

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值