flash网站效果,上海新政策,做网站系统如何保证自己的版权,建筑网站 知乎作者 | 周礼#xff08;不铭#xff09; 阿里巴巴集团消息中间件架构师导读#xff1a;本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》#xff0c;主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。关注阿里巴巴云原生公众号…作者 | 周礼不铭 阿里巴巴集团消息中间件架构师导读本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。关注阿里巴巴云原生公众号后台回复 818 即可获取直播回看地址和大会 PPT 合集。引言本文以一张云进化历史图开场来谈谈云原生时代消息中间件的演进路线但本文绝对不是“开局一张图内容全靠编”。从虚拟化技术诞生以来IaaS / PaaS / SaaS 概念陆续被提了出来各种容器技术层出不穷。到 2015 年Cloud Native 概念应运而生一时间各种云厂商云服务以及云应用都加上了“云原生”前缀。我们也一直在思考传统的消息中间件需要做些什么才能加上云原生这个修饰词这也是本文探讨的主题传统的消息中间件如何持续进化为云原生的消息服务。云原生消息服务1. 什么是云原生首先来谈谈什么是云原生云原生是一个天然适用于云计算的架构理念实践云原生技术理念的应用可以最大化享受云计算的技术红利包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。应用在实践云原生技术理念时一般会遵循四个要素采取 DevOps 领域的最佳实践来管理研发和运维流程通过 CICD 工具链做到应用的快速迭代和持续交付采取微服务架构采取容器及相关技术进行应用的托管。消息服务作为应用的通信基础设施是微服务架构应用的核心依赖也是实践云原生的核心设计理念的关键技术通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点所以消息服务的云原生化是至关重要的。2. 什么是云原生消息服务先说结论我们认为云原生消息服务是云原生的通信基础设施。2015 年成立的 CNCF 基金会大范围推广了云原生的技术理念并提供了一套完整的实践技术工具集帮助开发者落地云原生理念。这套工具集收录于 CNCF 云原生全景图其中消息中间件处于应用定义和开发层的 Streaming 和 Messaging 类目。消息中间件在云原生的应用场景主要是为微服务和 EDA 架构提供核心的解耦、异步和削峰的能力在云原生全景图定义的其它层次领域消息服务还发挥着数据通道、事件驱动、集成与被集成等重要作用。另外云原生倡导面向性能设计基于消息队列的异步调用能够显著降低前端业务的响应时间提高吞吐量基于消息队列还能实现削峰填谷把慢服务分离到后置链路提升整个业务链路的性能。3. 云原生消息服务演进方向云原生时代对云服务有着更高的要求传统的消息服务在云原生这个大背景下如何持续进化为云原生的消息服务我们认为方向有这么几个 1高 SLA 云原生应用将对消息这种云原生 BaaS 服务有更高的 SLA 要求应用将假设其依赖的云原生服务具备跟云一样的可用性从而不需要去建设备份链路来提高应用的可用性降低架构的复杂度。只有做到与云一样的可用性云在服务就在才能称为真正的云原生服务。2低成本 在过去每家公司自建消息中间件集群或是自研的、或是开源的需要投入巨大的研发、运维成本。云原生时代的消息服务借助 Serverless 等弹性技术无需预先 Book 服务器资源无需容量规划采取按量付费这种更经济的模式将大幅度降低成本。 3易用性 在云原生时代消息服务第一步将进化成为一种所见即所得、开箱即用的服务易用性极大的提高。接下来消息服务将以网格的形式触达更复杂的部署环境小到 IoT 设备大到自建 IDC都能以跟公有云同样易用的方式接入消息服务且能轻易地满足云边端一体化、跨 IDC、跨云等互通需求真正成为应用层的通信基础设施。 4多样性云原生消息服务将致力于建设大而全的消息生态来涵盖丰富的业务场景提供各式各样的解决方案从而满足不同用户的多样性需求。阿里云消息队列目前建设了多个子产品线来支撑丰富的业务需求比如消息队列 RocketMQKafka微消息队列等。5标准化 容器镜像这项云原生的核心技术轻易地实现了不可变基础设施不可变的镜像消除了 IaaS 层的差异让云原生应用可以在不同的云厂商之间随意迁移。但实际上很多云服务提供的接入形式并不是标准的所以依赖这些非标准化云服务的应用形成了事实上的厂商锁定这些应用在运行时是无法完成真正的按需迁移所以只能称为某朵云上的原生应用无法称为真正的云原生应用。因此消息服务需要做到标准化消除用户关于厂商锁定的担忧目前阿里云消息队列采纳了很多社区标准支持了多种开源的 API 协议同时也在打造自己标准化接口。总结一下传统的消息队列将从高 SLA、低成本、易用性、多样性和标准化几个方向持续进化为云原生的消息服务。云原生消息三化谈到云原生离不开 Kubernetes、Serverless 以及 Service Mesh接下来为大家分享下我们如何利用 K8s 社区的生态红利如何实践 Serverless 和 Service Mesh 技术理念。1. 云原生消息 Kubernetes 化Kubernetes 项目当下绝对是大红大紫在容器编排和应用托管领域绝对的事实标准整个社区也是生机盎然。所以必须将我们的消息服务升级为 K8s 环境开箱即用的服务。云原生消息 Kubernetes 化是指通过自定义 CRD 资源将有状态的消息集群托管至 Kubernetes 集群中充分利用K8s 提供的部署、升级、自愈等能力提高运维效率同时尽可能享受 K8s 的社区生态红利。我们在 RocketMQ 开源社区也提供了 CRD 描述文件以及相应的 Operator 实现通过这套实现可以快速部署 RocketMQ 集群至 K8s 环境利用 K8s 的能力低成本运维 RocketMQ 集群也可以使用云原生的 Prometheus 观察集群指标。RocketMQ 完成 Kubernetes 化后就变成了 Kubernetes 环境原生可访问的一个消息服务将给开发者带来极大的便利性。同时在商业化环境我们也正在依赖 Kubeone 将消息队列系列产品完成 Kubernetes 化。2. 云原生消息 Serverless 化Serverless 最核心的理念是“按需”云原生消息 Serverless 化主要是从两个维度落地按需的概念一方面根据业务规模自动化扩缩容实例规格、队列数等逻辑资源另一方面根据服务端负载自动化扩缩容计算、存储等物理资源。1逻辑资源按需扩缩容在用户侧更关心的是消息实例提供的逻辑资源是否充足比如购买的实例 TPS 规格是否足够队列数量是否能满足扩展性需求。比如一个商业化的 MQ 实例中可以根据用户的流量对实例规格进行自动的升降配从 2W TPS 至 10W TPS 按需调整也可以根据用户分布式消费者的数量规模对逻辑队列数量进行动态调整用户完全不需要进行容量评估。2物理资源按需扩缩容在云服务开发者侧我们更关心的是如何通过 Serverless 降低运维成本避免手动的机器购买、VIP 申请、磁盘申请以及集群扩缩容等。在 Kubernetes 化完成后可以很轻易地根据集群 Load 等指标自动扩容 MQ 物理资源在集群缩容的处理上会比较麻烦因为每个 MQ 节点其实是有状态的图中的某个 PV 代表了一个 CommitLog我们在内部通过在 ASI 上支持 PV 漂移在 RocketMQ 存储层支持多 CommitLog 挂载来完成自动化缩容。3. 云原生消息 Mesh 化Service Mesh 出发点是解决微服务架构的网络问题将服务之间的通信问题从业务进程中进行剥离让业务方更加专注于自身的业务逻辑。 云原生消息 Mesh 化将消息的富客户端能力下沉至 Sidecar将消息的服务发现、负载均衡、流量监控等职责与业务逻辑隔离在运行时完成透明组装同时提供细粒度的消息灰度和治理能力。目前阿里云消息队列 RocketMQ 是国内第二个成功进入 Service Mesh 官方社区的中间件产品在进行 Envoy 适配的过程中推动了 Envoy 社区加速对 on-demand CDS 的支持创新性地使用 Pop 消费模式来适配 Mesh 的无状态网络模型。更详细的 Mesh 化介绍参考文章Apache RocketMQ 的 Service Mesh 开源之旅云原生消息生态在云原生消息服务演进方向小节中提到云原生消息服务需要大而全的消息生态来覆盖业务方丰富的业务场景本小节介绍我们在生态建设方面做的一些努力。1. 云原生消息产品矩阵阿里云消息产品矩阵包含消息队列 RocketMQ、Kafka、AMQP、微消息队列 MQTT、消息通知服务 MNS 以及即将发布的 EventBridge涵盖互联网、大数据、移动互联网、物联网等领域的业务场景为云原生客户提供一站式消息解决方案。消息队列 RocketMQ 阿里巴巴自主研发及 双11 交易核心链路消息产品阿里云主打品牌主要面向业务消息处理打造金融级高可靠消息服务消息队列 Kafka 聚焦大数据生态链100% 融合 Kafka 开源社区大数据应用领域中不可或缺的消息产品微消息队列 MQTT 基于 MQTT 标准协议自研拓展消息产品的领域与边界延伸到移动互联网以及物联网实现端与云的连接消息队列 AMQP 100% 兼容 AMQP 事实标准协议全面融合 RabbitMQ 开源社区生态消息服务 MNS 聚焦云产品生态集成 消息通知服务HTTP Endpoint、Function Compute、事件通知、移动推送等事件总线 EventBridge 作为我们下一代的消息产品形态原生支持 CloudEvents 标准提供中心化事件服务能力加速云原生生态集成EDA 首选。2. 云原生消息生态在生态建设方面我们在商业化和开源两个生态都取得了不错得成功。在阿里云消息商业化生态中消息队列产品线已经支持 11 BU30 云产品或者解决方案有些对用户是可见的有些是不可见的真正做到了云原生通信基础设施的定位。在开源方面开源 RocketMQ 已经完成了云原生技术栈的集成包括 Knative 中的事件源Prometheus 的 ExporterK8s 的 Operator 等也支持了微服务框架 Dubbo、SpringCloud 以及函数计算框架 OpenWhisk同时开发了很多 Connector 作为 Sink 或者 Source 去连接了 ELK、Flume、Flink、Hadoop 等大数据和数据分析领域的优秀开源产品。3. 云原生消息标准最开始我们就提到标准化是云原生消息中间件的进化方向之一我们从两个维度打磨产品的标准化建设。1社区标准在消息领域无论是接口还是协议社区一直有很多事实上的“标准”比如 Kafka 提供的 API 和协议JMS APICloudEvents 规范MQTT 中的协议和模型AMQP 的协议和模型等阿里云消息队列产品线对这些事实标准都提供了相应的接入方式用户可以低成本完成迁移上云。2自建标准事实上的“标准”如果太多其实就没有标准开源方面一直在推动自建标准 OpenMessagingOMS 将提供六大核心特性多领域、流、平台无关、标准的 Benchmark面向云线路层可插拔。目前国内有很多云提供商都接入了 OMS 标准。云原生消息核心竞争力作为云原生的消息核心竞争力在哪特别是开源生态愈发蓬勃用户可选的解决方案非常多如何让用户选择我们云原生的消息服务我们认为核心竞争力主要有这么几个。1. 领先的消息服务能力阿里云的消息服务在多个方面都具备绝对领先的服务能力。1接入迁移 整个产品线支撑了多协议、多 API、多语言、多终端以及多生态的接入做到了“0”接入成本开源或自建用户都可以无缝上云同时全球消息路由也支持跨地域的消息同步异构的消息迁移同步等。 2多租户 阿里云消息服务支持命名空间隔离、标准的访问控制支持实例限流、资源隔离、多租户的海量堆积。 3消息类型 在业务消息领域阿里云消息有多年的业务沉淀消息类型上支持普通消息、事务消息、定时消息、顺序消息、重试消息以及死信消息等。 4消费 治理在消费和治理领域云消息服务支持 Pub / Sub 模式广播/集群消费模式消费过程中支持 Tag 过滤、SQL 过滤。在运维时提供了消息轨迹、消息查询以及消息回放等治理能力。 5服务能力 阿里云消息的服务能力是经过多年锤炼的高可用核心交易链路 12 年双十一 10 年历程在云上承诺的可用性 SLA 为 99.95%可靠性 8 个 9高性能双11 消息收发 TPS 峰值过亿日消息收发总量 3 万亿拥有全球最大的业务消息集群之一低延迟在 双11 万亿级数据洪峰下消息发送 99.996% 在毫秒级响应消息发布平均响应时间不超过 3 毫秒。2. 统一的消息内核阿里云消息队列的另一核心竞争力为统一的消息内核整个消息云产品簇都建设在统一的 RocketMQ 内核之上所有的云产品提供一致的底层能力。RocketMQ 内核主要包含以下几个模块1富客户端 RocketMQ 提供一个轻量级的富客户端暴露 Push、Pull 以及 Pop 三种消费模式同时内置了重试、熔断等高可用功能产品簇的众多客户端都是通过对内核的富客户端进行二次开发的。 2注册中心 也就是 RocketMQ 开发者熟知的 NameServer以简单可靠的方式提供集群管理、元数据管理、Topic 路由和发现等功能节点无状态最终一致的语义确保 NameServer 具有超高的可用性。3计算节点 Broker 中的计算部分包含一个高性能的传输层以及一个可扩展的 RPC 框架以支持各个产品的丰富的业务需求。4存储引擎 Broker 中的核心为存储引擎经过多年锤炼的存储引擎包含几个核心特点低延迟读写互斥通过在 PageCache 层完成消息的读写互斥来大幅度保障写链路的低延迟日志与索引分离整个存储层将消息以 Append-Only 的方式集中式存储在 CommitLog 中同时以索引派发这种可扩展的方法来支持事务、定时、查询以及百万队列等高级特性一致性多副本提供多套一致性多副本实现来满足不同的部署场景和需求比如 Master-Slave 架构、基于 Raft 的 Dleger 和正在自研的秒级 RTO 多副本协议多模存储在未来存储的方式肯定是多样化的存储引擎抽象来统一的存储接口并提供了本地块设备、云存储以及盘古原生存储等实现。多级存储越来越的用户对消息生命周期有了更高的要求在过去消息作为应用开发的中间状态往往只会被存储数天通过 Deep Storage将以低成本的方式大幅延长消息的生命周期将消息转化为用户的数据资产以挖掘更多的诸如消息分析、消息计算需求。3. 全方面的稳定性建设稳定性永远是前面的 1业务发展和创新是后面的 0。—— 叔同稳定性的重要性是不言而喻的稳定性是用户做技术和产品选型的时候考察第一要素阿里云消息队列在稳定性方面做了全面的建设。阿里云消息队列主要从以下几个维度进行稳定性建设1架构开发整个系统是面向失败设计的除了最核心的组件所有的外部依赖都是弱依赖在产品迭代阶段建立了完善的 Code Review、单元测试、集成测试、性能测试以及容灾测试流程。 2变更管理风险往往来自于变更我们对变更的要求是可灰度、可监控、可回滚以及可降级的。 3稳定性防护限流、降级、容量评估、应急方案、大促保障、故障演练、预案演练、定期风险梳理等都是我们的稳定性防护手段。4体系化巡检分为黑盒巡检和白盒巡检黑盒巡检会站在用户视角对产品功能进行全方面扫描包含了 50 检测项白盒巡检会自动化检测 JVM 运行时指标、内核系统指标、集群统计指标等并在指标异常时及时预警。5故障应急我们建设了一套完整的故障应急流程从监控报警-故障发生-快速止血-排查根因-故障复盘整个链路都是顺畅的。 云原生消息展望在消息产品矩阵小节中提到EventBridge 是作为我们下一代的消息产品形态该产品也即将迎来公测本章节主要介绍 EventBridge 的产品定位。1. 消息与事件消息和事件是两种不同形态的抽象也意味着满足不同的场景1消息消息是比事件更通用的抽象常用于微服务调用之间的异步解耦微服务调用之间往往需要等到服务能力不对等时才会去通过消息对服务调用进行异步化改造消息的内容往往绑定了较强的业务属性消息的发送方对消息处理逻辑是有明确的预期的。 2事件事件相对于消息更加具像化代表了事情的发送、条件和状态的变化事件源来自不同的组织和环境所以事件总线天然需要跨组织事件源对事件将被如何响应没有任何预期的所以采用事件的应用架构是更彻底的解耦采用事件的应用架构将更加具备可扩展性和灵活性。2. EventBridge中心化事件总线EventBridge 作为我们即将发布的新产品其核心能力之一便是提供中心化的事件总线能力。EventBridge 将提供云产品之间、云应用之间、云产品与云应用之间以及它们与 SaaS 提供商之间的集成与被集成能力。在中心化事件总线中有几个重要的概念事件源事件源可以是阿里云服务比如对象存储、ECS、数据库等也可以是用户的应用程序或者第三方 SaaS这些事件源将提供丰富的业务事件、云产品运维事件、事件流等资源管理EventBridge 内部将提供总线管理、规则管理以及 Schema 管理提供全托管的事件服务事件处理EventBridge 将提供事件传输、事件过滤、事件路由、事件查询、回放、重试、追踪等核心的事件处理能力事件目标事件最终投递的目标服务包罗万象既可以触发一个 Serverless 的 Function也可以投递至消息队列其它产品运维事件还可以通过短信、邮件以及日志服务触达运维人员。3. EventBridgeEDA 服务框架EventBridge 另一个核心能力是 EDA 服务框架。微服务有两种驱动方式请求驱动和事件驱动。在请求驱动模式下服务之间调用是同步调用这种模式优点是延迟低但是服务之间的耦合是比较重的相比之下事件驱动有几个优点异步化所有的调用通过事件异步化驱动服务之间没有显示的依赖关系松耦合通过事件总线解除所有服务之间的耦合关系可扩展可扩展能力非常强基于总线和事件 Schema 完成业务的扩展非常简单零改造请求驱动的微服务在遇到服务之间能力不对等时往往需要进行基于消息异步化改造避免慢调用、超时等异常情况在整个分布式集群触发雪崩效应。基于事件驱动的微服务天然具备力异步、削峰等能力所以在业务规模扩大时不会带来额外的改造成本。上图是设想的一个采用 EDA 的应用架构图基于 EventBridge 可以实践流行的 CQRS 和 Event Souring 范式可以从 IoT 端设备上接入 Event Streaming基于事件驱动的微服务程序也可以通过 API 网关暴露传统的 Request 请求方式供前端访问EventBridge 还可以连接第三方 SaaS 提供商云提供商不同组织的观察者与分布式的事件微服务集成事件驱动和请求驱动是相辅相成的关系通过统一 Event APIs 和 REST APIs 打通事件驱动的微服务与请求驱动的微服务来进行架构上的融合与统一。4. EDA 成熟度模型我们通过 Gartner 报告总结的 EDA 成熟度模型展望以下 EDA 架构的未来Incidental偶发性地使用事件通知机制来进行一些状态的捕获没有明确的事件处理策略Brokered提供托管的事件代理服务组织中部分应用开始采用基于消息或者事件的异步化架构Centralized以战略的形式提出中心化的 EDA 解决方案有专门的组织团队提供 EDA 实现EDA 架构开始广泛被采用AdvancedEDA 架构开始触达更多的业务领域比如流计算数据分析AI以及 API 市场等跨组织的事件生态开始形成并进行扩张Pervasive事件变得无处不在庞大的事件生态形成组织间的隔离被事件彻底打通企业的关键业务都将采取 EDA 架构事件驱动与请求驱动两个生态完成融合。阿里云消息团队在 EDA 领域的探索目前是处于第三个阶段未来还有很长的路要走。“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践做最懂云原生开发者的公众号。”
