API开放平台
前言
通过一个项目来学习一下如何设计一个多服务的系统。同时也能学习Spring Cloud Gateway、Dubbo、API签名等一些知识。
项目架构
用户前台
普通用户
例如管理员发布了一个新的接口A，如果一位开发者并没有注册为该平台的用户，那么即便这位开发者拿到了这个接口地址，也是不可以使用接口A的。
当他注册为平台用户后，后台会给他生成AccessKey和SecretKey（后文简称为ak和sk）用于API签名认证，这时，用户带着这两个key，就可通过前台提供的在线测试或者客户端SDK来调用想要的接口了。
管理员
管理员职责就是管理接口，包括接口的上线、下线、添加等
客户端SDK（api-client-sdk）
若管理员将接口下线，则请求无效
通过AccessKey和SecretKey来请求api-interface接口服务。其中ak和sk只有用户在平台注册账号后才会分。当然，添加网关后，应该在api-interface前使用添加一层网关服务来避免api接口的直接暴露
sdk中的请求方法应该和api-interface中提供的接口一一对应，也就是两边应该同步修改
网关（api-gateway）
使用Spring Cloud Gateway来完成一下功能
- 统一鉴权认证：应用 API 签名认证算法校验用户请求的合法性。根据请求拿到用户信息后从数据库中获取ak、sk进行比较，如果相同则代表用户请求合法
- 公共业务逻辑：对每个接口的调用进行集中的统计 。这类似于Spring MVC中的拦截器和Spring中的AOP
- 路由转发：前端发送请求到 API 网关，通过网关转发到实际的 API 接口 。这样就避免了直接将完整的接口地址暴露出来
- 流量染色：给经过网关的请求加上特定的请求头参数，便于让实际的 API 服务确定请求来源及合法性
接口服务（api-interface）
真正实现和提供接口的地方，可以只编写controller层
抽象接口（api-common）
在网关层由于要进行API鉴权，这避免不料要查询数据库，但是网关服务项目并没有使用MyBatis-Plus，为了避免写重复的代码，利用Dubbo分布式改造，使得网关层可以通过RPC来调用后端服务的方法
服务后台（api-backend）
最核心的业务层服务！
- 用户注册时会自动生成其ak和sk
- 接口信息的管理，即普通的增删改查，发布、下线接口
- 接口调用统计（没错，网关是通过rpc调用这里的服务）
- 当前台用户要进行在线测试时，我们会使用到用户的ak和sk，只有这样才能够比较安全的调用接口；而再通过客户端SDK，就能比较方便地去请求接口