微信早在 2015 年，参考 Google borg 论文及其他资源猫管理系统，开始了 Yard（Yet Another Resource Dispatcher) 系统研发，并于 2016 年逐步接入了微信大部分后台服务，解决了微信在线服务合并部署、资源管理、实时调度及扩缩容等问题。随着 K8s 技术的推广与成熟，K8s 逐渐成为了业界资源管理系统的事实标准，同时，自研 Yard 系统在长期的运营改造中，架构重构的方向越来越与 K8s 趋同，如容器化支持、灵活的调度策略、HPA、GPU 等 K8s 社区已相对成熟方向。在此大背景下，微信于 2020 年开始把在线资源管理系统由自研 Yard 切向 K8s，开始了微信后台云原生之路。

本主题阐述了微信当前的系统架构及容灾设计，分享微信后台在高可用的要求下进行容器化改造及平滑迁移 K8s 系统面临的各种问题及挑战。

演讲提纲：



1. 微信后台架构及容灾设计
2. 微信后台容器化改造的挑战
3. 支持Yard与K8s的“混合云”系统设计及实现
4. 成果展示

在 K8s 高可用领域有一个问题被大家所熟知，那就是 K8s 单集群规模带来的 SLO 问题。如果 ASI 单集群规模支撑超过社区的 5000 台，如何持续保障？这是个非常有意思且具备极大挑战的事情。这对需要进行 K8s 生产化的同学，甚至具备 K8s 生产化经验的同学来说，一定会是个感兴趣的话题。而 ASI 在单集群的规模从最初的 POC 100 台，到 4000 台，增长到 6000 台、8000 台，一直最终增长到 10000 台，每一次集群规模的增长，伴随着业务的增长和多样化，压力也在逐步发生着质变，给我们带来的挑战每一次都是不一样的，每一次都要比前一次挑战更大。 另外在我们的场景中还有一个问题，就是 K8s 集群成千上万，还牵涉到数百人以上的研发运维人员，功能发布频繁的迭代开发模式以及业务种类繁多带来的运行时的复杂多变，实现“4个9”（1-5-10目标），其难度不言而喻。 本次分享将为大家介绍阿里巴巴使用 K8s 开源项目如何从抗住，到建设出高可用体系的经验。

演讲提纲：

1. 背景：大规模 K8s 集群面临的问题与挑战

2. 高可用体系的设计

• 高可用基础能力
• 应急体系建设
• 能力和保险机制

3. 高可用基础能力的关键部分

• 架构升级
• 性能瓶颈突破
• 预发能力增强

4. 高可用应急体系的关键部分

• 一分钟发现：问题发现能力
• 五分钟定位：问题根因自动定位能力
• 十分钟恢复：恢复止损能力
• 问题持续跟踪机制

你将获得：

• 了解大规模 K8s 集群会存在的问题
• 了解如何基于 K8s 建设高可用体系
• 了解阿里巴巴 K8s 的落地实践与思考

面对国内疫情的积极向好趋势下，出行需求开始快速恢复。在今年的清明小长假、五一长假下，同程旅行迎来了历史流量的新高峰，主落地页流量较日常翻三倍。而去年做完降本增效的同程私有云平台，通过弹性计算完成了不新增资源、业务无感、无损单的预定技术目标。今天和大家聊下峰值流量应对、故障自愈、降本增效的核心技术——弹性计算体系的设计思考与在同程旅行的落地经验。其中包括如何自动化地确定扩缩容指标、峰值流量应对、离在线混合部署、线上故障自愈等，希望能为大家提供新的思路或者启发。

演讲提纲：

1. 出行需求快速上涨提出的挑战

2. 同程私有云平台弹性计算架构及整体解决方案

3. 自动化的计算服务的扩缩容指标

• 传统方法（压测、缩容法）计算扩缩容指标局限性
• 如何自动化的计算服务的扩缩容指标
• 弹性扩缩容的基石——服务画像

4. 在峰值流量下利用弹性扩缩容保障稳定性

• 弹性计算体系化应对峰值流量
• 影响弹性扩缩容时长、成功率、稳定性的几个关键点
• 秒级扩缩要如何实现

5. 利用弹性计算完成降本增效

• 迈向 Lambda 无服务器架构的第一步
• 如何自动化地计算当前服务需要多少资源
• 潮汐扩缩容在同程旅行的架构设计
• 推广业务上潮汐扩缩容的难题

6. 解决稳定性的最后一公里-自动漂移解决单机稳定性

• 弹性扩缩容如何解决单机稳定性
• 同程旅行的自动漂移架构

7. 一些展望和总结

听众受益：

• 了解弹性计算整体技术体系，以及如何建设
• 了解弹性计算在自动化的确定扩缩容指标、峰值流量应对、离在线混合部署、线上故障自愈方面的应用场景和解决方案
• 了解弹性计算在稳定性和成本节省方面能够给公司带来的收益

数据和算法会对推荐系统的效果产生重要的影响，但系统的实时性也是重要的一环。实时可以给用户更精准的推荐，让新发表的好内容更快的成为热点，整个生态形成正循环。实时推荐系统需要全链路都是实时的，不能出现短板。因此，我们分析了推荐的全链路，对其中的“非实时”部分，做了针对性的极致优化，主要包括特征服务、模型上线、检索召回三大部分，最终使得这些流程都达到了毫秒级或秒级的实时性。用户当前的行为为几秒后就会对推荐结果产生影响，助力各业务实现了秒级的实时推荐系统。 

演讲提纲：

1. 推荐系统中实时性的意义和挑战

2. 实时的特征服务

• 高吞吐的批量导入
• 流批一体的支持

3. 实时的模型上线

• 实时的推理模型上线
• 实时的向量检索服务 

听众收益:

• 了解推荐系统中实时性的意义
• 知道实现一个实时的推荐系统，需要解决那些问题 

东南亚因语种多样、语料库缺失、GIS 地理信息薄弱等多种原因，其末端物流发展还处于依靠人工的初级阶段，导致效率低下、准确受限、拓展速度受限。本分享将介绍 Shopee 如何基于大数据、人工智能等技术，在东南亚各个国家实现末端物流分拣的自动化、智能化，从而支撑 Shopee 快速发展的最佳实践。

演讲提纲：

1. 东南亚末端物流之痛
2. Shopee 末端物流解决方案

• 业务架构模型
• 技术架构模型
• 关键技术实践

3. 未来展望

随着外卖广告业务的不断迭代，目前已拥有5大业务方向，20+ 条业务场景，在迭代过程中，逐渐出现了业务逻辑复用度低、PM、RD 信息获取难等问题，直接影响着迭代效率。因此我们启动了平台化项目，意在从产研迭代的全流程进行升级改造，提升整体迭代效率。我们结合业务现状问题，提出了整体打法：标准化，平台框架，产研新流程 3 个核心点，其中在标准化过程中，我们聚焦在功能、数据协议、流程 3 个维度。在平台框架层面，在 3 高层面（高性能，高可用，高扩展），我们进行了大量思考。在产研新流程层面，在产研的 3 端也进行了一系列的改造，保证平台化整体推进落地。基于上述方案，平台化在广告业务场景落地后，取得较好的收益。

演讲提纲：

1. 背景

• 外卖广告业务介绍
  • 业务场景
  • 广告检索架构
• 目前现状 & 问题分析：研发现状问题
• 目标：提升产研全流程迭代效率

2. 架构解读

• 架构思考
• 具体实现
  • 标准化
  • 平台框架
  • 产研新流程

3. 成果展示

4. 总结

你将获得：

• 了解广告检索系统平台化的思路与具体实现
• 了解广告平台化遇到的问题以及解决方案

Metrics 监控是字节跳动重度依赖的可观测性手段，目前字节国内机房 Metrics 打点量已经达到 10+ 亿每秒。字节自研时序数据库，正是 Metrics 数据的载体。它以高可用、高性能为设计目标，同时具备亿级写入吞吐、秒级查询时延的能力。本次分享主要包含该时序数据库的整体架构、内核探究、周边生态等。

演讲提纲：

1. 字节自研时序数据库概述 

2. 字节自研时序数据库内核探究

• 高性能存储：结合 Cache 和 HDFS 构建冷热存储
• 高可用大脑：集群状态中心 Coordinator
• 高性能查询：分布式时序查询引擎

3. 业务支撑案例

• 框架和链路追踪
• 观测诊断平台
• 微服务数仓

4. 总结和展望