为了账号安全,请及时绑定邮箱和手机立即绑定

微服务进程间通信之REST

2019.07.26 23:01 397浏览

微服务进程间的通信可以是同步的消息调用,也可以是异步的.
异步的调用,我们一般使用消息队列
那么同步的调用中, 比较流行的解决方案是 REST和Thrift

下面介绍下REST:

REST是一种(几乎总是)使用HTTP的IPC机制。REST中的一个关键概念是资源,它通常表示业务对象,比如客户或产品,或者业务对象的集合。REST使用基于HTTP操作资源,这些资源使用URL引用。例如,GET请求返回资源的表示形式,它可能是XML文档或JSON对象的形式。POST请求创建一个新资源,PUT请求更新一个资源。

借用REST创始人的话来说:“REST提供了一组体系结构约束,当作为一个整体应用时,这些约束强调组件交互的可伸缩性、接口的通用性、组件的独立部署和中介组件,以减少交互延迟、加强安全性和封装遗留系统。”

下面是一个使用REST的微服务的示例:

图片描述

许多开发人员声称他们基于HTTP的api是RESTful的。
然而,并不是如此,

Leonard Richardson定义了一个非常有用的REST成熟度模型,该模型由以下级别组成。

图片描述

0级API的客户端通过向其唯一URL端点发出HTTP POST请求来调用服务。每个请求指定要执行的操作、操作的目标(例如业务对象)和任何参数。使用HTTP作为远程交互的传输系统,但不使用web的任何机制。通常基于远程过程调用。

级别1—级别1 API支持资源的概念。要在资源上执行操作,客户机发出POST请求,指定要执行的操作和任何参数。

级别2 -级别2 API使用HTTP谓词执行操作:GET检索、POST创建和PUT更新。请求查询参数和主体(如果有的话)指定操作的参数。这使服务能够利用web基础设施,例如缓存GET请求。

级别3 -级别3 API的设计是基于非常有名的HATEOAS(超文本作为应用程序状态引擎)原则。基本思想是,GET请求返回的资源的表示包含用于在该资源上执行允许操作的链接。例如,客户端可以使用order表示形式中返回的链接取消订单,该链接用于响应发送来检索订单的GET请求。HATEOAS的好处包括不再需要将url硬连接到客户机代码中。另一个好处是,由于资源的表示包含允许操作的链接,客户端不必猜测在当前状态的资源上可以执行什么操作。

例如:
请求:

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

得到的响应是:

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
     <link rel = "/linkrels/slot/book" 
           uri = "/slots/1234"/>
  </slot>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
     <link rel = "/linkrels/slot/book" 
           uri = "/slots/5678"/>
  </slot>
</openSlotList>

在响应的list中, 每一项中包含了URI来告诉我们怎么进行下一步的操作.
我们从REST的分级中,可以得到REST的一些设计思想:
第1级通过分治来处理复杂性问题,将大型服务端点分解为多个资源。
第2级引入了一组标准的动词,这样我们就可以用同样的方式处理类似的情况,消除不必要的变化。
级别3引入了可发现性,提供了一种使协议更加自文档化的方法。

使用基于HTTP的协议有很多好处:

HTTP简单而熟悉。
您可以使用诸如邮递员之类的扩展在浏览器中测试HTTP API,或者使用curl在命令行中测试HTTP API(假设使用JSON或其他文本格式)。
它直接支持请求/响应式通信。
当然,HTTP是防火墙友好的。
它不需要中间代理,这简化了系统的体系结构。

使用HTTP有一些缺点:

它只直接支持交互的请求/响应样式。您可以使用HTTP进行通知,但是服务器必须始终发送HTTP响应。
因为客户机和服务直接通信(没有缓冲消息的中介),所以它们必须在交换期间同时运行。
客户端必须知道位置(即,每个服务实例的URL)。正如在上一篇关于API网关的文章中所描述的,这在现代应用程序中是一个非常重要的问题。客户端必须使用服务发现机制来定位服务实例。

开发人员社区最近重新发现了RESTful api的接口定义语言的价值。有几个选择,包括RAML和Swagger。一些idl(比如Swagger)允许定义请求和响应消息的格式。其他一些规范(如RAML)要求使用单独的规范(如JSON模式)。除了描述api之外,idl通常还具有从接口定义生成客户机存根和服务器骨架的工具。

以上就是Rest的介绍 下节介绍Thrift。

点击查看更多内容

本文首次发布于慕课网 ,转载请注明出处,谢谢合作

1人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消