标签: Da-API平台

Da-API平台-项目部署

前后端分离部署：原生部署、宝塔方式部署、Docker部署、工作流部署

前端：npm run build项目打包
后端：

backend 项目：web 项目，部署 spring boot 的 jar 包（对外的）

gateway 网关项目：web 项目，部署 spring boot 的 jar 包（对外的）

interface 模拟接口项目：web 项目，部署 spring boot 的 jar 包（不建议对外暴露的）

关键：网络必须要连通

holic-x...大约 30 分钟

Da-API平台-分布式改造&RPC

1.RPC框架引入

网关业务逻辑梳理

问题：网关项目比较纯净，没有操作数据库的包、并且还要调用之前项目写过的代码，复制粘贴维护麻烦。

理想：直接请求到其他项目的方法（调用）

目前网关项目遇到一个问题，就是网关项目比较纯净，没有涉及数据库操作的包，但同时需要调用之前编写过的代码。尽管复制粘贴一开始并不麻烦，但是随着次数增多以及未来的修改维护，就变得相当繁琐了。（考虑系统迭代的可维护性和可扩展性）

因此，理想情况就是希望能够直接请求 api-platform-backend 项目中的 invokeCount 方法，此处引入一个概念：远程过程调用（RPC）。

holic-x...大约 23 分钟

Da-API平台-接口发布、在线调用

1.接口发布下线

【1】接口管理（发布、下线）

概念设计

（1）流程设计

基于现有接口管理模块开发一个用于发布和下线接口的功能。本质上来说，就是改变每条接口数据的状态。在设计接口信息表时，之前已经预留了一个状态字段status。其中，关闭和开启分别对应接口的下线和上线。只有状态为 1 的接口才可以被用户调用，否则将无法调用。（优先后台接口开发，后续完善页面设计）

（2）功能设计

开发发布接口和下线接口（仅管理员可操作这两个接口，防止用户越权操作）。大致规划一下思路：

发布接口：这个接口需要执行哪些任务呢？首先需要验证接口是否存在，然后判断接口是否可调用，否则访问接口都是 404，影响用户体验。如果接口可以调用，需要修改数据库中该接口的状态为 1，表示接口已经被发布，状态默认为 0(关闭)。

holic-x...大约 22 分钟

Da-API平台-平台功能扩展

1.问题分析

（1）URL存储和校验规则依托？

此处要梳理一个流程，请求配置必须通过网关转发到对应接口服务地址，因此此处要对url进行处理（后台调用访问的是网关IP+请求路径，网关验证的是真实URL完整路径）

因此要么url中保存完整的URL请求信息，要么在后台调用和网关验证处理的时候对URL进行解析，分别进行验证（项目中一开始没有对URL做处理，导致后台调用和网关验证用的都是URL，这样就会存在冲突）

【1】假设URL存储的是网关IP+请求路径：后端直接访问URL就会经过网关，网关转发请求源变为接口IP+请求路径，如果后端校验直接拿request的路径做验证则肯定会拿不到数据（因为网关和接口的IP不同），所以要注意处理

holic-x...大约 7 分钟

Da-API平台-接口调用统计可视化

1.需求分析

各接口的总调用次数占比（饼图）取调用最多的前 3 个接口，从而分析出哪些接口没有人用（降低资源、或者下线），高频接口（增加资源、提高收费）。

进一步思考：

现在可以进行哪些分析呢？基于当前的业务和数据，可以分析系统中的用户注册情况，即每日新增用户数量或总用户数，或者是，哪些接口被频繁调用、对于同一用户，他们使用的接口情况，例如某个用户今天调用了多少次接口。

基于现有的数据，假设一些需求。例如，设想统计某个特定用户对接口的调用次数占比，可以采用饼图来呈现这个数据，通过图表，能直观地看到接口被调用的次数。然而，在着手处理这个需求之前，必须要明确分析的目的是什么。为了让用户能够了解在某段时间内使用哪些接口的次数较多，可以据此判断某个接口在特定时间内是否被频繁调用，如果某个接口在某段时间内几乎没有调用记录，那么是否需要继续保持资源的分配呢？另一方面，对于高频次调用的接口，可以考虑是否需要增加相应资源，或者在某些情况下进行收费等等。因此，这个需求背后是有很多的价值和意义的。

holic-x...大约 6 分钟

Da-API平台-API网关&接口调用统计

1.构建思路

【1】接口调用统计思考

目前后端项目有 api-platform-backend、api-platform-interface，api-platform-client-sdk，在实际开发中可能会思考一个问题：为什么不在一个工程呢？（类似父子模块构建）

从项目开发设计上来说，这些项目本来就不应该在一个工程。举个例子，假设团队中有一个负责开发平台的团队，还有一个负责提供接口的团队。这两个团队有必要将项目放在同一个目录下吗？其实并没有必要。因为平台可以接入任何系统开发的接口，不一定是同一个团队或者公司内部的项目。而且可以将设计的范围扩大一点，除了提供给用户使用，还可以帮助开发者实现变现。