手写RPC框架，了解Dubbo底层原理

一、为什么需要学习RPC框架呢？

目前的互联网项目都要面临高并发的考验，传统的单体项目不可能支撑的了那么高的并发，因此，分布式架构成了互联网项目（大型项目）的首选，但是分布式架构也会存在缺点，因此需要通过各种技术栈去解决这些存在的缺点。

先简单的分析一下分布式的优缺点：

描述：把一个复杂的大型的项目按照业务来拆分成多个小项目，每个项目独立部署，每个小项目都会对应自己的业务库。

优点：

①每个小项目功能单一，运行速度快

②每个小项目开发和迭代的周期变短，每个项目则负责的人数更少，3-5个人即可组成一个小项目组

③技术选型比较灵活，不局限于某种开发语法

④承受更高的并发量，每个原来一个项目承受的项目摊分到不同的项目身上

缺点：

①协同比较麻烦，项目之间调用，项目组需要沟通和协调，更加考验项目Leader的管理能力

②技术变的复杂，集成更多的技术栈，对开发人员的要求变的更高

③架构变的复杂，项目之间的互相依赖，很难完全掌握整个项目的架构、技术栈

④工程数量变的庞大，部署变的麻烦，后期上线运维、监控、异常定位等等都很麻烦

大型分布式架构面临的问题，大致如下：

①服务之间通讯问题

②快速部署问题

③日志文件的收集、快速定位异常问题

④性能监控、链路追踪问题

⑤分布式事务问题，分布式架构一般采用的是弱事务性（数据最终一致性），根据CAP理论，一般采用最终保持数据一致性

⑥安全性问题，比如：限流、容错、接口幂等性

⑦集群部署、集群高可用

对应分布式架构来说，其实最急需解决的问题应该是服务的调用，那么服务之间的调用有哪些解决方案呢？

①WebService，基本上现在很少使用了，它是基于soap协议+xml的方式

②Http协议，比较轻量级，但是服务治理问题很难解决

③MQ消息队列，一般用于服务解耦，提高性能，不适合做业务接口的远程调用

④RPC框架，很多大公司都会自己研发自己的RPC框架，但是目前中国范围内很多企业都会直接使用阿里开源的Dubbo服务治理框架。

那么服务治理需要功能包括哪些呢？

其实服务治理就是服务之间的调用，但是调用的时候，必须解决一些特殊的问题，比如：负载均衡、服务容错、动态感知、地址管理。

问题描述：商品服务，迁移到别的服务器了，那么订单服务请求失败，需要手工修改服务地址，重新打包、部署。

服务治理：动态感知和地址管理问题，订单服务没有很好的感知商品服务的迁移，同时服务地址以硬编码的方式存在项目里面。

解决思路：①订单服务如何管理商品服务的地址呢？应该把它移交给第三方去维护。②订单服务如何感知商品服务迁移了呢？应该独立一个介质，通过心跳检测来监听所有的服务的状态

问题描述：一旦商品服务宕机了，那么订单服务每次都会发起请求，并且每次都请求失败

服务治理：服务容错和动态感知问题

解决思路：①一旦感知对方宕机，则停止调用；②进行容错，比如：连续调用三次都失败，则停止调用，等商品服务恢复启动，订单服务感知之后再继续调用

问题描述：如果商品服务部署多个，那么订单服务无法确定需要调用哪个服务

服务治理：负载均衡问题

解决思路：通过编写负载算法来选择一种一个服务调用

二、RPC的架构思想

思考：那么如何设计一个RPC框架来满足我们的需求呢？

架构简单分析

①服务提供者工程，在项目启动的时候，扫描某个包下面，含有某个注解的类，获取其接口信息注册到Zookeeper上面。

②如果服务提供者集成部署，可以把Zookeeper看做Map<String,String[]>的格式，那么key=接口的名称，value值是不同服务器地址的集合

③服务消费者工程，调用接口的时候，通过动态代理来生成一个代理类

④代理类注意实现以下功能

4.1）根据接口名称去获取对应的服务地址（String[]）

4.2）通过负载算法选取其中一个地址

4.3）根据地址发起远程调用（调用方式，可以是基于Netty、Socket、Http去实现）

三、RPC的实现

架构简单分析：

①其实根据上面画的架构图还是比较容器理解的，就不再文字描述了

RPC的Demo源码：https://gitee.com/zwyyf/rpc.git

慕课网专栏：https://www.imooc.com/read/73