百度爱番番为什么一定要选择云原生架构？爱番番做为典型的 ToB 业务，面临 ToB SaaS 需求多变、稳定性要求非常高、多云/私有化等多样化售卖场景，以及多语言异构技术栈和过于细致的微服务模型导致治理成本过高的困境，在技术架构上面临着非常大的挑战。

那么解决方案是什么呢？秉持以业务成功为导向演进思路，通过基础设施云化，能力就近下沉，提供快速迭代，弹性扩展，开源共建价值交付链。迁移 K8s 方面，以 DevOps 理念为指导，基于 K8s，建设统一、标准和自动化的持续交付 CI/CD 平台，落地业界主流的 Service Mesh 产品 Istio，包括与现有服务治理产品适配和平滑迁移方案，享受基于 Istio 释放的红利，包含逐步为业务赋能的实践案例。本次演讲，将重点介绍我们在技术选型上的考虑，和最终的效果案例。

演讲提纲：

1. 云原生架构介绍
2. 百度爱番番建设云原生架构的选择
3. 迁移 K8s 实践 —— CI/CD 平台
   • 寻找产品快速迭代与底层架构升级平衡点
   • 业务服务云无感知云原生化升级（CI流程）
   • 可编排，多平台部署与发布引擎(CD方案)
4. Service Mesh 体系建设
   • 传统运维治理架构在 ToB SaaS 下的挑战
   • Service Mesh 落地方案与技术架构
     • 业务迁移
     • 注册发现
     • 流量治理
   • Mesh化下红利释放实践
5. APM 体系建设
6. 稳定性保障
7. 未来规划与探索
   • 中间件网格化
   • Serverless 化
   • 运维 AIOps 化

你将获得：

1. 了解云原生下 CI/CD 平台的建设与落地经验
2. 了解 Service Mesh 在实际生产环境探索与落地
3. 了解云原生化下的 APM 体系探索与实践
4. 了解稳定性保障的方法论和体系化的解决方案与落地

作业帮是一家教育科技公司，致力于用科技助力普惠教育。业务范畴广，复杂度高，并发高。技术层面上面临了稳定性、成本、效率等诸多方面的挑战。每个方向，可能有多种解法。但我们不可能在众多基础技术上一直深入。所以摆在我们面前的就只有一条道路——云原生架构，用基础设施接管业务中大量非功能逻辑，实现弹性、韧性、可观测性、自动化、可持续等特性。

云原生中较为标志性的成熟技术是容器技术和 Service Mesh 技术，除此之外，多云技术也是最近大家津津乐道的一块。本次的议题也会基于这三部分来展开。

演讲提纲：

1. 作业帮云原生改造的背景
2. 作业帮云原生架构全貌
3. K8s 实践历程
   • 业务容器化改造原则及具体案例
   • 对内核、K8s 原生调度器的各种优化
4. 服务治理体系
   • Service Mesh 方案选型考量
   • 构建了一套高可用日志体系
5. 多云架构
   • 网络拓扑
   • 设计原则——单云闭环，集群发现
   • 多维度流量调度
6. 从稳定性、效率、成本等诸方面讲述云原生带来的收益
7. 展望
   • Serverless 更大规模的应用
   • 以 RTC 为场景的云边协同
   • Service Mesh 覆盖 RPC 以外更多场景
   • 云原生时代带来的零信任安全挑战

你将获得：

1. 了解容器改造的原则与实践经验
2. 了解 K8s 原生问题的深度优化经验
3. 了解 Service Mesh 的技术选型和落地实践
4. 了解适合中型和中大型企业的多云架构落地经验

云原生时代已经到来，较早发力的企业和新业务率先享受到云原生先进理念和领先架构的红利。然而，传统行业、企业存量系统依旧背负着沉重的技术债务和历史包袱，在技术革新与架构演进道路上举步维艰。

本次分享以网易集团跨入云原生时代的实践出发，介绍传统业务平滑演进到云原生架构的“纵”与“横” —— 纵，即以关键技术为核心的纵向能力建设，增强技术能力深度，解决业务单一场景的难题；横，即以业务场景为核心的横向能力建设，增强场景覆盖广度，解决业务架构演进过程各阶段的支撑难题（共存、互通、稳定性）。最终，以“纵”“横”架构为核心设计导向，结合微服务、负载均衡、服务网格、容器等云原生技术，在传统行业、企业存量系统得到了有效验证与大规模落地，帮助业务顺利进入云原生“航道”，高效获得云原生建设的价值回报。

演讲提纲：

1. 云原生的先进性
2. 奔向云原生的“纵”“横”架构
3. 云原生技术与“纵”“横”架构的整合实践
4. 传统业务系统奔向云原生的关键要素总结

你将获得：

1. 传统业务系统向云原生演进的整体架构设计思路
2. 整体架构与云原生技术、业务存量系统的整合实践，遇到的坑及如何规避
3. 云原生时代长效的演进架构设计思路

在字节使用 Kubernetes 的过程中，随着集群规模增大到 1w 节点左右，etcd 成为制约集群可扩展性的瓶颈，经常出现读写延迟增高、OOM 等问题。

针对以上问题，字节自研了 KubeBrain 代替 etcd 作为 Kubernetes 的元数据存储系统，旨在提高 Kube-APIServer 存储的读写性能，增强集群稳定性。

KubeBrain 构建在分布式的 multi raft group 的强制一致性 KV 之上，并支持事务写、快照读、Watch 等需求，同时针对 Kubernetes 场景做了深度的性能优化。

经过性能测试，KubeBrain 的读写性能大幅超过 etcd，在压测场景中，我们的 Kubernetes 集群到达了 5w 节点，200w Pod 的规模。线上集群规模到达了 2k Node，持续逐步上量。

演讲提纲：

1. 在大规模 Kubernetes 集群实践中，遇到的 etcd 相关瓶颈与相关分析
2. KubeBrain 的设计思路与实现介绍
3. KubeBrain 字节内部的落地情况与效果
4. KubeBrain 的未来规划

你将获得：

1. etcd 瓶颈分析
2. Kubernetes 元数据存储系统的需求、特点
3. 高性能 Kubernetes 元数据存储的设计思路与架构