网站发帖做业务网站seo源码

导语

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 集群是一个比较轻松的事情。

方案迁移落地

在上一个部分，提到了 TSE 云原生 API 网关的架构和设计，能够解决小鹅通不少的问题和要求，但是实际如何迁移落地是一件至关重要的事情，小鹅通对整个迁移方案进行了几个阶段的任务拆解；

第一阶段：针对小鹅通自研的网关、开源网关以及云原生网关进行性能压测对比，从 CPU、内存、带宽、新建连接数、并发连接数等等这些基础关键性的指标进行详细对比，确保验证通过并且符合小鹅通的预期。

第二阶段：根据这些多维度的指标，评估契合小鹅通业务的容量方案，包括规格、节点数等。

第三阶段：结合小鹅通实际的业务场景和业务开发测试一起进行多个业务线、多次的服务压测、全链路压测，以保障服务质量，为小鹅通的客户使用体验负责。

第四阶段：通过 OpenAPI 全量同步100多个公网负载、上千条的路由规则，在这个过程中，梳理了大量的路由规则，确认涉及的功能以及影响范围，将不确定性的部分变为确定性。

最后一步：根据前面梳理的规则，按照域名、用途进行分阶段分批次的渐进式迁移，逐步将流量切割到 TSE 云原生 API 网关上，完成最终落地。

如何完成平稳流量切割

关于如何完成域名平稳流量切割到 TSE 云原生 API 网关，这里列举了两个简化的场景。

第一种场景，设置域名解析权重，请求解析到不同的后端实例完成分流，从1%逐步增加流量直到全量请求到 TSE 云原生 API 网关，再将域名解析切换到 TSE 云原生 API 网关。

第二种场景，域名直接解析到 TSE 云原生 API 网关，在网关的服务或者接口路由上配置灰度策略，将流量转发到后端对应的业务服务，逐步增加流量到100%，最后清除灰度策略；实际情况下会比上面提到的两种稍微复杂一些，小鹅通在域名解析和灰度策略上做了不少工作，来实现秒级流量切换和回退。

统一网关带来的收益

除了解决前面提到的核心问题，统一网关也带来了以下收益：

1、减少了90%以上的 CLB 实例数量，通过网关自身的弹性扩缩容配合我们业务的弹性伸缩，极大的降低了我们的资源成本和维护成本；在整个迁移的过程中，同时也梳理了大量的公网域名、路由、负载，进行了相应的合并删减。

2、充分利用 OpenAPI、CRD、插件的方式提高小鹅通的自动化能力，将一些动作和小鹅通的服务初始化的流程和其他环节打通，提高效率的同时也降低了出错的可能性。

3、借助 TSE 云原生 API 网关来统一治理小鹅通业务服务的入口流量，和 WAF、VPN、流量镜像、接口请求响应的审计分析，和小鹅通的安全团队运维团队一起提高访问控制与安全性。

总结

感谢 TSE 云原生 API 网关团队，在性能压测和容量评估阶段，提供了很多的数据参考和成本方案建议，同时在整个迁移过程也提供了非常多的技术支持和保障护航。