我脑海中的前端架构师

什么是前端架构

最初浮现在我脑海里面的就是软件架构… 做些什么呢？

• 对涉及的项目、系统等做一系列的抽象，抽象出可以通用的框架结构
• 为软件提供一个结构、行为和属性的高级抽象，有构建的描述、构建的相互作用、指导构建集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且制定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理（来自百科）。软件架构要易于理解和开发，要保证可扩展性、可维护性、适用兼容性、鲁棒性、低耦合高内聚、对业务尽量少的侵入性等。

常见的软件架构有：

• 分层架构（Layered Architecture，表现层presentation、业务层business、持久层persistence、数据库database。）经典的三层架构，并不是MVC的三层，而是这里的表现层、业务层(包含持久层)、数据库，MVC是表现层的一种架构模式，除此之外现在常用的Vue、React实现的MVVM也是表现层的一种架构/设计模式。
• 事件驱动架构（Event-Driven Architecture，事件队列event queues、事件分发event mediator、事件通道event channels、事件处理event processors）观察者模式的实现
• 微内核架构（Microkernel Architecture，一个核心系统和插件集模块）
• 微服务架构（Microservices Architecture Pattern，分开部署的独立子服务单元separately deployed units、网络请求通信RESTfull API
• 弹性云架构（Space-Based Architecture业务处理单元、虚拟中间件[消息中间件messaging grid、数据中间件data grid、运算处理中间件processing grid、部署管理中间件deployment manager]）
• 无服务器架构（Serverless，Faas函数即应用 + Baas后端及服务）

在这些架构的演进过程中也伴随出现了许多新的业务类型IaaS、SaaS、DaaS、PaaS、Baas、Faas…
如果你是一个Server端的程序员，可能会反感前端架构这个描述，觉得前端没有什么架构可言，前端这群孩子太能闹，太浮夸。这些架构涉及到的一些构件可能在过去理解的前端边界里面没有，但核心思想是相通的，目标也是一致的：让开发者更加专注业务开发，NoOps化，以解决业务问题为核心导向，技术不是目的，技术思想不应该有边界。

前端架构师做什么

是不是知道上边那些NB的架构就一本万利了呢？是不是每个业务或团队一开始就要去是去实现一个庞大的架构框架呢？这里更推从贴合业务适当超前的架构，做的太通用会带来很多不必要的分支开销，做的没有扩展性则支撑不了业务发展更迭。

狭义 设计和实现对应软件的架构

广义(现状) 除了狭义的还包括以下我在团队建设及管理中随着业务及业务架构发展不同阶段所做的所有技术相关工作，及展望。

其实前端团队中不一定有架构师这个职务，但是每个团队发展到一定的阶段一定需要一些人去做这些架构上的事，从业务出发，为提升团队整体效率产出而不断探索。

初创阶段 (看山是山看水是水)

keywords: [代码复用, 模块化, 快速迭代, 角色穿插, MPA, SPA, PWA, MVC, MVVM]

特点: 初创阶段可能职能角色并没有明显的区分，做的事情主要支撑业务的快速迭代，对普通开发者基础知识要求较高，对核心开发者知识广度较高（有从0到1的能力），也有可能只有一个人。产品形态和方向不确定，基本需求是什么就做什么，过多延展性的考虑可能在较快的业务变化节奏下很快就不适用。

做什么: 这个阶段架构师的作用并没有太多突显，但这个时候已经开始接触架构了，可能在技术选型和项目结构上需要一定的预判预设才能保证在将来一段时间支撑业务的发展。基本的模块化、前后端分离、基础组件和框架选择，utils通用工具等，目的是保证技术对快速迭代的业务支撑。根据不同的业务场景选择不同的项目架构模式，如MPA, SPA, PWA(App Shell)…；应用分层架构模式MVC、MVVM…

思考: 业务产品探索初见成效，产品和人员增加后怎么协作。

多人协作 (看山是山看水不是水)

keywords: [流程统一, 规范制定, 质量监控, 构建部署, 性能优化, 安全管理, 组件抽离]

特点: 业务探索初见成效，方向基本确定，产品上可以做同类的扩展。技术上表现缺什么做什么，或者做到哪抽象到哪，也没有过多可预见的业务架构引导。（团队可能根据技术方向已经有不同的小组，移动端、官网运营、业务逻辑、基础组建、nodejs等这样技术方向的区分）

做什么: 人多了，团队里面每个人都可能有自己独特的观点和节奏、编码习惯、技术认知等组建团队的时候并不能避免的一些小问题。要让大家协作起来才能干大事，力往一处使才能创造更大（1+1>2）的价值。这时候统一流程，制定合理的规范不仅让大家做事有据可依，更能有的放矢，各展其长；人员多了代码的量和出现冲突的情况也增多了，代码质量需要保证，项目运行时的质量也要有保证，项目的质量监控不可或缺；保管用户的数据就要保证用户数据的安全，公司产品上线也需要保证对社会的影响，安全管理不容忽视；业务多了，通用的功能也可能不能满足或不便于处理现有的业务，定制化或扩展的组件抽象，形成组件库。

• 统一流程：涵盖从开发到上线的流程，这里的流程并非不可僭越的框架，参考引导为主。《新需求对接流程-[产品/运营/技术]》《code review流程》《联调流程》《提测流程》《上线部署流程》《故障处理流程》《项目安全审核流程》等
• 制定规范：从开发到上线中一些需要保证质量，保证稳定性的规范。《分支管理》《code规范-[js/css/vue等]》《线上问题处理规范》《新人答辩规范》等
• 质量监控：根据规范通过人员和工具等约束。codereview、部署过程监控，运行时脚本监控，其他服务稳定性监控等。
• 构建部署：dev环境、test环境、pre环境、线上环境的构建部署，构建脚本和工具搭建，部署脚本及工具搭建
• 性能优化：从浏览器工作原理出发，做高产低耗的提高效能的事。资源打包和加载优化、渲染型优化、计算型优化，除此外还有构建部署优化，服务接口优化等
• 安全管理：项目中的安全防护措施和安全审核必不可少。
• 组件抽像：基础组建，业务组建逐步抽象剥离。
  …

思考: 准备孕育出更多产品业务线后，怎样去提高整体效率

平台化阶段 (看山不是山看水不是水)

keywords: [解构重组, 抽象分层, 标准化, 通用模型, 微前端]

特点: 已有可持续发展的业务，并通过这些业务拓展出了其他业务线，业务架构的调整促使我们不得不调整人员组织去做不同的事。看起来被动打乱了，实际也被拆解了。（这个阶段根据不同的业务架构有所不同，有的可能没有这个很有意思和挑战的阶段）

做什么: 我们能做的事是去重组，这里并不是简单的把人分到不同的子业务线做不同的产品业务就完事了，我们还是一个团队，需要提高整个团队的产出战斗力。为了更好的复用以节约成本提升效率，这时候需要一些人来做平台化的东西，需要深入到业务架构中抽象分层，去格式化并标准化一个子业务线，去思考和架构出一个能普适的通用模型，甚至可以延展到其他部门或业界的通用解决方案。

平台化要做什么呢？平台化不止是在代码上的抽象分层，从人员职能、技术分层，做标准化，通用化的一套服务体系。包括接入规范及培训、加强前面阶段产出的工具、流程、质量、安全、性能、构建部署、基础和业务组件库等的通用化标准化建设，没有的需要补上。这大概是一个把80分做到90、95的过程。

平台化阶段要解决的问题是多个团队及业务线项目间的拆分和融合的把控，不同技术栈的融合，这时候可能引入微前端的概念(目标：技术栈无关、独立开发、独立部署，技术栈无关就意味着不同技术栈的的代码可能会在同一个运行时环境执行，需要解决js/css的隔离、子应用间切换及加载与卸载、资源管理，应用间，应用与平台间的通信等问题)。常见的微前端架构实现方式：

1. 不同执行环境

• 配置路由： 平台层提供注册机制让各业务线可以在路由层做跳转（前端路由或者静态服务层路由nginx或后端路由，这样的好处是简单，轻松应对不同技术栈的业务线，且不用处理样式和脚本冲突等问题，但跨业务线间的通信会比较麻烦，且相互跳转通常会刷新页面）
• 配置区域iframe： 平台层提供平台公共区域的渲染，管理平台与业务线iframe，业务线iframe与业务线iframe之间的通信衔接(这样解决了业务线之间跳转刷新的问题，但iframe之间的通信及路由处理起来也相对麻烦，且页面中多个iframe对性能也有一定的影响)

2. 相同执行环境

• 相同技术栈： 平台提供平台架构及基础代码，其他业务线应用以submodule的形式作为主框架应用的一部分，约定各子应用的js和css命名空间，避免对全局公用区域的干扰(优点是基础组建，模块等可以共建，跳转切换也比较流畅，缺点是人为约定容易出错，需要建设工具来监控代码，以及技术栈限制)
• 配置区域Web Component： 平台层提供平台公共区域的渲染，管理业务线组件的加载与卸载，随着WebComponent技术的成熟，一些生成工具Stencil等也随之出现(优点是组件样式代码是浏览器级API ShadowDOM的隔离，缺点在于现有框架需要转译成WebComponent的书写方式，及兼容性)

可以看到上面两大类方案，不同执行环境固然有很多好处，但性能或体验上会打折扣；相同执行环境目前的技术发部分只解决样式冲突的问题，js执行环境的隔离还需要进一步探索。

思考: 我们在解决一些问题或者优化等时在浏览器侧可能出现了瓶颈，我们需要跳出别人对前端的束缚，我们是技术人员。

跨越融合阶段(泛前端) (看山不是山看水是水)

keywords: [Nodejs, Native, BFF, SSR, GRPC, GraphQL, Electron, Serverless]

特点: 刚打开别人给自己施加的前端枷锁，开始跨越过去技术领域的瓶颈，初尝我是一个技术人员的自由。看不清前端的界限，用技术解决问题。

做什么: 秉承谁受益谁做的优良传统，我们出现一些BFF分层架构的尝试(多了这一层，前端可以控制的更多了，GraphQL也可以推进了)；更充分的权衡价值后可伸缩地回归SSR的尝试(同构)，对于静态的可以直接在构建过程中渲染模板；为了降低成本一码走天下，我们在移动端用过hybrid，为了提高性能我们有weex，有react-native，还可以换一个语法尝试下Fluter；想做一个桌面应用我们也有Electron等解决方案；

随着grpc-web和grpc-node项目的稳定我们可以不用管什么ajax、fetch了，就像在native中使用SDK一样，通过方法的调用就能愉快的实现和服务端的数据通行，http2和protocolBuffer的助力也使得grpc快到没朋友；做了这么多，一些不那么简单的服务我们也可以直接用nodejs码一把了吧，似乎这个感叹有些多余。

SA课程里面了解到的富B端轻应用架构（比如：HTML5版的RIA），现在正是这个时代吧。物联网伴随着5G时代的来临，前端技术还会擦出什么样的火花呢？打开认知枷锁，不要局限于js，浏览器，向更深的原理探索，架构可能就在这里等着你，赶紧拓展提升自己的技术知识吧。最后我们还是要感谢一下nodejs带前端跨越了各种瓶颈，下一个跨越是什么呢？

思考: 技术能解决的问题也遇到了瓶颈，该怎么突破？

整体架构阶段 (看山是山看水是水)

keywords: [业务架构, 组织架构, 用户价值, 解决问题]

特点: 这时候我们的知识应该突破了技术解决问题的限制，有调度不同工种的工作，调度业务之间的支撑，实现业务架构的能力，为解决问题和实现用户价值而奋斗。我们看到了问题的本质和技术的本质是解决问题和实现用户价值。

做什么: 产品技术体系的整体架构(如果你一开始就是一个团队的Team Leader，那当你加入或者组建这个团队的时候，就应该有了一个长期的团队整体架构规划，并随着业务的发展不断的调整和改进，为业务发展做坚实的支撑，为提高整体效率而不断探索)

思考: 真正的价值成就需要解决社会问题，人类的共同问题。要让天下没有难做的生意、要让人类出行更美好。

传承阶段 (看X是山看X是水)

keywords: [持续学习, 终身成长]

特点: 这时候可能有了超俗的成就，有了做事的一套方法论，并培育出了一些比自己优秀的人才。也许还能做自己人生的架构师了。

做什么: 传承和培育

思考: 适时的放空自己去做一些更有意义的事。防治沙漠化、解决出行安全、捐建科研等社会公益问题。

小结

工作之后的第一个五年结束了，在第二个五年的前期，为了达成第二个五年的目标，我不得不去校准我自己的发展方向。我不害怕失败，也不怕从头再来，这段时间也和很多人请教了个人发展方面的事情。总的来说，主要分两种：一个是走技术专家路线；另一个是走业务管理路线；我觉得两种现在的我都太极端，我比较推崇中间融合一点的从业务架构到管理的路线，从业务出发技术赋能，架构小的业务项目到架构整个业务线的人和事。但一切的起源都需要对一件事刻苦专研，潜心深挖，做到极致，并走出自己的康庄大道，总结出自己的方法论，才能拓展宏图。诸子百家，有的相辅相成，有的自成一派。同样，每一种成功可能都有一条自己的路线，这是我理解的架构师通往成功的阶段和路线。

前端架构师必备技能

前端架构师在不同阶段有不同的要求，通用的是

1. 有整套的知识体系，现有理解的B/S、C/S架构内相关的知识，不同阶段侧重不同；
2. 对新技术充满热情，保持自身知识的前沿性；
3. 知识面广，不应有明确的技术边界(很多思想可以从前人那里得到灵感，前人可能从计算机底层开始)，也不局限于技术(比如：业务的实现方式也可以变通等)；

前端架构师怎么做需求或需求从哪里来

前端架构师的需求可以理解为我们平时的技术任务，一般是自驱或者上级指派的技术任务。可以是一个scrum的敏捷开发过程，也可以是一个瀑布流的长期开发过程。不应有明确的技术边界，也不局限于技术。

一、不同阶段有不同的问题

已知问题 收集团队或业界已知的问题和解决方案

发现问题 根据业界类似场景的问题和解决方案找到团队的问题

预言问题 了解计算机体系内各种系统架构，提炼通用可借鉴的方案

创造问题 从生活中，各行各业中学习，拓展，抽象出可用的解决方案

二、分析问题（问题的本质）

• 做：逻辑梳理，性能检测（工具和人力）
• 输出：流程图（业务流程和技术开发流程），性能分析结果（细化到网络、资源、渲染、计算、逻辑等，有一些问题可能在不影响业务的情况下变通一下实现逻辑流程会带来性能的极大提升，甚至可以影响到一些业务逻辑的实现方式）

三、解决方案

• 做：结构梳理；讨论解决方案，发散
• 输出：解决方案，架构草图

四、提炼需求

• 做：方案可行性测试，细化解决方案，收敛和统一
• 输出：详细解决方案，架构图

五、开发阶段（可能代码）

• 做：使用说明，代码开发、方案落实。
• 输出：一个规范文档、一个流程文档、一个框架、一份代码、一个工具

六、Alpha

• 做：宣贯普及（好的方案需要大家的验证和补充才能发出光彩，提升价值），收集反馈，快速迭代，修订里程碑计划
• 输出：内测体验版

七、Beta

• 做：问题修复，收集反馈，修订里程碑计划
• 输出：公测版

八、v1.0.0

• 做：问题修护，维护和拓展v2.x，v3.x…
• 输出：正式版

前端架构狮除了以上的技术技能还要具备一定的说服力，要么说服并得到上级的支持，要么用实践说服其他人。

总结

在这篇文章之前我也不知道前端架构师该做什么，看了一个前端架构师jd后发现这几年在带业务团队中自己做的事情比较符合（此时从初创做到跨越融合阶段，但技术是为业务服务的，一些技术没有业务支撑，还在尝试和探索阶段）。去交流后，因为我的答案可能是狭义的前端架构理解+jd上我做过的事，也就是最后的一个问题我理解的前端架构师是什么样或者该做什么？因为我真的没有去思考过了，这也是回来后有了这篇文章的原因(这里只描述前端架构师在做什么，具体实践和理论之后会结合这几年做的架构相关的事务再做详述)。

现在我还在跨越融合阶段探索，这之后的阶段具体做什么我也没想好，也许我把当前阶段的做好了我也就知道了，也希望有业务能够支撑我继续做下去。欢迎讨论，持续更新中。