简介
架构分类
- 系统级架构
- 设计前端首要条件：了解前端系统与其他系统之间的关系。
- 关系包括：业务关系和协作机制。
- 设计后端：只需要规定与后台数据传递的机制。
- 包括：api设计规则，访问授权的一个开放标准(OAuth）跳转token的验证，数据传递cookie等。
- 前端与后端的关系考虑的主要因素是：前后端分离的架构设计。
- 前后端分离架构其实是如何实施技术决策，用户鉴权、API接口管理和设计、API文档管理、Mock的使用、BFF(服务于前端的后端,nodejs)，是否需要服务端渲染等。
- 应用级架构
- 应用级架构可以看作是系统级架构的细化。
- 单个应用与其他外部应用的关系，微服务架构下多个应用的协作，数据交换等。
- 脚手架
- 模式库
- 设计系统
- 代码级架构
- 开发流程。
- 代码质量以及改善。
- 规范而非默契。
- 在开发中，要注意可维护性。
- 简单的代码可维护性高；越是写的抽象的代码越难维护。
- 模坱级架构
- 这部分内容是我们开始业务编码之前进行设计，我们称为迭代。
- 微前端
- 在一个系统内微前端是应用间的架构方案。
- 在多个应用之间，微前端则是一种系统间等架构方案。
- 微前端是将多个前端应用以某种形式结合在一起进行应用。
- 旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、国队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的题。
- 单实例：即同一时刻 ，只有一个子应用被展示，子应用具备一个完整应用生命周期。
- 多实例：通常基于 url 的变化来做子应用的切换。
- 多实例：同一时刻可展示多个子应用。
- 通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。
架构师分类
- 系统架构师
- 从系统的维度，负责整体系统的架构设计。
- 主要是基础服务和各系统间协调，着眼全局。
- 比如关注负载，可靠性，伸缩，扩展 ，整体项目切分，缓存应用等方面的基础架构设计。
- 应用架构师
- 从应用程序的维度，负责某个应用的技术架构，主要偏业务系统。
- 关注理解业务，梳理模型，设计模式，接口，数据交互等方面。
- 业务架构师
- 从业务流程的维度，关注某，关注某一个行业、业务的领域分析，获取领域模型，最终获得系统的模型。
- 也可以叫业务领域专家、行业专家、产品咨询师、资深顾问。
如何选择技术
- 技术选型：社区氛围、发展规模、末来发展趋势、与当前团队的契合度、执行成本、维护和迁移成本、执行效率等内容的调研和报告。
- 充分调研每一项技术可能带来的利与弊。
- 最大程度上预测架构设计中的缺陷，以防止问题的发生。
架构优化
- 在架构发展过程中，可能会存在一些有悖于当前架构设计的实现，造成了架构发展阻塞，所以需要进行架构优化，使架构设计的适应性更高。
- 架构不是一蹴而就的，在业务发展过程中 ，架构也在不断演进。
- 对架构设计进行实时调优，使架构优化成为常态化。
- 通过不断的调整架构实现，改进初始架构中设计的不足，补足短板。
如何保证架构的质量(稳定性和健壮性)
- 系统的稳定性
- 定义：当一个实际的系统处于一个平衡的状态时，如果受到外来作用的影响时，系统经过一个过渡过程仍然能够回到原来的平衡状态，我们称这个系统就是稳定的,否则称系统不稳定。
- 架构设计的基石。
- 可以更好的实现自我修复
- 系统的健壮性
- 定义：计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下,能否不死机、不崩溃,就是该软件健壮性的具体表现。
- 解释：一个系统容错能力强，运行不易被干扰，安全性好
- 系统的健壮性的度量标准
- 一个软件可以从错误的输入推断出正确合理的输入。
- 一个软件可以正确的运行在不同环境下
- 一个软件能够检测自己内部的设计或者编码错误，并得到正确的结果。
架构质量的衡量
- 拓展性
- 可管理
- 维护性
- 高可用(故障修复，容灾，降级，熔断)
日常开发过程中的架构质量
- 理解难度
- 接入依赖的成本
- 错误上报和信息收集等功能
- 崩溃率和错误率的指标
- 开发效率tip
健壮性和稳定性是特定的软件自身的要求。
健壮性和稳定性是软件处理的一部分
软件架构的健壮性和稳定性是该软件规划时所确定的目标
若软件的实现末达原定目标，则该软件的健壮性和稳定性不够或不好
技术填补与崩溃预防
技术填补
- 技术填补-问题1
- 开发过程中因为时间紧迫导致的实现不合理。
- 举例：查找10000以内的质数。
- 循环的方式。筛选法。
- 技术填补-问题2
- 暂时没有想到更好的实现方式而妥协的版本。
- 刚开始使用话if...else实现
- 演变为使用责任链模式
- 技术填补-问题3
- 架构设计前期没有考虑到的细节。
- 交互细节-＞props传递参数（交互冗余，流程较长）
- 使用全局状态管理实现参数传递。
- 技术填补-问题4
- 不合理的交互设计 ，导致技术实现复杂。
- 技术填补-问题5
- 旧功能文档缺失，无正确拓展、修改和兼容旧功能，导致上线后问题剧增。
- 技术填补-后果1
- 修复变重构。
- 小的技术债务不做偿还，最后会演变成一场大规模的重构工作致产出不高。
- 技术填补-后果2
- 影响开发速度。
- 技术债务的存在导致整体开发需要兼容的点过多，影响开发效率，极大影响上线速度，导致整体项目迭代缓慢，失去核心竞争力。
- 技术填补-后果3
- 容易陷入 维护旧功能一>开发新功能一>兼容旧功能一>维护旧功能一开发新功能……这样的恶性循环
- 技术填补-解決方案1
- 优秀的架构设计是基础。
- 必须能够有效处理当前需求可预见的情况，对于末知的、可能出现的特殊情况，很小的改动就能解决问题。
- 根据当前的业务，进行合理的项目拆分，尽量的代码解耦和。
- 必须有日志模块，操作日志，错误日志，业务日志等等
- 技术填补-解決方案2
- 良好的技术培训和传帮带能力。
- 让每一位开发者可以从更深一层次理解自己所需要实现的功能。
- 从最开始的代码规范、到熟悉业务、最后再到编写文档。
- 技术填补-解決方案3
- 充分的技术方案可避免一部分技术债务的产生。
- 技术方案是充分理解需求之后所能产出的对需求理想的实现方式，必要性不言而喻。
- 技术填补-解決方案4
- 不同工程师之间可以相互review
- CodeReview 是非常重要的，同时也是对自身的一个提高。
- 技术填补-解決方案5
- 提升对修复技术债务重要性的认知
- 工程师如果能预见一个债务可能导致的问题，自然愿意花时间去处理，
- 技术填补-解決方案6
- 善于发现和定期处理一些技术债务。
- 勇于发现系统中的技术债务，让自己为系统负责。
tip
等产品上线后，开发就没有那么紧啦，这个时间大家可以找个时间处理技术债务，一边建立感情，一边品味一下原来的代码，这种感觉极其酸爽
崩溃预防
- 构崩溃是严重的架构设计事故，也是我们需要预防的关键所在。
- 系统崩溃的产生
- 日志记录，如：操作日志，错误日志 ，业务日志等
- 用户行为抓取一>争取在最新时间获取到用户操作链条
- 解决存量问题一>技术债务
- 遏制新增一>减少新增问题的概率
- 对脏数据进行兜底和检验
- 单元测试
- 崩溃报警
- 自动化测试
- 更广的灰度触达
- 性能优化体系
系统重构
架构不是永恒不变的。架构也是具有生命周期的。也会经历 初生、发展、巅峰、衰弱、消亡的过程。
内容包括