基于微服务的加解密方法、API网关系统及设备

摘要

本申请提出一种基于微服务的加解密方法、API网关系统及设备，该方法包括：接收终端发送的请求报文；根据请求报文的请求头，判断请求报文是否需要进行解密；若确定需要解密处理，则根据API网关的配置文件中存储的预设密钥，对请求报文进行解密。本申请由API网关与终端进行加解密交互，业务微服务不进行任何加解密操作，所以在各业务微服务系统开发时无需关注加解密功能的开发，提高了开发效率，测试简单，不需要对所有业务微服务逐个进行测试。当需要变更加密算法或者修改密钥时，只需要修改API网关和终端中的相关配置即可，不容易出现遗漏或者测试不充分的情况。

权利要求

1.一种基于微服务的加解密方法，其特征在于，应用于API网关，包括：接收终端发送的请求报文；

根据所述请求报文的请求头，判断所述请求报文是否需要进行解密；

若确定需要解密处理，则根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密；

其中，所述接收终端发送的请求报文之前，还包括：

遍历终端的页面中包括的每个接口对应的请求信息和响应信息；判断遍历到的当前接口对应的请求信息和/或响应信息中是否包含需要加密的敏感信息；如果是，则在API网关的配置文件中存储当前接口的接口路径；在所述API网关中设定所述接口路径与目标属性的对应关系，所述目标属性用于指示加解密的对象是请求报文和/或响应报文；在判断请求报文是否需要进行加解密处理时进行接口路径和目标属性的双重判断。

2.根据权利要求1所述的方法，其特征在于，所述根据所述请求报文的请求头，判断所述请求报文是否需要进行解密，包括：从所述请求报文的请求头中提取接口路径；确定预先设定的需要加解密处理的接口路径中是否包括提取的所述接口路径；如果是，则确定所述请求报文需要进行解密；或者，如果确定预先设定的需要加解密处理的接口路径中包括提取的所述接口路径，则确定所述接口路径对应的目标属性是否指示请求报文需要加解密；如果是，则确定所述请求报文需要进行解密；或者，检测所述请求报文的请求头中是否包含预设标识符；如果是，则确定所述请求报文需要进行解密。

3.根据权利要求1所述的方法，其特征在于，所述预设密钥为预设的非对称加密的私钥，根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密，包括：从所述请求报文的请求头中提取密钥密文；

从所述API网关的配置文件中获取预先存储的所述私钥，采用所述私钥对所述密钥密文解密，得到对称密钥；

从所述请求报文中获取请求体密文；

采用所述对称密钥对所述请求体密文解密，得到解密后的请求体；

根据所述请求报文的请求头和所述解密后的请求体，生成新的请求报文。

4.据权利要求1所述的方法，其特征在于，所述预设密钥为预设的对称密钥，根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密，包括：从所述请求报文中获取请求体密文；

从所述API网关的配置文件中获取预先存储的所述对称密钥，采用所述对称密钥对所述请求体密文解密，得到解密后的请求体；

根据所述请求报文的请求头和所述解密后的请求体，生成新的请求报文。

5.根据权利要求1所述的方法，其特征在于，所述接收终端发送的请求报文之前，还包括：接收终端发送的密钥获取请求，所述密钥获取请求包括报文标识符；

通过预设非对称加密算法生成公钥和私钥；

发送所述公钥给所述终端，以使所述终端通过所述公钥加密所述报文标识符对应的请求报文；

存储所述报文标识符与所述私钥的对应关系。

6.根据权利要求5所述的方法，其特征在于，所述预设密钥包括预设的对称密钥及所述对应关系中存储的所述私钥，所述根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密，包括：根据所述请求报文中包括的报文标识符，从所述报文标识符与私钥的对应关系中获取对应的私钥；

从所述请求报文中获取请求体密文；

采用获取的所述私钥对所述请求体密文解密，得到解密后的请求体；

根据所述请求报文的请求头和所述解密后的请求体，生成新的请求报文。

7.根据权利要求3、4、6中任一项所述的方法，其特征在于，所述生成新的请求报文之后，还包括：将所述新的请求报文转发给对应的业务微服务；

接收所述业务微服务返回的所述请求报文对应的响应报文；

判断所述响应报文是否需要加密；

若确定需要加密，则采用所述对称密钥对所述响应报文进行加密处理。

8.一种API网关系统，其特征在于，所述API网关系统的配置文件中存储有预设密钥，所述API网关系统包括：收发模块，用于接收终端发送的请求报文；

判断模块，用于根据所述请求报文的请求头，判断所述请求报文是否需要进行解密；

加解密模块，用于若所述判断模块确定所述请求报文需要解密处理，则根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密；

其中，所述API网关系统执行所述收发模块的操作之前，还用于遍历终端的页面中包括的每个接口对应的请求信息和响应信息；判断遍历到的当前接口对应的请求信息和/或响应信息中是否包含需要加密的敏感信息；如果是，则在API网关的配置文件中存储当前接口的接口路径；在所述API网关中设定所述接口路径与目标属性的对应关系，所述目标属性用于指示加解密的对象是请求报文和/或响应报文；在判断请求报文是否需要进行加解密处理时进行接口路径和目标属性的双重判断。

9.一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行如权利要求1至7中任一项权利要求所述的基于微服务的加解密方法的步骤。

10.一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如权利要求1至7中任一项权利要求所述的基于微服务的加解密方法的步骤。

说明书

基于微服务的加解密方法、API网关系统及设备

技术领域

[0001] 本申请属于微服务技术领域，具体涉及一种基于微服务的加解密方法、API网关系统及设备。

背景技术

[0002] 微服务系统包括多个业务微服务和一个API(Application  Programming Interface，应用程序接口)网关，业务微服务负责处理终端的业务请求，API网关负责在终端与各个业务微服务之间进行数据转发。

[0003] 每个业务微服务与终端交互的过程中都可能会涉及账号、密码、身份证、联系电话等敏感信息。为了确保敏感信息在交互过程中的安全性，需要对敏感信息进行加密。相关技术中每个业务微服务都开发有各自的加解密功能，开发比较繁琐，与终端联调也会非常耗时，测试也需要对所有业务微服务逐个进行验证。当需要变更加密算法或者修改密钥时，需要修改每个业务微服务中的相关配置，出现遗漏或者测试不充分时，将会带来不必要的风险，影响开发进度。

发明内容

[0004] 本申请提出一种基于微服务的加解密方法、API网关系统及设备，由API网关与终端进行加解密交互，业务微服务不进行任何加解密操作，所以在各业务微服务系统开发时无需关注加解密功能的开发，提高了开发效率，测试简单，不需要对所有业务微服务逐个进行测试。当需要变更加密算法或者修改密钥时，只需要修改API网关和终端中的相关配置即可，不容易出现遗漏或者测试不充分的情况。

[0005] 本申请第一方面实施例提出了一种基于微服务的加解密方法，应用于API网关，包括：

[0006] 接收终端发送的请求报文；

[0007] 根据所述请求报文的请求头，判断所述请求报文是否需要进行解密；

[0008] 若确定需要解密处理，则根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密。

[0009] 在本申请的一些实施例中，所述根据所述请求报文的请求头，判断所述请求报文是否需要进行解密，包括：

[0010] 从所述请求报文的请求头中提取接口路径；确定预先设定的需要加解密处理的接口路径中是否包括提取的所述接口路径；如果是，则确定所述请求报文需要进行解密；或者，

[0011] 如果确定预先设定的需要加解密处理的接口路径中包括提取的所述接口路径，则确定所述接口路径对应的目标属性是否指示请求报文需要加解密；如果是，则确定所述请求报文需要进行解密；或者，

[0012] 检测所述请求报文的请求头中是否包含预设标识符；如果是，则确定所述请求报文需要进行解密。

[0013] 在本申请的一些实施例中，所述预设密钥为预设的非对称加密的私钥，根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密，包括：

[0014] 从所述请求报文的请求头中提取密钥密文；

[0015] 从所述API网关的配置文件中获取预先存储的所述私钥，采用所述私钥对所述密钥密文解密，得到对称密钥；

[0016] 从所述请求报文中获取请求体密文；

[0017] 采用所述对称密钥对所述请求体密文解密，得到解密后的请求体；

[0018] 根据所述请求报文的请求头和所述解密后的请求体，生成新的请求报文。

[0019] 在本申请的一些实施例中，所述预设密钥为预设的对称密钥，根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密，包括：

[0020] 从所述请求报文中获取请求体密文；

[0021] 从所述API网关的配置文件中获取预先存储的所述对称密钥，采用所述对称密钥对所述请求体密文解密，得到解密后的请求体；

[0022] 根据所述请求报文的请求头和所述解密后的请求体，生成新的请求报文。

[0023] 在本申请的一些实施例中，所述接收终端发送的请求报文之前，还包括：

[0024] 接收终端发送的密钥获取请求，所述密钥获取请求包括报文标识符；

[0025] 通过预设非对称加密算法生成公钥和私钥；

[0026] 发送所述公钥给所述终端，以使所述终端通过所述公钥加密所述报文标识符对应的请求报文；

[0027] 存储所述报文标识符与所述私钥的对应关系。

[0028] 在本申请的一些实施例中，所述预设密钥包括预设的对称密钥及所述对应关系中存储的所述私钥，所述根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密，包括：

[0029] 根据所述请求报文中包括的报文标识符，从所述报文标识符与私钥的对应关系中获取对应的私钥；

[0030] 从所述请求报文中获取请求体密文；

[0031] 采用获取的所述私钥对所述请求体密文解密，得到解密后的请求体；

[0032] 根据所述请求报文的请求头和所述解密后的请求体，生成新的请求报文。

[0033] 在本申请的一些实施例中，所述生成新的请求报文之后，还包括：

[0034] 将所述新的请求报文转发给对应的业务微服务；

[0035] 接收所述业务微服务返回的所述请求报文对应的响应报文；

[0036] 判断所述响应报文是否需要加密；

[0037] 若确定需要加密，则采用所述对称密钥对所述响应报文进行加密处理。

[0038] 本申请第二方面的实施例提供了一种API网关系统，所述API网关系统的配置文件中存储有预设密钥，所述API网关系统包括：

[0039] 收发模块，用于接收终端发送的请求报文；

[0040] 判断模块，用于根据所述请求报文的请求头，判断所述请求报文是否需要进行解密；

[0041] 加解密模块，用于若所述判断模块确定所述请求报文需要解密处理，则根据所述API网关的配置文件中存储的预设密钥，对所述请求报文进行解密。

[0042] 本申请第三方面的实施例提供了一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行上述第一方面所述的基于微服务的加解密方法的步骤。

[0043] 本申请第四方面的实施例提供了一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述第一方面所述的基于微服务的加解密方法的步骤。

[0044] 本申请实施例中提供的技术方案，至少具有如下技术效果或优点：

[0045] 本申请实施例由API网关与终端进行加解密交互，业务微服务不进行任何加解密操作，所以在各业务微服务系统开发时无需关注加解密功能的开发，提高了开发效率，测试简单，不需要对所有业务微服务逐个进行测试。当需要变更加密算法或者修改密钥时，只需要修改API网关和终端中的相关配置即可，不容易出现遗漏或者测试不充分的情况。

[0046] 本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变的明显，或通过本申请的实践了解到。

附图说明

[0047] 通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

[0048] 图1示出了本申请一实施例所提供的微服务系统的架构示意图；

[0049] 图2示出了本申请一实施例所提供的一种基于微服务的加解密方法的流程示意图；

[0050] 图3示出了本申请一实施例所提供的一种API网关系统的结构示意图；

[0051] 图4示出了本申请一实施例所提供的一种计算机设备的结构示意图；

[0052] 图5示出了本申请一实施例所提供的一种存储介质的示意图。

具体实施方式

[0053] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

[0054] 可以理解，本申请所使用的术语“第一”、“第二”等可在本文中用于描述各种元件，但这些元件不受这些术语限制。这些术语仅用于将第一个元件与另一个元件区分。

[0055] 图1为一个实施例中提供的基于微服务的加解密方法的实施环境图，其实施环境为微服务系统，如图1所示，在微服务系统的架构中，包括终端110以及服务器120。其中，服务器120中包括API网关和多个业务微服务，API网关和业务微服务均为独立运行于服务器120中的应用程序，API网关分别与终端110及各个业务微服务连接，图1中仅示意性地画出了三个业务微服务，实际应用中可根据业务需求来设置业务微服务，本申请实施例并不限定业务微服务的数量。

[0056] 需要说明的是，服务器120以及终端110可为智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此。终端110与API网关可以通过无线方式或有线方式通信连接，本申请在此不做限制。

[0057] 本申请的一些实施例提供了一种基于微服务的加解密方法，该方法在API网关的配置文件中存储了密钥以及加密算法，由API网关负责所有加解密操作，各业务微服务不再进行任何加解密的相关工作，因此在各业务微服务系统开发时无需进行加解密功能的开发，提高了开发效率。

[0058] 在通过本申请实施例提供的方法进行在加解密之前，首先需要对API网关进行加解密的相关配置。首先在API网关和终端中配置需要加解密的接口，该接口可以为终端显示给用户的页面中提供给用户的按键或链接等，如登录按钮、注册按键等。

[0059] 在应用程序的开发过程中设定了页面中每个接口对应的请求内容和响应内容，接口对应的请求内容为用户点击接口后终端发送的请求报文中需要携带的内容，接口对应的响应内容即为用户点击接口后需要展示给用户看的内容。在API网关中配置需要进行加解密的接口时，首先遍历终端的页面中包括的每个接口对应的请求信息和响应信息，判断遍历到的当前接口对应的请求信息和/或响应信息中是否包含需要加密的敏感信息(如账号密码、身份证等)，如果是，则确定该当前接口为需要进行加解密的接口，在API网关的配置文件中存储当前接口的接口路径(如api/auth‑service/login)。按照上述方式将所有包含敏感信息的请求信息和/或响应信息对应的接口路径存储在API网关的配置文件中。API网关自动确定哪些接口是需要进行加解密处理的，自动完成需要加解密的接口路径的配置，提高了加解密功能的配置效率。

[0060] 在本申请的另一些实施例中，还可以由技术人员根据每个接口对应的请求信息和/或响应信息来确定需要进行加解密的接口，并将这些接口的接口路径存储到API网关的配置文件中。

[0061] 在API网关的配置文件中设定需要加解密的接口对应的接口路径，后续API网关只需根据请求报文和/或响应报文中的接口路径来判断是否需要进行加解密即可。如此在开发时只需要在设定的接口路径对应的接口程序中设置加解密程序，其他接口中无需做加解密的相关开发，提高了开发效率。

[0062] 在本申请的另一些实施例中，还可以在API网关和终端中设定需要加解密的接口路径与目标属性的对应关系，目标属性用于指示加解密的对象是请求报文，还是响应报文，还是请求报文和响应报文都需要加密。例如，目标属性可以包括request和response，用request表示请求报文，response表示响应报文。若request＝1，response＝0，表示请求报文需要加密，响应报文不需要加密。若request＝0，response＝1，则表示请求报文不需要加密，响应报文需要加密。若request＝1，response＝1，则表示请求报文和响应报文均需要加密。通过目标属性来指示请求报文和/或响应报文需要加密，在判断请求报文是否需要进行加解密处理时进行接口路径和目标属性的双重判断，能够实现请求报文和响应报文是否需要进行加密的多种情况的组合，使得方案更加灵活多样，更符合实际应用场景。

[0063] 在本申请的另一些实施例中，也可以不在API网关中设定接口路径。而是在开发阶段在终端与API网关之间约定好预设标识符，预设标识符可以为secret、password等。终端中预先设定好需要进行加密的接口。当用户点击这些接口触发请求报文时，终端在这些请求报文的请求头中添加预设标识符，并对请求体进行加密。API网关接收到请求报文后，根据请求报文中是否包含预设标识符来确定该请求报文是否需要进行解密操作。

[0064] 如此只需要在终端中配置需要加解密的接口，由终端在需要加解密的接口触发的请求报文中添加预设标识符。而API网关中无需配置太多，只要判断请求报文中是否包含预设标识符即可，简化了API网关的配置过程。

[0065] 本申请实施例还需要在终端和API网关的配置文件中进行密钥和加密算法的配置，本申请实施例可以采用以下第一、第二和第三任意一种的加解密方式，每种加解密方式对应的密钥和加密算法的配置情况不同，下面分别进行说明。

[0066] 第一、采用对称加密和非对称加密相结合的方式。

[0067] 采用预设非对称加密算法生成一个密钥对，包括公钥和私钥。通过预设对称加密算法生成一个对称密钥。将预设对称加密算法、该对称密钥、该公钥和该预设非对称加密算法存储在终端上，将预设对称加密算法、私钥和该预设非对称加密算法存储在API网关的配置文件中。其中，预设非对称加密算法可以为RSA(RSA algorithm)、DSA(Digital Signature Algorithm，数字签名算法)、ECC(Elliptic curve cryptography，椭圆加密算法)等，预设对称加密算法可以为DES(Data Encryption Standard，数据加密标准)、3DES(Triple Data Encryption Algorithm，三重数据加密算法)、AES(Advanced Encryption Standard，高级加密标准)等。

[0068] 第二，采用对称加密方式。

[0069] 通过预设对称加密算法生成一个对称密钥，在终端及API网关的配置文件中均存储该预设对称加密算法和该对称密钥。

[0070] 第三、在需要进行加密操作时临时生成密钥的方式。

[0071] 在终端及API网关的配置文件中均存储预设非对称加密算法。在该种方式中，还可以通过预设对称加密算法生成一个对称密钥，在终端及API网关的配置文件中存储该预设对称加密算法和该对称密钥，用于对响应报文进行加解密。

[0072] 在上述三种方式中涉及到对称加密的，均可以通过预设对称加密算法生成随机字符串，将生成的随机字符串作为对称密钥。也可以在生成对称密钥时，先获取当前系统时间、当前页面的页面名称、URL等页面信息以及接口的接口标识等信息，对获取的这些信息进行哈希运算，得到一个字符串，将该字符串作为对称密钥。

[0073] 通过上述方式完成对API网关的加解密的相关配置之后，通过图2所示的操作过程进行在线加解密操作，具体包括以下步骤：

[0074] 步骤101：接收终端发送的请求报文。

[0075] 当用户点击终端显示的页面中的某个接口时，终端获取该接口对应的接口路径，将该接口路径与预先设定的需要加解密的接口路径进行比较。若设定的接口路径中包括用户点击的该接口对应的接口路径，则确定该接口对应的请求报文需要进行加密操作。

[0076] 终端生成该接口对应的请求报文，并对该请求报文进行加密处理。若预先在终端与API网关之间约定采用上述第一种方式进行加解密处理，即采用对称加密和非对称加密相结合的方式。则终端通过预设的对称加密算法和对称密钥对该请求报文的请求体进行加密，得到请求体密文。然后通过预设的公钥和预设非对称加密算法对该对称密钥进行加密，得到密钥密文。将该密钥密文添加到该请求报文的请求头中，将添加了密钥密文的请求体和请求体密文组成新的请求报文。终端发送该新的请求报文给API网关。API网关接收终端发送的该请求报文。

[0077] 若预先在终端与API网关之间约定采用上述第二种方式进行加解密处理，即采用对称加密的方式。则终端通过预设的对称加密算法和对称密钥对该请求报文的请求体进行加密，得到请求体密文。将该请求报文的请求头和该请求体密文组成新的请求报文。终端发送该新的请求报文给API网关。API网关接收终端发送的该请求报文。

[0078] 若预先在终端与API网关之间约定采用上述第三种方式进行加解密处理，即在需要进行加密操作时临时生成密钥的方式。则终端检测到用户点击需要加解密处理的接口时，终端生成该接口对应的请求报文，然后发送密钥获取请求给API网关，该密钥获取请求中携带该请求报文的报文标识符，该报文标识符用于唯一标识该请求报文。API网关接收到该密钥获取请求之后，通过预设非对称加密算法临时生成一个密钥对，包括一个公钥和一个私钥。将该公钥返回给终端，并存储该私钥和报文标识符的对应关系。终端接收到API网关返回的公钥之后，通过该公钥加密该请求报文的请求体，得到请求体密文。将该请求报文的请求头和该请求体密文组成新的请求报文。终端发送该新的请求报文给API网关。API网关接收终端发送的该请求报文。

[0079] 每次终端发送需要加密的请求报文之前，API网关都临时生成非对称密钥对，通过临时生成的非对称密钥对进行加解密，进一步提高了数据安全性。

[0080] 终端通过上述第一、第二、第三任意一种方式对请求报文进行加密之后，该请求报文包括请求头和请求体，请求头中包括源地址和目的地址，源地址的URL(Uniform Resource Locator，统一资源定位器)中包括触发该请求报文的接口对应的接口路径。该请求报文的请求体中包括请求体密文。

[0081] 若终端确定出预先设定的接口路径中不包括用户点击的接口对应的接口路径，则确定该接口对应的请求报文不需要进行加密操作，则直接将该请求报文发送给API网关。

[0082] 步骤102：根据该请求报文的请求头，判断该请求报文是否需要进行解密。

[0083] API网关接收终端发送的该请求报文，从该请求报文的请求头中获取源地址，从源地址的URL中提取接口路径。确定配置文件中预先设定的需要加解密处理的接口路径中是否包括提取的接口路径。如果是，则确定该请求报文需要进行解密。

[0084] 若在配置需要加解密的接口路径时，还配置了每个接口路径对应的目标属性，则确定预先设定的需要加解密处理的接口路径中包括提取的接口路径时，进一步确定该接口路径对应的目标属性是否指示请求报文需要加解密。如果是，则确定该请求报文需要进行解密。

[0085] 在本申请的一些实施例中，API网关还可以检测该请求报文的请求头中是否包含预设标识符。如果是，则确定该请求报文需要进行解密。

[0086] 步骤103：若确定需要解密处理，则根据API网关的配置文件中存储的预设密钥，对请求报文进行解密。

[0087] 若步骤102中判断出该请求报文需要解密处理，则API网关根据配置文件中存储的预设密钥，按照与终端约定的加解密方式，对该请求报文进行解密。

[0088] 若预先在终端与API网关之间约定采用上述第一种方式进行加解密处理，即采用对称加密和非对称加密相结合的方式。则API网关的配置文件中存储的预设密钥为预设的非对称加密的私钥。API网关从该请求报文的请求头中提取密钥密文，从配置文件中获取预先存储的私钥，采用该私钥对密钥密文解密，得到对称密钥。从该请求报文中获取请求体密文，采用解密得到的对称密钥对该请求体密文解密，得到解密后的请求体。根据该请求报文的请求头和解密后的请求体，生成新的请求报文。

[0089] 由于密钥密文是经过非对称加密的，确保了对称密钥在传输过程中的安全性。通过预设的私钥对密钥密文解密才能得到对称密钥，通过对称密钥对请求体密文解密才能还原请求体，提高了请求体的安全性，且利用了对称密钥解密的速度快，效率高。该解密过程由API网关处理，后端的业务微服不再需要进行解密操作，因此业务微服开发时无需关注加解密功能的开发，提高了开发效率。

[0090] 若预先在终端与API网关之间约定采用上述第二种方式进行加解密处理，即采用对称加密的方式。则API网关的配置文件中存储的预设密钥为预设的对称密钥。API网关从该请求报文中获取请求体密文，从配置文件中获取预先存储的对称密钥，采用该对称密钥对该请求体密文解密，得到解密后的请求体。根据该请求报文的请求头和解密后的请求体，生成新的请求报文。

[0091] API网关通过预设的对称密钥对请求报文的请求体进行解密，后端的业务微服不再需要进行解密操作，因此业务微服开发时无需关注加解密功能的开发，提高了开发效率。

[0092] 若预先在终端与API网关之间约定采用第三种方式进行加解密处理，即在需要进行加密操作时临时生成密钥的方式。则在步骤101中终端发送该请求报文时API网关临时生成了一个公钥和一个私钥，终端采用该公钥对该请求报文的请求体进行了加密，而API网关的配置文件中存储了该请求报文的报文标识符与该私钥的对应关系。因此API网关接收到该请求报文后，从该请求报文中获取该请求报文的报文标识符，根据该请求报文中包括的报文标识符，从配置文件中存储的报文标识符与私钥的对应关系中获取对应的私钥。从该请求报文中获取请求体密文，采用获取的私钥对请求体密文解密，得到解密后的请求体。根据该请求报文的请求头和解密后的请求体，生成新的请求报文。

[0093] 每个需要加密的请求报文，都由API网关生成该请求报文对应的非对称加密的密钥对，该密钥对只用于该请求报文的加解密，提高了请求报文在传输过程中的数据安全性。

[0094] 通过上述任意方式对请求报文解密，并生成新的请求报文之后，API网关从新的请求报文的请求头中获取目的地址，根据该目的地址，将新的请求报文转发给对应的业务微服务。业务微服务接收到该请求报文之后，对该请求报文进行业务处理，生成该请求报文对应的响应报文，发送该响应报文给API网关。API网关接收业务微服务返回的该请求报文对应的响应报文，判断该响应报文是否需要加密。

[0095] 具体地，API网关从响应报文的响应头中提取接口路径；确定预先设定的需要加解密的接口路径中是否包括提取的接口路径；如果是，则确定响应报文需要加密。

[0096] 若在配置需要加解密的接口路径时，还配置了每个接口路径对应的目标属性，则确定预先设定的需要进行加解密处理的接口路径中包括提取的接口路径时，进一步确定该接口路径对应的目标属性是否指示响应报文需要加解密处理；如果是，则确定响应报文需要加密。

[0097] 通过设定接口路径的方式来判断响应报文是否需要加密处理，则只需要对设定的接口路径对应的接口进行加解密功能的开发，其他接口无需做加解密处理，提高了开发效率。

[0098] 在本申请的一些实施例中，API网关还可以检测响应报文的响应头中是否包含预设标识符；如果包含，则确定响应报文需要加密。通过在响应头中增加预设标识符的方式来判断响应报文是否需要加解密处理，API网关中无需配置太多，只要判断响应报文中是否包含预设标识符即可，简化了API网关的操作。

[0099] 在本申请实施例中，API网关接收到请求报文时，还可以创建一个线程，通过该线程处理该请求报文的加解密判断、解密处理、请求报文转发、响应报文接收及加密等操作，当处理该请求报文的线程接收到该请求报文对应的响应报文时，通过该线程确定该请求报文是否进行了解密处理，如果是，则确定该响应报文也需要进行加密处理。

[0100] 通过多线程并发处理请求报文，同一线程处理的请求报文及其对应的响应报文的加解密处理是相同的，若请求报文加密了，则响应报文也需要加密，否则都不加密。如此多线程并发，处理效率很高，而且对各请求报文的处理通过线程相互隔离。

[0101] 通过上述任意方式确定该响应报文不需要加密，则直接将该响应报文转发给终端。若确定该响应报文需要加密，则对该响应报文进行加密处理。由API网关对响应报文进行加密，后端的业务微服不再需要进行加密操作，因此业务微服开发时无需关注加解密功能的开发，提高了开发效率。

[0102] 若该响应报文对应的请求报文是采用上述第一种方式进行加解密的，则API网关在对该请求报文进行解密的过程中，通过配置文件中预存的私钥对请求报文的请求头中的密钥密文进行解密，获得了一个对称密钥。因此在对该请求报文对应的响应报文进行加密时，API网关使用该对称密钥对该响应报文进行加密。具体地，从响应报文中获取响应体；采用该对称密钥对响应体加密，得到响应体密文；根据响应报文的响应头和响应体密文，生成新的响应报文。API网关发送该新的响应报文给终端，终端接收到该响应报文之后，采用终端本地存储的预设对称加密算法和对称密钥对该响应报文进行解密。

[0103] 若该响应报文对应的请求报文是采用上述第二种方式进行加解密的，则API网关的配置文件中预存有一个对称密钥，则API网关从响应报文中获取响应体；采用配置文件中预存的该对称密钥对响应体加密，得到响应体密文；根据响应报文的响应头和响应体密文，生成新的响应报文。API网关发送该新的响应报文给终端，终端接收到该响应报文之后，采用终端本地存储的预设对称加密算法和对称密钥对该响应报文进行解密。

[0104] 若该响应报文对应的请求报文是采用上述第三种方式进行加解密的，则API网关的配置文件中也可以预存有一个对称密钥，则API网关按照上述方式采用该对称密钥对该响应报文进行加密，生成新的响应报文。API网关发送该新的响应报文给终端，终端接收到该响应报文之后，采用终端本地存储的预设对称加密算法和对称密钥对该响应报文进行解密。

[0105] 在采用第三种方式进行加解密的情况下，API网关的配置文件中也可以不预存对称密钥，而是也采用临时生成密钥的方式来对响应报文进行加密。具体地，API网关确定该响应报文需要加密时，发送密钥获取请求给终端，该密钥获取请求中携带该响应报文的报文标识符，该报文标识符用于唯一标识该响应报文，该报文标识符可以与该响应报文对应的请求报文的报文标识符相同。终端接收到该密钥获取请求之后，通过预设非对称加密算法临时生成一个密钥对，包括一个公钥和一个私钥，将该公钥发送给API网关，终端存储该私钥和报文标识符的对应关系。API网关接收到该公钥之后，通过该公钥加密该响应报文的响应体，得到响应体密文。将该响应报文的响应头和该响应体密文组成新的响应报文。

[0106] API网关发送该新的响应报文给终端，终端接收到该响应报文之后，从该响应报文中获取该响应报文的报文标识符，根据该响应报文中包括的报文标识符，从本地存储的报文标识符与私钥的对应关系中获取对应的私钥。从该响应报文中获取响应体密文，采用获取的私钥对响应体密文解密，得到解密后的响应体，完成对该响应报文的解密操作。

[0107] 本申请实施例由API网关与终端进行加解密交互，业务微服务不进行任何加解密操作，所以在各业务微服务系统开发时无需关注加解密功能的开发，提高了开发效率，测试简单，不需要对所有业务微服务逐个进行测试。当需要变更加密算法或者修改密钥时，只需要修改API网关和终端中的相关配置即可，不容易出现遗漏或者测试不充分的情况。

[0108] 如图3所示，本申请实施例提供了一种API网关系统，该API网关系统的配置文件中存储有预设密钥，该API网关系统包括：

[0109] 收发模块301，用于接收终端发送的请求报文；

[0110] 判断模块302，用于根据请求报文的请求头，判断请求报文是否需要进行解密；

[0111] 加解密模块303，用于若判断模块确定请求报文需要解密处理，则根据API网关的配置文件中存储的预设密钥，对请求报文进行解密。

[0112] 判断模块302，具体用于从请求报文的请求头中提取接口路径；确定预先设定的需要加解密处理的接口路径中是否包括提取的接口路径；如果是，则确定请求报文需要进行解密；或者，检测请求报文的请求头中是否包含预设标识符；如果是，则确定请求报文需要进行解密；或者，如果确定预先设定的需要加解密处理的接口路径中包括提取的接口路径，则确定接口路径对应的目标属性是否指示请求报文需要加解密；如果是，则确定请求报文需要进行解密。

[0113] 在本申请的一些实施例中，预设密钥为预设的非对称加密的私钥，加解密模块303，用于从请求报文的请求头中提取密钥密文；从API网关的配置文件中获取预先存储的私钥，采用私钥对密钥密文解密，得到对称密钥；从请求报文中获取请求体密文；采用对称密钥对请求体密文解密，得到解密后的请求体；根据请求报文的请求头和解密后的请求体，生成新的请求报文。

[0114] 在本申请的一些实施例中，预设密钥为预设的对称密钥，加解密模块303，用于从请求报文中获取请求体密文；从API网关的配置文件中获取预先存储的对称密钥，采用对称密钥对请求体密文解密，得到解密后的请求体；根据请求报文的请求头和解密后的请求体，生成新的请求报文。

[0115] 该装置还包括：密钥生成模块，用于接收终端发送的密钥获取请求，密钥获取请求包括报文标识符；通过预设非对称加密算法生成公钥和私钥；发送公钥给终端，以使终端通过公钥加密报文标识符对应的请求报文；存储报文标识符与私钥的对应关系。

[0116] 在本申请的一些实施例中，预设密钥包括预设的对称密钥及对应关系中存储的私钥，加解密模块303，用于根据请求报文中包括的报文标识符，从报文标识符与私钥的对应关系中获取对应的私钥；从请求报文中获取请求体密文；采用获取的私钥对请求体密文解密，得到解密后的请求体；根据请求报文的请求头和解密后的请求体，生成新的请求报文。

[0117] 该装置还包括：响应报文加密模块，用于将新的请求报文转发给对应的业务微服务；接收业务微服务返回的请求报文对应的响应报文；判断响应报文是否需要加密；若确定需要加密，则采用对称密钥对响应报文进行加密处理。

[0118] 响应报文加密模块，具体用于从响应报文的响应头中提取接口路径；确定预先设定的需要加解密的接口路径中是否包括提取的接口路径；如果是，则确定响应报文需要加密；或者，如果确定预先设定的需要进行加解密处理的接口路径中包括提取的接口路径，则确定接口路径对应的目标属性是否指示响应报文需要加解密处理；如果是，则确定响应报文需要加密；或者，检测响应报文的响应头中是否包含预设标识符；如果包含，则确定响应报文需要加密；或者，通过处理请求报文及响应报文的线程确定请求报文是否进行了解密处理，如果是，则确定响应报文需要进行加密处理。

[0119] 响应报文加密模块，具体用于从响应报文中获取响应体；采用对称密钥对响应体加密，得到响应体密文；根据响应报文的响应头和响应体密文，生成新的响应报文。

[0120] 本申请实施例由API网关与终端进行加解密交互，业务微服务不进行任何加解密操作，所以在各业务微服务系统开发时无需关注加解密功能的开发，提高了开发效率，测试简单，不需要对所有业务微服务逐个进行测试。当需要变更加密算法或者修改密钥时，只需要修改API网关和终端中的相关配置即可，不容易出现遗漏或者测试不充分的情况。

[0121] 本申请实施例提供了一种计算机设备，该计算机设备可以为配置有API网关和至少一个业务微服务的服务器。如图4所示，该计算机设备包括通过系统总线连接的处理器、非易失性存储介质、存储器和网络接口。其中，该计算机设备的非易失性存储介质存储有操作系统、数据库和计算机可读指令，数据库中可存储有控件信息序列，该计算机可读指令被处理器执行时，可使得处理器实现一种基于微服务的加解密方法。该计算机设备的处理器用于提供计算和控制能力，支撑整个计算机设备的运行。该计算机设备的存储器中可存储有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器执行一种基于微服务的加解密方法。该计算机设备的网络接口用于与终端连接通信。本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

[0122] 该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：接收终端发送的请求报文，判断请求报文对应的接口是否需要进行字典转换；接收终端发送的请求报文；根据请求报文的请求头，判断请求报文是否需要进行解密；若确定需要解密处理，则根据API网关的配置文件中存储的预设密钥，对请求报文进行解密。

[0123] 本申请实施例还提出了一种存储有计算机可读指令的存储介质，如图5所示，该计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：接收终端发送的请求报文；根据请求报文的请求头，判断请求报文是否需要进行解密；若确定需要解密处理，则根据API网关的配置文件中存储的预设密钥，对请求报文进行解密。

[0124] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read‑Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

[0125] 以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

[0126] 以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。