本人有幸于2021年5月30日在 QCon 2021 前端新趋势专场进行了技术分享，总结了此次分享《基于 Serverless 的腾讯在线教育大前端研发模式升级》的演讲内容跟大家一起交流一下。
序言
首先做一下简单的自我介绍。我是来自腾讯的工程师 haige，于 16 年校招进入腾讯 QQ 浏览器，17 年加入 IMWeb 团队。目前是 在线教育部 IMWeb 前端团队的一员，是团队的全栈研发方向的负责人。本文对有意致力于全栈开发落地的前端团队，以及有兴趣提升团队研发效能建设的同学，有一定的借鉴意义。本文观点仅限于技术交流本身，技术不分高低和对错，只有当下是否合适，而余下的非技术类的问题只是个人主观见解，有一定局限性，不代表团队。 欢迎有兴趣的同学随时找我交流，遇见有趣的人是一件有意思的事情，期待与你一起成长。
在国外互联网公司 Software Engineer（软件工程师，不区分前后端）的趋势是明显的，而在国内我们对前端和后台的概念区分得非常明确。短期国内也很难对齐国外的研发梯队，就像当下非要强行跟 Google & FB 对标研发模式和研发效能一样，本土化改造是在所难免的。和平共处五项原则在这个时代依旧试用，趋势确实在这里，落地的节奏是强求不来。当然也不需要强求绝对，合适的才是最好的，大势所趋和顺势而为是很重要的。抄袭和复制是一种逃避思考的陋习，找一条适合我们自己的路，才是能有持久的核心竞争力。
在国内互联网行业政策逐渐规范的今天， C 端用户的钱越来越难赚了。在没有现象级的产品和技术突破的情况下，短期内 C端用户的钱，确实没那么容易快速增长了，移动互联网浪潮的红利已经逐渐吃完了。在整个互联网行业都在向 ToB、ToG 转型的大背景下，时代气息就像一杯浓烈的酒——十里飘香，让你不得不沉醉其中。伴随着时代浓烈的气息，再看 “全栈开发” 这个名词似乎有了一些新意。前端全栈到底是不是银弹，在我今天看来也已经不重要了，能为产品创造价值，团队结果导向即可。 尤其是最近这一到两年我对于行业的概念的理解比以前稍微深刻了一些，就会发现垂直领域的架构师已经越来越多了。传统通信行业中售前、售后、售中的分工很早已经固化了，而传统互联网行业目前也开始逐渐向通信行业看齐了。 软件开发工程师大部分都在售中这个环节，负责项目落地和执行，以及部分售后过程中进行日常的维护和推广。
与此同时伴随着云时代的逐步落地，基础设施的逐渐闭环，垂类的行业属性会逐渐加剧。随着时间的推移，基础技术逐渐会被人们“深埋”与“遗忘”，互联网世界依旧保持着连接器的角色。通过开发工程师打通的一条条数据管道，在已经搭建好的基础设施上穿针引线，此时的基础设施跟过去十年的基础设施已经有了非常大的变化。（PS：不排除我们未来也去做芯片，但是这对大部分普通人和普通公司来说：很难！）
通过 “传统行业 + 互联网” 的模式去 “颠覆”和“重构” 一个又一个传统行业。在这样时代背景下，业务开发会更专注于交付产品功能，而远离编程语言和服务框架本身的束缚，前后端的研发模式，也会逐渐被基础技术抹平。 前后端都可以各自独立的基于现有技术体系的基础能力，独立闭环完成客户对于功能的诉求，而技术边界和分工会更加扁平化。这一切的到来已经在路上了。急促并且紧迫，似乎自己会有种“透不过气来了”的感觉，压力也与日俱增，其实这样才是刺激。今天的传统行业也不是过去的传统行业了，今天的传统行业也有了自己的技术团队，互联网公司又怎能想颠覆就颠覆呢？
我们很容易高估未来两年的技术发展，但是我们很容易低估未来十年的技术革新。所以，很开心依旧年轻着，有机会跟各位共同见证未来十年的技术发展，而且大家又都作为玩家，身在其中～未来是值得期待的。那么回到现在，我们要做的事情就是面向价值编程，让技术在业务中找到落地的价值，解决当下的痛点。这就是工程师当下最重要的事情。边界都是前人留下的，就是留给后人去打破的。 而今天要分享的全栈研发模式升级，就是在我们前端团队在构建和体会 “未来世界” 路上的一条注定要去尝试和经历的旅程。
本次分享的核心，主要从以下 3个维度聊全栈开发：
1、业务 为什么 要进行全栈研发升级 ？
2、如何基于 SCF 进行研发模式落地 ？
3、如何围绕 TKE 全栈体系持续深耕 ？
首先介绍一下部门的三款产品：腾讯课堂 for 职业教育、企鹅辅导 for K12 教育、腾讯开心鼠 for 少儿英语和思维。业务覆盖教育人群的全年龄段！目前，在整个互联网行业都在转型的过渡期，教育行业也是一个充满着颠覆与挑战的领域，并且是此时它事一个非常魔幻的产业！很开心自己在这样的赛道去感知这个世界，线上与线下之间的紧密结合，传统与现代模式交相呼应。业务挑战非常大，又那么让人充满期待。行业今天已经没有银弹的产品了，这是基本的共识！ 除非你能制造垄断，但是这基本上已经不可能了，产品未来的取胜之匙已经发生了很大的变化，很期待与新兴产业互联网模式一起成长，为职业生涯的下一个十年积蓄能量，那才是属于我们这一代人的时代。
面对问题的复杂程度和团队的品质与韧性，决定了我们旅程的有趣程度，去寻找如何解决眼前困境的取胜之匙的过程与取得结果本身，在当下对我们来说同样重要！ 因为行业的大势在变化，传统互联网的游戏规则发生了很大的改变。新规则又没有完全形成。现在最好的方式，就是去学习。曾经公司有多少抱着好产品起飞的人，因为你在哪里，你就能起飞的年代已经过去了。毕竟这不是10年前，腾讯做什么都相对可能出现成功的时候了（PS：不能说过去容易，只是概率相对比今天大）。现如今产品的每一次的成功，背后都注定包涵着鲜血与泪水的付出。所以，从 ROI 到 ROL 的是当下很重要的心态转变，保持耐心，保持韧性、保持长期主义很重要。 （PS：ROL 的 L 是 learning）
Topic 1: 业务 为什么 要进行全栈研发升级
其实我们团队的全栈研发一直在尝试。从 2015 年的 SSR、到 2017 年的逻辑服务、到最近 2020 年开始的全面体系化建设，我们一直没有停下探索全栈研发的脚步。右边是我们 2020 年前的架构图，形成了部分团队的研发规范，有一定的业务落地和技术上的探索与实践。这里主要分享一下从 2020 年以来，我们过去这段时间内的实践和总结，让大家了解一下，我们是如何成长的，同时也期待与你一起成长。
首先，团队的人数随着业务发展不断扩张，规模也变大了，让我们有人力去尝试更多的方向；其次，后台人力紧张，制约业务快速迭代，前端同学需要充当一号位，解决产品功能的问题；最后，中后台的场景多，业务并发量不高，对后台技术深度要求也不高。但是对业务理解要求非常的高，实际开发的沟通成本也很高，长此以往也制约后台同学的发展。
总结：前端同学可以通过全栈自闭环产品，不仅可以满足产品快速的迭代，也可以更多的提升团队业务中的价值和影响力。前端不是抢后台同学的饭碗，是互利互惠的事情，双赢思维很重要！
前端落地全栈，解决业务交付的问题，不仅能满足产品快速迭代，而且能提升前端本身的价值！当然，随之而来的挑战也非常明显——前端做后台，在新的技术靶场上，如何减少大家犯错误的机率，提升业务的质量和性能，就是我们需要面对的核心挑战！
Topic 2: 如何基于 SCF 进行研发模式落地
全栈开发的痛点：这里列举了很多，比如：流量、资源、扩容 等等。业务开发的本质是快速交付，而我们却渐行渐远，考虑很多基础性的问题，比如可靠性、扩展性、以及服务的性能，重复性的问题比较多，每个人都会遇到。
这里也引申出了一个问题：架构师的能力模型的讨论？ 在云时代之前，我们会造很多轮子，系统设计相对也比较封闭。比如我 16年校招进入公司使用的 TAF 框架，对外部开源的项目是 TARS，类似于阿里的 Dubble：一套微服务的框架！TAF 的框架相对封闭的，什么都自己做，网关系统、日志系统、染色系统、中心化的节点、甚至包括了存储方案，都是框架自己闭环掉了。而当下的这个云时代，是一个开放的社区的模式，架构师的核心价值变成了从过去如何实现基础组件，演变成为通过社区的组件的技术选型和定制化的落地改造，来更好地服务业务。 我们也可以用共建的模式，去回馈社区，解决行业的共性问题。云时代的架构师的技术思路，从给产品造一个发动机，变成了选择一台合适的发动机，而且这台发动机是开放并且免费的！
技术的发展，让开发者的能力模型发生很大的转变。面向未来编程很重要！
在您看完前端全栈的矛盾之后，我们看一下整个行业云计算的发展现状。从物理机、到云主机、到容器化，再到云函数；平台型产品的发展趋势是基础设施越来越厚，并且趋近于标准化。业务开发者的角度，服务会变轻、变薄。一线开发者越来越聚焦业务本身，开发更加专注于业务价值，而不是那些不重要的目标。 Serverless 这样的技术，恰好可以满足我们的业务场景，解决业务共同的痛点。
Serverless 拆解一下：server + less，服务 + 少，首先不是没有，是减少！Serverless 是指构建和运行不需要服务器管理的应用程序的理念。 它描述了一种更细粒度的部署模型，该模型将捆绑为一个或多个功能的应用程序下载到平台，然后根据当前所需的确切需求执行、扩展和计费。而广义的 Serverless 就是减少服务端运维的解决方案。
我们看下 Serverless : 无服务器架构。触发器，函数实例，调用后端服务，当云函数平台接收到触发函数的事件时，将会启动一个容器来运行函数代码，如果此时接收到了新的事件，并且上一个容器还在处理上一个事件，平台则启动第二个函数实例来处理第二个事件。用完即走的模式，保证了每个请求都是独立的、足够原子的且安全的。
在用与不用的边缘上，我们也进行很长一段时间的纠结，这里就不分析具体的过程了，过程也比较曲折，但总是要有人去尝试的。最后，我们还是选择了使用 SCF 去落地！SCF 是 Serverless Cloud Function ！针对 Serverless 的产品，我们也讨论了很多轮，针对使用哪种产品，我们也做了大量的调研，这里就不一一细说了。当然，在腾讯，肯定也不能选择阿里云或者 AWS 的产品。技术选型是有些局限的，如果你所在的团队是创业公司，你可以横向的去对比。
业务上我们也找到了突破口，从中后台业务开始着手，中后台业务对于稳定性要求，不如 C 端用户那么高，业务上有一定的容忍度！中后台业务对后台开发同学来讲，也缺少技术挑战和提升，后台同学也愿意让前端同学去承接；那我们前端接，做为全栈开发落地的突破口，从并发量不高的需求开始接，逐步渗透到 C 端；其实，大前端团队本身也是在一个不断学习和成长的过程当中！
在实际落地 SCF 的过程中，我们也发现了一些问题，如上图。当然业务方也要有开放的心态，与兄弟部门一起成长。互相学习和共同成长才是合理的思维方式，要相信办法总比问题多，事实也是如此。
Git 天然就是规范的载体。比如在一个 Group 下面，项目是不可能相同的。这样就可以解决同一个命名空间内，函数相互覆盖的问题！我们还将云函数的能力，进行了定制化，比如：它的 last 版本，就是我们业务的测试环境，包括网关，我们也做了一些自定义的规范；简化开发流程，完成了 CLI 脚手架的开发，一次性的熟悉成本，一体化的研发环境，屏蔽了大家的学习成本；再就是我们把云函数的 CI/CD 集成了进来，最终完成了整个 DevOps 的流水线。围绕着最基础性的原则和工具进行建设：云函数、CI/CD、闭环 DevOps。这里我理解就是一个原则：围绕着基础性和原则性的目标进行不断的优化！
通过拆解问题和细化问题的方式，进行逐个击破。而解决问题本身的思路并不复杂：标准化、工程化、自动化即可。
这里通过制定团队新的规范进行业务落地。经过整个团队一年的努力，几十个核心服务都已经逐渐搞定了。
通过打造 CLI 的工具解决开发效率的问题；通过网关和云函数本身提供的能力如：预留实例和保活机制进行质量落地。其实这也是一个不得已的过渡方案，历史总是在妥协中前行。网关方案团队也在逐步优化中，后续迁到 CLB 和 TAPISIX，会有一个新的形式，不过迁移过程会是比较漫长的过程。
PS: 目前教育前端云函数使用的网关是 NGW，支持了几乎所有的云函数的流量，包括我们的低代码平台搭建出来的后台接口，服务了很多 ToB 场景的业务，每日访问量在 300W 上下。这里也感谢 PCG 的 jsonsun 同学一起协同共建。
图中已经比较明确的总结 SCF 落地的工作。先制定了规范，然后完善工具链，逐步打通研发的流程闭环， 在过程中逐步解决。流程上是：先保证业务最小可用，明确技术投入可行性，然后再逐步解决各种瑕疵，让开发工具好用，最后再体系化建设和团队内部推广。
Topic 3: 如何围绕 TKE 全栈体系持续深耕
在落地完 SCF 之后，业务逐渐有了更多的需求，SCF 无法安全满足所有业务诉求，此时 TKE (Tencent Kubernetes Engine) 就登场了。下面一张图介绍了 TKE 的概念和优势。而且也恰逢公司上云的大背景，我们也就确定了选择 TKE。我相信公司内还是有很多通用的后台架构可以落地业务，但是最终我们还是选择了 TKE，有时候技术选型和技术决断就是那么几个人的故事。
这里可以看一下我收集的 TKE 的优点，好多呀。其实刚接入的时候，问题也不少，目前已经逐渐在解决了。上云对于业务来说是一件工作量不小的事情。前端同学还好，历史包袱比后台轻很多。目前，经过一年的时间，我们所有的核心 Node.js 服务都已经挪动到了 TKE 上。
这里对比了一下 SCF 和 TKE 容器上面跑的 Node.js 服务的区别。本质上 SCF 作为函数服务的 FasS 是希望事件触发之后的函数执行完成之后，容器就可以销毁了，这样程序所需要的执行环境就没有了。所以，作为后台服务最常用的内存缓存能力就没有了。而传统的容器服务也就是 BasS 服务，进程是常驻的，可以保存有状态的和长链接的数据，也可也通过内存缓存的能力，提升服务的并发数量。虽然有优点，但是也会遇到常驻服务的内存泄漏，程序突发异常的死循环导致的 CPU 100% 这种场景的增加。所以，当面对有状态的、高性能、更加灵活的场景，可以使用 TKE 的容易来承接服务。
前端运维 TKE 的挑战跟我们去关注传统的页面运维也差不太多, 主要是：性能、监控、告警、压测！其实维度是一样的，只是面对的场景和解决的问题重点有所不同。而且无论是从 SCF，还是从 CVM 迁移到 TKE 的 Node.js 服务，本质上也只是换了一个运行环境。因此我借用了 “新瓶装旧酒” 的概念，来阐述开发者面临的挑战。当然，核心的问题，肯定是要解决成本的问题！ 成本是一切软件服务的基础。
首先，将成本进行拆分，通过效率 + 性能 + 质量这一个纬度去衡量；其次，基于这三个大的目标，拆分了三个方向：研发框架、开发工具、业务治理的第二维，从而找到落地的基准；再次，基于可落地的第二维度，拆分了 12个更细粒度的子方向，进行逐一击破，分步实施。后续还是会沉淀一些中台化的方案和积累团队的技术分享，进而提升团队的综合效率和整体技术。
在研发框架的这个维度，我们核心关注的是 框架 和 生态！框架的基础是规范，从规范入手，开始落地团队的研发规范。目前的规范还在逐步形成和不断迭代中，毕竟罗马不是一天建成的，几代人逐步完善和不断修建的斗兽场才有了今天的恢弘和伟岸。做规范也是一样，落地实施的过程中抓大放小，先解决最核心的问题，后续再逐步演进即可。 而后是将规范落地在框架当中，不论你采用的是 Egg，还是 IMServer，其实这不是最核心的关键点，重要的是大家认同并且持续维护和遵守。而后在基于场景和业务定制一些工具化的基础组件和业务组件来提升大家的开发效率。基础组件的全面和稳定，其实也就到标志着一个团队在这个方向上积累的成效初具规模了。而后就是根据业务场景进行能力落地，在业务落地过程中会有一些服务化的中台出现，进而沉淀成中台化的服务，阶段性地去支撑部门内的业务。
全栈开发参与的同学非常多，为什么要拉着这么多人做？我理解不仅是后续推动接入的时候方便，更重要的是大家一起去尝试过一些事情之后，才能促进大团队不断融合。 毕竟 100个人以上的前端团队，我自己也是第一次经历如此大规模的软件开发组织。假使后续公司出现了统一的全栈规范可以接入，那我们依旧可以快速的接入和适配，即使现在的规范在未来被替代，我们在落地和探索的过程中，也学习和积累了充足的经验，会成为团队未来成就的基石。
这里可以看到所有接入规范的服务，我们都会自动化的生成右侧基础统一的视图。业务如果需要自定义，当然也是可以的。数据上报前后端统一，也相对保证了问题定位的效率。左侧的列表可以看到我们服务接入规范的进度和预期的时间以及责任人，这样方便大家可以在预期之内解决战斗。当然，很多时候单纯靠技术做不到的事情，也可以通过管理来辅助。有的时候软的不行，也可以来点硬的。
效能工具就是帮助开发者串联起开发域、测试域、运维域的效能支撑。这里罗列了一些工具，分别解决的是不同环节的问题。有些是开源社区提供的，有些是公司内优秀的框架和方案，有些是我们自己研发的。当然，谁做的在我看来也不是那么重要，都是阶段性的工具，核心是服务好当下的开发同学，让一线开发者幸福才是最重要的事情！ PS：回归本质解决的是开发的问题。
调试工具 tolstoy 在逐步支持了 RPC 的 Mock 能力，会更好的服务大家。坦白讲做一个 tolstoy 技术上对大家来说，并不是一件多么复杂的事情，重要的是我们要长期坚持并且持续性的维护下去，这才是最重要的。团队的同学们已经准备好了，尽可能的去孵化它。PS: tolstoy 是我们内部的前后端联调工具。
Nohost 支撑前端，已经在公司和业界被广泛认知了，其实它也也可以支撑服务端的路由转发，辅导和课堂的 Node.js 服务，目前已经在 Nohost 提供的 Node.js 研发环境上正常的使用了。Maybe，未来我们可能接入一些 Mesh 的方案去替代它，但是短期内通过 Nohsot 支撑部门 Node.js 服务测试环境调试的情况，还是会持续一段时间的。
监控这里参考了 TAFNode、Alinode 的行业方案，部分数据使用了云监控以及我们自研的 IX 系统，为大家做服务的保驾护航。日志目前都集中在 ELK 上面，有一些被中专到放到 Prometheus 上方便计算和持久化。
从服务的主调和被调、到接口的时延和返回码；从数据库的慢查询，到 Redis 的大 Key 读写，以及 kafaka 的队列长。我们跟后台同学一起深度的了解和学习了监控的指标和落地实施的细节，并且将监控出现的问题和 TAPD（TAPD 是 Tencent Agile Product Development 的缩写，即腾讯敏捷研发协作平台，凝聚腾讯十余年团队协作理念与敏捷研发实践精髓）打通，做到了流程的自动化。从监控发现问题，到问题的分发、处理和跟进，以及修复之后的反馈，定期的数据统计，都进行流水线的处理。这里也很感谢后台同学 simon 团队的大力支持。
上面是通过星海平台进行服务压测，IX 进行问题定位后的一个业务案例。在一定程度提升了服务的 QPS ，减少了机器，节省了业务成本。后面我们会持续加大在自动化测试的投入，通过红蓝火焰图的形式，服务大家更快的发现和定位问题。
这里分析了成本是如何被逐步分解和消化掉的流程。分类之间是有一些交叉和重叠的。比如 IMServer 的基础框架，它既可以解决开发效率同时也可以提升业务质量。这里我就不一一逐条讲解了，相信以大家的能力，读文即可达意。PS: IMServer 是内部 Node.js 服务框架。
最后再总结一下 IMWeb 团队全栈研发的架构图，介绍了团队过去一段时间尝试和沉淀的一些思考，后续还是会持续改进和不断革新的。全栈研发的形态会持续化从生根发芽到茁壮成长，进而枝繁叶茂的出现在大家的面前。希望后续有一些更好的落地方案与各位分享。
Topic 4: 下一个路口，在哪里？
这里我选择了四个基础的主题： WebIDE 的云端一体化建设，在未来还需要持续性的探索，也许基于 VSCode 的插件生态在未来完整支持云端一体化也未可知。 其次是 TF，上半年在业务中跟智平合作了2个项目，一个是 AI 推题，一个是 AI 智能批改，以及我们自己做的注意力识别检测。未来会在更多的场景中落地和使用到机器学习的能力。 低代码已经甚嚣尘上了，市面上看到的都是做的浅层低码的平台，包括我们自己的低代码也只是解决特定场景问题的产物。希望在未来能看到真正的低码平台的落地，D2C 今年我们也会尝试落地一个版本，万分期待中。 最后，我选了一个 WASM 作为结束。看起来 WASM 跟全栈关系不大，Node.js 最被后台开发诟病的就是性能问题，就好比写汇编的还觉得 C++ 不够牛X一样，不同时代都是有鄙视链存在的，已经 2021 年了，软件开发的模式发生了很大的变化，收起傲慢与偏见吧，更合理的技术选型才是最重要的。当然，这里表述的核心是通过 WASM 可以引申出浏览器端的性能优化和服务端语言 RUST，未来都是非常值得期待的。
总结一下分享的内容，全栈开发的历史必然性是由于技术发展的趋势决定的。人力成本在未来会逐渐高于机器成本，如何让工程师们创造更大的价值呢？打破工程师的边界，基础设施能力补齐后，让开发者逐渐消除技术壁垒，无论是前端同学，还是后台同学都可以通过平台提供的能力完成产品的闭环。而且无论是前端还是后台，都是希望在未来提升技术族群本身的价值。任何一个技术的水平拓展和延伸带来的绝不仅仅是技术革新和工作分工，同样也会带来组织内的变革。
也许未来全栈研发会换一种形态去发展，但是一定会持续下去，希望后续在组织内会有一些新的生长，到时候再跟大家继续分享。自己在跟着团队落地和学习的过程中也学习和思考了很多，非常宝贵的经历！在一个人数 100+ 的前端团队有机会参与和推动这样的事情，本身就很运气，感谢领导给这样的机会。我们始终要在技术上保持好奇心与热爱，并且保持好的心态，持续性的投入技术建设当中，逐步完善功能的迭代。总有各种问题会或多或少的影响着我们的生活，但是我们要始终保持耐心与团队韧性，没有一帆风顺的故事，只有不断经历的事故，在落地的过程，心态上要保持克制和长期主义的精神。
PS ：写在最后，要感谢一下 IMWeb团队的 每一位参与的同学，团队有非常多参与的同学，几十个人进行开发和迭代，这里就不一一感谢了，感谢 IMWeb Team All Player ～ ♥️ ！
