作者 | 元毅阿里巴巴高级开发工程师

想必大家都比较了解 RocketMQ 消息服务，那么 RocketMQ 与 Serverless 结合会碰撞出怎样的火花呢？我们今天介绍一下如何基于 RocketMQ + Knative 驱动云原生 Serverless 应用。本文主要从以下几个方面展开介绍：

云原生与 Serverless
Knative 简介
RocketMQSource
餐饮配送场景示例

云原生

先看一下 CNCF 对云原生的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

其实云原生旨在以标准化云服务的提供方式衔接云厂商和客户。这种方式对于客户而言降低了上云和跨云迁移的成本，让客户始终保有和云厂商议价的能力；对云厂商而言，因为客户跨云迁移的成本低，所以只要能提供性价比更高的云服务，就能很容易的聚集大量用户。

Serverless

Serverless（无服务器架构）是指服务端逻辑由开发者实现，运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。

Serverless 可以理解为云原生技术发展的高级阶段，使开发者更聚焦在业务逻辑，而减少对基础设施的关注。

这里提到的是 Functions Serverless, 其实除了 Functions Serverless，还有另外一种 Serverless 形态：容器化的Serverless。相较于 Function Serverless，容器化的 Serverless, 可移植性更强, 开发者对复杂应用程序能进行更好的掌控。除此之外，对于那些经历过容器时代洗礼的用户，容器化的 serverless或许是一种更好的选择。

对于Serverless, 有如下几点需要关注一下：

事件（event）驱动：Serverless 是由事件（event）驱动（例如 HTTP、pub/sub）的全托管计算服务；
自动弹性：按需使用，削峰填谷；
按使用量计费：相对于传统服务按照使用的资源（ECS 实例、VM 的规格等）计费，Serverless 场景下更多的是按照服务的使用量（调用次数、时长等）计费；
绿色的计算：所谓绿色的计算其实就是最大化的提升资源使用效率，减少资源浪费，做的“节能减排”。

Knative

上面提到了容器化的 Serverless，那么有没有这样的 Serveless 平台框架呢？答案就是：Knative。

Knative 是在 2018 的 Google Cloud Next 大会上发布的一款基于 Kubernetes 的 Serverless 编排引擎。Knative 一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。Knative 是通过整合容器构建(或者函数)、工作负载管理(弹性)以及事件模型这三者来实现的这一 Serverless 标准。Knative 社区的当前主要贡献者有 Google、Pivotal、IBM、RedHat。另外像 CloudFoundry、OpenShift 这些 PaaS 提供商都在积极的参与 Knative 的建设。

1. Knative 核心模块

Knative 核心模块主要包括事件驱动框架 Eventing 和部署工作负载的 Serving。

2. Serverless 服务引擎 – Serving

Knative Serving 核心能力就是其简洁、高效的应用托管服务，这也是其支撑 Serverless 能力的基础。Knative 提供的应用托管服务可以大大降低直接操作 Kubernetes 资源的复杂度和风险，提升应用的迭代和服务交付效率。当然作为 Severlesss Framework 就离不开按需分配资源的能力，阿里云容器服务 Knative 可以根据您应用的请求量在高峰时期自动扩容实例数，当请求量减少以后自动缩容实例数，可以非常自动化的帮助您节省成本。

Serving 通过与 Istio 结合还提供了强大的流量管理能力和灵活的灰度发布能力。流量管理能力可以根据百分比切分流量，灰度发布能力可以根据流量百分比进行灰度，同时灰度发布能力还能通过自定义 tag 的方式进行上线前的测试，非常便于和自己的 CICD 系统集成。

Serving 应用模型

Service: 对应用 Serverless 编排的抽象，通过 Service 管理应用的生命周期；
Configuration: 当前期望状态的配置。每次更新 Service 就会更新 Configuration；
Revision: configuration 的每次更新都会创建一个快照，用来做版本管理；
Route: 将请求路由到 Revision，并可以向不同的 Revision 转发不同比例的流量。

3. 事件驱动框架 – Eventing

1.采用 CloudEvent 作为事件传输协议: CloudEvent 以通用的格式描述事件数据，提供跨平台的服务交互能力。KnativeEventing 使用 CloudEvent 作为事件传输标准，极大的提升了应用的跨平台可移植性；
2.外部事件源接入和注册：提供 Github、RocketMQ 以及 Kafka 等事件源的支持，当然用户可以自定义事件源。
3.事件的订阅和触发：引入 Broker 和 Trigger 模型意义，不仅将事件复杂的处理实现给用户屏蔽起来，更提供丰富的事件订阅、过滤机制；
4.兼容现有消息系统：KnativeEventing 充分解耦了消息系统的实现，目前除了系统自身支持的基于内存的消息通道 InMemoryChannel 之外，还支持 Kafka、NATSStreaming 等消息服务,此外可以方便的对接现有的消息系统。

Eventing 中 Broker/Trigger模型

这里介绍一下 Eventing 中 Broker/Trigger 模型，其实并不复杂。外部事件源将事件发送给 Broker， Broker 接收事件之后发送给对应的 Channel（也就是消息缓存，转发的地方，如 Kafka，InMemoryChannel 等），通过创建 Trigger 订阅 Broker 实现事件的订阅，另外在 Trigger 中定义对应的服务，实现最终的事件驱动服务。

消息队列 RocketMQ

消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 版既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。

RocketMQSource

RocketMQSource 是 Knative 平台的 RocketMQ 事件源。其可以将 RocketMQ 集群的消息以 Cloud Event 的格式实时转发到 Knative 平台，是 Apahe RocketMQ 和 Knative 之间的连接器。

Knative + RocketMQ 场景示例-餐饮配送场景

我们接下来以餐饮配送为例进行演示，餐饮配送场景具有以下特征：

餐饮配送一天之内存在明显的高峰、低谷；
高峰时间下单量很大。

针对这样的情况，我们采用消息驱动 Serverless，在高峰的时候自动扩容资源，在低谷的时候缩减资源，按需使用能极大的提升资源使用率，从而降低成本。

1. 典型架构

如上图所示，当用餐时间来临，客户点餐生成下单消息发送到 RocketMQ, 通过 RocketMQSource 获取下单消息转换成事件发送到 Broker，通过 Trigger 订阅下单事件最终驱动订单服务生成订餐单。采用该方案具有以下优势：

通过 Knative 技术以 RocketMQ 为核心将餐饮配送系统 Serverless 化可以极大程度降低服务器运维与成本；
Knative 的弹性可以帮你轻松应对早、中、晚三餐资源高峰需求；
系统以 RocketMQ 做异步解耦，避免长链路调用等问题，提高系统可用性。

2. 操作

部署 Knative

参见阿里云容器服务部署 Knative。

部署 RocketMQSource

在 Knative 组件管理中，选择 RocketMQSource 点击部署。

部署订单服务

参考示例代码仓库。

一键部署服务命令如下：

kubectl apply -f 200-serviceaccount.yaml -f 202-clusterrolebinding.yaml -f 203-secret.yaml -f alirocketmqsource.yaml -f broker.yaml -f ksvc-order-service.yaml -f trigger.yaml

模拟高峰订餐下单

通过模拟下单，往 RocketMQ 中并发发送消息即可。消息格式参考：

{"orderId":"123214342","orderStatus":"completed","userPhoneNo":"152122131323","prodId":"2141412","prodName":"test","chargeMoney":"30.0","chargeTime":"1584932320","finishTime":"1584932320"}

3. 演示效果

如下图所示：

其它应用场景

1. Knative + RocketMQ 典型场景 – 构建 Serverless 电商系统

Knative 弹性可以帮你轻松应对团购、双11 等电商的大促活动；
系统以 RocketMQ 为中心做异步解耦，避免长链路调用等问题，提高系统可用性。

2. Knative + RocketMQ 典型场景- 构建监控告警平台

Metric、Log 等数据通过 RocketMQ 集群推送到 Knative 服务；
Knative 服务通过数据分析将告警内容推送钉钉或 slack 等通讯工具；
Knative 服务可以将 Metric 或 logs 数据进行处理，推送第三方系统。

3. Knative + RocketMQ 典型场景- 多数据格式转换

处理数据日志以生成多个结果派生词，这些结果派生词可用于运营，营销，销售等；
将内容从一种格式转换为另一种格式，例如，将 Microsoft Word 转换为 PDF；
需要转换为多种格式的主媒体文件。

总结

通过以上 RocketMQ 事件驱动 Knative Serverless 应用的介绍，是否也给你碰撞出了火花？可以结合自身的应用场景不妨一试，相信会给你带来不一样的体验。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

当 RocketMQ 遇上 Serverless，会碰撞出怎样的火花？

云原生

Serverless

Knative

1. Knative 核心模块