前言

最近在做一个权限控制的功能，其中一项服务是对用户进行冻结，具体的业务逻辑不一定合适细讲，就以“把大象装进冰箱”来抽象代替。其有如下流程：

1.把冰箱门打开
2.把大象放进去
3.把冰箱门关上

需要依赖两个服务提供方：
1.冰箱管理员（开门、关门）
2.搬运公司（搬大象进冰箱）

那么该如何设计服务的调用模式呢？

基于“标准”的调用

上古时代，服务提供方、和调用方会一起约定一个入参出参的报文标准（xml、json），根据这个约定，服务提供方发布http服务，调用方也根据这个入参出参标准来调用提供方的http服务。这里的入参出参约定，以及http协议本身，都是一种标准。即双方以一种共同遵守的标准，来组织服务调用关系。

image.png

基于API的调用

微服务时代，服务提供方对外暴露自己的API接口，隐藏具体实现逻辑。服务调用方引入对方的API之后，即可调用对方的服务。以API依赖的方式组织服务调用关系。

image.png

基于SPI的调用

中台时代，提倡大中台，小前台。中台负责实现“把大象装进冰箱”这个业务涉及的可复用的流程和能力，预留出对应能力的SPI拓展点，业务方通过实现对应的spi拓展点来提供差异服务。比如有些业务希望使用搬运工把大象搬进冰箱，另外一些业务希望使用吊车把大象搬进冰箱，通过在spi拓展点中实现不同的逻辑，即可达成这一点。

image.png

三者本质区别

这里引用 张群辉(辉子) 的定义
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泛化调用等）。

image.png

回到API调用模式的两个问题点，这种模式有如下好处。
1.参与“把大象装进冰箱”的服务节点全部配置在数据库，执行时动态初始化。在应对“把大象放进去之前，先清洗一下大象”这种业务变动时，只需要将清洗大象的服务节点在配置库中进行配置即可，不需要应用发布。
2.当需要SAAS化，部署到一个全新环境时，数据模型和代码逻辑都是可复用的，只需要把参与服务编排的节点配置替换为对方需要的即可，比如要把冰箱管理员和搬运公司替换为对方当地的公司（新的服务也必须遵守接口标准），只需要做配置库的变更，无需做代码改造。

后记

不同系统设计时，面对的领域问题不一样，解法就有差别。当前系统间调用，还是以API模式为主；绑在中台上的业务系统的还是以SPI模式来调用下游的API（个人片面理解，对中台没有深入研究）。以“接口标准”这样的服务编排、泛化调用模式，仅适用一些特殊场景。