Pulsar 分布式系统的最佳实践

理论上这些数据是在运行时实时计算的数据，如果对于单机的倒还好说，每次请求这个接口直接实时计算一次就可以了。但对于集群的服务来说会有多个节点，目前 Pulsar 提供的这个接口只能查询指定节点的负载数据，也就是说每次得传入目标节点的 IP 和端口。

所以我的预期是可以提供一个查询所有节点负载的接口，已经提了 issue，最近准备写 Purpose 把这个需求解决了。实现这个需求的方案有两种：拿到所有 broker 也就是服务节点信息，依次遍历调用接口，然后自己组装信息。

从 zookeeper 中获取负载信息。理论上第二种更好，第一种实现虽然更简单，但每次都发起一次 http 请求，多少有些浪费。

第二种方案直接从源头获取负载信息，只需要请求一次就可以了。而正好社区提供了一个命令行工具可以直接打印所有的 broker 负载数据：

分布式系统常用组件提供的命令行工具其实就是直接从 zookeeper 中查询的数据。

在分布式系统中需要一个集中的组件来管理各种数据，比如：可以利用该组件来选举 leader 节点使用该组件来做分布式锁为分布式系统同步数据统一的存放和读取某些数据可以提供该功能的组件其实也不少：zookeeperetcdoxiaZookeeper 是老牌的分布式协调组件，可以做 leader 选举、配置中心、分布式锁、服务注册与发现等功能。

在许多中间件和系统中都有应用，比如：Apache Pulsar 中作为协调中心Kafka 中也有类似的作用。在 Dubbo 中作为服务注册发现组件。etcd 的功能与 zookeeper 类似，可以用作服务注册发现，也可以作为 Key Value 键值对存储系统；在 kubernetes 中扮演了巨大作用，经历了各种考验，稳定性已经非常可靠了。

Oxia 则是 StreamNative 开发的一个用于替换 Zookeeper 的中间件，功能也与 Zookeeper 类似；目前已经可以在 Pulsar 中替换 Zookeeper，只是还没有大规模的使用。Pulsar 中的应用下面以 Pulsar 为例（使用 zookeeper），看看在这类大型分布式系统中是如何处理负载均衡的。再开始之前先明确下负载均衡大体上会做哪些事情。