抖音推荐 Feed 是抖音最核心的业务场景，是抖音用户最主要的内容消费渠道，对于高可用有着极高的要求。抖音推荐 Feed 的稳定性保障体系从 2018 年开始建设，随着抖音流量增长历经多轮迭代，持续优化“Feed可用性”及“容灾时Feed体验”。推荐 Feed 容灾架构经受住了 2019 ~ 2021 年抖音春节活动的考验，活动期间零故障。本次分享将重点介绍抖音架构治理团队积累的全链路、端到端的稳定性保障体系，以及极少需要人工干预的高可用容灾架构。

演讲提纲：
1. 背景：抖音推荐 Feed 全链路架构

• 网络接入架构
• 服务端架构

2. 多视角下的稳定性建设的一般思路

• 故障发生时机
• 故障类型
• 故障生命周期

3. 抖音推荐 Feed 稳定性保障体系

• 监控报警
• 容灾架构
• 服务治理
• 故障演练
• 应急响应

4. 具体案例

你将获得：

1. 了解稳定性建设的一般思路
2. 了解核心业务场景高可用架构的设计要点
3. 了解全链路稳定性保障体系

今年 4 月，同程艺龙上线了机票目的地盲盒活动，一经上线就倍受用户青睐。盲盒活动背后，面临着诸多的挑战，不仅仅有大流量对整个业务系统的考验，还有用户交互体验和口碑也对整个活动的成败有着重要的影响。要保障盲盒活动的顺利进行，不是使用某一个技术，或者依靠某一个系统就能做好的，而是积累的一系列平台和系统的合力使然。本次演讲，我将向大家揭露我们在盲盒活动中各系统的保障技术，有值得肯定的，有值得反思的，还有意料之外的。

演讲提纲：
1. 盲盒活动突增大流量

• 系统报警接踵而至
• 紧急召集团队，确定方案

2. 如何处理突增的大流量

• AIOps 流量预警
• 业务网关限流
• 分布式缓存
• 前端排队和秒杀交互
• 活动平台和无服务器架构
• 容器平台弹性扩缩容

3. 踩过的坑

• 小问题被流量放大
• 对于大流量，保持敬畏心

4. 总结

• 突发性大流量处理应对总结

你将获得：

• 突增大流量的预警方案
• 大流量秒杀场景下，团队踩过的坑
• 媒体和用户聚光灯下的活动，如何顶住压力开发好产品
• 总结处理突发性大流量的急应经验

C 端的计费中台在各互联网公司都是最核心系统之一，对可用性有着几近苛刻的要求。阅文集团旗下的 QQ 阅读、起点、webnovel 等 App 付费场景多为小额高频支付，在多次跟手Q春晚红包和515读书节等大型活动的洗礼下，支付中台活用有损思维及自研自适应限流 AdaptiveLimiter 和分布式事务 Seata on Tars 等技术手段，交出完美答卷。本次演讲我将向大家介绍支付领域“严谨”，“0 误差”如何跟“有损”结合，并带来阅文集团支付中台的思考和生产实践。

演讲提纲：

1. 当我们在谈有损服务，我们在谈什么

• 海量流量来临时的表象
• 思考模式和行为分析

2. 我们是这么使用限流的

• 常见开源限流组件 VS 生产环境中出现的问题及我们的思考
• 阅文自研自适应限流 AdaptiveLimiter 设计思路与细节
• 春晚活动限流效果
• 总结&工作中踩过的坑

3. 玩转最终一致

• 最终一致性技术手段结合玩法
• 真实案例：购买鉴权&计费中台的最终一致性
• 阅文改造分布式事务 Seata on Tars 设计思路与细节
• 总结&工作中踩过的坑

4. 做好降级这件“小事”

• 介绍服务降级国内的“鼻祖”
• 产品策略与技术手段上的降级——思路&说服产品篇
• 真实案例：技术细节&实际应用篇
• 总结&工作中踩过的坑

5. 总结

你将获得：

• 海量支付场景下踩过的坑及应对方案
• 根据业务场景改造组件的思路和要点
• 结合分享中的思考和实际案例解决工作中遇到的海量场景问题

RocketMQ 诞生于阿里云，自成为 Apache 顶级项目后在高可靠、高性能、低延迟领域有了长足的发展，俨然成为业内最流行的金融级消息中间件。本次议题从云上大规模生产场景出发，介绍新一代 RocketMQ5.0 在基础架构云原生化演进设计，并在此基础上分享 RocketMQ5.0 对于 Streaming 处理和事件驱动不一样的设计和思考。

为了服务于公司 G2-GreatQuality（高品质）和 Globalization（全球化）战略，携程从 2019 年下半年开始启动异地多活项目。MySQL 原生一主多从架构下，机房故障时需要数据层的 DR切换，造成恢复时间长；针对一些海外业务如果需要写数据，通常需要将数据回源上海，业务响应时间变长体验变差。异地多活架构下，机房故障时，只需要在入口将流量切离故障机房业务即可恢复，业务出海上云后实现本地读写。本次演讲，我将向大家介绍异地多活的核心组件 DRC 的详细设计以及背后的思考，在业务落地过程中遇到的问题以及解决方案。

演讲提纲：

1. 异地多活整体架构 

• 核心组件 Data Replication Center、Unit Control Service 和 API Router

2. DRC 详细设计

• 如何实现复制低延迟
• 如何保证数据一致性
• 如何不依赖独立数据库支持 DDL
• 核心指标监控告警

3. 公有云复制

• 公有云复制面临的挑战
• 公有云和自建机房双向复制方案
• 公有云和自建机房一对多复制

4. 高可用设计

• 核心组件高可用方案

5. 业务落地面临的问题

• 业务以 OrderID 作为分表键
• 现有 DBA 自动化系统需改造

你将获得：

1. 异地多活整体实施方案
2. 数据库双向复制设计方案
3. 公有云和自建机房复制解决方案

前后端分离的开发模式在业界已有一定成熟的应用，在此模式下的后端架构设计稳定性、连续性和灵活性，关乎业务能否通过高并发“大考”并保持高可用状态，特别是在流量较大微信生态场景下，如何解决这一痛点更加值得研发团队深入思考。微信和腾讯云的联合技术团队就基于架构稳定性和灵活性设计展开了一系列思考和实践，本次分享将重点介绍联合团队在探索过程中的经验沉淀和反思。

演讲提纲：

1. 背景：微信云托管架构介绍

• 微信生态流量洪峰对架构的挑战
• 为什么要做前后端分离？
• 微信云托管架构设计思考

2. 架构稳定性打磨经验总结

• 高可用多地域容灾
• 多集群能力建设
• 接口和功能拨测
• Sop 处理优化

3. 高并发与灵活性的权衡设计

• 支持高并发会让业务变得“笨重”？
• 弹性扩缩容设计

4. 一些案例

你将获得：

• 微信和腾讯云联合团队的高可用架构设计经验
• 前后端分离模式下后端建设新思路
• 多集群、多地域容灾能力建设方案

美团在多元业务场景下基础设施及业务系统具备复杂度高的特性，复杂度高体现在业务链路长、流量驱动模式多、一套基础设施支持多事业部场景等方面，同时也面对新业务迭代频繁、系统并发度高等诸多挑战。美团基础设施功能相对完善与统一，但在多元业务场景挑战下，也需要更多的从具体业务场景进行系统设计，建设全链路可用性保障体系。本次演讲，将向大家介绍复杂系统在高可用方面的难点、思考、应对方案。

演讲提纲：

1. 复杂系统高可用的困境

• 复杂系统的场景及特点
• 复杂性所引发系统可用性的冲击及挑战

2. 复杂系统的高可用应对方法

• 整体建设思路：预防、韧性、快速反应
• 故障预防
• 韧性
• 快速反应

3. 总结与展望

• 可用性建设总结
• 未来建设展望

你将获得：

• 了解长链路系统、多元业务场景异地多活系统、海量数据处理系统在可用性建设的难点及关键点
• 了解基础设施相对完善条件下，结合业务场景进行高可用系统设计的要点
• 掌握全链路稳定性保障的实践经验