导读：前端发展飞速，从最开始的静态页面到JavaScript，再从PC端到移动端，随着大前端的复杂度不断提升，很多公司开始前后端分离，剥离出前、后端架构设计。那我们来看看，前端架构设计是什么？曾经非常简单的前端架构发展到现在有哪些问题，遇到前端代码体量巨大、跨团队协作效率、代码耦合、技术栈落后等问题又该怎么解决？
一、什么是前端架构？
前端架构这一词，相信很多人的定义都不太一样；按照拆词的解释来看，我理解为“前端”+“架构”。前端是指，Web端的前台页面，包括网页的内容、样式、脚本等，这三者通常封装在组件中，可能是模板引擎的文件模块，也可能是MVVM框架里的组件。“架构”就更好理解了，架构一词来自建筑行业，可以理解是房屋的整体结构、框架。结合前端和架构的概念，“前端架构”可以理解为，Web页面组件的抽象和组织方式。
又因为各个公司的业务不同，每个公司的前端架构发展都不一样，这里，我会拿百度移动端经典的搜索场景来给大家举例，希望从百度的移动端架构演进过程中，发现一些共性的问题。
二、百度移动端背景及问题为什么是以百度来举例？是因为百度是国内搜索引擎的领头人，并且，目前一直处于行业领先状态。据statcounter前瞻产业研究院在年中国搜索引擎行中可以知道，百度搜索占全世界搜索引擎市场份额12.3％，居第二位，仅次于谷歌。所以用百度来举例，更具有代表性。
言归正传，打开百度App你会发现，百度前端直接分为首页和搜索结果页，搜索结果页是搜索的主要入口，每天承载着十亿级流量。
不仅如此，搜索结果页承载着许多产品线的需求和下游模块的运行时，每年内部的研发人员会提供五百多个产品需求，为十几个下游模块提供基础库和运行时。甚至还有后端协同，从图1我们可以看出结果页的整体架构。
△图1：百度搜索结果页的整体架构
针对整体的架构设计，有这些问题：
细分业务线众多，单个库代码庞大；平均每月有+提交，3w+行代码；80+开发者在同一个代码库中开发；没有人能完全掌握模块整体技术。
于是，梳理出三个方面的问题：
1.人员职责不清晰，单个模块同时承担了多个团队的职责
框和Tab：“全部”和垂类搜索共用；运营产品：渗透在结果页代码库里；其他：结果列表、用户反馈、搜索推荐、体验日志、速度日志、计费逻辑……2.代码耦合严重
容易出错，代码逻辑脆弱；结构僵化，不易新增功能；依赖牢固，代码很难复用。3.技术栈落后
页面没有组件化。没有Vue、没有React，还在用Smarty模板；无法支持Node.js。Smarty模板强依赖PHP环境；工具链落后。没有TypeScript、没有Jest。
这三个问题最终会影响到研发效率以及产品质量。那么百度又是怎么去具体做的呢？架构优化的目标只有两个，一是满足业务需求，二是技术上能对框架和工具灵活升级（也是为了持续的满足业务需求）。根据“满足业务需求”这一目标，百度内部是制定了三个层面的方向。（如图2）
底层基础层是贴近社区，因为据内部调研来看，造轮子的成本不高，但是维护这些轮子成本极高，如果想更快的迭代，还是建议贴近社区，去用些开源的事情或者去贡献开源。主要是解决技术栈落后以及职责不清晰等问题。中间层是独立模块，主要是应对之前提到的职责不清晰的问题以及交付效率低等问题。主要是解决职责不清晰以及交付效率低等问题。顶层就是组件化，在独立模块的基础上去做组件化，加速业务的迭代。
△图2：业务需求的三个方向三、怎么解决
根据这里提到的方向和目标，怎么结合百度自己的架构落地呢？首先，回顾下百度的架构，如下图3可以看到。
△图3：百度搜索结果页的整体架构1.这里有两块日志，意味着同一套代码要在两个部分维护；除了重复之外，它们的差异会对后续的维护引入更高的成本；
2.底层这个HHVM+PHP和社区更加拥抱Node.js会有冲突。
所以，百度同学把目标架构调整为图4所示。
△图4：结果页的目标架构图4中可以看到：
把日志、搜索框、相关搜索、性能打点等独立成单独的模块，有专门的同学来独立维护和迭代；在前后端之间加了一层渲染层；让业务代码和后端的逻辑分开；在底层加了Node.js机制。目标、方向都解决好之后，就得看如何实施。对于一个小体量的库来说，从零构建架构就行；但是对于百度来说，实施也是难点。不仅要考虑平滑迁移、性能不退化，还要考虑长期可维护性、安全性、跨平台等。
前文也提到了，基本思路是按照基础设施、模块拆分、组件化的步骤执行；基础设施是业务模块划分的关键，完善的自动化和工具链是模块化的前提；模块化拆分可以为业务和团队提供更好的横向扩展能力；模块化的基础上，可以进一步在模块内部建设组件化方案来加速业务迭代。
在基础设施需要