一个前端对架构设计的唠嗑

目的

让所有的大家了解一些架构的基础知识，并且根据了解到的内容投入到自身的工作中。也为大家在未来埋下一颗种子。

本文仅仅作为个人的一些分享，可能存在一些误导，大家可以在后续提供更加符合架构设计的思想以及内容的分享。

什么是架构设计

在很多刚入行的程序员看来，架构设计似乎是自己非常难以驾驭的事情。

而我认为，架构设计是将各种个体集合在一起，在一定的规则定义下，实现它们相互之间的业务联系和需求，并且解决业务发展和变化所带来的各种困扰。

在很多时候，大家会在不经意间进行一些架构设计。

比如，前端在做开发的时候，会遇到如何选择个某个框架、如何打包项目、前端涉及哪些第三方包、由于业务需求选择了哪些技术方案或者自行提出某些方案、代码的规范是什么等等。

这个也是一种架构设计。可以叫做开发架构。

架构不仅仅包含了开发架构，他还会有业务架构、应用架构、开发架构、技术架构。

在不同人的眼里，会产生不同的架构体系。他们看到的东西也会随着他们的身份改变。

这里举个例子，说明架构设计为什么要去了解业务：

一个电商网站上线一个秒杀业务，一般来说，这个就是很简单的CURD操作。谁点中了，那就是谁的。但是，电商网站没有想到业务的发展极其迅速，架构师也不了解业务，没有对业务的远期规划。业务增长之后，秒杀业务瞬间崩溃。

在这里可以说下，秒杀网站他们的一些架构设计

1. 抽奖模式，所有人首先进行预约秒杀，获取一个tick，在秒杀开始之后，服务端随机抽取tick。

2. 正常的消息消费模式，所有人先把秒杀请求放到消息队列中，服务端挨个获取进行判断识别，并且进行仓储管理。

3. 架构师还需要考虑机器人抢购，需要针对这些做出安全设计，最典型的，微博抽奖，男性用户是绝对中不了。这也是架构师了解业务之后做的架构设计。

如何开始架构？

1. 了解业务

2. 定义业务基本词汇

3. 分解业务，并且拆解各种业务从大模块到小问题

4. 决定架构运行规则

5. 规范团队协作

6. 知识库落地

7. 架构进化发展

架构必须知道：不要惧怕失败、不要惧怕苦难。没有一蹴而就的事情，所以得事务都在不停地变化。水无常形,人无常态，架构也是如此。

举例：人体是非常多的器官搭配而成，但是人身上也存在很多屎山。

喉返神经就是一个屎山。

1 了解业务

作为架构师，首要的就是去跟产品，跟客户聊业务，深入的去了解当前业务是如何运行的，这个业务是需要解决客户什么问题。

跟客户沟通业务的远期达成的目标是什么。并且要把所了解到的这个业务转述给团队成员。

可以通过以下几点确定业务的了解程度。

1. 业务需求分析：从用户和业务角度去了解系统的核心目标和功能需求。了解的业务，才能准确的进行架构设计，确保系统能满足业务方的需求。
   并且可以确定系统中的关键业务流程和数据流动。
2. 数据建模和数据库设计：设计业务所需要的模型，组织整个数据间的关系满足业务需求。并且确定数据如何存放和灾备。
3. 业务变化：如果了解完整个业务，需要对这个业务有现状和远期的分析，以更加灵活的架构设计，让系统适应未来的业务需求。
4. 业务团队沟通：和业务方沟通确定整个架构设计中的优先级，确认系统开发的层层推进。

2 定义业务基本词汇

架构师在了解完整个业务之后，需要对业务定义团队内部使用的基本词汇。之所以要定义词汇是为了满足一致性和准确性。

确定团队沟通使用一致的术语，避免功能、理念混淆。定义好的基本词汇，可以在团队内部，对外沟通和交流加快理解的意图，提高沟通效率。

也方便在编写文档的时候，更加容易理解阅读文档，保持所有文档的连贯性。文档的连贯性也有帮于整个业务、架构的知识传承和团队成员培训。

3 分解业务，拆解业务从大模块到小问题

在这个过程中架构师会根据业务确定，整个业务架构的模块。并且拆解成对应case来解决当前模块需要完成的业务问题。

在这个过程中，架构师还需要确定模块所涉及的归属成员。并且考虑一定的业务发展带来的过度设计。

过度设计在架构中必不可免，但是我希望大家在做设计的时候，尽可能的避免过度设计，以满足当前的需求，并且有一定的拓展性为主。

否则，会一直沉浸在未来可能永远不会发展到的业务设计中。造成架构设计的失败。

问题：架构师需要去拆解大模块到小问题吗？

4 决定架构运行规则

一般架构分为：

1. 分层模式，每一层都有自己的职责，配置每一层相互之间的访问方式。一般都是上层允许使用下层。典型架构是C# MVC架构。
2. 端口适配器模式，应用分为三部分承载业务逻辑的应用核心、依赖外部的被动适配器、主动提供的访问方式主动适配器。由内部提供核心业务逻辑，但是通过适配器组合对应的端口给到需求方。
3. 管道过滤器模式，数据如同流水一样，一层层的流过对应的模块，模块对数据进行加工处理，在前端比较典型的应用是Node.js的KOA架构就是管道过滤器模式。
4. 微服务模式，各个模块之间关联度不是很高，通过自身影响底层数据，并只对底层数据负责。并且对外暴露调用API，使用者仅知道API，不关心底层的实现。
5. 微内核模式，核心只提供通用功能，由注册进入的插件实现业务逻辑。

其他模式就不多做介绍了，使用最频繁的还是1,3,4两种模式。

架构模式其实和程序员的设计模式大同小异，只是他们针对的层面不同。架构模式更加宏观全面，对架构师的要求更加多。

架构师，需要拥有广泛的技术知识以应对架构设计。

在设置好架构之后，团队的开发人员就能知道，如何在这个架构内进行工作。

5 规范团队协作

团队协作一般指的是开发流程和方法：定义开发过程中的步骤、活动和交付物，例如敏捷开发、迭代开发、持续集成等。这些流程和方法可以提高开发效率、质量和团队的协作能力。

6 知识库落地

知识库不仅包含了业务的需求文档，还包括了开发文档、设计文档、流程文档等等。

对于知识库的建设，在一个有长远打算的团队中，是必不可缺的，因为知识库代表着项目的传承。

所有的人员，都会依据知识库了解业务，了解架构。而不是通过开发人员内部的口口相传。

7 架构进化和发展

架构在设计之后，并且开发上线之后，并不会完美的适应业务发展，架构师应该时刻关注业务、技术、团队的情况，并且在适当的时候做出调整。以便业务能更好的发展。

举个例子，比如 现在地图应用APP。最早之前有个名叫 凯立德的车机地图，当时的架构设计是需要人去通过刷机的方式，将地图输入应用中，而他的收费手段也是通过每次刷机收取费用。这个是他们的架构师对他们业务做出的设计。

而后来，移动端的大力发展，这种业务方式就开始崩塌了。但他们没有意识到这个问题，没有改善现有的架构，也无法舍弃现有的业务。最后泯然众人。虽然这个例子可能并不完全恰当。

但是，我认为，架构师应该有敏锐、前沿的意识。在某个阶段提前做出调整。

再举个不恰当的例子，比如最早以前，前端开发使用的是JQUERY，那这是一种架构技术选型。而后来的VUE、REACT的到来，让前端开发效率陡然提升。这个时候，架构师就要有意识的去了解这种加快效率的技术框架。

做出适合自己架构的技术选型。

结束语

本来打算写点离屏渲染的技术文章，但是在今年自己沉淀了一些关于架构的知识点，所以想给大家分享一下，可能上面的言论也可能存在谬论，欢迎大家勘正。最后发一段ChatGPT对于前端架构的认知。

前端开发架构

开发架构（Development Architecture）是指在软件开发过程中，为了有效组织、管理和支持软件开发活动而设计的整体框架和结构。它涉及到在软件开发过程中定义和组织开发环境、工具、流程和方法，以及开发团队之间的协作方式。

开发架构的目标是提高开发效率、降低开发成本，并支持软件系统的质量和可维护性。通过良好的开发架构，可以提供一个结构良好、模块化、可测试和可扩展的开发环境，使开发团队能够更加高效地进行软件开发。

以下是一些常见的开发架构组件和原则：

1. 开发环境：包括开发工具、集成开发环境（IDE）、版本控制系统、构建工具等。这些工具和环境能够提供编码、调试、构建和测试等功能，以支持开发人员的日常工作。

2. 开发流程和方法：定义开发过程中的步骤、活动和交付物，例如敏捷开发、迭代开发、持续集成等。这些流程和方法可以提高开发效率、质量和团队的协作能力。

3. 架构模式和设计原则：选择适合的架构模式（如分层架构、微服务架构、事件驱动架构等）和应用设计原则（如单一职责原则、开闭原则、依赖倒置原则等）。这些模式和原则可以指导软件系统的整体结构和组织方式，以提高系统的可维护性和可扩展性。

4. 模块化和组件化：将软件系统拆分为独立的模块和组件，以实现代码重用、降低耦合度，并支持并行开发和测试。模块化和组件化能够提高开发效率和代码的可维护性。

5. 文档和知识管理：建立适当的文档和知识管理系统，记录开发过程中的设计决策、技术文档、API文档等。这有助于知识的传承和团队成员之间的沟通与合作。

6. 测试和质量保证：建立测试策略和自动化测试框架，确保软件系统的功能和性能符合需求，并提供稳定的质量水平。测试和质量保证措施有助于减少缺陷和改进软件质量。

开发架构需要根据具体的项目需求、团队规模和技术栈来设计和调整。它在整个软件开发生命周期中扮演重要的角色，为团队提供统一的开发框架和指导，以确保软件项目的成功交付。