消息队列上云挑战与方案：腾讯云的 Apache Pulsar 云原生大潮风起云涌

云原生大潮风起云涌，企业不再停留在理念层面，目前已在多方面落地。消息队列作为关键技术基础设施之一，也在云原生时代面临着挑战和机会。本文从传统消息队列上云所面临的三大挑战说起，并以ApachePulsar为技术案例，深入浅出地讲解了如何打造适配云原生的消息队列。希望本文能对大家提供参考。
1背景介绍
如今，云原生的概念已经渗透到了软件开发的方方面面。云原生不再只是未来的设想，而是一个现在进行时。开发人员在开发设计之初就需要考虑未来如何在云原生环境上部署、运行服务，即如何“上云” 。
在云上，消息队列将成为一种基础设施，像自来水一样，可以随时按需使用，并且有无限容量。用户无需关心消息队列的型号、规格，或是否需要升级配置，只需专注上层业务。
腾讯云是腾讯集团倾力打造的云计算品牌，面向全世界各个国家和地区的政府机构、企业组织和个人开发者，提供全球领先的云计算、大数据、人工智能等技术产品与服务，助力各行各业实现数字化升级。为了更好地为广大用户服务，提供金融级可靠消息服务，腾讯云开启了消息队列上云之路，目前ApachePulsar在腾讯云上已经大规模使用。
2传统消息队列上云遇到的挑战
消息队列在上云过程中遇到了很多新的挑战，比如如何平滑扩容、如何管理海量分区、如何保证异地多活等高可用性。
挑战一：平滑扩容能力不足
传统消息队列（如Kafka等），在平滑扩容方面存在很多不足，很难做到快速、无感知地扩容。由于Kafka的数据保存在Broker上，而每个Broker上的分区数据是有状态的，因此每个Broker上数据可能不同，客户不能通过简单地增加Broker数量完成扩容。当集群增加新Broker进行扩容时，会涉及数据迁移和同步，进而引发磁盘IO和网络消耗。当流量突然爆发，业务本身使用IO和网络带宽就会很高。此时，如果由于集群容量不足而触发扩容，迁移的带宽占用和数据冷读会直接影响到上层业务的使用，造成高延迟和错误率飙升。如果写入的速度比迁移速度更快，那可能永远都无法完成数据迁移。
此外，通常20%的客户占用了80%的流量，有些用户对底层消息队列并不熟悉，使用方式可能不规范，导致Broker端出现数据倾斜，很容易造成某些节点的磁盘占满，而其他节点的磁盘有比较大的空间。只采用简单扩容、迁移数据的方式根本无法解决这种情况。
挑战二：海量分区管理无法承载
有些用户的业务比较特殊，单个分区的流量不大，但总体使用的分区数很多。现有的一些消息队列，很难承载海量的分区，例如：如果一个Kafka集群分区数太多，当出现Leader或者Controller切换时，恢复时间会很长。另外，如果不使用SSD ，文件写入变得分散，可能出现复制跟不上，导致ISR（In-SyncReplicas ，副本同步）频繁波动等。
为了解决上面这个问题，通常我们会为每个用户部署一个集群，保证每个集群的分区数不会过多。但由于每个集群总流量不大，会造成集群资源使用率不高，有大量闲置资源，无法发挥云原生环境的优势。
这种情况下，最理想的方式是多个用户共用一个集群的资源，分别限制资源的使用量，避免出现资源浪费。但如果把所有用户全部聚集起来放在同一个集群运行，又可能会出现几十万、上百万分区数问题，这就是我们的第二个挑战——海量分区管理。
挑战三：无开箱即用的异地多活解决方案
很多金融级用户的业务场景对高可用、RTO（RecoveryTimeObjective ，业务恢复时间）等指标要求非常高，因此需要同城多机房或者两地三中心的异地多活的方式。对于强一致的异地多活，现有的消息队列很少有提供开箱即用的完整方案。