微前端等新型架构
优势
- 技术栈无关
- 主框架不限制介入应用的技术栈，微应用具备完全自主权
- 独立开发、独立部署
- 增量升级
- 微前端是一种非常好的实现渐进式重构的手段和策略
- 微应用仓库独立，前后端可独立开发，主框架自动完成同步更新
- 独立运行
- 每个微应用之间状态隔离，运行时状态不共享
劣势
- 接入难度较高
- 应用场景移动端少，管理端多
Iframe
优势
- 技术成熟
- 支持页面嵌入
- 天然支持运行沙箱隔离，独立运行
劣势
- 页面之间可以是不同域名
- 需要对应的设计一套应用通讯机制，如何监听、传参格式等内容
- 应用加载、渲染、缓存等体系的实现
web component
优势
- 支持自定义元素
- 支持shadow dom,并可通过关联进行控制
- 支持模板template和插槽slot,引入自定义组件内容
劣势
- 接入微前端需要重写当前项目
- 生态系统不完善，技术过新容易出现兼容性问题
- 整体框架设计复杂，组件与组件之间拆分过细时，容易造成通讯和控制繁琐
自研框架
优势
- 高度定制化，满足需要做兼容的一切场景
- 独立的通信机制和沙箱运行环境，可解决应用之间相互影响的问题
- 支持不同技术栈子应用，可无缝实现页面无刷新渲染
劣势
- 技术实现难道较高
- 需要设计一套定制的通信机制
- 首页加载会出现资源过大情况
实现方式
- 路由分发式
- 主应用控制路由匹配和子应用加载，共享依赖加载
- 子应用做功能，去接入主应用实现主子控制和联动
软件设计原则（拓展学习——设计原则）
单一职责原则
- 永远不应该有多于一个原因改变某个类
- 理解：对于一个类而言，应该仅有一个引起它变化的原因
- 应用：如果一个类拥有了两种职责，那就可以将这个类分成两个类
- 如：验证密码和验证用户名分成两个类
开放封闭原则
- 软件实体扩展应该是开放的，但对于修改应该是封闭的
- 理解：对扩展开发，对修改封闭，可以去扩展类，但不要去修改类
- 应用: 当需求改动，尽量用继承或组合的方式和来扩展类的功能，而不是直接修改类的代码
- 如：先封装验证密码的方法，当验证通过返回true再执行后续操作，当校验密码需求变更时，只需确保校验返回结果正确
里氏替换原则
- 理解：父类一定能够被子类替换
最少知识原则
- 只与你最直接的对象交流
- 理解：低耦合，高内聚
接口隔离原则
- 一个类与一个类之间的依赖性，应该依赖于尽可能小的接口
- 理解：不要对外暴露没有实际意义的接口。用户不应该依赖它不需要的接口
- 应用：当需要对外暴露接口时，如果是非必要对外提供，尽量删除
依赖倒置原则
- 高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
- 理解：应该面对接口编程，不应该面向实现类编程
- 并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
SOLID原则
- 以上六大原则首字母SOLID(稳定的)所以称之为SOLID原则
补充设计原则
组合/聚合复用原则
- 当要扩展类的功能时，优先考虑使用组合，而不是继承
- 该原则在23种经典设计模式中频繁使用
- 如：代理模式、装饰模式、适配器模式等
无环依赖原则
- 当A模块依赖于B模块，B模块依赖于C模块，C 依赖于A模块，此时将出现循环依赖
- 在设计中避免该问题，可通过引入“中介者模式”解决
共同封装原则
- 应该将易变的类放在同一个包里，将变化隔离出来
- 该原则是“开放-封闭原则”的延伸
共同重用原则
- 如果重用了包中的一个类，那么也就是相当于重用了包中的所有类，我们要尽可能减小包的大小
好莱坞原则
- Don't call me , I'll call you
- “控制反转”（或称为“依赖注入”）
- 不需要主动创建对象，而是容器帮我们来创建并管理这些对象
不重复自己
- 不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能的封装。
保持它的简单与傻瓜
- 保持系统界面简洁，功能实用，操作方便
高内聚与低耦合
- 模块内部需要做到内聚度高，模块之间需要做到耦合度低
其他设计原则
关注点分离
- 将一个复杂的问题分离为多个简单的问题，然后逐个解决
- 难点：如何进行分离
你不需要它
- 不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。
- 让系统足够简单，而又不失扩展性
软件设计分层
系统级架构
- 应用在整个系统内，如与后台服务如何通信，与第三方系统如何集成
- 设计前端首要条件：了解前端系统与其他系统之间的联系
- 关系包括：业务关系和协作机制
- 设计后端：只需要规定与后台数据传递的机制
- 包括：api设计规则，访问授权的一个开放标准（OAuth）跳转token的验证，数据传递cookie等
- 前端与后端的关系考虑的主要因素是：前后端分离的架构设计
- 前后端分离架构其实是如何实施技术决策，用户鉴权，API接口管理和设计，API文档管理，mock的使用，BFF（服务于前端的后端，node.js）是否需要服务端渲染等
微前端
- 在一个系统内微前端是应用间的架构方案
- 在多个应用之间，微前端则是一种系统间的架构方案
- 微前端是将多个前端应用以某种形式结合在一起进行应用
- 旨在解决单体应用在一个相对长的时间跨度下，由于参与的团队人员的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题
单实例
- 即同一个时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期
多实例
- 通常基于url的变化，来做子应用的切换，同一时刻，可展示多个子应用
- 通常使用web components方案来做子应用封装，子应用更像是一个业务组件而不是应用
应用级架构
- 应用级架构可以看作是系统架构的组件
- 单个应用与其他外部之间的关系，微服务架构下多个应用的协作，数据交换等
应用级架构包括
- 脚手架
- 模式库
- 设计系统
模块级架构
- 这部分内容是我们开始业务编码之前进行设计，我们称之为迭代
代码级架构
主要是规范与原则
- 开发流程
- 代码质量以及改善
- 规范而非默契
注意
- 在开发中，要注意可维护性
- 简单的代码可维护性高；越是写的抽象的代码越难维护
如何保证架构的质量————稳定性和健壮性
系统的稳定性
- 定义：当一个实际的系统处于一个平衡的状态时，如果受到外来作用的影响时，系统经过一个过渡过程仍然能够回到原来的平衡状态，我们称这个系统就是稳定的，否则称系统不稳定
- 时架构设计的基石
- 可以更好的实现自我修复
系统的健壮性
- 定义：计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件健壮性的具体表现
- 解释：一个系统容错能力强，运行不易被干扰，安全性好
健壮性的度量标准
- 一个软件可以从错误的输入推断出正确合理的输入
- 一个软件可以正确的运行在不同环境下
- 一个软件能够检测自己内部的设计或者编码错误，并得到正确的结果
系统的健壮性和稳定性
- 健壮性和稳定性时特定的软件自身的要求
- 健壮性和稳定性时软件处理的一部分
- 软件架构的健壮性和稳定性是该软件规划时所确定的目标
- 若软件的实现未达到原定目标，则该软件的健壮性和稳定性不够或不好
架构质量的衡量
- 拓展性
- 维护性
- 可管理
- 高可用（故障修复、容灾、降级、熔断）
日常开发过程中的架构质量
- 理解难度
- 接入依赖的成本
- 崩溃率和错误率的指标
- 开发效率
- 错误上报和信息收集等功能