RPC
Dubbo 阿里2012开源的。和HSF是同一批人开发的。
Dubbo3.0，18年更的。
轻量级+高性能的RPC框架。
HTTP方式调用：服务名和路径
RPC调用：反射，获取服务特征量，方法寻址逻辑，找到正确的服务方。传输借助序列化和反序列化。
Dubbo特性
- 调用远程服务方便，类似Feign，比Feign更简单，不用建接口。
- 内置了负载均衡，只能感知节点的健康状况，显著减少调用延迟，提高吞吐量。
- 有Cluster组件，做集群容错。
- 支持多种注册中心。
Dubbo里的注册中心、Provider和Consumer三者之间都是长连接，借助于Zookeeper的高吞吐量，实现基于服务端的服务发现机制。
因此Dubbo利用Zookeeper+发布订阅模型可以很快将服务节点的上线和下线同步到Consumer集群。
如果服务提供者宕机，那么注册中心的长连接会立马感知到这个事件，并且立即推送通知到消费者。
对于注册中心宕机的情况，Dubbo和Eureka的处理方式相同，
这两个框架的服务节点都在本地缓存了服务提供者的列表，
因此仍然可以发起调用，但服务提供者列表无法被更新，
因此可能导致本地缓存的服务状态与实际情况有别。
核心功能
Registry模块
常用的是Zookeeper，他底层是树形的目录结构，同事支持基于发布订阅模型的变更推送。
zookeeper文档：https://zookeeper.apache.org
长连接
dubbo的注册中心、服务提供正、服务消费者三者之间均是长连接。
注册中心严密监测节点的状态变化。通过长连接感知服务提供者的状态。
服务剔除
当服务提供者出现异常，Dubbo的剔除原理是利用Zookeeper的临时节点和保持会话，。
服务容错
负载均衡
注册中心
zookeeper
Dubbo-Admin
源码
HSF和Dubbo
HSF HighSpeadFreamWork 高速服务框架
目的：作为桥梁连通不同的业务系统，解耦系统之箭的实现和依赖。
高速体现在：底层的非阻塞IO和优秀的序列化机制。
基本结构：
- 服务提供
- 注册中心
- 服务消费
- 规则中心
完成服务发布和订阅后，注册中心就不是强依赖了。
消费者和提供者太多，需要分组寻址，要用到Diomand。
一般一个客户端和一个服务端只有一个长连接，非阻塞IO，IO不是瓶颈。
架构结构：
- BIO部分：
- APIBean
- InvocationHandler
- Route 路由选址
- LoadBalance 负载均衡
- Registry
- Protocol 序列化 Hessian
- Packet --下面是框架的部分
- Serialize 协议编码
- ThreadPool
- Fram
- NIO部分
- Stream
IO的区别：
- 阻塞IO
- Thread的Dump可以看到，等待的IO没有释放CPU，tomcat为每一个请求分配一个线程，优编码简单，维护成本低。适合低QPS。浪费CPU和线程资源。
- 非阻塞IO
- 线程数一般与CPU核数相等，与请求数量无关，高效利用CPU和线程，适合高并发高QPS。