作为办公套件领域进场最晚的厂商，腾讯文档在初期发展主打的是快速将产品迭代并上线，开源组件的方案几乎成了唯一的选择，但是随着业务发展壮大，这种过度方案遇到了可预知的挑战：开源方案无法满足来自产品以及技术的需求。于是，我们在 2021 年进行了自研架构的设计和开发，并且在保持与老架构兼容的情况下，实现了线上的三大办公品类的平滑切换，完成了基于多平台原生应用的架构设计使得我们成为行业内首个实现了多端统一的办公套件。本次演讲将分享我们在从开源组件到自研架构的现代化工程演讲过程中的实践经验和思考。

演讲提纲

1. 背景

• 腾讯文档产品形态介绍
• 横跨 Web、客户端（早期没有）、小程序的多人在线协同文档办公套件

2. 不同阶段的问题和解决方案

• 初始阶段：做协同办公文档 SaaS 套件
  •  开源方案实践，半年快速迭代一个可用的在线 Office 协同产品
  •  开源方案应用过程思考：
    • 渲染：从 DOM 到 Canvas？还是 WebGL
    • 组件化：UI组件、网络组件......
• 发展瓶颈期：协同办公的全面兼容 Office 套件（不限于 SaaS，还要有客户端）
  • 遇到的问题：
    • 性能
    • Office 功能兼容性
    • 产品线缺失：客户端
  • 结合自身的团队技术水平制定合适的设计方案
  • 重新设计后的架构设计图-全景图
  • 结合现代化技术，拥抱变化
    • 使用 AIGC 生成部分代码
    • 使用 AI 处理单元测试用例
    • 多端用例同步，使得业务逻辑能够稳定对齐
• 发展后期
  • ​垂直领域技术人才的培养
  • 深入技术前瞻性，为拓展更多的可能做作准备
    • 多企业版本管理思考
    • 鸿蒙适配引发的思考

3. 经验总结与反思

实践痛点

1. 需要解决 wasm 无法获取浏览器提供接口以外的任何信息
2. 需要在过程中忍受很漫长的混合方案带来的 debug 难的问题
3. 忍受 c++ 代码带来的各种学习成本，运维成本等等的难题

听众收益

1. 了解腾讯文档对专业软件的探索以及发展思考
2. 每个阶段是如何做决策的以及有哪些经验是大家可从中受益的
3. 一个已经发展 30 多年的软件体系，如何在互联网时代焕发新的技术原力的

当前微服务发展至今，仍然存在几个问题：

1. 业务开发者需要感知复杂基础设施，启动慢（分钟级），研发效率低
2. 拆分微服务的成本高：拆分后每个子应用都包含公共部分（框架、中间件等），资源成本高，且需要长期维护
3. 拆分微服务的敏捷度与业务、组织发展的敏捷度不一致，如何合理的拆分微服务始终是个老大难的问题，拆得多造成资源和管理成本，拆的不够造成协作效率问题
4.……

蚂蚁在研究了业务痛点后，采用分层思维模式，在传统微服务只是横向拆分基础上，改进成同时进行纵向和横向拆分，纵向拆分成基座和模块，使得模块不占用额外机器（节省容量），模块开发者只关注业务自身（认知负荷低）；横向拆分成多个模块，让模块开发者可以独立迭代互不干扰（协作效率高）。当前蚂蚁内已经全部 BG 共 70W Core 应用使用该新型应用架构模式，构建产物从原来的 GB 下降到 MB, 业务启动降到秒级，平均迭代效率提升 10 倍。目前也开源出 Koupleless 项目，希望帮助行业解决类似问题，降本增效。

演讲提纲

1. 传统应用研发与微服务的问题与挑战

• 单体应用过大，多人协作阻塞
• 拆分微服务过多，资源占用过多
• 微服务拆分没有标准，大应用过大与小应用过多带来长期的问题治理成本

2. Koupleless 的思考与权衡

   解决思路：通过模块化框架对传统应用进行三个设计：

• 分层屏蔽基础设施
• 细化研发粒度避免协作阻塞
• 平滑演进帮助传统应用低成本享受到 Serverless 收益

3. 该模式需要建设的完整能力有哪些

   该模式带来的优势和劣势，如何权衡

• 优势：快、省、灵活部署、平滑演进
• 劣势：需要解决生态的模块化兼容性问题，如果在一个进程内运行多个应用，如果低成本的解决这些兼容适配问题

4. 运维平台与调度的低成本演进之法

• 基于模块化可以有哪些高级的运维调度能力，快速发布、秒级扩缩容、资源高密调度、流量调拨
• 模块化平台的基础能力需要有哪些
• 如何完成模块化平台的低成本能力建设，与生态融合

5. 蚂蚁与开源社区落地的实战经验

• 蚂蚁 Koupleless 诞生于开源之路
• 针对多种业务模式，中台模式、传统应用模式、通用基座、代码片段模式分别实践效果

6. 总结展望

• 帮助传统应用低成本演进到 Serverless 的经验总结
• 未来通过模块化研发模式实现降本增效、助力绿色计算的思考

实践痛点

当前的多模块是基于 Java 语言，在一个 JVM 内安装多个模块，也就是多应用模式。在多应用模式里，存在一些与生态不兼容的问题：

• 共享变量带来的互相干扰
• 运行时多 classLoader 切换时带来不一致的问题
• 在运维平台上，如何低成本的与现有的生态集成
• 如何支持更多的语言类型

演讲亮点

1. 在应用研发与微服务领域，与传统微服务的横向拆分方式不同，Koupleless 模块化将传统应用同时进行纵向和横向拆分

• 下沉基础设施
• 细化研发运维粒度

2. 存量应用可低成本演进的 Serverless 之路

听众收益

• 了解蚂蚁集团在应用架构上前沿的技术和成果
• 开拓一些新思路，用新方法思考如何合理拆分微服务，解决拆分过多，或未拆分带来的问题，同时也避免微服务的额外损耗
• 了解该新模式是如何权衡利和弊，在隔离与共享之间找到能解决当下问题的最佳平衡点
• 了解目前这种新模式在领域里的现状与挑战，以及未来的展望
• 如何将这套模式应用与自身企业，解决降本增效问题，帮助存量应用低成本演进到 Serverless 模式

字节跳动从 2018 年就开始了大规模云原生容器化部署的实践，依托于内部 TCE Toutiao-Compute-Engine 计算平台，推动核心业务方完成了的云原生容器化改造，，并借助在离线混布、集群联邦、混合调度等技术手段。与此同时，我们也在积极的探索容器技术的下一步。Serverless 团队早期聚焦于函数计算、批处理任务形态，2022 年字节跳动 Serverless 计算平台基本收敛了集团内部的事件驱动/消息队列消费的业务场景，在此基础之上，我们希望借助 Serverless 技术体系，助力集团业务的微服务进一步降本增效。

本次演讲我将重点介绍 2023 - 2024 年，字节架构 Serverless 团队依托于电商、直播等核心业务方，在微服务 Serverless 化方面做的技术工作，分享业务支撑过程中碰到的问题与痛点，抛砖引玉。

演讲提纲

1. 字节云原生技术体系介绍

• 字节 2016 年开始大规模容器化部署的过程：Toutiao Compute Engine
• 字节微服务：基于 Golang Thrift RPC 框架的 ServiceMesh 体系
• 容器化部署方案碰到的问题：
• 2019 年开始 Serverless 技术栈的投入：字节 ByteFaaS

2. 字节跳动 Serverless 技术体系

• 一套 Serverless 流量调度基座
• 多种上层计算产品形态：函数计算，异步任务，Serverless 微服务

3. 早期几次不太成功的推广尝试

• 尝试 1 ：框架层面进行侵入性改造，基于 Thrift IDL 生成 HTTP 服务代码，适配计算平台
  • 反思：计算平台应该适配业务研发生态
• 尝试 2 ：函数计算 支持 RPC 服务，同时与 Mesh 集成
  • 反思：作为函数计算起家的研发团队，拿着锤子找钉子
• 其他问题
  • 与用户开发习惯差别太大
  • 用户对稳定性的担忧
  • 还是冷启动、扩容速度

4. 2023-2024：微服务 Serverless 化：助力微服务体系演进

• 与其引导客户使用一套新的函数计算开发范式，不如思考如何让函数计算的底层计算调度能力适配微服务开发体系
• 产品层面
  • 与微服务开发平台整合，作为底层 计算运行时；用户无需更改代码
  • 容器负载 与 Serverless 弹性负载 混合使用：
  • Service Mesh 整合进计算运行时内部，对齐微服务流量治理研发生态
• 技术层面
  • 微服务体系集成：流量转发与资源调度解耦
  • 容灾体系：全托管的计算形态下，多集群、多 az 容灾
  • 弹性伸缩：基于业务指标增强的 autoscaling 与过载保护
• 冷启动：资源池化 + 容器进程快速拉起 + 闲置实例 的多条技术路径，解决不同类型用户对突增流量冷启动速度的诉求
• 业务试点与推广：以直播业务为例，分享业务在 微服务 Serverless 方案下的成本和性能收益

实践痛点

• 集团复杂的微服务 Mesh 体系的对接与整合
• 性能层面的损耗与应对措施
• 业务方对微服务 Serverless 的稳定性顾虑

演讲亮点

• 微服务 Serverlss 化项目实施过程中的真实问题与痛点
• 基于一套技术底座，实现多协议、多形态的计算产品的技术方案
• 多条技术路径分级解决业务冷启动问题的解决思路

听众收益

• Serverless 技术在字节内部推广的收益与阻力
• Serverless 与容器技术、微服务体系的边界划分与整合
• 了解字节 Serverless 底层技术演进开展的工作和未来的技术规划

B 站作为国内领先的内容分享平台，其核心功能之一便是支持 UP 主们创作并分享各类视频内容。UP 主稿件系统作为 B 站内容生产的关键环节，承担着从内容创作到发布的全过程管理。随着业务的快速发展，技术团队面临着组织变革、业务需求快速迭代以及系统劣化的挑战，稿件生产系统历经从大单体到分层架构，再到基于云原生的微服务架构演进，在这一过程中我们需要面临降本增效、业务耦合、历史债务、线上稳定性等，本次分享将会从业务视角介绍架构演进落地实践的经验和思考。

演讲提纲

1. 背景：B 站稿件业务形态和系统架构介绍

• 业务形态，业务架构服务于业务战略
• 业务架构概览
• 技术指标与业务指标，怎么判断业务的连续性和健康度

2. 架构演进的几个策略

• 大单体的混沌时代到服务分层
• 微服务化与业务事件驱动模型
  • 稿件业务的异步模型流程
• 勇于选择数据模式的更换
  • 适配业务需要，新的存储模型选择，数据迁移痛点
• 代码之上，运行时环境的演进
  • 演进式架构，体现在代码本身的改变，也体现在代码的运行环境、运行时、服务的层级/领域、微服务组成网络拓扑的演进
• 多活、FaaS 化和混合云
  • 同城/异地多活
  • 转码资源调度的 FaaS 化
  • 投稿存储转码的混合云是下一步计划

3. 经验总结与下个阶段的展望

• 痛点总结，没有银弹，总要做选择和取舍

互联网 App 春节发红包已经成为惯例，春节活动中抢红包场景下流量集中 QPS 较高，且一年仅一次，需要保证其绝对稳定。快手支付团队将多年的经验沉淀为活动系统及标准保障流程，保障了每年的活动稳定，也大幅降低了每年的人力及机器成本。

演讲提纲

1. 春节红包的背景与挑战

• 春节红包的历史及快手红包玩法
• 百万级 QPS 准实时入账的各项挑战

2. 技术方案及实践

• 架构设计：高效、可横向扩展的系统架构
• 细节优化：代码、数据库、JVM、各项组件的调优
• 稳定性保障
• 资金安全保障

3. 总结展望

• 从历史实践中提炼的技术经验沉淀
• 红包活动中的踩坑经历和解决方案
• 未来展望

实践痛点

成本与用户体验之间做了一些平衡。

演讲亮点

高并发的解决方案在业界已经比较成熟，这里主要是和大家讨论一下如何完整的串起来并沉淀一套流程来保证可靠性及降低长期成本。

听众收益

• 了解快手历年红包活动的经验总结及技术沉淀
• 讨论高并发业务的总体设计及细节优化思路