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不是瓶颈。

架构结构：

1. BIO部分：
   1. APIBean
   2. InvocationHandler
   3. Route 路由选址
   4. LoadBalance 负载均衡
   5. Registry
   6. Protocol 序列化 Hessian
   7. Packet  --下面是框架的部分
   8. Serialize 协议编码
   9. ThreadPool
   10. Fram
2. NIO部分
   1. Stream 

IO的区别：

• 阻塞IO
  • Thread的Dump可以看到，等待的IO没有释放CPU，tomcat为每一个请求分配一个线程，优编码简单，维护成本低。适合低QPS。浪费CPU和线程资源。
• 非阻塞IO
  • 线程数一般与CPU核数相等，与请求数量无关，高效利用CPU和线程，适合高并发高QPS。