grpc与thrift

HTTP2.0 相比 HTTP1.1 有非常大的不同，HTTP1.1 还是基于文本协议的问答有序模式，但是 HTTP2.0 是基于二进制协议的乱序模式 (Duplexing)。这意味同一个连接通道上多个请求并行时，服务器处理快的可以先返回而不用因为等待其它请求的响应而排队。

头部优化：我们知道 HTTP 协议的请求头有大量的 key/value 文本组成，多个请求直接 key/value 重复程度很高。为了优化这部分，HTTP2.0 对请求头的 key/value 做了字典处理，对于常用的 key/value 文本无需重复传送，而是通过引用内部字典的整数索引来达到显著节省请求头传输流量的目的。这也意味着以后我们无法直接使用肉眼来观察 HTTP 协议测传输内容了，它的协议内容对肉眼不再十分友好。
grpc线程模型:
gRPC 默认使用的是异步 IO 模型，底层有一个独立的事件循环。它的异步不是使用 Python 内置的 asyncio 来完成的，它使用的是开源异步事件框架 gevent。gevent 的优势在于可以让用户使用同步的代码编写异步的逻辑，而完全不知内部正在进行复杂的协程调度，这样可以明显降低框架代码的实现复杂度。grpc 服务器端接收到一个完整的消息包后就会传递到线程池去进行业务逻辑处理，线程池是由用户层代码来指定的，待线程池将任务执行完成后会将结果扔到 IO 模型的完成队列中进行后续的响应处理。

gRPC Streaming模式：
gRPC 的一个特色之处在于提供了 Streaming 模式，有了 Streaming 模式，客户端可以将一连串的请求连续发送到服务器，服务器也可以将一连串连续的响应回复给客户端。它类似于列表类型的消息，但是又不一样。列表类的消息要求我们一次性将整个列表消息打包传递给服务器，但是 Streaming 不一样，可以生成一个请求就可以立即发往服务器，接下来继续生成请求，继续发送，就好比流水线一样。对比前面的同步调用，Streaming 可以理解为 gRPC 的异步调用。
thrift原理：

版权声明：本文来源CSDN，感谢博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/u011915028/article/details/89005754
站方申明：本站部分内容来自社区用户分享，若涉及侵权，请联系站方删除。

发表于 2020-03-01 22:00:01
阅读 ( 1179 )
分类：

grpc与thrift

你可能感兴趣的文章

精选的优质文章

0 条评论

官方社群

GO教程

推荐文章

猜你喜欢

随便看看