作者 | 褚杏娟
本文是 “2022 InfoQ 年度技术盘点与展望” 系列文章之一，由 InfoQ 编辑部制作呈现，重点聚焦云原生领域在 2022 年的重要进展、动态，希望能帮助你准确把握 2022 年云原生领域的核心发展脉络，在行业内始终保持足够的技术敏锐度knative系列。
“InfoQ 年度技术盘点与展望”是 InfoQ 全年最重要的内容选题之一，将涵盖操作系统、数据库、AI、大数据、云原生、架构、大前端、编程语言、开源安全、数字化十大方向，后续将聚合延展成专题、迷你书、直播周、合集页面，在 InfoQ 媒体矩阵陆续放出，欢迎大家持续关注knative系列。
特此感谢丁宇（叔同）、董晓聪、裴超、冯常健、柯琪、吕亚霖、王泽锋、于广游（按姓名首字母排序）对本文的贡献，他们的真知灼见，是本文能与大家见面的关键knative系列。
数据显示，云原生计算基金会（CNCF ）拥有超过 850 家参与组织，相较去年增长 15%，其中今年新增的 220 多个成员中，有 19 个来自中国knative系列。
去年的盘点中，我们用了“抢占技术 C 位，迎来落地大爆发”的标题来总结云原生整体的发展势头knative系列。今年，云原生的发展依然可圈可点，比如开源容器编排平台采用率激增、各种行业加入到了云原生大家庭等。这次，我们将从底层基础技术和偏向场景化的应用技术两方面，对云原生今年的发展情况进行盘点，以期自顶向下地呈现出相关亮点和挑战：
容器的“黑盒”打开knative系列，混部带来了效率提升，备受企业欢迎；
Serverless 基于容器完成标准化knative系列，应用“元年”开启；
Service Mesh 进行新尝试knative系列，落地方式还在探索；
降本增效大主题下knative系列，FinOps 理念得到快速发展；
越来越多的传统行业开始应用云原生技术等knative系列。
基础技术篇
从物理机到虚拟机再到云原生，底层基础技术对上层应用赋能的边界在不断提升，业务研发越来越从底层事物中抽离，聚焦于本身的业务逻辑knative系列。
容器的“黑盒”已经打开
7 月，Kubernetes 发布了 Gateway API 0.5 版本，主要组件的 Gateway API 资源首次升级为 Beta 版knative系列。同时社区还探索如何将 Gateway API 用于网格并引入新的实验概念。这也促成了 Envoy Gateway 项目的推出。
12 月， Kubernetes 原生工具集合项目 Argo 正式从 CNCF 毕业knative系列。
容器发展至今，已经完成了自身的蜕变knative系列。
在第一阶段，容器只是在解决如何做好自己内部技术组合的问题，比如怎么与服务网格、可观测性的产品结合knative系列。这期间，企业只是选一部分比较周边的业务使用容器，而容器化业务内部系统就像一个“黑盒子”，各细分组件通过 ELB 调用实现交互，容器并不能直接与每一个部分做精细互通，致使容器化业务系统跟周边业务系统的交互效果很不理想。
到了第二阶段，“黑盒子”打开，容器开始深入到整个云原生体系中，真正作为云最核心的部分，与网络、存储、数据库等做很好的结合，比如容器化业务应用可以直接与其他所有云服务通信等knative系列。
作为云原生的典型代表，如今容器技术的成熟度是最高的，同时这也意味着容器技术自身很难再有非常大的突破和变化knative系列。Kubernetes 成为行业事实标准，如今定位也类似 Linux 内核，虽然没有大的功能性迭代，但已经成为云原生领域最基本的设施，也成为企业 IT 系统的基本设施。
今年，容器的演化进入了“扫尾阶段”，开始解决原来不好做或不能做的场景应用问题knative系列。Kubernetes 这一年稳定更新的三个版本，更多是在 API 怎么更加健壮、流控怎么更好更安全、改进 Windows 支持等细节上做优化。
另外，内核提升可以为容器带来更好的隔离和性能等，因此随着容器的广泛应用，其对内核的要求也越来越高knative系列。大厂们开始往更高内核版本 5.10 上迁，Kubernetes 社区也在落地内核方面的内容，给企业带来的直接影响就是观测性上有了很大的进步，性能和隔离性的提高也很明显。
展开全文
应用上，虽然容器正在大规模铺开，但如何用好容器也很有挑战，比如 Kubernetes 在调度、场景优化、降低复杂性等方面还有很大的进步空间knative系列。
微软全球副总裁柯琪表示，随着容器的广泛应用，企业部署了很多 Kubernetes 集群，如何对其管理是企业面临的问题之一knative系列。鉴于这部分与多云有部分重合，我们留到多云部分再表。
混部
今年，容器混部取得了较大的进展，不过这个进展并不是体现在技术上knative系列。之前混部主要是各大头部企业内部使用，对于技术细节有些“秘而不宣”的意味，但今年云厂商开始把混部技术开源或者变成云产品提供给用户。
混部就是要把各种不同的业务放在一起后对它们进行复用knative系列。听着简单，但混部有着较高的技术门槛，主要体现在调度、隔离和干扰处理上。
具体地，Linux 操作系统内核的隔离性做得不好，但 Linux 内核面向通用场景，如果要解决隔离问题就要对内核做非常深度的改造，但国内大部分企业并没有独立的内核团队，况且这样的人才也是凤毛麟角knative系列。当然，不做内核隔离只做调度混部也可以，但对资源利用率的提高就很有限。
另外，合理的调度需要有全面的应用画像，这需要大量的数据和业务去打磨算法，这在实现上也非常困难knative系列。调度实际上是一个系统性工程，并没有标准化方案，企业可以自行摸索初级方案，但更深入的可能就要使用市面上的产品。
其实，企业目的不是混部，而是为了提高资源利用率、降低成本knative系列。降低成本有两种方式：一是企业已经买好资源，内部不同业务复用这些资源，这条路线的代表就是混部；二是企业直接使用云厂商提供的成本很低的产品，这条路线的代表是 Serverless，也是大家比较好看的方向。
可以预见，下一年，Kubernetes 的演化依旧以解决场景化的细节问题为主knative系列。腾讯云容器技术总监、TKE 产品负责人于广游总结道，整体上，容器未来将呈现出以下趋势：
第一，往更高层的抽象演进knative系列。最早用容器的时候，大家关心的是容器中的资源、pod、container，但是业务并不关心这些，他们真正在意的是应用。因此，容器平台向应用平台演进会是一个趋势。
第二，不断拓应用宽度knative系列。Kubernetes 的应用已经延伸到了混合云、边缘云，在对中心、边缘、IDC 的资源进行统一调度等方面，还有技术挑战。
第三，多样化应用knative系列。企业会逐渐通过采用容器技术重塑自己的业务和全部技术栈，比如监控、日志、中间件、数据库、运维等。容器带来了好处，但它跟企业之前的技术会产生割裂，这时更多的企业会选择将所有工作负载运行到容器上，容器化间接成为企业重塑技术栈的动力。
结果就是，企业业务容器化后，还会把有状态应用、AI 业务、大数据业务、转码业务、离线业务等都容器化knative系列。所以现在的容器不仅仅与微服务挂钩，还在朝大数据、AI 等方向发展，这个趋势是非常明显的。
第四，更下沉的方向knative系列。对于平台自身而言，如何更稳定、成本更低？还有更多的细节亟待完善。
Serverless：与容器技术体系相通
3 月，开源 Serverless 应用框架 Knative 成为 CNCF 孵化项目knative系列。谷歌此前曾明确 Knative 不捐给任何基金会，但去年底宣布捐赠到今年 Knative 正式成为 CNCF 孵化项目，极大促进了社区的发展。
5 月，开源 FaaS 项目 OpenFunction 成为 CNCF 的沙箱项目knative系列。
9 月，Serverless Devs 进入 CNCF 沙箱，这也是 CNCF 首个 Serverless 工具项目knative系列。
当前用户对云服务的使用主要有两种方式knative系列。一种是把云服务作为资源使用，比如云服务器、容器等，它们不会影响用户应用的开发方式，这类就是容器化 Serverless；另一种是把云服务作为应用构建的模块，例如对象存储，消息队列等服务，用户在应用开发过程中使用这些云服务，但它们会影响用户构建应用的方式，这就是应用层 Serverless。
传统意义上的 Serverless，也被称为 FaaS，即函数形态的 Serverlessknative系列。2014 年，亚马逊推出了 Amazon Lambda，其将 FaaS 理念延伸到数据库、中间件等产品，让各种应用场景下的用户都不用关心资源和集群，而是直接使用 API，这是业内公认最早的 Serverless 服务。
FaaS 的核心价值在于让整个云产品体系及生态形成一个有机整体，而不是只用来提供弹性资源knative系列。阿里巴巴研究员、阿里云智能云原生应用平台总经理丁宇（叔同）指出，用户可以利用 FaaS 组合其他 Serverless 云服务（BaaS）快速构建应用，这种组装式的研发模式将对研发效率带来革命性变化，是云解决大规模复杂软件研发挑战的关键。
另一方面，由于单纯的 FaaS Serverless 是基于函数的，其开发模式、技术体系、产品形态与容器并不相同，不能为用户提供“原汁原味”的 Kubernetes APIknative系列。该方式下，用户用提交的一个代码片断进行托管，各厂商自成体系，业内没有统一的标准，短期内也很难看到有事实标准诞生。因此在于广游看来，容器的大规模流行反而暂时抑制了 FaaS Serverless 的发展，因此落地也相对缓慢。
目前，业内对于 FaaS Serverless 的发展还存在不同的看法和方向，现在也没有孰优孰劣的定论knative系列。
作为应用层面的 Serverless，以 FaaS 为核心的 Serverless 体系更加强调 Serverless BaaS 的丰富度和 BaaS 之间的深度集成，用户上手快，但需要花费时间和精力去打磨整个云产品体系knative系列。但 FaaS Serverless 的核心价值依然是被肯定的，像亚马逊云科技和阿里云还在继续这方面的深研，用更被接受的方式发挥其价值。
不过当前的实际生产中，不要求用户改变研发方式的容器化 Serverless 获得了更多的青睐，很多企业多少都了有一定的应用knative系列。
实际上，亚马逊云科技首先提出 FaaS Serverless 后，其他云厂商纷纷跟进knative系列。但单纯的 FaaS Serverless 由于对云产品要求高等原因，在国内的接受度不如海外。这种情况下，业内也开始探索其他方式。
之前，大家把 Serverless 作为一种具体的实现，而现在将其视为一种理念和价值，并尝试为这种理念和价值找到更合理的实现方式，容器化 Serverless 就是这种转变下的解决方案之一knative系列。
容器化 Serverless 发展的目标是为了兼容原本容器的技术体系、降低企业迁移的成本knative系列。容器化 Serverless 将 Serverless 与容器结合，Serverless 技术兼容容器的 API，两个技术体系打通后也意味着容器化 Serverless 是标准的。因此，各云厂商的产品标准在趋于一致，能力也在逐步完善。在这个前提下，企业服务的迁移会更容易。
当然，容器化 Serverless 不同厂商之间的产品策略也有差异knative系列。比如，微软的 Container Apps 支持 Dapr 分布式应用环境，运行在基于 AKS 的隐藏的抽象 Kubernetes 集群之上，甚至不向用户公开 Kubernetes API，阿里云则走在提供 Serverless 容器服务 ASK 的道路上。
现状及趋势
Serverless 的应用如今实现了“从点到面”的转变knative系列。
现在，Serverless 的稳定性和效率已经被逐渐接受，一些企业之前只是在周边的个别业务上牛刀小试，现在开始将部分核心业务放到 Serverless 上knative系列。比如阿里云完成核心云产品全面 Serverless 化，作业帮将某部分核心业务放到 Serverless 后成本节省了 20%-30%，高德业务投放平台全面采用基于函数计算构建的 Serverless 架构来支撑百万 QPS 等。
今年，很多云厂商在各自大会上都提到了 Serverless 的重要性，比如阿里云栖、亚马逊 re:Invent、腾讯数字生态大会等，但热闹的背后反而说明了 Serverless 还处于发展初期，需要推新和推广knative系列。这一年，国内 Serverless 被认为是发展元年，虽然还称不上是大规模落地，但业内在 Serverless 成为云原生未来重点方向这一点上几乎没有太多分歧。
Serverless 适用于流量波动大和需要更敏捷、更灵活开发的场景knative系列。现在 Serverless 架构可以解决微服务架构无法带来足够灵活度的问题，帮助企业快速适应业务变化。
Serverless 为能力不同的开发者抹平了技术鸿沟knative系列。如果将应用分为应用运行时（即计算部分）和 BaaS 化服务两部分，那么 Serverless 化后的架构会变得更简单。对于 BaaS 服务，可以进行全面托管并免运维 API 化，开发不需要关心资源等问题；对于定制代码部分则可以把 BaaS 的 API 组装起来，让应用开发更快建出新能力，同时不需要关心容量问题。
成本方面，对于企业为波峰预置服务器产生浪费的费用、业务需要扩容时购买机器花费的成本和精力、机器维护成本等，Serverless 都可以将这些交给程序运行，按需使用资源、动态伸缩，为企业带来降本增效的效果knative系列。
Serverless 的快速发展也会对运维领域产生一次颠覆性升级，工程师将精力更多放在开发降本等平台上，而不再关注底层的扩容、采购、网络等问题knative系列。
预计下一年，会有更多产品具备 Serverless 能力，Serverless 会变得更加普适knative系列。另外，Serverless 产品的更多细节也会进一步完善，比如如何提高产品弹性、如何进一步降低成本（如从之前的包年包月到按 CPU 利用率的计费模式）、功能如何更加丰富等。
应用上，以上两种方式虽是业内对 Serverless 应用的不同探索方向，但都各具优势和不足knative系列。业内现在有将 FaaS Serverless 和容器化 Serverless 结合起来提供解决方案的尝试：容器化 Serverles 解决资源层面的问题，应用层面的问题让 FaaS + Serverless Baas 解决。用户将不同 Serverless 化产品通过事件驱动等方式深度集成后，通过 FaaS 组合其他云服务来快速实现弹性、高可用。
当然，Serverless 虽被认为是大势，甚至被视为云未来发展最重要的价值，但从趋势到产品、到行业普遍应用，再到真正大规模落地，还需要业内的长期投入和推动knative系列。
Service Mesh：还有挑战需要解决
4 月，谷歌声明将 Istio 捐赠给 CNCF，9 月份 Istio 正式成为 CNCF 孵化项目knative系列。这一事件使 CNCF 社区的确定性更强，也消除了前些年大家对社区治理、法规等方面的顾虑。
5 月，Envoy Gateway 项目宣布开源knative系列。该项目旨在大幅降低将 Envoy 作为 API 网关的使用门槛。
9 月，Istio 宣布引入了一种新的数据平面模式 Ambient Mesh，该模式取消了以 sidecar 为中心的架构，取而代之的是无 sidecar 的方法，同时保留了 Istio 的零信任安全、遥测和流量管理的核心功能knative系列。
很多企业都是多协议、多语言栈的，他们选择使用 Service Mesh 来解决复杂的服务治理问题knative系列。Service Mesh 理念本质上是把一些非功能性的基础设施拆解到中间件中，即 sidecar。
在之前的一些实践取得正反馈后，Service Mesh 使用范围也在扩大knative系列。今年的 Service Mesh 不再局限于 RPC，开始向对象存储、加解密、MySQL、Redis 等领域深入。
但总体看，这一年，Service Mesh 落地还是遇到了大的技术挑战，远没有达到企业理想的使用状态knative系列。有一定研发能力的企业使用传统治理模式也可以做得不错，这时就不会选择完全换成 Mesh 架构，只会在一些新的、没有历史负担的业务上试用。
归根到底，Service Mesh 只是转移了复杂度，但到了一定规模后复杂度问题就会再次显现knative系列。拿当前业内应用较多的 sidecar 模式来说，它很适用于逻辑复杂的场景，如路由、治理，灵活且对业务无入侵。但是，流量劫持和对流量进行逻辑处理需要很强的扩展能力，在规模特别大的场景下，sidecar 模式的复杂度就上来了，性能优势不再明显，资源占用也变得不可忽略。可以说，sidecar 模式天生在大规模场景应用中就有一定的局限性。
为解决这个问题，今年九月，Istio 推出了 Sidecarless 的 Ambient Meshknative系列。Ambient 是将 Istio 分成两个不同的层次：安全覆盖层（四层治理）和 七层处理层（七层治理）。但在网易数帆云原生平台负责人冯常健看来，四层治理模式将复杂度降到了 Node 级别，但可能只有对网格安全能力感兴趣的企业会尝试，而七层治理模式本质上还是独立的应用层代理，链路也并未减少。因此，对于该模式的应用，业内更多还是持观望态度。
网关层面，社区基本分为 NGINX 和 Envoy 两派：Kong 、APISIX 等基于 NGINX，网易、阿里云等更多应用 Envoy 技术栈knative系列。有人认为 NGINX 及其生态已经比较成熟了，但随着 Kubernetes Gateway API 的成熟，以及社区推出 Envoy Gateway 组件，新一轮网关标准定义的争论再次掀起。
Kubernetes Gateway API 对标的是 Ingress APIknative系列。Ingress 的 API 解决流量从集群外导入集群内的问题，但表达能力较弱，使用场景有限，因此社区推出了 Kubernetes Gateway API，希望其提供更高级的网络能力。
Kubernetes Gateway API 直接促进了 Envoy Gateway 项目的发展knative系列。Envoy Gateway 进而统一了网关的控制面 API。原先网关控制面是通过 xDS 控制数据面，现在更多会基于 Kubernetes Gateway API。
实际上，现在各个企业都在从不同的方向尝试对 Service Mesh 进行完善和补充，如网易向 Envoy 社区贡献 Dubbo 核心支持能力来促进落地knative系列。虽然社区有了各种开源产品，但业内还没有形成像 Kubernetes 这样的事实标准。当有这样的一个事实标准出来后，Service Mesh 才会迎来自己的爆发。这与容器的发展轨迹是类似的。
Service Mesh 也在寻找更适合的落地方式knative系列。现在，业内有尝试不再将 Service Mesh 作为一个独立的产品，而是将其与 Serverless 结合。Serverless 不让用户去关心服务器，Service Mesh 不让用户关心服务治理，如果将服务治理的 Service Mesh 容器内置到 Serverless 平台里面，企业提交一个业务的容器进项后也会拥有 Serverless 的能力。
硬件与云knative系列，互相影响
6 月，阿里云发布云数据中心专用处理器 CIPU，形成“倚天 + 飞天 +CIPU”组合knative系列。
11 月，亚马逊发布 Nitro v5 、Graviton 3E 系列芯片knative系列。
12 月，腾讯云发布了新代次的裸金属云服务器、GPU 云服务器，此外还发布了银杉智能网卡等knative系列。
同月有消息称，微软以 1.9 亿美元（约 13.2 亿人民币）的价格收购了加州 DPU 初创公司 Fungibleknative系列。
从整个计算机发展历史看，软硬件迭代呈现出了交替螺旋的方式，即某个新技术出来后，都先用软件测试可行再进行小规模应用，当发展规模大到一定程度时，人们便开始考虑用硬件方式加速实现，云原生也不例外knative系列。
如今，云已经取代传统 IDC 服务器成为新的基础设施，企业开始通过硬件进一步提高效能knative系列。企业选择云原生硬件的考量主要有两点：成本和不同应用上的性能表现。
成本方面，虽然硬件开发的一次性投入相对较大，灵活性相较软件也差很多，但只要需求固化下来并开发成功后，企业采购的边际成本是非常低的knative系列。
性能方面knative系列，硬件对云的性能提升包括可靠性、稳定性、安全性等方面：
热操作能力knative系列。与传统业务不同，云是不能停机的，热操作能力，包括热升级、热迁移、热插拔等都是云提出的特殊要求，而传统硬件并不具备这些能力。现在，云计算领域里的自研硬件会在设计要求有热升级等功能，像 DPU 里任何一个组件都有热升级能力。
租户隔离knative系列。云的特性之一是弹性共享，一个物理机上可能会有很多用户在运行虚拟机，怎么加强用户之间的隔离、避免互相影响，也是云对硬件提出的新要求。
安全性knative系列。云上很多用户运行在一台物理机、一个网络里，如果某个用户恶意利用一些漏洞获取到其他用户的数据或者逃逸到云的平台层，那么会产生非常严重的后果。因此，云对硬件的安全性要求也非常高。传统 IDC 对带内、带外并没有做非常强的隔离，但在云上就不允许互通，这也是调整改造的方向之一。
当前云原生领域的硬件设备可以分为通用型和专用型两类，前者如 CPU，后者有 GPU、DPUknative系列。DPU 是专门为云而生的。传统情况下，服务器的 IO 更多是通过网卡、硬盘等硬件直接实现。但在云原生领域，网卡、硬盘等都是虚拟的，用户把东西发到网络或写在硬盘的动作实际上是先交给了云平台侧的软件进行加工处理后再发到网络或写入硬盘。
腾讯云高性能网络产品中心总监裴超表示，云和硬件也在彼此影响着向前发展knative系列。一方面，随着云原生应用的需求不断提高，硬件设备为了满足这些需求也在快速迭代。比如虚拟机网卡从 20G、50G，甚至迈向 100G，云原生对硬件的蓬勃发展起到了一定的刺激作用。另一方面，很多云原生软件产品的设计之初，就会有硬件专家参与进来，一起考虑未来用硬件加速的可能性。可以预计，未来的架构师、技术负责人多少都需要对硬件有所了解，以便对总体架构进行把握。
目前，云厂商已经越来越多地参与到硬件和芯片的研发当中knative系列。相较之前，一款芯片可以用三四年，现在基本保持一年一更新的频率，迭代可以算是频繁。像英特尔、AMD 等垂直芯片厂商也在努力直接了解终端客户需求，尽快推出新的芯片。
产业落地篇
行业主题：降本增效
“降本增效”无疑是今年行业的大主题knative系列。在这个背景下，整个行业不再像之前那样去追逐前沿技术，而是回归到了云的最基本价值上。这一变化也可以从今年云厂商讲故事的角度上看出来。往年，云厂商会争相发布各种技术，努力往技术前沿方向走。但今年，云厂商追求的是“do more with less"，即如何用更少的成本帮助客户获得更多的收益。
FinOps
谈起降本增效，之前企业常常在这年做完后不知道下一年该怎么做，本质上是缺乏方向性的指导knative系列。正因如此，这也促进了今年指导云财务管理的 FinOps 理念的快速发展。
FinOps 的历史并不悠久，公有云早期传播者 Adobe 和 Intuit 在 2012 年首次描绘出了 FinOps 的雏形，直到数年后云成本问题日益严重才逐渐崭露头角，更多企业也是今年才刚刚接触knative系列。
成本管理的难点在于资源并不是独享的，而是共享knative系列。通常单个集群可以托管多个工作负载和应用，但云厂商的账单无法体现每个工作负载或应用消耗的资源。缺乏对多个团队如何利用或共享基础设施的可见性造成了成本“黑洞”。
FinOps 本质上是把财务和整个架构技术结合在一起，弄清楚各业务对云服务使用的具体账目，然后把资源利用率提上来，减少成本消耗knative系列。该理念要求企业首先要清楚自己具体拥有哪些资产、这些资产属于谁；其次是看这些资产的利用率怎么样，然后再结合相关的技术进行优化。
实践中，企业的架构团队搭建相应平台将成本可视化，并在 DevOps 里加入管控审批等流程，用流程去约束成本knative系列。另外企业还要引入一个“成本负责人”的角色，这个角色主要由业务部门承担，负责掌握每个部门申请资源的原因、能否创造足够的利润覆盖这部分成本、资源使用率低的话是否减配等，具体执行时则主要由 SRE 把控。
FinOps 相关产品之前更多是多云管理的商业化公司推出，今年云厂商也有陆续推出，如阿里云的 ACK FinOps 套件knative系列。云厂商有很多运行时数据，如闲置率、平均负载等，也可以为企业提供优化建议。但企业如果想真正控制成本，更多还是要自己去做。
现在也有一些 FinOps 开源项目，如腾讯云开源的 Crane 等，这些项目本身就是一个成本管理平台，会把涉及到的成本信息汇集起来做出趋势图等，帮助企业做决策knative系列。但业内目前没有完全的开源实施标准，也很难做出一个大统一的产品，因为这样的产品需要考虑的因素是方方面面的，现在只是每个细节和分支有产品雏形。
作业帮基础架构负责人董晓聪认为，FinOps 的理论体系会逐渐沉淀和完善，各企业的落地方式相差无几，不过使用的具体产品可能不同knative系列。事实上，FinOps 可能目前只要满足企业的特定需求就好，不是非要演化出这样的标准。
FinOps 一定程度上会倒逼企业进行整个技术架构的演进，促进企业用更好的技术、更好的生产力工具，或者是更少的服务去支撑更大的服务knative系列。一定程度上，FinOps 会成为撬动企业增长的一个杠杆。
当然，FinOps 不是万能的，因为“降本增效”也有成本knative系列。对于成本已成为不可承受之重、之前也没有进行过优化的企业，里面一定存在大量的技术浪费，这时候就需要花费人力优化，企业肯定能从中享受到优化红利。但如果一家企业处于高速发展阶段，有能力赚取非常高的利润去完全覆盖浪费的成本，那么肯定业务为王，暂时还不必在降本上花费很多精力。
如今，FinOps 还处在大家都很需要、但没有做得特别好的阶段knative系列。下一年，FinOps 的趋势会延续，甚至未来几年内都会是很多企业关注的重点，其应用的领域也不会局限在互联网。
多云
很多企业前几年就开始考虑多云架构，直到今年开始真正在生产落实knative系列。这背后的原因也是企业对成本的考虑，还有就是对稳定性需求的提升。
实际上，国内外各大云厂商都出现过大大小小的故障，很多情况下企业要依靠多云架构去弥补这部分损失knative系列。另外，只要选择了两家云厂商，选择权就到了企业手里，企业与云厂商谈判的议价关键取决于企业在云之间迁移的能力。当然，企业如果实践不好，反而会增加成本。
总之，多云要做的就是云间的闭环和自由迁移，以及能够做得更高可用，抵销对云厂商的依赖knative系列。
在多云的初级阶段，不同云上的应用管理是手动的，业务量多的时候管理员会非常痛苦knative系列。之后，多云才有了一定的自动调度和差异化配置能力，业务不用感知资源池细节和授权等问题，这样的资源池化能力正是企业需要的。
现在社区比较流行的开源集群管理产品是 Cluster API，该产品使用 Kubernetes 风格的 API 和模式自动化集群生命周期管理，谷歌、微软等云厂商都有基于 Cluster API 的服务knative系列。华为云等多家企业联合发布并开源的 Karmada，是 CNCF 首个多云容器编排平台项目。今年，Kubernetes 多集群管理平台 OCM v0.9.0 发布，来进一步改善托管集群安全性问题。实际上，虽然每个云厂商都在自己推出产品，但很大程度上也是基于上游社区的建设。
不过，华为云云原生开源负责人、CNCF 大使王泽锋也指出，现在多云、多集群的编排调度等问题还没有特别成熟的商用级解决方案knative系列。
首先是多集群的负载管理knative系列。一些负载不能放到一个集群里，而是需要建立一个容错性更强的集群体系，这个系统通常由多个 Kubernetes 集群组成。多个集群间如何部署应用、主副关系还是平等，很多细节问题都要考虑。
其次是多集群的流量管理knative系列。单集群内的流量管理，一定程度上是通过控制面来维护各个实例的健康状态、调整流量分布。但是到了多集群架构下，由于单集群自治属性强，控制面与各个单集群之间的联系减弱，并不能简单地通过两者的联系来判定哪个集群无法处理流量、需要重分配。如何实现数据面自治的多集群流量管理，是个很大的挑战。
再者，业务部署在不同的云或集群里，业务互相访问时会有网络连通性、身份授权等问题knative系列。多云的场景是多样化的，很多用户不会接受拉昂贵的专线方式，网关方式又比较适合允许有延迟、对网络可靠性要求不高的业务场景。身份授权更为棘手，多云、多集群本就是天然屏障，如何身份授权进行全局管理就是一个很大的难点。
最后，实现多云、多集群的互访后，业务还需要有较强的适应性，能够在不同的模式下工作knative系列。
越来越多传统行业入场
除了降本增效，今年很多企业也纷纷投入到了数字化转型当中knative系列。实践中，转型企业是用互联网技术和互联网思维方式构建自己新的数字化体系。数字化中，很多企业首选云原生技术。
今年，除了有像腾讯这样业务完成全面上云的互联网企业，还有越来越多的传统企业开始上云knative系列。工业制造行业围绕业务需要主动上云，云厂商也会根据其业务需求提供配套解决方案，金融、零售、政务、能源、物流等行业也都入局云原生。
根据云原生技术实践联盟（CNBPA）调查，95% 以上的受访央国企已经考虑或正在使用云原生技术，其中近 80% 的企业已经使用容器、微服务、DevOps 等云原生技术knative系列。支持一云多芯的全栈云原生是更贴近业务的技术应用架构，更能聚焦央国企的数字化转型。
传统企业使用云原生技术更多会从 to C 业务入手，比如个税办理等面向个体消费者的 Appknative系列。当然还有像光伏行业通过“云原生 +AI”技术提升良品率类的应用。另外，传统企业在新建或升级系统时，也会优先选择更流行和最有效的技术，而云原生就在其中。
非互联网企业也积极拥抱开源，并参与云原生社区，比如波音今年加入了 CNCF 成为白金会员，中国电信、中国电子云成为 CNCF 黄金会员knative系列。
在今年 3 月，波音宣布与国外三大云计算提供商亚马逊云科技、微软和谷歌，签署了协议，扩大云运营规模并减少对本地系统的依赖knative系列。波音大部分应用都是在本地服务器上托管和维护的，很多遗留系统正在老化，需要大量维护工作，阻碍了波音开发和部署新型数字化解决方案。波音选择将大部分工作负载转移到云端的方式消除基础设施带来的限制。
像波音这样的非互联网企业进入云原生领域，是该技术更大规模落地的预兆之一knative系列。
云安全
或受去年 Log4j 漏洞事件的影响，加上 Kubernetes 安全事件频发，今年业内在安全方面的实际行动也很多，尤其是在供应链安全和模糊测试上knative系列。
供应链安全更靠近企业实践knative系列。之前，企业为了安全直接做物理隔离，但由此也带来了很多问题。当前阶段，企业做的比较多的是扫描检测部署的业务应用对应的版本，对于有问题的版本进行拦截，不允许其部署到生产环境中，初步保证业务的生产系统不暴露在漏洞之下。
另外，云原生给安全提供了一个新的抓手knative系列。之前的 DevOps 体系里融进安全的东西很难，而云原生的 DevOps 体系下，企业可以结合 CI/CD 技术，从软件的编码构建到测试、部署和运维的整个链路中，加入面向代码级的扫描能力、面向依赖的组件做版本的分析，并与漏洞库进行匹配，如果 CI/CD 部署对接到多云上，中间还会做防篡改等设计。
不过，作业帮基础架构 - 架构研发团队负责人吕亚霖表示，云原生也打破了安全原有的物理边界，这对安全领域也是场考验knative系列。
模糊测试是一种常用的应用程序安全测试，主要用来发现应用中的功能性缺陷、安全问题等knative系列。当前，大家对模糊测试的使用更偏单点技术。CNCF 中的多个项目都在使用模糊测试，如 Argo、Envoy、Fluent-bit、Kubernetes 等。这一年，Ada Logics 的团队持续努力将模糊测试集成到 Kubernetes Cluster API 项目中。
今年，国外云厂商在安全方面也做了很多事情，比如微软发布的Azure AD workload identity 预览版可以在 Pod 级别进行身份托管，还宣布实现在Kubernetes中支持AMD SEV-SNP，以此保护数据安全；亚马逊云科技扩展了 Amazon GuardDuty 安全监控服务的范围，增加了对部署容器的运行时环境的威胁检测knative系列。另外，很多创业公司也在做相关工作，比如五名前谷歌员工共同创建了专注开源供应链安全的 Chainguard。
云原生安全相关项目
但在下一年，行业是否能延续对安全的重视其实还是未知的knative系列。实际上，还有很多除漏洞外的安全问题。比如多云和边缘都会加倍放大安全问题，多云里的资源访问权限和身份授权就是很大的问题，边缘很多是离线场景但又不是绝对的物理安全。能否继续重视安全，取决于人们的意识。
写在最后
今年在互联网历史上并不是高速发展的一年，甚至全球经济下行给行业发展蒙上了一层“寒霜”knative系列。但反过来，这样的环境也促进了行业不去关注各种花样繁多的新技术，而是朝着更好、更深度的方向发展，这对云来说是一种利好。
这一年，我们看到有些企业出于各种考虑开始“下云”，有人认为正常，也有人认为这是“开倒车”，而新上云的企业也要面对走出舒适圈带来的阵痛knative系列。实际上，上了云和能用好云是两码事，还有各种规模的企业坚持在云上运行，现在大家都还远没有触碰到云效益的天花板。
总体来看，明年，云原生领域的主旋律依旧是价值回归，业内围绕着切实可行的技术去落地、深入实践降本增效，变得更加务实knative系列。不够成熟的技术会努力找到降低门槛、找到被开发者接受的方式，相对成熟的技术继续深挖，给开发者创造更大的价值。
采访嘉宾介绍（按姓名首字母排序）：
丁宇（叔同）knative系列，阿里巴巴研究员、阿里云智能云原生应用平台总经理
董晓聪knative系列，作业帮基础架构负责人
裴超knative系列，腾讯云高性能网络产品中心总监
冯常健knative系列，网易数帆云原生平台负责人
柯琪knative系列，微软全球副总裁
吕亚霖knative系列，作业帮基础架构 - 架构研发团队负责人
王泽锋knative系列， 华为云云原生开源负责人、CNCF 大使
于广游knative系列，腾讯云容器技术总监、TKE 产品负责人
如果你对本文感兴趣knative系列，欢迎在文末留言，或加入 InfoQ 写作平台话题讨论：/
同时knative系列，InfoQ 年度展望直播周将于 2023 年 1 月 3 日首场开播，并持续输出精彩内容，关注 InfoQ 视频号，与行业技术大牛连麦~
马化腾内部开炮：有些业务都活不下去了knative系列，周末还打球；阿里云香港服务器“史诗级”宕机；马斯克萌生退意 ｜ Q资讯
奇点已来knative系列，推进All on Serverless有哪些困难、如何破局？｜ 解读Serverless的2022
解读数字化的2022：不再追求大而全的“军备竞赛”knative系列，用聚焦来提高转型“成功率”
如何更好地干掉微服务架构复杂性knative系列？
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有