随着云原生技术的普及和落地，企业在构建业务系统时，往往需要依赖多个云产品和服务，产品互联、系统协同的需求越来越强。事件驱动架构将事件应用于解耦服务之间的触发和交互， 能够帮助用户很好实现产品、系统之间的互联互动。函数计算作为事件驱动架构的最佳选择，需要为用户提供丰富的事件源触发能力。 对于函数计算而言，事件源接入需要清晰地了解上游每一个事件源的诸多细节和鉴权要求，同时事件处理和系统错误追踪变得越加困难，集成效率成为阻碍产品能力的最大障碍。为了加速事件源集成的效率，函数计算需要找到一种统一标准的事件源接入方式，基于通用的接入层进行基础能力和可观测性的建设，为客户提供丰富的事件源触发选择。 在这样的背景和需求下，阿里云函数计算（Function Compute）和阿里云事件总线（EventBridge）产品完成全面深度集成。这意味着函数计算和阿里云生态各产品及业务 SaaS 系统有了统一标准的接入方式，意味着函数计算将具备接入 EventBridge 所有事件源的触发能力，Serverless 函数计算将实现触达阿里云全系产品服务的“最后一公里”，为基于阿里云生态产品提供重要的架构扩展能力。 为什么是 EventBridge？ 阿里云事件总线（EventBridge）是一种无服务器事件总线，支持将用户的应用程序、第三方软件即服务（SaaS）数据和阿里云服务的数据通过事件的方式轻松的连接到一起，这里汇聚了来自云产品及 SaaS 服务的丰富事件，EventBridge 具备事件标准化和接入标准化的能力： 事件标准化：EventBridge 遵循业界标准的 CloudEvent 事件规范，汇聚了来自阿里云生态和 EventBridge 合作伙伴丰富事件源的各种事件，同时提供了完善的事件投递机制和消费策略，整个系统事件流转遵循统一的事件格式； 接入标准化：函数计算选择和 EventBridge 集成，无论是产品服务类型众多的阿里云官方事件源，还是第三方 SaaS 系统，EventBridge 都能够为函数计算和其它系统集成提供统一的集成界面，函数计算无需关注上游事件源的具体实现细节，只需要专注于事件处理，将事件的集成和投递全部交给 EventBridge 来处理； EventBridge  + Function Compute 的结合让事件驱动型应用程序的构建变得简单，因为它可以为您完成事件摄取和交付、安全保障、授权以及错误处理工作。允许您构建松散耦合和分布的事件驱动型架构，帮助提高开发人员敏捷性和应用程序弹性。函数计算系统提供了完善的函数创建， 发布和运行体系，灵活的构建能力结合极致的运行时弹性能力将帮助业务构建云原生时代最富显著特征的事件驱动型架构。 同时，EventBridge 能够提供来自事件源（例如 MQ、OSS、RDB等）的实时数据流，并将该数据路由到阿里云函数计算作为目标。您可以设置路由规则来确定发送数据的目的地，以便构建能够实时响应所有数据源的应用程序架构。 函数计算 + EventBridge 带来的变化？ 提供 90+ 事件源接入 在和 EventBridge 集成之前， 函数计算已经实现了和阿里云部分核心系统的集成，随着函数计算 EventBridge 的深度集成，阿里云生态大量服务实现了和函数计算集成， 这些服务或产品的事件将作为事件源触发函数；目前函数计算触发器类型已经从原来的 15+ 增加到 90+，并随着 EventBridge 上游接入系统的增加而不断丰富； 控制台享受一站式服务 EventBridge 和函数计算控制台数据互通，用户在 EventBridge 控制台能够以事件为主体选择函数计算作为事件处理目标，在 EventBridge 控制台享受一站式服务；同样在函数计算控制台，用户能够根据不同触发器类型根据对应的事件类型编写函数；用户无需在函数计算控制台和事件总线控制台来回跳转； 保证数据一致性和稳定性 用户无论是在函数计算控制台上通过创建触发器的方式处理指定事件源的事件；还是在 EventBridge 控制台使用函数计算作为事件处理目标，提供统一的资源视图；同时在底层系统实现上，由于后端系统 API 的深度集成，能够保证上层业务逻辑采用统一的 API 及处理逻辑，从技术层面确保了多个入口功能实现的一致性，为客户系统稳定运行奠定坚实的基础； 简化数据消费投递的复杂度 对于数据消费场景，EventBridge 负责了上游系统的对接和数据消费，用户无需关心事件源系统数据具体消费方式，这部分工作统一由 EventBridge 完成；对于函数计算用户，只需要考虑数据投递的逻辑；用户可以直接选择 EventBridge 提供的下游 Target 实现数据投递，也可以在代码层面仅使用 EventBridge 提供的 SDK 实现数据的投递，大大简化了数据投递的复杂度。 触发器业务应用场景 下面就让我们一起探索， 实际的业务生产环境，我们如何利用这两把利器让这一切简单的发生： 自动化运营分析和展示 业务系统会产生大量动态指标数据，需要提取指标数据做运营分析和展示，通过 EventBridge 和 FC 异步化串联实现自动化运营分析和展示。传统方案需要基于实时计算或者离线计算产品做数据提取和分析，整个方案较重，配置复杂。数据分析结果需要做预定义的展示渲染和推送，需要手工对接业务系统，步骤繁琐。 采用新的 EDA 架构，采用 EventBridge 对接业务自定义事件数据，规则驱动过滤逻辑简单。采用 FC 可以轻量化实现常见的数据分析操作，代码编写调试更简单；同时利用EventBridge 丰富的推送能力，可以实现分析结果快速触达受众。 异步解耦 以交易引擎为例，交易系统引擎作为最核心的系统，每笔交易订单数据需要被几十几个下游业务系统关注，包括物品批价、发货、积分、流计算分析等等，多个系统对消息的处理逻辑不一致，单个系统不可能去适配每一个关联业务。结合 EventBridge 事件中心和函数计算灵活的逻辑扩展能力构建业务逻辑。 新零售大促场景 Serverless + EDA 整合 大型新零售场景会伴随不定期大促，平时流量不大的业务在大促场景也会产生系统流量突增，极致弹性和稳定解耦的架构至关重要。基于传统模式开发稳定可靠、高弹性的后台服务人力不足、工期紧张；大促场景保障峰值流量需要预留大量资源，平时低峰期资源闲置浪费。新零售大促场景利用函数计算 + EventBridge + API 网关搭建 Serverless 模式服务中台，支撑海量请求访问， 系统具备极致弹性，无需预留管理 IaaS 资源，极大程度降低闲置成本；同时函数计算提供敏捷开发结合 EventBridge 低代码异步驱动，业务迭代效率大幅提升。 总结 如果说事件背后的服务是阿里云生态服务的积木， 那么 Serverless 函数计算将是能够将这些积木通过轻巧的方式组合起来艺术化的最佳手段；你可以利用函数计算为这些积木涂上更绚丽的色彩，同时能够将他们串联起来，搭建一个具有无比想象空间的 SaaS/PaaS 服务艺术品。 EventBridge 触发器现已在阿里云函数计算控制台所有地域（Region）开放，欢迎大家点击进行使用体验！ 关于触发器具体创建，配置，参考阿里云函数计算官方帮助文档： 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：

前天我参加了信通院的云原生产业大会，参加会议的企业非常多，并且来自于各行各业，我在会场上非常感慨。我想起 2019 年的时候，我在搜索引擎上搜索“云原生”这个词，那时的搜索频率还比较低，而 2019 年又是云原生在国内开始飞速发展的一年。而今年的云原生会场上，已经有非常多的企业来参加，这些企业在技术、产品、生态中都在应用云原生，所以说，整个云原生已经从最开始的技术变成了行业，现在发展成了比较大的产业，并且这个产业的规模每年以非常快的速度在增长。 在今天，可能有很多咨询机构、企业，或者是个人开发者都在解读云原生，也许很多人对云原生都有比较深入的认识了。大家都可以认同的是，云原生肯定与云有关，但是它改变了什么，为企业带来什么价值呢？最核心的点应该是可以改变企业的应用架构；还有一种可能是不改变应用架构，只是把整个运维体系基于云原生进行重塑。但所有的这些，背后的目的都是为了加速企业的价值创造过程，简单的说，和制造企业改良生产线是一样的，核心点就是改良我们作为软件企业的生产线。 阿里在云原生的实践从 2006 年就开始了。我们在做云原生的过程中积累了很多经验，我们认为，今天云原生对于企业数字创新主要提供了多个价值： 一是资源弹性。弹性这个词大家很容易理解，实际上弹性有不同的层面。比如说基于虚拟机的弹性，提供的弹性能力是分钟级的。如果基于这些技术的应用是毫秒级的，那么分钟级只解决了资源弹性问题，整个应用高可用问题还需要进一步解决。如果说弹性到了应用的层面，到了毫秒级，高可用问题也得到一定程度的解决。 除此以外，系统的稳定性也是大家非常关注的方面。云原生就是把整个软件构造过程中非功能性特性拉出来放到云原生产品上去，帮助应用开发从非功能性处理过程中解脱出来，更多的专注在功能性。同样的，云原生有很多工具理念，可以让我们变得更好，整个软件开发从代码到上线的时间大幅缩短。同样的，今天在基于云原生可观测性上面我们会积累非常多的数据，这些数据可以结合机器学习这些能力，帮助我们改善企业的用户体验。这些对于业务来讲会带来比较大的价值。 阿里云原生的实践历程 今天，云原生在 CNCF、国内相关的开源、还有三方组织的推动下，可以使得一家企业在做技术选型的时候有非常多的选项。大家通常会面临一个问题，在这么多选择里面，要真正达到生产可用的目的到底选谁？特别是当我们的业务需要在非常短的时间内就上线，在业务高速发展的阶段，我们应该选什么样的架构，选什么样的开源开放的产品，这个是摆在广大企业技术决策者以及架构师面前的难题。 在云原生领域中，阿里云是相对比较早开始做自研的。从 2006 年到 2009 年互联网的中间件开始发展，到阿里云正式成立，整个过程中我们通过云原生解决很多业务问题。通过应用云原生相关技术，从早期很好地支持了淘宝的高速发展，到了 2015 年以后很好地支持了阿里的中台建设，以及到今天随着阿里巴巴整个生产系统、核心系统全部 100% 上云，这个过程中我们运用的云原生技术，像容器技术、微服务技术支持的规模都是百万级以上。 相关调研显示，这样的云原生落地规模在全球范围内都是非常领先的。实际上，对于很多企业来讲，也许用不到这些规模，但是阿里通过解决这样的大规模下的性能、稳定性问题，积累了非常多的硬核技术，最终能够把这些技术转变成了产品，通过阿里云对外输出，服务于各行各业的广大客户。 我们认为，云原生对于整个软件的改变，或者对软件公司的开发流程的改变是非常深刻的。首先 K8s 已经变成了软件交付的标准界面，它改变的不止是运维，而是从 CICD 到后续发布上线整个生产链条。由于所有生产流程得到改变，以及很多企业通过云原生技术重塑了软件架构，使得软件架构从传统架构变成了新的、我们称之为现代化的应用架构，因此云原生可以通过这种生产工具的改良进一步改变企业的生产关系，最终影响企业，使得企业在软件开发过程中得到了极大的提速。 阿里云在云原生实践过程中，积累了很强的技术竞争力，体现在这些方面： 一、我们有非常多领先的技术解决云原生领域里面的稳定性问题、可靠性问题，大规模下的高并发问题等。同时，我们会把所有的这些技术通过开源开放的形式输出。我们知道，在云原生的世界，企业需要的是开源开放的技术，而不是被像阿里这样单独一个厂商所锁定的技术。这个过程中我们基于开源开放技术标准积累了很多产品的硬核能力。在产品上，除了大家看到的基于云原生应用架构里，还包括云原生数据库、云原生大数据等。 在云原生相关的领域有比较多的测评，在这些测评里，例如阿里云容器产品 ACK，在去年 Gartner 评测中拿到满分，全球厂商中只有两个厂商拿到满分，阿里云是其中之一。今年，阿里云再次入选 Gartner 容器竞争格局。在新兴的计算形态领域中，今年阿里云进入 Forrester FaaS 领导者象限，函数计算获得了全球 FaaS 产品最高分。 在可观测性里，阿里云代表国内云厂商进入 Gartner APM 象限。所有这些三方评估从另外一个层面反映了阿里云产品的能力。容器架构上，我们基于开源开放的 K8s 技术体系，基于阿里云的硬件做深度的优化，在比较多的领域和场景里为广大 K8s 应用提供服务。我们把在 K8s 集群里面超大规模集群管理的能力输出到 ACK 产品里面，使得阿里云的客户在管理集群的时候，可以摆脱大规模集群的管理复杂性问题。 比如完美日记，作为美妆行业的独角兽公司，他们的业务发展速度非常快，但在业务快速发展过程中，他们面临的问题就是在大促的场景中怎么更好地预留资源，以及在大促时怎么样比较好地解决新上线的功能，以及需求的稳定性问题。在这个过程中，他们利用 PTS 作为压测，所有应用跑在 ACK 平台上面，通过压测模拟大促的流量，从而能够把整个大促从需要投入较大的状态提升到具备可以常态化的做大促压测的能力，也通过这个能力使得系统稳定性相关问题得到快速收敛。 云原生中间件 从微服务、消息到各种应用工具以外，根据企业常见的 IT 场景，云原生中间件也提供了很多解决方案。阿里云中间件诞生于集团内的大规模调用场景，同时兼容开源，并且融入了更多产品能力，例如在整个大促过程中表现优异的可观测性、高可用能力等，都属于云原生中间件产品体系。 同样在中间件领域里，我们也和较多企业客户有相应的合作。畅捷通是一家做 SaaS 的企业，迄今已经为超过四百万的小微企业做了云管。ToB 类型的应用复杂度较高，最大的问题就是整个软件的发布频率是非常快的，怎么样在高频软件发布下面能够比较好的解决软件的各种 BUG，或者解决设计上的不足带来的稳定性的问题，这是在前期探讨过程中畅捷通提出来的关注点。通过应用云原生中间件，不仅解决了整个应用的可观测性问题，并且让应用具备 360 度无死角可观测能力，通过应用探测能够快速发现在整个压测过程中各种可能的不稳定风险，从而使得相应风险得到快速的收敛。 Serverless 很多学术机构在 Serverless 领域深入研究，我们预感 Serverless 极有可能会成为下一代主流技术趋势。阿里云在 Serverless 领域里做到业界领先的毫秒级计费，以及在整个阿里云底层做深度优化，使客户的应用真正达到了智能的弹性、极致的运维和大幅提升开发效率。阿里云也和许多企业客户达成深度合作，进行 Serverless 落地实践，通过帮助客户将应用迁到 Serverless 技术体系上，达到比较快的应用部署；同时，把应用的稳定性问题、运维都委托给 Serverless 这样的云产品去解决。 解决方案 云原生在快速发展过程中，只有通过不断的技术创新、产品创新，才有可能使得云原生技术更好的服务于广大的企业客户。今天，阿里云对外发布四大解决方案：全链路压测解决方案、异地多活解决方案、资源混部解决方案、可观测解决方案。这些解决方案可以高效地解决在传统领域里还没有很好解决的问题。比如全链路压测，大家都知道全链路压测是个好东西，比较大的问题是在应用压测过程中使应用改造最小，甚至不要做改造，所以这次阿里云升级的全链路压测就可以帮助企业应用解决这些问题。 今天企业在不断深入地使用云以后，不管公有云还是专有云上，都会碰到整体 CPU 利用率不高的问题，混部就使得各种离线任务和在线任务可以部署在一起，各自享用资源调度的优势，使得整体机房的 CPU 利用率得到比较大的提升。在这个过程中要解决混部之后带来的稳定性问题、资源占用问题。阿里是比较早地应用大规模的混部，像支撑电商双十一的云原生产品。今天我们也是把混部能力变成解决方案对外输出。 大家都知道，阿里是比较早实现了单元化的架构，通过单元化架构实现了多活。今天我们把单元化整体的架构能力作为多活的解决方案。同时，这样的多活不仅可以支持自有数据中心、私有云的场景，也能够支持公有云和混合云场景实现整个应用的多活。 可观测性一直都是大家特别关注的话题，因为通过可观测性使得我们可以主动发现在系统的运行过程中可能出现的各类风险。今天，阿里云升级的可观测性方案包括从拨测到各种前端的性能监控，一直延伸到后端应用，甚至延伸到云服务里。 产品升级 除了解决方案的创新以外，我们在相应的云原生产品上面也做了比较多的升级。容器 ACK 备份容灾中心全新发布，为容器用户提供集群、应用和数据的完整性保护： 1、支持自动分析应用依赖的元数据及存储，实现秒级创建应用+数据的一致性快照； 2、支持创建备份计划，自动按预设时间点创建备份； 3、完全兼容 Kubernetes，并支持多集群、多地域、跨数据中心进行备份和恢复。 容器镜像 ACR 发布企业级 Serverless 构建服务，大幅提升云原生制品的构建效率和体验： 1、支持多操作系统、多架构镜像的矩阵构建，支持大规模并发任务构建。 2、支持多级缓存的构建加速，平均构建提速 30%。 3、支持自动构建加速镜像，实现 AI 等大镜像秒级按需加载，平均启动时间减少 60 %。 在微服务领域，越来越多的应用考虑采用服务网格技术。用户希望服务网格在开源技术之上有更强的微服务治理能力，因此阿里云推出专业版 ASM Pro，具备增强多协议支持，提升动态扩展能力，精细化服务治理，完善零信任安全体系。专业版相比去年发布的普通版，在性能及规模上均有显著提升，与开源的差异化竞争力进一步增强，降低用户在生产环境落地服务网格的门槛。 Gartner 预测，未来事件驱动将成为业务开发的主流架构。企业客户上云过程中对于低代码、无服务器弹性应用架构，如何轻量集成众多异构云服务的数据流有着明确的痛点和诉求。基于此趋势，阿里云发布了事件总线 EventBridge 这款产品，其目标在于统一阿里云云服务、第三方 SaaS 厂商、用户自定义的事件标准，通过标准、弹性、轻量的核心能力帮助用户快速低成本获取并处理海量事件，驱动业务开发。 在过去的一段时间，我们对 EventBridge 的产品能力做了进一步的扩充和升级： 在事件生态集成的规模方面，新增 60+ 云产品官方事件源接入，涵盖计算、存储、网络、数据库等主流云产品； 在事件触达和处理方式上，内置了十多种过滤匹配转换逻辑，并且新增了跨网络、跨地域、跨账号等深度触达方式，方便企业大客户做深层次的安全、隔离等定制； 在此基础上，阿里云 EventBridge 首次推出事件驱动应用中心，内置常见的事件驱动应用模板，用户无需代码和部署即可简单配置完成常见的事件 ETL 处理、数据同步等场景功能。 阿里云拥有最广泛的云原生客户群体。随着更多的企业客户上云，将有更多复杂的场景，对于云原生技术、产品以及云原生理念提出更高的要求。阿里云希望跟社会各界的朋友一起在云原生领域里面做更多的探索，希望通过云原生技术，真正为企业带来更多的业务价值，助力企业整体的业务创新。 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：