小鹅通基于 TSE 云原生 API 网关的落地实践

导语

2023腾讯全球数字生态大会已于9月7-8日完美落幕，40+专场活动展示了腾讯最新的前沿技术、核心产品、解决方案。

微服务与消息队列专场，我们邀请到了小鹅通的基础架构组负责人黄徐震为我们带来了《小鹅通基于 TSE 云原生网关的落地实践》的精彩演讲。

本篇文章针对这场演讲做了详细的解读。主要介绍小鹅通在 TSE 云原生 API 网关上的一些建设和经验，以及在这个过程中遇到了哪些问题和挑战，基于 TSE 的解决方案又是如何在小鹅通进行落地的，以及如何利用云原生网关实现降本增效的经验分享。

关于小鹅通

小鹅通是一家以知识产品与用户为核心的技术服务商。提供知识产品与用户服务的私域运营工具，小鹅通创始至今已经服务百万家客户，最高同时在线人数达一千万，面向7.8亿终端用户提供2000万知识产品。

小鹅通现状分析

CVM 时代入口网关架构

在 CVM 时代，小鹅通的入口网关是比较典型的一个架构，由大量的公网负载 CLB 组成，由于不同的场景和策略，导致小鹅通的安全防护覆盖程度不完全并且也难以梳理；小鹅通的业务场景属于流量变化比较明显的，在 CLB/CVM 的架构下，难以及时进行扩缩容，有些业务需要进行2到3倍的资源冗余，以保证流量上涨的稳定性，就会造成小鹅通的资源利用率低和成本的增加；伴随着这个问题，小鹅通有上百个公网 CLB，CLB 背后有上千条的路由规则，和后端的业务服务形成多对多的非常复杂的矩阵，造成运维成本非常高。

容器时代入口网关架构

随着采用容器化部署，小鹅通目前大部分的流量在容器集群上，在过渡阶段以及部分业务情况仍然需要考虑 CVM 场景，在一开始的技术选型上采用的是公司内部技术栈比较熟悉的也具备高性能的 Openresty 来实现的 Ingress API 网关，但引入了新架构的同时也加剧了原先存在的问题；因为小鹅通的业务和基础设施都是在云上，这部分和云产品的集成度一般，在保障稳定性建设的同时，还需要投入比较多的精力开发集成各块云原生产品。

因此，需要设计更好的架构以满足小鹅通的业务需求，解决痛点问题。

解决方案

在前期的自研过程，小鹅通也参考和调研了许多优秀 API 网关的架构与设计，像 Kong、ApiSix、TSE、Higress 等等，结合本公司的实际业务场景，从稳定性与高可用、流量治理、自动化能力、资源利用率出发，认为以上几个点需要优先保障或解决。

小鹅通列出每个维度需要考虑的要素，进行综合性对比分析。

云原生时代入口网关架构

相比其他解决方案，TSE 云原生 API 网关满足多可用区容灾部署、多种接入方式统一管理能力、开箱即用的限流熔断、流量灰度流量镜像、安全防护能力。由于小鹅通业务服务流量波峰波谷的性质，TSE 云原生 API 网关同样集成支持按照弹性伸缩和定时伸缩，最终小鹅通在这些方案中选择了 TSE 作为小鹅通的统一 API 网关方案。

经过变化调整，小鹅通得到一个如下图所示的云原生入口网关架构，通过从网关到小鹅通的服务再到数据库中间件的多可用区部署，来保障稳定性与高可用能力；统一流量入口、集中访问控制和提高安全性；提升自动化能力以提高我们的运维效率；根据自动弹性扩缩容、按需按量的付费策略，资源复用，提高小鹅通的资源利用率以降低成本。

接下来看一下小鹅通使用 TSE 云原生 API 网关后的两个具体场景。

稳定性与高可用

采用 TSE 云原生 API 网关节点的多可用区部署，配合小鹅通后端业务集群和底层的基础设施、数据库中间件的多可用区部署，在极端场景下的节点机器、磁盘、网络故障发生时，能够做到自愈和快速恢复，借助多可用区容灾能力提高小鹅通整体的稳定性和高可用能力。

流量治理

流量治理是前面提到的比较头疼的部分。面向客户端，小鹅通有非常多的入口，有100多个公网负载、上千条的路由规则，需要对这些进行拆分和复用；面向后端，小鹅通有 K8s 集群、CVM、Serverless 多种运行环境，同时也有多套 K8s 集群，也需要降低这里的运维成本。

因此这里分为两个部分来说明，面向客户端，通过 TSE 云原生 API 网关来统一管控，按照业务场景和需求进行集群、分组拆分，例如集群级别的物理隔离、不同网络安全策略，进行多集群的横向拆分，在单个集群内，还可以进行分组，达到物理隔离和配置路由复用的目的，从而完成南北流量和东西流量的统一治理；面向后端，多个业务集群统一管控，支持K8s、CVM 等多种运行环境的接入，TSE 本身和TKE 集群的集成度比较高，所以管理多个 K8s 集群是一个比较轻松的事情。