Netty

Netty是由JBOSS提供的一个java开源框架。Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
也就是说，Netty 是一个基于NIO的客户、服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。
“快速”和“简单”并不用产生维护性或性能上的问题。Netty 是一个吸收了多种协议的实现经验，这些协议包括FTP,SMTP,HTTP，各种二进制，文本协议，并经过相当精心设计的项目，最终，Netty 成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。

Netty 跟RPC有什么关系？
RPC要做到用户无感知的调用远程服务必定要经过网络传输，而netty正好是是Java编写的快速开发高性能高可靠性的网络编程框架。目前使用netty作为传输层的RPC框架很多，国内知名的有dubbo，motan等。下面以新浪开源的motan为例，说明netty在RPC的位置：下图中transport即使使用netty实现的。

总结来说，netty就是解决RPC网络传输的。

分布式RPC需要解决哪些问题呢？
1. protocol：传输协议
2. proxy：client代理，服务引用方调用方法通过代理发送远程消息
3. codec：协议编解码压缩等
4. transport：协议传输
5. registry：注册中心，服务注册服务发现
6. cluster：负载均衡，服务容错策略
7. 其他：服务降级，服务隔离，服务治理

如何实现一个分布式的RPC框架呢？
现在互联网已经很少单点服务了，一个好的rpc框架能帮我们省掉很多工作，那么如何撸一个自己喜欢的RPC框架呢？
现在写rpc框架已经不难了，我们可以有很多参考，很多成熟的第三方开源项目可以依赖，可以说是站在巨人的肩膀上。
第一步，选择传输协议：
高性能的rpc和良好的编码协议是分不开的。好的协议不仅耗用流量小，而且序列化和反序列化更快。
现在比较流行的协议有thrift，protobuf，json，restful等。其中thrfit和protobuf性能都比较优异，而且占用空间小，最重要的是跨语言，具有语言平台无关性。但，美中不足的是他们都需要预先根据协议文件预先生成好代码。开发极不流畅。
我们也可以自定义协议，像dubbo和motan一样，定制自己的私有协议，
比如motan协议的header部分如下：

body部分采用hession或者fastjson序列化，
如果不考虑跨语言，这种算是比较完美的解决方案。

定义协议过程中的一些重要且容易忽略的问题：
• 协议版本号
• 消息id
• 协议扩展字段
第二步，协议传输层
一个高性能RPC框架最重要的四个点就是：传输协议，框架线程模型，IO模型，零拷贝。
java程序如果能做好这四点，那么性能应该不会比c++程序差多少。
而作为java开发者，netty正好解决了后三个点，所以使用netty作为RPC框架的传输层会事半功倍。
第三部，注册中心的选择
现在有很多提供服务注册发现的服务，实现成本比较低就是zookeeper，可以很容易的实现服务注册和服务发现的功能。

解决了这三部，后面的就得脚踏实地码代码了，当然后续会有很多细节，不过都不是问题，现在有好多成熟的开源框架可以参考。

当然也可以参考我最近实现的分布式RPC框架，也欢迎提issue(后续会持续优化)。
自己撸一个RPC还是很不错的，如果有兴趣建议自己撸一遍玩玩。

RPC(远程过程调用)是什么
• 简单的说，RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
• RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
• RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
• RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。

远程过程调用发展历程
• ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
• CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
• DCOM（分布式组件对象模型），COM+
• Java RMI
• .NET Remoting
• XML-RPC，SOAP，Web Service
• PHPRPC，Hessian，JSON-RPC
• Microsoft WCF，WebAPI
• ZeroC Ice，Thrift，GRPC
• Hprose

早期的 RPC
• 第一代 RPC（ONC RPC，OSF RPC）不支持对象的传递。
• CORBA 太复杂，各种不同实现不兼容，一般程序员也玩不转。
• DCOM，COM+ 逃不出 Windows 的手掌心。
• RMI 只能在 Java 里面玩。
• .NET Remoting 只能在 .NET 平台上玩。

XML-RPC，SOAP，WebService
• 冗余数据太多，处理速度太慢。
• RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
• Web Service 没有解决用户的真正问题，只是把一个问题变成了另一个问题。
• Web Service 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。
• 跨语言跨平台只是 Web Service 的一个口号，虽然很多人迷信这一点，但事实上它并没有真正实现。

PHPRPC
• 基于 PHP 内置的序列化格式，在跨语言的类型映射上存在硬伤。
• 通讯上依赖于 HTTP 协议，没有其它底层通讯方式的选择。
• 内置的加密传输既是特点，也是缺点。
• 虽然比基于 XML 的 RPC 速度快，但还不是足够快。

Hessian
• 二进制的数据格式完全不具有可读性。
• 官方只提供了两个半语言的实现（Java，ActionScript 和不怎么完美的 Python 实现），其它语言的第三方实现良莠不齐。
• 支持的语言不够多，对 Web 前端的 JavaScript 完全无视。
• 虽然是动态 RPC，但动态性仍然欠佳。
• 虽然比基于 XML 的 RPC 速度快，但还不是足够快。

JSON-RPC
• JSON 具有文本可读性，且比 XML 更简洁。
• JSON 受 JavaScript 语言子集的限制，可表示的数据类型不够多。
• JSON 格式无法表示数据内的自引用，互引用和循环引用。
• 某些语言具有多种版本的实现，但在类型影射上没有统一标准，存在兼容性问题。
• JSON-RPC 虽然有规范，但是却没有统一的实现。在不同语言中的各自实现存在兼容性问题，无法真正互通。

Microsoft WCF，WebAPI
• 它们是微软对已有技术的一个 .NET 平台上的统一封装，是对 .NET Remoting、WebService 和基于 JSON 、XML 等数据格式的 REST 风格的服务等技术的一个整合。
• 虽然号称可以在 .NET 平台以外来调用它的这些服务，但实际上跟在 .NET 平台内调用完全是两码事。它没有提供任何在其他平台的语言中可以使用的任何工具。

ZeroC Ice，Thrift，GRPC
• 初代 RPC 技术的跨语言面向对象的回归。
• 仍然需要通过中间语言来编写类型和接口定义。
• 仍然需要用代码生成器来将中间语言编写的类型和接口定义翻译成你所使用的编程语言的客户端和服务器端的占位程序（stub）。
• 你必须要基于生成的服务器代码来单独编写服务，而不能将已有代码直接作为服务发布。
• 你必须要用生成的客户端代码来调用服务，而没有其它更灵活的方式。
• 如果你的中间代码做了修改，以上所有步骤你都要至少重复一遍。

Hprose
• 无侵入式设计，不需要单独定义类型，不需要单独编写服务，已有代码可以直接发布为服务。
• 具有丰富的数据类型和完美的跨语言类型映射，支持自引用，互引用和循环引用数据。
• 支持众多传输方式，如 HTTP、TCP、Websocket 等。
• 客户端具有更灵活的调用方式，支持同步调用，异步调用，动态参数，可变参数，引用参数传递，多结果返回（Golang）等语言特征，Hprose 2.0 甚至支持推送。
• 具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
• 兼容的无差别跨语言调用
• 支持更多的常用语言和平台
• 支持浏览器端的跨域调用
• 没有中间语言，无需学习成本
• 性能卓越，使用简单