2022 年，云原生领域有哪些值得关注的趋势？

2021 年，云原生取得很多重要进展。2022 年又有哪些值得关注的趋势？12 月 27 日，阿里云资深技术专家李国强（崭岩）做客 InfoQ 视频号，对云原生趋势做了最新的解读。以下根据直播内容整理，有不改变原意的删减，完整内容可点击查看回放视频。

Q：2021 年，云原生领域发生了哪些您比较印象深刻的事情？

A：在 2020 年的时候，云原生理念就被提到得越来越多，但我觉得真正呈现出爆发形态、真正被所有的云厂商、用户广泛使用的是在 2021 年。

2021 年发生了很多印象深刻的事情，可以挑两件跟大家分享。

第一个，分布式云在 2021 年有了比较大的爆发。不管是用户使用还是各个云厂商的技术支持方面，都呈现出了非常火热的趋势。为什么呢？我觉得这跟大家业务形态的发展联系非常紧密。直播、5G、IOT 等领域的兴起，让业务对于云的形态需求更高，大家希望云能够更贴近数据的产生点，因此相应的边缘云、本地云、混合云的形态越来越多。现在，整个云计算有一个很重要的趋势，就是呈现一云多形态的模式，用户在各个地方都能用到云计算的能力。但这也对云的基础设施提出了比较大的挑战。用户以前就是用一朵云，管理复杂度是可以接受，但多朵云形态后，挑战难度就比较大了。

云原生技术天然能够比较好地解决云变成多形态后的统一界面管理问题，包括混合云带来的复杂度挑战。所以各个云厂商在这方面的投入非常大。亚马逊的 EKS Anywhere 在今年九月份上线，阿里云也在今年 10 月发布了 ACK Anywhere，两者本质上都是提供更加完备的方案让用户可以在一朵云的模式下使用多朵云。业务场景驱动了技术的普遍落地。

第二个，2021 年，头部互联网公司的云原生落地到达了一个里程碑式的关键节点，代表性事件就是各大互联网公司基本完成了云原生化，所有业务百分之百上云。如今，云原生的核心技术如容器、微服务、服务网格等的可用性和成熟度都已经可以支撑起头部互联网的体量。每个行业的云原生进度不一样，头部互联网公司跑得比较靠前，基本都做到了全面云原生化。未来几年，其他行业会逐步追随互联网的脚步全面走向云原生化。

Q：有人说，云原生乃至整个云计算就是标准之争。您怎么看待这句话？这场“战争”您认为结束了吗？

A：这个是蛮有意思的话题。实际上，现在云原生领域的开源是非常火的。CNCF 里面有非常多的开源项目，里面的项目已经超过一千了。这么多开源项目的标准到底和云计算公司是什么关系？在我个人看来，我不会把它定义为标准之争，因为标准演进的作用对于云厂商和用户来讲都是非常关键，只有标准化后，才能真正实现规模化和效率的提升。未来，不管是云厂商还是其他企业，大规模、高效率的方向一定是标准化。

在云原生领域有几个比较关键的标准。最早出现的是容器，解决了应用打包标准化和应用发布标准化的问题。在此之前，虚拟机等方式的标准化程度是不够的，Docker 终结了这一问题。随着 Docker 的不断演进和推广，在应用编排、资源调度等有出现了新的问题，当时的 Docker  Swarm、Mesos 和 Kubernetes 互相竞争，最后 Kubernetes 胜出，并带来了新的资源编排方面的事实标准。今天的 Kubernetes 已经成为一个事实标准。而应用层之前也是百家争鸣的情况，每个企业都在做自己的云原生应用，现在有越来越多的开源声音和标准出现，如 Open  Application  Model 等，大家都在尝试定义应用层的标准。

2000 年或者更早的时候，标准化的玩法是，一些组织设立标准委员会去制定。今天标准的定制流程更多的是先有开源项目，当开源成为事实标准后，大家来 Follow。国内还会有一些相关的部门参与标准的制定和推广。对我来讲，标准化更多的是企业和生态的协作，推动整个云计算和云原生技术体系更加规模化和普适化。

Q：云原生领域有什么趋势会延续到 2022 年？

A：云原生领域真的是太丰富了，有非常多的东西会延续到下一年，包括前面讲到的分布式云。我还是非常看好分布式云里的边缘计算场景的，为什么呢？因为这个场景正变得越来越丰富。例如，大家现在看文字内容越来越少，音视频越来越多，因此视频处理业务发展非常快，对边缘计算的需求会越来越强烈。

边缘计算作为云计算的延展会被应用到更多领域，同样也会给基础设施带来很多的挑战，比如有的边缘侧网络可能是弱网络，计算资源也不丰富，基础设施怎样在这种情况下发挥作用。云边协同的时候如何解决运维等问题。边缘架构之下，容器在网络打通、弹性负载等方面可以发挥比较大的作用。这方面，云厂商的投入也比较大，多个开源的项目如 OpenYurt、KubeEdge 等多个边缘侧开源项目进入 CNCF。2021 年，边缘技术在从业务侧和开源侧的爆发比较强，我期望 2022 年无论是开源社区还是云厂商的支持能力都可以有较大的变化和进展。

Q：有没有边缘计算的应用案例可以分享？

A：案例是非常多的。互联网业务中，大家熟知的像 CDN、音视频处理都是典型的边缘场景。举例来说，很多园区或工厂等会有视频采集，之后企业会做深入分析。工厂、园区、居民楼等是否能监测到安全违规行为就需要在视频采集后进行分析，最终发现问题。以前的流程是先采集视频，然后上传到中心云或者本地服务器进行处理，但这已经不能满足企业的需求了。现在，企业希望采集完后能够就近处理这些视频数据，而不需要再上传到中心云端，以满足网络延迟需求，以及降低网络传输的成本。这种场景下，边缘容器能够对不同场景进行算力管理，包括算法下沉。

再比如电力行业有变电站这种分散在全国各地的基础设施，如何对这些基础设施进行算力管理、将业务快速部署到一些边缘节点等属于边缘领域。以前变电站基础设施升级可能需要人亲自到那个地方去，效率很低。在云原生化后，基础设施管理及其上面的应用管理、算法等都能用云原生的方式解决，效率会大大提升。

Q：随着接入的服务越来越多，k8s 配置也越来越复杂。本来是解放生产力，现在好像被束缚了。您如何看待这个现象？这一年，大家对容器的应用还提出了哪些新的挑战吗？

A：这个蛮有意思的。K8S 解决的是容器编排和资源调度问题，而这个问题对于企业来讲本来就是非常复杂的，只不过 K8S 尝试用云原生的方式去重新定义应用的编排和资源调度，而且是比原来方案更好。现在，K8S 上的业务类型越来越丰富，从最初的无状态到后来的有状态，如今像 AI 这样比较复杂的计算引擎也都放在 K8S 之上了，这就是一个相互促进的过程，这上面的负载类型越来越多，整个 K8S 体系也确实变得越来越复杂，但它能够管理的东西也越来越多。如果未来用户完全使用容器，那容器的复杂度必然会提升。

但对于企业和云厂商来讲，要做的就是在容器能做更多事情后去降低它的复杂度，要不然容器的门槛就会非常高。现在，各个厂商都在考虑从智能运维角度做更多的努力。比如在集群管理方面，如何用智能运维的方式发现当前运行中的一些状况，并且能够给出处理办法。现在也有智能应用画像和资源画像方式提高资源利用率。智能运维也是一个比较热的方向。

还有一点，整个技术栈的变化会带来整个企业组织的变化，很多时候是颠覆性的变化。

围绕容器的生态可以认为是近十年最重要的 IT 技术的变革，它必然会引起一系列的变化，包括企业内部组织的变化。我们会看到，不仅整个运维管理体系在变化，企业内部也会出现新的组织形态，比如 Google 提出的 SRE 团队就是为可用性负责。现在很多深度使用云原生的企业，包括阿里，都有专门的 SRE 团队，这个团队会负责整个可用性相关能力的建设。其次，企业也会出现一些平台横向性的部门，基于云原生体系去支撑上方业务的部门。以前有些企业可能是偏竖井式的业务单元，即一个业务单元下面有支撑团队，容器包括 K8S 会让企业内部有更多平台横向型部门的出现。这也是解决复杂度的一个方法，因为不是每个纵向的业务部门都有足够的资源投入和专业度去解决这个问题。企业足够大的时候一定要考虑在 SRE 层和平台建设层形成横向部门，进行职能分离。

Q：您预计，容器在 2022 年的技术研发重点会是什么？对其未来的应用有哪些展望？

A：今年还有一个很火的词：绿色低碳。另外，今年整个互联网有点像进入寒冬期，很多互联网公司都提出了降本增效。降本已经成为很多企业 CTO 非常重要的 KPI，也成为技术发展的一个必然趋势。

就降本角度来讲，企业能做的事情非常多。从偏底层看，很多云厂商和头部互联网公司在自研芯片，这块的投入是非常大的，但软硬一体确实会带来降本增效。还有比较火的就是容器化操作系统，这个领域大概有六七年的历史了，也是基础设施层面一个比较重要的优化方法。

弹性是很多企业使用广泛的降本增效的方法，特别是和云厂商结合之后，弹性应用更加广泛。目前，很多互联网公司在尝试离在线混部技术，本质上还是提高机器利用率。之前各个厂商在自建机房或者云上购买服务器的利用率往往都低于 10%。这个利用率并不高，很多企业尝试去推高这个水平线，但推高水平线必然会带来很多技术挑战，比如利用率高了之后，多种负载混合跑时，是否会互相影响。几大厂商都在通过开源或商业化产品形式尝试输出离在线混部（多种负载混合部署）技术，我相信离在线混部技术在明年将迎来进一步的产品化。

现在有一个概念叫 FinOps，即面向成本的应用和管理。这方面，目前在做的就是成本可视化，比如了解企业内部几个部门分别在云厂商或本地机房成本是多少、不同业务成本是多少等。

开源方面有一个项目 Kubecost，从开源角度去提供这样的能力。云厂商会在容器服务里提供“成本中心”，帮助用户把云账单和集群关联起来，能清晰地看到每个部门、每个业务的成本，甚至据此给出一些建议。这很适合不同业务混合部署场景。成本管理明年也会看到一些发展。

还有一个比较有意思的事儿，国外云厂商提出来一个概念叫 Carbon Bills，就是碳账单，它把企业成本消耗都转成了碳账单的形式，这也是个比较有意思的方向。

降本这件事情是所有企业永远的诉求，不过当企业在高速发展的时候这个诉求没有那么强烈，会以业务先行。随着业务进入平稳期或者遇到困难时，降本需求会更明显。

Q：Serverless 的应用场景多样化差异比较明显，这会影响该技术的通用性和可复用性吗？为什么？

A：Serverless 也是最近大家谈得比较多的话题。首先想先和大家聊聊什么是 Serverless，因为每个人对 Serverless 的理解不一样。有些人会把 Serverless 简单理解为函数计算，确实最早时候亚马逊推出的 AWS Lambda 就是函数式计算产品，并把它定义为 Serverless。但实际上，今天的 Serverless 范围确实越来越广，Serverless 本质上来讲是一种设计理念，已经不仅仅是函数计算范畴了。

现在，市面上有面向函数计算的 Serverless 产品，也有面向应用的 Serverless 产品，如国外云厂商推出的 App Runner、国内的 Serverless 应用引擎等，让用户对偏传统的应用不需要做改造就可以使用 Serverless 架构，也不用关心底层的 IaaS 基础设施。此外，还有面向 K8S 的 Serverless 产品，用户可以通过 K8S 的界面使用 Serverless，还有面向容器的 Serverless，即用来交付容器实例的 Serverless。这些产品的本质都是让使用者以一个界面使用云资源，而不必关心底下的基础设施。Serverless 多样化给用户带来了更多的选择。

还有一个比较大的趋势就是越来越多的云产品也在变得 serverless 化。如果大家关注了亚马逊的 re:Invent 就会发现，很多云产品本身也在 Serverless 化，比如推出了 Kafka 的 Serverless 版本。这意味着，用户在实际使用云产品时，完全不需要关注云产品本身的规模，直接按照按量付费即可。

云产品本身的 Serverless 化也带来了多样性，在我看来，这个多样性是 Serverless 理念在用户使用界面和产品形态上不断丰富带来的，也在不断推动行业的标准化进程，用户在使用多种多样的 Serverless 产品时，也能用标准的形式去使用各个云厂商的产品。比如函数计算领域，它的触发会是越来越标准的 http 模式，可观测性能够与 Prometheus、OpenTelemetry 等开源技术结合，这些都会让 Serverless 产品标准化程度也越来越高。

用户需求的多样化是与 Serverless 产品的标准化结合在一起的，并且这是一个必经的过程，这样才能有越来越多的用户使用。

Q：我们在 2019 年就说 Serverless 的未来已来，在您看来这个“未来”真的来了吗？

A：Gartner 发布过技术成熟度曲线，一个新技术都会经历上升期、膨胀期、幻灭期，最后到平稳期。在我来看，Serverless 技术现在已经度过幻灭期，开始进入平稳期。前几年应该是 Serverless 最火的时候，当时大家对 Serverless 非常推崇，那时是处于膨胀期。前面提到的场景多样化也与此相关，膨胀期里说的场景越来越多，在真正进入幻灭期后，落地的场景会越来越多。

我举个例子，大家就能够看到 Serverless 落实应用是不是真的已经比较多了。

首先是阿里自己在 2021 年双十一的时候，大量的前端应用实际上是用 Serverless 框架实现的。这是一个比较典型的 Serverless 场景，比较容易落地。阿里内部跨很多业务部门，基于 Node.js 框架的前端业务，如今全部是用 Serverless 框架开发部署、使用的，这也支撑了双十一的海量应用。Serverless 带来了非常高的开发效能和极致弹性的提升。

另外，音视频处理用 Serverless 架构的用户也非常多。某音乐服务厂商今年在阿里公共云上用函数计算进行音视频处理，包括音频转码、自动识别等。厂商选择 Serverless 是因为其弹性能力。比如刚拿到一批歌曲的版权后，厂商要快速地对所有歌曲进行码质的转换，这就属于爆发式的弹性需求，也是一种并行的批量式任务，而 Serverless 可以处理得很好。还有像视频 APP 的企业用微服务架构，这样基础设施运维投入也会比较高。有的企业会选择面向应用的 Serverless 产品，比如阿里云的 Serverless 应用引擎将微服务部署到平台上，不需要做任何基础设施管理。这个是现在 Serverless 真正的价值。

网友：云原生对编程语言会有特别的要求吗？

A：不知道大家是否了解，国内后端开发最火的语言是什么？还是 Java。但如今，多语言是必然趋势。很多公司在用 Go 作为主要开发语言，PHP 的使用也非常广泛。每种语言的特点不太一样，很多企业会根据业务需要选择一种合适的语言。这时可能会出现多种语言，业务部门觉得用 Go 比较好，偏前端的想要 PHP 或者 Node.js，多语言在企业内部越来越普遍。

开发人员想用什么语言就用什么语言，但是运维人员就会面临很大的挑战，如多语言环境下的服务治理怎么能统一做等。目前，云原生领域推出了像 Service  Mesh 这样的技术去做多语言的服务治理。就整个生态来讲，目前最成熟的后端语言还是 Java，招聘 Java 人才也比较容易，而 Go 也有非常好的增长趋势。未来，企业对于多语言的容忍程度会越来越高。

Java 之前在阿里基本处于统治地位，但现在阿里内部也多语言了。阿里收购了非常多的企业，如饿了么、飞猪、高德等，但不可能让所有并购进来的公司都改变编程语言，这是很难的。由于公司并购，阿里内的编程语言已经变得多元化了。企业足够大的话，就一定是多语言的。如果是初创公司或者体量还不够大，语言统一确实能带来便捷。

Q：网友问到说云原生很火，可能不用云原生显得不高级，比如 Mesh。您怎么看待网友的这个疑问？

A：云原生领域的火是市场和业务驱动带来的。技术发展的丰富度也会带来选型难的问题，即有选错路线的风险，这是真实存在的。今天云原生技术很火，刚才也提到 CNCF 有上千个项目，用户该用哪个？这确实是每个企业都会考虑的问题。在我看来，要选适合自己，但前提是有相应的技术场景支撑。至于该不该选 Mesh，这最终取决于企业的业务诉求。

比如偏稳健的团队要很稳地去落地而且支持单语言，这时选择比较成熟的 SpringCloud 和 Dubbo 是比较好的选择。但如果团队是面向多语言或面向未来去选架构，有些企业就会选 Mesh。Mesh 经过几年的演进，开源社区的相对成熟，像 Istio 基本上已经成为事实标准，很多企业已经用这些技术生产，并不太需要去担心 Mesh 是不是泡沫，它的泡沫阶段已经过去了，已经到了可以实打实进行生产的阶段了。

Q：服务网格的目标是成为云原生的网络基础设施。您觉得这个目标进行到哪一步了？下一步的研发和应用重点分别是什么？

A：刚才回答网友的问题也大概讲到了我的一个观点，就是服务网格技术逐渐成熟，Envoy 和 Istio 也是越来越普遍。CNCF 之前调研服务网格的使用率已经 27%了，这已经很好了。头部互联网公司现在已经在用 Istio，或者在社区上做自研。蚂蚁在前几年宣布整个核心业务 Mesh 化，阿里巴巴集团面临多语言治理问题也在 Mesh 化。如果需求匹配也有技术储备，是可以尝试使用 Mesh 的。

不过，现在技术应用到生产中，社区技术版本还需要面对一些挑战，比如存量系统的逐步过渡。Istio 整套体系和 K8S 生态关联很紧密，但是很多企业的虚拟机可能还没有完全过渡到容器，存在部分虚拟机，那怎么能让服务网络支持虚拟机？有些企业可能是多种微服务框架混存的，有的已经使用 SpringCloud 了，那么 Mesh 能不能和 SpringCloud 进行打通？社区在这方面的方案还不是特别全面。另外，Service Mesh 要上生产，非常重要一点就是可观测性。完全自建的企业就会面临这样的技术挑战。

企业要真正自己去构建 Mesh 体系，需要有技术储备和相关人才。另外，企业也可以借助云厂商的力量。目前的几个云厂商都有 Mesh 方面的云产品，比如阿里云就有提供 Service Mesh 托管等服务。企业可以先根据自己的业务维度判断技术团队的能力，再决定是完全自建还是借助云厂商的能力。

Q：有网友问到，阿里都有哪些可观测性方面的技术组件？

A：可观测性也是云原生非常重要的一个领域，是企业上生产的必备搭档。

目前，可观测性方面有两个比较大的趋势。第一个大的趋势就是全栈的可观测性。业务中常常面临的挑战是用户上报了一个问题，企业如何快速用可观测性的方式在整个链路判断出是哪里的问题。现在，架构越来越复杂，企业可能要从用户侧开始，比如从前端到应用层、再到基础设施层等等，需要的是整套链路的诊断能力。所以可观测性的一个重要的趋势就是打通整条链路。

另外一个非常重要的趋势就是指标体系的打通。可观测性领域有 Metric、tracing 和 Loggin 三大数据，这三大数据以前有点各做各的，但今天的用户对将三大数据打通做统一监控有非常大的诉求。比如当一个问题出现的时候，可能是 Metric 发现了指标有异常，这时开发人员可能希望看下 Metric 异常对应的交易的日志，看到日志之后可能想看这个交易对应的整条链路的情况。在可观测性场景下，大家对统一监控数据的需求越来越强烈。刚才听众问到阿里在这块正在做什么，其实就是围绕上面说到的两点提供全面的托管服务，比如 Prometheus，Grafana 的托管产品。

Q：社区也有人问到，开发测试人员对容器技术不熟练的话，企业如何探索云原生？

A：我觉得整个上云的过程是要根据企业的情况和模式来做。业界有一个普遍的说法就是会把上云分成几个阶段。首先，最简单的办法就是 Rehosting，即把原来的线下机房搬到云上来。原来线下是虚拟机，到云上也是虚拟机，这给企业带来的往往是财务上的变化，原来拥有的是资产，现在变成了云上服务。这对企业来说就是平移，整体价值稍微低一点，但成本也是最低的，基本上不需要对业务进行改造，运维模式也不需要变化。所有企业都可以做。

第二步是 Replatform。这与云原生一些理念就有关联了，比如将原来的虚拟机变成容器化模式。Replatform 的一个典型特点就是，企业不需要对应用进行改造，只需要对系统运维模式进行改变。很多时候对应用进行改造的代价和成本是比较高的。容器化一般并不需要对企业的应用进行该案。另外就是考虑从自己建设的开源工具变成使用云厂商的产品，比如原来自建 MySQL，变成云厂商的 RDS 等。企业可以真正看到云原生带来的降本增效成果。

从团队建设角度来说，还是需要有懂 K8S 的人。K8S 的学习资料还是非常多的，InfoQ、CNCF 官网、开源社区的官网，还有阿里云都有大量的资料可以让用户使用。

最后一个阶段也是很多企业在做的，就是 Refactor，即重构，企业整个应用架构往往发生一些变化，包括 Serverless 化，微服务化等。这个阶段会涉及应用改造，但也才是真正能够让应用侧发挥云优势的时候。企业可以结合自己的特点，选择逐步的云原生化。

另外，企业还要看自己的业务类型。现在有一个叫“双态 IT”的理念，就是讲稳态和敏态。稳态是企业内部变化不是很大的业务，对于这类业务，我们建议只需要做 Replatform 就可以，因为它的迭代速度没有那么快，业务改动也不是很大，但需要通过容器化等模式增强它的稳定性和弹性等。而敏态业务还有快速的迭代，这时可能会建议做 Refactor，如微服务化等，这样可以提升整个研发效率。

企业要根据自己的业务类型和技术储备等，综合考虑自己云原生化的方式。

Q：云原生体系越来越大，开发人员要学习的东西也越来越多，您有什么学习建议给到大家吗？

A：确实要学的东西很多，而且更新迭代非常地快，我是建议大家换个角度学习。自学当然没有问题，网上有各种各样的资料。但有一点，大家在做云原生能力落地的时候一定要从业务驱动的视角去做。

我看到有些企业是为了技术而去做云原生，这样最后不一定有好的结果，更多时候还是先从业务价值角度出发考虑要做什么事情，再选择相应的技术。一方面，企业有业务驱动，便会有足够多的资源投入。另一方面，企业在做技术选型和落地的时候会有足够多的实践。

从领域来讲，我给大家的建议就是先把基础打好，之后再完善一些生产必备的技能。容器技术是所有的基石，在这之后是一些比较关键的像可观测性、CICD、微服务等企业内部落地真正需要的一些关键技术。