上一篇文章介绍了 CloudFlare 开源的网络框架 Pingora, 此篇文章我们使用该框架从零到一实作一个应用网关. 目前大规模应用的网关主要分为三大类, 一类是以传统 C 语言开发的 Nginx 为基础并通过 Lua 进行扩展的网关, 诸如 OpenResty, Kong 等便是如此; 一类则在诞生之初便完全为云原生提供解决方案的代理, 诸如 Envoy, Linkerd2 和 Cilium (严格说来 Cilium 划分在网关代理类并不合适); 最后一类便是和应用深度绑定的应用网关, 如 Spring Cloud Gateway. 从今天的视角看 Spring Cloud 微服务的模式与云原生存在较大的竞合, 同时 微服务, 注册中心 等概念被 Kubernetes 的不同 Service 通过类 DNS 模式一一种优雅的方式解决, 这也导致了 Spring Cloud Gateway 模块在 Kubernetes 集群内尴尬的境地. 开发中经常面对一种场景是微服务部署到 Kubernetes 内本地无法调试的问题和多应用集群内应用间相互调用的问题. 我们这里通过 Pingora 构建的应用网关主要便是为解决此特定场景下请求转发与应用鉴权的工作, 同时在此基础上可做进一步扩展. 首先声明一个 Gateway 结构体作为网关的主体, 后续有需要时可通过扩展该结构体以绑定资源, 实现一些高级功能. #[derive(Debug, Default)] pub struct Gateway { } 在定义完 Gateway 后, 考虑到 TCP 连接特性我们再定义一个 Host 元组结构体以反映不同服务对应的 IP 和 Port:

CloudFlare 在 2022 年中时曾发布过一篇博文 How we built Pingora, the proxy that connects Cloudflare to the Internet 介绍了其为了解决 Nginx 在实际应用场景下的诸多困境从头设计并使用 Rust 开发了一个名为 Pingora 的 代理, 并在文章中介绍将会开源该系统. 但后续针对 Pingora 便再无其他消息, 开源计划看起来也是遥遥无期, 个人也一直担心是否会像 Servo 一样胎死腹中. 但昨天 CloudFlare 在 Github 上开源了该系统相关代码 cloudflare/pingora, 同时也发布了一篇博文 Open sourcing Pingora: our Rust framework for building programmable network services 介绍了 Pingora 开发相关的工作. 在开发 Pingora 之初, 与所有其他公司一样 CloudFlare 也考虑过通过付费以便 Nginx 背后的公司可以为其进行定制化开发和迁移到其他诸如 Envoy 等第三方代理系统, 但经长期考虑最终还是选择自行构建一个全新的代理系统, 该系统设计目标主要是 快速, 高效 和 安全. 在不舍弃 高效 和 快速 的前提下追求尽可能 安全 的目标, CloudFlare 自然地选择了 Rust 语言开发 Pingora.