如何设计一套SPI应用架构

一、API和SPI区别

1.1 API

为了做一个简单区别,先来说一下API(Application Programming Interface) ,目前一般企业架构内部都会有一个RPC框架,如果没有自研的也都在使用开源的比如比较有名的DUBBO,JSF等。业务需求确定之后,技术侧也会相互沟通说需要对方提供几个API接口。从面向接口编程的方式而言如下图1所示。另外还有当前的开放平台也是把企业内部的接口通过API网关暴露出去提供给第三方开发者如图2所示。这两种情况下说的都是API。接口我自己定义,自己来实现,然后暴露出去供别人调用,这是属于API概念。

如何设计一套SPI应用架构

图1

如何设计一套SPI应用架构

图2

1.2 SPI

SPI(Service Provider Interface)  一方制定接口,另外一方提供接口实现,比如在开放平台中,有平台制定接口,第三方去实现。这里的第三方是指开放平台的开发者,SPI这种调用关系多存在于开放平台架构中。接口我自己定义,但是我并不去实现,而是有其他模块或系统去实现,这是属于SPI概念。

1.3 小节

API是属于任意的调入,调出方式,这里的任意特指所有接口参数数量,类型都不固定,比如企业内部发布了很多业务的接口,同时很多业务的接口都发布到了API GATEWAY上从而开放出去。SPI是属于标准化的调入,调出方式,需要有一方来创建接口标准,参数数量和类型固定之后,由第三方来实现。下图3是以平台为例。SPI是一种思想,这篇文章中主要以开放平台做为案例来说明,另外我们也会在下文讲述这种SPI思想。

如何设计一套SPI应用架构

图3

二、术语约定

2.1 SPI

由平台(比如淘宝开放平台、京东开放平台)定义服务接口,第三方来实现。通过HTTP协议来调用。

2.2 场景

一组SPI接口的集合,SPI的权限管理单位。

2.3 回调地址

SPI服务的实现,一个可访问的HTTP连接。请求格式和响应格式都是有平台方制定。

三、业务场景

一种场景对应一个业务,或者可以称作业务场景,比如会员通场景,购物车回调场景。场景同时还分为官方场景和自定义场景。这篇文章中所讲述的主要是官方场景。实际上呢放开官方场景限制后,技术上稍作改动即可实现自定义场景。正如术语约定中所述,场景是一组SPI接口的集合。创建好场景以后,实现场景的一方实际上是实现的场景下的一组接口,从而来满足这个业务实现的。以会员通场景举例,需要同步线上和线下的会员信息,保证一个用户可以在比如京东商城网站和在线下比如奥康店都可以享受到会员的待遇。这样就会涉及到绑定查询、绑定、注册SPI接口的实现。

如何设计一套SPI应用架构

这个场景下一共包含3个SPI接口,1-绑定查询SPI,2-注册SPI, 3-绑定SPI。

四、架构实现

如何设计一套SPI应用架构

4.1、场景创建

由平台运营人员来创建,也可以将创建权限开放出去各个业务方都可以创建自己的场景。

4.2、路由寻址

平台调用者要能够知道请求到什么地方,也就是2.3中说的回调地址,实现方实现接口的时候配置的一个URL地址。开发者要实现一个场景的API必须先成为开发者,这样获取到一个APPKEY。在调用者请求SPI GATEWAY的时候传入的参数包括场景ID,具体API的名称method,APPKEY这三个参数。这样平台就可以路由到具体的URL,如下图:

如何设计一套SPI应用架构

4.3、字段映射

开放平台供外部查看的文档包括的字段和实际内部接口中的字段类型有不一致的情况,这种情况下就需要字段映射了。

4.4、信息转换

系统参数和业务参数的校验,以及错误信息的返回都会涉及到信息转换。

4.5、账号

普通的开放比如通过商家账号即可实现全流程业务。但是在SPI开放场景下会涉及到另外一个账号类型,这个新的账号类型可以成为企业账号,一个企业账号下又包括很多个品牌,比如宝洁公司下涵盖飘柔、潘婷、海飞丝等众多品牌,品牌下又有很多个店铺。

4.6、SPI

RESTFul 风格的SPI跟文档总是密不可分,一个开发者基本的诉求包括SDK、测试、文档。因此文档是开发者重点关心的一个方面。开源的实现有apidoc、Swagger等。

4.7、流控

流控是一个网关基本的功能,同样SPI GATEWAY也必须具备。在开放平台中流控要做分布式流控,一般会给调用者分配流量包,比如按照分钟,小时,天等。<!--后续另有专题文章介绍-->

4.8、授权

开发者要想获取到使用他们应用的用户的数据,必须得到用户的授权。如下图所示关系。<!--后续另有专题文章介绍-->

如何设计一套SPI应用架构

五、测试

5.1、平台业务调用平台的MOCK测试

作为平台一方也就是创建场景并创建SPI的一方,在开发者实现SPI并对接场景上线之前,平台一方需要查看自己创建的各种SPI接口是否规范,是否能够调用。这个时候就需要类似MOCK测试的功能。由SPI网关来模拟开发者的实现并返回对应的结果。

5.2、平台调用实现方的MOCK测试

同理,在开发者实现了一个场景下的SPI之后,自己需要先行测试,那么由SPI网关平台提供一个可测试SPI实现的功能,有平台发起来调用开发者的实现接口,当然这个时候开发者要配置成功自己的回调地址。

六、SPI是一种思想

SPI也是一种思想。继续回到如下这张图,调用者自己定义接口,由实现者去实现该接口,同时利用多态的特性可以有很多个接口实现者。这样调用者就可以根据需要调用各种实现。

如何设计一套SPI应用架构

这种思想跟我们熟悉的策略模式很类似,如下图所示,抽象策略类是接口的制定者,具体策略类是接口的实现者。那么SPI是把面向接口编程的基本思想应用到了实际的业务场景中,放大看可以解决开放平台调用开发者的基本需求从而实现无界零售线上线下数据互通的业务场景。

如何设计一套SPI应用架构

七、总结

我们可以理解成SPI是API的反向调用,通常开发者通过调用平台的API接口获取平台提供的数据比如用户、订单、商品等数据信息。那么在一种新的业务场景下,平台需要向开发者请求数据信息,就需要一个类似API而且又跟API调用相反的路径来进行。同时平台去创建标准场景,场景下创建SPI,并且有开发者按照平台统一的标准来实现。这样做可以让更多的开发者快速的接入到平台的SPI场景中来,因为我们统一了接入标准,也就是统一了接口参数。

如何设计一套SPI应用架构