1 注册中心
主要是用来完成服务注册和发现的工作。虽然服务调用是服务消费方直接发向服务提供方的,但是现在 服务都是集群部署,服务的提供者数量也是动态变化的,所以服务的地址也就无法预先确定。因此如何 发现这些服务就需要一个统一注册中心来承载。
2 服务提供方(RPC 服务端) 其需要对外提供服务接口,它需要在应用启动时连接注册中心,将服务名及其服务元数据发往注册中 心。同时需要提供服务服务下线的机制。需要维护服务名和真正服务地址映射。服务端还需要启动 Socket 服务监听客户端请求。
3 服务消费方(RPC 客户端) 客户端需要有从注册中心获取服务的基本能力,它需要在应用启动时,扫描依赖的 RPC 服务,并为其生成 代理调用对象,同时从注册中心拉取服务元数据存入本地缓存,然后发起监听各服务的变动做到及时更 新缓存。在发起服务调用时,通过代理调用对象,从本地缓存中获取服务地址列表,然后选择一种负载 均衡策略筛选出一个目标地址发起调用。调用时会对请求数据进行序列化,并采用一种约定的通信协议 进行 socket 通信。
三技术选型 1 注册中心 目前成熟的注册中心有 Zookeeper,Nacos,Consul,Eureka,它们的主要比较如下:
一致性协议 雪崩保护 多数据中心 自动注销实例
本实现中支持了两种注册中心 Nacos 和 Zookeeper,可根据配置进行切换。
210 通信框架
本实现采用 Netty 作为底层通信框架,Netty 是一个高性能事件驱动型的非阻塞的 IO (NIO)框架。 3 通信协议 TCP 通信过程中会根据 TCP 缓冲区的实际情况进行包的划分,所以在业务上认为一个完整的包可能会被 TCP 拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的 TCP 粘包 和拆包问题。所以需要对发送的数据包封装到一种通信协议里。
Zookeeper CP 无 不支持 支持
Consul CP
无 支持 支持
Eureka AP 有 支持 支持
Nacos CP+AP 有 支持 支持