系统设计理论基础

设计系统的工程师叫做架构师，就如同几千年之前的鲁班一样，设计出了精妙绝伦的系统。

架构不是一成不变的，从最早的单体服务，到如今的分布式服务，微服务，云原生，这要求架构师要不断的学习，变化是最重要的设计考虑因素。

世界上不存在银弹，或许你钟爱某一种形式的设计，但是技术不分好坏，我们总是在寻求利弊而已，我们架构师要做的不过是取舍。一切皆是权衡。

技术广度和深度

架构师需要掌握的技能，从技术角度分为技术广度和深度。通常来说，对于架构师，广度的重要性大于深度，没有广度就无法纵观全局。

架构师不可能在所有领域都保持一定的深度，这不现实，人不会有这么多的空余时间，我的建议是，在某个领域保持绝对的技术深度的同时，提高自己的技术广度，就好比，你是局长兼某科科长，在你的科你的技术是绝对的一流，但你还是局长，必须要了解其它科的技术，才能真正的掌握全局。

权衡利弊

微服务一定比单体服务优秀吗？异步通信就是比同步通信好吗？

这个世界是现实的，任何的好处都是有代价的，微服务在可扩展性，高可用性等特征上的确比单体服务优秀，但是它要比单体服务性能更差，复杂度也高很多，花费也要高很多，当我们面向一个场景简单，用户量低的场景下，毫无疑问，选择单体服务是更好的选择。

架构选择没有对错，只有取舍和适合。

模块化

模块化的概念是什么？

我给出一个定义，构建更复杂结构中的一组标准化零件，一个复杂结构中的独立单元。一个函数就是整个代码集群中的一个模块，一个数据库组件就是数据库集群中的一个模块。

我们使用三个标准去评估模块之间的关系：

• 內聚性
• 耦合
• 共生性

內聚性：

也称之为内聚力，高内聚的模块指的是：功能单一，独立性强，逻辑清晰，如果分割该模块将得到更坏的结果

耦合：

耦合度，指的是模块间的依赖关系，高耦合的模块指的是：模块间的依赖关系过多，模块间的修改会相互影响，如果分割该模块将得到更坏的结果

共生：

模块间的依赖关系，如果一个组件的变更需要修改另一个组件才能保证系统整体的运行，那么他们之间是共生关系

一个合理的共生关系通常是合理的。通常来说，弱共生关系更合理

高内聚低耦合的好处

高内聚的好处

提高软件质量：

• 功能明确：每个模块专注于特定的任务，使得代码逻辑更加清晰，易于理解和维护。开发人员可以快速定位问题所在，减少错误的发生。
• 可靠性高：由于模块内部的紧密协作，其功能实现更加稳定可靠。一个高内聚的模块通常经过良好的设计和测试，能够在各种情况下正确执行其特定任务。

增强可维护性：

• 易于修改：当需要对软件进行修改时，高内聚的模块可以独立进行修改，而不会对其他模块产生过多的影响。这大大降低了维护成本和风险，提高了维护效率。
• 可扩展性强：可以方便地在不影响其他模块的情况下，为高内聚的模块添加新的功能或改进现有功能。这种可扩展性使得软件能够适应不断变化的需求。

提升开发效率：

• 分工明确：开发人员可以根据模块的功能进行分工合作，提高开发效率。每个开发人员专注于特定的模块，能够更好地理解和实现其功能，减少开发过程中的冲突和重复工作。 可重用性高：高内聚的模块通常具有较高的可重用性，可以在不同的项目或系统中重复使用。这不仅节省了开发时间，还提高了代码的质量和一致性。

低耦合的好处

提高软件的灵活性：

• 易于替换：当需要更换某个模块时，低耦合的设计使得可以轻松地替换该模块，而不会对其他模块产生重大影响。这为软件的升级和改进提供了更大的灵活性。
• 适应变化：低耦合的软件能够更好地适应需求的变化。当需求发生变化时，可以只对受影响的模块进行修改，而不会波及整个系统。

增强软件的可维护性：

• 独立测试：低耦合的模块可以独立进行测试，这使得测试更加容易和高效。可以针对每个模块编写独立的测试用例，确保其功能的正确性，而不需要考虑其他模块的影响。 降低维护成本：由于模块之间的依赖关系较少，维护一个低耦合的软件系统相对容易。当出现问题时，可以快速定位问题所在的模块，并进行修复，而不会影响到其他模块。 提高软件的可扩展性：
• 方便添加新功能：低耦合的设计使得可以方便地添加新的模块或功能，而不会对现有系统造成太大的影响。新的模块可以独立开发和测试，然后与现有系统进行集成。
• 支持分布式开发：低耦合的软件更适合分布式开发，不同的开发团队可以独立开发不同的模块，然后进行集成。这种开发方式可以提高开发效率，降低开发风险。

架构特征

功能性相关

• 可用性：指系统或产品能够被正常使用的程度。
• 性能：系统或产品在运行时所表现出的各种能力指标。
• 可扩展性：系统能够方便地进行功能扩展。
• 弹性：系统能够适应变化和压力的能力。
• 高效性：强调系统在执行任务时能够以较少的资源消耗实现较高的产出。

安装与部署相关

• 可安装性：系统或产品能够在特定环境中成功安装的容易程度。
• 兼容性：指系统能够与其他不同的软件、硬件或系统协同工作的能力。

维护与管理相关

• 可维护性：系统易于进行维护和修复的程度。
• 可支持性：系统能够获得技术支持和维护的程度。
• 可测试性：系统易于进行测试，以便发现和修复潜在的问题。
• 可观察性：可以对系统的运行状态进行监控和观察。

数据与资源管理相关

• 可重复利用性：可以多次使用系统的某些部分或整体。
• 可归档性：系统或数据能够被有效地存档保存。
• 准确性：对于数据处理或计算任务，确保结果的准确无误。

用户体验相关

• 易用性：系统易于使用和操作的程度。
• 可访问性：确保用户能够方便地访问系统或获取信息的程度。
• 可定制性：允许用户根据自己的特定需求对系统进行个性化设置和调整。

安全与合规相关

• 可恢复性：系统在出现故障或问题后能够恢复到正常状态的能力。
• 安全性：保障系统免受各种安全威胁。
• 认证：确认用户或系统的身份、真实性等的过程。
• 授权：给予特定用户或实体特定的权利或权限。
• 可审计性：能够对系统的操作和数据访问进行记录和审查。
• 法律：与系统或业务相关的法律法规要求。
• 隐私性：保护用户或系统的私密信息不被泄露的特性。

其他特性

• 连续性：事物持续不间断的状态。
• 稳定性：系统在长时间运行过程中保持可靠。
• 及时性：系统能够在规定的时间内完成任务或响应请求。
• 互操作性：不同的系统或组件之间能够进行有效的交互和协作。

给架构师的忠告

第一条，不要执迷于架构特征的数量，要尽可能保证简单，举个例子，一个用户量只有几万的小项目，你不能执迷于可扩展性，弹性，高可用性这种架构特性，它要的就是简单而已，做好一定的限流措施，就够了。

第二条，确定系统特性的优先级，比如，我确定了，弹性和性能是优先级，那么该系统的设计就主要围绕这些特性去设计。

第三条，架构师跟外人沟通的时候要使用通用语言，比如，把可行性和简单行改成预算低，时间短，把性能，容错，降级等改成用户满意度，记住，架构师不仅仅是一个技术人员，也是技术管理者，当一个管理者要沟通的时候，他应该使用通用语言，而不是他的专有语言。

第四条，架构师应该会从需求中提炼架构特征，比如，1 万人的学校，需要一个搜索系统，那么你可以提取需要的架构特征，人数不大，可用性要高，预算可能不是太充足，所以后期运维要简单，比如一个企业，员工 100 万，需要一个财务系统，那么这个系统就跟刚才的不同，需要满足高可用行，高性能，需要考虑容灾和服务降级，需要考虑高防护性

kata (opens new window) 是架构师 ted neward 创建的架构设计训练网站，里面有很多的需求，我们可以使用这个网站去锻炼自己提取需求的能力，设计架构的能力