系统架构设计知识体系总结
1.技术选型
1.什么是技术选型？
技术选型是指评估和选择在项目或系统开发中使用的最合适的技术和工具的过程。这涉及考虑基于其能力、特性、与项目需求的兼容性、可扩展性、性能、维护和其他因素的各种可用选项。技术选型的目标是确定与项目目标相符合、能够有效解决项目挑战和目标的最佳技术。
技术选型的过程通常包括：
项目评估：了解项目的目标、需求、约束和范围，以确定需要哪些技术。
研究：对不同技术、框架和工具进行彻底的研究，以满足项目的潜在需求。
比较：评估每种技术选项的优势和劣势，考虑功能、性能、社区支持、可扩展性、安全性和成本等因素。
概念验证：构建原型或进行小规模实验，以验证在项目中使用特定技术的可行性。
风险分析：识别与每个技术选择相关的潜在风险，包括兼容性问题、学习曲线、厂商依赖性和未来支持等。
专家咨询：寻求对所考虑技术有经验的专家、同事或行业专业人士的建议。
长期可行性：评估所选技术的长期可行性和未来增长潜力，以确保其能够在一段时间内保持相关性和支持。
成本考虑：评估实施和维护所选技术的初期和长期成本。
反馈与迭代：在选型过程中融入利益相关者、开发人员和用户的反馈，以确保与其需求保持一致。
决策：基于对选项及其影响的全面理解做出明智的决策。
有效的技术选型至关重要，因为技术选择可以显著影响项目的成功。恰当选择的技术可以简化开发流程、提高性能、改善用户体验并促进长期维护。另一方面，糟糕的技术选型可能导致项目延迟、增加成本、兼容性问题甚至项目失败。因此投入时间和精力进行研究、比较和选择合适的技术是实现成功项目成果的基本步骤。
2.为什么要技术选型？
技术选型的重要性体现在以下几个方面：
- 满足项目需求： 不同的项目有不同的需求和目标。技术选型可以确保所选的技术和工具能够满足项目的功能、性能、安全性和可扩展性等需求。
- 提高开发效率： 选择合适的技术可以加快开发过程，减少开发人员的工作量。适合项目的技术能够提供更多的开发工具、库和框架，从而简化开发流程。
- 优化性能： 不同技术在性能方面有所差异。选择性能良好的技术可以确保项目具有快速的响应时间和高效的运行。
- 降低风险： 经过充分的调研和验证后，选择合适的技术可以降低项目失败的风险。避免了可能的技术问题和不稳定性。
- 适应未来发展： 选用能够适应未来技术发展的技术，可以延长项目的寿命并减少技术迁移的成本。
- 提高用户体验： 选择适合项目的技术可以提供更好的用户体验，包括更快的加载时间、友好的界面和响应式设计等。
- 降低成本： 正确选择技术可以减少项目开发和维护的成本。合适的技术可以减少不必要的资源浪费。
- 避免厂商锁定： 在技术选型时，考虑到技术的开放性和厂商支持，可以避免在未来被特定供应商限制。
- 可维护性： 选择易于维护的技术可以确保项目在长期内保持稳定和可维护。
- 支持社区： 选择有活跃社区的技术可以获得更多支持、文档和解决问题的资源。
综上所述，技术选型是项目成功的关键因素之一。通过仔细考虑项目需求、调研不同的选项、验证适合性并做出明智的决策，可以确保项目在开发、上线和维护过程中取得更好的成果。
3.技术选型案例
跨境电商企业在技术选型时选择了Service Mesh Istio，但是在没有经过充分调研和验证的情况下，直接在开发环境中部署。这导致了一系列问题，包括项目延迟和长时间的适应期，最终影响了项目的正式上线。
从中提取出了一些重要的教训：
- 充分调研： 在决定采用新技术之前，进行充分的调研，了解技术的特点、优势、劣势以及适用场景。不要轻率地选择技术，而是确保它能够满足项目需求。
- 小规模尝试： 在大规模采用之前，尝试在小规模环境中引入新技术。这有助于发现潜在问题、了解技术的运作方式，并在实践中积累经验。
- 验证和适应期： 对于新技术，预留一段适应期是很重要的。技术的实际表现可能与预期不同，因此给予项目团队足够的时间来适应和解决问题是必要的。
- 项目风险： 技术选型不仅需要考虑技术本身的特点，还需要考虑其可能引发的项目风险。不稳定的技术可能导致项目延迟、成本增加等问题。
- 经验积累： 通过小规模引入和验证，项目团队可以积累关于技术的经验，了解如何优化和解决潜在问题。
综合来看，这个案例强调了在技术选型中谨慎而有计划的重要性。不要急于采纳新技术，而是通过调研、验证和小规模试验来确保技术能够稳定地支持项目的成功实施。
2.系统设计方法
1. 前端
2. 后端
3. API gateway网关架构
4. 7种分布式系统设计模式
5. 6种API架构风格
6. 常见应用架构模式
7. api安全的12个要点
8. 提升api性能的7中方法
9. 系统设计应遵循的原则
10. Redis常见用法
11. 25篇经典分布式架构设计论文
12.DevOps&SRE
13. 5种部署方法
3.微服务架构方法
1.微服务架构设计理论
1.NFR(非功能性需求)：
2.架构的构成元素：
3.软件架构的4+1视图模型
4.编写FTGO应用架构文档案例
4+1视图架构：
架构愿景（vision）
系统上下文
架构涉及的核心用户故事和场景
非功能性需求：
编写服务清单文档
编写服务领域模型文档
记录架构决策
总结
2.微服务设计模式
4.云原生架构要点
0.架构演进的过程
1.云原生应用设计的12个要素
基准代码：指代码版本管理，基于同一个版本代码开发
依赖：显式的依赖
配置：代码与环境配置分开
进程：应用以一个或多个进程进行运行，应用无状态
端口绑定：端口与服务绑定
日志：日志以事件流的形式来看，方便处理
2. 云原生架构
3.下一代云原生架构serviceMesh(服务网格化)
微服务与Service Mesh 的区别和联系：
4.Docker
Docker原理
5.k8s
k8s架构
5.代码审查清单
常规项
- 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
- 所有的代码是否简单易懂？
- 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
- 是否存在多余的或是重复的代码？
- 代码是否尽可能的模块化了？
- 是否有可以被替换的全局变量？
- 是否有被注释掉的代码？
- 循环是否设置了长度和正确的终止条件？
- 是否有可以被库函数替代的代码？
- 是否有可以删除的日志或调试代码？
安全
- 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
- 在哪里使用了第三方工具，返回的错误是否被捕获？
- 输出的值是否进行了检查并且编码？
- 无效的参数值是否能够处理？
文档
- 是否有注释，并且描述了代码的意图？
- 所有的函数都有注释吗？
- 对非常规行为和边界情况处理是否有描述？
- 第三方库的使用和函数是否有文档？
- 数据结构和计量单位是否进行了解释？
- 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？
测试
- 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
- 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
- 单元测试是否真正的测试了代码是否可以完成预期的功能？
- 是否检查了数组的“越界“错误？
- 是否有可以被已经存在的API所替代的测试代码？
6.参考资料
- 《微服务架构设计模式》 & 代码： https://github.com/microservices-patterns/ftgo-application
- 微服务理论网站：
https://microservices.io/
https://eventuate.io/