自由发布接口并获得收益的平台

1. 背景与目标

1.1. 提出背景

接口服务层的目标是打通技术和业务的壁垒，技术可以专心的进行接口开发，产品和业务层在此基础上不断进行组合衍生出各种各样的产品。同时，分账的机制，可以确保接口的开发者是能够得到回报的。这个机制也鼓励开发者开发出更需要、更高效、更易用的接口。

接口服务层主要做两件事情，为前端提供业务接口，为后端各个服务提供便利的接口调用，同时稳定性和性能以及可扩展性，也是这个系统最需要考虑的因素。

在这个系统，成员可以做什么：

1. 参与系统的搭建，得到收益
2. 参与拦截器的设计和开发，提出有意思的拦截器，并发布到接口层，得到收益
3. 把自己想要的点子，以服务接口的形式发布到接口层，提供给他人调用，并得到收益
4. 使用接口层上他人提供的服务，快速的开发一款新产品（=>新产品扶持，接口不收费）

1.2. 目标与内容

• 服务/接口注册：当后端开发完接口后在平台注册接口（支持批量导入），并允许定义接口是否收费，收费标准等，只有持有社区成员才可以注册服务/接口
• 请求转发：将用户的请求转发到实际的业务服务，内网请求，在获得授权的情况，可以直接进行接口访问，转换成微服务架构
• 请求拦截器：负责对请求的通用性的处理，比如请求计数器，用于请求的监控和计费
• 可以设计链上的分账合约，使每一个人参与方都能获得回报

1.3. 数据结构

数据对象	字段
服务(Service)	服务名称[string]，owner[address]，资源名称[string]，拦截器[List]，启用合约分账(启用后将创建链上的智能合约)，需要用到的用户属性[List]
服务详情(ServiceDetail)	(服务的一些详细的用于展示信息，可没有)
接口(Resource)	接口 ID，服务 ID，接口名称[string]，调用地址1[string]，调用地址2[string]，调用地址3[string]，调用异常处理[json]，owner(默认继承自服务)，请求方式，是否公开
接口设置(ResourceSetting)	接口 ID，是否收费，拦截器[List]，是否需要用户鉴权，是否需要 app 鉴权，是否存在数据更新，是否启用链路追踪，是否启用合约分账(启用后将创建链上的智能合约)，调用异常处理[json]，调用约束
接口信息(ResourceInfo)	接口 ID，接口参数[json]，接口返回[json]，接口说明
接口告警规则(ResourceAlertRule)	规则 ID，接口ID，规则名称，规则定义，owner
接口告警(ResourceAlert)	告警 ID，通知方式，处理方式
拦截器(Interceptor)	拦截器 ID，拦截器名称，专属配置[json]，是否同步(同步拦截器的添加要十分严格)，owner（收费？）

2. 核心接口

• 各个数据对象的增删改查（需要登录，且必须为社区成员，只有对象的 owner 才有对象的修改权限）

• • 接口告警除外
  • 拦截器的添加等于新版本的发布，是否可以设计为动态添加？

• 核心请求接口格式：

• • https://[endpoint]/api/[service]/[res] (endpoint 为指向接口服务的域名，service 为服务名称，res 为接口路径)
  • 参数与请求方式，继承自接口
  • 特殊的 Header：AppToken，UserToken

3. 核心业务逻辑

3.1. 处理业务请求

处理业务的请求的流程如下，先执行拦截器的处理，再执行到实际服务的转发。其中拦截器分成两类，异步执行的，和同步执行的，请求转发需要等待同步执行的拦截器执行完成。异步执行的拦截器，将提交到线程池进行处理，提交到线程池前，将请求相关的数据以及时间点，请求 ID 等以及拦截器列表构成线程的执行数据。

3.2. SDK 调用

内网直接调用时，SDK 定期从接口服务同步路由 Map，通过路由 Map 获取当前调用者需要调用的请求，并转发请求到目标服务器，SDK 转发请求时会将请求的 requestId 一起携带到下一个请求，如果无 requestId 则将生成一个。

如果是内网商业调用，则与普通调用相同，只是接口服务的地址改成内网。