驾驭千级节点——揭秘PUMA大规模集群能力（一） ——需求分析

前言

这个系列的文章主要介绍了大规模PUMA集群的一些内容，包括产品对大规模集群的诉求、业界使用大规模kafka集群的分析、千级节点集群和单集群千万tps的可行性分析、PUMA针对千级节点集群在弹性伸缩上做的技术突破、最后介绍一下在华为企业云上进行大规模集群测试的过程及测试结论分析等等。

PUMA是什么？

PUMA：Portable(Programmable) and Unified Message Architecture，统一开放消息总线，解决大规模分布式应用的通讯问题，保障消息通信高可靠、搞吞吐、高扩展。

什么是大规模集群？

何谓大规模集群？三节点、五节点、七节点算不算，肯定算不上了，那200节点、500节点或者1000节点的集群呢，我认为其实没有一个统一的划分，不同产品对集群规模的支持是不同的；比如redis，通过分槽来实现集群化，槽的总数是一定的，这就导致你不可能去搭建一个千节点的redis集群，因为这没有任何的实际意义除了增加你访问的时延；再比如zookeeper，最终一致性，每个节点上 访问到的数据或者看到的视图都是一样的（可能会出现数据不一致的情况，但最终会同步成一致的），你去搭建一个千节点的zk集群，我只能说过犹不及，集群的写性能会大幅下降，因为你的数据写入了leader后需要同步到所有的Learner(包括follower和Observer)中去，读性能提升也有限，因此业界使用zk集群的规模一般在5节点或者7节点的规模，兼顾了读写性能和容灾备份。

哪些产品能驾驭千节点集群的规模呢？

这里举个栗子：PUMA（统一开放消息总线，技术选型为kafka），其集群的节点间是松耦合的，任意两个节点间的关联很少，增加节点可以线性增加整个集群的tps，而且几乎没什么副作用；通过增加PUMA集群的节点，可以很轻松实现千万tps的消息队列，支持更多的租户和更多的topic（队列）。

产品诉求

这里主要说下某两个产品对大规模集群的诉求，对应大规模集群的两个方面：千级数量节点的集群和千万tps性能的集群

云消息服务

云化场景消息服务，PaaS的基础中间件能力。

如上图所示：

1） ELB需感知每租户到每集群的映射关系，为尽量和ELB解耦。考虑提供消息集群注册发现机制和租户与集群的对应关系，需要ELB进行集成；

2） 多集群下租户订阅服务时集群的创建和已有集群的选择，需要有一个类似资源调度的算法来决定是否创建新的集群还是在某个已有集群里进行扩展；

3） 每个子集群支持多个租户，平均10个租户，100个节点，需要支持多租户及资源的共用或隔离，节点扩展后的消息分布问题；

4） 用户不感知后台架构，订阅服务后直接使用，提供统一的服务规格和SLA（讨论点）。

集群初始化为一个租户的规模（如10个节点），当租户规模增大时，扩展消息集群的规模，按一个租户扩展特定节点的量（如10个节点）扩展。当集群分配满时（即达到100个节点时），则扩展新的集群。

由于多个租户共享一个PUMA集群，需要PUMA提供租户的隔离能力，其主要包括租户创建topic的命名空间的隔离，性能和稳定性的隔离，租户对topic访问的权限控制。

租户与消息集群之间的对应关系，可以是一个租户绑定到唯一的一个集群，也可以是一个租户绑定到多个集群，如果是后者，则需要在上层增加一个租户topic到集群映射关系表。如果租户只能绑定到一个集群，这样随着租户业务量增加以及租户量增加时， 需要消息服务支持大规模集群的能力。当前设计的单集群的最大的规格为100节点，PUMA集群能支持多大规模，需要评估，期望能支持1000+的集群规模；另外，当PUMA集群规模增大时，Rest proxy集群如何扩展，也需要考虑。

云消息服务场景的主要需求：

1） 弹性伸缩：支持PUMA按负载的弹性扩，为云化消息提供基础能力（自动弹性扩容），同时支持当增加业务或应用的topic时，通过弹性扩展避免应用之间的性能影响；

2） 多租户隔离及访问：a.集群内多租户，具备租户认证、授权能力，租户间业务性能和稳定性互不影响；b.具备租户内的用户的认证、授权能力；租户内业务性能和稳定性互不影响；

3） 大规模集群：PUMA提供大规模集群能力，支持1千broker节点的集群规模，以便应对用户的扩容和海量topic的需求。

日志检索

某日志平台主要用于收集业务的各种日志，用于快速定界定位问题，统计分析业务的：质量，容量，监控业务告警等功能。

产品现状：

现网存在的问题：

1、稳定性（异常挂死）、性能不足；

2、Redis非集群，多业务使用暂未统一；

3、ES性能问题（不足以支撑现网的日志量入库和检索）；

基于PUMA的改进方案如下：

整体系统的能力诉求：

1、 每秒需要处理的日志数量: 100~150W/s，2016年底1000W/S的处理能力

2、 每天处理的数据：100~200TB/天，未来具备支撑PB/天量级的能力

3、 保存时间，定位问题:建议一周(日志中枢保留一周，ES集群可以根据业务需要自行设定，Push建议最多一周)

4、 带宽需求：每条消息长度:100~300Bytes  ，以上能力为国内节点业务量诉求

5、查询性能：10分钟以内（查询用户当天的业务数据），30分钟以内(查询用户最近一周的业务数据)

6、全球部署：北京、香港、北美、巴西。中国区各机房分节点部署，对于跨机房部署的，需要考虑策略，对vpn带宽的占用。

该场景主要需求如下：

1） PUMA取代以前的Redis部件，提供消息的日志传输通道；

2） 提供PUMA-ES的数据传送通道；

3） 与Agent/Flume对接，接收Agent/Flume送过来的日志数据；

Agent为C语言开发，这里需要提供RESTFUL接口；

4） 峰值处理能力达到1000w TPS，来应对全业务接入的压力；

小结

两个产品，一个需要部署千级节点集群来应对用户的扩容升级和创建海量topic，另一个需要千万tps来支撑海量日志的传输；归结到一点就是需要puma的单个集群能支撑千级节点的部署和千万tps的性能。

业界分析

PUMA的技术选型为kafka，业界分析这块的话就主要是看一下业界部署和使用kafka集群的规模如何，我这里选取了两组参照物：LinkedIn和青云/Ucloud；众所周知，kafka是由LinkedIn开源的，而且领英公司自己也广泛使用了kafka来做消息通信服务；青云和Ucloud是国内的两个云服务商，其产品中有基于kafka的消息队列服务，也有一定的代表性。

LinkedIn

在LinkedIn的Kafka的系统上，每天有超过8000亿条消息被发送，相当于超过175TB字节的数据，另外，每天还会消耗掉650TB字节数据的消息，为什么Kafka有这样的能力去处理这么多产生的数据和消耗掉的数据，对每一种消息分类是一个重要原因。在每天系统最繁忙的时候，他们每秒接收超过1300万条消息，相当于每秒2.75GB数据。去处理这所有的信息，LinkedIn运行超过60个kafka集群，并在上面部署超过1100个Kafka节点；平均算下来，每个kafka集群内有大概20个节点。

总体来说，由于业务需求的原因，LinkedIn未选择使用大规模的kafka集群，而是通过搭建60+的小集群来实现对业务的全覆盖。

青云/ucloud

QINGCLOUD和Ucloud，这是国内的两家顶尖的云服务提供商，都有使用kafka来提供消息总线服务，从他们的官网和用户手册上可以看到相关介绍，用户创建kafka集群时，集群的节点数量都限制在20个以内，我也注册了相关的账号进行测试，发现在搭建kafka集群时，其集群的节点数量确实被限制在20个以内：

咨询他们的售后客服，问是否可以升级扩容，得到的答复是在20节点以内的集群可以进行扩容，最大扩容到20节点，缩容节点的话需要手动操作，先停服务，再迁移分区，最后下线节点，对运行中的业务有影响；另外，两家均没有提供缩容分区的能力。

小结

通过分析业界使用kafka集群的情况，暂无发现超过100节点的kafka集群使用案例，而且业界所提供的扩容缩容服务都有一定的局限性，要么对业务有影响，要么只能手动操作，要么只能在比较小的集群规模内进行。

华为云计算

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。