“随风潜入夜，润物细无声”，用来形容这个设计模式，是最恰当不过了。这个设计模式，Java程序员往往看不到它，甚至感觉不到它的存在，却在享受它带来的便利。
大家好，欢迎关注极客架构师，极客架构师——专注架构师成长，我是码农老吴。
本期是《架构师基本功之设计模式》的第10期。
在第9期，我分享了创建型设计模式中的工厂系列模式（静态工厂方法，工厂方法，抽象工厂），打造了可扩展的，支持多语言的电商平台，商品数据导出模块。
本期，我将分享行为型设计模式中，大名鼎鼎却很少现身的命令模式（command pattern），我们基于命令模式重构电商系统中的降级模块。
根据REIS分析模型，对命令模式进行分析，命令模式包含4种角色，命令角色（command role），命令创建者角色（command creator role），命令调用者角色（command Invoker role），命令执行者角色（command executor role）。命令创建者角色将命令的参数，状态及命令执行者的相关信息，封装在独立的，可传输的，和可序列化的命令角色中，以便通过命令角色解耦合其他三个角色。最终实现命令的排队，日志及可撤销等高级功能。
电商行业大促备战之降级策略
第一版代码（无设计模式）
第二版代码（命令模式，简版）
第三版代码（命令模式，完整版）
命令模式定义
使用REIS模型分析命令模式
互联网时代——命令模式的发展窘境
命令模式的红利
命令模式通用代码和类图
后续规划
自从2009年，阿里推出了第一届双十一大促活动以来，中国的电商行业进入了高速发展期。京东也不甘人后，推出了自己的大促节日——618（据说比阿里还早了一年）。自此，每年两次的电商行业大促营销活动，就成了中国广大网民的购物狂欢节，俗称剁手节。随着每年订单销售额的节节攀升，电商系统以及电商系统的架构师，程序员，也在同时经历着，血与火的洗礼。每年的两次大促，上半年的618，下半年的双十一，就成了电商行业架构师的大考，优者加官进爵，劣者卷铺盖走人。
而大促之前的备战工作，就是部门Leader和架构师大展拳脚的机会。
每当大促备战启动会召开之后，各个部门的各项工作都要有序展开，系统梳理，流量预估，完善日志，加强监控，机器扩容，系统压测，降级预案，事故演练等措施一个都不能少。
而我们今天的重点，就是降级问题。
降级的主要任务，就是弃车保帅，在系统流量超出预期时，或者服务器，数据库等资源出现异常或者短缺时，次要的业务能停就停，确保黄金流程（用户下单的流程）能正常使用。
降级的方式很多，有自动降级的，有发生异常被动降级的，也有根据订单情况，手动降级的，这些我们今天不细聊，后面在分享分布式系统架构时，我会详细的，系统的分享这些内容。今天我们只关注其中一个点，就是手动降级。
手动降级，可以通过程序员修改系统或者应用的配置参数实现降级，但是在大促期间，大家压力都比较大，修改配置参数出错的可能性比较大，加上一个大部门，有上百个应用，管理起来还是比较麻烦的。
所以实现降级的方案是，由各个应用提供降级的接口，然后由降级管理控制平台，统一进行管理。如果要对某个应用或者模块进行降级，直接点个按钮就可以了，当然通过消息系统也可以实现。
降级策略也有很多，轻一点的可以部分限流；稍微严重的还可以禁用写服务，减轻后端压力；再严重的，就需要把应用的功能下线，暂停服务。然后给用户在前台显示一个，“网络故障，稍后重试，谢谢”，把锅甩给运营商哦。
我们的案例，就以“系统下线”为例，支持系统下线的应用，通常有商品评价应用和商品推荐应用等，这两个应用，因为不属于黄金流程，而且占用资源还比较多，都属于被优先降级的重点应用。
这次我们采用spring boot框架配置项目，采用常见的三层架构的方式进行代码开发。
我们先看第一版，没有采用任何设计模式。
表示层：
DegradeController
服务层：
IDegradeService
DegradeServiceImpl
RPC调用：
IAppClient
RecommendAppImpl
ReviewAppImpl
其他：
AppCodeEnum
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
4.0.0
org.springframework.boot
spring-boot-starter-parent
2.7.3
com.geekarchitect.patterns
command-pattern
0.0.1-SNAPSHOT
command-pattern
命令模式案例
1.8
org.springframework.boot
spring-boot-starter-web
org.projectlombok
lombok
true
org.springframework.boot
spring-boot-starter-test
test
org.springframework.boot
spring-boot-maven-plugin
org.projectlombok
lombok
表示层：DegradeController
package com.geekarchitect.patterns.command.demo02;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/29
*/
@Controller
public class DegradeController {
private static final Logger LOG = LoggerFactory.getLogger(DegradeController.class);
@Autowired
private IDegradeService degradeService;
public void offline(int appCode) {
LOG.info("Controller层——DegradeController");
degradeService.offline(appCode);
}
}服务层：
IDegradeService
package com.geekarchitect.patterns.command.demo02;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/29
*/
public interface IDegradeService {
void offline(int appCode);
}DegradeServiceImpl
这里的代码是重点。
package com.geekarchitect.patterns.command.demo02;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Service;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/29
*/
@Service
public class DegradeServiceImpl implements IDegradeService {
private static final Logger LOG = LoggerFactory.getLogger(DegradeServiceImpl.class);
@Autowired
private ApplicationContext applicationContext;
@Override
public void offline(int appCode) {
LOG.info("Service层——DegradeServiceImpl");
switch (AppCodeEnum.getEnumByCode(appCode)) {
case REVIEW: {
IAppClient appClient = (IAppClient) applicationContext.getBean("reviewApp");
appClient.offline();
break;
}
case RECOMMEND: {
IAppClient appClient = (IAppClient) applicationContext.getBean("recommendApp");
appClient.offline();
break;
}
default: {
LOG.info("appCode {} 不存在");
}
}
}
}RPC调用：
IAppClient
package com.geekarchitect.patterns.command.demo02;
/**
* app客户端
*
* @author 极客架构师@吴念
* @createTime 2022/8/31
*/
public interface IAppClient {
void offline();
}ReviewAppImpl
package com.geekarchitect.patterns.command.demo02;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/29
*/
@Component("reviewApp")
public class ReviewAppImpl implements IAppClient {
private static final Logger LOG = LoggerFactory.getLogger(ReviewAppImpl.class);
public void offline() {
LOG.info("RPC层");
LOG.info("下线商品评价应用");
}
}第一版代码，没有使用任何设计模式，就是凭正常的思路，按照多层架构的方式实现。有朋友看到DegradeServiceImpl里面有个switch语句，我们是不是要用命令模式，来消除switch语句呢，答案当然是否定的。命令模式的价值不是用来消除switch语句的。
那边，这版代码的问题点在哪里呢？
如果不考虑设计模式，这版代码是正常的，可以使用的。
如果从命令模式的角度看，
IAppClient接口和它的两个实现类RecommendAppImpl、ReviewAppImpl属于当之无愧的命令执行者角色，也就是一线员工，真正干活的。
而DegradeServiceImpl这个类，它充当了其他两个角色，命令创建者，命令调用者。
这里面还没有真正意义上的命令角色。
下面的第二版代码，我们只是增加了命令角色，实现了一个简版的命令模式。
我们继续。
新增接口及类：
ICommand
CommandImpl
命令角色
ICommand：命令接口
注意，命令接口里面的方法,这个方法的名称，习惯上命名为execute()，而且这个方法一般有以下潜规则。
1，没有入参：原因是参数已经通过构造函数或者set方法，传入到命令对象了。为什么不通过方法参数来传递，主要是为了方便命令调用者调用该方法。否则就需要命令调用者自己准备参数了。而命令模式中，方法参数通常是命令创建者在创建命令时，提取准备好的。
2，没有返回值：原因是命令调用者通常不关心方法的返回值，如果要返回值，还比较麻烦，需要通过回调来实现，做过多线程开发的朋友应该有这方面的经验。
总而言之，命令角色里面的方法，越简单越好。随着后面的讲解，大家就能明白其中的深意。
package com.geekarchitect.patterns.command.demo03;
/**
* 应用下线命令接口
*
* @author 极客架构师@吴念
* @createTime 2022/8/29
*/
public interface ICommand {
void execute();
}CommandImpl：命令实现类
命令实现类，它里面除了要实现接口的execute()方法外，通常包括一下要素。
1，封装方法参数的属性：如这里面的commandPara属性，这个属性通常是通过构造函数或者set方法，由命令创建者角色进行初始化。
2，代表命令执行者的属性：如这里面的appClientV2属性，这个属性也是通过构造函数或者set方法，由命令创建者角色进行初始化。在execute()方法中，调用命令执行者对象的相应方法，执行命令。
3，命令状态属性：用于存储命令执行的状态，在undo，redo等功能中使用，所以命令角色的对象，是一个有状态的对象。在web项目开发中，通常都是无状态的对象。有状态的对象一般很少见。
package com.geekarchitect.patterns.command.demo03;
import com.geekarchitect.patterns.command.demo04.DegradeServiceImplV3;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.Map;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/29
*/
public class CommandImpl implements ICommand {
private static final Logger LOG = LoggerFactory.getLogger(DegradeServiceImplV3.class);
private final Map commandPara;
private final IAppClientV2 appClientV2;
public CommandImpl(Map commandPara, IAppClientV2 appClientV2) {
this.commandPara = commandPara;
this.appClientV2 = appClientV2;
}
@Override
public void execute() {
LOG.info("入参commandPara={}", commandPara.toString());
this.appClientV2.offline(commandPara);
}
} DegradeServiceImplV2
因为引入了命令角色，所以这个类里面的方法，也需要做出调整。如下：
这里面的代码，创建了命令角色的对象，并且把方法参数commandPara,以及命令执行者appClientV2
通过构造函数，传输给了命令角色对象。
那么这么多，有什么好处呢，看后面的方案点评。
package com.geekarchitect.patterns.command.demo03;
import com.geekarchitect.patterns.command.demo02.AppCodeEnum;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Service;
import java.util.HashMap;
import java.util.Map;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/29
*/
@Service
public class DegradeServiceImplV2 implements IDegradeServiceV2 {
private static final Logger LOG = LoggerFactory.getLogger(DegradeServiceImplV2.class);
@Autowired
private ApplicationContext applicationContext;
@Override
public void offline(int appCode) {
LOG.info("Service层——DegradeServiceImpl");
Map commandPara = new HashMap();
commandPara.put("appCode", String.valueOf(appCode));
IAppClientV2 appClientV2 = null;
switch (AppCodeEnum.getEnumByCode(appCode)) {
case REVIEW: {
appClientV2 = (IAppClientV2) applicationContext.getBean("reviewAppImplV2");
break;
}
case RECOMMEND: {
appClientV2 = (IAppClientV2) applicationContext.getBean("recommendAppImplV2");
break;
}
default: {
LOG.info("appCode {} 不存在");
}
}
ICommand offlineCommand = new CommandImpl(commandPara, appClientV2);
offlineCommand.execute();
}
} 第二版代码，相比第一版代码，增加了命令角色。它的好处就是，实现了DegradeServiceImplV2和命令执行者IAppClientV2的解耦合。从上面的交互图，也可以看出来，DegradeServiceImplV2类并没有调用IAppClientV2实现类里面的方法。而是通过命令角色调用的。
这版代码，从命令模式的角度看，已经增加了两个明确的角色：
命令执行者角色：IAppClient接口和它的两个实现类RecommendAppImpl、ReviewAppImpl。
命令角色：ICommand接口及CommandImpl实现类。
而DegradeServiceImplV2仍然隐形的充当着命令创建者和命令调用者角色，它既创建命令对象，又调用命令对象的execute()方法。
这版可以算是形成了命令模式的雏形，一个命令模式，命令角色作为核心，不能缺少，其他几个角色，都可以变通。而完整的命令模式，还需要把命令创建者和命令调用者分离，才能发挥命令模式的价值。
我们继续看第三版，完整的命令模式。
新增接口及类：
ICommandManager
CommandManagerImpl
现在，命令模式的四种角色全部出现：
命令角色：ICommand、CommandImpl
命令创建者角色：IDegradeServiceV3、DegradeServiceImplV3
命令调用者角色：ICommandManager、CommandManagerImpl
命令执行者角色：IAppClient、RecommendAppImpl、ReviewAppImpl
命令模式的交互图，可以分为两个阶段：
1，创建命令阶段：由命令创建者角色，创建命令角色的对象，初始化命令对象所需的参数以及命令执行者角色，然后将命令对象，传输或者注册给命令调用者角色。
2，执行命令阶段：由命令调用者角色，根据自身需求，自主调用命令对象里面的方法，发出执行命令的请求，由命令对象调用和它绑定的命令执行者角色的方法，执行命令。
ICommandManager
命令调用者，通常需要提供一个方法，让命令创建者，可以把创建好命令对象，传输或者注册给自己。
package com.geekarchitect.patterns.command.demo04;
import com.geekarchitect.patterns.command.demo03.ICommand;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/30
*/
public interface ICommandManager {
void addCommand(ICommand offlineCommand);
}CommandManagerImpl
命令调用者，它里面通常会有一个集合属性，用来存储命令创建者，传输或者注册给自己的命令对象。然后根据情况，依次从集合取出命令对象，执行命令。
这里我是采用定时器模拟的，也有可能是用户在前台触发引起的，这种GUI代码，Java程序员一般比较陌生。
package com.geekarchitect.patterns.command.demo04;
import com.geekarchitect.patterns.command.demo03.ICommand;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import java.util.ArrayList;
import java.util.List;
import java.util.Timer;
import java.util.TimerTask;
/**
* @author 极客架构师@吴念
* @createTime 2022/8/30
*/
@Component
public class CommandManagerImpl implements ICommandManager {
private static final Logger LOG = LoggerFactory.getLogger(CommandManagerImpl.class);
private final List commandList = new ArrayList<>();
public CommandManagerImpl() {
startTimeJob();
}
@Override
public void addCommand(ICommand offlineCommand) {
LOG.info("添加命令 offlineCommand = {}", offlineCommand.toString());
commandList.add(offlineCommand);
}
public void startTimeJob() {
TimerTask timerTask = new TimerTask() {
@Override
public void run() {
while (commandList.size() > 0) {
ICommand offlineCommand = commandList.remove(0);
offlineCommand.execute();
}
}
};
Timer timer = new Timer();
timer.schedule(timerTask, 3000, 1000);
}
} 这版代码，完整的实现了一个基于命令模式的降级模块。这个重构的过程，就是不断的提取出，抽象出新角色的过程。核心角色是命令角色，然后是其他三个角色。
Why，为什么要这么做？
答案很简单，就是为了解耦合，就是为了复用，就是为了支持更复杂的功能，这里我们不多说，后面会展开说明。
Encapsulate a request as an object，thereby letting you parameterize clients with different requests，queue or log requests，and support undoable operations.
—— Gof《Design Patterns: Elements of Reusable Object-Oriented Software》
将请求封装为一个对象，从而让你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以便支持可撤销的操作。
——Gof《设计模式：可复用面向对象软件的基础》
命令模式的概念，相比前面我们分享的其他几个设计模式的概念，要具体的多。它里面的关键词，“排队”，“日志”，“可撤销”都是非常具体的，浅显易懂的。
从这个概念，我们主要能看出，命令模式主要的目的，就是对用户的请求排队，或者记录请求日志，以便实现可撤销的功能。关于撤销功能，大家在编辑器中经常用到，撤销，恢复操作，关于这些，我们后面会结合其他几个设计模式，进行讲解。
下面我们用REIS模型，对命令模式进行分析，大家就会理解的更透彻一些。
REIS模型是我总结的分析设计模式的一种方法论，主要包括场景（scene），角色（role），交互（interaction），效果(effect)四个要素。
场景，也就是我们在什么情况下，遇到了什么问题，需要使用某个设计模式。
当出现以下情况时，可能需要使用命令模式。
1，当希望实现面向对象中的回调机制时：命令模式，号称面向对象中的回调函数。
2，当想让执行的操作或者命令，支持排队功能时：也就是把命令对象放入对象，依次执行。互联网项目中的消息系统，就是干这个的。
3，当想让命令支持undo，redo功能时：也就是大家在记事本，word等编辑器里面经常见到的撤销，恢复功能。这个功能，我们后面结合备忘录模式进行详细讲解。
4，当想让命令支持日志功能时：通过对执行的命令进行日志记录，可以在系统发生崩溃时，恢复系统的状态。这个功能在以前的单机版架构的软件中，有其用武之地。互联网项目，项目的状态，都记录在数据库里面，恢复系统状态，可以借用数据库的日志恢复功能，所以互联网项目中，这个功能被冷落了。
5，当希望实现事务功能时：通过命令模式实现事务功能，在早期还有用，而互联网项目中，事务主要依赖数据库，所以在实际项目中，也很少遇到。
角色，一般为设计模式出现的类，或者对象。每种角色有自己的职责。
命令模式包含4种角色，命令角色（command role），命令创建者角色（command creator role），命令调用者角色（command Invoker role），命令执行者角色（command executor role），这四个角色，以命令角色为核心。
命令角色( command role)：命令角色是命令模式的核心，也是其他几个角色之间的桥梁。它里面往往封装了以下几个要素。
1，执行命令所需的参数：有命令创建者角色在创建命令对象时提供。
2，命令执行者的引用：用于调用命令执行者执行命令，简化的情况下面，命令角色也可以自己执行命令，而不依赖命令执行者角色。
3，执行命令的通用接口：通常是一个execute()方法，或者是action()方法。这个方法往往比较简单，没有入参，因为入参已经封装到类里面了，所以方法就不需要入参了。也没有返回值，如果有返回值，就比较麻烦了，需要通过特殊的方法获取执行结果。
4，命令执行的状态：保持命令执行的状态，可以在执行undo等操作时使用。
命令创建者角色（command creator role）:在原始设计模式中称为Client，用于创建命令角色，给命令角色设置具体的命令执行者角色，并将命令对象，传输或注册给具体的命令调用者角色。也就是命令创建者角色，只负责创建命令对象，但是不调用命令对象。
命令调用者角色（command Invoker role）:在原始设计模式中称为invoker，用于调用命令对象，执行命令。如果是仅仅调用命令，好像命令调用者角色没啥用，其实，它是命令模式中重要程度仅次于命令角色的一个角色。它不仅仅是简单调用命令对象。还起到命令排队，记录命令日志，实现undo，redo等操作。它的重要性显而易见。
命令执行者角色（command executor role）:在原始设计模式中称为receiver，是真正执行命令的角色，说的通俗点，就是个一线员工，干活的，而其他三个管理者，命令创建者角色，命令角色，命令调用者角色，都是管理层。三个管一个，累死这个傻小子。
交互，是指设计模式中，各种角色是如何交互的，一般用UML中的序列图，活动图来表示。简单的说就是角色之间是如何配合，完成设计模式的使命的。
命令模式，因为它通过命令角色，将命令创建者角色，命令调用者角色，命令执行者角色，进行了解耦合，所以它的交互图需要分为两个阶段，创建命令阶段和执行命令阶段。
交互图参考前面第三版代码中的交互图。
效果，使用该设计模式之后，达到了什么效果，有何意义，当然，也可以说说它的缺点，或者风险。
命令模式，具有以下效果。
1，解耦合：通过命令角色，将命令创建者角色，命令调用者角色，命令执行者角色，进行了解耦合。解耦合之后，命令角色和命令调用者角色，都有很高的可重用性。一个命令角色，可以传输或者注册给多个命令调用者角色。而命令调用者角色，可以调用不同的命令角色。
2，可扩展：扩展性主要体现在命令角色。每个具体的命令子类，都封装了一个命令。当需要增加新的命令时，只需要增加命令子类即可。命令调用者的代码几乎不需要做任何修改。
3，实现命令的undo，redo功能。
4，实现宏命令：这个后面我们会结合组合模式，进行详细讲解。
总结一下，根据REIS分析模型，对命令模式进行分析，命令模式包含4种角色，命令角色（command role），命令创建者角色（command creator role），命令调用者角色（command Invoker role），命令执行者角色（command executor role）。命令创建者角色将命令的参数，状态及命令执行者的相关信息，封装在独立的，可传输的，和可序列化的命令角色中，以便通过命令角色解耦合其他三个角色。最终实现命令的排队，日志及可撤销等高级功能。
命令模式里面的命令角色，它里面有方法执行的参数，以及方法执行的状态，所以，命令模式是有状态的，这也是它在互联网时代，发展遇到窘境的原因。互联网时代的web项目，受Http协议影响，通常是无状态的，特别是在基于多层架构的项目中，不论是控制器，服务层，还是DAO层，里面的类，基本上都没有状态。如果非要维持状态，小型Web项目系统，可以通过session来解决，而如果是分布式部署，则系统的状态，一般只能集中存储在缓存中，如redis集群中，或者干脆存储到数据库中。也就是在web项目中，对象的方法和对象的状态是分离的。这也是命令模式不太流行的原因。那么是不是说，就彻底没有用武之地呢。不是的，其实作为Java程序员，一直在享受命令模式带来的红利。
远的不说，就是上面我们刚刚使用的Timer，TimerTask，它里面就用的是命令模式，Timer是命令调用者角色，TimerTask是命令角色。类似的还有线程池，大家看看创建线程时，执行的Runnable接口，是不是，就是一个命令接口。命令模式无处不在，只不过不显山，不漏水。而且常常被并发编程中的一个设计模式——“生成者-消费者”模式，抢了风头。“生成者-消费者”模式的底层逻辑就是命令模式。
Runnable接口
另外，在Strus框架流行的年代，程序员继承Action类，实现execute()方法，也是命令模式在为我们服务。值得一提的是，命令模式还有另外两个别名，就是Action和Transaction，Struts框架的这个接口的命名，估计就是从命令模式里面来的。关于开源软件中的命令模式，我会在相关的《源码说》里面进行详细讲解。
Struts框架的Action接口
/**
* All actions may implement this interface, which exposes the execute() method.
*
* However, as of XWork 1.1, this is not required and is only here to assist users. You are free to create POJOs
* that honor the same contract defined by this interface without actually implementing the interface.
*
*/
public interface Action {
/**
* Where the logic of the action is executed.
*
* @return a string representing the logical result of the execution.
* See constants in this interface for a list of standard result values.
* @throws Exception thrown if a system level exception occurs.
* Note: Application level exceptions should be handled by returning
* an error value, such as Action.ERROR.
*/
public String execute() throws Exception;
}相关代码，已上传到github上，大家自行下载即可。
今天分享的命令模式，只是它的主体内容，还有两个重要功能，如下所示，我们要结合其他设计模式进行讲解。
宏命令：联合命令模式和组合模式进行讲解。
undo,redo功能：联合命令模式和备忘录模式进行讲解。
极客架构师，专注架构师成长。
关注我，我将持续分享更多架构师的相关文章和视频，我们下期见。
| 留言与评论（共有 0 条评论） “” |
