Chapter1：前端架构
本章主要什么是软件架构，以及为什么需要软件架构，介绍了如何设计软件架构以及设计风格及两种主流架构设计方法，接着介绍了三个基本的架构设计原则，最后是关注前端相关架构设计。
本文只要摘于《前端架构从入门到微前端》 书 chapter1，著作人：黄峰达。请多多支持这位大佬，书写的很棒，本人只是看了后，做的一个笔记
前端架构是软件系统得高级结构，以及创建这种结构和系统的约束，盖房子和软件开发是相似的，需要规划、设计、实施后才能使用，盖房子最先的设计是建筑的架构，有了建筑的蓝图，还需要考虑美观、实用、坚固等要素，从各种材料中选择合适的，才能进入实施阶段，实施过程中严格按照建筑的蓝图进行施工，保证质量，才能造出所需的建筑：
- 如果不能完成地基的建设，那么房子就无法继续往上盖
- 开始盖房子时，便是在实施对应的架构，若地基有问题，房子很难长期存在
- 在浇筑钢筋水泥过程中，若不注意，房屋很可能歪歪扭扭
- 虽然房子盖好了，后期不保养和维护，仍会出现问题
开发人员需要怎样的软件架构
一个无法上线的应用架构、一个没有人完成的软件架构，一个现有技术不可行的架构，不易实现为目的的都是毫无意义的。
期望的架构应该包含一些内容：
- 系统间关系：明确指出该系统与其他系统之间的关系，是调用关系还是依赖关系
- 系统内关系：系统内各子系统之间的关系，如前端应用与后端应用，以怎样的方式通信，需要怎样的通信机制
- 应用内架构：包含应用相关的框架、组件，并清楚的表示出他们之间的关系
- 规范和原则：用于指导项目中的开发人员，编写出符合需求的代码，以构建出设计中的架构
架构的设计
架构设计并非只是一个技术工作，它包括软件工程、开发实践、业务交付等相关领域，具体步骤如下（根据项目实实际情况，部分步骤可以忽略）：
- 收集利益相关者需求，倾听业务、项目负责人需求，进行用户需求收集（了解相关者利益，架构关注点，明确跨功能需求，罗列技术风险点）
- 与相关技术（如开发、测试）人员讨论，了解架构潜在限制 （需要考虑各方利益诉求，在一起讨论折中的方案）
- 寻找潜在可行性技术方案
- 整理出功能列表中的功能需求和跨功能性需求
- 找出会严重影响开发的风险点
- 和技术委员会，利益相关者反复确认方案
- 对架构设计进行概念证明
- 细化架构的部分实施细节
- 结合技术和业务，进行需求排期
各组织、开发人员大部分项目中有以下相同关注点
我们进行角色时，应和相关者讨论，反复确认后，我们会得到关注点的优先级，这些优先级能在后期开发设计中减少不必要的返工
| 关注点 | 说明 |
|---|---|
| 性能 | 应用需要达到怎样的指标、可以实现多少用户的并发 |
| 安全 | 应用如何保障用户数据的安全、如何应付客户端、服务端的攻击 |
| 平台化 | 应用是否作为一个平台，来承载其他系统 |
| 代码维护 | 是不是稍有经验的开发人员能尽快上手 |
| 用户体验 | 用户体验是否比其他几个维度更重要 |
罗列技术风险点
设计架构中，需要寻找系统中的一系列技术风险：
- 技术风险：如果某一功能的实现比较复杂，或者团队缺乏某一领域的经验，如AI，那在实践中可能会影响系统的架构
- 第三方系统集成：如果集成后端服务，那只需要关注对方API能否按时上线，如果使用第三方集成到系统，则需要提前进行技术评审
- 受限制的线上运行环境： 开发人员和运维人员分离的组织里，需要选定语言，便于维护
- 其他：一些需求变化会增加额外的技术膨胀，则会带来应用开发风险，则需要进行新的评估并和 相关利益人员进行讨论
架构模式
架构风格
日常的开发中，常见的风格有：
- 分层风格： 这是常见的架构风格，它将系统水平切分方式分为多层，一个系统由多层组成，每层由多个模块组成，每一层为上层提供服务，并使用下层提供的功能。最为人所知的架构应用是OSI 七层模型和TCP/IP 五层模型，在开发后端服务得到了广泛运用
- MVC架构： 这种风格相当广泛，它强调了职责分离，将软件系统分为三个基本部分：model、views、controller
- 发布-订阅风格：成为基于事件的架构风格，它是一对多的关系，一个对象状态发生改变，所有订阅它的对象都会得到通知。这种架构风格最大好处就是代码的解耦。
- 管道和过滤器：适合于处理数据流的架构模式，它将每个步骤都封装在一个过滤器组件中，数据通过相邻过滤器之间管道传输，最典型的管道-过滤器架构是UNIX shell设计。
架构设计方法
简单介绍以下两种设计方法
1. 4+1视图法
mindmap
开发视图
场景
物流视图
流程视图
逻辑视图
- 逻辑视图： 在设计期的模块、接口划分、职责及协作方式
- 流程视图：在运行期运行的数据同步，如在微前端中数据流、控制流等
- 开发视图：在开发期的框架、库、技术选型及对应的编译
- 物理视图：又称部署视图，在部署期与持续交付相关的技术决策
- 场景：又称用例视图，它使用一组用例或场景来说明架构
从上图看出设计流程如下：
- 架构人员根据需求创建对应的逻辑架构，开发人员进行详细设计
- 架构人员和开发人员需求设计物流架构，再由开发人员根据物理架构进行对应的详细设计 4+1视图是依靠软件建模和OO技术来进行架构设计，尤其在逻辑架构设计方面更符合传统的瀑布流模式，需要实现设计好各类接口，才能进入项目的开发阶段，这种很繁琐，不适合互联网应用，又不适合前端应用
2.架构开发开发：TOGAF及ADM
针对大型的企业架构可以采用TOGAF的标准设计企业架构，从1995年发布第一个版本至今，已经发布了9个版本，以目前9.2版本而言，该版本将企业架构分为4个架构域： 业务架构、应用架构、数据架构、技术架构，在没有足够时间和精力下，往往很难覆盖4个架构域描述，还有一个架构开发方法叫ADM,用于创造企业级架构，ADM分为8个阶段
-
架构愿景： 设定项目范围、约束和期望
-
业务架构：开发业务架构，用于支持设定的架构愿景
-
信息系统架构：开发信息系统架构，用于支持设定的架构愿景
-
技术架构：开发技术架构，用于支持设定的架构愿景
-
机会及解决方案：为前几个阶段定义架构进行初步实施计划和交付工具的识别
-
迁移计划：通过最终确定的详细实施和迁移计划，阐述如何从基准体系结构迁移到目标体系架构
-
实施治理：准备和发布架构契约，并对实施的架构进行监督，以确保实施项目符合架构要求
-
架构变更管理：对架构变更进行持续的监控
TOGAF是面向大型企业的架构方法，内容比较广泛且繁琐，对应中小型企业及中小型应用比较复杂，需要按照自己的需求进行裁剪
生产架构产出物
不论采用那种架构设计，都需要留下相应的架构文档，它能为团队打下基础，在进入开发阶段时，作为普通开发人员需要得到内容如下：
- 架构图。 它包含了整体架构，用于显示告诉开发人员，如何构成的整个系统和每个部分之间的关系
- 迭代计划。按照业务和技术要求，按时间顺序排列出项目的实施计划
- 技术栈及选型。确定项目使用语言、框架、库等相关技术栈
- 示列代码。在这些代码展示架构风格及相应设计规范
- 测试策略。明确项目测试类型、测试流程，以及相应人员在哪些层级进行测试
- 部署方式。定义应用的部署方式及相应的部署方案
架构设计原则
不同的设计架构会出现不同的风格，在细节把握上也会出现特有的风格，这便是架构设计原则，常用的三个设计原则为：
- 不多也不少：不做多余的设计，也不缺少关键的部分
- 演进式： 不断的演进使架构适应当前的环境
- 持续性：长期的架构改进比什么都重要
前端架构的发展史
最初前端是没有架构的，因为功能简单的代码没有架构可言，通过操作DOM就能完成的工作，不需要复杂的设计模式和代码管理机制，前端开发的发展历史可分为以下阶段：
- 古典时期：由后端渲染出前端HTML,用table布局，用css简单辅助
- 动效时期：前端开始编写一些简单的JavaScript脚本做动态效果
- Ajax异步通信：2005年，Google在诸多web应用使用ajax做地图
- 通过jQuery model UI 解耦
- 更好的构建工具：grunt, gulp等工具
- 包管理：产生了用于前端的包管理工具 bower 和 npm
- 模块管理：AMD,Common.js等不同的模块管理方案
- API管理：采用swagger等api管理工具
- 大前端： 前端开发跨平台应用框架，采用诸多ionic，react native， flutter
- 组件化： 前端应用从一个个细小的组件组合而成，不在是一个大页面组件
- 跨框架： 在一个页面运行，可以同时使用多个前端框架
- 应用拆分：将一个复杂的应用拆解为多个微小的应用，类似于微服务
- 遗留系统迁移：让旧的前端框架，可以直接嵌入现有的应用运行
前端架构层级
-
系统级：前后端分离架构，微前端架构
-
应用级：模式库、组件库、设计系统
-
模块级：组件化、模块化
-
代码级：规范、原则、质量
