原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『高级篇』docker之微服务间如何通讯（六）

创新互联的团队成员不追求数量、追求质量。我们经验丰富并且专业，我们之间合作时就好像一个人，协同一致毫无保留。创新互联珍视想法，同时也看重过程转化带来的冲击力和影响力，在我们眼中，任何细节都不容小觑。一直致力于为企业提供从主机域名、网站策划、网站设计、商城开发、网站推广、网站优化到为企业提供个性化软件开发等基于互联网的全面整合营销服务。

从通信模式角度考虑

说到通信可能会想到：socket，http，tcp/ip，zookeeper等等，这么多东西在一起可能会感觉比较乱，提供个思路来考虑微服务的问题，通信方式和通信协议来考虑。

通信方式

• 一对一（同步），特别常见请求相应模式，最常见的
• 一对一（异步），某个服务发送通知的时候， 不需要等待响应，不需要对方立刻响应，而是通过回调的方式得到对方的响应。
• 没有一对多（同步）这种场景
• 一对多（异步），发布订阅的方式、发布异步响应。例如：滴滴打车，叫一辆车的时候，系统会将我这个消息告诉所有能够接受消息的车主，他们来抢单，发出一个响应回来，就知道那位师傅抢到了单子。

通信协议

• REST API

  很多人把rest api等同于 http的接口设计，其实他们不能直接化等号的，rest 是很早提出的一个概念，rest是表现层的状态转移，其实这个没几个人可以听的懂，其实rest是网络中客户端和服务端的一种交互形式，它本身就是一个抽象概念，主要是如何设计一个rest api，以http为例，就是用http协议来实现rest形式的api，

在 Web 应用中处理来自客户端的请求时，通常只考虑 GET 和 POST 这两种 HTTP 请求方法。实际上，HTTP 还有 HEAD、PUT、DELETE 等请求方法。而在 REST 架构中，用不同的 HTTP 请求方法来处理对资源的 CRUD（创建、读取、更新和删除）操作：
若要在服务器上创建资源，应该使用 POST 方法。
若要检索某个资源，应该使用 GET 方法。
若要更改资源状态或对其进行更新，应该使用 PUT 方法。
若要删除某个资源，应该使用 DELETE 方法。

• RPC

  1. dubbo
  2. motan
  3. dubbox
  4. grpc
  5. thrift
• MQ

  消息队列，实际场景用的不太多，例如之前说的滴滴打车这种就是消息订阅的模式。

如何选择RPC框架

RPC是微服务方面最多的一种情况，也是选择比较多的情况，可选的RPC框架也非常的多，选择一个RPC框架是需要面临的问题。

• I/O，线程调度模型

  长连接，短连接，单线程，多线程，线程调度算法的性能

• 序列化的方式

  可读的（XML，JSON），二进制（FASTJSON），为什么要考虑序列化呢，因为序列的效率直接影响到我们通信的效率，扩大了序列化和反序列化的时间，RPC的效率，同一个对象如果序列化小的话大大提升效率。

• 多语言支持

  根据团队语言，如果是多语言就需要找支持多语言的RPC框架，如果单语言例如都是java，就直接dubbo只支持java。

• 服务治理

  比如有没有服务发现，服务监控，一个拥有服务治理的RPC框架，一般支持集群的部署和服务高可用。

目前流程RPC框架有哪些

• Dubbo/DubboX

  2014年10月份，dubbo就不在维护了，时隔3年dubbo又重新开始维护，一来用户量确实很多，二来微服务比较火，对微服务更好的支持。DubboX是在阿里的dubbo基础上开发的一套DubboX。只支持java语言。

• Motan

  一套新浪微博的，2016年5月进行的开源，号称每天支持新浪微博的千亿级别的调用量，通过spring的调用方式不需要额外的代码就具有分布式的能力。只支持java语言。

• Thrift

  2007年facebook开发的，08年进入了apche项目，它是一个跨语言的。毕竟那么多年，你想到的它都支持。没有服务治理相关的东西。

• GRPC

  google开源的一个项目，跟Thrift相似，也支持跨语言。

对比

PS：微服务通信的根本就是RPC通信，比http效率高，稳定性好。

本文题目：『高级篇』docker之微服务间如何通讯（六）
URL标题：http://www.tsicrk.com/article/jiojso.html