微服务优化之使用gRPC做微服务的内部通信

使用grpc做微服务的内部通信

grpc是一个由google开源的远程服务调用框架，具有多路复用和双向流式通信的特性。

大家好，在本文中将为大家介绍为什么我们应该使用grpc代替restful或json，来开发微服务内部的通信接口。

什么是grpc?

grpc是一个高性能的、开源的、普遍通用的rpc框架。简单地说，它能够帮助我们建立透明的服务端和客户端通信系统。google开发了grpc并且将其开源。 通过它，一个客户端消费者服务可以像调用本地方法一样，调用另一台主机上面的服务端方法。 grpc本质上仍然遵循常规的remote procedure call (rpc) 技术，但是在实现上使用了http2.0、协议缓冲区等更现代化的技术方案，从而最大程度上确保服务端和客户端的互操作性及性能上的提升。

服务之间如何使用grpc通信？

当客户端向服务端发起请求的时候，客户端grpc类库使用协议缓冲区并且封装远程过程调用(rpc),并且将其通过http2发送到服务端。服务端将其拆封，并且使用协议缓冲区调用对应的程序。响应数据的过程和发送请求的过程是类似的，只不过一个是从客户端到服务端，一个是从服务端到客户端。
从开发的角度，在服务端和客户端使用grpc最大的好处在于：你的服务端的代码和客户端的代码不需要担心它会影响你解析json或者其他类似的文本格式消息。grpc虽然接收到的是二进制格式，但会并将其反序列化为对象。同样的我们可以通过idl来定义服务接口，idl是非常强大的一个特性，帮助我们处理多个微服务之间的互操作。

为什么grpc是高效的？

• 它基于http2构建，既支持传统的请求-响应模型，也支持双向流模型。
• 可以将json数据转换到协议缓冲区
• 多路复用
• 双向流模型
• 网络传输的是二进制数据，相对于json等文本数据更加轻量级。
• 多语言支持

什么时候使用grpc？

最初，几乎所有的微服务之间都是通过json数据接口通信的，一个服务可能调用空一个服务或者多个服务，被调用的服务可能还调用其他服务。如果其中任何一个服务运行缓慢，将影响整个系统的运行速度，因为restful(json) api不支持http2的多路复用和双向流模型。传统的restful接口使用json、xml或者其他的一些格式作为数据载体，使得服务运行缓慢，内存占用较高、并且传输过程没有压缩。

grpc解决所有的这些问题，但是它仅仅用于系统应用微服务之间的通信的情况，系统的对外服务接口仍然使用http-json接口。这样保证对外部用户的开发技术栈没有任何影响。

总结 conclusion

与传统rest api相比，使用grpc创建的api可以为你的应用带来令人难以置信的性能改进。

欢迎关注我的博客，里面有很多精品合集

• 本文转载注明出处（必须带连接，不能只转文字）：。