1. RPC调用过程（实现原理）

rpc组件和基本流程

RPC组成部分和基本流程.png

而RPC框架的实现目标则是将上面的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务

RPC实现原理架构.png

两台服务器AB，一个应用部署在A服务器，想到调用B服务器上的应用提供的方法，由于不在同一个内存空间，不能直接调用，需要通过网络表达调用的语义和传递调用信息，一般分为几部分

1. 建立通信，通过在客户端与服务端之间建立TCP连接，远程过程中调用的所有交换数据都在这个连接传输。可以使按需连接（可建立连接，结束断掉），也可以是长连接（长期持有，配合心跳检测），多个远程调用共享一个连接

2. 服务寻址， 服务端提供机器ip和特定的端口，然后指定调用的方法名和入参出参，能够完成调用。所以说可靠的寻址方式是RPC的实现基石。比如通过zk或者redis来注册服务。

3. 网络传输 序列化与反序列化

4. 服务调用

2. dubbo原理和机制

dubbo 总体分了以上这么几个角色，分别的作用是xxxx。

dubbo服务暴露流程.png

在provider初始化的时候，会通过Config组件中的ServiceConfig读取服务的配置信息，三种形式，XML文件、注解和配置文件（yaml和properties）
在读取配置文件生成服务实体后，会通过ProxyFactory将Proxy转化为Invoker。会通过 proxyFactory.getInvoker，利用 javassist 来进行动态代理，封装真的实现类
然后再通过 URL 参数选择对应的协议来进行 protocol.export，默认是 Dubbo 协议, 此时Invoker会被包转成Exporter
将export得到的 exporter存入一个Map中，供之后的远程调用查找，然后会向注册中心注册提供者的信息。

dubbo服务消费流程.png

服务引入原理

调用某个接口的方法会调用之前生成的代理类，然后会从cluster中经过路由的过滤、负载均衡机制选择一个invoker发起远程调用，此时会记录此请求和请求的ID等待服务端的响应。

服务端接受请求之后会通过参数找到之前暴露存储的map得到相应的exporter，然后最终调用真正的实现类，再组装好结果返回，这个响应会带上之前请求的ID。

消费者收到这个响应之后会通过ID去找之前记录的请求，然后找到请求之后将响应塞到对应的 Future 中，唤醒等待的线程，最后消费者得到响应，一个流程完毕。

关键的就是cluster、路由、负载均衡，然后 Dubbo默认是异步的，所以请求和响应是如何对应上的。

之后可能还会追问 Dubbo 异步转同步如何实现的之类的，在丙之前文章里面都说了，忘记的同学可以回去看看。

可以，启动Dubbo时，消费者会从ZK拉取注册的生产者的地址接口等数据，缓存在本地，每次调用时，按照本地存储的地址进行调用。

random:（默认）随机选取，有利于动态调整提供者权重。截面碰撞率高，调用次数多，分布越均匀。

roundRobin: 轮询选举提供者策略，平均分布，但是存储请求累积的问题。

leastActive: 最少活跃策略。

constantHash: 一致性hash策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者。

Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。
Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。
Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

默认的容错方案是 Failover Cluster。