分布式系统 - 通信方式

同步

RPC

实现考虑

  • 通讯方式,IO选择(同步阻塞的BIO、同步非阻塞的NIO、异步非阻塞的AIO), 长连接还是短连接
  • 序列化与反序列化,hessian、protobuf、json、kryo等
  • 服务注册与发现
  • 负载均衡及容错
  • 结果缓存
  • 接口多版本控制

现有案例

  • motan
    • 新浪微博出的rpc框架
  • gRPC
    • GRPC尚未提供连接池,需要自行实现
    • 尚未提供“服务发现”、“负载均衡”机制
    • 因为基于HTTP2,绝大部多数HTTP Server、Nginx都尚不支持,即Nginx不能将GRPC请求作为HTTP请求来负载均衡,而是作为普通的TCP请求。(nginx1.9版本已支持)
    • Protobuf二进制可读性差(貌似提供了Text_Fromat功能)
  • Apache Thrift
  • Dubbo
    • rpcx go语言版本
    • dubbox
  • HTTP - 特殊的RPC
HTTP1.0 协议时,HTTP 调用还只能是短链接调用,一个请求来回之后连接就会关闭。HTTP1.1 在 HTTP1.0 协议的基础上进行了改进,引入了 KeepAlive 特性可以保持 HTTP 连接长时间不断开,以便在同一个连接之上进行多次连续的请求,进一步拉近了 HTTP 和 RPC 之间的距离。

当 HTTP 协议进化到 2.0 之后,Google 开源了一个建立在 HTTP2.0 协议之上的通信框架直接取名为 gRPC,也就是 Google RPC,这时 HTTP 和 RPC 之间已经没有非常明显的界限了

- Http 1.0 短连接
- Http 1.1 Keep-Alive 保持长连接
- Http 2.0
1
2
3
4
5
6
7

异步

消息队列

  • ActiveMQ
  • RabbitMQ
  • Kafka
  • ZeroMQ