前端架构都在聊什么

缘起

对于「前端架构」，在几年前我一般不说这个词儿的，一方面功力不够觉得前端架构都是一些能力拼凑出来的，另一方面觉得满嘴说着架构总感觉有点江湖骗子的感觉。

近几年经历的项目多了，同时因为工作交流上遇到了一些可笑的事情，所以想深入探讨下这个偏向于艺术的话题（没有准确答案），看看前端架构究竟是怎么个事儿。

架构之“道”

见过一些认为用了各种库拼凑出来的项目跑起来就是架构设计了，比方曾遇到过因为没使用「css modules」就质疑整个架构设计不合理的事情。

我认为这些都是手段，相当于“术”，而架构设计指的是背后的“道”，以下是AI给出的定义：

架构设计是对一个系统的顶层结构进行规划与设计的过程，旨在合理划分系统模块、明确各部分职责、规范交互方式，从而实现系统的稳定性、可扩展性、可维护性和高性能。

可以看出，核心考量主要是稳定性（安全、稳定等）、维护性（维护成本、可扩展等）、高效性（性能、体验等）。架构设计的过程就是围绕着这三方面做各种手段的组合，当然这都是思维层面的，一般架构图不会单独体现。

架构之“术”

通常见到的架构都是分层展现的，最上层是业务层，逐步拆解到最底层，层层递进一目了然。上面提到的“道”都蕴含在其中，下面尝试换个角度从“道”出发进行分析。

稳定性

对于稳定性的考量，主要看重系统是否可以长期稳定运行、是否会因频繁迭代导致系统不稳定。主要考量维度：

• 可用性：系统是否能持续稳定运行，比如是否有完善的监控和报警机制。
• 健壮性：是否会因为某些不易察觉的错误导致崩溃，比方说空错误直接白屏了。
• 安全性：是否容易因攻击导致崩溃，比方说一个SQL注入直接导致被拖库。
• 容错性：当出现错误时是否有合理的降级和容错方案，避免整体系统崩溃。
• 可恢复性：系统出现问题后是否能快速恢复，比如是否有备份和回滚机制。

针对稳定性，通常采用看得见、易恢复、避再犯的思路去针对建设。

• 看得见（事前）：也就是问题发现的手段建设，最常见的主动手段包括技术监控、自动化测试/扫描、技术方案/Code Review等。被动手段比如各种用户反馈渠道等。
• 易恢复（事中）：明确的问题相应SOP建设，在问题发生时，可以快速定位到问题所在，快速修复问题等等环节的保障。
• 避再犯（事后）：经验沉淀机制，为了避免类似问题的再次发生，进一步做能力建设。

维护性

维护性主要看重系统的维护成本，最直接的成本是需求的开发成本，长期看还包括可扩展性、上手成本、重构成本等。

• 可扩展性：通过协议、流程化等等思路将项目中的可变和不可变拆分开，去提高系统在快速迭代过程中的灵活性。
• 上手成本：通过技术选型、巧妙地代码组织、文档、注释、示例等手段去降低新同学的入门门槛。
• 重构成本：项目迭代有很多不确定性，要保留一定的灵活性，避免过度设计，为未来的变留出一定的空间。

维护性往往是纯技术设计的考量，这部分需要很多经验积累，同时需要对业务有足够的理解，才能做出合理的设计。

高效性

高效性主要看重系统的开发成本、性能、体验等。

• 开发成本：这方面也涉及到维护性，通过各种设计模式、框架、库的运用去提高开发效率，比方说通过组件化、配置化能力等。
• 性能：通过各种技术手段去监控和提高系统的性能，比方说通过SSR、缓存、CDN等。
• 体验：技术开发体验、用户体验等都包含在内。

当然不只是局限在以上这些手段，还有很多其他手段可用，需要看内部已有基建能力、建设ROI等等综合评估，不是说越复杂越高级越好，需要灵活运用才是王道。

结语

了解了上述“道”和“术”，对于前端的架构设计基本就算是有一个整体认知了，其他的无非就是根据实际场景去看能力怎么建设、架构图怎么画/框怎么摆的问题了。

随着AI时代的到来，在上述各环节均有AI的用武之地，任重而道远需要长期思考。