前端架构体系调研整理汇总

1.公司研发人数与前端体系

 小型创业公司

• 前端人数： < 3 人

• 产品类型： 产品不是非常成熟，比较新颖。

• 项目流程：不完善，快、紧促，没有固定的时间排期。

• 技术栈： 没有历史包袱，技术栈较新、无前端架构师甚至无高级前端。

• 项目安全：几乎不会额外考虑安全性。

• 基础设施：几乎无。

• 系统可用性：几乎无具体标准。

• 前端工程化： 使用业界方案，怎么快怎么来。

• 学习氛围：自学。

中型创业

• 前端人数： > 20 人

• 产品类型： 公司有自己较成熟的产品，有一定的用户量。

• 项目周期：快、紧促，有大概固定的时间排期，时忙时闲。。

• 技术栈： 没有历史包袱，技术栈较新、有前端架构师或者 teach lead

• 项目安全：考虑一些简单的安全问题，例如 sql 注入、xss、csrf 等，依赖第三方库。

• 基础设施：错误监控、日志收集、代码回滚三件套。明显的体验就是有时候做新功能或者改 bug 的时候一不小心就把之前的代码改炸了。

• 系统可用性：几乎无具体标准。

• 前端工程化：使用业界方案，用文档来做规范化和沉淀，会有一些跟业务无关的技术需求的沉淀。

• 学习氛围：自学 + 讨论。

传统 500 强企业

• 前端人数： > 50 人

• 产品类型：产业转型，大多数是内部产品，例如一些 saas 产品、对内使用较多。

• 项目周期：处于行业转型，较快、较紧促，有大概固定的时间排期，时忙时闲，或者是都挺闲的。

• 技术栈： 有历史包袱，技术栈较老、技术栈多，会有前端架构师或者 teach lead。

• 项目安全：定期会请专门安全团队做安全检测。

• 基础设施： 会有 A/B test、数据埋点。会尽量去避免出现错误，流程还是没有达到规范化，明显的体验就是不敢重构，不敢升级依赖，不敢更换系统，不敢接锅，能跑起来就行。

• 系统可用性：没有或者 3 个 9

• 前端工程化：使用业界方案，用文档来做规范化和沉淀，缺少自己内部的前端定制化工具库、组件库等。

• 学习氛围：自学 + 讨论。

百亿级别公司

• 前端人数: > 500 人

• 产品类型：多个成熟的产品，且成为行业龙头或者独角兽

• 项目周期：两周一迭代，项目紧，较紧促，有大概固定的时间排期，时忙时闲，有项目间隔期。

• 技术栈： 有历史包袱，技术栈较新、技术栈多，会有前端架构师或者 teach lead。

• 项目安全：定期会请专门安全团队做安全检测。

• 基础设施：主要还是配置化、工具化、完善的基础设施，会考虑性能问题，能在客户发现问题之前，就发现部分问题，能快速定位问题，并解决，明显的体验就是有专门的团队去维护这些标准或者操作流程，原则还是人操作工具来提效，去约束人。

• 系统可用性：普遍 4 个 9 以上。

• 前端工程化： 用文档和工具结合做到规范化、例如代码规范、代码校验、代码测试覆盖等等，能沉淀出一些流程脚本，代码库、工具、经验、脚手架。

• 学习氛围：每周分享，了解各种前沿技术。

• 2.前端整体架构方案

• 前端架构概览图

• 前端工程化体系

• 3.混合开发方案

  • 混合开发多端一体化方

  • 美团整体架构体系

  • EH - 增强型Hybrid框架

  • EH - Enhanced Hybrid框架是美团金融研发的针对Hybrid业务场景的增强型框架。Hybrid实现虽然在研发效率上有很大优势，但同时也存在大量的用户体验问题。

  • 页面白屏问题，无法做到原生页面在切换时候的流畅度。白屏问题的本质原因在于原生页面切换到Web页面时候，Web页面这时候还未加载渲染完成，因此会导致白屏问题。解决方案就是在当前原生页面中通过一个不可见的webview将页面进行加载，当webview页面完全加载完成后通知原生页面然后进行跳转。

  • 离线化技术，通过资源离线化，线上增量更新，实现页面的加载性能提升，接近于原生的渲染体验。

    交互一致性，由于SPA的前端系统在页面交互上难以做到原生一致的体验，例如左滑回退操作等等，EH TransPage通过使用Native导航结合SPA页面实现，在交互体验上和原生保持一致。

    一体化配置，前端页面在Webview中缺乏对外部宿主的有效控制，例如导航栏样式、状态栏文字颜色等等，EH Config提供一套接口可以让前端页面灵活进行配置，实现视觉一致性。

    下图是EH的整体架构图：

  • 4. 典型案例汇总

    • 美团点评

    • 美团点评是一个多业务形态的平台，各个业务发展阶段和技术诉求都不尽相同，因此前端技术在美团点评各个团队中百花齐放，诞生了众多的解决方案。下面我分享一下几个代表性团队的前端技术体系。

    • 酒旅团队

    • 以上是酒旅前端团队的技术体系结构图，我们有两种共存的项目类型（静态化项目和服务端项目），静态化项目是通过CDN进行承载，使用Vue进行功能开发，同时借助移动端样式组件库提升开发效率，通过离线包机制和KNB (Native Bridge)增强页面在容器内的表达能力，最后通过AWP（自建的静态化发布系统）可以高效的进行上线部署。

      服务端项目不同的是使用NodeServer进行承载，前端通过AngularJS/VueJS进行功能开发，同时配合NGUI（AngularJS样式组件库）快速进行页面搭建，Node端框架选用的是Express，服务的部署通过OPS（内部的运维发布系统）完成。

      人机识别服务是我们在前端角度设计和开发的一套安全机制，它包含前端SDK和基于Node实现的验证服务，可以用于接口的防抓取、防止接口被第三方非法调用等场景。目前线上接入的业务平均拦截率在30%左右，接口TOP90的响应时间在9ms以内。

      构建工具栈中我们通过Yeoman开发了团队的脚手架，开发者可以通过脚手架快速的进行项目搭建和组件开发，通过Gulp和Webpack进行项目的构建和打包，NPM作为团队统一的包管理工具，Sass作为CSS的预编译工具提升CSS代码的可维护性，Babel作为ES6的编译工具，ESLint作为团队的代码检查工具保证代码的规范一致，并且接入了Sonar。同时借助一些开源的自动化测试工具提升开发阶段的代码质量。

      监控体系中Sentry用于线上错误信息的收集和监控，Perf平台用于Web端性能数据的收集，灵犀用于业务的统计和埋点，Falcon一方面用于Server的监控报警，一方面用于业务监控和报警（比如火车票的抢票失败率和接口调用情况），PM25是我们自建的一套针对NodeServer进程粒度的开源的监控报警系统，用于确保线上Node服务的稳定性。

    • 5. 目前公司前端架构

      • 前端架构体系图

      • 基础设施：云端能力成为各大互联网的基础能力，可以想象未来云端会越来越强大，可以提供更多标准化的能力，前端可以自主做更多的事情。

        服务层：BFF/SSR是前端服务层的主要作用，从技术栈而言，Node->GraphQL->Serverless会是一个大趋势，尤其是Serverless的出现让大家看到前端更加独立放飞自我的可能性。

        应用层：在前端三大框架React、Vue、Angular之上，形成了一系列强约束性、架构标准化、插件化扩展的应用层开发框架，这类应用框架的出现对于大厂技术栈能力沉淀起到非常重要的作用。

        UI组件库：组件库不再是简单的UI组件的封装，而是一套完整的设计语言。同时随着端的丰富，组件库也从PC端来到移动端、小程序，形态上也更多出现了数据可视化等更为丰富的表现。

        跨平台动态化：跨平台和动态化始终是一个关于研发效率与用户体验如何平衡的热门话题，不论是Hybrid的Web容器增强还是RN、Flutter这类虚拟运行环境的解决方案，都有着不同的应用场景。在国内，对于研发效率和动态化能力执着追求下，在用户体验妥协下，RN、Flutter技术得到长足的发展，RN目前已经进入了成熟期，各大公司的基础建设也相对完善；Flutter则是当红炸子鸡，处于技术泡沫期，但其未来前景有可能更好，其跨平台的愿景更为宏大，未来可期。

        工程智能化：大前端研发早就进入到大规模、多团队协作的工作模式，因此工程化的基础建设对于研发效率、规范落地、线上异常性能监控等方面都起到非常重要的作用。目前阿里在云端化的建设，例如Web IDE、云构建等，进一步提升了前端工程化的能力。同时前端智能化这个方向也非常热门，在Pro Code/Low Code/No Code三个方向都有很多突破，前端同学在自我革命的道路上越走越决绝了。