标签：交流 状态 soft spm dna 就是 环境 ali 参考
作者 | 元毅? 阿里巴巴高级开发工程师
阿里巴巴云原生公众号后台回复?Knative，免费下载《Knative 云原生应用开发指南》电子书！
想必大家都比较了解 RocketMQ 消息服务，那么 RocketMQ 与 Serverless 结合会碰撞出怎样的火花呢？我们今天介绍一下如何基于 RocketMQ + Knative 驱动云原生 Serverless 应用 。本文主要从以下几个方面展开介绍：
先看一下 CNCF 对云原生的定义：
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
其实云原生旨在以标准化云服务的提供方式衔接云厂商和客户。这种方式对于客户而言降低了上云和跨云迁移的成本，让客户始终保有和云厂商议价的能力；对云厂商而言，因为客户跨云迁移的成本低，所以只要能提供性价比更高的云服务，就能很容易的聚集大量用户。
Serverless（无服务器架构）是指服务端逻辑由开发者实现，运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。
Serverless 可以理解为云原生技术发展的高级阶段，使开发者更聚焦在业务逻辑，而减少对基础设施的关注。
这里提到的是 Functions Serverless, 其实除了 Functions Serverless， 还有另外一种 Serverless 形态：容器化的Serverless。相较于 Function Serverless，容器化的 Serverless, 可移植性更强, 开发者对复杂应用程序能进行更好的掌控。除此之外，对于那些经历过容器时代洗礼的用户，容器化的 serverless或许是一种更好的选择。
对于Serverless, 有如下几点需要关注一下：
上面提到了容器化的 Serverless，那么有没有这样的 Serveless 平台框架呢？答案就是：Knative。
Knative 是在 2018 的 Google Cloud Next 大会上发布的一款基于 Kubernetes 的 Serverless 编排引擎。Knative 一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。Knative 是通过整合容器构建(或者函数)、工作负载管理(弹性)以及事件模型这三者来实现的这一 Serverless 标准。Knative 社区的当前主要贡献者有 Google、Pivotal、IBM、RedHat。另外像 CloudFoundry、OpenShift 这些 PaaS 提供商都在积极的参与 Knative 的建设。
Knative 核心模块主要包括事件驱动框架 Eventing 和部署工作负载的 Serving。
Knative Serving 核心能力就是其简洁、高效的应用托管服务，这也是其支撑 Serverless 能力的基础。Knative 提供的应用托管服务可以大大降低直接操作 Kubernetes 资源的复杂度和风险，提升应用的迭代和服务交付效率。当然作为 Severlesss Framework 就离不开按需分配资源的能力，阿里云容器服务 Knative 可以根据您应用的请求量在高峰时期自动扩容实例数，当请求量减少以后自动缩容实例数，可以非常自动化的帮助您节省成本。
Serving 通过与 Istio 结合还提供了强大的流量管理能力和灵活的灰度发布能力。流量管理能力可以根据百分比切分流量，灰度发布能力可以根据流量百分比进行灰度，同时灰度发布能力还能通过自定义 tag 的方式进行上线前的测试，非常便于和自己的 CICD 系统集成。
1.采用 CloudEvent 作为事件传输协议: CloudEvent 以通用的格式描述事件数据，提供跨平台的服务交互能力。KnativeEventing 使用 CloudEvent 作为事件传输标准，极大的提升了应用的跨平台可移植性；
2.外部事件源接入和注册： 提供 Github、RocketMQ 以及 Kafka 等事件源的支持，当然用户可以自定义事件源。
3.事件的订阅和触发：引入 Broker 和 Trigger 模型意义，不仅将事件复杂的处理实现给用户屏蔽起来，更提供丰富的事件订阅、过滤机制；
4.兼容现有消息系统：KnativeEventing 充分解耦了消息系统的实现，目前除了系统自身支持的基于内存的消息通道 InMemoryChannel 之外，还支持 Kafka、NATSStreaming 等消息服务,此外可以方便的对接现有的消息系统。
这里介绍一下 Eventing 中 Broker/Trigger 模型， 其实并不复杂。外部事件源将事件发送给 Broker， Broker 接收事件之后发送给对应的 Channel（也就是消息缓存，转发的地方，如 Kafka，InMemoryChannel 等），通过创建 Trigger 订阅 Broker 实现事件的订阅，另外在 Trigger 中定义对应的服务，实现最终的事件驱动服务。
消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 版既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。
RocketMQSource 是 Knative 平台的 RocketMQ 事件源。其可以将 RocketMQ 集群的消息以 Cloud Event 的格式实时转发到 Knative 平台，是 Apahe RocketMQ 和 Knative 之间的连接器。
我们接下来以餐饮配送为例进行演示，餐饮配送场景具有以下特征：
针对这样的情况，我们采用消息驱动 Serverless， 在高峰的时候自动扩容资源，在低谷的时候缩减资源，按需使用能极大的提升资源使用率，从而降低成本。
如上图所示，当用餐时间来临，客户点餐生成下单消息发送到 RocketMQ, 通过 RocketMQSource 获取下单消息转换成事件发送到 Broker，通过 Trigger 订阅下单事件最终驱动订单服务生成订餐单。采用该方案具有以下优势：
在 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"}
如下图所示：
通过以上 RocketMQ 事件驱动 Knative Serverless 应用的介绍，是否也给你碰撞出了火花？可以结合自身的应用场景不妨一试，相信会给你带来不一样的体验。
<关注阿里巴巴云原生公众号，回复?Knative?即可下载电子书>
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”
当 RocketMQ 遇上 Serverless，会碰撞出怎样的火花？
标签：交流 状态 soft spm dna 就是 环境 ali 参考
原文地址：https://www.cnblogs.com/alisystemsoftware/p/12785251.html
