8、深入解析 Knative 服务原理及请求处理流程

深入解析 Knative 服务原理及请求处理流程

1. 无服务器系统的发展与 Knative 基础

早期的无服务器系统，如 AWS Lambda 和 Google App Engine，使用“源代码包”或“JAR”作为公共打包格式，再通过机密构建系统将其转换为内部存储格式。这种方式虽总体可行，但偶尔会出现“在本地机器上运行正常，但在云端不行”的问题。而 OCI 容器在很大程度上解决了这一问题。

部分无服务器平台试图通过自动为应用分配生成的名称来简化操作，但这又引入了将“友好名称”映射到计算机生成名称的额外步骤，因为人类更喜欢有意义的名称。

“控制平面”和“数据平面”的术语源自网络交换。在网络交换中，数据平面使用专用硬件来路由数据包，控制平面则负责对数据平面进行编程以实现正确的路由。这使得数据平面可以使用快速但简单的硬件，而控制平面使用较慢但更智能的硬件。

Knative Serving 基于许多应用可以实现为无状态的 HTTP 服务容器这一理念，实现了无服务器代码执行运行时。它借鉴了十二因素应用宣言以及 Google App Engine 和 Cloud Foundry 等平台的早期工作，这些平台主要专注于处理基于 Web 的应用。由于基于 REST 的 API 和基于 Web 的接口的普及，以及将每个 HTTP 请求视为一个工作单元的能力，无状态的基于 HTTP 的工作非常适合无服务器架构。随着 OCI 容器作为打包和执行格式的兴起和标准化（受 Docker 和 Kubernetes 的推动），容器成为在不同实现中可移植封装应用的自然选择。

应用的一些重要信息，如“使用什么名称访问应用”或“进程需要多少内存”等，通常不会包含在编译工件中，