共计 5205 个字符，预计需要花费 14 分钟才能阅读完成。
**
导语
2022 腾讯寰球数字生态大会已圆满闭幕，大会以“数实翻新、产业共进”为主题，聚焦数实交融，摸索以全真互联的数字技术助力实体经济高质量倒退。大会设有 29 个产品技术主题专场、18 个行业主题专场和 6 个生态主题专场，各业务负责人与客户、合作伙伴独特总结经验、凝固共识，推动数实交融新倒退。
本次大会设立了微服务与中间件专场，本专场从产品研发、运维等最佳落地实际登程，具体论述云原生时代，企业在开发微服务和构建云原生中间件过程中应该怎么少走弯路，聚焦业务需要，助力企业倒退翻新。
随着大数据时代的到来，企业在生产和经营流动中产生的各类数据正以前所未有的速度增长，通过对实时及历史数据的交融剖析，及时开掘业务洞察和辅助决策，已成为企业的广泛口头。在云原生的浪潮下，企业须要聚焦业务，迫切需要简单易行，零代码地配置搭建起本人的能够达到将本增效成果的数据链路零碎。
本篇文章将从以下几个方面来跟大家一起分享 Pulsar 在腾讯的实际中遇到的问题和挑战以及对应的解决方案。
● 音讯队列倒退历史
● 开源计划可能面临的问题和挑战
● 咱们的摸索与解决方案
● Pulsar 在腾讯外部的案例实际
● TDMQ 将来布局
音讯队列倒退历史
下图是开源社区整个消息中间件产品，从 2003 年诞生的 ActiveMQ 到 2012 年 诞生的 Pulsar 的整个倒退过程。
在这个倒退过程中，不同的产品解决了各种各样不同的问题。下图是各产品之间的比照，大家最关注的是在线音讯和离线音讯，当初业界比拟通用的会把 Kafka 用在离线音讯上，在线音讯更多采纳的是 RocketMQ。RabbitMQ 可能在扩展性上存在一些差别，然而它简略易用，历史也更悠久。规模决定了这些音讯产品的扩展性如何，是否反对十万或者百万的音讯 Topic 的量级，下表中对最小规模也做了具体比照。
Pulsar 诞生的背景和起因
看了以上那么多音讯产品的比照，大家必定会有一个疑难，既然曾经有这么多的音讯产品了，为什么还要用 Pulsar？Pulsar 它存在的意义是什么呢？基于 Pulsar 研发人员本人的教训以及社区的背景，Pulsar 有三个值得关注的倒退方向：云原生环境适配、多租户和海量 Topic、离在线流批一体。
云原生环境适配
● 计算与存储拆散的架构，对于原生的 K8s 或者容器化的环境是更加敌对的，人造适配云原生环境，不同的组件能够离开扩大。
● 基于对机器容灾的思考，反对跨 Region/ 机架数据写入。
● 对于普通用户，能够不便的应用开源的 Operator 在云环境间接部署，真正的服务于业务。
多租户和海量 Topic
● 人造反对多租户，Namespace 和 Topic 级别的权限治理，能够做共享大集群。
● 设计层面反对海量 Topic，对于有这类需要的用户有比拟强的吸引力。
离在线流批一体
● 在系统维护层面，All in one 的吸引力。
● 对业务只须要保护一套中间件即可实现流批一体。
● Kafka 等 Connector 的存在，迁徙不便。
广泛状况下离线会采纳 Kafka，在线会采纳 RocketMQ，但实际上，很多用户或者很多基础设施的同学团队，更心愿有一款产品可能把离线和在线联合起来，具备 All in one 的能力。Pulsar 在设计之初就是有这样的考量，也参考了前者的一些劣势。
Pulsar 的整体架构
上图左下角的局部能够看成一个整体，是 Pulsar 的一个 Broker 集群，也就是后面介绍到的计算节点，右侧 Bookeeper 是 Pulsar 的存储节点，也就是存算拆散中的存，Zookeeper 是 Pulsar 元数据管理核心，这是整个分布式的部署环境。大家能够看到整体的架构包含三个局部：
● 2Broker+3Zookeeper+3Bookeeper，这是一个最小集群构造。
● 多语言 SDK，Java/Go/C++/Node，对应的是上图的上半局部，Pulsar 当初多语言 SDK 也是比拟丰盛的，用的最多的就是 Java/Go/C++/Node 等。
● 一些 Manager 的管控 UI，这部分在社区绝对不是特地欠缺。
开源计划面临的问题和挑战
开源计划面临的问题
管控面：
1、元数据资源的权限治理，如何划分不同的用户和不同的权限。
2、当一个集群超过肯定的规模，海量 Topic (3w 分区)的状况下，策略更新对管控稳定性产生影响。
3、用户对元数据 (Topic 等) 进行治理呈现问题, 比拟难以定位，没有操作轨迹。
数据面：
1、在线音讯生产限流之后，客户端无奈明确感知，对生产稳定性有影响。
2、不少配置项短少动静能力，进行更新时须要重启 Pulsar。
3、不同网络环境上面，ListenName 的网络计划扩容不敌对。
4、呈现音讯空洞时，无奈主动复原。
5、如果集群容量有余，如何将用户从一个集群无缝迁徙到另一个集群加重集群压力
可观测性：
1、海量 Topic 的数据指标上报，Promethus 一次性产生几十 MB 数据，对 Broker 有较大性能影响。
2、服务端音讯轨迹，服务提供方和用户侧无奈对一条音讯的轨迹进行追溯。
3、针对简单的生产问题，无奈提前发现，如 Unack 导致 Backlog 沉积。
基于以上三个方面的问题，开源计划遇到的挑战也有三个方面：
● 百万级 Topic 撑持，如何保障性能和稳定性？
● 生产级运维要求，如何疾速预警排查定位问题？
● 多业务场景共享，如何精细化平安管控和治理？
咱们的摸索与解决方案 - 管控面
存在问题：
1、性能：对 Broker 能接受什么样的量级要有感知，感知起源不能是一般的压缩数据，比如说大家从开源社区里看到的一些指标在以后的场景下适不实用要存疑，频繁操作资源会导致 Broker 不稳固。
2、稳定性：在局部场景下，当 Topic 数据很多，或者运行工夫足够长，会存在肯定的 Zookeeper 元数据透露，元数据会越积越多，因为目前 Pulsar 版本对 Zookeeper 有强依赖，所以如果 Znote 有限增长，那么最终对稳定性有极高的影响。
3、可运维性：当资源呈现不合乎预期的场景时，无奈追踪每次申请的信息。
解决方案：
● 性能优化：Broker 操作资源性能优化 + 专享压测保障 + 生产大规模集群验证，保障能够反对操作元数据 1000TPS 长时间运行没有问题；
● 针对稳定性影响的问题，做了运维管理系统，能够观测 Znote 的增量，晓得哪些增量是不合乎预期的，能通过和 Broker 元数据做比对，校验元数据是否有逻辑问题，不该增长，便于自助勘误与运维；
● 元数据存储标签，对预先数据分析提供反对；
● 资源管理轨迹，保障每笔资源操作信息可查。
咱们的摸索与解决方案 - 数据面
当把管控面的问题解决之后，生产更多要关注数据面的稳定性问题，数据面的稳定性其实就包含两局部生产和生产。
存在问题：
1、生产生产问题：限流场景用户无奈感知，空洞音讯的问题，可能须要重启或者服务端去帮用户做 Unload 的操作。
2、网络计划：用户通过 ListenerName 的形式接入存在肯定的感知，但须要扩容的时候运维不够灵便。
3、性能稳定性：Pulsar 里有缓存的概念，那么缓存的有效性命中率有多高，在共享的场景下
须要做判断或者压测，须要做缓存的集中式的治理，包含对整个 Pulsar 存储局面 BK 的一些稳定性的优化。
4、可运维性：不少配置项须要重启 Broker 机器失效，在运维场景下不够敌对，对在线音讯的场景影响较大，用户音讯的轨迹无奈确认，但对离线场景感知不显著。
解决方案：
● 反对空洞音讯的被动推送，Pulsar 在服务端能感知到空洞音讯，因为 Pulsar 有一个记录，是曾经被确认的音讯的汇合，这样在服务端去判断空洞音讯的时候就是看它在服务端是否超过了用户配置的工夫，比方，用户认为拿到一条音讯到生产完最多须要 10 秒，那么就能够 10 秒检测一次，如果发现这个音讯在空洞音讯列表里存在了 10 秒，Pulsar 就会被动推给用户，解决用户单机常见的问题。
● 生产限流的场景下，Pulsar 也反对 Failfast 的逻辑，如果你被限流了，能够把限流的异样间接返回给用户，这样的话用户也就能够很快的晓得这个场景，他能去做对应的逻辑解决。
● 通过泛域名的调配与解析，解决用户须要指定 listenerName 的问题，晋升前期的运维灵活性；
● 反对 OHC+LRU 的全局缓存策略，修复 BK 稳定性 Bug Fix，性能和稳定性会有较大晋升。
● 对于可运维性上的配置项问题，其实社区目前的动静配置次要是基于 ZK 的，当你的代码层面上反对了动静配置，你能够通过去操作 Pulsar 的动静配置的命令将这个数据写入 ZK，而后 Broker 会监听到 ZK 的变动，而后去更新内存的这种配置，这样的话，首先须要去做一些代码层面的改变，动静运维的货色都要动静调整，这外面包含负载平衡的比例、策略等，社区前面也会对 ZK 做一些相应的替换，咱们更心愿与运维相干的动静配置有一个通用的中央去存储，代码级别反对 Apollo 动静配置，包含腾讯云外部的动静配置。这样对于运维管控就不依赖于 ZK 的稳定性。
● 在音讯轨迹层面，在 Broker 的代码层面，做了一些 Feature。就是当用户发送音讯的时候，咱们会把用户发送音讯的客户端的起源 IP、音讯 ID 以及发送音讯的耗时等这些信息，记录下来组成一笔轨迹；当这条音讯被生产的时候，也会记录一条轨迹，包含哪一台客户端，哪一个 Consumer 去生产；当用户把这条音讯真正去 Ack 的时候，也会做相应的轨迹，最终会出现给用户一个产品化的货色，当用户发现某一笔音讯没有被失常生产的时候，他能够拿音讯 ID 来运维管控端查问，咱们会通知他这个音讯有没有被推过，推了几次，目前这个音讯在哪里。
咱们的摸索与解决方案 - 可观测性
存在问题：
1、海量 topic：exporter 造成频繁的 gc；
2、broker 轨迹：生产生产，资源管理服务端无轨迹；
3、监控报警：须要用户配置一套报警零碎和规定；
4、指标简单：如何无效监控预警
解决方案：
● 信息被动上报：当 Topic 很多的时候，当 Brocker 上有 3 万分区的时候，每次 Promethus 去拉取用户的指标时，须要产生一个 String 的数据，这个数据须要一次性报给 Promethus，通过咱们的判断，可能会呈现几十兆，上百兆的数据，这样一分钟拉取一次，对服务端的 GC 压力十分大，服务端的性能就会降落的比拟显著。如果把拉的形式改成推的形式，在代码层面，周期性的把内存中的这种数据做拆分，比方每 5 个 Topic 上报一次，咱们在服务端做这样的聚合，益处在于，把一次性的这种数据变成了相似于流的解决，这样的话，性能和稳定性也会有较大的晋升。
● 全链路跟踪，反对音讯轨迹和资源管理轨迹。
● 精细化监控，对接云监控与报警零碎，反对精密的监控与报警。
● 自动化巡检：社区的版本，指标是比较完善的，咱们能够通过各种各样的指标来判断服务端目前的衰弱状态，包含用户的生产状况，真正用户应用的状况下会发现一些问题，次要起因是指标的确很多也很简单，对用户来说，他要了解这个指标，并且通过这个指标来判断本人的问题，是比拟艰难的，腾讯云 TDMQ 做了自动化巡检，针对简单的指标有效性问题，通过自动化巡检零碎，被动触达用户。
Pulsar 在腾讯外部的案例实际 - 王者营地
王者营地 App 对用户的登入登出状态，组队状态，房间状态，局内高光数据，击杀数据等用户的生产状态，生产到 Pulsar 集群，这些行为的生产方会在 Pulsar 外面去生产，通过 TDMQ Pulsar 削峰填谷，以及 Shared 的订阅模式，进行音讯的散发。如果不必音讯的话，下图左侧的生产方，须要感知他所有的生产方，并且对所有的生产方做一次 RPC 的调用，老本较高。包含很多音讯不是须要实时性的，通过削峰填谷能够缩小业务的压力。上面是一些实际状况。
● 通过不同的 Topic 后缀来辨别不同环境。
● 因为业务上过期数据能够不生产，因而设置了 2 小时的 ttl 过期工夫。
● 客户端应用 Golang pulsar sdk。
● 吞吐量级：十万级生产，十万级生产。
基于以上场景，腾讯云在生产商举荐用户应用最多的是 Java 和 Go 的 SDK，同时也更举荐用户们应用 Shared 的订阅模式，包含 Namespace 的策略上，也更倡议用户依据本人的场景来决定是不是须要生产过期，是不是须要设置一些音讯保留的机制，不便用户前期的一些回溯。
TDMQ 将来布局
后面介绍了很多，大家在本人的理论应用场景中，不论是自建还是做开源社区的开发，或者是本人公司外部应用 Pulsar，如果大家遇到以上相似的问题，都能够参考以上的优化计划或者去跟进社区的新版本，腾讯云开发的 Pulsar 也会尽量跟社区保持一致，并奉献给社区。后续也会在以下几个方面做更多的致力。
● 反对依据业务 ID 的音讯轨迹查问
● 加强经营管控端业务可了解的指标丰盛度
● 运维测反对音讯生产生产问题诊断
● 优化大规模超长提早音讯
● Broker 动静配置能力反对，反对灰度配置变更 **
