架构学习01- 03基本原则和23个设计模式分类

Posted 2023-04-03 miaoao611

对接口编程而不是对实现编程。

优先使用对象组合而不是继承。

六大原则
单一职责原则
前端写页面，后端写逻辑。
即： 只负责自己分内之事，让单个模块更简单且复用，高内聚。

开闭原则
实现一个热拔插的效果， 当程序增加了新的功能时， 不能修改原来的代码。
即： 开放扩展，拒绝修改。 增加扩展性可复用性与系统稳定。

里氏替代原则
基类可以出现的地方，子类也一定可以出现。
即： 设计接口时要满足： 任何子类实现都可以在其抽象与高层抽象中自由的替换，且无错误。 增加了可替换性，功能无限延伸。

接口隔离
客户端依赖需要的最小接口。
类似于单一职责， 避免过大的接口设计。

依赖倒置
高层模块不依赖具体实现， 只依赖于上层抽象。
高层模块与底层模块进行解耦，符合里氏替代原则。

迪米特法则
最少知识原则，模块之间应该保持陌生，拒绝过多关联，屏蔽细节。

常用23种设计模式分类
创建型设计模式
创建对象且屏蔽复杂创建细节。
1.1 工厂方法模式
简单工厂：使用工厂if-else创建对象，屏蔽对象的创建细节，实现业务与创建对象的解耦， 无法扩展。
工厂方法：解决if-else问题， 建立多个工厂，当有新的产品时，只需要建立一个新的工厂实现工厂接口。
1.2 抽象工厂模式
缩减工厂方法实现子类的数量，将产品进行分组，每组中的不同产品，通过不同的抽象方法来进行创建和组合。
1.3 单例模式
系统中只存在某个类的唯一一个实例，提供统一的访问接口。
1.4 创建者模式
当对象复杂时，将多个组合对象通过一系列的工序进行组装对象。 工厂创建的是单一产品（产品的意思和对象的意思不同），创建者（建造者）创建的是复合产品。
1.5 原型模式
通过对象创建对象，不需要经过复杂的过程实现复制的对象。
结构型模式
关注类和对象的组合，获取新的功能。
2.1 适配器模式
适配器也叫做转换器，中间转换的角色，进行解耦两端的连接。 ex： type-c转3.5mm 转接器。
2.2 过滤器模式
标准模式，允许增加不同的标准来进行过滤一组对象内容。
2.3 桥接者模式
解决继承会造成类爆炸问题， 将抽象类组合一个实现类接口，然后组合他们的功能。
2.4 组合模式
把一组相似的对象看做一个对象。 ex： 类目树
2.5 装饰器模式
类似于继承后使用super()， 不过是在运行时去给对象进行包装增加新的功能。 增强本身的能力。
2.6 门面模式
外观模式，屏蔽一个系统的实现细节，将不同的子系统的内容进行组合，提供高层的接口，使功能简单易用。
2.7 代理模式
一个接口，他的实现被例外一个实现组合。然后进行增强。 即 被代理对象被代理对象进行控制了。
2.8 享元模式
将对象进行缓存起来。
行为模式
关注对象之间的通信。
3.1 责任链模式
将发送者和多个处理者进行解耦，多个处理者组成一个链表，发送者不需要关心处理的逻辑与细节。
3.2 命令模式
感觉就是用了桥接模式去替代if-else判断。 暂时不是特别理解这个。
3.3 中介者模式
解决网状关系，建立一个中间者来将多方关系解耦。 ex： 微信聊天群。
3.4 备忘录模式
保存对象的快照。可以用来进行恢复。 ex： control + z
3.5 迭代器模式
ex: Iterator 接口
3.6 解释器模式
解析定义的内容，ex： 将json解析为对象，将java 解析成 class
3.7 观察者模式
生产者（被观察者）主动推送给 多个消费者（观察者）。 生产维护一个List<消费者>
3.8 状态模式
将状态切换的逻辑抽离出实体本身。 状态模式关注的是实体本身的状态与行为的转变
3.9 模板模式模式
定义一个流程，父类中可以写公共的内容，实现类只需要实现自己的逻辑就可以形成完整标准的流程。 复用。
3.10 访问者模式
将行为和数据进行分离。 不知道实际应用是什么

阿里架构师分享丨Java架构设计的重点知识和学习路径（建议收藏）

本文已收录GitHub，更有互联网大厂面试真题，面试攻略，高效学习资料等

学习架构呢，要掌握的东西有很多，你是不是开始担心自己一辈子都学不完呢？其实，我们也不需要一下子铺开学习所有的架构技能，重要的是把控好学习的节奏，在适当的时间学习适当的内容，我们可以结合实际工作，一步步地成长。所以今天这一讲，我想给你提供一些架构学习的重点方向和路径建议。

架构原则汇总

在技术架构篇，我针对系统的高可用、高性能、可伸缩和低成本，给你介绍了很多的架构设计原则，不同的原则对应着不同的目标，这里我把这些架构原则和目标汇总成一个表格，来帮助你更直观地了解它们。

限于篇幅，这里我挑选几个原则来重点说下：

可回滚 / 可禁用

• 可回滚原则确保了系统可以向后兼容，当系统升级出现问题的时候，我们可以回滚到旧版本，保证系统始终可用。不过有些时候，系统回滚很困难。举个例子，如果数据库的新旧表结构差异很大，除了回滚代码，我们还要回滚数据库，这样操作起来往往需要很长时间，系统的可回滚性就比较差。所以在设计时，我们要尽量考虑数据库修改和代码的兼容性，并提前做好系统回滚的预案。
• 可禁用原则要求我们提供功能是否可用的配置，在系统出现故障时，我们能够快速下线相应的功能。比如说，新的商品推荐算法有问题，我们可以通过程序开关禁用这个功能。

使用成熟技术

• 作为开发人员，我们都很想尝试新技术，但我们知道，新的技术还没有经过充分的验证，它往往会存在很多隐藏的 Bug。
• 所以，作为架构师，我们在做方案设计的时候，一方面，要从系统的稳定性出发，尽量选择成熟的技术，避免因为新技术的坑而导致系统可用性出现问题；另一方面，选择成熟的技术也意味着选择了团队熟悉的技术，这样学习成本低，落地快。

使用同质化硬件

• 我们在做硬件选型的时候，要尽量选择相同的硬件和相同的配置。
• 比如说，对于服务器，我们选择同样的 CPU 和内存配置，以及同样的操作系统版本，这样我们更容易通过统一的自动化脚本，对节点进行配置，对系统做水平扩展时也会更加容易。

架构落地过程

这些架构原则都是我们要深入理解，并且在实践中要逐渐运用和掌握的。那么下面，我就带你来了解一下架构的具体落地过程，帮助你更好地理解架构师的职责和技能要求。

简单地说，架构师的职责就是负责设计架构，并跟踪架构的实施过程，解决过程中出现的疑难问题，确保架构顺利落地。在之前的文章中介绍过架构师的能力模型，比如抽象思维、平衡取舍、沟通能力等等。接下来，我就结合架构的落地过程和架构师的能力模型，来具体说下架构师是如何开展工作的。

架构师的工作从接到项目需求，或者从自己主动识别系统当前的问题开始，TA 的工作过程可以分为三个大阶段。

首先，架构师要和产品经理或者业务人员沟通，了解业务；和开发人员沟通，了解系统。了解完系统和业务后，架构师接下来就要设计具体的方案，方案设计要分三步走：

• 首先，架构师针对业务需求，分解相应功能到现有的各个系统，把系统的各个部分串起来，这个第一版的方案至少要能够在表面上解决当前的问题，这样就形成一个草根的方案。
• 然后，架构师要进一步深入思考业务的本质，对现有的草根方案进行升华，比如说，通过抽象，让方案更加通用，可以解决多个类似的或潜在的业务需求，这样，草根的方案就变成了一个高大上的方案，这里很考验架构师的透过问题看本质和抽象总结的能力，
• 接下来，基于现有的各项约束，比如时间、资金和人员技术能力等因素，架构师要对方案进行简化，把高大上的方案变成一个接地气的方案，以最小的代价实现最大的价值，这里很考验架构师的平衡取舍能力。

方案设计好之后，最后还要进行宣讲，架构师需要说服相关的人员接受方案，并且在后续的方案执行中，负责跟踪架构的落地，如果过程中有疑难问题，架构师还要协助解决。

所以，我们可以看到，架构师在设计方案时，会有一个反复迭代的过程，最终才能得到一个简约而不简单的方案。并且在方案设计的前后，架构师还需要和大量的人员进行沟通，这些都需要架构师具备宽广的知识面和良好的沟通能力。

架构师知识结构

那么，架构师都需要掌握哪些具体的技能呢？这里我给你提供了一个简化的架构师技能图谱，可以帮助你循序渐进地学习这些架构技能。

首先，作为架构师，我们需要了解计算机硬件和操作系统的相关知识，它们是负责具体干活的，如果对它们有深入的了解，我们就能知道系统底层是怎么执行的，在做具体设计的时候，我们也就可以做各种优化。比如说，在设计 RPC 通讯框架时，我们可以通过 IO 多路复用和内存零拷贝技术，来提升服务端并发处理请求的能力。

在这之上就是具体技术相关的内容，从浅到深可以分为三个部分：

• 第一部分是开发相关的基本知识，比如数据结构和算法、具体的开发语言、常用的设计模式以及开发框架等等，这样你就具备了基本的开发能力。
• 第二部分是各种中间件知识，常用的中间件包括数据库、缓存、消息系统、微服务框架等等，对于这些核心中间件，我们不但要了解具体的用法，还要深入理解它们的适用场景。这样你就能写出高效健壮的代码，能够独立承担一个子系统的开发。
• 继续往下深入，你还要学习分布式系统相关的知识，包括底层网络和分布式通信技术，这样你就可以了解系统是怎么连接在一起的。除此之外，你还要了解一些周边的系统，比如大数据平台、运维监控系统、接入系统等等，这样，你就可以了解系统端到端的运行过程，从技术架构上保证系统的稳定可用。

掌握了这些技术能力之后，你就可以逐渐往全面的架构师发展了。比如说，你可以结合业务，来设计应用体系，包括数据模型和服务设计；你可以了解各种应用架构模型，知道它们的优缺点和适用场景，能够定义一个良好的应用依赖关系。

再往上，就是成为业务领域专家。在这个阶段，你已经知道如何通过业务拆分，实现业务之间的解耦；如何通过业务抽象，实现业务的扩展和重用。

到最后，你已经对各种架构设计的目标和架构原则都非常了解了，知道面对一个具体的问题，大致都有哪些解决的手段；然后，经过大量的实践，你能够把技术架构、应用架构、业务架构融会贯通，并针对具体情况，对架构的各个目标做良好的平衡。当然，作为架构师，你还要和一系列的人员打交道，这时候就需要你培养更多的软技能，能把复杂的架构问题以简单的方式表达出来。

架构师成长路径

现在，你已经清楚了作为一个架构师，TA 需要具备什么样的知识结构。如果你想成为一名架构师，在不同的成长阶段，你还需要学习不同的内容。这里，我以 Java 为例，进一步给出学习的重点内容，给你提供更具体的参考。

第一个阶段是初级开发阶段。

在这个阶段，你需要深入学习数据结构和算法，并且一定要深入掌握单体应用的分层架构，因为这是架构设计的基础。

另外，对 JDK 的一些核心类，你不能仅仅停留在使用层面，而是要深入研读源代码，了解它的内部设计。这样你就知道如何开发一个高效的程序，如何进行各种代码级的调优。

第二个阶段是高级开发阶段。

首先，你需要非常了解设计模式，每个设计模式都可以看做是一个小型的架构设计，这里面有很好的设计原则和抽象思维，你在做系统设计时可以借鉴它们。

然后，你需要非常了解核心的中间件，包括 DB、微服务框架、缓存和消息系统，要清楚地了解它们的适用场景（比如消息系统的削峰、解耦和异步），知道如何对它们进行调优，以及了解它们都有哪些常见的坑等等，核心中间件是我们做技术选型的基础。

同时，你要深入掌握数据库设计和服务接口设计，了解它们的最佳设计实践，它们承载了系统核心的业务数据和业务逻辑。

最后，你需要进一步研读源码，源码是活的教材，它包含了大量实用的设计原则和技巧。这里我建议你选择一些开源的开发框架和 RPC 通信框架，去深入了解它们内部的实现原理，比如 Spring 和 Netty。

第三个阶段是架构师阶段，成为技术专家。

首先，你需要深入了解网络通信，比如说网络分层和 HTTP/TCP 协议，还有各种常见的RPC 通讯框架，了解它们的特性和适用场景，这样你在设计分布式系统时，就能够进行合理的技术选型。

然后是了解底层系统，包括 JVM、操作系统和硬件原理，再往上延伸到系统的接入部分，了解常见的负载均衡特性和用法，这样你可以对整体的系统有个透彻的了解，把各个环节可以很好地衔接起来。这里，我特别建议你去读下 Java 和 JVM 的规格说明书，了解 Java 的底层设计。

最后，你需要熟练掌握各种设计工具和方法论，比如领域驱动设计和 UML，了解常用的架构设计原则，这样你就能够结合业务，选择合适的应用架构和技术架构并进行落地。在这一阶段，对你总的要求就是能够从端到端的角度进行业务分析和系统设计。

第四阶段是大师阶段。

在这个阶段，你需要对架构的各个目标都非常了解，除了业务系统设计，你还要对运维和监控有深入的认知。同时，你需要了解业界的架构实践，跟踪技术的发展趋势，如果出来一项新技术，你可以比较准确地对它进行定位，把它纳入到自己的能力体系当中。

另外，在这个阶段，你也已经通过大量的实践，培养了很好的软技能，比如沟通能力、项目管理能力等等。那么最后，你就能做到技术和业务的融会贯通，可以平衡各种架构目标，设计非常实用和接地气的架构，并保障它的顺利落地。

架构师境界

你可以发现，架构师的能力是一个逐渐提升的过程，如果从架构师的境界来看，由浅到深可以分为四层：第一层看山不是山，第二层看山是山，第三层看山不是山，第四层看山是山。

这是一个螺旋式上升的过程，那么它究竟是什么意思呢？

刚接手项目的时候，你对业务还不太了解，经常会被业务方冒出的术语弄得一愣一愣的，如果把现有问题比作山，那就是横看成岭侧成峰，你根本摸不透，此时看山不是山。

经过业务梳理和深入了解系统以后，你能够设计出一个简单的方案，把各个系统串起来，能解决当前的问题，对当前的这个“山”能够看清楚全貌，此时就做到了看山是山。但这样的方案往往设计不够，只能解决表面问题，碰到其它类似问题或者问题稍微变形，系统还需要重新开发。

通过进一步抽象，你能够发现问题的本质，明白了原来这个问题是共性的，后续还会有很多类似的问题。然后你就对设计进行总结和升华，得到一个通用的方案，它不光能解决当前的问题，还可以解决潜在的问题。此时，你看到的已经是问题的本质，看山不是山。但这样的方案往往会过度设计，太追求通用化，会创造出过多的抽象概念，理解和实现起来都特别困难，过犹不及。

最后回到问题本身，你能够去除过度的抽象，给出的设计简洁明了，增之一分嫌肥，减之一分嫌瘦，既能解决当前的问题，又保留了一定的扩展能力，此时问题还是那个问题，山还是那个山。这样的方案在了解问题本质的基础上，同时考虑到了现状，评估了未来，不多做，不少做。

你可以对照这四个境界，来评估你当前的架构能力，不断地提升对自己的要求。

总结

本文汇总了常见的技术架构设计原则，它们都是实践的总结，你在做架构设计时，可以参考这些原则，在项目中采取相应的手段来实现架构目标。值得注意的是，在做具体的架构设计时，你需要对设计进行反复迭代，才能最终得到一个高性价比的方案。

针对架构师的成长，我也给你提供了相应的知识结构和可行的进阶之路，希望你能够一步步成长，最终实现自己的理想。

读万卷书，行万里路。架构师的成长尤其如此，架构没有速成之路，我们先要“读万卷书”，学习各种架构需要的技能，然后“行万里路”，通过大量的实践把架构知识变成架构能力。