走向边缘的设计模式

在起草本篇博文之前，关于这个题目该如何命名斟酌了好久，随着互联网技术的兴起和日异月新的发展，代码设计上的美感比起为达目的面向服务编程已经变得微乎其微。本来想起名为“走向灭亡的设计模式”，但是仔细思考下也不对，第一每个架构师和程序员都有追求完美代码的意愿，第二设计模式留下的思想上的精髓依然适用于互联网时代。所以本篇不套用任何设计模式的代码公式，只研究每种模式的思想。

 

设计模式分为三大类：创建模式、结构模式、行为模式

 

创建模式：面向主体的构建过程

1， 工厂模式

先来看工厂模式的思想和设计初衷：客户端不关心具体主体是啥，只关心所提供的服务，主体创建过程比较复杂，不希望暴露过多内部结构给外界，降低耦合度。

做MVC模式开发时这个概念大家都玩烂了，来到微服务架构下每个服务节点不都是用了工厂模式么？RestFul松耦合，只关心服务能力不关心服务实现，服务构建和启动复杂等等。

2， 原型模式

设计思想就是好不容易构造出一个主体，我不想再从头到尾再构造一个出来了，我复制一个出来。

做MVC模式下原型模式我们是对对象进行克隆，来到微服务架构下这尼玛不又是Docker容器的概念么？弄个微服务镜像，启动多个容器。

3， 单例模式

设计思想是限制某个主体不被随意地创建，保证构造方法私有，开发人员最熟悉的模式，不多说。

4， 建造者模式

给什么材料出什么成品，用的较少。

 

结构模式：面向主体和主体之间的关系。

1， 外观模式

设计思想是多个主体通过重新组合对外提供一个简明一致的接口，隐藏系统的复杂性，是之更容易被客户端使用。

MVC中我们对它的使用是对相互交叉的复杂关系和算法做上层的封装，在微服务中每个节点依旧采用了外观模式的思想，上层结点是重新封装后的外观，隐藏了对下层多个节点的调用。

2， 代理模式

3， 装饰模式

代理模式和装饰模式放在一起来归纳，是因为这两种模式在使用时结构一样，都是将真正提供服务的主体set给另一个代理主体或装饰主体内，由后者负责对外提供服务。

这两者的区别是，代理模式重点在于控制，代理主体要控制好什么情况下调用什么样的服务主体；装饰模式重点在于加强，对主题提供的服务进行前后加强。

在Spring Framework架构的微服务中，Spring Cloud Zuul就是代理模式，API网关对下层节点的访问做控制，filter里要求请求者必须具备什么样的条件才可以调用到服务。Spring Cloud Sleuth使用的是装饰模式，对服务调用时添加一些装饰（服务追踪信息）。

4， 享元模式

设计思想是系统中如果有多个相同的对象，那么只共享一份就可以了，不必每个都去实例化一个。猛一看与单例模式极容易混淆，但是完全是2个概念。单例模式是构建过程中只允许构建一个，享元模式是使用过程中能创建一个就创建一个。

Java基础中String是享元的，在互联网技术中享元使用的也很普遍。例如Lucene对词根Prefix+Suffix技术的存储就是这种模式的体现（Lucene技巧分析）；微服务中一些元素据信息在Redis等共享内存中的保存也属于享元的体现。

5， 组合模式

在微服务架构中，每个服务节点之间地位是平等的，大家都是Http直接请求得到的独立个体，也就没有整体-部分这些概念了，所以这个模式慢慢弱化。

6， 桥接模式

7， 适配器模式

这俩模式放在一块归纳，是因为个人观点而言，一旦用到这俩模式，说明你的代码设计已经存在问题了，这属于后期补救没有办法的办法了，这俩模式并不是合理的设计中应该出现的，所以也弱化。

 

 

行为模式：面向主体的服务过程。

1， 模板模式

设计思想是主体提供的服务是呈现套路特性的，里面先干什么后干什么是个百年不变的模式，而且有些公共的部分是可以在基类中实现的，具体子类将个性的部分重写。

Java代码中怎么用，我相信大家项目中都使用过，我们重点来看在微服务架构中这货体现在哪里。以Logstash为例，先接收消息再进行中间处理后输出消息，input-filter-output这就是固定的套路，研发人员自己对input、filter、output做配置相当于进行了重写。

2， 备忘录模式

也叫快照模式，设计思想是将主体某一原始状态做备份等有需要时恢复回去。

备忘录模式讲究的是出现问题推倒重来，数据库的备份，Docker容器的重建都可以归于备忘录模式。Spring Cloud Config也有点备忘录的影子，先将远程Git仓库的信息做一份本地的备忘录，一般用不到，当远程Git访问不到是，就去本地的这份快照里去取值。

3， 观察者模式

设计思想是由第三方的某个主体来观察客户端和服务端的关系，当发生变化时自动修改它们的映射关系，客户端和服务端各自只需要搞好各自的事情，发生的变化他们是不知道的，只有第三方知道并处理。

站在系统架构角度来考虑，微服务架构中服务治理就像是观察者模式，它独立于真正提供业务服务的节点之外，观察监督着节点间的调度和健康状况，当满足一定条件时自动扩容、修改服务节点等，这些是服务主体感知不到的。

4， 责任链模式

设计思想是每一环判断并做好自己的本分工作，同时将任务传给下一链，整个一条链组成一个功能服务接口，客户端不需要知道任务是怎么被完成的。

5， 策略模式

设计思想与责任链模式恰恰相反，提供N个平行的策略供客户端选择，客户端要告知策略模式使用哪种策略来提供服务。

站在客户端角度来说，责任链模式更受欢迎一些，因为它降低了客户的要求，客户不需要懂具体业务直接傻瓜式的丢给链的第一环就OK了，只符合互联网客户一键操作体验的要求。但是站在研发角度来说，责任链会掺杂很多if-else这样判断责任的代码，而且链性的调用没有具体某个策略性能上来的快，响应速度也是互联网客户体验的一部分。

6， 命令模式

设计思想从字面意思来看已经很明显了，将事件枚举成一个个的命令，客户端负责发送命令指令，服务端负责执行。

说实话在传统软件中我对命令模式使用的很少，但是到了互联网软件架构上命令模式华丽的成为了主角，因为无阻塞的高并发就是建立在对服务处理拆分成足够小的命令单元的基础上的。

Redis将对记录的操作拆分成一个个的命令，Event Sourcing中的事件处理也是一个条命令。

命令是必须要尊崇和执行的，所谓开弓没有回头箭，微服务架构的无状态性和最终一致性让命令模式的价值体现到了极致。

7， 状态模式

设计思想是内在状态的变化会改变主体的服务能力，本质上有点像责任链模式和策略模式的结合。对状态的判断就像责任链模式中各环节对本职范围的判断，每种状态的处理是平行独立的，每种状态对应每种策略。

8， 中介者模式

设计思想是通过中介将主体间网状关系的引用改为星状关系的引用，主体和主体之间的关系变成了主体和中介者之间的关系。

Java开发中我还真没用到过，但是在Spring Framework微服务架构中Spring Cloud Eureka就是这个中介，所有节点只依赖了Eureka的地址，而没有依赖其它服务的地址。

9， 解释器模式

头大，实战中几乎不用，相当于自己定义一套语言并实现某种服务，还要提供解析这门语言的解析器。

10，             访问者模式

不同的访问者对操作不同的扩展，抽象出一层来专门解耦这部分变化使真正提供服务的主体不受污染。

 

设计模式不在于行而在于神，所以通篇没有插入一行代码，因为我们需要明白设计者为什么要推出这种模式，是为了解决什么场景下什么样的问题，而不是形而上学的套代码套公式。