前言
最近在做一个权限控制的功能，其中一项服务是对用户进行冻结，具体的业务逻辑不一定合适细讲，就以“把大象装进冰箱”来抽象代替。其有如下流程：
1.把冰箱门打开
2.把大象放进去
3.把冰箱门关上
需要依赖两个服务提供方：
1.冰箱管理员（开门、关门）
2.搬运公司（搬大象进冰箱）
那么该如何设计服务的调用模式呢？
基于“标准”的调用
上古时代，服务提供方、和调用方会一起约定一个入参出参的报文标准（xml、json），根据这个约定，服务提供方发布http服务，调用方也根据这个入参出参标准来调用提供方的http服务。这里的入参出参约定，以及http协议本身，都是一种标准。即双方以一种共同遵守的标准，来组织服务调用关系。
基于API的调用
微服务时代，服务提供方对外暴露自己的API接口，隐藏具体实现逻辑。服务调用方引入对方的API之后，即可调用对方的服务。以API依赖的方式组织服务调用关系。
基于SPI的调用
中台时代，提倡大中台，小前台。中台负责实现“把大象装进冰箱”这个业务涉及的可复用的流程和能力，预留出对应能力的SPI拓展点，业务方通过实现对应的spi拓展点来提供差异服务。比如有些业务希望使用搬运工把大象搬进冰箱，另外一些业务希望使用吊车把大象搬进冰箱，通过在spi拓展点中实现不同的逻辑，即可达成这一点。
三者本质区别
这里引用 张群辉(辉子) 的定义
1.“标准”即双方共同遵守的协议。（比如http协议，或者http调用中的入参、出参定义。基于消息解耦其实也属于这一范畴）
2.接口实现者拥有接口的是API模式 ，一个API一般只有一种实现，提供一种能力。（比如搬运公司提供搬大象进冰箱的能力）
3.使用接口者拥有接口的是SPI模式，使用接口者先定义接口，实现者根据接口定义来实现具体逻辑，一种SPI可以有多个实现。（比如中台架构定义的把大象搬进冰箱SPI拓展点，可以实现为搬运工搬，也可以实现为吊车搬）
三者取舍
我所开发的权限控制功能，完全没有可能成为一个权限控制中台，加上中台的概念现在基本也快凉了，所有首先放弃中台SPI拓展的设计模式。
那么如果采用API依赖模式，将会是如下情况.
1.服务提供方发布自己的API
/***
* 搬运公司
*/
public interface MovingCompany{
void move(Elephant elephant);
}
/***
* 冰箱管理员
*/
public interface RefrigeratorManager{
void open();
void close();
}
2.调用方引入对方服务，然后调用，以实现把大象装进冰箱
void putElephant2Refrigerator(elephant){
refrigeratorManager.open();//把冰箱门打开
movingCompany.move(elephant);//把大象放进去
refrigeratorManager.close();//把冰箱门关上
}
这种调用模式有什么问题呢？
1.如果有一天，业务要求把大象装进冰箱之前，还得清洗一下大象，那么我需要修改代码，引入一个清洗大象的服务，然后发布生效。
2.如果有一天，国外一个公司觉得这个“把大象装进冰箱”的功能很好，希望购买这个服务，部署到他们公司去，那也搞不定，因为这个功能强依赖了我当前引入的冰箱管理员和搬运公司，我需要改代码，把依赖的冰箱管理员和搬运公司换成他们当地的。
最终，“把大象装进冰箱”功能使用了基于“标准”的调用模式。
1.所有需要参与到“把大象装进冰箱”的服务提供方，都按照标准（入参列表和出参）实现下述接口来提供服务（接口名、方法名随意）
Result<Void> putElephant(String xxxId,String xxxType,String ext);
2.服务节点提供服务元数据,落配置库，用来进行后续服务初始化
{
"operateType":"XXX",
"order":"1",
"interface":"com.xxx.service",
"method":"putElephant",
"Url":"xxx.xxx.xxx.net:12220",
"uniqueId":"xxx",
"argTypes":[
"java.lang.String",
"java.lang.String",
"java.lang.String"
],
"description":"把大象搬进冰箱"
}
3.服务执行时，读取配置库，根据服务节点元数据的顺序，动态初始化服务，泛化调用服务节点（dubbo泛化调用、sofa泛化调用等）。
回到API调用模式的两个问题点，这种模式有如下好处。
1.参与“把大象装进冰箱”的服务节点全部配置在数据库，执行时动态初始化。在应对“把大象放进去之前，先清洗一下大象”这种业务变动时，只需要将清洗大象的服务节点在配置库中进行配置即可，不需要应用发布。
2.当需要SAAS化，部署到一个全新环境时，数据模型和代码逻辑都是可复用的，只需要把参与服务编排的节点配置替换为对方需要的即可，比如要把冰箱管理员和搬运公司替换为对方当地的公司（新的服务也必须遵守接口标准），只需要做配置库的变更，无需做代码改造。
后记
不同系统设计时，面对的领域问题不一样，解法就有差别。当前系统间调用，还是以API模式为主；绑在中台上的业务系统的还是以SPI模式来调用下游的API（个人片面理解，对中台没有深入研究）。以“接口标准”这样的服务编排、泛化调用模式，仅适用一些特殊场景。
