onvno
commented
5 years ago RPC框架介绍
随着公司规模的扩大，以及业务量的激增，单体应用逐步演化为服务/微服务的架构模式， 服务之间的调用大多采用rpc的方式调用，或者消息队列的方式进行解耦。几乎每个大厂都会创建自己的rpc框架，或者基于知名的rpc框架进行改造。
目前, rpc框架主要沿着两条路线发展，一个是目标为了跨语言，服务端可以用不同的语言实现，客户端也可以用不同的语言实现，不同的语言实现的客户端和服务器端可以互相调用。很显然，要支持不同的语言，需要基于那种语言实现相同协议的框架，并且协议设计应该也是跨语言的，其中比较典型的是 grpc,基于同一个IDL，可以生成不同语言的代码，并且语言的支持也非常的多。
另一个rpc框架发展的目标是支持服务治理，主要的精力放在服务发现、路由、容错处理等方面，主要围绕一个语言开发，可能也有一些第三方曲折的实现服务的调用和服务的实现，这其中的代表，也是比较早的开源的框架就是阿里巴巴的dubbo。
有些rpc框架协议的涉及一开始就没有考虑的跨语言，其中使用了语言的一些特有的属性，比如Java的ObjectInputStream/ObjectOutputStream, Golang的Gob等，有些在协议的设计上就考虑了通用性， 使用JSON或者Protobuffer作为数据序列化。
有些框架是基于TCP的二进制流的数据传输，有些基于http的request/response模型进行请求，也有基于http2的流式传输，更有一些支持可信赖的UDP进行数据传入，比如quic、kcp等。
有些提供了生态圈的一些框架，比如gateway、agent等，有些restful风格的rpc框架天然支持API gateway进行负载均衡。
四、工业界的 RPC 框架一览 4.1、国内 Dubbo 。来自阿里巴巴 http://dubbo.I/O/ Motan 。新浪微博自用 https://github.com/weibocom/motan Dubbox 。当当基于 dubbo 的 https://github.com/dangdangdotcom/dubbox rpcx 。基于 Golang 的 https://github.com/smallnest/rpcx
4.2、国外 Thrift from facebook https://thrift.apache.org Avro from hadoop https://avro.apache.org Finagle by twitter https://twitter.github.I/O/finagle gRPC by Google http://www.grpc.I/O (Google inside use Stuppy) Hessian from cuacho http://hessian.caucho.com Coral Service inside amazon (not open sourced) 上述列出来的都是现在互联网企业常用的解决方案，暂时不考虑传统的 SOAP，XML-RPC 等。这些是有网络资料的，实际上很多公司内部都会针对自己的业务场景，以及和公司内的平台相融合（比如监控平台等），自研一套框架，但是殊途同归，都逃不掉刚刚上面所列举的 RPC 的要考虑的各个部分。
个人调研 - 如何选择RPC框架
因为一些需求，所以在不断调研。对RPC也有了更多的了解，实际上RPC通信很多种，从通用性的角度，
http协议毫无疑问是最好的。但是效率上http会携带很多容易信息，所以需要改进。有些如gRPC谷歌开源的是基于http2支持二进制传送，而很多RPC框架都是为了效率自我实现一些协议，这样在解决效率的同时，问题就在于如何支持更多的语言，平台。这就是业界对RPC框架选择的顾虑，可以参考以下文章：thrift基本介绍
而单从效率而言，facebook开源的thrift无疑性能是最高的，参照以下文章： RPC框架的性能比较
thrift支持的语言很多，所以可以作为未来的技术改善点http协议
http协议因为有
keep-live的存在，所以在多请求情况下可以保持一段时间的连接状态，所以连接的握手时间可以忽略，从而性能上差异也不算大。初期从使用方便的角度确实可以