Top100大会2024北京站见闻
12月份笔者有幸参加了在北京举行的Top100大会，持续两天半的议程干货满满，收益良多。借本文整理、分享本次会议的相关内容和笔者自己的一些思考，为这次来之不易的北京之行做一个总结和回顾，也希望可以让我的读者们有所收获。
Top100大会北京站介绍链接：https://top100.msup.com.cn/Project
这次大会中，来自各行业领先公司的专家们进行了近100个不同主题的分享/报告，但是正如本次大会的宣传口号“大模型时代案例启示录”所表达的大会主题，这其中近90%的分享是围绕人工智能展开，没有相关研究背景和实践经历的我，坐在台下，仿佛回到了十多岁时的课堂上。因此，笔者在此仅为大家介绍下我能听懂且感兴趣的2场报告：
来自 微博 网关架构师 王飞飞 的分享：超热点流量下基于api网关的业务高可用实践
来自 去哪儿网 技术架构SIG成员 姜川 的分享：机票主流程稳定性架构
1. 【微博】热点流量下的网关高可用建设
微博作为老牌、传统的吃瓜一线战场，后端系统总是会承受不可预期的流量洪峰。
业务属性带来的问题必须要有工程上的解决方案，但是这个解决方案不是架空的，必须要服从一定的约束。当然，其实我们看来这些约束不是微博系统特有的。
在上述背景下，微博工程师们逐步完善、落地了一揽子的整体演进。
1.1 全链路流量调度：流量疏导
接入层网关划分为 单元化集群 和 公共集群
单元化集群用于就近访问，同时承接基准流量
公共集群用于备援/容灾，可跨单元调度流量，用于承接流量洪峰和故障切换应急
流量治理/迁移白屏化、预案化、自动化
1.2 API降级：内置止血能力
将限流/熔断环节左移到流量接入层，避免过载流量涌入后端服务带来的资源开销。同时，可以在通过降级能力快速处理后端服务不可用的极端场景。
为支撑动态的业务降级需求，网关路由支持配置的备用API(轻量的)供自定义的动态业务降级。
为支撑静态的业务降级需求，可配置静态的接口降级缓存。
1.3 动态、多级缓存：降低后端负载
整体类似热点探测与本地缓存机制，通过全局视角下的数据统计，让热点的缓存驻留在网关进程内，保证热点内容的响应延迟同时降低后端服务的负载。
当然，该架构能成立也是由于微博作为UGC平台的业务特性决定的。缓存带来的最大的问题可能就是博文点赞量、评论量数据有延迟，并不会有交易、结算层面的不一致，对缓存一致性的容忍度是比较高的。
1.4 自适应限流：弃卒保车
事前人肉梳理、确认核心API
动态感知网关资源水位
根据资源水位执行限流预案
1.5 总结
2. 【去哪儿网】核心链路稳定性加固
去哪儿网作为业内知名的在线旅游平台，在服务化、容器化的大背景下，面临了一些微服务架构下常见的问题。
为了解决上述问题，去哪儿工程团队逐步落地了一套完备的解决方案。
2.1 精细化的流量识别与控制
通过统一埋点在网关分流、服务内RPC等流量环节进行流量优先级决策、流量来源跟踪，实现流量元数据全链路感知，为链路流量治理(如监控、告警、限流、降级等)提供统一的元数据抓手。
2.2 突增流量应对+弹性限流
基于上述流量识别结果，对流量进行分级治理、管控。
2.3 演练+预案
预案平台化
告警和预案关联
识别强弱依赖，提供故障应急、服务治理抓手
模拟故障识别系统稳定性漏洞
2.4 总结
3. 个人感想
受限于议程时间安排，相关主题的分享只是点到即止，只能尽可能让台下的观众理解想法和思路，具体的实现细节其实不会是分享者的重点。
整体的感受下来，好像体量相似的各家互联网公司面临的挑战度都是类似的：成本、效率、性能、稳定性。
因为业务属性不同决定了面对同样问题的整体解决方案是不同的，但是组成解决方案的Action其实也都是业内不约而同的在尝试、在实践的东西，好像也没有那么神秘。