资讯专栏INFORMATION COLUMN

微服务指南走北(二):微服务架构的进程间通信(IPC)

beanlam / 1585人阅读

摘要:微服务常用的进程间通信技术即表述性状态传递英文,简称是博士在年他的博士论文中提出来的一种软件架构风格。摘自微服务实战从架构到部署处理部分请求失败对于分布式的微服务,必须要面对的一大问题就是局部请求失败的处理。

先抛出几个问题

微服务架构的交互模式有哪些?

微服务常用的进程间通信技术有哪些?

如何处理部分请求失败?

API的定义需要注意的事项有哪些

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

微服务架构的交互模式 一对一还是一对多?

一对一:每个客户端请求有一个服务实例来响应

一对多:每个客户端请求有多个服务实例来响应

同步还是异步?

同步模式:客户端请求需要服务端即时响应,甚至可能由于等待而阻塞

异步模式:客户端请求不会阻塞进程,服务端的响应可以是非即时的

一对一的交互模式有以下几种方式:

请求/响应:一个客户端向服务器端发起请求,等待响应,客户端期望此响应即时到达。在一个基于线程的应用中,等待过程可能造成线程阻塞。

通知(也就是常说的单向请求):一个客户端请求发送到服务端,但是并不期望服务端响应。

请求/异步响应:客户端发送请求到服务端,服务端异步响应请求。客户端不会阻塞,而且被设计成默认响应不会立刻到达。

一对多的交互模式有以下几种方式:

发布/ 订阅模式:客户端发布通知消息,被零个或者多个感兴趣的服务消费。

发布/异步响应模式:客户端发布请求消息,然后等待从感兴趣服务发回的响应。

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

REST:REST即表述性状态传递(英文:Representational State Transfer,简称REST)是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。

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流行的一个重要因素。对于微服务架构而言,必须要有一个简单且轻量级的消息机制。

参考文章:

微服务实战:从架构到部署

by 刘迎光@萤火虫工作室
OpenBI交流群:495266201
MicroService 微服务交流群:217722918
mail: liuyg#liuyingguang.cn
博主首页(==防止爬虫==):http://blog.liuyingguang.cn
OpenBI问答社区:http://www.openbi.tk

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/66808.html

相关文章

  • 服务指南走北(一):服务是什么

    摘要:每个微服务提供一组,供其他微服务或者应用客户端所用。由于微服务架构的分布式特点,测试一个基于微服务架构的应用也是很复杂的任务。微服务架构模式下,应用的改变将会波及多个服务。 微服务Microservices已经成为软件架构最流行的热词之一。网络上看到很多关于微服务的文章,但是感觉很多离我们还很遥远,并且没有找到多少真正在企业场景中应用的实例。此处省略一万字~~~~于是想要将自己最近一段...

    sherlock221 评论0 收藏0
  • PHP进程通信

    摘要:一进程间通信理解间进程通信机制,先了解下进程间有哪些通讯机制历史发展按照历史来源主要有两大块的管道,,信号的消息队列,共享内存,信号灯。信号量主要作为进程间,以及进程内部线程之间的通讯手段。主要依赖,兼容扩展实现方式的进程间通信之消息队列。 PHP间进程如何通信,PHP相关的服务的IPC是实现方式,IPC的思想如何用到项目中。 一、linux进程间通信 理解php间进程通信机制,先了解...

    haobowd 评论0 收藏0
  • 服务指南走北(三):Restful API 设计简述

    摘要:为了避免的变动导致用户使用中产生意外结果或调用失败,最好强制要求所有访问都需要指定版本号。请避免提供默认版本号,一旦提供,日后想要修改它会相当困难。返回结果针对不同操作,服务器向用户返回的结果应该符合以下规范。 API的定义取决于选择的IPC通信方式,如果是消息机制(如 AMQP 或者 STOMP),API则由消息频道(channel)和消息类型;如果是使用HTTP机制,则是基于请求/...

    TZLLOG 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<