云原生架构下应用引擎演进、特点、定位及部署是什么？

1. 云原生技术架构下应用引擎的演进

云原生应用引擎从传统互联网架构发展到云原生架构，其支撑的软硬件类型由操作系统、数据库、应用中 间件和 Web 服务器逐步发展为基于云原生内核、分区解耦的数据库及相关衍生产品，例如，API 网关、入 / 出 口网关、边车、微隔离、消息代理、应用代理等。云原生架构的应用引擎实现虽然需要借助容器、DevOps、 微服务等新兴云原生技术，但我国在云原生应用引擎技术领域已经积累了深厚的研究基础。

据 Gartner1 预测，到 2025 年，云原生平台将成为超过 95% 的新数字计划的基础，远高于 2021 年的不到 40%。以上预测说明，中国云原生产业将迎来蓬勃发展，基于云原生应用引擎在云原生技术的突出位置，应用 引擎将成为信息产业发展的主力军和排头兵。

2. 云原生应用引擎的特点

作为云原生环境部署里的基础组件，云原生应用引擎具有如下特征：

(1) 无状态能力： 云原生应用引擎有多种形态，如应用服务器、应用代理，但无论哪种都需适应云原生环境的多变的动态部 署要求，包括扩展、迁移 , 特别是适配云原生的容器化部署。因此，一定不能在节点存储状态数据，需要把状 态数据及时同步到控制管理平面。以 NGINX 为例，其集群同步能力可以在不同实例间同步配置，产生的日志 可以不落盘，而直接对接管控平面的日志服务组件。

(2) 可观测能力： 传统应用的网络和硬件规划是静态的，而云原生环境下的规划部署是动态的，并且请求的拓扑每次都可能 不同。因此，云原生应用引擎需要支持 Opentracing 等可观测架构，按要求及时上报请求的跟踪信息。NGINX 早在数年前就支持 Opentracing，可以对接 Zipkin、Jaeger server，实现统一的调用链观测。

(3) 动态配置能力 ：云原生环境下由于业务服务变动频繁，需要应用网关或代理即时变更配置，同时云原生环境下的微隔离也 要求控制面及时下发控制策略。因此，云原生应用引擎，尤其是代理服务器必须具备动态配置能力，才不会因 为不及时的配置变更影响业务。

(4) DevOps 集成能力： 云原生的应用架构有快速迭代、多版本并存、蓝绿部署以及热更新的特点。因此，需要应用引擎提供接口 支持版本热更新、流量切换、灰度测试等能力。例如，NGINX 支持热更新，可以根据复杂协议特有的变量进行 不同的路由选择。

3. 云原生架构下应用引擎的定位

应用引擎在微服务体系中发挥着重要的作用。一是作为应用服务器，能够适应企业现有的实现语言，提 供相应的服务器实现，从而保证企业能以较低的成本完成业务的云化改造。例如，NGINX 通过两种模式实现 通用服务器支持，通过动态模块机制、加载不同语言的模块，目前已经有对应的 C / Go / Java 或解释型语言 如 PHP / Python / LUA ；或者把不同的语言首先翻译为 WASM 方言，再通过 WASM 模块执行。二是作为流量 或 API 网关，应用引擎仅仅是代理或施加策略控制，有时还可以弥补服务实现的缺陷，比如下面章节中代理 MQTT 消息协议时对其缺乏 HA 能力的弥补。

而在服务网格架构中，应用引擎除了上述的作用外，还以边车的形态和控制面组件进行交互，为服务增强 了可观测性、安全、流量控制。例如，NGINX 本身的融断机制、丰富的路由策略满足边车的流量调度需要，而 微隔离的需求则通过丰富的第三方安全插件支持，原生的丰富的 upstream 指标体系则满足了可观测性需求。

4. 云原生架构下应用引擎的部署

应用引擎的部署包含数据平面、控制平面、管理平面。数据平面实现业务的数据处理，控制 平面实现对业务策略的配置，管理平面实现对引擎的管理。基于管理平面、控制平面与数据平面的协同交互， 云原生应用引擎在数据平面实现了安全、高效部署，基于 API 网关和入口网关（Ingress）传入的数据，服务 节点借助边车功能实现了一系列的微服务，并将服务结果输出到相关用户。基于边车技术，应用引擎实现了数 据平面与控制平面和管理平面的功能解耦，底层实现对软硬件资源的自动化管理和控制，其技术更新对上层服 务逻辑的影响较小，上层用户不必对底层服务进行重复设计和主动干涉，从而带来效率和安全性的提高。

应用引擎在云原生环境中实现了以下部署：

(1) 消息队列 ：消息队列是构建低延迟、高并发、高可用、高可靠的分布式消息中间件。 云原生环境中部署消息队列，将消息队列作为服务运行，允许在不进行配置服务器的情况下创建应用程序 处理扩展管理，由云提供商抽象和处理，以微服务为中心，消息队列松耦合，可以更新特定功能而不会导致应 用程序停机。

(2) 入口 / 出口网关（Ingress/Egress）: 云原生架构下应用引擎的部署可以在整个系统的入口和出口处部署代理，使得所有流入和流出的流量都由 代理进行转发，而这两个负责入口和出口的代理就叫入口网关和出口网关。它们相当于整个微服务应用的边界 代理，把守着进入和流出服务网格的流量。

(3) API 网关 ：API 网关是一个云原生、高性能、可扩展的微服务网关，基于 OpenResty 结合 etcd 来实现，API 网关具 备动态路由和插件热加载的特性，适合微服务下的 API 管理。 API 网关实现了客户端和服务端调用关系和部署环境的解耦，它向客户端隐藏了应用划分的微服务的部署 版本。API 网关可以根据负载策略进行请求流量调节，客户端可以灵活地选择在不同场景使用不同版本的后端 服务。 API 网关是所有业务流量的入口，可以处理传统的南北向流量客户端服务器通信，也可以处理服务间的东 西向流量，也可以当作 K8s 入口网关来使用。

(4) 边车: 边车是分布式和微服务架构的设计模式，实现了控制和逻辑的分离与解耦。通过给应用服务加装一个边车 达到控制和逻辑分离的目的，通过给应用程序加上一个边车的方式扩展应用程序现有的功能，如日志记录、监 控、流量控制、服务限流等。业务服务只需要专注于实现业务逻辑即可。

(5) Serverless 应用引擎： Serverless 应用引擎是面向应用的 Serverless PaaS 平台，帮助 PaaS 层用户免运维 IaaS，按需使用，按 量计费，实现低门槛微服务应用上云，有效解决成本及效率问题。 Serverless 应用引擎支持 WAR / JAR / 压缩包自动构建成 Docker 镜像能力，让零容器基础的客户沿用原 有部署方式使用 Serverless 应用引擎。