协议

Json Over HTTP (baseline)

Pro:

1. 工具最完善
2. 浏览器友好 (利于调试)
3. 纯文本, 协议容易理解

Con:

1. head-of-line blocking:
   • HTTP1.1要并发请求必须建立多个TCP连接, 在同一条连接上,一个较慢的请求会阻塞后续包
2. 使用时需自己拼装json, 校验不足

grpc

Pro:

1. 支持所有主流语言
2. 更丰富的生命周期管理
   • 发送一个请求, 持续接受结果, 而无需等待所有结果接续后序列化为json
   • 持续发送请求, 等待服务处理完毕后返回
   • 双向流
3. 使用Protobuf定义接口, 自动编译为代码
4. 很多第三方的工具已经支持grpc接口, 比如tensorflow-serving
5. 基于HTTP/2, 有完善的代理/负载均衡工具, 比如nginx/haproxy, 和其他工具, 网关/监控/中简件 (https://github.com/grpc-ecosystem)
6. client-side load balancing and state management, 可以放心的重启服务, 而无需把节点从l5中下掉 避免了一些服务调用时不上报l5导致挂掉的服务一直报警
7. 不依赖外部网络库

Con:

1. Python中可能和其他非grpc服务结合需要起线程, 比如redis/mysql…
2. 性能差, 各种rpc框架都拿来做baseline

Thrift

分为Apache Thrift和fbthrift两种

baidu-rpc

Pro:

1. 性能强于grpc

Con:

1. Only C++ implementation is opensourced right now.

框架

• Twisted: 比较早的(开始于2002年)Python 异步IO框架, 基于回调
• Tornado: 简化版的Twisted, 附带了web功能
• gevent: 协程, monkey-patch可以把第三方库(mysql/redis…)对socket的请求转换为异步
• asyncio: Python3引入的标准库, 使用新关键字async/await

从网上的benchmark来看, 这些框架速度上没有太大区别, 主要从易用性和积累方面选择

• WSGI服务器, 一般置于NGINX后面:
  • uWSGI
  • Gunicorn
• WSGI框架:
  • Flask
  • Django

结论

从生态系统的角度应该选择HTTP+JSON/grpc

如果是内部的微服务, 应该使用RPC框架, 这样可以快速开发和测试, 进化协议, 而且无需写client.

grpc和thrift都支持所有可能的语言, grpc更晚设计, 有一些更好的特性, 比如流

如果请求和返回格式比较简单, 且每个包数据量比较小可以考虑选择HTTP+JSON.

Reference

• gRPC Concepts
• Building scalable microservices with gRPC