这是我参与11月更文挑战的第14天，活动详情查看：2021最后一次更文挑战
本系列文章为黄峰达的《前端架构：从入门到微前端》的学习记录。
什么是架构
架构是一个演变的过程。 它指的不是随着历史的演变，而是随着项目演变。 通常说架构，指的是架构模式。
架构都是基于当前的技术，人员，财力等而定的，架构不会一成不变的。在软件的生命周期中，架构可以不断地优化，持续地变好，使得架构可以适用于当前的场景。
如何判断一个架构的好坏？
◎ 一个无法上线的应用架构，算不上好的软件架构。
◎ 一个没有人能完成开发的软件架构，算不上具有可行性的软件架构。
◎ 一个在现有的技术上不可行的架构，算不上合理的软件架构。
我们希望实现的软件架构是什么样的？
◎ 系统间关系。明确地指出该系统与其他系统之间的关系，是调用关系，还是依赖关系等。
◎ 系统内关系。系统内各子系统之间的关系，如前端应用与后端应用，以怎样的方式通信，需要怎样的通信机制。
◎ 应用内架构。包含应用相关的框架、组件，并清楚地表示出它们之间的关系。
◎ 规范和原则。用于指导项目中的开发人员，编写出符合需求的代码，以构建出设计中的架构。
如何进行架构设计
进行架构设计包含了一系列的复杂工作，如图
相应的步骤如下：
（1）收集利益相关者的需求。倾听业务人员、项目负责人等相关者的需求，进行用户访谈，收集相关的需求。
（2）与相应的技术人员（如开发人员、测试人员）讨论，了解架构上的潜在限制。
（3）寻找潜在的可行性技术方案。
（4）整理出功能列表中的功能性需求和跨功能性需求。
（5）找出会严重影响开发的风险点。
（6）和技术委员会、利益相关者反复确认方案（可选）。（7）对架构设计进行概念证明。
（8）细化架构的部分实施细节。
（9）结合技术和业务，进行需求排期。
架构关注点：
从质量与可维护性出发要考虑的：
◎ 运行质量（Execution Qualities）：即可以在系统运作时观察到的质量，例如安全性、易用性等。
◎ 演进质量（Evolution Qualities）：它们体现在系统的静态结构中，例如软件可测试性、可维护性、可扩展性、可伸缩性（Scalability）等。
◎ 可用性：是指在一段时间内，系统能够正常运行的概率。如何保证这样的可用性？
◎ 可维护性：其表现的指标是，在接到修改后，可以在相应的时间内（如小功能1～3天）修改完成。
◎ 可变性：在未来，应用的哪些地方会发生变化？是否需要提前做好准备？
◎ 容错性：系统中可能会出现哪些故障？如何确保这些故障不会让系统无法运行？
◎ 可伸缩性：当更大规模的用户使用系统时，哪些服务会出现问题？
◎ 浏览器的支持范围：明确指出我们要针对哪些浏览器，以及浏览器的哪些版本做兼容。
◎ 移动端设备支持的版本：常见的设备如Android和iOS，设备最低的支持版本，以及支持哪些设备制造商。
架构模式
（1）分层模式
这是最常见的架构风格，它将系统按照水平切分的方式分成多个层。一个系统由多层组成，每层由多个模块组成。每一层为上层提供服务，并使用下层提供的功能。
比如我们众所周知的OSI七层模型和TCP/IP五层模型。
（2）MVC 架构模式
这种风格应用得相当广泛，它强调职责分离，将软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
由视图和控制器一起完成用户界面的功能，并设计一套变更机制，来保证用户界面与模型的一致性。
它是一种常见的架构风格，在涉及图形用户界面时，往往都有它的身影，如前端应用、移动端应用等。
（3）发布-订阅模式
这种风格又可以称为基于事件的架构风格，它是一种一对多的关系，一个对象状态发生改变时，所有订阅它的对象都会得到通知。
这种架构风格带来的最大好处是，代码上的解耦。发布者不关心事件的订阅者，只需要在适当的时候发布相应的事件即可；而订阅者则依赖于事件，而非事件的发布者。
在前端的日常开发中，为了解耦不同的UI组件的依赖，会经常采用这种模式。
（4）管理和过滤器
这是一种适合于处理数据流的架构模式，它将每个步骤都封装在一个过滤器组件中，数据通过相邻过滤器之间的管道传输。
如前端框架的Angular，也直接内置了管理（Pipe）系统。
架构开发方法
（1）4+1视图法
每个项目都会有一张系统架构图，里面包含了系统的主要层级之间的关系，以及一些第三方系统之间的关系。
我们可以通过开发、部署、流程相关的内容来了解系统的架构：
释义：
◎ 逻辑视图（Logical View）：在设计期的模块、接口划分，职责及协作方式等。◎ 流程视图（Process View）：在运行期运行的数据同步，如在微前端中的数据流、控制流等。
◎ 开发视图（Development View）：在开发期的框架、库、技术选型及其对应的编译。
◎ 物理视图（Physical View）：又称为部署视图。在部署期与持续交付相关的技术决策。
◎ 场景（Scenarios），又称为用例视图，它使用一组用例或场景来说明架构。
4+1视图法设计流程
（1）架构人员根据需求创建相应的逻辑架构，开发人员进行详细设计。
（2）架构人员和开发人员根据需求设计物理架构，再由开发人员根据物理架构进行对应的详细设计。
总结
4+1视图法是倚靠软件建模和OO技术来进行架构设计的，尤其在逻辑架构设计方面更符合传统的瀑布模式，需要事先设计好各类接口，才能进入项目的开发阶段。这种烦琐的设计方式，既不适合于互联网应用，又不适合于前端应用。
（2）TOGAF 及 ADM
针对大型的企业架构来说，可以采用TOGAF（TheOpen Group Architecture Framework，开放组体系结构框架）的标准化方式来设计企业架构。
TOGAF 的架构域
◎ 业务架构（Business Architecture）：定义业务战略、治理方法和关键业务流程。
◎ 应用架构（Application Architecture）：为将要部署的各个应用程序提供蓝图，并展示它们的交互及与核心业务流程的关系。
◎ 数据架构（Data Architecture）：描述了一个组织的逻辑、物理数据资产及数据管理资源的架构。
◎ 技术架构（Technology Architecture）：定义了支持部署业务、数据和应用程序服务所需的逻辑软件和硬件功能，它包含了IT基础设施、中间件、网络、通信、处理和标准。
ADM
ADM，用于创建企业级架构。ADM一共分为8个阶段：
下面对8个阶段进行解释：
A．架构愿景。设定项目的范围、约束和期望。
B．业务架构。开发业务架构，用于支持设定的架构愿景。
C．信息系统架构。开发信息系统架构，用于支持设定的架构愿景。
D．技术架构。开发技术架构，用于支持设定的架构愿景。
E．机会及解决方案。为前几个阶段定义的架构进行初步实施计划和交付工具的识别。
F．迁移计划。通过最终确定的详细实施和迁移计划，阐述如何从基准体系结构迁移到目标体系结构。
G．实施治理。准备和发布架构契约，并对实施的架构进行监督，以确保实施项目符合架构的要求。
H．架构变更管理。对架构变更进行持续的监控。
架构产出物
不论采用哪种架构设计方式，都需要留下相应的架构文档，它们将为团队开发打下基础。
◎ 架构图：它包含了系统的整体架构，用于显示地告诉开发人员，它们是如何构成整个系统的，以及每个部分之间的关系。同时，显式地表明哪些部分是第三方系统，以及它们与该系统之间的关系。
◎ 迭代计划：按照业务和技术的要求，按时间顺序排列出项目的实施计划。由于其中也包含了上线时间，所以也可以从上线时间往前推算出迭代时间。开发流程：定义开发人员的工作方式，诸如采用敏捷还是瀑布的开发模式、何种源码方式（主分支、GitFlow或者FeatureBranch（功能分支）工作流），必要时还要提前准备相应的工具和设备。然后，有针对性地对开发流程进行一定程度的裁剪，以真正满足团队的开发。
◎ 技术栈及选型：确定项目中使用的语言、框架、库等相关的技术栈，以及相应的依赖等。
◎ 示例代码：在这些代码中展示架构的风格及相应的设计规范。
◎ 测试策略：明确项目的测试类型、测试流程，以及相应的人员在哪些层级进行测试。
◎ 部署方式：定义应用的部署方式及相应的部署方案。
◎ 持续集成方案：描述系统的各个模块之间（如前后端）如何集成，以及采用怎样的时间和频率来集成相关的模块。
架构设计原则
◎ 不多也不少：不做多余的设计，也不缺少关键的部分。
◎ 演进式：不断地演进以使架构适应当前的环境。
◎ 持续性：长期的架构改进比什么都重要。
以软件开发和设计领域的专家Martin Fowler的观点来看，两者间最合理的分配是20%的计划式设计，80%的演进式设计。这样的设计需要我们注意以下几个方面：
（1）在项目初期进行计划式设计，以确保架构能处理最大的风险。
（2）在迭代0进行初步的架构实践，编写示例的架构性代码——以将设计原则、风格融入项目中。
（3）在项目实施过程中，采用局部设计或演进式设计，以应对需求变化。
（4）配合重构、测试驱动设计与持续集成等敏捷实践，来驱动架构的实施，并防止架构腐烂。
如何通过层次设计来设计前端架构
从高手多年的经验来说前端架构可以通过层次设计的方式来进行，即由顶至底进行一层一层的技术决策，再由底至顶逐层验证方案的可行性。
架构设计可以分为四个层级：
相应的层级解释如下：
◎ 系统级，即应用在整个系统内的关系，如与后台服务如何通信，与第三方系统如何集成。
◎ 应用级，即应用外部的整体架构，如多个应用之间如何共享组件、如何通信等。
◎ 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
◎ 代码级，即从基础设施来保障架构实施。
前后端分离架构
它包含了一系列的决策、用户鉴权、API接口管理与设计、API（契约）文档管理、Mock Server使用、BFF（服务于前端的后端）、是否需要服务端渲染等。
当在一个系统内时，微前端是一个应用间的架构方案，当在多个应用间时，微前端则是一种系统间的架构方案。
层级设计的设计方法：
（1）应用级架构
应用级架构指的是，单个应用与外部应用的关系，如微服务架构下的多个应用的协作。
-
脚手架
-
模式库
-
设计系统
（2）模块级架构
模块级架构是深入单个应用内部、更细致地设计应用内部的架构，它所涉及的内容是我们在日常开发中经常接触的。
-
模块化：它包含了CSS、JavaScript、HTML/模板的模块化
-
组件化：它主要考虑的是，在应用内如何对组件进行封闭，以及相应的原则和粒度。
（3）代码级：规范与原则
架构实施
无论是短期项目还是长期项目，它们都包含了相似的启动和实施周期：
这三个时期的工作内容介绍如下。
◎ 技术准备期：开始与架构实施相关的一系列工作，如搭建脚手架、测试及部署等。
◎ 业务回补期：填补第一个时期造成的业务进度落后的问题，以技术实践业务来证明技术的价值。
◎ 成长优化期：持续地对项目的技术和业务进行优化，以实现开发及业务人员的诉求。
