之乎者也·的博客

代理模式」是一种结构型设计模式， 能够提供对象的替代品或其占位符（「即是给某一个对象提供一个代理，并由代理对象控制对原对象的引用」代理控制着对于原对象的访问， 并允许在将请求提交给对象前后进行一些处理。例如电脑桌面的快捷方式就是一个代理对象，快捷方式是它所引用的程序的一个代理。「主要作用」：为其他对象提供一种代理以控制对这个对象的访问。「何时使用」：想在访问一个类时做一些控制。「如何解决」：增加中间层。「关键代码」：实现与被代理类组合。「主要解决」：在直接访问对象时带来的问题，以及对一些对象的增强。

设计模式面试题分析

（1）source 接口是具体资源访问策略的抽象，也是所有资源访问类所实现的接口。（2）Resource 接口主要提供了如下几个方法:getInputStream()：定位并打开资源，返回资源对应的输入流。每次调用都返回新的输入流。调用者必须负责关闭输入流。exists()：返回 Resource 所指向的资源是否存在。isOpen()：返回资源文件是否打开，如果资源文件不能多次读取，每次读取结束应该显式关闭，以防止资源泄漏。

每年淘宝都有双11、双12等大促，我们价格服务小组的工作就是提前预计算大促期间消费者将要购买的每一件商品的价格，为消费者选出真正优惠的商品。但是大淘宝营销策略历时已久，种类多样，又紧跟市场波动，千变万化，这就要求我们设计的系统具备高可扩展性。因此今天我向大家介绍一下我们营销域下的价格服务系统是如何做到高可扩展性的。我们价格服务的下游使用方有多个，不同的下游使用方业务不同，目的不同，业务模型有差别，获取的结果中的关键参数自然也不同。

本文既有理论知识，又有实用信息：我们将学习每一种具体的模式，为什么以及应该在什么地方使用；然后，我们将看下应用了这些模式的参考架构；接下来，我们将综合运用新学到的模式设计我们的架构；最后，我们将确定选用什么技术实现架构。本文将介绍微服务架构设计中的设计模式、原则及最佳实践。我们将使用适当的架构设计模式和技术。通过本文，你将了解到如何利用微服务分布式架构设计一个高可用、高可扩展、低延迟且对网络故障有弹性的系统，以处理数以百万计的请求。

从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装 （1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）他们都是使用分而治之这项成熟的传统技术来应对大型系统的复杂性。自 2010 年开始，这些技术被证实无法继续应对 Web 级应用或者现代大型企业级应用的复杂性。

设计模式（Design pattern） ：由软件开发人员在软件开发中面临常见问题的解决方案，是经过长时间的试验积累总结出来的，它使设计更加灵活和优雅，复用性更好。从实用的角度来看，它代表了某一类问题的最佳实践。设计模式是研究类和本身以及类和类之间如何协作的模式，是在软件开发中常见问题的解决方案模板。这些模板是经验丰富的开发者在解决各种问题时提出的最佳实践的总结。设计模式提供了一种通用的、可重复使用的方法，可以用于解决特定类型的问题，以改善软件的结构、可维护性和可扩展性。

设计模式是程序员在面对同类软件工程设计问题所总结出来的有用的经验， 模式不是代码，而是某类问题的通用解决方案，设计模式（Design pattern） 代表了最佳的实践。这些解决方案是众多软件开发人员经过相当长的一段时 间的试验和错误总结出来的。设计模式的本质提高 软件的维护性，通用性和扩展性，并降低软件的复杂度。设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、健壮性以及安全性的解决方案。

迭代器模式抽象迭代器类来分离了集合本身与对集合的遍历行为，在不暴露集合的内部结构的情况下让外部代码访问集合内部的数据。

在解释器模式模式中经常分不清表达式里面【终结符】和【非终结符】，以至于我们常常对概念比较混乱，实际上我们这一定程度上将一个表达式当成一个树状结构来看待会清晰很多，【终结符】当成叶子结点，【非终结符】当成树枝节点，遇到非终结符要继续往下解析，遇到终结符则返回。

实现观察者模式的时，发布者和观察者之间不能直接调用，否则会使发布者和观察者之间紧密的耦合，从根本上违反面向对象的设计的原则。

中介者是迪米特法则的一个典型应用，通过引入中介者对象，可以将系统的【网状结构】变成以中介者为中心的【星形结构】，中介者承担了中转作用和协调作用，简化了对象之间的交互，还可以进一步的控制组件类之间的交互。

访问者模式的核心主要是「将数据操作行为和数据结构分离」，在使用该模式之前我们要保证「对象结构是否足够稳定，是否需要经常定义新的操作。

状态模式的使用免去了过多的if–else判断，但是会造成更多的接口和类，所以对于非常简单的状态判断，不建议使用。当状态的个数有限并且相互独立的时候可以考虑使用状态模式。

窄接口」只允许它把备忘录对象传给其他的对象。针对的是负责人对象和其他除发起人对象之外的任何对象。「宽接口」允许它读取所有的数据，以便根据这些数据恢复这个发起人对象的内部状态。针对发起人。

策略模式，「实质是对算法的封装 ， 它把算法的责任和算法本身分割开 ， 委派给不同的对象管理」，用户可以自由选择这些算法进行操作。策略模式本身理解起来没什么难点，但是在实际应用中其本身主要结合工厂模式一起使用。

模板方法模式基于继承机制实现，子类通过重写部分父类方法，影响父类行为的结果，在实际的开发中使用的非常频繁，很多开源框架都会提供一个抽象类，当我们需要扩展功能时，只需要继承此抽象类，重写基本方法，调用模板方法即可。

职责链模式在处理请求时一个处理者对象有两种行为和对一个请求的两种情况。「一个处理者对象有两种行为」处理请求将请求传递到下一节点「一个请求的两种情况」「纯的职责链模式」一个请求必须被某一个处理者对象所接收，且一个具体处理者对某个请求的处理只能采用上述两种行为之一：自己处理请求或者将请求传递到下一节点。「不纯的职责链模式」允许出现某一个具体处理者对象在「承担了请求的一部分责任后又将剩余的责任传给下家的情况」，且一个请求可以最终不被任何接收端对象所接收。

命令模式的意图是将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。命令模式的实现过程通过调用者调用接受者执行命令，顺序：调用者→命令→接受者。

Bridge 模式是一个结构型的模式，实现比较复杂，它很好的融入了「开闭原则」与「单一职责原则」。避免了继承的强关联，使得不同维度可以独立开来，使得客户端与具体实现高度解耦。

在日常编码中，我们会大量使用外观模式，只要是高层模块需要调度多个子模块，我们都可以进行抽象，提供精简的接口，让高层模块可以更加容易地间接调用模块的功能。

组合模式是一种解决树状问题的结构型模式，再使用过程中需要有较强的层次结构，在实现时要注意树枝节点的特有接口以及含有内部属性 List，List里面放 Component。

装饰者模式实际上类似AOP思想的一种实现方式，跟AOP类似的它可以控制被装饰者行为，在调用父类方法之前或之后给被装饰者添加附加的行为。

在使用对象的适配器模式，多用合成/聚合、少用继承。「用作DataSet和数据源之间的适配器DataAdapter」。

享元模式虽然减少系统中对象的数量。但也导致引起系统的逻辑更加复杂。主要通过核心的享元工厂类来共享享元对象。不变的内部状态存储于享元对象内部，可变的外部状态由客户端负责。

单例模式属于创建型模式，是 Java 中最简单的设计模式之一，单例模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。主要作用：保证一个类仅有一个实例，并提供一个访问它的全局访问点。主要解决：一个全局使用的类频繁地创建与销毁。何时使用：控制实例数目，节省系统资源的时候。如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。核心代码：构造函数是私有的 private单例模式解决了两个问题单例类必须给所有其他对象提供这一实例（提供全局访问点）。

原型模式通过Object的clone()方法实现，由于是内存操作，无视构造方法和访问权限，直接获取新的对象。但对于引用类型，需使用深拷贝，其它浅拷贝即可。

建造者模式的使用场合是当创建复杂对象时，把创建对象成员和装配方法分离出来，放在建造者类中去实现，客户端使用该复杂对象时，不用理会它的创建和装配过程，只关心它的表示形式。

工厂模式与抽象工厂模式都属于创建型模式，在工厂模式中弥补了简单工厂模式的缺陷（不符合开闭原则），而在抽象工厂模式中弥补了工厂模式的不足（一个工厂只能生产一种产品）。

工厂方法模式(Factory Method Pattern)，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将具体创建的工作交给子类去做。该核心类成为一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。工厂方法模式是简单工厂模式的衍生，解决了许多简单工厂模式的问题。

策略模式是属于设计模式中的行为模式中的一种，策略模式主要解决选项过多的问题，避免大量的if else 和 switch下有太多的case。策略模式的重心不是如何实现算法，而是如何组织、调用这些算法，从而让程序结构更灵活，具有更好的维护性和扩展性策略（Strategy）模式：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换策略模式让算法独立于使用它的客户而变化。策略是个形象的表述，所谓策略就是方案，日常生活中，要实现目标，有很多方案，每一个方案都被称之为一个策略。

策略模式定义了算法族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的的客户。这个策略模式的定义是不是有点抽象呢？那我们来看点通俗易懂的比喻：假设你跟不同性格类型的小姐姐约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去逛街买买买最合适。当然，目的都是为了得到小姐姐的芳心，请看电影、吃小吃、逛街就是不同的策略。策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。当你想要让一个以上的对象。

Double-Check概念对于多线程开发者来说不会陌生，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象。滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为该对象是垃圾而被回收，这可能会导致对象状态的丢失；

观察者模式：定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新。组合模式：将对象组合成树形结构来表示“部分-整体”的层次结构，使得客户端对单个对象和组合对象的使用具有一致性。适配器模式：将一个类的接口转换成客户端所期望的接口，解决不兼容接口之间的问题。装饰器模式：动态地给一个对象添加一些额外的功能，而不需要修改其原始类。命令模式：将请求封装成对象，使得可以用不同的请求对客户进行参数化。工厂模式：将对象的创建委托给工厂类，客户端通过工厂类来创建对象。