微服务架构的进程间通信(IPC)

微服务架构的进程间通信(IPC)

先抛出几个问题:

  1. 微服务架构的交互模式有哪些?
  2. 微服务常用的进程间通信技术有哪些?
  3. 如何处理部分请求失败?
  4. API的定义需要注意的事项有哪些
  5. 微服务的通信机制与SOA的通信机制之间的关系与区别

微服务架构的交互模式

一对一还是一对多?
  1. 一对一:每个客户端请求有一个服务实例来响应
  2. 一对多:每个客户端请求有多个服务实例来响应
同步还是异步?
  1. 同步模式:客户端请求需要服务端即时响应,甚至可能由于等待而阻塞
  2. 异步模式:客户端请求不会阻塞进程,服务端的响应可以是非即时的
一对一的交互模式有以下几种方式:
  1. 请求/响应:一个客户端向服务器端发起请求,等待响应,客户端期望此响应即时到达。在一个基于线程的应用中,等待过程可能造成线程阻塞。
  2. 通知(也就是常说的单向请求):一个客户端请求发送到服务端,但是并不期望服务端响应。
  3. 请求/异步响应:客户端发送请求到服务端,服务端异步响应请求。客户端不会阻塞,而且被设计成默认响应不会立刻到达。
一对多的交互模式有以下几种方式:
  1. 发布/ 订阅模式:客户端发布通知消息,被零个或者多个感兴趣的服务消费。
  2. 发布/异步响应模式:客户端发布请求消息,然后等待从感兴趣服务发回的响应。

微服务常用的进程间通信技术

  1. REST:REST即表述性状态传递(英文:Representational State Transfer,简称REST)是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。
  2. Thrift:thrift是一个软件框架,用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎,以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务

API的定义需要注意的事项

  • IPC通信方式的选择:API的定义取决于选择的IPC通信方式,如果是消息机制(如 AMQP 或者 STOMP),API则由消息频道(channel)和消息类型;如果是使用HTTP机制,则是基于请求/响应(调用http的url)。
  • API的版本升级:服务的API往往随着时间的推移而不断变化。在单体应用中,往往会直接修改API的消费者。但是在微服务中,通常不能让所有的API消费者保持与API同步更新,可能新版本和旧版本的API同时运行。
  • 消息格式的选择:为微服务来决定最适合的消息格式是另一个关键要素。传统的单体的软件使用复杂的二进制的格式,SOA/Web services的应用使用基于复杂消息格式(SOAP)和schema(xsd)的文本消息。在大多数的微服务里面,它们使用简单的基于文本的消息格式,例如基于HTTP资源API风格之上的JSON/XML等。在某些情况下它们需要二进制的格式时(文本消息在某些场景下显得啰嗦),可以使用二进制的协议例如二进制的Thrift、Protobuf、Arvo。(摘自《微服务实战:从架构到部署》)

处理部分请求失败

对于分布式的微服务,必须要面对的一大问题就是局部请求失败的处理。

Netfilix 提供了一个比较好的解决方案,具体的应对措施包括(摘自“Chris Richardson 微服务系列”):

  • 网络超时:在等待响应时,不设置无限期阻塞,而是采用超时策略。使用超时策略可以确保资源不被无限期占用。
  • 限制请求的次数:可以为客户端对某特定服务的请求设置一个访问上限。如果请求已达上限,就要立刻终止请求服务。
  • 断路器模式(CircuitBreakerPattern):记录成功和失败请求的数量。如果失效率超过一个阈值,触发断路器使得后续的请求立刻失败。如果大量的请求失败,就可能是这个服务不可用,再发请求也无意义。在一个失效期后,客户端可以再试,如果成功,关闭此断路器。
  • 提供回滚:当一个请求失败后可以进行回滚逻辑。例如,返回缓存数据或者一个系统默认值。

微服务的通信机制与SOA的通信机制之间的关系与区别

在单体应用里面,不同组件的业务功能通过函数调用或者语言级别的方法调用来实现。在SOA中,这转变为更加松耦合的Web Service级别的消息,主要是基于HTTP、JMS等不同协议的SOAP。Webservice 包含的几十种操作以及复杂的消息机制是阻碍Web Services流行的一个重要因素。对于微服务架构而言,必须要有一个简单且轻量级的消息机制。

参考文章:

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值