从 2016 年开始招募第一名前端、从 0 开始搭建快手前端整体技术服务和脚手架，到前端团队贡献一份力量、支撑快手完成春晚任务：春晚红包互动总量达 639 亿次；红包站外分享次数达 5.9 亿次。快手春晚直播间累计观看人次 7.8 亿，最高同时在线人数 2524 万。在短短的 4 年时间里，快手前端团队经历了什么？快手 App 访问量的快速增长对前端团队带来哪些挑战？InfoQ 记者在 GMTC 全球大前端技术大会（深圳站）2019 期间采访了快手前端技术专家宋云路，一探究竟。

InfoQ：能否先请介绍一下快手 App 前端业务的发展历程、期间一些重要的节点？

宋云路：快手是 2016 年前后才开始招募专职的前端工程师的，之前前端工作都是由全栈工程师来完成。我也是 2016 年年中入职到快手的，2016 年起我们用小而精的团队从 0 开始搭建快手前端的整体技术服务和脚手架。

在 2017 年到 2018 年的时候，快手的业务量和 DAU 迅速增长，公司也逐渐孵化出一些产品矩阵，就像孵化器一样，“我们先孵化一个孩子，养大点就送出去独立闯荡了”。快手前端也从最开始的仅一个团队逐渐分化为近十个团队，从最初的几人，发展到目前近 200 人。

如果说其间的一些重要发展节点，2018 年起，我们逐渐开始做一些运营类的业务，然后前端访问量就逐渐开始变大。2018 年春节之前，快手 App H5 业务突破了亿级日访问量；到了 2019 年春节的时候，已经达到十亿级别的访问量；今年 2020 年春晚快手成为春晚红包独家合作伙伴，春晚红包活动中有一部分功能就是由前端负责实现的，我们也在用尽全力去保障前端业务的高可用性。

InfoQ：快手 App 访问量的快速增长，对您的团队会有哪些挑战？

宋云路：我们团队建立的时候没有什么历史包袱，最开始就是基于 Node.js 中间层做前后端分离的，后端只提供类 Restful API 接口，其他都由前端负责。从这个角度来讲，前端承担的职责是比较广的，包括 Node.js 开发、DevOps 等一些常规的页面端和服务端的事情都需要去处理。

一方面我们会去借鉴业界的一些优秀实践经验，另外会划分出一部分精力来做常规前端不太擅长的知识的沉淀和提升。比如高访问量 Node.js 服务和纯前端服务的稳定性保障等方面，我们通过每年春节活动等重大活动的验证，最高支持了十万级 QPS 前端项目的稳定运行，已经积累了一些非常成熟的经验。

InfoQ：回到前端中台化，当时为什么会决定要做这个事情？背景是什么样的？

宋云路：前端中台化的前提首先是快手从公司层面有一个整体的中台战略，它会从公司层面提供一套整体的中台通用技术服务，比如账号类、日志类、通用工具类的技术服务等。有了中台通用技术服务的支撑，我们就可以在上层去做具体业务中台化的尝试。

我们启动前端中台化的起因就是，伴随我们孵化的新业务越来越多，发现新业务中很多业务流程以及运营活动和主 App 的功能基本上 99% 都是相同的，然后不同点可能是样式方面会有些不同。另外因为涉及端能力的调用，在不同客户端调度能力有差异。所以我们遇到的主要问题就是，对于有端能力需求的 H5 业务，如何让它无缝地运行在不同客户端里面，这就是最开始的背景。

起初我们的处理方式是抽象一些适配器模块去做逻辑分支的判断，但是执行了一段时间发现当逻辑比较多的时候，到后面再改东西会比较难改、或者不敢改，因为我不确定它的影响范围会是多大。不可能为了改一个小功能，把所有已上线的 App 全部拿出来重新再回测一遍。

那个时候我们就在想，如何基于公司的中台化战略，去设计一个更好的通用服务来提高迭代效率？解决方案就是抽象一些 H5 的业务中台，每个业务中台都有一个 C 端页面和对应的后台管理功能。这样就可以动态的去控制该服务在某个客户端中的自定义行为表现。对于有客户端桥依赖的中台，我们会给每个业务中台定义一套 JS 桥 API 约定，如果某个业务或者说某个客户端想接入，它就按照我们这个 API 约定去开发相应接口来接入就好了。比如运行这个中台需要三个 JS 桥能力，我们提前把这三个 JS 桥的名字和调用方式约定好，就是说你要想接入进来，你需要在你的客户端里面去支持这三个 API 才能使用这些功能。

在此基础之上，我们会发现我们 H5 业务中台在实际接入的过程中，还是会需要每个业务做一些适配联调工作，或者说需要做一些接入层面的开发工作。基于一些开发和迭代成本的考虑，又设计了一个 H5 容器的技术中台，我们期望这些业务中台全都运行在这个 H5 容器中台里面。这样的话，只要在 H5 容器中台里面支持了这些通用中台桥依赖，刚才我说的每个业务自己去实现 API 就不用再做了。还有一个好处是，通过 H5 容器中台，我们可以很容易让新业务集成 H5 开发常用的端能力集合，比如离线包能力，动态鉴权能力，数据统计能力等。最终就实现了通过业务中台 + 技术中台组合的方式让前台业务以最快速度去接入相关的通用服务，最大化提高我们开发和迭代的效率，为业务赋能。

InfoQ：您认为前台中台化最大的挑战是什么？

宋云路：首先就是要明确中台化的边界：哪类业务要做中台化？哪些不需要中台化？其次，就是业务中台、技术中台的职责如何划分，最常见的就是端能力的依赖问题。比如一个 JS 的 API，我是在中台里面去实现，还是在业务中自己去实现，这个边界需要考虑；另外，前端中台化可参考的经验并不是特别多，我们相当于也在摸索中前进。

InfoQ：现在快手前端中台化做的怎么样？

宋云路：从业务中台方面，目前已经有接近十个业务中台的抽象，有的业务中台已经运行在大约 20 多个客户端里面了。技术中台是我们 2019 年的目标，比如 H5 容器中台我们从 2019 年年初开始开发，下半年开始上线，目前已经上线了包括快手在内的约 10 个客户端业务。

不过倒过来往回看，这里边还是有很多可以优化的空间的，主要是在协作分工上。因为前端主要承担的是表现层的逻辑，做中台的话要涉及到一些与客户端、后端的职责划分和解藕，所以其实有的中台功能是前端主导，有的是客户端主导，也有的是后端主导。

在我看来，理想的前端中台化，每个客户端只是一个载体，没有能力上的差异，各个业务功能都可以通过中台化的方式去独立运行，它们之间也可以非常灵活的组合，实现最大化的能力上的复用。

InfoQ：您认为中台这件事儿人的问题是否会成为瓶颈？

宋云路：其实是有可能的，因为中台不是开发完成就完事了，往往是一个需要长期支持的项目，所以其实这个里边就涉及到中台到底应该由谁来做的问题。可能有的公司会有一个中台的团队去负责所有中台的产出，有的公司会从组织架构上有划分。如果是从组织架构上没有划分清楚，一般我们建议就由最大的业务方去负责中台的孵化。这样的话就能保证中台的设计能够满足最复杂应用场景。因为如果是让一个比较小的业务方负责中台，很有可能他考虑的场景不够全面。所以在快手，主 App 相关团队承担的中台孵化和抽象相对多些。

InfoQ：您觉得前端中台化接下来会是大势所趋吗？宋云路：前端中台化只是中台化里面的一个分支，还是要看业务体量，所以不一定适用于所有公司。如果说业务还没有成型，复用场景还没有那么多，说明不确定性还比较多，可能就不适合做前端中台化。

InfoQ：快手的前端中台化，接下来的最大挑战是什么？宋云路：我认为挑战还是在与端结合的一些能力的抽象、复用和体验优化上，比如说如何处理端内 H5 功能与客户端能力的耦合关系等。对于我们 C 端业务，端内的 H5 页面总是免不了和客户端去打交道，那如何把 H5 和客户端结合起来去提供统一的、一致的，可扩展的能力，并且能够让业务使用得比较舒服，让我们升级迭代顺畅，这个是我们后面要去优化的。

InfoQ：除了中台，您的团队近期还有哪些正在探索中的工作？宋云路：我们在 2019 年进行过 Flutter 方面的探索，Flutter 现在在快手的几个业务线上都得到了落地。

从业务层面，因为我们已经实现了 H5 容器的端能力的统一，于是我们目前就在基于这个 H5 容器，探索中台之间服务打通的解决方案，让我们的业务方能够比较容易的去集成公司层面的整体服务。目前第一个落地的就是我们的 H5+ 客户端全链路性能监控，从客户端的行为，到 H5 的行为，再回到客户端的行为，我们会把性能的一些指标做统一封装，做一个更完整的监控解决方案。同时会通过数据分析，实现自动报警、自动预警。

InfoQ：2020 年的大前端领域，您最看好哪些技术趋势？宋云路：除了 Serverless 和 Flutter 等已经非常火热的概念以外，我个人会倾向于通过前端智能化减少重复劳动的相关解决方案。像服务的监控报警，如何让我们基于数据分析更智能的去做这个事情，而不是每次上线新业务都要写一堆报警条件、去人工检查等；另外比如如何通过 Low Code / No Code 的解决方案，帮助前端工程师节省简单页面的开发时间等也是我所关注的。

嘉宾介绍：宋云路，快手前端技术专家，2016 年加入快手，亲身经历了快手从千万级 DAU 到亿级 DAU 的前端架构演进全过程，目前主要负责快手主 App 相关的前端业务开发和架构优化。对前端中台、前端高可用性，前端性能监控、 Node.js 开发运维等方面有比较丰富的实践经验。