代码拉取完成，页面将自动刷新
保证一个类仅有一个实例，并提供一个访问它的全局访问点
public class SingletonClass{
private static SingletonClass instance=null;
public static SingletonClass getInstance(){
if(instance==null){
synchronized(SingletonClass.class){
if(instance==null){
instance=new SingletonClass();
}
}
}
return instance;
}
}
类图：
装饰者模式，在保持原有功能不变的情况下将一个类重新装饰，使其具有更强大的功能，用一句成语形容“锦上添花”。
类结构：
Component：抽象组件，定义了一组抽象的接口，指定了被装饰的组件都有哪些功能。
ComponentImpl：抽象组件实现类，完成了基本的功能实现。
Decorator：装饰器角色，持有Component的实例引用，有点递归的感觉。
伪代码：
Component c=new ComponentImpl();
Decorator d1=new Decorator();
d1.setComponent(c);
Decorator d2=new Decorator();
d2.setComponent(d1);
Decorator d3=new Decorator();
d3.setComponent(d2);
Decorator d4=new Decorator();
d4.setComponent(d3);
d4.methodA();
装饰者模式和适配器模式有点类似，都是包装（wrapper）了一个类，但目地却不相同。适配器模式是将一个接口转换成另一个接口，从而达成匹配。而装饰者模式并没有改变原来的接口，而是改变原有对象的处理方法，借助递归提升性能。
适配器模式就是一个类的接口不能被客户端接受，需要转换为另一种接口，从而使两个不匹配的接口能在一起工作。
类结构
Adaptee：源接口，需要适配的接口
Target：目标接口，暴露出去的接口
Adapter：适配器，将源接口适配成目标接口
举个现实例子：
Adaptee就是相机中的内存卡片，Target就是电脑，而Adapter则是USB读卡器。
适用场景：
比如查物流信息，由于物流公司的系统都是各自独立，在编程语言和交互方式上有很大差异，需要针对不同的物流公司做单独适配，同时结合不同公司的系统性能，配置不同的响应超时时间
观察者模式通常也叫发布—订阅模式，或者事件监听模式，定义一对多的依赖关系，让多个观察者对象同时监听一个主题对象，如果这个主题对象的状态发生变化时，会通知所有的观察者对象。 异步消息（MQ、activeMQ）都是基于这种模式
类结构图：
优点：
责任链模式就是很多对象由每个对象对其下家的引用串连起来形成一条链，请求在这条链上传递，直到最终处理完。就象一根水管一样，水从一端流入，会经过一系列的阀门，最终从另一端流出。如果有一个阀门关着，水都流不出来。
链上的节点可以控制，根据是否执行分为两种情况：
http://blog.csdn.net/itomge/article/details/20792567
策略模式通常是指完成某个操作可能会有多种方法，适用于多种场合。我们需要把每个操作方法当做一个实现策略，调用者可根据需要（特定的规则）选择合适的策略
结构类图：
例子：
@Override
@Enhancement({ @Capability(type = CapabilityTypeEnum.INVOCATION_STATS) })
public void sendGoods(SendGoodsParam param) throws ServiceException {
if (null == param || null == param.getId()) {
this.throwInvalidError(ErrorCodeEnum.NULL_PARAM, null, param);
}
TradeFlowService t = createTradeFlowServiceByOrderId(param.getId());
t.sendGoods(param);
}
createTradeFlowServiceByOrderId方法会根据”订单号的长短“选择具体的子策略
彼此子策略实现互不干扰，有效达到隔离效果。
可以控制某资源同时被访问的个数。例如连接池中通常要控制创建连接的个数。
tryAcquire方法，获得锁
release方法，释放锁
应用场景很多，尤其是在框架设计中，提供了一个方便的开发程序的模板，你只要实现模板中的一些接口或方法就能完成一个复杂的任务。
结构类图：
public TradeFlowActionResult execute(TradeFlowActionParam param, Map context) throws ServiceException {
try { // 业务逻辑校验
this.validateBusinessLogic(param, context);
} catch (ServiceException ex) {
sendGoodsLog.info("SendGoodsAction->validateBusinessLogic got exception. param is " + param, ex);
throw ex;
} catch (RuntimeException ex) {
sendGoodsLog.info("SendGoodsAction->validateBusinessLogic got runtime exception. param is " + param, ex);
throw ex;
}
try {
// 卖家发货业务逻辑
this.sendGoods(param, context);
} catch (ServiceException ex) {
sendGoodsLog.info("SendGoodsAction->sendGoods got exception. param is " + param, ex);
throw ex;
} catch (RuntimeException ex) {
sendGoodsLog.info("SendGoodsAction->sendGoods got runtime exception. param is " + param, ex);
throw ex;
}
try {
// 补充业务（结果不影响核心业务）
this.addition(param, context);
} catch (ServiceException ex) {
sendGoodsLog.info("SendGoodsAction->addition got exception. param is " + param, ex);
throw ex;
} catch (RuntimeException ex) {
sendGoodsLog.info("SendGoodsAction->addition got runtime exception. param is " + param, ex);
throw ex;
}
// 处理结果
return null;
}
上面提到的三个抽象方法（业务逻辑校验、卖家发货业务逻辑、补充业务）都是在子类中实现的
即控制了主流程结构，又不失灵活性，可以让使用者在其基础上定制开发。
代理模式，为其它对象提供一种代理以控制对这个对象的访问。
类结构图：
代理模式其实就是在操作对象时引入一定程度的间接性。这种间接性，可以增加很多附加操作。比如权限控制，参数校验等等
public class ProxyPersonManager implements PersonManager {
// 接口引用
PersonManager realPersonManager = new RealPersonManager();
@Override
public double getSalary(String name, String operateName) {
// 1. 增加一些的权限判断。比如操作人是否有查询某人工资的权限
// 2. 具体类的调用
return realPersonManager.getSalary(name, operateName);
}
}
基于角色的权限访问控制。
用户---》用户的身份（店铺、达人）--》对应的权限集合
每个权限都拆分原子的，采用并集的形式。另外增加个性化权限表，专属用户有专门的权限。
几乎所有数据库都支持高可用性集群，大多数数据库对系统一致性模型提供一个易于理解的方式，保证强一致性模型的安全方式是维持数据库事务操作的有序日志，理论上理由非常简单，一个事务日志是一系列数据更新操作的动作有序记录集合，当其他节点从主节点获得这个事务日志时，能够按照这种有序动作集合重新播放这些操作，从而更新自己所在节点的数据库状态，当这个事务日志完成后，次节点的状态最终会和主节点状态一致，
Event sourcing事件溯源是借鉴数据库事务日志的一种数据持久方式，在事务日志中记录导致状态变化的一系列领域事件。通过持久化记录改变状态的事件，通过重新播放获得状态改变的历史。 事件回放可以返回系统到任何状态。
https://www.jdon.com/event.html
Sidecar主张以额外的容器来扩展或增强主容器，而这个额外的容器被称为Sidecar容器。也可以理解为插件。
主要是用来改造已有服务。我们知道，要在一个架构中实施一些架构变更时，需要业务方一起过来进行一些改造。然而业务方的事情比较多，像架构上的变更会低优先级处理，这就导致架构变更的 " 政治复杂度 " 太大。而通过 Sidecar 的方式，我们可以适配应用服务，成为应用服务进出请求的代理。这样，我们就可以干很多对于业务方完全透明的事情了。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。