OpenAPI SDK组件介绍

news/2024/4/26 13:58:53/文章来源:https://blog.csdn.net/qq_30038111/article/details/129219278

背景

公司成立以来，积累了数以万计的可复用接口。上层的SaaS业务，原则上要复用这些接口开发自己的业务，为了屏蔽调用接口的复杂性，基础服务开发了apisdk组件，定义了一套声明OpenAPI的注解、注解解析器，实例化OpenAPI的工具，封装了签名算法，同时提供了查询域名、查询参与签名的secret、获取Token等基础服务。不同场景的OpenAPI，如App端和Web端，需要调用不同的基础服务。

这套apisdk组件经过了多年的应用，功能上完全hold住业务需求，然而问题来了。

公司在疫情这几年的经济效益实在太差，我做这期分享前，裁了50%（可能有人猜到是哪家公司），当然大多数的互联网公司都有裁员的动作。那裁员之后的业务谁来做？公司战略是交给外包。

但是我们的业务完全依赖基础服务的自研网关、用户体系、接口暴露组件、apisdk组件、基础服务等，外包要承接业务，必须要学会这套东西。但这些东西封装的并不完善，简单来说，都不是傻瓜式的，对外包来说成本太高。别说外包了，业务部门说直白一点，是面向接口编程，对新入职的同学，学习成本高，开发效率低。

于是，为了让一切变得傻瓜式，我承担了网关接口暴露组件、apisdk的二次封装。此次分享内容主要以apisdk为主，涉及的技术/内容：Springboot拓展点的应用、自定义Spring扫描、Spring IoC（FactoryBean）、JDK动态代理、aop源码拓展、javassist字节码技术等。

注：分享的源码全部是自己代码，借鉴了Spring注解、aop等源码，不含公司成分，目的是分享这些技术的实战。

apisdk组件

apisdk组件包括了开放接口声明、签名算法、Http执行器（okhttp3）、响应数据解析等模块，其中接口声明、参与签名的参数需要开发者提供，开发者调用接口方法，触发Http执行器发起接口调用。

二次封装原因：除了学习成本高，它还是java和kotlin混用，原作者早已离职，维护困难，只能在原基础上做封装。

下面截图是原始的apisdk和二次封装后的apisdk使用方式的对比，通过截图，大家会对开放接口的声明、请求上下文构建、接口调用方式有一定的认识，有助于大家理解屏蔽了哪些操作。

接口声明

原接口声明

在这里插入图片描述
接口声明必须要有SdkContext固定参数，接口调用前，必须手动调用基础服务构造SdkContext上下文，这样才能正确的发起调用。

二次封装后接口声明

在这里插入图片描述
二次封装后，由底层完成了SdkContext参数的自动填充。

接口调用

原调用方式

在这里插入图片描述
上面是模拟调用的过程，包括接口实例化、SdkContext封装、接口调用，实际的调用过程比这个复杂的多。

二次封装后接口调用方式

在这里插入图片描述

apisdk二次封装介绍

二次封装涉及到的技术：自定义自动装配、自定义Spring扫描、Spring IoC（FactoryBean）、JDK动态代理、aop源码拓展、javassist字节码技术等。下面简单的介绍下二开的思路及相关的技术点。

思路

原始接口声明必须要定义SdkContext参数，必须要手动调用多个服务创建SdkContent，必须要手动声明接口实例。据我了解：

公司不允许跨区域（域名）调用开放接口，如不允许中国区调用美国区暴露的接口。
调用开放接口一定要有SdkContext参数
SdkContext构建的步骤是固定的，但涉及的服务较多

综上，域名问题可以通过部署环境动态获取（已有服务）；开发者可以不定义SdkContext参数，底层通过字节码技术动态新增SdkContext方法参数；底层拓展aop的advice，方法执行前构建SdkContext参数；实现Spring扫描组件，通过FactoryBean实例化接口，开发者使用注解即可完成Bean对象的依赖。