Serverless Eventing：探索 Pulsar 作为 Knative Eventing 的后端详解

最新推荐文章于 2025-11-24 15:13:15 发布
原创 最新推荐文章于 2025-11-24 15:13:15 发布 · 806 阅读 · 14 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#serverless #knative #云原生 #Pulsar

Serverless Eventing：探索 Pulsar 作为 Knative Eventing 的后端详解

在云原生架构中，事件驱动（Event-Driven Architecture, EDA） 已成为构建松耦合、高扩展性应用的核心范式。Knative Eventing 是 Kubernetes 上主流的 Serverless 事件管理平台，它提供了一套标准化的事件模型（CloudEvents）、事件源（Event Sources）、事件通道（Channels）和订阅（Subscriptions）。

而 Apache Pulsar 凭借其高吞吐、低延迟、多租户、持久化和跨地域复制等能力，正逐渐成为 Knative Eventing 的理想后端消息系统（Broker）。

本文将深入探讨如何将 Pulsar 作为 Knative Eventing 的 Channel Backend，实现高性能、可扩展的 Serverless 事件流处理。

一、Knative Eventing 架构回顾

Knative Eventing 的核心组件包括：

组件作用
Event Source产生事件（如 GitHub、Kafka、Timer）
Broker事件入口，接收并路由事件
Trigger定义事件过滤与目标服务（Function/Service）
Channel事件的持久化队列（可选）
Subscription连接 Channel 与 Subscriber 的管道

🔁 事件流路径：

Source → Broker/Channel → Subscription → Trigger → Sink (Service/Function)

其中，Channel 是可插拔的消息中间件，Knative 支持多种 Channel 实现，如 InMemoryChannel、KafkaChannel、PulsarChannel。

二、为什么选择 Pulsar 作为 Knative 后端？

特性Pulsar 优势对 Knative 的价值
✅ 高吞吐 & 低延迟百万级 TPS，毫秒级延迟支持高并发事件处理
✅ 持久化 & 重放基于 BookKeeper 持久化事件不丢失，支持回溯
✅ 多租户 & 隔离Namespace 级配额、ACL多团队/应用安全共用
✅ 跨地域复制Geo-replication多区域事件同步
✅ 灵活订阅模型Exclusive, Shared, Key_Shared, Failover支持多种消费语义
✅ 分层存储冷热数据自动分层长期事件归档
✅ 轻量级 Proxy统一接入、安全网关简化 Knative 集成

🚀 相比 Kafka，Pulsar 更适合 Serverless 场景：更灵活的订阅模型、更低的运维复杂度、更强的多租户支持。

三、Pulsar 作为 Knative Channel Backend 的架构

+----------------+       +---------------------+
|   Event Source | ----> |   Knative Broker    |
+----------------+       +----------+----------+
                                    |
                                    | (CloudEvent)
                                    v
                   +-------------------------------+
                   |   PulsarChannel (CRD)         |
                   |  - Topic: knative-broker-x    |
                   |  - Persistence: Pulsar        |
                   +---------------+---------------+
                                   |
                                   | (Pulsar Protocol)
                                   v
                   +-------------------------------+
                   |   Apache Pulsar Cluster       |
                   |  - Broker                     |
                   |  - BookKeeper (Storage)       |
                   |  - ZooKeeper (Coordination)   |
                   +---------------+---------------+
                                   |
                                   | (Consumer)
                                   v
           +-----------+    +-----------+    +-------------+
           |  Service  |    |  Function |    |  Operator   |
           |  (Sink)   |    |  (Sink)   |    |   (Sink)    |
           +-----------+    +-----------+    +-------------+
  • PulsarChannel：Knative 自定义资源（CRD），由 Pulsar Controller 管理
  • Topic 映射：每个 Knative Broker 对应一个 Pulsar Topic（如 persistent://knative/channels/default-broker）
  • 事件路由：Trigger 通过 Subscription 订阅 Channel，由 Pulsar Consumer 拉取消息

四、部署 Pulsar 作为 Knative 后端

1. 前置条件

  • Kubernetes 集群（v1.20+）
  • Knative Serving & Eventing 已安装
  • Apache Pulsar 集群可用（可本地或远程）

2. 安装 Pulsar Controller for Knative

使用官方或社区提供的 Pulsar Channel Controller：

# 克隆项目（示例：apache/pulsar-knative）
git clone https://github.com/apache/pulsar-knative.git
cd pulsar-knative

# 部署 Controller
kubectl apply -f config/

该 Controller 会监听 PulsarChannel CRD，并自动创建 Pulsar Topic。

3. 配置 Pulsar 连接信息

创建 Secret 存储 Pulsar 连接参数：

apiVersion: v1
kind: Secret
metadata:
  name: pulsar-secret
  namespace: knative-eventing
type: Opaque
data:
  webServiceURL: cHVsc2FyOi8v<base64>    # pulsar://pulsar-broker:8080
  brokerServiceURL: cHVsc2FyOi8v<base64>  # pulsar://pulsar-broker:6650

✅ 支持 TLS、认证（JWT/OAuth2）等高级配置。

4. 创建 PulsarChannel

apiVersion: messaging.knative.dev/v1
kind: PulsarChannel
metadata:
  name: my-channel
  namespace: default
spec:
  persistence:
    pulsar:
      tenant: knative
      namespace: channels
      cluster: standalone
  topic:
    name: my-topic
  retention:
    time: "P7D"  # 保留 7 天
    size: "10GB"

Controller 会自动创建 Pulsar Topic：persistent://knative/channels/my-topic

五、使用 PulsarChannel 创建 Broker

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: default
  annotations:
    # 指定使用 PulsarChannel
    eventing.knative.dev/channel: "messaging.knative.dev/v1:PulsarChannel"
spec:
  config:
    apiVersion: messaging.knative.dev/v1
    kind: PulsarChannel
    name: my-channel

✅ 此 Broker 的所有事件将通过 my-channel 持久化到 Pulsar。

六、定义 Trigger 与事件处理

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: handle-github
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: dev.knative.source.github.push
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: github-handler

当 GitHub 事件到达 Broker 时：

  1. 被写入 Pulsar Topic
  2. Trigger 订阅该事件
  3. 事件被转发到 github-handler Serverless 函数

七、Pulsar 特性在 Knative 中的应用

1. 事件重放（Replay）

  • 利用 Pulsar 的持久化能力，可重新消费历史事件
  • 用于调试、数据修复、新服务初始化

2. 多订阅模型

  • Exclusive：单实例处理（如状态机）
  • Shared：负载均衡（如无状态函数）
  • Key_Shared：按 key 分区处理（如用户会话）

3. 跨地域事件复制

# 在 Pulsar 中启用 geo-replication
pulsar-admin tenants create knative --allowed-clusters us-west,us-east
pulsar-admin namespaces set-clusters knative/channels --clusters us-west,us-east
  • 实现多区域事件同步，支持灾备与就近处理

4. 分层存储（Tiered Storage）

pulsar-admin namespaces set-tiered-storage-threshold knative/channels --size 1G
  • 超过 1GB 的数据自动归档到 S3/GCS
  • 支持长期事件审计

八、监控与运维

1. 监控指标

  • Knative：event_count, event_processing_duration
  • Pulsar：pulsar_broker_topic_backlog, pulsar_producer_rate, bookie_journal_write_latency

2. 日志收集

  • 使用 Fluentd / Loki 收集 Pulsar 和 Knative 日志
  • 关键日志：pulsar-channel-controller, broker, trigger

3. 故障排查

  • 事件丢失？ 检查 Pulsar 持久化、Ack 策略
  • 延迟高？ 检查 Pulsar 写入延迟、GC、网络
  • Consumer 未触发？ 检查 Trigger 状态、Subscription

九、最佳实践

场景建议
多租户环境使用 Pulsar Tenant/Namespace 隔离
高吞吐事件流启用批处理、压缩、多分区 Topic
低延迟处理使用 Key_Shared 订阅，避免排队
生产环境部署 Pulsar Proxy，统一接入与安全控制
Serverless 函数使用 Knative Autoscaler 自动伸缩

十、总结

能力Pulsar + Knative 实现
事件持久化✅ BookKeeper 保证不丢失
高吞吐处理✅ 百万级 TPS 支持
灵活消费模型✅ 多种订阅语义
跨区域复制✅ Geo-replication
长期归档✅ 分层存储
安全隔离✅ 多租户 ACL
Serverless 集成✅ Knative Trigger 自动扩缩容

✅ Pulsar 作为 Knative Eventing 的后端，完美结合了 Serverless 的弹性与消息系统的可靠性，是构建现代云原生事件驱动架构的理想选择。

📌 附：开源项目推荐

Spring Cloud Stream：消息驱动微服务实战
Java大师兄的博客
06-20 549
在传统微服务中，服务间通信多依赖 HTTP 同步调用（如 Feign），但这种方式存在“强耦合”“无法异步”“流量波动时易雪崩”等问题。消息驱动架构（Event-Driven Architecture）通过消息中间件（如 RabbitMQ、Kafka）实现异步通信，能有效解决这些问题。本文将聚焦——Spring 生态中专门用于构建消息驱动微服务的框架，覆盖其核心概念、实战开发、常见问题与未来趋势，帮助开发者快速掌握这一技术。用“快递系统”类比解释核心概念；
【云原生系列】第四讲：Knative 之 Eventing
颜淡慕潇
11-28 5915
Kubernetes 用户在实现开发和部署阶段服务之间松耦合的同时，服务间常要通过不同的事件机制来进行事件传递，为了解决大部分的云原生消息通信需求，Knative 提供了 Eventing 组件。特点：服务开发部署松耦合支持各种事件传递事件的生产者和事件的消费者是相互独立的确保跨服务的互操作性支持第三方的服务对接 Eventing 系统。
云原生开源工具、软件、教程大全。
a1058926697的博客
05-08 2460
云原生开源工具、软件、教程大全
CNCF LandScape Summary
dechen6073的博客
08-18 5032
CNCF Cloud Native Interactive Landscape 1. App Definition and Development 1. Database Vitess:itess is a database clustering system for horizontal scaling of MySQ...
CNCF CloudNative Landscape
dechen6073的博客
04-21 3881
cncf landscape CNCF Cloud Native Interactive Landscape 1. App Definition and Development 1. Database Vitess:itess is a database clustering system for horizontal scaling of MySQL. Apache CarbonD...
CNCF Landscape Summary
dechen6073的博客
05-06 3246
awesome-cloud-native awesome-cloudnative-cn cncf landscape CNCF Cloud Native Interactive Landscape 1. App Definition and Development 1.1Database Vitess:i...
RabbitMQ核心架构与应用
一名80后IT人的成长记录，记录自己在工作、学习中的点点滴滴，在成长的喜悦与忧心的故事里，铭记反脆弱的勇气。
08-15 1244
RabbitMQ作为AMQP协议的实现者，采用Erlang/OTP平台构建，具备高并发和分布式特性。其核心架构包括生产者、消费者、交换器、队列和绑定规则，支持四种消息路由模式：Direct（精确匹配）、Fanout（广播）、Topic（通配符）和Headers（属性匹配）。RabbitMQ通过消息持久化、镜像队列和确认机制确保高可用性，集群部署可实现横向扩展，但需权衡性能与可靠性。Erlang语言的选择使其具备轻量级进程模型和热升级能力，单机吞吐量可达1-2万条/秒，成为分布式系统中高效可靠的消息中间件解决
新一代Serverless平台:Knative在OpenShift上的实践
02-23
Serverless部不是一个新的概念，Knative也不是第一种Serverless平台。以往的Serverless平台，有的不支持K8S，有的虽然支持，但与K8S配合并不紧密。我们知道K8S已经成了事实上的容器云标准，而从K8S到FaaS，需要一个...
云原生Serverless实践：RocketMQ与Knative的结合
Knative作为基于Kubernetes的Serverless平台，包括Eventing和Serving两个核心模块，分别处理事件驱动和工作负载服务。此外，文档还提及了事件源的多样性，如RocketMQ、GitHub、Kubernetes等，以及CloudEvent标准在...
《Serverless架构深度解析：从Knative到Spring Cloud Function实战》
qq_62112907的博客
03-27 522
两大场景，结合Knative Eventing与Spring Cloud Function源码，深度拆解Serverless架构的核心机制。"为什么Serverless能实现毫秒级计费？冷启动延迟如何从10秒优化到100毫秒？传统Spring应用如何零改造迁移到无服务器架构？：通过Spring Cloud Function Web适配层。建议使用GraalVM编译原生镜像优化启动速度。采用Knative多集群部署+统一事件总线。：对接Knative Eventing。：无请求时自动销毁实例（冷启动根源）
K8s 原生 Serverless 实践：ASK 与 Knative
m0_63174475的博客
10-29 218
**Service ** Service 对应 Serverless 编排的抽象，通过 Service 管理应用的生命周期。Service 下又包含两大部分：Route 和 Configuration。 Route Route 对应路由策略。将请求路由到 Revision，并可以向不同的 Revision 转发不同比例的流量。 Configuration Configuration 配置的是相应的资源信息。当前期望状态的配置。每次更新 Service 就会更新 Configuration。 R.
云原生架构2025年趋势：Serverless与边缘计算
2509_93942347的博客
11-24 163
先来聊聊Serverless。更重要的是，Serverless正与事件驱动架构深度耦合，任何数据源的变动、API的调用、消息队列的抵达，都能自动触发相应的函数执行，构建出高度松耦合、实时响应的应用系统。开发者编写一段业务函数，通过工具链描述其所需的运行环境和对延迟、位置的敏感性，平台便能自动、智能地将这个函数分发到全球成百上千个最适合的边缘节点上。从智慧城市的实时交通调度，到全球协作的沉浸式虚拟空间，再到个人化的AI健康助手，其背后都可能由运行在全球边缘节点上的无数个Serverless函数默默支撑。
云原生与Serverless架构在高并发互联网系统中的设计优化与工程实践经验分享
最新发布
2501_94114264的博客
11-24 413
架构设计优先云原生微服务与 Serverless 函数结合，实现弹性伸缩和高可用功能拆分独立部署，提高可维护性高并发优化异步任务、消息队列削峰负载均衡和限流策略保证系统稳定资源管理与弹性容器化 + 自动伸缩Serverless 并发配置和预热降低延迟监控闭环与持续优化日志、性能指标、告警形成闭环持续分析瓶颈，迭代优化函数性能和微服务效率云原生与 Serverless 架构在高并发互联网系统中，通过微服务化、事件驱动、异步任务和弹性伸缩，实现了高性能、低成本、可扩展、易运维的现代互联网基础设施。
TL课堂 - Java架构班第八期（包更新）
2501_94094391的博客
11-22 922
能够清晰地判断，一个复杂的业务系统中，哪些部分适合用传统的微服务（需要常驻状态、复杂内部逻辑），哪些部分更适合用 Serverless Function（事件驱动、短时任务、流量波峰明显）。然而，微服务在带来秩序的同时，也引入了新的复杂性：运维成本激增、资源利用率不佳、以及尽管服务本身“微”了，但支撑服务的中间件和基础设施却变得“重”了。每个服务都可以由独立的团队负责，围绕业务能力进行构建，这是架构领域一次伟大的“解耦”与“分工”。掌握这一进化脉络，你便不仅仅是技术的追随者，更是未来架构的定义者与领跑者。
Serverless架构实践：成本与性能的平衡
2509_93943125的博客
11-23 209
最大的吸引力无疑是成本。最重要的是，我们为关键业务函数设置了定时预热触发器，每隔5分钟自动调用一次，保持函数实例活跃。未来，随着Serverless技术的成熟，特别是容器镜像启动、预留实例等技术的普及，冷启动问题正在逐步缓解。作为技术人，最重要的是根据自身业务特点，找到那个最适合的平衡点——既不让性能拖累体验，也不让成本成为负担。在这个云计算的时代，最聪明的架构不是最先进的，而是最合适的。我们做过测试，在并发请求突然增加时，前几十个请求的延迟明显高于后续请求，这正是系统在扩容过程中不断经历冷启动的表现。
把 Spring Boot 的启动时间从 3 秒打到 30 毫秒，内存砍掉 80%，让 Java 在 Serverless 时代横着走
yu779的博客
11-23 695
摘要：本文实战演示如何通过GraalVM Native Image将Spring Boot 3应用启动时间从2.9秒优化至28毫秒，内存占用降低81%。详细介绍了环境搭建、Native Image编译原理、容器化部署方案，并提供了GitHub Actions自动化构建脚本。测试数据显示，优化后的应用在512MB内存限制下单核可达13K RPS，P99延迟12ms。文章还总结了常见问题解决方案，如反射处理、镜像瘦身技巧等，证明Java在Serverless场景已具备竞争力。
修改knative func build的image
要努力成为很厉害很厉害的人哦
06-12 948
基于func create创建的function的source code，并基于build创建出function对应的image。我们需在该image内创建安装iperf3。
云原生自治网络趋势下基于 Go 构建高性能分布式服务网格通信框架的设计实践与深度优化研究
2501_94058529的博客
11-24 294
服务网格（Service Mesh）作为云原生时代的服务通信基座，为应用提供了“零侵入、强治理、高自动化”的基础能力，而 Go 语言凭借内存安全、高并发与良好网络栈性能，成为当前主流 Sidecar 与控制平面实现语言。随着云边协同计算、eBPF 加速、AI 自适应调度与 FinOps 成本治理不断深入，未来的服务网格将从“通信控制”演化为“自治运行平台”，而 Go 仍将是核心实现语言之一，为下一代分布式系统提供基础技术动力。在实际故障处置中，可结合观测数据实时切换路由策略，实现分钟级容灾。
云原生安全
2509_93947362的博客
11-24 157
先聊聊容器安全这块硬骨头。另外，容器运行时也得盯紧，像Falco这种开源工具能实时监测异常操作，比如突然冒出的特权容器或者敏感目录访问，一有风吹草动就告警。云平台的原生安全工具也得用起来，比如AWS的Security Group和Azure的NSG，规则要最小权限原则，只开放必要端口。说实话，刚开始推行时总有人抱怨流程繁琐，等真防住几次零日漏洞攻击后，全员才意识到：云原生安全就是个持续博弈的过程，今天偷懒省一步，明天就可能全线崩盘。总之，云原生安全没有银弹，它得像编织渔网一样，把技术、流程、文化三层织密。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值