分布式框架 java_Java分布式服务框架

简述

业界主流(O:Open Source): Thrift(O), Avro-RPC(O), Hessian(O), gRPC(O), Dubbo(O), HSF, Coral Service(亚马逊), DSF(华为)

分布式服务框架包括: RPC组件, 配置化服务发布, 基于服务注册中心的订阅和发布, 服务治理

RPC 组件: 通信框架, 编码, 协议栈

涉及到的技术: Socket 通信, 多线程, 协议栈 -> Netty

关键字: 长连接, NIO(多路复用)

epoll 没有最大连接句柄 1024/2048 的限制, 意味着只需要一个线程负责 Selector 的轮询, 就可以接入成千上万的客户端

可靠性设计靠心跳来实现: TCP 层面的心跳检测(Keep-Alive), 协议层的心跳检测, 应用层的心跳检测

Netty 的心跳检测实际上利用了链路空闲检测机制实现的, 默认为读写空闲(链路持续时间 t 没有接受或者发送消息)

Netty 的 EventLoopGroup 线程组会默认创建 CPU Core * 2 个线程, 使用的时候一定要评估线程数指定, 最好不要使用默认, 或者创建一个数组, 按照 Hash 复用 EventLoopGroup

服务组件: 路由

基于服务注册中心(例如: Zookeeper)的订阅发布机制, 消费者可通过主动查询和被动通知的方式获取服务提供者的地址, 消费者本地也缓存服务地址列表, 当注册中心挂掉时, 仍可向服务发起通信

消费者访问服务的负载均衡: 随机, 轮循, 服务调用延时(消费者缓存服务调用延时, 计算权重, 让延时高的服务接收更少的消息), 一致性哈希

本地路由优先策略: injvm(本地 JVM 中), innative(相同物理机或者VM)

一致性哈希: 希望在增删节点(集群)的时候，让尽可能多的数据不失效, 精华:每个实际节点的N个虚拟节点尽量随机分布在整数环上,增加cache节点时,就能尽量保证移动到新cache节点的key来自于不同的cache节点, 从而保证负载均衡, 即 hash(key) -> 虚拟节点 -> 真实节点

集群容错

什么场景需要容错: 通信链路故障, 服务端超时, 服务端调用异常失败

容错策略: 失败自动切换(Failover), 失败通知(Failback), 失败缓存(Failcache), 快速失败(Failfast)

不同的容错策略适用于不同的业务服务, 容错接口开放使得服务提供者能够按需配置自己的策略

HSF 默认采取失败自动切换的容错

服务调用: 同步, 异步, 泛化

用户发起远程服务调用之后, 经历层层业务逻辑处理、消息编码、最终序列化后的消息会被放入到通信框架的消息队列中

异步实际上是返回 Future 对象, 调用者可以通过 get 阻塞等待获取结果, 也可以通过 Future-Listener 进行回调

泛化调用: 客户端没有API接口及数据模型时, 泛化引用将参数及返回值中的所有 POJO 均用 Map 表示; 服务端没有API接口及数据模型时, 泛化实现将参数及返回值中的所有 POJO 均用 Map 表示; 常用于通用测试