上海市建设工程交易服务中心网站,唐山培训网站建设,网站作品怎么做链接,无锡论坛网站制作导语
2023腾讯全球数字生态大会已于9月7-8日完美落幕#xff0c;40专场活动展示了腾讯最新的前沿技术、核心产品、解决方案。
微服务与消息队列专场#xff0c;我们邀请到了小鹅通的基础架构组负责人黄徐震为我们带来了《小鹅通基于 TSE 云原生网关的落地实践》的精彩演讲。…导语
2023腾讯全球数字生态大会已于9月7-8日完美落幕40专场活动展示了腾讯最新的前沿技术、核心产品、解决方案。
微服务与消息队列专场我们邀请到了小鹅通的基础架构组负责人黄徐震为我们带来了《小鹅通基于 TSE 云原生网关的落地实践》的精彩演讲。
本篇文章针对这场演讲做了详细的解读。主要介绍小鹅通在 TSE 云原生 API 网关上的一些建设和经验以及在这个过程中遇到了哪些问题和挑战基于 TSE 的解决方案又是如何在小鹅通进行落地的以及如何利用云原生网关实现降本增效的经验分享。
关于小鹅通
小鹅通是一家以知识产品与用户为核心的技术服务商。提供知识产品与用户服务的私域运营工具小鹅通创始至今已经服务百万家客户最高同时在线人数达一千万面向7.8亿终端用户提供2000万知识产品。
小鹅通现状分析
CVM 时代入口网关架构
在 CVM 时代小鹅通的入口网关是比较典型的一个架构由大量的公网负载 CLB 组成由于不同的场景和策略导致小鹅通的安全防护覆盖程度不完全并且也难以梳理小鹅通的业务场景属于流量变化比较明显的在 CLB/CVM 的架构下难以及时进行扩缩容有些业务需要进行2到3倍的资源冗余以保证流量上涨的稳定性就会造成小鹅通的资源利用率低和成本的增加伴随着这个问题小鹅通有上百个公网 CLBCLB 背后有上千条的路由规则和后端的业务服务形成多对多的非常复杂的矩阵造成运维成本非常高。 容器时代入口网关架构
随着采用容器化部署小鹅通目前大部分的流量在容器集群上在过渡阶段以及部分业务情况仍然需要考虑 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 网关团队在性能压测和容量评估阶段提供了很多的数据参考和成本方案建议同时在整个迁移过程也提供了非常多的技术支持和保障护航。
