共计 2539 个字符，预计需要花费 7 分钟才能阅读完成。
之前分享了如何从 0 到 1 设计一个 MQ 音讯队列，明天谈谈“如何从 0 到 1 设计一个 Dubbo 的 RPC 框架”，重点考验：
- 你对 RPC 框架的底层原理把握水平。
- 以及考验你的整体 RPC 框架零碎设计能力。
RPC 和 RPC 框架
1.RPC(Remote Procedure Call)
即近程过程调用, 次要解决近程通信间的问题，不须要理解底层网络的通信机制。
2.RPC 框架
RPC 框架负责屏蔽底层的传输方式（TCP 或者 UDP）、序列化形式、以及通信细节。
理论应用中，并不需要关怀底层通信细节和调用过程，让业务端专一于业务代码的实现。
国内大家熟知的 PRC 框架，阿里的 HSF 和Dubbo(开源)
Dubbo 的倒退由来
1. 业务规模小
比方晚期一个利用 Java War 包，将所有性能都打包，部署在一个单机服务器，调用接口也比拟不便，不波及到任何分布式场景。
2. 业务规模变大
随着业务的疾速倒退，业务越来越多、子系统也越来越多时。比方：淘宝的交易系统、商品零碎、用户零碎、评估零碎…上百个零碎的呈现。
零碎变得越来越简单，业务代码仍然耦合在一起。比方最晚期的淘宝 denali 工程，蕴含所有业务零碎的代码，就仅打包部署都须要很长的工夫。
并且，随着每个业务线的疾速倒退，业务代码耦合在一起，上线后呈现问题急须要回滚代码，拉分支、大量的代码 merge 工作，这个过程极其苦楚。
这个时候，你会发现技术曾经成了业务的瓶颈，急需把业务独自抽离进去，各自独自部署。
3.Dubbo 和 HSF 的呈现
利用零碎一旦波及到拆分部署，问题就来了，急需一种高效的应用程序间的通信伎俩来实现这种需要，这就会波及到 分布式近程调用。
于是，淘宝就把 denali 依照业务为单位拆分成了相似这样的零碎：UM(UserManger)、SM(ShopManager).. 等等几十个工程代码。
再依照业务为单位，把所有调用相干的接口以业务为单元进行拆分：UIC(用户核心服务)、SIC(店铺核心服务)…等等以业务为单位集群部署，依照业务提供服务。
所以，RPC 的框架来了，阿里外部应用 HSF，以及开源的 RPC 框架：Dubbo。
RPC 框架的外围设计
后面 mikechen 提到了 RPC 的外围指标：次要是解决分布式系统中服务之间的调用问题。
其实，走到这一步波及的常识体系十分的多：要求对通信、近程调用、音讯机制等有深刻的了解和把握，要求的都是从实践、硬件级、操作系统级以及所采纳的语言的实现都有分明的了解。
1.RPC 框架三个外围角色
1)服务提供者（Server）
对外提供后盾服务，将本人的服务信息，注册到注册核心
2)注册核心（Registry）
用于服务端注册近程服务以及客户端发现服务。
目前次要的注册核心能够借由 zookeeper，eureka，consul，etcd 等开源框架实现。
比方：阿里的 Dubbo 就是采纳 zookeeper 实现注册核心。
3)服务消费者（Client）
从注册核心获取近程服务的注册信息，而后进行近程过程调用。
2.RPC 近程调用过程
1）服务调用方（client）调用以本地调用形式调用服务；
2）client stub 接管到调用后负责将办法、参数等组装成可能进行网络传输的音讯体；在 Java 里就是序列化的过程
3）client stub 找到服务地址，并将音讯通过网络发送到服务端；
4）server stub 收到音讯后进行解码, 在 Java 里就是反序列化的过程；
5）server stub 依据解码后果调用本地的服务；
6）本地服务执行解决逻辑；
7）本地服务将后果返回给 server stub；
8）server stub 将返回后果打包成音讯，Java 里的序列化；
9）server stub 将打包后的音讯通过网络并发送至生产方
10）client stub 接管到音讯，并进行解码, Java 里的反序列化；
11）服务调用方（client）失去最终后果。
RPC 框架的指标就是要 2~10 这些步骤都封装起来。
RPC 框架波及技术
1. 建设通信
首先，要解决通信的问题，次要是通过在客户端和服务器之间建设 TCP 连贯，近程过程调用的所有替换的数据都在这个连贯里传输。
2. 服务寻址
1）服务注册
首先须要把服务注册到服务中心。其实就是在注册核心进行一个注销，注册核心存储了该服务的 IP、端口、调用形式 (协定、序列化形式) 等。在 zookeeper 中，进行服务注册，实际上就是在 zookeeper 中创立了一个 znode 节点，该节点存储了下面所说的服务信息。
2）服务发现
服务消费者在第一次调用服务时，会通过注册核心找到相应的服务的 IP 地址列表，并缓存到本地，以供后续应用。当消费者调用服务时，不会再去申请注册核心，而是间接通过负载平衡算法从 IP 列表中取一个服务提供者的服务器调用服务。
3）注册服务
牢靠的寻址形式（次要是提供服务的发现）是 RPC 的实现基石，比方能够 zookeeper 来实现注册服务等等。
- 服务提供者启动后被动向服务（注册）核心注册机器 ip、端口以及提供的服务列表。
- 服务消费者启动时向服务（注册）核心获取服务提供方地址列表，可实现软负载平衡和 Failover。
- 提供者须要定时向注册核心发送心跳，一段时间未收到来自提供者的心跳后，认为提供者曾经进行服务，从注册核心上摘取掉对应的服务等等。
3. 网络传输
数据传输采纳什么协定，数据该如何序列化和反序列化
4.NIO 通信
以后很多 RPC 框架都间接基于 netty 这一 IO 通信框架，比方阿里巴巴的 HSF、dubbo，Hadoop Avro，举荐应用 Netty 作为底层通信框架。
5.服务调用
比方：B 机器进行本地调用（通过代理 Proxy）之后失去了返回值，此时还须要再把返回值发送回 A 机器，同样也须要通过序列化操作，而后再通过网络传输将二进制数据发送回 A 机器，而当 A 机器接管到这些返回值之后，则再次进行反序列化操作
总之，要实现一个 RPC 不算难，难的是实现一个高性能高牢靠的 RPC 框架，如果还想更加深刻理解请查看 Dubbo 源码分析，看看 Dubbo 是如何来解决这些难题。
对于作者：mikechen，十余年 BAT 架构教训，资深技术专家，曾任职阿里、淘宝、百度。
关注作者公众号：回复 【架构】，即可查看 mikechen 互联网架构 原创的 300 期 +BAT 架构技术系列文章与 1000+ 大厂面试题答案合集。