网站新闻标题标题怎样进行优化,如何做国外外贸网站,幸运28网站建设,wordpress 高可用导语
由 StreamNative 主办的 Pulsar Meetup Beijing 2023 在2023年10月14日完美落幕#xff0c;本次活动大咖云集#xff0c;来自腾讯、滴滴、华为、智联招聘、RisingWave 和 StreamNative 的行业专家们一起#xff0c;深入探讨 Pulsar 在生产环境中的最佳应用实践#x…导语
由 StreamNative 主办的 Pulsar Meetup Beijing 2023 在2023年10月14日完美落幕本次活动大咖云集来自腾讯、滴滴、华为、智联招聘、RisingWave 和 StreamNative 的行业专家们一起深入探讨 Pulsar 在生产环境中的最佳应用实践共享 Pulsar 社区的最新发展和动态。
本次 Meetup腾讯云高级工程师林宇强为大家带来了议题为《Apache Pulsar 在腾讯云上的最佳实践》的精彩演讲接下来的篇幅将从系统架构、设计思路、寻址服务、跨集群迁移、跨地域容灾几个方面详细为大家介绍 Apache Pulsar 在腾讯云上的最佳实践。
Pulsar 系统架构
上图是一个很常见的 Pulsar 部署架构ZK 采用了腾讯云 TSE ZK对接内部的配置中心、CICD 平台可以实现标准化部署其余的 Bookie 和 Broker 和开源自建的部署模式差别不大。
这里需要介绍下腾讯云自研部分的诊断三件套MetricsTrace日志采集。
MetricsBroker 自研采集→上报 Monitor 集群 Topic →Pulsar Sink 聚合预处理→腾讯云监控。这里值得说明的是我们在 Broker 和云监控之间加了一层 Pulsar Broker 集群Monitor 集群作为缓冲并使用 Pulsar 自带的 Sink 来进行 Metrics 数据的预处理因为该监控链路是地域级别比如广州地区只部署一套而对外提供业务服务的 Broker 集群数则规模较多总的 Topic 数规模大故而需要中间增加一层来缓解对云监控的压力这是量变引发质变的结果。
TraceBroker 自研采集→Trace 日志→Filebeat 上报→APM这也是演进的结果。原先的架构是 Skywalking 采集→内存排队上报→APM这种架构看似简单但是当 Broker 的流量规模到达一定程度时Trace 产生的速度高于上报的速度导致内存不断增长进而 OOM因此 Trace 最终也是回归原始放弃 Skywalking利用磁盘承受住短时的洪峰。当然也有一部分业务持续高流量造成上报永远追不上 Trace 日志的产生这种情况下也只有两种做法对于对消息轨迹不强求的业务关闭 Trace 上报对于流量大并且对轨迹仍然有要求的只能通过升配的方式调大 Filebeat 的可用核心数硬抗。
CLS日志采集Metrics 和 Trace 由于和 Broker 自身的逻辑有强耦合我们只能针对 Broker 进行定制化开发。但是日志采集是个普适性功能因此我们直接采用腾讯云 CLS 来实现我们的目的日志采集汇总根据环境、地区、集群分类关键字监控日志长时间存档关键字告警等。
Lookup ServiceLookup Service 是个地域级别的模块每个地区只部署一套用于同一个地区所有 Broker 集群的路由、寻址功能这个模块后续会重点介绍。
设计背景及思路
介绍完 Pulsar 系统架构接下来介绍一下我们在腾讯云场景下所面临的问题及解决思路。
● 完全容器化包括 ZK、BK、Broker 以及其他周边设施全部部署在容器平台上。
● 多环境、多地区这是云服务提供商相比常规的业务。我们不仅有测试、预发、线上环境线上环境还有多个地区比如北京、上海、广州、新加坡、香港等每个地区分别有多个集群。
● 多可用区同城多机房云自身自带同城多机房因此可以很方便做同城多活的容灾。
● 集群数量多、Topic 规模大集群数量多、Topic 多这对应的我们要设计标准化部署流程前面讲到的监控链路也是在这个背景下的产物。
● 产品形态多种多样产品形态对应的是部署架构上的差别租户、Broker、Bookie 之间的部署关系。
● 虚拟网络接入方式多样这是云服务提供商必然要面对的多网络平面的问题。
● 支持集群热迁移在客户端 url 不变的前提下将租户从集群1迁移到集群2这也是云服务提供商所需的产品能力比如将一个集群从标准版升级到专业版那么就对应租户和底层物理资源分配上的迁移。
容器化
虽然 Pulsar Broker 可以称作为云原生消息队列但是实际上Broker在运行时是有状态的比如Topic 和 Broker 之间的归属关系。
因此我们在进行容器化的时候整体的思路就是让 Pod 和 VM 尽可能划上等号于是我们做了以下设计
● 固定 IPIP 不会随着 Pod 的销毁重建而随机变化。
● Pod 与 Node 网络拉平针对腾讯云的场景Client 一定不是运行在 Broker 部署的容器集群上如果不拉平的话Lookup 时就得考虑容器网络Overlay和基础网络Underlay之间的映射关系会让 Lookup 变得很复杂。
● 云盘Pod 中挂的数据盘为云盘真正的计算存储分离。
● 与 CVM 共存每个 Pod 独占一台 CVM两者 CPU 和内存参数对等这样能最大程度保证 Pulsar 运行时的物理隔离性当然这也是腾讯云 EKSTKE Serverless天然提供的能力。另外在容器化迁移过程中同一个集群必然存在 Pod 节点和 CVM 节点同时存在因此也需要考虑这二者之间的相容性。
● 优雅停机Pod 销毁时需要确保触发 Pulsar 的 Shutdown 逻辑否则对 Client 来说就会变得强烈感知这也是容器场景和 CVM 场景在 CICD 流程上的差异导致需要注意的地方。
● Liveness probe 调优Liveness probe 也有一个有意思的点由于 k8s 自身的各种健康检查机制其实都是依赖于一个超时时间如果 Broker 启动阶段不能在约定超时时间内返回正确的结果k8s 容易误判为失败造成 Broker 无限重启。举个例子假设某个 Broker 集群有几万个 Topic那么其 Broker 启动时间可能需要耗时90s以上如果 Liveness 设置超时时间低于该值就需要特别注意。当然这也是我们集群规模多导致我们的不同集群可能是不同的业务场景在使用因此很多类似的参数都需要针对性调优。
● Helm 编排Pulsar 的部署步骤其实比较繁杂Bookie 部署、Bookie 初始化、Broker 部署、Broker 初始化以及所需的 Secret、ConfigMap、网络模块等要讲这么多模块有序的编排起来Helm 当然是最好的选择。
Topic 规模大
Topic 数多会引发以下问题
● ZK 元数据过多负载高
● 启动变慢K8s 就绪误判
● Broker 重启爆炸半径大
● Lookup 性能变差
● 监控采集聚合引发质变
产品形态多样 腾讯云 Pulsar 提供多种产品形态对应底层就是部署架构的多样性当然这会对应最终每个实例的售卖价格和腾讯云本身的成本。
● 共享版Bookie 和 Broker 都是共享的本质和一个公司自建一个集群给公司内所有业务团队共用是一个模型共享版下的一个实例对应 Pulsar 的一个租户。
● 专业版Bookie 和 Broker 都是独占的且该集群只有一个租户该租户独占完整的所有物理资源。
接入方式
腾讯云 Pulsar 提供了多种网络接入方式网络接入即 Broker 和 Client 之间的网络连通关系。
内网接入 内网接入在本质上和常规的公司内自建使用类似Broker 和 Client 都处在同一个内网之中且二者之间是完全互通的Client 连接的 IP 也都是 Broker 的节点原始 IP无任何网络转换。
VPC 接入 VPC 即虚拟私有网络每个用户可以创建多个VPC每个VPC下又可以创建多个子网。想了解更多可查看私有网络 产品概述-产品简介-文档中心-腾讯云
两个 VPC 之间通常是无法互通的比如图上的10.0.0.0/8和192.168.0.0/16除非使用云联网、对等连接等 VPC 之间的互通产品但是这个不在我们的讨论范围。
如图所示Broker 部署在10.0.0.0/8而 Client 在192.168.0.0/16那么这时候Client 想要访问 Broker 就变得不可能。
在云网络场景VPC 提供了云虚拟网关仅内部组件来支持两个 VPC 之间的互通我们便称之为跨网络平面互通。
当然其本质就是做网络映射比如
● Broker1在10.0.0.0/8的 IP 是10.2.0.1我们通过云虚拟网关创建 Broker1 在192.168.0.0/16的 IP 为192.168.1.1那么当 Client 在10.0.0.0/8中就需要用10.2.0.1访问Broker1当 Client 在192.168.0.0/16中就要用192.168.1.1来访问 Broker1。
● 由于 Pulsar Client 的连接协议是先 Lookup 后直连的方式这个可以参照后面的 Lookup 寻址时序图就对 Broker 的 Lookup 接口提高了要求Broker 就需要自动化地判定
1. 当 Client 来自于10.0.0.0/8网络返回10.2.0.1
2. 当 Client 来自于192.168.0.0/16网络返回192.168.1.1
这也就是 Pulsar 这个服务在云服务场景所要面对的问题。
公网接入 前面介绍了 VPC 接入其实公网接入和 VPC 接入也是类似的。
唯一的差别是:
● VPC 接入Broker 和 Client 处在两个不同的内网网络平面。
● 公网接入Broker 部署在内网而 Client 来自于公网可以直接把公网看作一个特殊的 VPC 就很好理解了。
寻址服务
下面我们来介绍下腾讯云的寻址服务的思路来源也是寻址服务的价值所在。
RocketMQ 架构参考 我们看下 RocketMQ 的服务其架构分为 NameServer 和 Broker。
● NameServer 保存了集群的元数据Topic 和 Broker 之间的归属关系这样就可以动态地配置 Topic 和 Broker 之间的从属关系也可以将 Topic 在不同的 Broker 集群之间调度。
● RocketMQ 同 Pulsar 一样也有类似 Lookup 的寻址流程只不过 RocketMQ Client 寻址的请求对象是 NameServer而 Pulsar Client 寻址的请求对象是 Broker从这方面看来架构上可以理解为 Pulsar Broker 相当于是 RocketMQ NameServer 和 RocketMQ Broker 结合到了一起。
优缺点
Pulsar 这样做部署架构简单不会额外多出一个 NameServer 服务但是同样也失去了 Topic 在物理集群之间的调度能力。
RocketMQ 虽然多出了一个模块但是其提供的集群调度能力是一种非常重要的运维能力。
这种调度能力恰恰是云服务所需要的有了这种调度能力我们的云服务才能对集群有可运维性和灵活的资源调度方式。
多网络 Lookup 如前面所说在云服务场景针对 Pulsar Broker我们需要提供的内网、VPC、公网三种网络接入场景和 Pulsar Broker 本身提供的 Lookup 能力的矛盾。使用寻址模块便有以下好处
● 将多网络接入这种云服务场景收敛在寻址服务内核中而 Broker 仍然只提供最纯粹的内网服务更好地保持 Broker 的原始能力以及与开源的衔接。
● 动态地增减接入点即不同的网络接入方式的概念名称对于一个 Pulsar 集群来说增加、减少一个内网、VPC、公网接入点时不需要对 Broker 做任何变动。
● 实现扩缩容的自动化和无感知化Broker 的扩缩容等同的也需要对该集群的所有接入点中的网络映射进行扩缩容变更由于寻址模块的存在这部分全部收敛在该模块Broker 的扩缩容不需要对存量节点做任何变动。
Lookup 时序 前面介绍了很多寻址模块和寻址流程这里来重点介绍下 Pulsar-Client 的寻址时序来补充下对前面的介绍以及科普下 Pulsar Client 的机制
● 第一步获取 Topic 分区数Client→CLB→Broker一对多指的是该请求落到 CLB 后面的任意一台 Broker 都能对等返回正确结果。
● 第二步单分区 Topic Lookup针对单个分区进行 Lookup询问该 Topic 当前的 Owner Broker 地址同样是一对多不同 Broker 之间提供对等服务。
● 第三步基于第二步返回的该 Topic 分区的 Owner Broker 地址进行直连随后进行消息收发。一对一特指此时的直连必须精准连接 Broker 集群中的某台 Broker比如 Broker-2连接别的 Broker 则会连接失败。
这就是 Pulsar-Client 初始化一个 Producer/Consumer 的步骤。
我们的寻址模块切入点在哪呢
就是第一和第二步如图所示在这两个步骤中间加入一层代理层这样就可以在寻址返回结果上针对多网络接入、Topic 和物理集群从属关系调度上做一些篡改以达到我们的目的。
集群间调度 上图是我们加入寻址模块后Pulsar 架构上的改变整个架构就变得和 RocketMQ 有点类似有一个中央元数据服务用来管理 Topic 资源和物理计算资源之间的关系。
跨集群迁移
前面铺垫了这么多介绍了寻址模块以及架构上的优化接下来介绍下在此之上我们所做的产品化能力——跨集群迁移。
跨集群迁移特指一个租户从物理集群1迁移到物理集群2两个集群同时提供服务在线热切换Client 轻微感知。
如图所示整个流程也很简单寻址服务保存了租户和物理集群的路由关系路由关系一变更即集群迁移变更。 基于 Pulsar Lookup 寻址的协议路由关系的切换粒度可以做到租户粒度、Namespace 粒度、Topic 粒度、分区粒度。
切换的方式路由切换Topic unload
机制上来说这个切换流程很简单难点在前置准备工作上
● 元数据迁移租户、Namespace、Policies、Topic、订阅、Token 等。
● 消息双向同步切换过程中两个集群同时提供服务为了提供可回滚能力发送的消息需要在两个集群之间双向同步保证两个集群都有完整的所有消息。
● 进度同步每个 Topic 的订阅消费进度不同需要定时同步尽量较少切换过程中的重复消费。
消息同步
消息同步比较简单我们采用了 Pulsar 自带的 GEO-Replicator 功能这里不再赘述。 进度同步
这里简单介绍下进度同步的机制。
1. 消息迁移在消息同步阶段GEO-Replicator会在消息头部携带消息的源集群里的消息 IP。
2. 定时同步定时将源集群的消费进度同步到目标集群基于 Compact topic 同步和持久化。
3. 进度缓存目标集群读取 Compact topic 中的消费进度信息将消费进度加载到内存。
4. 投递过滤在 Pulsar 的投递流程 Dispatcher 处理过程中过滤掉本要投递但是已经在源集群进度中投递过的。
跨地区容灾
跨地区容灾也是我们基于寻址服务的架构改进后所开发出的产品化能力。
本质和跨集群迁移类似但是由于跨地区的网络时延问题在侧重点上有所不同 如图所示假设我们的 Pulsar 实例在广州地区Client 也在广州地区但是由于不可抗力导致广州地区的 Pulsar 实例全部宕机并且短时间内无法迅速恢复我们可以暂时将 Client 的流量切到上海地区的容灾实例来保证 Client 在线业务的迅速恢复。
● 同一时间只有一个集群提供服务。
● 短时间、临时性切换由于跨地区时延的不可控特别是国外地区容灾机制一定是临时的待广州地区恢复后理应尽快将流量回切。
● 元数据定时同步因为我们无法预测广州集群何时宕机且该场景的使用频度较低这是一种权衡的结果。
● 消息、进度不同步面对的是广州集群全部宕机此时广州集群磁盘中的数据暂时无法读取另一个原因就是跨地区时延大做实时消息同步的性价比太低。
● 切换基于域名解析切换因为广州和上海的寻址服务互相独立隔离这个时候如果广州集群有堆积那部分只能继续堆积着等广州地区恢复了才有机会重新消费。
● 回切由于上海集群只是用来紧急容灾在广州集群恢复后必定要重新切回广州回切的过程中比较重要的就是上海集群上堆积的消息需要回写到广州这个过程中不可避免会出现一部分重复消费和消费顺序错乱同一分区内。
该方案是面对地区级别灾难场景下的容灾因为每个地区本身已经是多可用区部署同城多机房因此整个地区不可用的概率较低因此跨地区容灾的整个产品设计侧重主要用于应急而不是为了像跨集群迁移一样的热切换需要做到非常严格的双向同步。
总结
我们先从腾讯云 Pulsar 的整体架构讲起介绍了在腾讯云的场景下所需要面对的问题引出了寻址模块Lookup Service并介绍了寻址模块的引入对于 Pulsar 的部署架构上的优化。随后介绍了 Lookup Service 解决的两个核心问题多网络 Lookup 和集群间调度并保证对客户端接入的无感知和对架构的低侵入性。由于寻址模块的存在我们便能基于它做进一步的产品化能力跨集群迁移和跨地区容灾从而能够在不同级别的灾难场景下都能提供相应的修复措施和运维能力。
未来我们还会继续在容灾能力、Pulsar 周边生态对接、存储优化等方面继续努力以提供成本更低、稳定性更高的 Pulsar 产品。
