作者 | Dapr 社区
译者 | 敖小剑
来源|阿里巴巴云原生公众号

Dapr 是 2019 年 10 月开源的分布式运行时。早在 Dapr 开源初期，阿里云就开始参与 Dapr 社区建设和代码开发，目前已有两位 Dapr 成员，是 Dapr 项目中除微软之外代码贡献最多的公司。作为 Dapr 项目的早期采用者，阿里在 Dapr v1.0 发布之前就在内部小规模的试点。本文由 Dapr 社区成员敖小剑翻译。

分布式应用程序运行时现在已经生产就绪啦！

今天，我们很高兴地发布分布式应用运行时（Distributed APplication Runtime / Dapr）的 v1.0 版本，它已经达到了生产就绪所需的稳定性和企业准备。Dapr 是一个开源、可移植、事件驱动的运行时，它使开发人员能够轻松地构建运行在云平台和边缘的弹性而微服务化的应用程序，无论是无状态还是有状态。Dapr 让开发人员能够专注于编写业务逻辑，而不是解决分布式系统的挑战，从而显著提高生产力并减少开发时间。Dapr 降低了基于微服务架构构建现代云原生应用的准入门槛，而通过此次发布的 v1.0 版本，Dapr 应用可以部署到生产场景中的自托管基础设施或 Kubernetes 集群。

自 2019 年 10 月首次发布 以来，Dapr 已有 14 个版本，每个版本都建立在大量的社区和用户反馈基础上，以推动改进、稳定性和性能。这些版本立足于构建真实的应用，反映了当今开发者在开发云原生应用时的实际情况；无论是在云平台、边缘还是私有基础设施上，社区都在加紧贡献与 Azure、AWS、阿里巴巴和 Google cloud 集成的 Dapr 组件。

解决现实世界场景中的分布式应用挑战

从成立之初开始，Dapr 开源项目就面向那些正在构建新的现实世界绿色地带（greenfield）应用的开发者，以及那些在云原生架构中迁移和利用现有应用和组件的开发者。Dapr 方法的关键是满足开发者和企业的现状，帮助他们实现应用的现代化，并利用他们在云原生和微服务架构中的现有技能。在 v1.0 版本中，我们专注于将 Kubernetes 作为运行生产应用的主要托管环境，随着 Dapr 的进一步成熟，我们希望在无服务器（serverless）环境中看到 Dapr。在过去的一年半时间中，我们与早期采用者和合作伙伴紧密合作，因此 Dapr 现在已经成为多个基于 Kubernetes 的生产和预生产应用的核心。在这个用户驱动的过程中，Dapr 社区改进了 Java、.NET 和 Python SDK 的原生语言体验，用真实的工作负载测试了规模和性能，增加了安全特性，并证明了 Dapr 的 Actor 编程模型是工作流和物联网（IoT）场景的最佳选择。以下是一些早期采用者的故事，以凸显 Dapr 如今的使用情况。

蔡司：光学和光电子领域的国际技术领导者

ZEISS 面临的挑战是维护和更新一个具有 20 年历史的带有硬编码业务规则的后端系统。原来的订单验证和路由解决方案是基于一个具有固定容量的单体架构，开发人员在不直接在系统中重新配置表格的情况下，无法轻松的更新、重新路由或跟踪订单。此外，业务部门无法直接控制其订单处理流程。由于存在大量的系统依赖，变更总是需要代价高昂而耗时的开发人员干预。为了解决这个问题，ZEISS 使用 Azure 和 Dapr 开发了一个新的应用程序，可以更快地完成客户订单，同时还加快了开发速度，并改善了公司的业务连续性。你可以在 这里 阅读更多关于他们的故事。

Ignition Group：一家位于南非的技术企业，专注于客户承诺和销售支持工具

Ignition Group 打造的订单处理软件可以跟踪产品、管理订阅和处理来自各种来源的支付。订单处理涉及许多依赖，有一个采购跟踪机制，这个机制会调用客户订阅，触发会计和计费流程，并确定适当的支付渠道。Ignition Group 希望微服务能给其工作流逻辑带来好处——高可用性、弹性、可扩展性和性能。使用 Dapr 和 .NET Core，Ignition Group 构建了一个新的、可扩展性更好的、可维护的订单处理和支付系统，该系统目前已在生产中运行。Ignition Group 今天已经运行在生产中，你可以在 这里 阅读更多关于他们的故事。

Roadwork：采集数据洞若观火

Roadwork 是一家为自主系统提供端到端平台的初创公司，让用户产生可执行的洞察力并据此行动。目前，他们专注于数据提取技术，并以全面集成自主系统为路径。通过对 Dapr 与 KEDA 的梳理，他们在 Kubernetes 上创建了一个生产服务，根据传入的客户负载请求，自动扩展应用和集群。Dapr 提供了使用 RabbitMQ 的 pub/sub 的抽象和集成，其能够轻松拥有 竞争消费者模式。今天，Roadwork 的第一个产品 Scraper.ai 已经在生产中运行。在 这里 了解更多信息。

社区和生态系统

是社区的努力让 Dapr 成长到 v1.0。自 Dapr 首次公布以来，开源社区团结在 Dapr 周围并不断成长，令人惊叹——从 2019 年 10 月的 114 个贡献者增长到今天的 700 个。在短短的 16 个月内，增长了 6 倍多!

社区对项目的贡献涉及到 Dapr 的每一个仓库，范围包括提交问题、参与功能提案讨论、提供样本，当然也包括贡献代码。社区成员对项目贡献最大的部分包括 Dapr 运行时、文档、CLI 和 SDK。另外一个关键的贡献领域是创建了一个丰富的组件生态系统。可供开发人员使用的组件超过 70 个，使 Dapr 成为一个可以适用于广泛场景的解决方案，包括开源技术和云提供商的特定集成。当开发人员希望创建具有高可移植性的云平台无关的应用程序时，这些使得 Dapr 成为一个有吸引力的选择。

贡献并不局限于个人，还包括阿里云、HashiCorp、微软等组织，以及上文提到的 ZEISS 和 Ignition Group 等早期采用者。Dapr 生态系统还包括合作伙伴的技术栈，这些技术栈为使用 Dapr 的开发者提供了附加值。例如，New Relic 提供了关于他们的监控工具如何与 Dapr 无缝工作的指导，这要归功于 Dapr 使用的标准跟踪协议，这些协议可以在不改变任何代码的情况下轻松地检测您的应用程序。

培养一个开放和包容的社区是 Dapr 项目的首要目标。作为该承诺的一部分，我们分享了 向开放治理模式的过渡，这也是我们保持 Dapr 开放、供应商中立和包容性的方式。我们的愿景是继续这一旅程，并打算在不久的将来让 Dapr 加入一个开放软件基金会。同时，我们邀请您通过 GitHub、Dapr 社区定期会议 和最近推出的 Discord 服务器 与 Dapr 社区互动。

“在阿里云，我们相信 Dapr 将引领微服务的发展。通过采用 Dapr，我们的客户现在可以以更快的速度来构建可移植和健壮的分布式系统。”—— 阿里云资深技术专家 李响

发布亮点

在最近的几个月中，我们已经发布了三个 v1.0 版本的候选版本，专注于从社区获得反馈，并为 v1.0 版本做准备。在性能、安全、高可用性（HA）和一致性等方面更深入地关注于生产就绪。完整的发布说明可以在 这里 获得，以下是一些亮点：

作为生产环境的 Kubernetes

对于 v1.0 版本，Kubernetes 是首选的托管环境，它与 Dapr 控制平面和 Dapr sidecar架构深度集成。例如，在运维上，通过 Dapr CLI “init” 和 “upgrade” 命令简化了 Dapr 在 Kubernetes 上的安装和升级，这些命令可以拉取正确的 Dapr 运行时版本，并确保这些版本以受控的方式推出，包括迁移正在使用中的证书。您可以在 HA 模式下安装 Dapr 控制平面，确保多个实例同时运行，而且 Dapr sidecar 有一个健康端点，可以实现 Kubernetes 就绪（readiness）和活泼度（liveness）探针以确定其健康状态。在整个发布候选版本的过程中，我们与早期采用者密切合作，以确保他们能够以可运维的方式迁移到每个 Dapr 运行时版本，而不是构建新的集群。请参阅 生产部署指南 以了解更多信息。

性能、一致性和支持

在云原生应用中，性能是至关重要的，而 Dapr 对高性能非常重视。一个经常被提起的话题是，由 sidecar 模型为应用程序完成所有繁重工作所带来的影响，以及数据平面性能的权衡取舍。其中一个特别关注的领域是服务调用构建块，在这里，当通过两个 Dapr sidecar 在两个应用之间调用并收到响应时，Dapr 在 p90 时增加了约 1.2ms 的端到端延迟，在 p99 时增加了约 2ms。由此可见，Dapr 具有极低的服务间延迟，并针对高吞吐量场景进行了优化。

Dapr 有超过 70 个由社区开发的组件，为了确保对这些组件的使用信心，它们要经过一系列的一致性测试。组件首先从 alpha 状态开始，最终达到 GA 状态，并需要用户在生产中使用它们。对于 v1.0 版本，只有部分已经在生产中广泛使用的组件被批准为 GA，其他组件在满足标准后也将加入其中。与众多开源云原生技术一样，变更、修复和改进的引入速度很快，这意味着受支持版本存在滚动窗口。重要的是，Dapr v1.0 版本宣称 API 层面是稳定的，如果未来需要修改，将通过 版本机制 来保证 API 的完全向后兼容，如果需要破坏性的修改，则会提前几个版本注明。最后，从支持的角度来看，当前和之前的版本都将支持 在出现关键问题或安全问题时进行补丁更新。

安全

安全一直是 Dapr 的核心主题，因为我们已经认识到基于微服务架构构建安全的现代分布式应用的复杂性，而 Dapr 已经通过了多项独立的安全审计。为了抵御应用程序之间的中间人攻击，您需要进行加密，而 Dapr 通过其控制平面服务发出的 x.509 证书提供加密，这些证书会自动更新和滚动。为了提供对资源的访问控制，如状态存储、密钥、服务间调用，或发布/订阅特定主题的能力，您需要细粒度的访问控制策略（ACL）。当使用 spiffe 作为身份标准访问资源时，Dapr 提供了广泛的 ACL。当运行应用程序时，您可以将这些应用程序隔离在不同的命名空间中，以便进行运维部署和隔离。这些广泛的安全能力在下图中显示，这里有三个利用 Dapr 安全特性的微服务：

编程语言和 SDK

Dapr 以其编程语言、框架和工具拥抱所有的开发者社区。Dapr 被设计为可以通过 HTTP 和 gRPC 协议从任何编程语言中使用，这意味着您不需要在编译时包含任何依赖关系。当然，为了改善开发者的原生语言体验，Java、.NET、Python 和 Go 的 SDK 也以 v1.0 生产就绪的形式发布，这反映了它们在社区和组织中的成熟应用。这些 SDK 可以让您作为开发者，使用您最喜欢的开发环境，如 VS Code 或 IntelliJ。JavaScript/Node.js、C++、Rust 和 PHP 的 SDK 目前处于预览阶段，随后将发布 v1.0 版本。PHP SDK 包括对 Actor 的支持，这是社区为 Dapr 广泛且不断增长的编程语言列表做出贡献的一个极佳的例子。

展望未来

通过这个 v1.0 版本，我们为构建现代云原生应用所需的基本构建块奠定基础的旅程才刚刚起步。社区驱动意味着社区将在未来的版本中设定项目的优先级，其中许多优先级已经被投票通过。例如，增强现有构建块的亮点，包括在状态管理中使用 OData 查询和过滤多个值的能力。在 pub/sub 中，支持 CloudEvents v1.0 过滤功能，以根据消息内容过滤出用户感兴趣的事件。在可观测性方面，提供一个 API 用于 从应用中追踪事件，防止您不得不绑定到特定的监控类库，并使 actor 能够直接订阅 pub/sub 事件，从而开启了丰富的事件驱动场景。

新的构建块提案包括用于读写应用程序配置数据的配置 API，例如来自 Azure Configuration Manager 或 GCP Configuration Management。领导者选举构建块，提供创建单例实例、同步或锁定语义能力。用于网络级服务调用的透明代理构建块，使您能够根据 URL 或 DNS 地址来路由消息，以及用于熔断器、隔离舱和超时等模式的更多弹性构建块。

最后，在 v1.0 版本中，Dapr 集成了多个开发者框架，包括 ASP.NET Core、Java Spring Boot、Azure Functions 和 Logic Apps，而我们认为这还将继续，更多的开源框架如 Django、Nodejs 和 Kyma 都是潜在的例子。此外，考虑到 Dapr 的托管平台独立性，在虚拟机、边缘平台（如 Azure Stack Hub 或 AWS Outpost）和其他分布式系统平台上提供对 Dapr 控制平面一流的支持，可以实现应用的可移植性。

开始和贡献

我们希望您能试用 Dapr v1.0。您可以使用文档中的 入门指南 进行学习，然后通过 快速入门 来深入了解。如果你需要更多信息，样本库 是 Dapr 社区捐赠的不同的应用程序的展示。Dapr 文档 docs.dapr.io 是全面的指南，还有几本书，包括《 Learning Dapr》、《使用 Dapr 和 .NET 实践微服务》以及最新发布的免费电子书《Dapr for .NET 开发者》。如果您有任何疑问，遇到问题或想与社区的其他成员交流，Dapr 社区随时在 Discord 上欢迎您的到来。

对于 Dapr 来说，v1.0 版本的发布只是一个开始，在这个过程中，我们感谢并鼓励您的持续帮助、反馈和贡献。无论是编写新的组件，提出建议，贡献新的构建块，还是增强您最喜欢的语言的 SDK，我们都希望听到您的意见并与您一起参与。在这个微服务开发的时代，作为一名开发者，这是一个令人兴奋的时刻，Dapr 将释放您的生产力和创造力，轻松构建现代化的分布式应用。我们非常高兴的看到您继续使用这个项目，看到您使用它进行构建，并对 Dapr 的发展保持关注。

译者注

1. 英文原文来自 Dapr 官方网站博客文章 Announcing Dapr v1.0。
2. 译者所在的阿里云云原生团队深度参与了 Dapr 1.0 的开发，同时也正在内部小规模的试点 Dapr ，稍后将分享阿里云在 Dapr 上的实践。
3. 文中提到的 《 Learning Dapr》 一书，译者所在的团队正在翻译中，预计很快就将出版发行，欢迎关注。
4. Dapr 中文社区 目前正在组织翻译 Dapr 的官方文档，预计不久将完成部分章节并在官方上线，同样欢迎关注，更欢迎一起参与。

译者简介

敖小剑，资深码农，十九年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人。专注于基础架构，Cloud Native 拥护者，敏捷实践者，坚守开发一线打磨匠艺的架构师。曾在亚信、爱立信、唯品会、蚂蚁金服等任职，对基础架构和微服务有过深入研究和实践。目前就职于阿里云云原生应用平台从事 Service Mesh、Serverless、Multiple Runtime 等云原生产品设计和开发。

2021新年开工，Rainbond迎来了重量级版本5.3发布，我们在云原生应用的治理、观测方面进一步耕耘，为社区用户带来了更多开箱即用的能力。为了进一步降低新用户安装和多集群部署的门槛，我们重新实现了产品安装流程，支持UI化对接公有云资源和自建基础设施。同时在应用交付、应用运维和平台管理方面做了大量的优化改进。

Rainbond 是云原生且易用的云原生应用管理平台。云原生应用交付的最佳实践，简单易用。专注于以应用为中心的理念。赋能企业搭建云原生开发云、云原生交付云。

对于企业： Rainbond 是开箱即用的云原生平台，借助 Rainbond 可以快速完成企业研发和交付体系的云原生转型。

对于开发者： 基于 Rainbond 开发、测试和运维企业业务应用，开箱即用地获得全方位的云原生技术能力。包括但不仅限于持续集成、服务治理、架构支撑、多维度应用观测、流量管理。

对于项目交付： 基于 Rainbond 搭建产品版本化管理体系，搭建标准化客户交付环境，使传统的交付流程可以自动化、简单化和可管理。

重要新特性

支持云原生应用治理模式切换

应用治理模式切换是指可以无侵入地变更应用下组件间通信治理模式，过去的版本中Rainbond默认为内置的ServiceMesh模式。 Rainbond 致力于无侵入，松耦合的应用管理理念。松耦合体现在多个方面，应用治理模式可切换就是其中之一。

• 服务间松耦合

对于微服务的核心理念是，系统中的各个服务可被独立开发、独立部署，独立升级，各个服务之间是松耦合的。云原生应用架构理念是进一步强调架构的松耦合，降低服务之间相互依赖的程度。Rainbond 开箱即用的服务治理思想使部署到平台的应用天然形成微服务架构。

• 应用和运行环境松耦合

应用研发、打包独立化、标准化，通过标准化的平台实现交付到任何运行环境中。Rainbond 提供了应用模型开发、发布、分享、安装全链路支持，服务于应用交付场景。

• 服务治理能力与业务逻辑解耦

这是我们新版本的重点，我们引入了应用级治理模式切换功能，实现服务治理能力可动态切换，无需业务逻辑变更，为业务提供不同的治理能力。当前版本我们支持在内置 ServiceMesh 治理模式和 Kubernetes 原生模式直接切换。有了这套体系，未来的版本中将实现用户自定义治理模式，引入 Istio、Linkd 等成熟的 ServiceMesh 框架。

详细使用说明参考文档 应用治理模式切换

支持组件自定义业务监控和可视化

Rainbond 希望提供给开发者对应用全方位的监控能力。过去的版本中已经包括资源监控、性能分析、状态检测等维度。本次更新，提供给开发者在业务维度自定义监控及可视化的能力。Prometheus 已经成功云原生监控领域的事实规范，Rainbond 支持开发者基于 Prometheus 规范定义业务监控指标，通过配置监控点后由 Rainbond 自动发现并收集监控数据，并提供给用户进行历史数据查询和可视化。用户可以借助插件安装社区已有的 Exporter 插件，便捷的扩展业务监控能力。在自定义可视化面板中用户可以绘制关于应用资源占用、业务性能、网关流量全方位的观察指标图形。

详细使用说明参考文档 业务自定义监控

全新的控制台和集群安装方式

为了进一步降低用户的使用 Rainbond 的门槛，在 5.3 版本中我们将控制台的安装运维和集群端的安装运维解耦合。用户仅需一条 Docker run 命令即可再任意有 Docker 环境中将 Rainbond 控制台运行起来。在集群安装维度，新增了阿里云 ACK集群、对接已有 Kubernetes 集群、从主机便捷安装集群等多种途径，帮助用户快速完成资源池化。开箱即用的能力可以帮助用户在云端或私有设施中快速的搭建Kubernetes集群。

详细使用说明参考文档 快速安装

应用配置组

云原生应用推荐使用环境变量进行配置管理。因此我们经常需要在同一个应用的多个组件中添加相同的配置。比如一个应用下有多个组件使用同一个 Oracle 数据库，我们通过环境变量来配置 Oracle 数据库的连接信息。管理和配置需要做很多重复的事。借助应用配置组即可将配置信息在应用级统一管理，批量更改生效，大大降低开发者的操作次数。

详细使用参考文档 应用配置组

其他新特性和变化

• 应用组件库支持应用模型的版本管理和详情设置。

• 应用模型离线导出规范改进，导出文件大小显著降低（向下不兼容）。

• 应用模版离线导入改进，支持并行导入多个应用模型。

• 支持控制台数据备份和迁移。

• 改进 Oauth2.0 支持，现已支持 Github，Gitlab，Gitee，钉钉，阿里云等第三方Oauth认证。

• 应用网关新增支持会话保持负载均衡算法，对无法实现完全无状态化的应用可实现水平扩容。

• 团队视图应用列表排序改进，基于应用操作活跃情况进行排序，便于开发者快速定位操作的应用。

• 新增应用维度资源占用情况数据统计和展示，应用整体状况更容易掌握。

• 应用发布流程改进，支持发布时灵活编辑发布的组件数量，移除了安装的组件不能发布的限制。

• 应用升级体系增加了对插件、配置组等属性的支持。

• 支持 Java Maven 配置管理，移除了maven.goodrain.me的支持，默认采用阿里云Maven源，用户可自定义配置。

• 移除 rbd-repo 组件降低资源消耗，源代码构建资源下载和缓存能力由新增的rbd-resource-proxy提供。

• Rainbond 项目切换为 gomod 管理。

• Rainbond console 开发语言 python 版本从2.7升级到 3.6。

• Rainbond console 支持SQLite3数据库。

了解更多

学习更多Rainbond知识，访问Rainbond项目官网：https://www.rainbond.com

关注Rainbond开源项目: https://github.com/goodrain/rainbond

开始快速安装体验: 安装参考文档

加入Rainbond社区 钉钉群，随时参与社区交流，近期会举办多场以5.3.0新版本为主题的在线分享，进群关注。

作者 | 计缘
来源|阿里巴巴云原生公众号

众所周知，游戏行业在当今的互联网行业中算是一棵常青树。在疫情之前的 2019 年，中国游戏市场营收规模约 2884.8 亿元，同比增长 17.1%。2020 年因为疫情，游戏行业更是突飞猛进。玩游戏本就是中国网民最普遍的娱乐方式之一，疫情期间更甚。据不完全统计，截至 2019 年，中国移动游戏用户规模约 6.6 亿人，占中国总网民规模 8.47 亿的 77.92%，可见游戏作为一种低门槛、低成本的娱乐手段，已成为大部分人生活中习以为常的一部分。

对于玩家而言，市面上的游戏数量多如牛毛，那么玩家如何能发现和认知到一款游戏，并且持续的玩下去恐怕是所有游戏厂商需要思考的问题。加之 2018 年游戏版号停发事件，游戏厂商更加珍惜每一个已获得版号的游戏产品，所以这也使得“深度打磨产品质量”和“提高运营精细程度”这两个游戏产业发展方向成为广大游戏厂商的发展思路，无论是新游戏还是老游戏都在努力落实这两点：

• 新游戏：面向玩家需要提供更充足的推广资源和更完整的游戏内容。
• 老游戏：通过用户行为分析，投入更多的精力和成本，制作更优质的版本内容。

这里我们重点来看新游戏。一家游戏企业辛辛苦苦研发三年，等着新游戏发售时一飞冲天。那么问题来了，新游戏如何被广大玩家看到？

首先来看看游戏行业公司的分类：

• 游戏研发商：研发游戏的公司，生产和制作游戏内容。比如王者荣耀的所有英雄设计、游戏战斗场景、战斗逻辑等，全部由游戏研发公司提供。
• 游戏发行商：游戏发行商的主要工作分三大块：市场工作、运营工作、客服工作。游戏发行商把控游戏命脉，市场工作核心是导入玩家，运营工作核心是将用户价值最大化、赚取更多利益。

• 游戏平台/渠道商：游戏平台和渠道商的核心目的就是曝光游戏，让尽量多的人能发现你的游戏。

这三种类型的业务，有专注于其中某一领域的独立公司，也有能承接全部业务的公司，但无论那一种，这三者之间的关系是不会变的：

所以不难理解，想让更多的玩家看到你的游戏，游戏发行和运营是关键。通俗来讲，如果你的游戏出现在目前所有大家熟知的平台广告中，那么最起码游戏的新用户注册数量是很可观的。因此这就引入了一个关键词：买量。

根据数据显示，2019 年月均买量手游数达 6000+ 款，而 2018 年仅为 4200 款。另一方面，随着抖音、微博等超级 APP 在游戏买量市场的资源倾斜，也助推手游买量的效果和效率有所提升，游戏厂商更愿意使用买量的方式来吸引用户。

但需要注意的是，在游戏买量的精准化程度不断提高的同时，买量的成本也在节节攀升，唯有合理配置买量、渠道与整合营销之间的关系，才能将宣发资源发挥到最大的效果。

通俗来讲，买量其实就是在各大主流平台投放广告，广大用户看到游戏广告后，有可能会点击广告，然后进入游戏厂商的宣传页面，同时会采集用户的一些信息，然后游戏厂商对采集到的用户信息进行大数据分析，进行进一步的定向推广。

游戏运营核心诉求

游戏厂商花钱买量，换来的用户信息以及新用户注册信息是为持续的游戏运营服务的，那么这个场景的核心诉求就是采集用户信息的完整性。

比如说，某游戏厂商一天花 5000w 投放广告，在某平台某时段产生了每秒 1w 次的广告点击率，那么在这个时段内每一个点击广告的用户信息要完整的被采集到，然后入库进行后续分析。这就对数据采集系统提出了很高的要求。

这其中，最核心的一点就是系统暴露接口的环节要能够平稳承载买量期间不定时的流量脉冲。在买量期间，游戏厂商通常会在多个平台投放广告，每个平台投放广告的时间是不一样的，所以就会出现全天不定时的流量脉冲现象。如果这个环节出现问题，那么相当于买量的钱就打水漂了。

数据采集系统传统架构

上图是一个相对传统的数据采集系统架构，最关键的就是暴露 HTTP 接口回传数据这部分，这部分如果出问题，那么采集数据的链路就断了。但这部分往往会面临两个挑战：

• 当流量脉冲来的时候，这部分是否可以快速扩容以应对流量冲击。
• 游戏运营具备潮汐特性，并非天天都在进行，这就需要考虑如何优化资源利用率。

通常情况下，在游戏有运营活动之前，会提前通知运维同学，对这个环节的服务增加节点，但要增加多少其实是无法预估的，只能大概拍一个数字。这是在传统架构下经常会出现的场景，这就会导致两个问题：

• 流量太大，节点加少了，导致一部分流量的数据没有采集到。
• 流量没有预期那么大，节点加多了，导致资源浪费。

数据采集系统 Serverless 架构

我们可以通过函数计算 FC 来取代传统架构中暴露 HTTP 回传数据这部分，从而完美解决传统架构中存在问题，参考文章：《资源成本双优化！看 Serverless 颠覆编程教育的创新实践》。

先来看架构图：

传统架构中的两个问题均可以通过函数计算百毫秒弹性的特性来解决。我们并不需要去估算营销活动会带来多大的流量，也不需要去担心和考虑对数据采集系统的性能，运维同学更不需要提前预备 ECS。

因为函数计算的极致弹性特性，当没有买量、没有营销活动的时候，函数计算的运行实例是零。有买量活动时，在流量脉冲的情况下，函数计算会快速拉起实例来承载流量压力；当流量减少时，函数计算会及时释放没有请求的实例进行缩容。所以 Serverless 架构带来的优势有以下三点：

• 无需运维介入，研发同学就可以很快的搭建出来。
• 无论流量大小，均可以平稳的承接。
• 函数计算拉起的实例数量可以紧贴流量大小的曲线，做到资源利用率最优化，再加上按量计费的模式，可以最大程度优化成本。

架构解析

从上面的架构图可以看到，整个采集数据阶段，分了两个函数来实现，第一个函数的作用是单纯的暴露 HTTP 接口接收数据，第二个函数用于处理数据，然后将数据发送至消息队列 Kafka 和数据库 RDS。

1. 接收数据函数

我们打开函数计算控制台，创建一个函数：

• 函数类型：HTTP（即触发器为 HTTP）
• 函数名称：receiveData
• 运行环境：Python3

• 函数实例类型：弹性实例
• 函数执行内存：512MB
• 函数运行超时时间：60 秒
• 函数单实例并发度：1

• 触发器类型：HTTP 触发器
• 触发器名称：defaultTrigger
• 认证方式：anonymous（即无需认证）
• 请求方式：GET，POST

创建好函数之后，我们通过在线编辑器编写代码：

# -*- coding: utf-8 -*-
import logging
import json
import urllib.parse
HELLO_WORLD = b'Hello world!\n'
def handler(environ, start_response):
    logger = logging.getLogger() 
    context = environ['fc.context']
    request_uri = environ['fc.request_uri']
    for k, v in environ.items():
      if k.startswith('HTTP_'):
        # process custom request headers
        pass
    try:        
        request_body_size = int(environ.get('CONTENT_LENGTH', 0))    
    except (ValueError):        
        request_body_size = 0   
    # 接收回传的数据
    request_body = environ['wsgi.input'].read(request_body_size)  
    request_body_str = urllib.parse.unquote(request_body.decode("GBK"))
    request_body_obj = json.loads(request_body_str)
    logger.info(request_body_obj["action"])
    logger.info(request_body_obj["articleAuthorId"])

    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return [HELLO_WORLD]

此时的代码非常简单，就是接收用户传来的参数，我们可以调用接口进行验证：

可以在函数的日志查询中看到此次调用的日志：

同时，我们也可以查看函数的链路追踪来分析每一个步骤的调用耗时，比如函数接到请求→冷启动（无活跃实例时）→准备代码→执行初始化方法→执行入口函数逻辑这个过程：

从调用链路图中可以看到，刚才的那次请求包含了冷启动的时间，因为当时没有活跃实例，整个过程耗时 418 毫秒，真正执行入口函数代码的时间为 8 毫秒。

当再次调用接口时，可以看到就直接执行了入口函数的逻辑，因为此时已经有实例在运行，整个耗时只有 2.3 毫秒：

2. 处理数据的函数

第一个函数是通过在函数计算控制台在界面上创建的，选择了运行环境是 Python3，我们可以在官方文档中查看预置的 Python3 运行环境内置了哪些模块，因为第二个函数要操作 Kafka 和 RDS，所以需要我们确认对应的模块。

从文档中可以看到，内置的模块中包含 RDS 的 SDK 模块，但是没有 Kafka 的 SDK 模块，此时就需要我们手动安装 Kafka SDK 模块，并且创建函数也会使用另一种方式。

1）Funcraft

Funcraft 是一个用于支持 Serverless 应用部署的命令行工具，能帮助我们便捷地管理函数计算、API 网关、日志服务等资源。它通过一个资源配置文件（template.yml），协助我们进行开发、构建、部署操作。
所以第二个函数我们需要使用 Fun 来进行操作，整个操作分为四个步骤：

• 安装 Fun 工具。
• 编写 template.yml 模板文件，用来描述函数。
• 安装我们需要的第三方依赖。
• 上传部署函数。

2）安装 Fun

Fun 提供了三种安装方式：

• 通过 npm 包管理安装 —— 适合所有平台（Windows/Mac/Linux）且已经预装了 npm 的开发者。
• 通过下载二进制安装 —— 适合所有平台（Windows/Mac/Linux）。
• 通过 Homebrew 包管理器安装 —— 适合 Mac 平台，更符合 MacOS 开发者习惯。

文本示例环境为 Mac，所以使用 npm 方式安装，非常的简单，一行命令搞定：

sudo npm install @alicloud/fun -g

安装完成之后。在控制终端输入 fun 命令可以查看版本信息：

$ fun --version
3.6.20

在第一次使用 fun 之前需要先执行 fun config 命令进行配置，按照提示，依次配置 Account ID、Access Key Id、Secret Access Key、 Default Region Name 即可。其中 Account ID、Access Key Id 你可以从函数计算控制台首页的右上方获得：

fun config

? Aliyun Account ID *01
? Aliyun Access Key ID *qef6j
? Aliyun Access Key Secret *UFJG
? Default region name cn-hangzhou
? The timeout in seconds for each SDK client invoking 60
? The maximum number of retries for each SDK client 3

3）编写 template.yml

新建一个目录，在该目录下创建一个名为 template.yml 的 YAML 文件，该文件主要描述要创建的函数的各项配置，说白了就是将函数计算控制台上配置的那些配置信息以 YAML 格式写在文件里：

ROSTemplateFormatVersion: '2015-09-01'
Transform: 'Aliyun::Serverless-2018-04-03'
Resources:
FCBigDataDemo:
Type: 'Aliyun::Serverless::Service'
Properties:
Description: 'local invoke demo'
VpcConfig:
VpcId: 'vpc-xxxxxxxxxxx'
VSwitchIds: [ 'vsw-xxxxxxxxxx' ]
SecurityGroupId: 'sg-xxxxxxxxx'
LogConfig:
Project: fcdemo
Logstore: fc_demo_store
dataToKafka:
Type: 'Aliyun::Serverless::Function'
Properties:
Initializer: index.my_initializer
Handler: index.handler
CodeUri: './'
Description: ''
Runtime: python3

我们来解析以上文件的核心内容：

• FCBigDataDemo：自定义的服务名称。通过下面的 Type 属性标明是服务，即 Aliyun::Serverless::Service。
• Properties：Properties 下的属性都是该服务的各配置项。
• VpcConfig：服务的 VPC 配置，包含：
  • VpcId：VPC ID。
  • VSwitchIds：交换机 ID，这里是数组，可以配置多个交换机。
  • SecurityGroupId：安全组 ID。
• LogConfig：服务绑定的日志服务（SLS）配置，包含：
  • Project：日志服务项目。
  • Logstore：LogStore 名称。
• dataToKafka：该服务下自定义的函数名称。通过下面的 Type 属性标明是函数，即 Aliyun::Serverless::Function。
• Properties：Properties下的属性都是该函数的各配置项。
• Initializer：配置初始化函数。
• Handler：配置入口函数。
• Runtime：函数运行环境。

目录结构为：

4）安装第三方依赖

服务和函数的模板创建好之后，我们来安装需要使用的第三方依赖。在这个示例的场景中，第二个函数需要使用 Kafka SDK，所以可以通过 fun 工具结合 Python 包管理工具 pip 进行安装：

fun install --runtime python3 --package-type pip kafka-python

执行命令后有如下提示信息：

此时我们会发现在目录下会生成一个.fun文件夹 ，我们安装的依赖包就在该目录下：

5）部署函数

现在编写好了模板文件以及安装好了我们需要的 Kafka SDK 后，还需要添加我们的代码文件 index.py，代码内容如下：

# -*- coding: utf-8 -*-
import logging
import json
import urllib.parse
from kafka import KafkaProducer
producer = None
def my_initializer(context):    
    logger = logging.getLogger() 
    logger.info("init kafka producer")
    global producer
    producer = KafkaProducer(bootstrap_servers='XX.XX.XX.XX:9092,XX.XX.XX.XX:9092,XX.XX.XX.XX:9092')
def handler(event, context):
    logger = logging.getLogger()   
    # 接收回传的数据
    event_str = json.loads(event)
    event_obj = json.loads(event_str)
    logger.info(event_obj["action"])
    logger.info(event_obj["articleAuthorId"])
    # 向Kafka发送消息
    global producer
    producer.send('ikf-demo', json.dumps(event_str).encode('utf-8'))
    producer.close()
    return 'hello world'

代码很简单，这里做以简单的解析：

• my_initializer：函数实例被拉起时会先执行该函数，然后再执行 handler 函数 ，当函数实例在运行时，之后的请求都不会执行 my_initializer 函数 。一般用于各种连接的初始化工作，这里将初始化 Kafka Producer 的方法放在了这里，避免反复初始化 Produer。
•  handler：该函数只有两个逻辑，接收回传的数据和将数据发送至 Kafka 的指定 Topic。
• 下面通过 fun deploy 命令部署函数，该命令会做两件事：
  • 根据 template.yml 中的配置创建服务和函数。
  • 将 index.py 和 .fun 上传至函数中。

登录函数计算控制台，可以看到通过 fun 命令部署的服务和函数：

进入函数，也可以清晰的看到第三方依赖包的目录结构：

3. 函数之间调用

目前两个函数都创建好了，下面的工作就是由第一个函数接收到数据后拉起第二个函数发送消息给 Kafka。我们只需要对第一个函数做些许改动即可：

# -*- coding: utf-8 -*-
import logging
import json
import urllib.parse
import fc2
HELLO_WORLD = b'Hello world!\n'
client = None
def my_initializer(context):    
    logger = logging.getLogger() 
    logger.info("init fc client")
    global client
    client = fc2.Client(
        endpoint="http://your_account_id.cn-hangzhou-internal.fc.aliyuncs.com",
        accessKeyID="your_ak",
        accessKeySecret="your_sk"
    )
def handler(environ, start_response):
    logger = logging.getLogger() 
    context = environ['fc.context']
    request_uri = environ['fc.request_uri']
    for k, v in environ.items():
      if k.startswith('HTTP_'):
        # process custom request headers
        pass
    try:        
        request_body_size = int(environ.get('CONTENT_LENGTH', 0))    
    except (ValueError):        
        request_body_size = 0   
    # 接收回传的数据
    request_body = environ['wsgi.input'].read(request_body_size)  
    request_body_str = urllib.parse.unquote(request_body.decode("GBK"))
    request_body_obj = json.loads(request_body_str)
    logger.info(request_body_obj["action"])
    logger.info(request_body_obj["articleAuthorId"])
    global client
    client.invoke_function(
        'FCBigDataDemo',
        'dataToKafka',
        payload=json.dumps(request_body_str),
        headers = {'x-fc-invocation-type': 'Async'}
    )

    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return [HELLO_WORLD]

如上面代码所示，对第一个函数的代码做了三个地方的改动：

• 导入函数计算的库：import fc2
• 添加初始化方法，用于创建函数计算 Client：

def my_initializer(context):
        logger = logging.getLogger()
        logger.info("init fc client")
        global client
        client = fc2.Client(
            endpoint="http://your_account_id.cn-hangzhou-internal.fc.aliyuncs.com",
            accessKeyID="your_ak",
            accessKeySecret="your_sk"
)

这里需要注意的时，当我们在代码里增加了初始化方法后，需要在函数配置中指定初始化方法的入口：

• 通过函数计算 Client 调用第二个函数

global client
    client.invoke_function(
            'FCBigDataDemo',
            'dataToKafka',
          payload=json.dumps(request_body_str),
            headers = {'x-fc-invocation-type': 'Async'}
)

invoke_function 函数有四个参数：

• 第一个参数：调用函数所在的服务名称。
• 第二个参数：调用函数的函数名称。
• 第三个参数：向调用函数传的数据。
• 第四个参数：调用第二个函数 Request Header 信息。这里主要通过 x-fc-invocation-type 这个 Key 来设置是同步调用还是异步调用。这里设置 Async 为异步调用。

如此设置，我们便可以验证通过第一个函数提供的 HTTP 接口发起请求→采集数据→调用第二个函数→将数据作为消息传给 Kafka 这个流程了。

使用两个函数的目的

到这里有些同学可能会有疑问，为什么需要两个函数，而不在第一个函数里直接向 Kafka 发送数据呢？我们先来看这张图：

当我们使用异步调用函数时，在函数内部会默认先将请求的数据放入消息队列进行第一道削峰填谷，然后每一个队列在对应函数实例，通过函数实例的弹性拉起多个实例进行第二道削峰填谷。所以这也就是为什么这个架构能稳定承载大并发请求的核心原因之一。

4. 配置 Kafka

在游戏运营这个场景中，数据量是比较大的，所以对 Kafka 的性能要求也是比较高的，相比开源自建，使用云上的 Kafka 省去很多的运维操作，比如：

• 我们不再需要再维护 Kafka 集群的各个节点。
• 不需要关心主从节点数据同步问题。
• 可以快速、动态扩展 Kafka 集群规格，动态增加 Topic，动态增加分区数。
• 完善的指标监控功能，消息查询功能。

总的来说，就是一切 SLA 都有云上兜底，我们只需要关注在消息发送和消息消费即可。

所以我们可以打开 Kafka 开通界面，根据实际场景的需求一键开通 Kafka 实例，开通 Kafka 后登录控制台，在基本信息中可以看到 Kafka 的接入点：

• 默认接入点：走 VPC 内网场景的接入点。
• SSL 接入点：走公网场景的接入点。

将默认接入点配置到函数计算的第二个函数中即可。

....
producer = KafkaProducer(bootstrap_servers='XX.XX.XX.XX:9092,XX.XX.XX.XX:9092,XX.XX.XX.XX:9092')
....

然后点击左侧控制台 Topic 管理，创建 Topic：

将创建好的 Topic 配置到函数计算的第二个函数中即可。

...
# 第一个参数为Topic名称
producer.send('ikf-demo', json.dumps(event_str).encode('utf-8'))
...

上文已经列举过云上 Kafka 的优势，比如动态增加 Topic 的分区数，我们可以在 Topic 列表中，对 Topic 的分区数进行动态调整：

单 Topic 最大支持到 360 个分区，这是开源自建无法做到的。

接下来点击控制台左侧 Consumer Group 管理，创建 Consumer Group：

至此，云上的 Kafka 就算配置完毕了，即 Producer 可以往刚刚创建的 Topic 中发消息了，Consumer 可以设置刚刚创建的 GID 以及订阅 Topic 进行消息接受和消费。

Flink Kafka 消费者

在这个场景中，Kafka 后面往往会跟着 Flink，所以这里简要给大家介绍一下在 Flink 中如何创建 Kafka Consumer 并消费数据。代码片段如下：

final ParameterTool parameterTool = ParameterTool.fromArgs(args);
String kafkaTopic = parameterTool.get("kafka-topic","ikf-demo");
String brokers = parameterTool.get("brokers", "XX.XX.XX.XX:9092,XX.XX.XX.XX:9092,XX.XX.XX.XX:9092");
Properties kafkaProps = new Properties();
kafkaProps.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, brokers);
kafkaProps.put(ConsumerConfig.GROUP_ID_CONFIG, "ikf-demo");
FlinkKafkaConsumer<UserBehaviorEvent> kafka = new FlinkKafkaConsumer<>(kafkaTopic, new UserBehaviorEventSchema(), kafkaProps);
kafka.setStartFromLatest();
kafka.setCommitOffsetsOnCheckpoints(false);
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
DataStreamSource<UserBehaviorEvent> dataStreamByEventTime = env.addSource(kafka);

以上就是构建 Flink Kafka Consumer 和添加 Kafka Source 的代码片段，还是非常简单的。

压测验证

至此，整个数据采集的架构就搭建完毕了，下面我们通过压测来检验一下整个架构的性能。这里使用阿里云 PTS 来进行压测。

创建压测场景

打开 PTS 控制台，点击左侧菜单创建压测/创建 PTS 场景：

在场景配置中，将第一个函数计算函数暴露的 HTTP 接口作为串联链路，配置如下图所示：

接口配置完后，我们来配置施压：

• 压力模式：
  • 并发模式：指定有多少并发用户同时发请求。
  • RPS模式：指定每秒有多少请求数。
• 递增模式：在压测过程中可以通过手动调节压力，也可以自动按百分比递增压力。
• 最大并发：同时有多少个虚拟用户发起请求。
• 递增百分比：如果是自动递增的话，按这里的百分比递增。
• 单量级持续时长：在未完全达到压力全量的时候，每一级梯度的压力保持的时长。
• 压测总时长：一共需要压测的时长。

这里因为资源成本原因，并发用户数设置为 2500 来进行验证。

从上图压测中的情况来看，TPS 达到了 2w 的封顶，549w+ 的请求，99.99% 的请求是成功的，那 369 个异常也可以点击查看，都是压测工具请求超时导致的。

总结

至此，整个基于 Serverless 搭建的大数据采集传输的架构就搭建好了，并且进行了压测验证，整体的性能也是不错的，并且整个架构搭建起来也非常简单和容易理解。这个架构不光适用于游戏运营行业，其实任何大数据采集传输的场景都是适用的，目前也已经有很多客户正在基于 Serverless 的架构跑在生产环境，或者正走在改造 Serverless 架构的路上。

来源|阿里巴巴云原生公众号

美国当地时间 2021 年 2 月 2 日，全球顶级开源社区云原生计算基金会(Cloud Native Computing Foundation，简称 CNCF)正式宣布其新一届技术监督委员会(Technical Oversight Committee，简称 TOC)席位改选结果。阿里云高级技术专家张磊入选，成为本届 TOC 11 个席位中唯一一位来自中国的代表。

CNCF 在官方公告中表示，张磊的入选是因为其在 Kubernetes 领域所做的突出贡献：“张磊是 Kubernetes 社区的共同维护者，也是 CNCF App Delivery SIG 的 Co-chair，在阿里巴巴主导 Kubernetes 和大型集群管理系统等工作。”

唯一一位来自中国的现任 CNCF TOC 委员

CNCF 成立于 2015 年 7 月，隶属于 Linux 基金会，围绕“云原生”服务云计算，致力于维护和集成开源技术，支持编排容器化微服务架构应用。目前，CNCF 有会员公司超过 300 家，其中包括 AWS、Azure、Google、阿里云等大型云计算厂商。CNCF 的技术监督委员会由 11 位具有丰富技术知识和行业背景的代表组成，为云原生社区提供技术领导。

自 2017 年以来，阿里巴巴在云原生技术领域投入了巨大力量，深度参与到 ETCD、Kubernetes、ContainerD 等多个顶级开源项目的开发与维护当中，并通过云原生技术栈完成了整体基础架构体系的自我升级，如自主开源 Dubbo、RocketMQ 等明星项目，捐献给 Apache 基金会并以顶级项目的身份毕业；Spring Cloud Alibaba 开源两年已经成为 Spring Cloud 最活跃、开发体验最好的 Spring Cloud 实现；Dragonfly 晋升成为 CNCF 孵化项目，OpenYurt、OpenKruise 进入CNCF Sandbox；联合微软云发布全球首个开放应用模型 OAM，共同引领云原生标准应用交付生态，随后推出了基于 OAM 的云原生平台核心引擎 KubeVela ，填补了Kubernetes 生态在构建标准应用交付系统领域的空白；联合南京大学开源了云原生基础架构项目 Fluid，补齐了 CNCF 全景中让大数据和 AI 拥抱云原生的重要组件；Serverless Devs 开发者平台源，成为国内首个进驻 CNCF Landsacpe Tools 的 Serverless 工具等。

截至 2020 年底，阿里巴巴已有超过 10 个项目进入 CNCF Landscape；对 Kubernetes 项目的贡献量也位居全球前 10。

来自阿里云的张磊成为现任 CNCF TOC 中唯一一位来自中国的委员。1989 年出生的他，是 Kubernetes 社区最年轻的早期维护者之一，曾发起和参与设计了 Kubernetes 多个基础特性如 CRI（容器运行时接口）、等价类调度、拓扑资源管理等。因在 Kubernetes 社区的持续影响力，张磊于 2016 年就被推举为 CNCF 官方大使，连续担任多届 KubeCon 评审、KeynoteSpeaker。2019 年，张磊以最高票当选为 CNCF 应用交付领域小组 co-chair，是至今为止 CNCF 7 大领域小组中唯一的华人 co-chair。

张磊，阿里云高级技术专家、CNCF 技术监督委员会委员

加入阿里云后，张磊重点参与设计了阿里云云原生应用基础设施，参与维护了国内最大公共云容器集群。他提出的“以应用为中心”的标准应用交付体系，催生出了一系列前瞻性的云原生应用管理领域头部开源技术。

此外，张磊还带领团队联合微软云 CTO Office 共同提出了“开放应用模型”开源项目（OAM），这是业界第一个云原生应用交付与管理领域的标准模型与框架项目，已经迅速成为了包括 MasterCard、第四范式等国内外十余家企业构建云原生应用平台的基础模型，并被工信部信通院标准化立项“云计算开放架构通用需求和参考框架”，被美国知名科技媒体 TheNewStack 评选为“Top Cloud Native Technology Trends from 2020”、InfoQ 评选为“2020 年十大新锐开源项目”。

张磊：云原生带来的全新应用交付方式正在成为主流

从 CNCF、阿里云和张磊一直专注的事情中，我们不难看到一个明确的发展趋势，那就是在今天，没有人再会去质疑一个平台团队采纳 Kubernetes 做为本身的基础设施的合理性。事实上，2020 年的 Kubernetes 项目已经很接近于完成了它最重要的使命，即：为云计算基础设施带来一层可让平台团队基于此构造“一切”的平台层抽象。

然而，“云原生”究竟是什么？它为什么对云计算生态充满吸引力？中国本土的云原生又该走向何方？我们一起听听新晋 CNCF TOC 成员张磊的看法。

Q：祝贺你成为 CNCF 全球 11 位 TOC 委员之一！先和大家介绍下自己吧？

张磊：我目前在阿里云负责云原生应用平台基础设施相关的技术工作，同时也在参与和推动 OAM/KubeVela，OpenKruise 和 OpenYurt 等阿里核心开源项目的建设工作。在加入阿里云之前，我主要工作在 Kubernetes 社区上游，是 CRI、调度器等多个核心特性的早期发起者与维护者之一，也是 KataContainers 项目组的成员。近期，我们正在同 CNCF TOC 和 40 多家参与公司一起推进一个厂商中立的 GitOps 应用交付工作组的成立。

Q：你如何看待 Cloud Native 近几年的发展和演变？

张磊：随着云原生技术的极大普及，我们已经看到这种全新的应用交付方式正在结合“标准应用模型”、“基于 Mesh 的渐进式发布”等关键技术一起，成为业界构建应用平台的主流方向。

今天大家所熟知的云原生（Cloud Native）理念，本质上是一套“以利用云计算技术为用户降本增效”的最佳实践与方法论。所以，云原生这个术语自诞生，到壮大，再到今天的极大普及，都处于一个不断的自我演进与革新的过程当中。

无论是 2014 年以 Docker 为代表的容器技术的巨大成功，还是 2019 年后以  Kubernetes 为代表的容器编排技术的迅速崛起，再到今天云原生几乎“包罗万象”般的无处不在，都是 Cloud Native 理念在从概念到实践，再沉淀出新的理念和架构过程的真实写照。这种以一个核心理念为基础的不断演进、逐步影响到整个云计算领域方方面面的过程，是近几年云原生生态发展壮大背后的一个主旋律。

Q：你在去年看到的云原生领域主要变化是什么？你认为它会带来什么影响？ 

张磊：在 2020 年，我们能够看到云原生的迅速普及正在给越来越多的领域带来基于“云”的变革，并且通过云原生体系让这些领域迅速融入到了云计算的能力池当中，从而为最终用户直接带来了“降本增效”的巨大价值。仅以 CNCF 开源社区为例，在 2020 年，阿里云有 OpenYurt 边缘容器项目（边缘领域革新）和 OpenKruise 工作负载管理（ 应用管理能力下沉）项目进入了 CNCF 沙箱，还有 Virtual Cluster （Serverless 基础设施领域革新）技术成为了 Kubernetes 官方子项目，更有多个核心项目比如 OAM/KubeVela （应用交付领域革新 + 能力下沉）正在孵化中。这些开源技术的涌现和普及，不仅为云原生生态的持续发展和演进提供了至关重要的牵引力，也正在不同领域里让“释放云计算红利”的核心目标真正成为现实。

2020 年的云原生依然是整个云计算生态中发展最迅速的一条主线脉络，而也正是伴随着这样的发展劲头，云原生在新的一年里，已经要开始思考它的下一步发展空间。事实上，咱们已经可以看到各类各样的厂商和团队在不一样的领域积极发力和探索。

Q：你认为 Cloud Native 未来将会走向何方？

张磊：今天云原生的发展趋势，正在离它所倡导的“软件天然生在云上、长在云上”越来越近，但也暴露出了原有的云原生技术底盘过分关注于基础设施抽象与管理、忽视了最终用户侧的体验和技术带来的诸多问题。而在 2020 年云原生领域的变化中，我们已能够看到云原生社区正逐步沿着“能力下沉、价值上浮”的路径向更贴近最终用户的方向靠拢。这也解释了为什么在 Kubernetes 之后，Service Mesh 正在迅速改变中间件与微服务治理技术，GitOps 正在对持续交付领域产生重至关重要的影响，而 OAM 和 Dapr 则正在进一步解决应用抽象模型与服务接入模型的问题。

我们预期在未来的几年内，云原生体系与生俱来的敏捷和用户粘性，会带着云计算的庞大能力池进一步普及到数据库、AI、边缘等更加垂直的领域当中，进而更广泛地影响云计算底层基础架构和云端应用的部署与分发方式。甚至可能会成为未来“云计算无处不在”的最真实写照。

Q：进入 TOC 之后，你会重点关注哪些领域？

张磊：在接下来，我会和 CNCF TOC 一起持续重点关注应用管理与交付、云原生编程模型、云端开发者体验等为最终用户带来直接价值的上层技术领域，联合社区的力量更好的孵化或者更多的吸纳这些领域中具备潜力的开源项目进入 CNCF。与此同时，TOC 也会把目光放的更长远，尤其是关注 WebAssembly、eBPF 等最近正在迅速崛起的底层关键技术。所以如果在不久的将来，CNCF 中最知名的项目不再是 Kubernetes 了，到时咱们千万不要觉得意外。

Q：对于如何推动中国本土环境下的云原生生态的发展，你有什么看法和建议吗？

张磊：实际上，今天在 CNCF 生态中大家正逐步形成一个非常好的认知，那就是今天全世界云原生普及最好、落地效果最扎实的社区，是中国的云原生社区，而不是自己都不用 Kubernetes 的 Google 或者 AWS。我们今天所具备的深度的人才储备和高速增长中的场景与大环境，既是让全世界云原生参与者羡慕不已的、得天独厚的条件，也是国内云原生生态取得迅速发展、能够最大程度释放云原生红利的重要原因之一。

在这个基础上，作为国内的云原生生态成员，我们实际上应该更加大胆的去创新，而不仅仅是 follow，同时也应该更大胆的去让我们的技术走向国际化舞台，积极借助像 CNCF 这样具有一定全球影响力的、并且咱们自己也有一定话语权的中立组织来构建属于我们自己的发声体系，主动吸纳来自北美、欧洲的用户、参与者与贡献者进入到我们的社区当中。当然，这里面自然少不了国内各个云原生领域厂商、社区成员和开源项目维护者们的通力协作。我的个人预期是，很快完全本土化运作的 KubeCon 峰会、跨公司跨地域的云原生编程马拉松等，都会在国内社区开花结果。

持续的生命力，是 “云原生”对云计算生态充满吸引力的源泉

云原生到底是什么？从云原生这个术语出现开始，就一直是很多初次接触云原生理念的工程师、团队和企业常常提出的困惑。

实际上，作为一套“以利用云计算技术为用户降本增效”的最佳实践与方法论，云原生都处于一个不断的自我演进与革新的过程当中。正如张磊在一篇文章中写道：这种“永远没有确切定义”的持续生命力，才正是“云原生”之所以对云计算生态充满吸引力的源泉。

“云原生的向前发展，需要依靠整个云原生社区不停歇的思考、沉淀与再创新进行补充和修正，才能让云原生的技术价值逐步‘上浮’，对最终用户产生直接的价值与体感，让构建简单、易用的云原生平台再也不是“阳春白雪”，这也是我一直在坚持的事情。”张磊表示。

作者 | 江昱

前言

图像分类是人工智能领域的一个热门话题。通俗解释就是，根据各自在图像信息中所反映的不同特征，把不同类别的目标区分开来的图像处理方法。

它利用计算机对图像进行定量分析，把图像或图像中的每个像元或区域划归为若干个类别中的某一种，以代替人的视觉判读。

图像分类在实际生产生活中也是经常遇到的，而且针对不同领域或者需求有着很强的针对性。例如通过拍摄花朵识别花朵信息、通过人脸比对人物信息等。

通常情况下，这些图像识别或者分类的工具，都是在客户端进行数据采集，在服务端进行运算获得结果，也就是说一般情况下都是有专门的 API 实现图像识别的。例如各大云厂商都会为我们有偿提供类似的能力：

阿里云图像识别页面：

华为云图像识别页面：

本文将会通过一个有趣的 Python 库，快速将图像分类的功能搭建在云函数上，并且和 API 网关结合，对外提供 API 功能，实现一个 Serverless 架构的“图像分类 API”。

首先和大家介绍一下需要的依赖库：ImageAI。通过该依赖的官方文档我们可以看到这样的描述：

ImageAI 是一个 python 库，旨在使开发人员能够使用简单的几行代码构建具有包含深度学习和计算机视觉功能的应用程序和系统。
ImageAI 本着简洁的原则，支持最先进的机器学习算法，用于图像预测、自定义图像预测、物体检测、视频检测、视频对象跟踪和图像预测训练。ImageAI 目前支持使用在 ImageNet-1000 数据集上训练的 4 种不同机器学习算法进行图像预测和训练。ImageAI 还支持使用在 COCO 数据集上训练的 RetinaNet 进行对象检测、视频检测和对象跟踪。最终，ImageAI 将为计算机视觉提供更广泛和更专业化的支持，包括但不限于特殊环境和特殊领域的图像识别。

也就是说这个依赖库，可以帮助我们完成基本的图像识别和视频的目标提取，虽然他给了一些数据集和模型，但是我们也可以根据自身需要对其进行额外的训练，进行定制化拓展。通过官方给的代码，我们可以看到一个简单的 Demo：

# -*- coding: utf-8 -*-
from imageai.Prediction import ImagePrediction

# 模型加载
prediction = ImagePrediction()
prediction.setModelTypeAsResNet()
prediction.setModelPath("resnet50_weights_tf_dim_ordering_tf_kernels.h5")
prediction.loadModel()

predictions, probabilities = prediction.predictImage("./picture.jpg", result_count=5 )
for eachPrediction, eachProbability in zip(predictions, probabilities):
    print(str(eachPrediction) + " : " + str(eachProbability))

当我们指定的 picture.jpg 图片为：

我们在执行之后的结果是：

laptop : 71.43893241882324
notebook : 16.265612840652466
modem : 4.899394512176514
hard_disc : 4.007557779550552
mouse : 1.2981942854821682

如果在使用过程中觉得模型 resnet50_weights_tf_dim_ordering_tf_kernels.h5 过大，耗时过长，可以按需求选择模型：

• SqueezeNet（文件大小：4.82 MB，预测时间最短，精准度适中）
• ResNet50 by Microsoft Research （文件大小：98 MB，预测时间较快，精准度高）
• InceptionV3 by Google Brain team （文件大小：91.6 MB，预测时间慢，精度更高）
• DenseNet121 by Facebook AI Research （文件大小：31.6 MB，预测时间较慢，精度最高）

模型下载地址可参考 Github 地址：
https://github.com/OlafenwaMoses/ImageAI/releases/tag/1.0

或者参考 ImageAI 官方文档：
https://imageai-cn.readthedocs.io/zh_CN/latest/ImageAI_Image_Prediction.html

项目 Serverless 化

将项目按照函数计算的需求，编写好入口方法，以及做好项目初始化，同时在当前项目下创建文件夹 model，并将模型文件拷贝到该文件夹：

项目整体流程：

实现代码：

# -*- coding: utf-8 -*-

from imageai.Prediction import ImagePrediction
import json
import uuid
import base64
import random

# Response
class Response:
    def __init__(self, start_response, response, errorCode=None):
        self.start = start_response
        responseBody = {
            'Error': {"Code": errorCode, "Message": response},
        } if errorCode else {
            'Response': response
        }
        # 默认增加uuid，便于后期定位
        responseBody['ResponseId'] = str(uuid.uuid1())
        print("Response: ", json.dumps(responseBody))
        self.response = json.dumps(responseBody)

    def __iter__(self):
        status = '200'
        response_headers = [('Content-type', 'application/json; charset=UTF-8')]
        self.start(status, response_headers)
        yield self.response.encode("utf-8")

# 随机字符串
randomStr = lambda num=5: "".join(random.sample('abcdefghijklmnopqrstuvwxyz', num))

# 模型加载
print("Init model")
prediction = ImagePrediction()
prediction.setModelTypeAsResNet()
print("Load model")
prediction.setModelPath("/mnt/auto/model/resnet50_weights_tf_dim_ordering_tf_kernels.h5")
prediction.loadModel()
print("Load complete")

def handler(environ, start_response):
    try:
        request_body_size = int(environ.get('CONTENT_LENGTH', 0))
    except (ValueError):
        request_body_size = 0
    requestBody = json.loads(environ['wsgi.input'].read(request_body_size).decode("utf-8"))

    # 图片获取
    print("Get pucture")
    imageName = randomStr(10)
    imageData = base64.b64decode(requestBody["image"])
    imagePath = "/tmp/" + imageName
    with open(imagePath, 'wb') as f:
        f.write(imageData)

    # 内容预测
    print("Predicting ... ")
    result = {}
    predictions, probabilities = prediction.predictImage(imagePath, result_count=5)
    print(zip(predictions, probabilities))
    for eachPrediction, eachProbability in zip(predictions, probabilities):
        result[str(eachPrediction)] = str(eachProbability)

    return Response(start_response, result)

所需要的依赖：

tensorflow==1.13.1
numpy==1.19.4
scipy==1.5.4
opencv-python==4.4.0.46
pillow==8.0.1
matplotlib==3.3.3
h5py==3.1.0
keras==2.4.3
imageai==2.1.5

编写部署所需要的配置文件：

ServerlessBookImageAIDemo:
  Component: fc
  Provider: alibaba
  Access: release
  Properties:
    Region: cn-beijing
    Service:
      Name: ServerlessBook
      Description: Serverless图书案例
      Log: Auto
      Nas: Auto
    Function:
      Name: serverless_imageAI
      Description: 图片目标检测
      CodeUri:
        Src: ./src
        Excludes:
          - src/.fun
          - src/model
      Handler: index.handler
      Environment:
        - Key: PYTHONUSERBASE
          Value: /mnt/auto/.fun/python
      MemorySize: 3072
      Runtime: python3
      Timeout: 60
      Triggers:
        - Name: ImageAI
          Type: HTTP
          Parameters:
            AuthType: ANONYMOUS
            Methods:
              - GET
              - POST
              - PUT
            Domains:
              - Domain: Auto

在代码与配置中，可以看到有目录：/mnt/auto/ 的存在，该部分实际上是 nas 挂载之后的地址，只需提前写入到代码中即可，下一个环节会进行 nas 的创建以及挂载点配置的具体操作。

项目部署与测试

在完成上述步骤之后，可以通过：

s deploy

进行项目部署，部署完成可以看到结果：

完成部署之后，可以通过：

s install docker

进行依赖的安装：

依赖安装完成可以看到在目录下生成了 .fun 的目录，该目录就是通过 docker 打包出来的依赖文件，这些依赖正是我们在 requirements.txt 文件中声明的依赖内容。

完成之后，我们通过：

s nas sync ./src/.fun

将依赖目录打包上传到 nas，成功之后再将 model 目录打包上传：

s nas sync ./src/model

完成之后可以通过：

s nas ls --all

查看目录详情：

完成之后，我们可以编写脚本进行测试，同样适用刚才的测试图片，通过代码：

import json
import urllib.request
import base64
import time

with open("picture.jpg", 'rb') as f:
    data = base64.b64encode(f.read()).decode()

url = 'http://35685264-1295939377467795.test.functioncompute.com/'

timeStart = time.time()
print(urllib.request.urlopen(urllib.request.Request(
    url=url,
    data=json.dumps({'image': data}).encode("utf-8")
)).read().decode("utf-8"))
print("Time: ", time.time() - timeStart)

可以看到结果：

{"Response": {"laptop": "71.43893837928772", "notebook": "16.265614330768585", "modem": "4.899385944008827", "hard_disc": "4.007565602660179", "mouse": "1.2981869280338287"}, "ResponseId": "1d74ae7e-298a-11eb-8374-024215000701"}
Time:  29.16020894050598

可以看到，函数计算顺利地返回了预期结果，但是整体耗时却超乎想象，有近 30s，此时我们再次执行一下测试脚本：

{"Response": {"laptop": "71.43893837928772", "notebook": "16.265614330768585", "modem": "4.899385944008827", "hard_disc": "4.007565602660179", "mouse": "1.2981869280338287"}, "ResponseId": "4b8be48a-298a-11eb-ba97-024215000501"}
Time:  1.1511380672454834

可以看到，再次执行的时间仅有 1.15 秒，比上次整整提升了 28 秒之多。

项目优化

在上一轮的测试中可以看到，项目首次启动和二次启动的耗时差距，其实这个时间差，主要是函数在加载模型的时候浪费了极长的时间。

即使在本地，我们也可以简单测试：

# -*- coding: utf-8 -*-

import time

timeStart = time.time()

# 模型加载
from imageai.Prediction import ImagePrediction

prediction = ImagePrediction()
prediction.setModelTypeAsResNet()
prediction.setModelPath("resnet50_weights_tf_dim_ordering_tf_kernels.h5")
prediction.loadModel()
print("Load Time: ", time.time() - timeStart)
timeStart = time.time()

predictions, probabilities = prediction.predictImage("./picture.jpg", result_count=5)
for eachPrediction, eachProbability in zip(predictions, probabilities):
    print(str(eachPrediction) + " : " + str(eachProbability))
print("Predict Time: ", time.time() - timeStart)

执行结果：

Load Time:  5.549695014953613
laptop : 71.43893241882324
notebook : 16.265612840652466
modem : 4.899394512176514
hard_disc : 4.007557779550552
mouse : 1.2981942854821682
Predict Time:  0.8137111663818359

可以看到，在加载 imageAI 模块以及加载模型文件的过程中，一共耗时 5.5 秒，在预测部分仅有不到 1 秒钟的时间。而在函数计算中，机器性能本身就没有我本地的性能高，此时为了避免每次装载模型导致的响应时间过长，在部署的代码中，可以看到模型装载过程实际上是被放在了入口方法之外。这样做的一个好处是，项目每次执行的时候，不一定会有冷启动，也就是说在某些复用的前提下是可以复用一些对象的，即无需每次都重新加载模型、导入依赖等。

所以在实际项目中，为了避免频繁请求，实例重复装载、创建某些资源，我们可以将部分资源放在初始化的时候进行。这样可以大幅度提高项目的整体性能，同时配合厂商所提供的预留能力，可以基本上杜绝函数冷启动带来的负面影响。

总结

近年来，人工智能与云计算的发展突飞猛进，在 Serverless 架构中，如何运行传统的人工智能项目已经逐渐成为很多人所需要了解的事情。本文主要介绍了通过一个已有的依赖库（ImageAI）实现一个图像分类和预测的接口。借助这个例子，其实有几个事情是可以被明确的：

• Serverless 架构可以运行人工智能相关项目；
• Serverless 可以很好地兼容 Tensorflow 等机器学习/深度学习的工具；
• 虽然说函数计算本身有空间限制，但是实际上增加了硬盘挂载能力之后，函数计算本身的能力将会得到大幅度的拓展。

当然，本文也算是抛砖引玉，希望读者在本文之后，可以发挥自己的想象，将更多的 AI 项目与 Serverless 架构进行进一步结合。

作者 | 阿里云容器服务团队
来源|阿里巴巴云原生公众号

2020 终于过去。在这一年，特殊的环境让企业的生存和发展充满着不确定性。在持续应对由变化带来的挑战过程中，数字化创新能力对于企业来说似乎比以往任何时候都更加重要。

疫情之下，越来越多的企业坚定了上云和实现数字化转型的信念和步伐，并且积极探索云原生架构转型落地。2020 年 双11，阿里巴巴实现了核心系统全面云原生化的重大技术突破。基于云原生架构，企业可以最大化使用云的能力，聚焦于自身业务发展，开发者也可以基于云原生的技术和产品，提升开发效率，将精力更多地聚焦于业务逻辑的实现。可以看出，以容器为代表的云原生技术正在成为释放云价值的最短路径。

作为云原生发展的基石，容器技术的新趋势和新挑战备受关注。2021 年伊始，阿里云容器服务团队的技术专家们为大家带来了他们对新一年容器技术趋势的六个重要解读。

趋势一：以 Kubernetes 为代表的容器技术，已成为云计算的新界面

汤志敏｜阿里云容器服务资深技术专家

在最新发布的 “CNCF 2020 年中国云原生调查”中显示，有 72% 的中国受访者在生产中使用了 Kubernetes。过去一年，我们观察到的阿里云上云原生生态的蓬勃发展也印证着云原生技术正成为释放云价值的最短路径。从早期的无状态应用、到 AI 大数据和存储类应用都在拥抱容器技术。可以看见，以 Kubernetes 为代表的容器技术已成为云计算的新界面，并将继续带来更大价值。

1. 企业从上云，到通过云原生加速分布式云管理

• 对于企业来讲，容器持续向下封装基础设施，屏蔽底层架构的差异性。
• 而 Kubernetes 的新界面进一步促进云和边的基础能力对齐，推动“边”的产品能力丰富度和标准化，从而加速容器应用在边缘、IoT 和 5G 等场景的落地。

2. 容器应用的高密高频挑战，持续重构（Refactor）云计算的架构

• 在容器应用的高密高频的应用场景推动下，面向容器优化的 OS、裸金属协同、硬件加速等技术持续演进，进一步催熟云计算架构的全栈优化和软硬一体，并给云计算用户带来极致的敏捷、弹性等红利。
• 而在容器新界面之上的 Serverless、新一代的中间件、新一代的应用 PaaS 方兴未艾。

3. 容器大规模应用进入深水区，在自动化运维、企业 IT 治理、端到端安全等迎来挑战

• 随着越来越多的工作负载、AI 大数据、数据库等应用容器化，如何统一容器和基础资源形成统一的人、财、物、权等企业 IT 治理能力，是大规模落地容器的关键述求。
• 随着越来越多的自定义控制器、越来越丰富的云原生制品格式，如何保障大规模 K8s 集群的稳定性带来强需求，而数据化智能化的 K8s 自动化集群运维和细粒度的 SLO 能力更加迫切。
• 零信任安全、容器身份认证、云原生制品生命周期管理、安全容器、机密计算等 DevSecOps 实践，持续打造端到端的容器安全网。

趋势二：围绕云原生应用的高度自动化

王思宇｜阿里云技术专家，云原生应用自动化引擎开源项目 OpenKruise 作者&初创团队成员

得益于 Kubernetes 面向终态的理念，云原生架构天然具备高度自动化的能力。在应用云原生化的过程中会充分享用到自动化带来的优势，副本数维持、版本一致性、错误重试、异步事件驱动等能力，相比过去面向过程的运维模式而言是一次新理念、新技术带来的进步。在这片蓬勃发展的土壤之上，如何围绕云原生、为应用打造更加自动化的基础设施是未来 2021 年探索的重点方向之一：

• 应用部署运维更加自动化：云原生业务类型及其多样化，不管是传统 IT、互联网，还是 Web 服务、搜索、游戏、AI、边缘等细分领域，每一种都会有自身特殊应用场景，而抽象、提炼出其中核心通用的部署运维诉求并转化为更加自动化的能力则是深耕云原生的必经之路。
• 风险防控能力更加自动化：面向终态的自动化是一把 “双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大，例如在发生操作故障时副本数维持、版本一致性、级联删除等机制反而很可能导致爆炸半径扩大。因此，通过防护、拦截、限流、熔断等防控自动化能力来抑制其他功能性自动化能力的缺陷和副作用，是伴随着云原生规模急剧扩大的必要防护措施。
• Operator 运行时更加自动化：Kubernetes 能成为容器集群调度管理引擎的事实标准，其强大而又灵活的扩展能力功不可没。Operator 既是一种特殊的应用，也是不少有状态应用的自动化管理者。而过去社区整体 Operator 趋势还停留在数量野蛮增长、周边运行时机制却无太大进步，2021 年 Operator 的运行时将会在水平扩展、灰度升级、租户隔离、安全防护、可观测性等方面获得充分的自动化增强。

趋势三：以“应用”为中心构建高可扩展的上层平台

孙健波｜阿里云技术专家，开放应用模型 OAM 开源项目负责人

随着容器技术的进一步成熟，越来越多的企业开始关注容器技术如何更好的为业务带来价值。我们可以看到以 Kubernetes 为交付界面的云原生生态日益庞大，越来越多的团队会基于 Kubernetes 构建上层抽象，增加更多的扩展能力，以“应用”为中心构建高可扩展的云原生平台。

• 基于 Kubernetes 与标准应用模型构建的易用、可扩展的上层平台将取代传统 PaaS 成为主流。当前云原生生态的软件虽然日益丰富，但是学习和使用门槛依旧非常高，易用性将成为“以应用为中心”的首要突破点。除此之外，在易用的同时保证可扩展性，保证以 Kubernetes 为接入点的开源软件无需或只要较小改造便可接入使用，也是这样类型应用管理平台的重要特征。
• “关注点分离”的标准化应用构建方式进一步深入人心。围绕 Kubernetes 构建应用交付平台已经逐渐成为共识，任何一个 PaaS 平台都不想把 Kubernetes 屏蔽掉。但是这并不意味着直接把 Kubernetes 所有的信息暴露给用户，PaaS 平台的构建者们极度渴望给用户最佳的体验。解决这个问题的突破点就是大家使用一个标准化的、关注点分离的应用构建模型，平台的构建者们关注 Kubernetes 接口（CRD 和 Operator），而平台的用户，也就是应用开发者们关注的则是一个标准化的抽象应用模型。
• 应用中间件能力进一步下沉，应用逻辑与中间件逻辑逐步解耦。随着云原生以及整个生态的发展，中间件领域也在逐步发展变化，从原先的中心化 ESB 到如今通过 Sidecar 模式提供能力的 Service Mesh 。应用中间件不再是通过一个胖客户端提供能力，而是成为一个能力的标准接入层，能力的提供则由应用管理平台通过 Sidecar 的方式在应用运行时注入。相信 Sidecar 这种模式将在除流量治理、路由策略、访问控制之外的更多中间件场景中得到应用，“以应用为中心”，让业务更专注，更聚焦。

趋势四：“云边一体”迎来快速发展

黄玉奇｜阿里云高级技术专家，边缘计算云原生开源项目 OpenYurt 负责人 

随着 5G、IoT、直播、CDN 等行业和业务的发展，越来越多的算力和业务开始下沉到距离数据源或者终端用户更近的位置，以期获得很好的响应时间和成本，这是一种明显区别于传统中心模式的计算方式——边缘计算。未来，边缘计算将存在三个非常明显的发展趋势：

• AI、IoT 与边缘计算的融合，边缘计算场景中业务种类会越来越多、规模越来越大、复杂度越来越高。
• 边缘计算作为云计算的延伸，将被广泛应用于混合云场景，这里面需要未来的基础设施能够去中心化、边缘设施自治、边缘云端托管能力。
• 5G、IoT 等基础设施的发展将会引爆边缘计算的增长。

边缘计算的规模、复杂度正逐日攀升，而短缺的运维手段和运维能力也终于开始不堪重负。在这个背景下，“云边端一体化运维协同”已经开始成为一种架构共识。通过云原生加持，云边融合的进程也正在被急剧加速：

• “云”层，让我们保留了原汁原味的云原生管控和丰富的产品能力，通过云边管控通道将之下沉到边缘，使海量边缘节点和边缘业务摇身一变成为云原生体系的工作负载。
• “边”侧，通过流量管理和服务治理使其更好的和端进行交互，获得和云上一致的运维体验，更好的隔离性，安全性以及效率，从而完成业务、运维、生态的一体化。

边缘计算云原生即是云原生的新边界，也是边缘计算的新未来。

趋势五：云原生 AI 只是起点，云原生驱动数据变革是新主题

张凯｜阿里云高级技术专家，负责容器服务和云原生 AI 解决方案研发 车漾 | 阿里云高级技术专家，开源项目 Fluid 联合发起人

数据是企业的核心资产，云原生为了更好地支撑企业 IT 数字化和智能化转型，拥抱数据驱动应用是其未来几年中最重要的使命之一。除了生在 Docker 里、长在 Kubernetes 下的云原生 AI 之外，如何能让传统的大数据和 HPC 应用也平滑迁移到 Kubernetes 平台上来，实际上也是云原生社区需要回答的问题。我们看到的趋势是致敬传统任务调度器、容器化资源精细调度、弹性数据任务全新场景、AI 与大数据的统一云原生底座。

• 致敬传统任务调度器: Kubernetes 关注于资源调度，但是对于大数据和 HPC 的调度功能比起 Yarn 等离线传统调度器还有很多需要借鉴的地方，最近在 Kubernetes 的 Scheduler Plugin Framework 的灵活框架下，适配于大数据和 HPC 场景的批量调度，Capacity 调度正在逐步落地。
• 容器化资源精细调度：Kubernetes 利用容器特性和插件化调度策略，可以原生地支持 GPU 资源共享调度，并且可以进行 GPU 资源隔离，Nvidia Ampere 的调度也在 Kubernetes 上做了 Mig 原生支持。这也是 Kubernetes 独特的能力。而资源共享不仅仅限于 GPU，对于 RDMA，NPU 甚至存储设备，这种调度能力都是必不可少的。
• 弹性数据任务全新场景：随着大数据和 AI 应用的弹性化越来越普及，如何让数据也有弹性的能力，让数据像流体一样，在诸如 HDFS、OSS、Ceph 等存储源和 Kubernetes 上层云原生应用之间，灵活高效地移动、复制、驱逐、转换和管理，推动广阔云服务场景下的大数据、AI 落地新应用。
• AI 与大数据的统一云原生底座：基于作业调度、资源利用率优化和数据编排这些原子能力，越来越多 AI、机器学习平台和大数据分析平台构建在容器集群之上。而 AI 与大数据对数据的依赖度，对计算、网络和存储资源的需求特点、工作负载特征、运行策略、对在线服务的重要性，甚至影响企业 IT 成本的因素，都有很多相似之处。因此如何以统一的云原生底座同时支持 AI 和大数据作业，将成为企业 CTO、CIO 思考的主题之一。

趋势六：容器安全成为重中之重

杨育兵｜阿里云容器服务高级技术专家

容器已经成为应用交付的标准，也是云原生时代计算资源和配套设施的交付单元。以 runC 为代表的使用 linux container 技术实现的容器运行时，以轻量、高效、自包含、一次打包到处运行等优秀特性，深受广大容器开发者和使用者的喜爱。

容器技术及应用日渐普及，正成为云计算的新界面。但云计算下的容器技术正面对新的挑战。多个容器共享了同一内核，在隔离和安全性方面必然存在天然缺陷，并进一步限制了容器的应用场景和发展，使其只能应用于企业内部环境等单租场景。但云原生产品交付给不同租户的容器，即使运行在同一台宿主机上也必须具备强隔离的安全保证；在云原生产品时代，容器运行时除了需继续保持轻量、高效、自包含、一次打包到处运行的优秀特性外，还需进一步确保良好的安全隔离性，容器安全成为重中之重。以 KATA 为代表的使用轻量虚拟化实现的容器时逐渐成为多租场景的标准容器运行时。

除了运行时的安全隔离，网络、磁盘、镜像、K8s API 等层面的安全隔离也是必须要解决的问题。涉及到多租户和运行不可信代码，用户可接触到的一切资源都是需要隔离的，包含网络可达的目标，可以使用的存储，可以下载或本地访问的镜像内容都需要隔离。为了防止隔离实现本身有漏洞被用户利用，安全防护需要多层次的深度防护，网络防护除了 VPC 隔离，还需要网络策略细化隔离；计算的隔离除了虚拟化技术的隔离还需要有命名空间、系统调用等方面的隔离；存储的隔离除了有虚拟化相关的隔离，还需要在宿主机上面做 DiskQuota 隔离；镜像的隔离除了要做网络隔离，还需要做本地的镜像引用隔离。这些实现都是向强隔离、多层深度隔离方向发展。

容器安全技术也面对其它新的挑战：引入虚拟化后，容器技术实现不再轻量，如何对虚拟化技术优化，并尽可能轻量、高效成为我们必须要解决的问题；业界也有像 Google 的 gVisor 和 Crosvm、Amzon 的 Firecracker 等轻量虚拟化支持容器化的技术，阿里内部也有相应的 Daishu 虚拟化容器技术来解决这个问题。

下载《云原生大规模落地应用指南》，收藏更多云原生规模化落地实践经验！点击即可下载

​大家好，我是来自灵雀云的邢海涛，今天演讲的主题是Service Mesh安全，主要从四个方面来跟大家做一下分享。首先介绍Service Mesh 安全需求，然后详细介绍Istio的安全实现，随后介绍两款Service Mesh产品的安全特性：LinkerD 和 Alauda Service Mesh。希望通过这个演讲，让大家了解Istio的无代码侵入，灵活的安全解决方案，启发大家思考自己的安全解决方案，以及如何迁移到Istio的安全模型。

安全无处不在。为了适应企业数字业务的快速发展，企业应用架构正在从单体架构过渡到微服务架构。一方面，微服务架构带来更好的敏捷性，可伸缩性和更好的重用服务能力。另一方面，架构师不得不面对汹涌的网络攻击。

同时，结合无处不在的互联网访问，设备扩展和云计算，企业应用还要面对更多防火墙内部和外部的基础设施、系统和用户数量。企业应用不得不面对零信任网络环境。

我们认为，Service Mesh安全需求可以分为上面三类：网络攻击、服务访问控制和审计。防御网络中间人攻击，流量加密是必须的。为了提供对应用和用户的访问控制，Service Mesh需要双向TLS和细粒度的访问策略。为了确定谁在什么时候做了什么，需要审计工具。

02

全方位Istio安全

这张图来自Istio官网。Istio安全性的目标是：

• 默认情况下的安全性：无需更改应用程序的代码和基础架构
• 深度防御：与现有安全系统集成以提供多层防御
• 零信任网络：在不受信任的网络上构建安全解决方案

说到底，Istio安全主要有两项功能：即无代码侵入前提下，实现流量加密和AAA（验证、授权、审计）。流量加密，用来解决零信任网络的问题。Istio的AAA是在集成现有安全协议/标准之上实现的，这些安全协议/标准包括双向TLS，JWT，OpenID Connect等。

其他描述都是支撑这两大功能：秘钥和证书管理都是为支撑流量加密的基础设施；identity用来支撑身份验证机制；policy用来支撑授权机制；endpoints，communication，data都是加密的对象。

这张图显示了Istio安全体系架构，构建于Istio控制平面和数据平面的基础架构之上。控制平面主要实现如下功能：

• Citadel组件作为证书颁发机构（CA），用于密钥和证书管理
• 接受来自API server下发的配置信息：认证策略、授权策略、安全的命名信息
• Pilot组件负责下发配置信息给Sidecar proxy。

数据平面在安全方面则提供两大功能：

• Sidecar和外围代理充当策略执行点 （PEP），以保证客户端和服务器之间的通信。
• 一组Envoy代理扩展，用于管理遥测和审计

总之，控制平面处理来自API server的配置信息，并下发到数据平面，数据平面sidecar Envoy充当策略执行点执行安全策略。

双向TLS就是Service Mesh安全的基础，流量加密和AAA都是基于双向TLS实现的。双向TLS包含一个握手的过程，用于相互检查验证对方身份，这里都是可选操作，可以选择单向验证，甚至不验证。然后是交换对称秘钥，最后用对称秘钥加密通讯内容。

这里验证身份的过程就是利用证书来完成的，证书就是一个passport，由证书权威机构签发的，有时效性的包含你是谁的一段信息。这里签发就是用证书权威机构的私钥给这段信息的摘要签名的过程。

验证过程就是检查证书权威机构是否被信任，证书是否过期，以及检查证书持有者的IP，域名或服务名和证书是否一致。

Istio的安全模型都是围绕双向TLS实现的：

• 自建证书权威机构，让私钥和证书轮换自动化
• 强制双向的身份认证
• 客户端检查服务端身份的同时，还要检查谁在运行服务端，这个人是否有资格运行服务端
• 服务端检查客户端身份的同时，启动授权机制，检查客户端是否有权访问服务端的资源

Istio提供了一个相当灵活的身份模型。Istio使用service identity作为身份，可以表示人类用户，单个workload或一组workload。支持多种公有云平台，在没有服务身份的平台上，Istio可以使用服务名称作为Workload实例的身份。

Istio使用X.509证书为每个Workload设置强身份。Envoy代理、Istio agent和istiod协同一起工作，实现了密钥产生和证书轮换的自动化。

这个过程是这样的：Envoy通过Envoy 定义的API向Istio agent发送证书和密钥请求。Istio agent收到请求后，会先创建私钥和CSR证书签名请求,然后将请求及凭据发送到istiod。Istiod的CA验证CSR中携带的凭据，并对CSR签名以生成证书，并返回给istio agent。Istio agent 将收到的证书和私钥发送给Envoy。通过定期反复的上述过程，istio实现了密钥产生和证书轮换的自动化。

Istio身份验证包含两种类型：对等身份验证和请求身份验证。对等身份验证用于service to service的身份验证，请求身份验证用于对用户和人的身份验证。

对等身份验证用于service to service 的身份验证，以验证建立连接的客户端。Istio将来自客户端的出站流量重新路由到客户端的本地Sidecar Envoy。客户端Envoy与服务器端Envoy开始相互TLS握手。通常的TLS握手，会验证证书的签名，检查证书是否过期，以及证书里名称和域名一致。但Istio Envoy之间在握手，客户端Envoy还会进行安全的命名检查，而不是检查域名和证书是否一致，以验证服务器证书中提供的服务帐户service account是否有权运行目标服务。

客户端是通过服务发现或DNS检索证书中的服务名称的，能够防止HTTPS流量受到一般网络劫持。但是，不能防止DNS欺骗。这也说明Istio还要依赖于底层基础设施的安全保障。客户端Envoy和服务器端Envoy建立了相互TLS连接，Istio将流量从客户端Envoy转发到服务器端Envoy。授权后，服务器端Envoy通过本地TCP连接将流量转发到服务端的服务。

Istio通过使用JSON Web令牌（JWT）验证进行请求身份验证，便于集成使用OpenID Connect的应用。我们使用YAML文件来定义验证策略。部署后，策略将保存在Istio配置存储中。Istio控制器监控配置存储。在任何策略更改后，新策略都会转换为适当的配置，通知Envoy sidecar如何执行这些策略。验证策略可以包含用于验证JWT的公钥，以便传递给envoy sidecar。

Istio授权支持service to service的授权，以及针对最终用户和人的授权访问。Istio授权提供了一个CRD形式的灵活简单的API，我们可以自定义条件，使用DENY和ALLOW动作作为结果。

本地Envoy上执行的授权过程，保证了高性能。同时为了减轻运维人员的负担，Istio支持不同级别分级的授权机制，即从网关，到命名空间再到具体的workload的控制级别。

我们也能看到Istio授权机制的演进过程，从1.4版开始，支持基于策略的授权机制及PBAC，而之前提供的是RBAC的机制，通过左右对比，可以看到由两个CRD化简到一个CRD完成，语义功能上没有丝毫的减弱。

Istio 安全的审计功能比较简单。因为envoy的access log可以输出到标准输出，并可由kubectl logs访问。通常由PaaS平台统一收集处理，可以考虑增加过滤条件进一步便捷审计查询。

Linkerd是第一代service mesh，目前已经发展到第二代，由于第一代Linkerd十分笨重，第二代设计上放弃了可选实现的多样性选择。因此，第二代Linkerd非常轻量，性能非常高。Linkerd官网展示的4个案例，都是始于Istio，最终选择linkerd实施service mesh的。

默认情况下，Linkerd自动给mesh里的通讯加上双向TLS，但是对流入和流出的流量不强制加密。另外，LinkerD使用的kubenetes Service Account token目前是共享的，依赖kubernetes版本更新，将得以修复。

Alauda Service Mesh是灵雀云推出的Service Mesh产品，基于原生Istio，运行在Kubernetes之上，提供了一键部署、可视化管理、可视化配置、便捷的灰度发布等功能，极大降低运维难度，降低了学习Service Mesh的成本。

Alauda service mesh目前支持针对工作负载workload级别的手动配置双向TLS，设置双向TLS的严格模式和兼容模式。

来源|阿里巴巴云原生公众号

2020 年，新冠肺炎疫情催化数字化生活方式渐成常态。在企业积极进行数字化转型、全面提升效率的今天，几乎无人否认背负“降本增效”使命诞生的 Serverless 即将成为云时代新的计算范式。

Serverless 将开发者从繁重的手动资源管理和性能优化中解放出来，正在引发云计算生产力的新变革。

然而，Serverless 的落地问题却往往很棘手，例如传统项目如何迁移到 Serverless，同时保障迁移过程业务连续性，在 Serverless 架构下如何提供完善的开发工具、有效的调试诊断工具，如何利用 Serverless 做更好的节约成本等，每一个都是难题。

尤其涉及到在主流场景大规模的落地 Serverless ，更是并非易事。正因为这样，业界对于 Serverless 核心场景规模化落地最佳实践的呼唤更加迫切。

总交易额 4982 亿元，订单创建峰值 58.3 万笔/秒，2020 年天猫 双11 又一次创造记录。对于阿里云来说，今年的 双11 还有另一个意义：阿里云实现了国内首例 Serverless 在核心业务场景下的大规模落地，扛住了全球最大规模的流量洪峰，创造了 Serverless 落地应用的里程碑。

Serverless 落地之痛

挑战一：冷启动耗时长

快弹是 Serverless 天然自带的属性，但是快弹的条件是要有极致的冷启动速度去支撑。在非核心的业务上，毫秒级别的延时，对业务来说几乎不受影响。但是，对于核心业务场景，延时超过 500 毫秒已经会影响到用户体验。

虽然 Serverless 利用轻量化的虚拟技术，不断的降低冷启动，甚至某些场景能降低到 200 毫秒以下。但这也只是理想的独立运行场景，在核心业务链路上，用户不仅是运行自己的业务逻辑，还要依赖中间件、数据库、存储等后端服务，这些服务的连接都要在实例启动的时候进行建连，这无形中加大了冷启动的时间，进而把冷启动的时间加长到秒级别。

对于核心在线业务场景来说，秒级别的冷启动是不可接受的。

挑战二：与研发流程割裂

Serverless 主打的场景是像写业务函数一样去写业务代码，简单快速即可上线，让开发者在云上写代码，轻松完成上线。

然而在现实中，核心业务的要求把开发者从云上拉回到现实，面对几个灵魂拷问：如何做测试？如何灰度上线？如何做业务的容灾？如何控制权限？

当开发者回答完了这些问题，就会变的心灰意冷，原来在核心业务上线中，“函数正常运行”只占了小小的一环，离上线的距离还有长江那么长。

挑战三：中间件的连通问题

核心在线业务不是独立函数孤立运行的，需要连接存储、中间件、数据中后台服务，获取数据后再计算，进而输出返回给用户。

传统中间件客户端需要打通和客户的网络、初始化建连等一系列操作，往往会使函数启动速度下降很多。

Serverless 场景下实例生命周期短、数量多，会导致频繁建连、连接数多的问题，因此针对在线核心应用常用的中间件的客户端进行网络连通优化，同时对调用链路进行监控数据打通，帮助 SRE （Site Reliability Engineer ）从业者更好的评估函数的下游中间件依赖情况，对于核心应用迁移上 Serverless 非常重要。

挑战四：可观测性差

用户大多数的核心业务应用多采用微服务架构，看核心业务应用的问题也就会带有微服务的特性，比如用户需要对业务系统的各种指标进行非常详尽的检查，不仅需要检查业务指标，还需要检查业务所在系统的资源指标，但是在 Serverless 场景中没有机器资源的概念，那这些指标如何透出？是否只透出请求的错误率和并发度，就可以满足业务方的需求？

实际上，业务方的需求远不止这些。可观测性做的好坏还是源于业务方是否信任你的技术平台。做好可观测性是赢得用户信任的重要前提。

挑战五：远程调试难度高

当核心业务出现线上问题时，需要立即进入调查，而调查的第一要素就是：现场的保留，然后登陆进行调试。而在 Serverless 场景中没有机器层面的概念，所以如果用户想登陆机器，在现有的 Serverless 基础技术之上是很难做到的。当然原因不仅限于此，比如 Vendor-lockin 的担心等。

上面几大类痛点的概括，主要是针对开发者的开发体验，对于实际的开发场景中，是否真的是”提效”, 而不是新瓶装旧酒。目前仍有大部分核心应用开发者对 Serverless 还是持有观望状态，当然也不乏一些质疑观点，“FaaS 只适合小业务场景以及非核心业务场景”。

Serverless 的 双11 “大考”

2019 年 12 月咨询公司 O’Reill 发布 Serverless 使用调研中，已有 40% 的受访者所在的组织采用了 Serverless。2020 年 10 月，中国信息通信研究院发布的《中国云原生用户调研报告》指出：“Serverless 技术显著升温，近 30% 的用户已在生产环境中应用。”2020 年，越来越多企业选择加入 Serverless 阵营，翘首以待更多 Serverless 规模化落地核心场景的案例。

面对 Serverless 开发者数量的稳步增长的现状，阿里巴巴年初就制定了“打造 Serverless 双11”的策略，目的不只是单纯的去抗流量、打峰值，而是切实的降成本，提高资源利用率，通过 “双11 技术炼金炉”把阿里云 Serverless 打造成更安全、更稳定、更友好的云产品，帮助用户实现更大的业务价值。

与过去 11 年的 双11 都不同的是，继去年天猫 双11 核心系统上云后，阿里巴巴基于数字原生商业操作系统，实现了全面云原生化，底层硬核技术升级带来了澎湃动力和极致效能。以支撑订单创建峰值为例，每万笔峰值交易的 IT 成本较四年前下降了 80%。Serverless 也迎来了首次在 双11 核心场景下的规模化落地。

场景一：前端多场景

2020 年 双11，阿里巴巴集团前端全面拥抱云原生 Serverless，淘系、飞猪、高德、CBU、ICBU、优酷、考拉等十数 BU ，共同落地了以 Node.js FaaS 在线服务架构为核心的云端一体研发模式。

今年 双11 在保障稳定性、高资源利用率的前提下，多 BU 的重点营销导购场景实现了研发模式升级。前端 FaaS 支撑的云端一体研发模式交付平均提效 38.89%。依托 Serverless 的便利性和可靠性，淘宝、天猫、飞猪等 双11 会场页面快捷落地 SSR 技术，提高了用户页面体验，除了保障大促以外，日常弹性下也较以往减少 30% 计算成本。

场景二：个性化推荐场景

Serverless 天然的弹性伸缩能力，是“个性化推荐业务场景”选择由 Serverless 实现的最重要原因，数以千计的异构应用运维成本一直是这个场景下的痛点。通过 Serverless 化进一步释放运维，让开发者专注于业务的算法创新。

目前这个场景的应用范围越来越广，已经覆盖了几乎整个阿里系 APP：淘宝，天猫，支付宝，优酷，飞猪等等，因此我们可以对机器资源利用率方面做更多的优化，通过智能化的调度，在峰值时的机器资源利用率达到了 60%。

场景三：中、后台场景

2020 年，世纪联华 双11 基于阿里云函数计算(FC)弹性扩容，在大促会场 SSR、线上商品秒杀、优惠券定点发放、行业导购、数据中台计算等多个场景进行应用，业务峰值 QPS 超过 2019 年 双11 的 230%，研发效率交付提效超过 30%，弹性资源成本减少 40% 以上。

当然，适用于 Serverless 的场景还有很多，需要更多行业的开发者们共同丰富。总的来说，今年 FaaS 的成绩单非常耀眼，在 双11 大促中，不仅承接了部分核心业务，流量也突破新高，帮助业务扛住了百万 QPS 的流量洪峰。

阿里云如何击破 Serverless 痛点？

那么，面对行业共有的 Serverless 落地之痛，阿里云是如何克服的呢？

1. 预留模式 + 按量模式消除冷启动

在 2019 年的 Serverless 2.0 重大升级中，阿里云函数计算率先支持了预留模式，接着 AWS Lambda 几个月后，也上线了类似的功能。

为什么阿里云会率先提出这个问题？阿里云 Serverless 团队不断探索真实业务的需求，按量模式的按需付费模式，虽然非常的诱人，但是冷启动时间过长，因此把核心在线业务拒之门外。接下来阿里云着重分析了核心在线业务的诉求：延时小，保证资源弹性。那如何解决呢？

请看下图，一个非常典型的业务曲线图，用预留模式方式满足底部固定的量，用弹性能力去满足 burst 的需求。

针对 burst 扩容，我们利用两种扩容方式结合进行满足：按资源扩容与按请求扩容，比如用户可以只设置 CPU 资源的扩容阈值为 60%，当实例的 CPU 达到阈值后，就会触发扩容。此时的新请求并没有立即到扩容实例，而是等待实例准备好后再导流，从而避免了冷启动。

同理，如果只设置了并发度指标的扩容阈值为 30（每一个实例承载的并发度），同样满足这个条件后，也会触发同样流程的扩容。如果两个指标都进行了设置，那么先满足的条件会先触发扩容。

通过丰富的伸缩方式，阿里云函数计算解决了 Serverless 冷启动的问题，很好的支撑了延时敏感业务。

2. 核心业务研发提效 38.89%

“提升效率”本应该是 Serverless 的优势，但对于核心应用来说，”快” = “风险大”，用户需要经过 CI 测试，日常测试，预发测试，灰度部署等几个流程验证，才能确保函数的质量。这些流程是阻碍核心应用使用 FaaS 的绊脚石。

针对于这个问题，阿里云函数计算的策略是” 被集成“，把研发平台的优势与阿里云函数计算进行结合，既能满足用户的 CI/CD 流程，又能享受到 Serverless 的红利，帮用户跨过使用 FaaS 的鸿沟。

阿里集团内部通过暴露标准的 OpenAPI 与各个核心应用的研发平台进行集成，经过双十一业务研发的验证，研发效率大大提高了 38.89%。在公有云上我们与云效平台集成，把研发流程与 FaaS 结合的更紧密、更顺畅，帮助集团外的业务提高人效。

3. 中间件连通

核心应用离不开上下游的配合，一旦核心应用使用了函数计算，又该如何与中间件相配合？传统应用开发需要集成各类中间件的 SDK，进行打包上线，但对于 Serverless 的函数来说，代码包的大小就是一个硬伤，这个问题将将直接影响冷启动的时间。

阿里云函数计算经过两个阶段的发展，第一个阶段我们通过搭建中间件 Proxy，通过 Proxy 去打通中间件，函数只用单一的协议与 Proxy 进行交互，从而 offload 掉中间件的 SDK 的包袱。

第二个阶段：随着中间件能力的下沉，一些控制类型的需求也被提上了议程，比如：命令下发，流量管理，配置拉取等等，期间阿里云拥抱了开源组件 Dapr，利用 Sidecar 的方式 Offload 中间的交互成本。

上述的方案，是基于阿里云函数计算的 Custom Runtime，以及 Custom Container 功能完成的。

4. 极致的开发体验

远程调试、日志查看、链路追踪、资源利用率，以及完善周边工具链是开发者的必备能力。阿里云函数计算同时启动了不同的攻关小组，首先与 Tracing/ARMS 结合，打造清晰的链路追能力，与 SLS 集成打造了全面的业务数据监控。

因此，业务可以根据需求进行自定义，并且拥抱开源产品 Prometheus 暴露出资源利用率，支持远程调试能力的 WebIDE。

再加上阿里云近期刚开源的重磅武器：Serverless-devs ，一个无厂商绑定的、帮助开发者在 Serverless 架构下实现开发/运维效率翻倍的开发者工具。开发者可以简单、快速的创建应用、项目开发、项目测试、发布部署等，实现项目的全生命周期管理。

Serverless 初始的痛点有很多，为什么阿里云却能把 Serverless 落地到各行各业？

首先，阿里云提供了所有云厂商中最完整的 Serverless 产品矩阵，包括函数计算 FC、Serverless 应用引擎 SAE、面向容器编排的 ASK、以及面向容器实例的 ECI。

丰富的产品矩阵能够覆盖不同的场景，比如针对事件触发场景，函数计算提供了丰富的事件源集成能力和百毫秒伸缩的极致弹性；而针对微服务应用，Serverless 应用引擎能做到零代码改造，让微服务也能享受 Serverless 红利。

其次， Serverless 是一个快速发展的领域，阿里云在不断拓展 Serverless 的产品边界。例如函数计算支持容器镜像、预付费模式、实例内并发执行多请求等多个业界首创的功能，彻底解决了冷启动带来的性能毛刺等 Serverless 难题，大大拓展了函数计算的应用场景。

最后，阿里经济体拥有非常丰富的业务场景，可以进一步打磨 Serverless 的落地实践。今年阿里经济体的淘系、考拉、飞猪、高德等多个 BU 的 双11 核心业务场景均使用了阿里云函数计算，并顺利扛住了 双11 的高峰。

Serverless 引领下一个十年

“劳动生产力的最大激进，以及运用劳动时所表现的更大熟练、技巧和判断力，似乎都是劳动分工的结果” ，这是摘自《国富论》的一段话，强调的是“劳动分工”的利害关系，任何一个行业，市场规模越大，分工将会越细，这也是著名的“斯密定理”。

同样，这一定理也适用于软件应用市场行业，随着传统行业进入了互联网化阶段，市场规模越来越大，劳动分工越来越细，物理机托管时代已经成为了历史，被成熟的 IaaS 层取代，随之而来的是容器服务，目前也已经是行业的标配。

那么，接下来的技术十年是什么呢？答案是：Serverless，抹平了研发人员在预算、运维经验上的不足，在对抗业务洪峰的情况下，绝大多数研发也能轻易掌控处理，不仅极大地降低了研发技术门槛，同时大规模提升了研发效率，线上预警、流量观测等工具一应俱全，轻松做到了技术研发的免运维，可以说 Serverless 是更细粒度的分工，让业务开发者不再关注底层运维，只关注于业务创新，以此大大提高了劳动生产力，这就是“斯密定理”效应，也是 Serverless 成为未来必然趋势的内在原因。

当下，整个云的产品体系已经 Serverless 化，70% 以上的产品都是 Serverless 形态。对象存储、消息中间件、API 网关、表格存储等 Serverless 产品已经被广大开发者熟知。下一个十年， Serverless 将重新定义云的编程模型，重塑企业创新的方式。

作者 | 守辰、志敏
来源|阿里巴巴云原生公众号

11 月 11 日零点刚过 26 秒，阿里云再一次抗住了全球最大的流量洪峰。今年 双11 是阿里经济体核心系统全面云原生化的一年，相比去年核心系统的上云，云原生化不仅让阿里享受到了云计算技术成本优化的红利，也让阿里的业务最大化获得云的弹性、效率和稳定性等价值。

为应对 双11，阿里云原生面临怎样的挑战？

为了支持阿里这样大规模业务的云原生化，阿里云原生面临怎么样的挑战呢？

1. 集群多、规模大

基于对业务稳定性和系统性能等方面的综合考虑，大型企业往往需要将业务集群部署到多个地域，在这样的场景下，支撑多集群部署的容器服务能力非常必要。同时，为了简化多集群管理的复杂度，以及为不能实现跨集群服务发现的业务提供支持，还需要关注容器服务中单个集群对大规模节点的管理能力。另外，大型企业的业务复杂多样，因此一个集群内往往需要部署丰富的组件，不仅包括主要的 Master 组件， 还需要部署业务方定制的 Operator 等。集群多、规模大，再加上单个集群内组件众多， 容器服务的性能、可扩展性、可运维性都面临着很大的挑战。

2. 变化快、难预期

市场瞬息万变，企业，特别是互联网企业，如果仅凭借经验、依靠规划来应对市场变化，越来越难以支撑业务发展，往往需要企业快速地进行业务迭代、部署调整以应对市场的变化。这对为业务提供应用交付快速支持、弹性伸缩性能和快速响应支撑的容器服务提出了很大的要求。

3. 变更多、风险大

企业 IT 系统的云原生化过程不仅要面临一次性的云迁移和云原生改造成本，还将持续应对由于业务迭代和基础设施变更、人员流动带来的风险。而业务的迭代、基础设施的变更会无法避免地为系统引入缺陷，严重时甚至造成故障，影响业务正常运行。最后，这些风险都可能会随着人员的流动进一步加剧。

阿里云容器服务大规模实践

1. 高扩展性

为了提高容器服务的可扩展性，需要自底向上、联动应用和服务一起优化。

1）接口最小化

针对上层 PaaS，容器服务依托 OAM（Open Application Model） 和 OpenKruise Workload 提供了丰富的应用交付能力抽象。对于 PaaS 层来说，只需要读取汇总的应用部署统计数值即可，极大减少了上层系统需要批量查询 pod、event 等信息的工作量，进而减小了对容器服务的管控压力；同时，通过把数量多、占用空间大的 pod 及 events 信息转存到数据库中， 并根据数据库中的内容提供一个统一的、可内嵌的部署状态查看和诊断页面的方式，可以使 PaaS 层避免直接访问容器服务来实现相关功能。

2）分化而治之

“分化而治之”是指要对业务做出合理的划分，避免因为所有业务和应用都集中在少数几个命名空间中，导致容器服务管控（控制器和 APIServer）在查询命名空间下所有资源时产生过大消耗的情况。目前在阿里内部最广泛的实践方式是使用“应用名”做为命名空间。一方面应用是业务交付的基本单位，且不受组织调整的影响；另一方面，容器服务的组件以及业务自己的 Operator，在处理时往往会 list 命名空间下的资源，而命名空间默认在控制器和 APIServer 中都实现有索引，如果使用应用作为命名空间可以利用默认的索引加速查询操作。

3）苦修内外功

对于容器服务的核心管控，需要扎实的内功做基础。针对大规模的使用场景，阿里云的容器服务进行了大量的组件优化，比如通过索引、Watch 书签等的方式，避免直接穿透 APIServer 访问底层存储 ETCD，并通过优化 ETCD 空闲页面分配算法、分离 event 和 lease 存储至独立 ETCD 的方法，提升 ETCD 本身的存储能力，其中不少已经反馈给了社区，极大降低了 ETCD 处理读请求的压力。 详情可查看：https://4m.cn/JsXsU。

其次，对于核心管控本身，要做好保护的外功。特别是安全防护，需要在平时就做好预案，并且常态化地执行演练。例如， 对于容器服务 APIServer， 需要保证任何时候的 APIServer 都能保持可用性。 除了常见的 HA 方案外， 还需要保证 APIServer 不受异常的 operator 和 daemonset 等组件的影响。为了保证 APIServer 的鲁棒性，可以利用官方提供的 max-requests-inflight 和 max-mutating-requests-inflight 来实现， 在紧急情况下阿里云还提供了动态修改 infight 值配置的功能，方便在紧急情况下不需要重启 APIServer 就可以应用新的配置进行限流。

对于最核心的 ETCD，要做好数据的备份。考虑到数据备份的及时性，不仅要进行数据定期的冷备，还需要实时地进行数据的异地热备，并常态化地执行数据备份、灰度的演练，保证可用性。

2. 快速

在应对业务变化多、基础设施变化多带来的不可预期问题，可采取以下方式。

1）负载自动化

为了高效地进行应用交付，研发需要权衡交付效率和业务稳定性。阿里大规模地使用 OpenKruise 进行应用的交付，其中 cloneset 覆盖了阿里上百万的容器。 在 cloneset 中可以通过 partition 来控制暂停发布从而进行业务观察，通过 maxunavailable 来控制发布的并发度。通过综合设置 partition 和 maxunavailable 可以实现复杂的发布策略。实际上，大多数情况下 PaaS 层在设计分批发布的功能时，往往选取了每批暂停的方式（仅通过 cloneset partition 字段来控制分批），如下图。然而，每批暂停的方式往往因为应用每批中个别机器的问题而产生卡单的问题，严重影响发布效率。

因此推荐使用流式发布的配置：

apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
  updateStrategy:
  # 首批partition设置， 非首批置0
    partition: 0  
  # 控制发布的并发度， 实现为1/分批数
    maxUnavailable: 20%

2）以快制动

为了应对突发的业务流量， 需要能够快速的进行应用的部署，并从多方面保障紧急场景的快速扩容。

一方面，通过推进业务使用方的 CPUShare 化，让应用能够原地利用节点额外计算资源，从而给紧急扩容争取更多的反应时间。

其次，通过镜像预热的方式来预热基础镜像，通过 P2P 和 CDN 的技术加速大规模的镜像分发，通过按需下载容器启动实际需要的镜像数据，使业务镜像下载时间极大地降低。

3）打好提前量

俗话说，”不打无准备之仗” 。要实现高效率的部署，做好准备是必需的。

首先是对于资源的准备， 如果集群内没有为服务准备好一定的容量，或者没有为集群准备好额外节点额度的话，就无法在必要时实现弹性。因为阿里不同业务有着不同的流量峰值，我们会结合实际情况定期对部分业务缩容，并对另外一种业务进行扩容的方式实现计划资源的伸缩。

当然，寻找这样可以匹配较好的业务组会比较困难，对于采用函数等 Serverless 形态的应用， 阿里构建一个公共预扩容的 Pod 池，使得不同业务紧急扩容时能够完全规避调度、网络和储存的开销， 达到极致的扩容速度。

3. 稳定

为了确保使用容器服务的业务稳定，阿里在具体实践中遵循了以下几个原则。

1）信任最小化

俗话说，”常在河边走，哪有不湿鞋”。为了确保频繁进行集群运维工作的同学不因为疏忽而犯错，就要保证业务可操作的权限最小化，对于授权的写和删除操作，还要增加额外的保护。近一步来讲，为了防止容器服务用户的误操作，我们对 Namespace、CRD 和 Workload 的资源都增加了级联删除的保护，避免用户因为误删除还在运行 Pod 的 Namespace、CRD 和 Workload 而引发灾难性的后果。下图展示了删除一个 CRD 可能造成的级联删除故障，实际应用中，许多 operator 中都会设置 CR 为关联 Workload 的 Owner， 因此一旦删除了 CRD（例如非预期的 Operator 升级操作），极有可能会导致级联删除关联的所有 Pod，引起故障。

另外， 对于业务运行依赖的如日志上传、微服务调用、安全审计等基础设功能，需要进行资源的隔离。因此，阿里在对应用进行大量的轻量化容器改造过程中，采取了把基础设施功能从应用的富容器中剥离到 Sidecar 或者 Daemonset 中的方式，并对 Sidecar 或者 Daemon 的容器进行资源的隔离， 保证即使基础设施功能发生内存泄露等异常也不会直接影响业务的正常运行。

2）默认稳定性

指保证所有应用都具备基本的稳定性保障配置，包括默认的调度打散策略、Pod 中断预算、应用负载发布最大不可用数量，让稳定性成为像水、电、煤一样的基础设施。这样能够避免应用因为宿主机故障、运维操作、应用发布操作导致服务的完全不可用。保障可以通过 webhook 或者通过全局的应用交付模板来实现，应用 PaaS 也可以根据业务的实际要求来定制。

3）规范化应用

在进行云原生改造时，需要制定启停脚本、可用和探活探针规范，帮助业务把自愈能力内置到应用中去。这包括推动应用配置相应的存活探针，保证应用在异常退出后能够被自动拉起；保证应用启动和退出时执行优雅上下线的操作等。配合这些规范，还需要设置相关探针的准入、监测机制，防止业务研发同学在对 K8s 机制不完全了解的情况下编写错误的探针。我们常常见到很多研发同学直接复用已有的健康检查脚本来作为探活探针，但是这些脚本往往存在调用开销大（例如执行了解压缩）、存在副作用（例如会修改业务流量开启状态）、以及执行不稳定（例如调用涉及下游服务）的问题，这些对业务的正常运行都会产生非常大的干扰，甚至引发故障。

4）集中化处理

对于探活失败的自动重启、问题节点的驱逐操作， 阿里云容器服务把 Kubelet 自主执行的自愈操作，改为了中心控制器集中触发，从而可以利用应用级别的可用度数据实现限流、熔断等安全防护措施。这样，即使发生了业务错配探活脚本或者运维误操作执行批量驱逐等操作状况，业务同样能得到保护；而在大促峰值等特殊的业务场景下，可以针对具体需求设计相应的预案，关闭相应探活、重启、驱逐等操作，避免在业务峰值时因为探活等活动引起应用资源使用的波动，保证业务短期的极致确定性要求。

5）变更三板斧

首先，要保证容器服务自身的变更可观测、可灰度、可回滚。 对于 Controller 和 Webhook 这类的中心管控组件，一般可以通过集群来进行灰度，但如果涉及的改动风险过大，甚至还需要进行 Namespace 级别细粒度的灰度；由于阿里部分容器服务是在节点上或者 Pod 的 Sidecar 中运行的，而官方 K8s 中欠缺对于节点上 Pod 和Sidecar 中容器的灰度发布支持，因此阿里使用了 OpenKruise 中的 Advance Daemonset 和 Sidecarset 来执行相关的发布。

使用阿里云容器服务轻松构建大规模容器平台

阿里云容器服务 ACK（Alibaba Cloud Container Service for Kubernetes）是全球首批通过 Kubernetes 一致性认证的服务平台，提供高性能的容器应用管理服务，支持企业级 Kubernetes 容器化应用的生命周期管理。ACK 在阿里集团内作为核心的容器化基础设施，有丰富的应用场景和经验积累，包括电商、实时音视频、数据库、消息中间件、人工智能等场景，支撑广泛的内外部客户参加 双11 活动；同时，容器服务将阿里内部各种大规模场景的经验和能力融入产品，向公有云客户开放，提升了更加丰富的功能和更加突出的稳定性，容器服务连续多年保持国内容器市场份额第一。

在过去的一年，ACK 进行了积极的技术升级，针对阿里的大规模实践和企业的丰富生产实践，进一步增强了可靠性、安全性，并且提供可赔付的 SLA 的 Kubernetes 集群 – ACKPro 版。ACK Pro 版集群是在原 ACK 托管版集群的基础上发展而来的集群类型，继承了原托管版集群的所有优势，例如 Master 节点托管、Master 节点高可用等。同时，相比原托管版进一步提升了集群的可靠性、安全性和调度性能，并且支持赔付标准的 SLA，适合生产环境下有着大规模业务，对稳定性和安全性有高要求的企业客户。

9 月底，阿里云成为率先通过信通院容器规模化性能测试的云服务商，获得最高级别认证—“卓越”级别，并首先成功实现以单集群 1 万节点 1 百万 Pod 的规模突破，构建了国内最大规模容器集群，引领国内容器落地的技术风向标。此次测评范围涉及：资源调度效率、满负载压力测试、长稳测试、扩展效率测试、网络存储性能测试、采集效率测试等，客观真实反映容器集群组件级的性能表现。目前开源版本 Kubernetes 最多可以支撑 5 千节点及 15 万 Pod，已经无法满足日益增长的业务需求。作为云原生领域的实践者和引领者，阿里云基于服务百万客户的经验，从多个维度对 Kubernetes 集群进行优化，率先实现了单集群 1 万节点 1 百万 Pod 的规模突破，可帮助企业轻松应对不断增加的规模化需求。

在应用管理领域，OpenKruise 项目已经正式成为了 CNCF 沙箱项目。OpenKruise 的开源也使得每一位 Kubernetes 开发者和阿里云上的用户，都能便捷地使用阿里内部云原生应用统一的部署发布能力。阿里通过将 OpenKruise 打造为一个 Kubernetes 之上面向大规模应用场景的通用扩展引擎，当社区用户或外部企业遇到了 K8s 原生 Workload 不满足的困境时，不需要每个企业内部重复造一套相似的“轮子”，而是可以选择复用 OpenKruise 的成熟能力。阿里集团内部自己 OpenKruise；而更多来自社区的需求场景输入，以及每一位参与 OpenKruise 建设的云原生爱好者，共同打造了这个更完善、普适的云原生应用负载引擎。

在应用制品管理领域，面向安全及性能需求高的企业客户，阿里云推出容器镜像服务企业版 ACR EE，提供公共云首个独享实例的企业级服务。ACR EE 除了支持多架构容器镜像，还支持多版本 Helm Chart、Operator 等符合 OCI 规范制品的托管。在安全治理部分，ACR EE 提供了网络访问控制、安全扫描、镜像加签、安全审计等多维度安全保障，助力企业从 DevOps 到 DevSecOps 的升级。在全球分发加速场景，ACR EE 优化了网络链路及调度策略，保障稳定的跨海同步成功率。在大镜像规模化分发场景，ACR EE 支持按需加载，实现镜像数据免全量下载和在线解压，平均容器启动时间降低 60%，提升 3 倍应用分发效率。目前已有众多企业生产环境模使用 ACR EE，保障企业客户云原生应用制品的安全托管及多场景高效分发。

我们希望，阿里云上的开发者可以自由组合云上的容器产品家族，通过 ACK Pro+ACR EE+OpenKruise 等项目，像搭积木一样在云上打造众多企业自有的大规模容器平台。

更多企业落地实践内容，可下载云原生架构白皮书了解详情！

TiDB 简介

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

KubeSphere 简介

KubeSphere 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台，完全开源，支持多云与多集群管理，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。

部署环境准备

KubeSphere 是由青云 QingCloud 开源的容器平台，支持在任何基础设施上安装部署。在青云公有云上支持一键部署 KubeSphere（QKE）。

下面以在青云云平台快速启用 KubeSphere 容器平台为例部署 TiDB 分布式数据库，至少需要准备 3 个可调度的 node 节点。你也可以在任何 Kubernetes 集群或 Linux 系统上安装 KubeSphere，可以参考 KubeSphere 官方文档。

1. 登录青云控制台：https://console.qingcloud.com/，点击左侧容器平台，选择 KubeSphere，点击创建并选择合适的集群规格：

2. 创建完成后登录到 KubeSphere 平台界面：

3. 点击下方的 Web Kubectl 集群客户端命令行工具，连接到 Kubectl 命令行界面。执行以下命令安装 TiDB Operator CRD：

kubectl apply -f https://raw.githubusercontent.com/pingcap/TiDB-Operator/v1.1.6/manifests/crd.yaml

4. 执行后的返回结果如下：

5. 点击左上角平台管理，选择访问控制，新建企业空间，这里命名为 dev-workspace

6. 进入企业空间，选择应用仓库，添加一个 TiDB 的应用仓库：

7. 将 PingCap 官方 Helm 仓库添加到 KubeSphere 容器平台，Helm 仓库地址如下：

8. 添加方式如下：

部署 TiDB-Operator

1. 首选创建一个项目（Namespace）用于运行 TiDB 集群：

2. 创建完成后点击进入项目，选择应用，部署新应用

3. 选择来自应用模板:

4. 选择 pingcap，该仓库包含了多个 helm chart，当前主要部署 TiDB-Operator 和tidb-cluster。

5. 点击 TiDB-Operator 进入 Chart 详情页，点击配置文件可查看或下载默认的 values.yaml，选择版本，点击部署：

6. 配置应用名称并选择应用版本，确认应用部署位置：

7. 继续下一步，该步骤可以在界面直接编辑 values.yaml 文件，自定义配置，当前保留默认即可：

8. 点击部署，等待应用状态变为活跃：

9. 点击工作负载（Deployment），查看 TiDB-Operator 部署了 2 个 Deployment 类型资源：

部署 TiDB-Cluster

1. TiDB-Operator 部署完成后，可以继续部署 TiDB-Cluster。与部署 TiDB-Operator 操作相同，选择左侧应用，点击 tidb-cluster：

2. 切换到配置文件，选择版本，下载 values.yaml到本地：

3. TiDB Cluster 中部分组件需要持久存储卷，青云公有云平台提供了以下几种类型的 StorageClass：

/ # kubectl get sc
NAME                       PROVISIONER     RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
csi-high-capacity-legacy   csi-qingcloud   Delete          Immediate           true                   101m
csi-high-perf              csi-qingcloud   Delete          Immediate           true                   101m
csi-ssd-enterprise         csi-qingcloud   Delete          Immediate           true                   101m
csi-standard (default)     csi-qingcloud   Delete          Immediate           true                   101m
csi-super-high-perf        csi-qingcloud   Delete          Immediate           true                   101m

4. 这里选择 csi-standard 类型，values.yaml 中的 StorageClassName 字段默认配置为 local-storage。因此，在下载的 yaml 文件中直接替换所有的 local-storage 字段为 csi-standard。在最后一步使用修改后的 values.yaml 覆盖应用配置文本框中的内容，当然也可以手动编辑配置文件逐个替换：

5. 这里仅修改 storageClassName 字段用于引用外部持久存储，如果需要将 tidb、tikv或 pd 组件调度到独立节点，可参考 nodeAffinity 相关参数进行修改。点击部署，将 tidb cluster 部署到容器平台，最终在应用列表中可以看到如下 2 个应用：

查看 TiDB 集群监控

1. TiDB 集群部署后需要一定时间完成初始化，选择工作负载，查看 Deployment 无状态应用：

2. 查看有状态副本集（StatefulSets），其中 tidb、tikv 和 pd 等组件都为有状态应用：

3. 在 KubeSphere 监控面板查看 tidb 负载情况，可以看到 CPU、内存、网络流出速率有明显的变化：

4. 在 KubeSphere 监控面板查看 TiKV 负载情况：

5. 查看容器组（Pod）列表，tidb 集群包含了 3 个 pd、2 个 tidb 以及 3 个 tikv 组件：

6. 点击存储管理，查看存储卷，其中 tikv 和 pd 这 2 个组件使用了持久化存储：

7. 查看某个存储卷用量信息，以 tikv 为例，可以看到当前存储的存储容量和剩余容量等监控数据。

8. 在 KubeSphere 项目首页查看 tidb-cluster 项目中资源用量排行：

访问 TiDB 集群

1. 点击左侧服务，查看 TiDB 集群创建和暴露的服务信息。

2. 其中 TiDB 服务 4000 端口绑定的服务类型为nodeport，直接可以在集群外通过 nodeIP 访问。测试使用 MySQL 客户端连接数据库。

[root@k8s-master1 ~]# docker run -it --rm mysql bash [root@0d7cf9d2173e:/# mysql -h 192.168.1.102 -P 32682 -u root Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 201 Server version: 5.7.25-TiDB-v4.0.6 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show databases; +--------------------+ | Database | +--------------------+ | INFORMATION_SCHEMA | | METRICS_SCHEMA | | PERFORMANCE_SCHEMA | | mysql | | test | +--------------------+ 5 rows in set (0.01 sec) mysql>

查看 Grafana 监控面板

另外，TiDB 自带了 Prometheus 和 Grafana，用于数据库集群的性能监控，可以看到Grafana 界面的 Serivce 3000 端口同样绑定了 NodePort 端口。访问 Grafana UI，查看某个指标：

总结

KubeSphere 容器平台对于云原生应用部署非常友好，对于还不熟悉 Kubernetes 的应用开发者而又希望通过在界面简单配置完成 TiDB 集群的部署，可以参考以上步骤快速上手。我们将在下一期的文章中，为大家分享另一种部署玩法：将 TiDB 应用上架到 KubeSphere 应用商店实现真正的一键部署。

另外，TiDB 还可以结合 KubeSphere 的多集群联邦功能，部署 TiDB 应用时可一键分发 TiDB 不同的组件副本到不同基础设施环境的多个 Kubernetes 集群，实现跨集群、跨区域的高可用。如果大家感兴趣，我们将在后续的文章中为大家分享 TiDB 在 KubeSphere 实现多集群联邦的混合云部署架构。

参考

• KubeSphere GitHub: https://github.com/kubesphere/kubesphere
• TiDB GitHub: https://github.com/pingcap/TiDB
• TiDB Operator 快速入门: https://github.com/pingcap/docs-TiDB-Operator/blob/master/zh/get-started.md
• TiDB-Operator 文档: https://docs.pingcap.com/tidb-in-kubernetes/stable/TiDB-Operator-overview
• KubeSphere Introduction: https://kubesphere.io/docs/introduction/what-is-kubesphere/
• KubeSphere Documentation: https://kubesphere.io/docs/

关于 KubeSphere

KubeSphere （https://kubesphere.com.cn）是在 Kubernetes 之上构建的开源容器混合云，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。KubeSphere 已被 Aqara 智能家居、本来生活、新浪、华夏银行、四川航空、国药集团、微众银行、紫金保险、中通、中国人保寿险、中国太平保险、中移金科、Radore、ZaloPay 等海内外数万家企业采用。KubeSphere 提供了开发者友好的向导式操作界面和丰富的企业级功能，包括多云与多集群管理、Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、存储与网络管理、GPU support 等功能，帮助企业快速构建一个强大和功能丰富的容器云平台。