文 / Kenyon，资深软件架构师，15年软件开发和技术管理经验，从程序员做到企业技术高管，专注技术管理、架构设计、AI技术应用和落地。
由于公众号推流的原因，请在关注页右上角加星标，这样才能及时收到新文章的推送。
引言
大家好，我是Kenyon！上一篇文章我们聊了架构设计里面的基本设计原则——《SOLID》，如果把架构设计比喻成是一栋大厦，那么SOLID就是这座大厦的“地基”，后续所有的架构设计原则或者是方法都得靠它支撑的，如果没有它的话，架构设计就会变得非常复杂和混乱。接下来今天的这篇文章，我们接着探讨一下其他的一些架构的通用设计原则、方法、模式及相关要考虑的问题。
一、通用设计原则
- YAGNI (You Aren't Gonna Need It) 这个原则的核心意思就是，别搞过度的设计。我们设计的时候就老老实实的把当前必须要有的功能实现了就行了，别老想着“未来可能用得上”，就提前把不必要的功能给设计进来。 就好比在需求还不明确的时候，我们得先把眼前的业务给满足了，别一上来就搞一堆复杂的东西。比如说微服务拆分的时候，需要拆那个就拆那个，别说为了那“可能的扩展性”，就早早地把服务给拆得七零八落的，这样只会得不偿失！
- DRY (Don't Repeat Yourself) 这个原则的核心就是，别让代码、配置或者逻辑出现重复。我们可以通过抽象或者复用的办法，把维护成本给降下来。 在架构层面，重复的情况可不少。像好几个服务都实现一样的权限逻辑，还有重复的配置管理啥的。这时候，我们就可以把公共的能力下沉到中间件或者共享服务里，问题就解决了。
- 高内聚低耦合 (High Cohesion, Low Coupling) 这个原则说的是，模块里面的功能得紧密相关，这就是高内聚；模块和模块之间的依赖得尽量少，这就是低耦合。 比如说服务拆分的时候，得保证每个服务就负责一个单一的业务域。就像订单服务，就只管订单的生命周期。而且模块之间最好通过接口来依赖，别直接依赖实现类，这样耦合度就能降下来。
- 迪米特法则 (Law of Demeter) 这个原则讲的是，一个对象得尽量少去了解其他对象的内部结构，尽量只跟自己直接的调用的类或者模块通信。 在微服务调用的时候，如果不限制好的话，就特别容易出现问题。比如说那种链式调用，serviceA.getServiceB().getServiceC().doSomething() ，这样肯定是不行的啊。我们应该通过API网关或者聚合服务，把依赖给简化简化。
- KISS (Keep It Simple, Stupid)
这个原则的核心就是，能设计多简单就多简单，别整那些不必要的复杂玩意。越简单的系统约靠谱，也好维护，还能快速应对变化。
比如说新项目刚开始的时候，我们就选成熟又简单的技术栈就可以了。接口设计的时候，也别过度设计参数和返回值。代码实现的时候，优先考虑可读性。就像那些产品的日活用户都不到1万的创业公司，就别一上来就用什么服务网格这样复杂的架构了。
二、架构设计方法学
- 领域驱动设计 (DDD) 这方法的核心是以业务领域为中心，通过领域建模来指导架构设计，这里面有聚合、实体、值对象、领域服务这些概念。 在复杂业务系统里，像金融、电商这些领域，这样DDD就特别适用。通过划分限界上下文（Bounded Context），来指导微服务的拆分，让服务边界和业务边界保持一致。
- 事件溯源 (Event Sourcing) 这方法的核心是，不仅保存当前的状态，还要把所有状态变更的事件都记录下来。如果出现故障的时候就可以通过重放这些事件，快速地恢复系统的状态。 像那些需要审计、追溯或者有复杂状态管理的系统，比如交易系统、物流跟踪系统，这样设计就特别适合。要是再结合CQRS，还能优化读性能呢。
- CQRS (Command Query Responsibility Segregation)
这方法的核心是把命令（就是写操作）和查询（就是读操作）给分开，用不同的模型和存储来优化它们各自的性能。
在那种读多写少，或者读写逻辑差异特别大的系统里，就特别好用。比如说商品详情页，写操作就更新数据库，读操作就从缓存或者搜索引擎里获取数据。
三、架构模式
- 六边形架构 (Hexagonal Architecture) 这架构也叫“端口适配器模式”，我的帐号取名就是来自于它了，它的理念就是把业务逻辑和外部依赖（像数据库、UI、第三方服务这些）都给隔离开来，通过端口（就是接口）和适配器（就是实现）来交互。 在那种需要频繁更换外部依赖的系统里，就特别适用。比如说我们要把数据库从MySQL切换到PostgreSQL，就只需要把数据适配器替换一下就行。
- 洋葱架构 (Onion Architecture) 这种架构模式的核心是领域模型，外层可以依赖内层，但是内层就不可以依赖外层，这就是依赖反转。它的层次依次是：领域模型 → 领域服务 → 应用服务 → 基础设施层。 在那种强调业务逻辑独立性的系统里，就特别适合用这种架构模式，这样假如架构某部分内容变了也能保证不影响核心业务规则。
- 整洁架构 (Clean Architecture)
这架构和洋葱架构有点像，它强调的是“依赖规则”，就是内层定义接口，外层来实现；业务逻辑不能依赖框架、数据库或者UI。
在那种需要长期维护的大型系统里，就特别适用，能保证代码好测试、好扩展。
四、分布式系统与性能
- ACID 这是数据库事务的四个特性，原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 在金融交易这种对强一致性要求特别高的场景里，就特别适用，它和BASE是不同的权衡方向。
- CAP定理 在分布式系统里，一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个东西，没办法同时都满足，最多就只能满足其中两个。 像金融交易系统，就得优先保证一致性和分区容错性，也就是CP；社交媒体系统呢，就得优先保证可用性和分区容错性，也就是AP。
- BASE理论 这理论是CAP定理的补充，它提出“基本可用，最终一致”，就是牺牲点强一致性，来换取可用性。它包括基本可用（就是系统出故障了，还能提供降级服务）、软状态（就是允许有中间状态）、最终一致（就是系统最后肯定能达到一致状态）。 在电商系统、缓存系统、消息队列这些分布式系统里，就特别适用。
- 阿姆达尔定律 (Amdahl's Law) 这定律说的是，并行系统的性能提升，会受到串行部分比例的限制。它的公式是：加速比 = 1 / (串行比例 + (并行比例 / 处理器数量)) 。 在性能优化的时候，我们就得优先优化系统的串行瓶颈，像数据库锁、单线程处理这些，别盲目地去增加节点。
- 古斯塔夫森定律 (Gustafson's Law) 这定律说的是，随着问题规模越来越大，并行部分的比例也会增加，系统的加速比就能接近处理器数量。 在大数据处理这种规模可以扩展的场景里，就特别适用，通过增加节点就能线性提升性能。
五、组织与架构的关系
- 康威定律 (Conway's Law) 这定律说的是，系统架构能反映出组织的沟通结构，也就是“产品的结构等于组织的结构”。 比如在微服务拆分的时候，需要考虑团队的结构是否是符合拆分后的服务边界的。比如说如果是按业务线来划分团队的话，那就要对应着业务域来进行拆分服务，这样能避免跨团队频繁沟通。
- 逆康威定律 (Inverse Conway's Law) 这定律说的是，可以通过设计系统架构，来影响组织的沟通结构和方式。比如说通过引入API网关，强制服务之间要通过接口的方式来进行通信。 在那种需要打破部门墙、促进协作的组织里面，就特别适用，这样就可以通过架构约束来引导组织变革。
六、可靠性与运维
- MTBF/MTTR MTBF是Mean Time Between Failures的首字母缩写，说的是系统平均出现故障时的间隔时间，能衡量系统靠不靠谱。MTTR是Mean Time To Recovery的首字母缩写，说的是系统出现故障后平均需要的恢复时间，能衡量系统好不好维护。 在架构设计的时候，我可以通过冗余、自动恢复这些机制，把MTBF提高；通过监控、灰度发布这些办法，把MTTR降低。
- 故障注入 (Chaos Engineering)
这个方法的核心就是主动的去模拟各种各样的故障，像服务器宕机、网络延迟、上游接口超时、中间件崩溃等这些情况，从而来验证系统的容错能力是否达到要求。
在高可用系统里，像电商大促、金融核心系统这些，就特别适用这样的方式，通过混沌工程来测试能发现潜在的弱点。
最后总结
架构设计原则、方法、模式这些内容其实还蛮多的，就像是我们盖房子的时候的工具和图纸。在不同的场景下，就得选不同的工具和图纸。在实际的开发中，我们得根据项目的实际情况，灵活的运用这些原则和方法，才能设计出既靠谱又好维护的架构。而且架构设计也不是一成不变的，得随着业务的发展和技术的进步，不断调整和优化。只有这样，我们的系统才能在复杂多变的环境里，稳稳当当地运行下去，祝大家永远都不会出Bug！
互动话题：大家在实际项目中，是如何运用架构设计原则和方法的？有哪些经验可以分享？
关于作者
Kenyon，资深软件架构师，15年的软件开发和技术管理经验，从程序员做到企业技术高管。多年企业数字化转型和软件架构设计经验，善于帮助企业构建高质量、可维护的软件系统，目前专注技术管理、架构设计、AI技术应用和落地；全网统一名称"六边形架构"，欢迎关注交流。
原创不易，转载请联系授权，如果觉得有帮助，请点赞、收藏、转发三连支持！
