微服务消息传递协议简介

栏目: 服务器 · 发布时间: 5年前

内容简介:当公司将基于各种服务的应用程序集合在一起时,您可以预期它们正在运行微服务架构结构。微服务主要用于实现,提供复杂应用程序的模式,协议和部署。从根本上说,这种架构风格颠覆了与整体扩展,速度,语言障碍和组织相关的许多问题。虽然由于这些原因大规模采用微服务技术,但我们应该置身于微服务架构的两个部分,这通常是开发人员的绊脚石:通信和消息传递。当从单一应用程序结构转换到多独立结构时,您会立即发现调用其他组件并不与单进程系统对齐。在单进程系统中,您通常会使用各种语言方法或通过依赖注入来调用组件,就像我们在Angular中

当公司将基于各种服务的应用程序集合在一起时,您可以预期它们正在运行微服务架构结构。微服务主要用于实现,提供复杂应用程序的模式,协议和部署。从根本上说,这种架构风格颠覆了与整体扩展,速度,语言障碍和组织相关的许多问题。

虽然由于这些原因大规模采用微服务技术,但我们应该置身于微服务架构的两个部分,这通常是开发人员的绊脚石:通信和消息传递。

微服务架构中的通信有何不同?

当从单一应用程序结构转换到多独立结构时,您会立即发现调用其他组件并不与单进程系统对齐。在单进程系统中,您通常会使用各种语言方法或通过依赖注入来调用组件,就像我们在Angular中看到的那样。由于基于微服务的应用程序可以在各种服务器,主机和进程上运行,因此我们看到通信倾向于HTTP(超文本传输​​协议),TCP(传输控制协议)和AMQP(高级消息队列协议)。所有这些协议都是为IPC或进程间通信而构建的,因为它们正在管理共享数据。

那么,微服务架构如何处理分布式独立进程中的通信?一些交叉的方式:

  1. 同步协议
  2. 异步协议
  3. 单接收器
  4. 多个接收器

由于服务,主机和客户端的通信方式不同,因此基于微服务的消息传递或通信建立在协议和接收器的交叉点上。

同步协议

您会发现自己每天都在进行同步协议处理,因为它内置于聊天功能,HTTP,即时消息和“实时”功能中。这是一种定期发生的数据传输,通常取决于微处理器时钟,因为发送器和接收器之间需要有时钟信号。您还可以将其理解为需要主/副本配置的协议,因为一个设备可以控制另一个设备以确保同步。

异步协议

与同步异步协议相反的是在时钟信号的约束之外工作,并且在任何时间以不规则的间隔发生。如上所述,同步协议依赖于微处理器,这意味着这些协议通常用于计算机内部发生的过程。对于异步流程,缺乏这种依赖性使它们广泛用于云环境和操作系统。发送信息后无需等待接收方的响应。

单接收器

名称中隐含的单个接收器设置表示每个请求必须由一个接收器处理。因此,在数据传输的情况下,需要交错请求以便被接收,因为它们不能同时被接收。

多个接收器

多个接收器可以处理多个请求,因为每个请求可以由零到多个接收器处理。例如,您通常会看到Saga模式中使用的多个接收器,因为它需要异步并同时提升数据一致性。

什么交叉点对于基于微服务的架构很受欢迎?

如您所见,由于需要整合和管理的各种服务,架构依赖于协议和接收器的组合。最常用的组合往往是使用同步协议的单接收器通信,如HTTP或HTTPS,因为它调用常规Web服务。当我们考虑 Docker 如何使用可以轻松运行Web应用程序的容器时,您可以想象它的频率。

这有什么重要意义?

虽然这些讨论点对您来说可能有点热门,但维护和集成微服务实际上是沟通方面的关键。开发人员希望能够保持每个微服务的独立性,同时将它们无缝地和异步地集成到应用程序中。

应用程序中的微服务之间的同步通信通常被视为一种并发症,头痛,并且最坏的情况是丧钟。这是因为基于微服务的架构在微服务的自主性及其对消费者的即时可用性方面发挥了作用。因此,即使另一个微服务在应用程序中瘫痪,由于同步依赖性,在所有微服务中也没有涟漪效应。

从传闻研究来看,由于数据依赖性,开发人员在构建体系结构时经常会遇到麻烦。有时,您会发现一个微服务需要来自应用程序内另一个微服务的数据。如果您使用同步通信来请求数据,那么如果请求的微服务突然停止工作,则没有备份。现在有两个(或更多),而不是只有一个处于“无序”状态的微服务。

如何避免同步依赖?

复制和传播将有助于回避同步性问题。通过复制,您可以将数据存储在多个站点(如服务器)中。这极大地提高了数据的可用性并减少了不一致性。通过传播,您可以将数据从服务器推送到客户端,这对于本地访问方案非常有用。

如果复制和传播不是当前路由,您还可以跨微服务复制数据。这与每个微服务的域模型边界密切配合。在处理域模型边界时,您需要关注业务功能的范围,并在服务之间创建可理解且有意义的分离。如果实现有意义的分离,这也将有助于提高数据和迭代的可伸缩性和域驱动选择。

什么是流行的沟通方式?

因此,在对微服务到微服务通信的更大考虑之后,大多数人会怎么做?

  • 对内部微服务结构之外的服务使用HTTP / REST(同步)通信。HTTP / REST通信非常适合外部请求,因为它可以轻松处理来自客户端的实时交互等项目。
  • 在内部微服务结构中使用AMQP(异步)进行通信方法。

最终,微服务架构遵循在应用程序中应用消息传递和通信协议的逻辑结论。在采用微服务时,您必须确保在开发和构建多方面应用程序时需要考虑前瞻性思路:可扩展性,基础架构和转换。在整个服务中建立强大的沟通基础是明智的,因为它有助于它的发展并影响应用程序的其他部分。

随着您扩展您对微服务的了解并可能进入开发和实现,您将需要更多地探索在应用程序中创建一致性,探索围绕采用微服务的案例研究,以及微服务对DevOps生命周期的影响。基于微服务的体系结构非常灵活且功能强大,尤其是在开发通信背后的基础方面,了解每项服务的范围以及客户和消费者的前端需求之后。

赞赏

微服务消息传递协议简介 微信赞赏 微服务消息传递协议简介 支付宝赞赏


以上所述就是小编给大家介绍的《微服务消息传递协议简介》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

失控

失控

[美]凯文·凯利(Kevin Kelly) / 张行舟 等 / 译言·东西文库/电子工业出版社 / 2016-1 / 89.00元

《失控:全人类的最终命运和结局》(全新修订本)是一部思考人类社会(或更一般意义上的复杂系统)进化的“大部头”著作,对于那些不惧于“头脑体操”的读者来说,必然会开卷有益。 “大众智慧、云计算、物联网、虚拟现实、网络社区、网络经济、协作双赢、电子货币……我们今天所知的,绝大多数是我们二十年前就已知的,并且都在这本书中提及了。”——凯文·凯利 《失控》成书于1994年,2010年中文版首次面......一起来看看 《失控》 这本书的介绍吧!

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具