设计模式: 关于项目架构，架构质量, 系统稳健性，技术选型，技术债务问题与解决方案

设计模式: 关于项目架构，架构质量, 系统稳健性，技术选型，技术债务问题与解决方案

正确的选择是良好的开端

1 ）指标

• 系统稳定性
• 系统健壮性

2 ) 衡量

• 在概念层次衡量架构质量
• 在实际开发中衡量架构好坏

3 ) 架构分类

• 系统架构
  • 从系统维度，负责整体系统的架构设计
  • 基础服务和各系统间协调，着眼全局
  • 比如关注负载，可靠性，伸缩，扩展，整体项目切分，缓存应用等方面的基础架构设计
  • 偏向于对技术的架构设计
• 应用架构
  • 从应用程序的维度，负责某个应用的技术架构，主要偏向业务系统
  • 关注理解业务，梳理模型，设计模式，接口，数据交互等方面
  • 主要思考，如何让业务更好实现，如何让数据更好的交互，什么设计更好的拓展
  • 需要了解整体业务系统怎样流转，针对所有业务系统做架构设计
• 业务架构
  • 从业务流程维度，关注某一个行业，业务领域分析，获取领域模型，最终获得系统模型
  • 也可叫业务领域专家，行业专家，产品咨询师，资深顾问
  • 所做事情脱离具体开发任务，比如数据分析和模型建设来推动业务发展
• 如何选择
  • 特别关注技术，朝着系统架构师方向发展
  • 业务与技术并存，了解技术在业务里如何应用，每个应用间的交互，朝着应用架构师方向努力
  • 如何希望脱离具体开发任务，只需要关注数据系统模型，得到结论，就要朝着业务架构师方向发展

关于架构质量

1 ) 架构质量的衡量

• 易于拓展的设计：复杂逻辑的添加不会影响系统架构设计，简单功能向高级功能的过渡
• 易于维护的设计：当前发现的问题可以以最快的时间定位和解决
• 可管理：对整体的架构设计，需要进行合理化管控，如果当前架构设计超出管控范围，则不可控
• 高可用：故障修复，容灾，降级，熔断

2 ）日常开发过程中的架构质量

• 理解难度
  • 当前架构设计对整体软件开发人员的理解成本很高，这种是不太好的，需要改良，让开发人员更好的理解
• 接入依赖的成本
  • 如果当前的设计在接入依赖时，需要变动整体架构的核心内部，或大量变动核心代码，这种是有问题的
  • 让整体的架构设计是可拓展的，便于接入依赖，提升整体架构的拓展性，保证健壮性和稳定性
• 崩溃率和错误率的指标
  • 如果一个应用的错误率和崩溃率达到了5%以上，整体的架构设计是一个失败的架构设计
  • 崩溃率和错误率已经超标，用户和自己在使用的时候，是不信任的，也即是说整体的架构设计是失败的
• 开发效率
  • 本质而言，在做开发过程中的所做的架构设计都是被业务和技术赋能的
  • 如果某一个设计，降低了开发效率，这时候需要思考哪些是不合理的地方
• 错误上报和信息收集的功能
  • 当发生问题时，可快速定位到问题发生的目标点
  • 收集信息以分析错误产生的原因
  • 如果不具备这类功能，则很难定位和修复

关于系统稳健性

1 ) 稳定性

• 当一个实际的系统处于一个平衡的状态时候，如果收到外来作用的影响时
• 系统经过一个过渡过程仍然能够回到原来的平衡状态，我们称这个系统就是稳定的，否则称系统不稳定
• 它的特点是架构设计的基石，可以更好的实现自我修复

2 ) 健壮性

• 计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机，不崩溃，就是该软件健壮性的具体表现
• 也就是说：一个系统的容错能力强，运行不易被干扰，安全性好
• 别名：鲁棒性

3 ) 度量标准

• 一个软件可以从输入推断出正确合理的输出
• 一个软件可以正确的运行在不同环境下
• 一个软件能够检测自己内部的设计或编码错误，并得到正确结果

4 ) 系统健壮性和稳定性的补充

• 健壮性和稳定性是特定的软件自身的要求
• 健壮性和稳定性是软件处理的一部分
• 软件架构的健壮性和稳定性是该软件规划时所确定的目标
• 若软件的实现未达到原定目标，则该软件的健壮性和稳定性不够或不好

技术前期准备

• 技术选型

  • 社区氛围，发展规模，未来发展趋势，与当前团队的契合度，执行成本，维护和迁移成本，执行效率等内容的调研和报告
  • 根据报告内容做一些取舍，选定当前技术类型，通过技术类型进行开发
  • 充分调研每一项技术带来的利弊，根据利弊进行取舍，得到最优组合
  • 最大程度上预测架构设计中的缺陷，防止问题的发生
  • 凡是不打无准备之仗

• 技术优化

  • 在架构发展过程中，可能会存在一些有悖于当前架构设计的实现，造成了架构发展阻塞，所以需要进行架构优化，使架构设计的适应性更高

• 架构优化

  • 架构不是一蹴而就的，在业务发展过程中，架构也在不断演进
  • 对架构设计进行实时调优，使架构优化成为常态化
  • 通过不断的调整架构实现，改进初始架构中设计的不足，补足短板

技术债务

• 开发过程中因为时间紧迫导致的实现不合理
  • 举例：查找100000以内的质数
  • 算法不同，效率不同，好算法和坏算法的时间
• 开发过程中暂时没有想到更好的实现方式而妥协的版本
  • 刚开始使用if…else实现
  • 使用责任链模式来进行改进：每个函数都可以独立出来，作为一个判断条件使用
  • 作为整体使用不好，使用责任链使用会让复用性提高，维护性提高
• 架构设计前期没有考虑到的一些细节
  • 交互细节 -> props传递参数 (交互冗余，流程较长)
  • 使用全局状态管理实现参数传递
• 不合理的交互设计，导致技术实现复杂
  • 交互设计的难度，正确和设计人员沟通
  • 减少这类问题出现
• 旧功能文档缺失，无正确拓展，修改和兼容旧功能，导致上线后问题剧增
  • 无技术文档，技术功能没有预留出修改和兼容的接口
  • 新开发功能要预留兼容旧功能的接口
  • 让旧功能逐步符合当前架构设计的内容
  • 阶段性重构，将旧功能变为新功能的实现

不修复技术债务的后果

1. 修复变成重构：新功能要兼容旧功能的逻辑，有些旧功能无法兼容就不得不修改旧功能，导致重构，导致排期的影响
2. 小的技术债务不做偿还，最后会演变为一场大规模的重构工作，导致产出不高
3. 影响开发速度
4. 导致整体开发需要兼容的点较多，影响开发效率和上线速度，导致整体项目迭代缓慢，失去核心竞争力(项目是企业战略落地的载体)
5. 容易陷入，维护旧功能，开发新功能，兼容旧功能，维护旧功能，开发新功能的恶性循环

技术填补的解决方案

1. 优秀的架构设计是基础
2. 当前架构设计，能够有效处理当前需求可预见的情况，对于未知的，可能出现的特殊情况，很小的改动就能解决问题
   • 2.1 我们的架构应该是简练的，精简的，对于一些可预见的问题，不建议做一些功能处理，只需要做一些预留接口即可
3. 根据当前的业务，进行合理的项目拆分，尽量的代码解耦合
4. 必须有日志模块，操作日志，错误日志，业务日志等等
5. 良好的技术培训和传帮带能力
6. 让每一位开发者可以从更深一层次理解所需要实现的功能
7. 从最开始的代码规范，到熟悉业务，最后再到编写文档
8. 充分的技术方案可避免一部分技术债务的产生
9. 技术方案是充分理解需求之后所能产出的对需求理想的实现方式，必要性不言而喻
10. 不同工程师之间可以相互review代码，避免当局者迷出现，codeReview是非常重要的，同时也是对自身的一个提高
11. 提升对修复技术债务重要性的认知
12. 工程师如果能预见一个债务可能导致的问题，自然愿意花时间去处理
13. 善于发现和定期处理一些技术债务问题
14. 勇于发现系统中的技术债务，让自己为系统负责
15. 让自己为系统负责

总结

• 等产品和功能上线后，开发就没有那么紧张了，可以找个时间来处理技术债务
• 技术债务不仅仅是研发这个部门的责任, 需要联合测试和业务部门才能实现
• 所以，技术负责人和架构师请谨慎对待技术债务，否则可能会导致成本增加和线上风险
• 如果项目节奏正常，合格的技术负责人，架构师在提测之前就需要处理好这些问题
• 代码review是一个重要的工作, 团队代码review是一种共同学习的方式