MQ从字面意思上看，本质是个队列，FIFO先入先出，只不过队列中存放的内容是message而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ之后，消息发送上游只需要依赖MQ，不用依赖其他服务。
享元模式主要用于共享通用对象，减少内存的使用，提升系统的访问效率。较大的对象通常比较耗费内存，需要查询大量的接口或使用数据库资源，因此有必要统一抽离出来作为共享对象使用。
外观模式也叫门面模式，它主要解决的是降低调用方使用接口时的复杂逻辑组合。在调用方与实际的接口提供方之间添加了一个中间层，向包装逻辑提供API接口。有时外观模式也被用在中间件层，用服务中的通用性复杂逻辑包装中间件层，让使用方可以只关心业务，简化调用。
装饰器模式就像俄罗斯套娃，它的核心是在不改变原有类的基础上给类新增功能。对于不改变原有类，可能有的人会想到集成、AOP切面，虽然这些方式都可以实现，但是使用装饰器模式使另外一种更灵活的思路，能够避免继承导致的子类过多问题，也可以避免AOP带来的复杂性问题。
通过把相似对象或方法组合成一组可被调用的结构树对象的设计思路，成为组合模式。
桥接模式的作用是通过将抽象部分与实现部分分离，将多种可匹配的使用进行组合。其核心实现是在A类中含有B类接口，通过构造函数传递B类的实现，这个B类就是设计的桥。
适配器模式的主要作用是把原本不兼容的接口通过适配修改做到统一，方便调用方使用。
单例模式是整个设计中比较简单的模式，即使没有看过设计模式的相关资料，也会经常用在实际业务的编码开发中。因为在编程开发中经常会遇到这种场景—需要保证一个类只有一个实例，哪怕多线程同时访问，而且需要提供一个全局访问此实例的点。
原型模式主要解决的是创建重复对象的问题，而这部分对象内容本身比较复杂，从数据库或者RPC框架获取相关对象数据的耗时较长，因此需要采用复制的方式节省时间。
建造者模式的核心是通过使用多个简单对象一步步构建出一个复杂对象。例如，《英雄联盟》游戏的初始化界面有道路、树木、野怪和防御塔等。换一个场景选择其他模式时，同样会建设道路、树木、野怪和守卫塔等，但是他们的摆放位置和大小各有不同。这种初始化游戏元素的场景就可以使用建造者模式。
5 / 12
