上QQ阅读APP看本书，新人免费读10天

设备和账号都新为新人

推荐文章 | Article

解读云原生的2021：抢占技术C位，迎来落地大爆发

作者褚杏娟审校蔡芳芳

本文是“2021 InfoQ年度技术盘点与展望”系列文章之一，由InfoQ编辑部制作呈现，重点聚焦云原生领域在2021年的重要进展、动态，希望能帮助你准确把握2021年云原生领域的核心发展脉络，在行业内始终保持足够的技术敏锐度。

“InfoQ年度技术盘点与展望”是InfoQ全年最重要的内容选题之一，将涵盖架构、AI、大数据、大前端、云计算、数据库、中间件、操作系统、开源、编程语言十大领域，后续将聚合延展成专题、迷你书、直播周、合集页面，在InfoQ媒体矩阵陆续放出，欢迎大家持续关注。

特此感谢傅轶、黄玉奇、马若飞、彭涛、彭锋、宋净超、汤志敏（按姓名首字母排序）对本文的贡献，他们的真知灼见，是本文能与大家见面的关键。

数据显示，云原生计算基金会（CNCF）现在拥有730多个成员组织和100多个开源云原生项目，整个云原生生态逐步趋于完善。

根据CNCF统计，OpenTelemetry在CNCF中拥有第二大贡献社区，仅次于Kubernetes（下文简称K8s）；如果把Argo和Flux项目的发展速度结合起来，那么GitOps生态系统在CNCF中的发展速度是最快的；Envoy社区继续保持强大且不断增长，已成为整个Service Mesh生态系统中使用最广泛的数据平面之一。专注于开发者体验改进的项目，无论是Backstage、Dapr还是GitOps生态系统，都在持续增长。

SlashData最新数据显示，目前已经有680万云原生开发人员，其中460万人使用容器编排工具，400万使用Serverless平台，同时使用两者的人达180万。

开发人员正在考虑如何通过云原生技术，用统一架构、统一技术堆栈来支撑更多类型的工作负载，避免不同负载、不同架构和技术带来的“烟囱”系统、重复投入和运维负担等问题。

此外，2021年，云原生领域还发生了哪些值得关注的事儿呢？

重要事件回顾

技术动态

• 2月4日，“策略即代码"项目Open Policy Agent正式从CNCF毕业，意味着人们对统一授权解决方案越来越感兴趣。同月，Service Mesh第一届社区会议IstioCon召开，展示了Istio的实践经验等内容。

• 3月，持续交付 (CD) 平台Flux进入CNCF孵化阶段。Flux v2提供了全面的GitOps解决方案，支持将git存储库存到本地或远程集群，自动更新、渐进交付。这在一定程度上意味着会有更多GitOps程序出现和成熟。

• 6月22日，可观测性平台项目Pixie成为CNCF沙盒项目。

• 7月，第一个Service Mesh项目Linkerd从CNCF毕业。Linkerd可以在不需要更改代码的情况下，为云原生应用程序提供关键的可观测性、安全性和可靠性。

• 同样在7月，Kafka / Spark宣布K8s support GA，这意味着大数据生态开始全面拥抱K8s，大数据平台很快不再需要独立的资源管理。

• 8月26日，可观测性项目OpenTelemetry成为CNCF孵化项目。OpenTelemetry现在在CNCF中拥有第二大贡献社区，表明大家对现代可观测性工具和协作的兴趣仍然很重要。

• 9月，AWS发布了EKS Anywhere，并开源了EKS Distro发行版，支持线下异构环境的K8s部署。同月，阿里云容器服务全面升级为ACK Anywhere，并发布ACK发行版、ACK敏捷版和ACK ONE分布式云容器平台。两者的目标都是让企业在任何环境都能获得一致的容器基础设施能力。

• 10月13日，基于eBPF的高性能容器网络项目Cilium成为CNCF孵化项目。Cilium是Datadog网络堆栈的重要组成部分，可以在云供应商之间提供一致的Kubernetes网络，以及性能和安全的通信。目前大多数大型云服务提供商都依赖于Cilium。

• 11月，开源微服务构建软件Dapr正式加入CNCF孵化项目。Dapr是一个开源、可移植、基于事件驱动的运行时，开发者可以用它构建运行在云端和边缘的具有弹性、无状态、有状态、基于微服务的应用程序。云原生本质上是进行解耦和分布式应用改造，所以在云原生的落地过程中，类似Dapr这样的服务变得越发重要。

• 11月2日，Serverless项目Knative 1.0发布，同月Google宣布将Knative捐赠给云原生计算基金会 (CNCF)。Knative提供面向K8s标准化API进行Serverless应用编排能力，支持基于流量的自动弹性、灰度发布、多版本管理、缩容到零、事件驱动Eventing等诸多特性，已成为K8s上安装最广泛的无服务器层。

• 11月3日，腾讯云发布云原生操作系统遨驰Orca。据悉，腾讯云原生操作系统遨驰单集群支持10万级服务器、百万级容器规模，管理的CPU核数超过1亿，计算正式进入亿级时代。

行业动态

• 今年1月，红帽宣布收购K8s原生安全初创公司Stackrox，计划将其添加到Red Hat OpenShift中。OpenShift对Windows容器的支持普遍可用。

• 4月，亚马逊云科技将分叉项目Elasticsearch OpenDistro重新命名为OpenSearch，7月发布了OpenSearch 1.0版本。9月，Amazon Elasticsearch Service更名为Amazon OpenSearch Service，并支持OpenSearch 1.0。

• 当地时间7月7日，美国国防部宣布正式取消与微软的100亿美元JEDI云计算合作，后续计划将此分拆给微软和亚马逊两家公司。云计算领域竞争加剧。

• 当地时间8月12日，Google、Microsoft、Isovalent、Facebook和Netflix联合宣布，Linux基金会旗下的非营利性组织eBPF基金会正式成立。该基金会致力于推动开源项目eBPF的发展，支持Linux和其他开源技术的商业增长。

• 当地时间10月14日，全球第二大开源代码托管平台GitLab正式在纳斯达克上市，市值接近150亿美元。12月，GitLab公司宣布收购Opstrace，用以扩展其DevOps平台。

• 当地时间，12月9日，开源软件公司HashiCorp（HCP）正式在纳斯达克挂牌上市，成为今年全球市值最高的开源公司。HashiCorp提供多云基础设施自动化技术，以及一套自动化工具来帮助企业转型为云运营模式。

直播预约卡片

重点技术演进

云原生领域涵盖的技术类别越来越多，但最关键的三项是容器、Serverless、Service Mesh，因此本文主要围绕这三个领域做了年终回顾和趋势展望。

容器：大规模应用的一年

2021年可以称得上是容器大规模应用的一年。基于K8s来屏蔽异构环境的差异，搭建分布式云架构已经成为企业和云厂商的共识。

“今年，对容器的应用呈现出井喷趋势，我们通过弹性计算、自动漂移等方式对业务容器的云原生进行了改造。”受访专家对InfoQ表示。这一现象也体现在了数据上：根据SlashData最新报告，现在有560万开发者使用K8s，较去年增长了67%，尤其在500名以上员工的企业中，K8s和容器的采用率猛增。

总体来看，企业对容器的应用诉求可以分为三个阶段：

第一阶段，降本增效。在这个阶段，企业主要收口线上资源，将IDC、物理网络、虚拟网络、计算和存储等资源，通过IaaS、PaaS等实现虚拟化封装、切割和再投产的自动化流程。整合后的资源会形成统一的资源池，对特定服务器资源的依赖度大大降低。

第二阶段，增加服务的可扩展性和弹性。在这个阶段，企业在公有云、私有云和专属云等新型动态计算环境中构建和运行可弹性扩展的应用。业务对平台使用声明式API调用不可变基础设施、Service Mesh和容器服务构建容错性好、易于观察的应用系统，同时结合平台的自动化恢复、弹性计算来提高服务的稳定性。

第三阶段，“混合部署”成为常态。这个阶段中，企业需要做好服务依赖的梳理和定义。所依赖的基础组件、基础服务云原生化服务完全不需要关心底层资源、机房、运行和供应商。企业利用开放的生态和标准的云原生应用模型，完成跨地域、跨云的自动化灾备自举。

目前，大多数企业已经进行到第二、三阶段。随着更大规模的应用，企业对容器核心技术的启动效率、资源开销、调度效率也有了更高的要求。

全链路的云原生化是目前比较核心的需求，也是落地场景比较难的课题。具体体现在以下几个方面：

• 落地难。整体来说，基于云原生概念构建复杂的生产环境业务是一个任重道远的过程。从基础组件的云原生化、到基础设施的全链路支持，再到公司内已有服务的云原生改造，都需要企业投入大量的时间和精力。虽然业界总体上在CNCF基金会的主导下趋于统一，但不同公有云厂商的标准实现起来仍有差异。这个问题关系到了企业能从云原生上具体获得哪些长效收益来支撑企业长期投入。

• 集中式云计算中心很难支撑起对实时要求高的业务。业务的解耦程度越高，相互的调用时延也越长，时延放大到客户端就会带来用户体验的下降。这类问题是集中式云计算中心的通病。这个问题的解决将会让企业在现行计算模型下获得成本和用户体验上的极大改善。

• 随着接入的服务越来越多，K8s的配置复杂度随之上升。K8s本意是想解放生产力，但相关的配置浩如烟海，开发人员需要了解很多概念。而面向终态的API设计和面向命令式的API设计之间存在思维方式冲突，往往需要加入第三方组件来协调，例如Service Mesh接管了流量等。

2022年，容器技术将持续发挥其高效调度和弹性能力，通过与最新节能数据中心技术、芯片等结合，帮助企业实现上下游的全栈优化。企业会构建出更多插件来扩展K8s平台的能力。大型分布式应用都会面向K8s编程，整个K8s生态开始发生体系化的演进。

容器的智能化运维体系建立也是一个重点。复杂容器集群和应用也带来了一系列管理问题，为此，增强K8s master、组件和节点的自愈自恢复能力，提供更加友好的异常诊断、K8s配置推荐、弹性预测等能力是很有必要的。

另外，安全合规问题越来越被大家重视。StackRox报告显示，55%的受访者出于安全考虑推迟了将K8s应用程序部署到生产环境中。安全问题将促进DevOps向DevSecOps的全面演进，具体包括面向Helm、Operator等OCI Artifacts优化整体的安全定义、签名、同步和三方交付；加固容器的南北向和东西向的网络隔离和治理，推进零信任的链路安全；进一步提升安全容器和机密计算容器的性能和可观测能力等。

Serverless：应用更加理性

Serverless在2019年取得了重大发展，如今两年过去，企业对Serverless的使用变得更加谨慎。根据SlashData最新报告，参与Serverless架构的开发人员比例从27%下降到了24%。

企业对Serverless的使用各有不同。有的企业选择自研Serverless平台，有的在开源项目如Knative等上面自建平台，有的则直接采购商用平台。Serverless是要解决容器和Kubernetes未能解决的问题，如开发部署效率提升、运维自动化、事件触发与编排等。但是，不同的方向对Serverless有不同的出发点和需求。

比如对前端来说，Serverless可以减少其对运维等不太擅长领域的依赖，解放出更多精力在SSR服务端渲染、小程序和H5开发、BFF接口聚合服务等方面进行深入探索。同时Serverless的自动扩缩容等特性可以在前端经常涉及的活动页面、长尾应用上提供很大帮助，减少前端在部署、运维层面的人力成本。对于批量任务、离线算法类操作，需要人为调整算法所需资源，没办法做到弹性自动化扩缩容，而Serverless平台自动扩缩容特性可以减轻日常运维压力。

Serverless涵盖了很多技术，基本分为两类：FaaS（Function as a Service，函数即服务）和BaaS（Backend as a Service，后端即服务）。在语言和环境方面，FaaS函数就是常规的应用程序。业务代码下沉至函数级、运维能力集成平台统一提供，或将带领云原生进入下一个发展阶段。

但是，目前Serverless最核心的挑战是更广义层面的推广和实际落地。

企业内部基础架构部门研发的Serverless平台，想要真正帮助业务部门解决实际痛点就需要和应用场景更充分地结合。Serverless的应用场景多样化是很明显的一个特点，但是难点在于，一个好的Serverless平台既要避免太多定制化功能，还保持技术上的通用性和可复用性。

对于企业来说，Serverless平台的搭建是直接采购商业化的项目还是完全自研，亦或是基于开源项目做定制化开发？这也是困扰很多企业的问题。

目前Serverless领域并没有一个被大规模使用的开源组件，市面上的很多项目或多或少存在一些不成熟或者不能满足需求的情况。正如SlashData最新报告中分析，Serverless研发人员比例下降可能是由于Serverless解决方案缺乏灵活性，公司担心被锁定在特定供应商中。尽管Google Cloud Run已经获得了很多拥护者，但目前有53%的Serverless开发者在使用AWS Lambda，其仍是目前最受欢迎的Serverless解决方案。

Serverless的标准不统一也是个问题。虽然CNCF已经推出了Serverless Workflow规范，但目前各大云厂商和开源项目基本都是有着自己的标准，很少互相适配，造成了事件编排使用上的割裂以及厂商锁定和平台迁移困境。因此，Serverless还需要朝着更开放、更友好的方向发展。

Serverless生态，来源CNCF

接下来，Serverless还需要做到更加智能地快速扩缩容。很多Serverless平台的自动扩容算法需要用户填写一些预估参数，但用户往往并不清楚自身服务的Qps或者并发请求数，这导致用户接入存在障碍。因此，Serverless平台一方面需要采集更多的指标数据，另一方面需要聚合全方位的指标后提出更智能的算法，减少用户接入和使用成本。

从技术角度看，Serverless还面临的挑战有：企业内部的Serverless平台面对混合云场景时，如何扩展到公有云上，实现更加灵活的Serverless架构；Serverless技术实现上需要考虑与重视与Service Mesh融合、与现有微服务网关打通、与服务治理等能力适配问题；Serverless快速扩缩容特性也会对网络、存储、中间件等提出更高的稳定性要求。

“Serverless已经广为人知，各大厂商对其宣传也愈演愈烈。但开发者还是需要冷静思考自身的需求，避免被Serverless的各种概念引导和束缚。”受访专家提醒道。

Service Mesh：落地问题尚待解决

今年，Service Mesh的落地越来越多，尤其是在银行电信等传统行业和中小企业中。“去年Service Mesh使用增长率在50%左右，虽然今年的统计还没出来，但我认为今年可能还是会大幅度提升。”受访专家表示。

随着Istio、Linkerd和Kuma等开源项目逐渐成熟，企业对Service Mesh的兴趣越来越大。Service Mesh是云原生网络基础设施，企业对于Service Mesh的需求主要体现在以下几点：

• 统一的服务治理方案。这个方案对系统是无侵入的，同时不受技术栈的制约。比如使用Spring Cloud必须受限于Java语言，但异构系统或多技术栈的综合性系统并不希望受此限制。

• 流量管理的云原生实现。比如灰度发布、动态路由、弹性设计等无侵入的方案。

• 较低的维护成本和学习成本。现有技术栈的使用方案，如Spring Cloud等的维护、学习成本等较高，都不利于落地。

Service Mesh生态，来源CNCF

近一两年内，Service Mesh仍需聚焦在一些落地问题的解决上。以Istio为例，大家对其最大的疑问是Istio是否会影响应用性能、扩展性是否足够好。此外，Istio太过复杂、旧服务迁移成本高，业界经验少、学习曲线陡峭也是很多开发者的顾虑。

现在，Istio的架构已经稳定，也被很多企业应用，但整个生态还处于萌芽之中。今年，Istio的开源生态有明显的向上发展趋势，例如网易轻舟定位于Service Mesh智能管理器的开源项目Slime和基于lstio Envoy构建的云原生API网关Hango，以及腾讯云为Istio提供的一种非侵入式的协议扩展解决方案Aeraki等。可以看出，Istio生态的发展也是围绕具体落地问题来进行的。

总体来说，Service Mesh产品的成熟度还有待加强。首先，Service Mesh产品需要解决易用性问题，从部署方式、使用方式等各方面着手，尽可能地降低开发者的学习和使用成本；其次，Service Mesh需要有更高的性能，比如在延迟性上，有些业务对几毫秒延迟没有感知，但有些特殊业务就非常敏感，要求相对也更高；另外，虽然Service Mesh现有解决方案的流控是相对比较完整的，但也比较粗粒度，不够精细和完善。

“从技术角度来说，今年不是一个有剧烈变化或者重大突破的年份，更多还是在稳步发展的阶段。”受访专家表示。明年，Service Mesh还是会继续按需迭代、稳步发展。

随着云原生技术领域里各种技术的发展，基于Serverless部署的应用、Service Mesh、现有微服务网关打通和服务治理等等，如何更好地适配、更高效地发挥作用，都对技术提出了更高的要求。

值得关注的“新”技术

这里的“新“技术，并非指那些最新的研发成果，而是新加入云原生体系、用来解决新问题的技术，这些技术或许会对云原生的发展起到重要作用。

边缘计算

随着5G、IoT、音视频、直播、CDN等发展，企业开始将更多的算力和业务下沉到距离数据源或者终端用户更近的地方，从而来获得更短的响应时间并降低成本。这就是区别于传统中心式的云计算模式——边缘计算。

边缘计算的正式概念是在2003年由IBM和Akamai共同提出来的。作为云计算的延伸，边缘计算广泛应用在混合云/分布式云、IoT等场景，用来补齐算力集中的云计算在面对“低时延、大带宽、大链接、本地化、安全”等需求场景下的短板。

当前，边缘计算还在不断发展中。从Gartner预测报告来看，边缘计算还处于上升阶段，需要2~5年才能达到平稳期。当前业界对边缘计算的理解和应用主要分成五种：

• 传统的CDN厂商（如Akamai，国内的帝联、蓝汛等），对于边缘计算的研究主要是以降低计算访问延迟为主。

• 云厂商（如亚马逊、腾讯、阿里），主要是为了丰富自己的云计算产品，将用户的计算任务部署在云上，降低云服务的访问延迟。

• 小米、华为等智能家居厂商，是最极端的边缘计算，从计算的发起到在网络上只需要“一跳”，通过边缘计算建立本地的计算中心。

• 以Google、Facebook为首的互联网厂商，将边缘计算作为AR、VR的基座进行开发，主要是利用边缘计算来降低计算时延和提升计算可靠性。

• 以运营商为主的厂商则主要希望通过边缘计算来支撑更多的设备接入，降低带宽传输。

目前，边缘计算的挑战有很多。首先，不同的场景下的设备接入标准、预期等都不一样，很难有一个标准化的落地方案，这对边缘计算平台的设计能力是非常大的考验。其次，与集中式云计算不同，边缘端系统最需要考虑的就是在弱网甚至断网环境下如何提供服务，这很考验设备的的接入速度。再者，通常情况下，边缘节点不像云计算中心有大批量的资源冗余，往往节点很少，可靠性和可用性不高。如何让这部分计算任务无损平滑地完成是一个难度很高的课题。最后，边缘端系统接入的服务类型很多，比如智能驾驶接入边缘要完成视频解析，AR/VR要求完成实时渲染等，所以通用平台的建设很重要。

针对边缘计算云原生架构和技术体系，具体需要解决以下问题：云边运维协同、弹性协同、网络协同、边缘IoT设备管理、轻量化、成本优化等。

机器学习

在数字化转型浪潮下，企业需要处理的数据量越来越大。2015年，许多公司在初步尝试实现“大数据”的承诺时，建立了大型的本地数据湖。但在那个时候，云原生AI平台还没有成熟到足以激励企业将数据密集型ML项目迁移到云环境。

随着云计算和人工智能的不断发展，两种技术的协同将为创新公司带来显著的竞争优势。企业内部使用容器的范围从最初的在线业务正在逐渐向AI、大数据演进，对GPU等异构资源的管理和AI任务和作业的管理需求也越来越多。

深度学习、AI任务成为社区寻求云原生技术支撑的重要工作负载之一。AI要成为企业生产力，必须以工程化的技术来进行模型开发、部署、管理、预测、推理等全链路生命周期管理。目前，AI工程化领域有三大亟待推进的事情：数据和算力的云原生化、调度和编程范式的规模化、开发和服务的标准化普惠化。

这三件事情的实现，需要持续优化GPU等异构架构的高效调度，结合Kubeflow Arena的AI任务流水线和生命周期管理能力和分布式缓存、分布式数据集加速等技术。业内认为，云原生和AI的融合将在提高算法模型的开发效率和提升交付、部署、运维环节的效率并降低TCO等方面，起到很大作用。

可观测性

不管是容器、Serverless还是Service Mesh，监控、日志还是链路追踪，真正在生产环境中部署还需要可观测性的支撑。由于传统主机和K8s在很多方面存在较大差异，如何搭建一套适合云原生的可观测性体系是企业发展道路上必须面对的问题。

对于K8s集群下的Pod日志采集，目前主要分为DaemonSet和Sidecar两个流派，不同的Agent部署方式在用户体验和运维形态上有较大区别。对业务应用部署方式是否有侵入，使用emtyDir、hostPath还是pv来挂载日志目录，如何注入K8s的namespace、Pod等元信息，对下游带来的吞吐压力如何等，很多没有相关经验的企业都被这些问题困扰，而社区始终没有统一的答案。

相比日志的百花齐放，Prometheus提供了比较统一和标准化的监控，基于各类Exporter、AlertManager和Grafana生态搭建一个基础的云原生监控平台对很多企业来说挑战不算大，甚至能够进一步在Prometheus-Operator的基础上加速达到更加云原生化的体验。但大部分企业长期停留在了这一阶段，基本可用和期望中的稳定、易用、智能化存在一定距离。

统一的可观测性平台能够将log、monitor和trace结合起来，这对很多企业都有很大的吸引力。国内外云厂商和提供可观测性服务的公司，一直在可观测性的融合上发力，同时CNCF在持续推行OpenTelemetry及其标准，也在这个方向添了一把火。

一定程度上，可观测性更多是关于组织的文化转变，而不仅仅是使用行业正在融合的一些技术、工具和平台。

写在最后

回顾这一年，云原生技术稳步发展，也更加注重解决落地实践上遇到的具体问题，未来方向也是如此。我们期待2022年云原生领域有更多的技术进展，整个生态更加繁荣。

采访嘉宾介绍（按姓名首字母排序）：

傅轶，网易数帆架构师，轻舟日志平台负责人；

黄玉奇（花名：徙远），阿里云高级技术专家，Kubernetes Member，CNCF边缘计算云原生项目OpenYurt负责人；

彭涛，同程旅行容器云平台负责人、架构师，Kubernetes Flink代码贡献者；

彭锋，智领云联合创始人兼CEO，拥有20余年软件开发、大数据及云计算经验；

宋净超（Jimmy Song），Tetrate布道师，云原生社区创始人；

马若飞，Freewheel首席工程师，《云原生应用架构》作者，AWS container hero；

汤志敏，阿里云资深技术专家，目前负责阿里云容器技术相关后端产品和研发工作。