别再瞎设计！从0到1构建高可用系统：架构师的10条"潜规则"

文 / Kenyon，10多年技术开发和管理经验，从程序员到技术总监，目前专注于技术团队管理、架构设计和AI落地实践，欢迎关注我一起学习交流。

由于公众号推流的原因，请在关注页右上角加星标⭐️，这样才能及时收到新文章的推送。

在前几篇文章中，我们探讨了关于团队和个人的价值层次还有个人该如何给团队赋能的内容。接下来我想跟大家去探讨系统架构方面的内容，今天，让我们先深入探讨架构设计中更底层的逻辑——架构设计原则，这些被称为"黄金法则"的指导思想，是构建高质量系统的基础。

作为长期从事架构设计实践的"老司机"，我见证了太多团队因为缺少对核心设计原则的理解和应用，导致系统随着业务发展变得臃肿、难以维护，甚至不得不进行大规模重构。架构设计原则就像建筑设计中的"力学定律"，它们不是束缚创造力的枷锁，而是让创意能够落地并持久的保障。

核心观点：架构设计原则是系统设计的"指南针"，它们帮助我们在复杂的技术选择中做出正确的决策，构建出高内聚、低耦合、可扩展、可维护的系统。

一、基本设计原则：SOLID原则的"五根支柱"

打个比喻，如果把架构设计比作一座大厦，那么基本设计原则就是大厦的"地基"。SOLID原则作为面向对象设计的核心原则，为我们提供了构建高质量软件的基础框架。

1.1 单一职责原则（Single Responsibility Principle，SRP）

• 定义：一个模块只有一个主要的职责
• 应用：每个组件只负责一个明确的功能，不同类型的功能应该由不同的组件负责
• 好处：降低模块之间的耦合度，提高内聚，便于系统和模块后续的维护

实战要点：

• 避免出现"万能类"或"万能模块"的情况，每个类或模块都应该有一个明确的职责
• 当你需要去修改一个类或模块的时候，要先问问自己："这次修改的内容是否属于它的核心职责？"，如果是，那么就可以修改；如果不是，那就需要考虑是否应该将这个功能拆分成一个新的类或模块。

1.2 开闭原则（Open-Closed Principle，OCP）

• 定义：类、模块等软件实体应该对扩展开放，对修改关闭
• 应用：通过抽象和多态实现功能的扩展，避免直接修改已有的代码
• 好处：提高系统的稳定性的同时，还能支持灵活地扩展系统地功能

实战要点：

• 使用接口或抽象类定义稳定的契约
• 通过继承或组合实现功能扩展，而非直接修改现有代码

1.3 里氏替换原则（Liskov Substitution Principle，LSP）

• 定义：子类应能替换父类而不破坏程序正确性
• 应用：确保继承关系的正确性
• 好处：确保继承体系的契约一致性，避免继承滥用

实战要点：

• 子类必须完全实现父类的抽象方法
• 子类不能违背父类的约定（如前置条件、后置条件）

1.4 接口隔离原则（Interface Segregation Principle，ISP）

• 定义：客户端应依赖于最小的接口集合，不应该依赖它不需要的接口
• 应用：设计小而专一的接口，而不是大而多功能的接口
• 好处：减少不必要的依赖，降低接口复杂性，提高接口的灵活性和独立性

实战要点：

• 避免设计"胖接口"，将大接口拆分为多个小接口
• 接口应该只包含客户端需要的方法

1.5 依赖倒置原则（Dependency Inversion Principle，DIP）

• 定义：高层模块不应该依赖低层模块，都应该依赖抽象
• 应用：通过依赖注入实现解耦
• 好处：提高系统的灵活性和可测试性

实战要点：

• 依赖抽象类或接口，而非具体实现类
• 使用依赖注入容器管理对象依赖关系

二、架构设计原则：构建系统的"上层建筑"

如果说基本设计原则关注的是"如何设计好一个类或模块"，那么架构设计原则关注的是"如何设计好整个系统"。

2.1 分离关注点（Separation of Concerns）

• 定义：将复杂问题分解为独立的关注点
• 应用：按功能、层次、职责分离系统
• 实现方式：
  • 分层架构：按技术层次分离系统，如我们常见的Model、View、Controller的MVC架构
  • 模块化：按功能领域分离系统，如按业务功能或技术组件来组织代码，比如公共代码模块、数据访问模块、业务逻辑模块（还可以继续分用户模块、订单模块、支付模块等）等
  • 服务化：按业务能力分离系统，如微服务架构，将系统拆分成多个独立的服务，每个服务负责一个明确的业务功能

实战要点：

• 每个关注点应该有明确的边界
• 关注点之间的通信应该通过明确定义的接口或者是事件来进行

2.2 高内聚低耦合（High Cohesion, Low Coupling）

• 内聚性：模块内部元素的相关程度
• 耦合性：模块间的依赖程度
• 目标：提高内聚性，降低耦合性
• 实现方式：
  • 明确的接口定义：模块之间通过接口或者事件进行通信，而不是直接调用彼此的方法
  • 最小化依赖关系：每个模块只依赖于必要的其他模块，避免依赖于过多的模块
  • 使用抽象层隔离变化：通过抽象层（如接口、抽象类）隔离模块之间的变化，使系统更灵活

实战要点：

• 模块内部的功能应该高度相关
• 模块之间的依赖应该越少越好，依赖关系应该越弱越好

2.3 抽象与封装（Abstraction and Encapsulation）

• 抽象：隐藏复杂性，突出本质特征
• 封装：隐藏实现细节，提供稳定接口
• 应用：
  • API设计：提供简洁的接口
  • 数据封装：隐藏数据结构细节
  • 服务封装：隐藏业务逻辑实现

实战要点：

• 抽象类和方法的时候应该抓住问题的本质，忽略次要细节
• 封装应该提供足够的抽象，同时隐藏内部实现

2.4 可扩展性设计（Scalability Design）

• 水平扩展：可以不断地增加更多的服务器实例来分担负载
• 垂直扩展：增强单个服务器的能力，如升级硬件、增加内存等
• 设计考虑：
  • 无状态设计：每个请求都是独立的，不依赖于之前的请求状态
  • 数据分片策略：将数据分布到多个服务器实例，避免单点故障
  • 负载均衡机制：将请求分发到多个服务器实例，避免过载
  • 缓存策略：缓存热数据，减少数据库访问次数

实战要点：

• 优先考虑水平扩展，因为它比垂直扩展有更好的伸缩性，而且基本不用停机维护
• 设计系统时要考虑未来的增长需求，提前预留好扩展空间，避免因为系统负载增加而导致的性能问题

2.5 容错与恢复（Fault Tolerance and Recovery）

• 故障预防：通过设计避免故障发生
• 故障检测：及时发现系统故障
• 故障隔离：防止故障扩散
• 故障恢复：快速恢复系统服务
• 实现模式：
  • 断路器模式
  • 重试机制
  • 降级策略
  • 备份恢复

实战要点：

• 在设计系统时，要考虑如何做好故障隔离和恢复机制，比如可以假设所有上游接口系统和依赖的模块都可能失败
• 设计系统时要考虑各种故障场景，如数据库故障、网络故障、服务器故障等
• 做好系统的监控和告警，及时发现故障，快速定位问题根源

三、架构设计原则的实战应用：从理论到实践

3.1 原则应用的优先级

在实际项目中，我们不可能同时完美地应用所有原则，需要根据项目的实际情况确定优先级：

• 小型项目：可以更关注基本设计原则（SOLID），快速交付功能
• 大型项目：需要更关注架构设计原则，确保系统的可扩展性和可维护性
• 高并发系统：需要特别关注可扩展性和容错设计
• 长期维护的系统：需要平衡所有原则，确保系统的稳定性和可维护性

3.2 原则之间的平衡

架构设计原则之间有时会存在冲突，需要在实际应用中进行平衡：

• 单一职责原则 vs 高内聚低耦合：单一职责可能导致模块过多，增加系统复杂性
• 开闭原则 vs 简单性：过度设计可能导致系统过于复杂，影响开发效率
• 可扩展性 vs 性能：某些扩展性设计可能会影响系统性能

实战建议：

• 不要为了遵循原则而遵循原则，原则是手段，不是目的
• 每个项目都有其独特性，需要根据实际情况灵活应用原则
• 在应用原则时，要考虑投入产出比

四、常见误区：避免原则应用的"陷阱"

在架构设计原则的应用过程中，我总结了几个常见的误区：

4.1 过度设计

• 表现：为了未来可能的需求，过度应用各种原则，导致系统过于复杂
• 解决方法：遵循"YAGNI"（You Ain't Gonna Need It）原则，只设计当前需要的功能

4.2 教条主义

• 表现：严格遵守原则，不考虑项目的实际情况
• 解决方法：将原则作为指导思想，而非硬性规定

4.3 忽视权衡

• 表现：只关注某一个原则，忽视其他原则的影响
• 解决方法：在应用原则时，要考虑原则之间的相互影响和平衡

4.4 缺乏实践

• 表现：只了解原则的理论，缺乏实际应用经验
• 解决方法：在实际项目中应用原则，通过实践加深理解

五、总结与行动建议

架构设计原则是架构师的"工具箱"，它们帮助我们在复杂的技术选择中做出正确的决策。好的架构不是设计出来的，而是演进出来的，而架构设计原则就是指导这个演进过程的"指南针"。

给架构师的3个行动建议：

1. 理解原则的本质：不要只记住原则的名称和定义，要理解它们背后的思想和目的
2. 在实践中应用：选择一个正在进行的项目，尝试应用这些原则，在实践中学习和提高
3. 持续反思和改进：定期回顾系统架构，思考如何更好地应用原则，不断优化系统设计

记住架构设计的核心理念："好的架构应该是简单的、清晰的、可扩展的、可维护的"——这也是我们应用架构设计原则的最终目标。

---

互动话题：作为架构师，你在应用架构设计原则时，遇到过哪些挑战？是如何克服的？欢迎在评论区分享你的经验。

关于作者

Kenyon，资深软件架构师，15年的软件开发和技术管理经验，从程序员做到企业技术高管。多年企业数字化转型和软件架构设计经验，善于帮助企业构建高质量、可维护的软件系统，目前专注技术管理、架构设计、AI技术应用和落地；全网统一名称“六边形架构”，欢迎关注交流。

原创不易，转载请联系授权，如果觉得有帮助，请点赞、收藏、转发三连支持！