微服务系统访问控制方法、装置、设备和存储介质与流程

1.本发明涉及计算机技术领域，尤其涉及微服务系统访问控制方法、装置、设备和存储介质。


背景技术：

2.微服务架构是一种分布式框架，主要用于在云中部署应用和服务。微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署。不同的微服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。
3.相关技术中，如果一个用户业务需要多个微服务提供服务时，需要在不同微服务之间均进行各自的授权过程，否则无法完成对应业务。但是每个微服务之间的授权过程是独立的，如果一个用户业务需要较多微服务分别参与时，重复进行授权以及权限校验过程，容易导致业务超时。


技术实现要素：

4.本技术实施例的主要目的在于提出微服务系统访问控制方法、装置、设备和存储介质，降低不同微服务之间进行权限验证的复杂度，提升微服务系统访问效率。
5.为实现上述目的，本技术实施例的第一方面提出了一种微服务系统访问控制方法，所述微服务系统至少包括第一后端微服务和第二后端微服务，所述微服务系统被配置成不同的后端微服务均可根据请求实体的请求信息，生成可用于访问其他后端微服务的服务授权码；所述方法包括：第一后端微服务接收请求实体的第一业务请求信息；第一后端微服务响应所述第一业务请求信息，生成第一服务响应信息和服务授权码；其中，所述第一服务响应信息为第一后端微服务根据所述第一业务请求信息生成的；所述第一后端微服务用于生成至少一个第二后端微服务对所述请求实体的所述服务授权码；第一后端微服务将所述第一服务响应信息和所述服务授权码发送至所述请求实体；第二后端微服务接收所述请求实体基于所述服务授权码生成的第二业务请求信息；所述第二后端微服务对所述服务授权码进行权限校验；根据权限校验结果，所述第二后端微服务响应所述第二业务请求信息，生成第二服务响应信息。
6.在一实施例中，所述第一后端微服务响应所述第一业务请求信息，生成第一服务响应信息和服务授权码，包括：第一后端微服务响应所述第一业务请求信息，生成第一服务响应信息；利用权限控制模块根据所述第一业务请求信息生成所述服务授权码。
7.在一实施例中，所述第一业务请求信息包括访问令牌，所述利用权限控制模块根据所述第一业务请求信息生成所述服务授权码，包括：利用所述权限控制模块根据所述访问令牌判断是否进行授权；若判断结果是进行授权，则所述权限控制模块根据预设授权码格式生成所述服务授权码。
8.在一实施例中，所述第一业务请求信息还包括：请求用户信息、操作文件信息和文件权限信息；所述权限控制模块根据预设授权码格式生成所述服务授权码，包括：根据所述第一业务请求信息生成授权码参数，所述授权码参数包括：请求用户参数、操作文件参数和文件权限参数；基于所述预设授权码格式，生成所述授权码参数的所述服务授权码。
9.在一实施例中，所述操作文件信息包括：操作文档类名和操作文档编号；所述基于所述预设授权码格式，生成所述授权码参数的所述服务授权码，包括：根据操作文档类名和操作文档编号生成所述操作文件参数，所述操作文件参数包括：操作文档类参数和操作文档编号参数；将所述操作文件参数拼接在所述请求用户参数后，得到第一授权码信息；将所述文件权限参数拼接在所述第一授权码信息后，得到所述服务授权码。
10.在一实施例中，所述基于所述预设授权码格式，生成所述授权码参数的所述服务授权码之后，还包括：利用预设加密算法和预设密钥对所述服务授权码进行加密，得到加密后的所述服务授权码。
11.在一实施例中，所述请求用户信息为用户会话编号。
12.在一实施例中，所述服务授权码中包括至少一个所述文件权限参数，不同的所述文件权限参数利用预设分隔符进行分隔生成。
13.在一实施例中，所述第二后端微服务对所述服务授权码进行权限校验，包括：从所述第二业务请求信息中提取得到所述服务授权码，所述服务授权码位于所述第二业务请求信息的预设位置；获取所述服务授权码中的所述授权码参数；若所述授权码参数满足权限校验条件，则权限校验通过。
14.在一实施例中，所述若所述授权码参数满足权限校验条件，则权限校验通过，包括：根据所述请求用户参数判断当前用户是授权用户，则第一权限校验通过；根据所述操作文件参数判断请求操作的文件是授权文件，则第二权限校验通过；根据所述文件权限参数判断文件操作权限是授权接口，则第三权限校验通过；若第一权限校验通过、第二权限校验通过和第三权限校验通过，则权限校验通过。
15.在一实施例中，所述第二业务请求信息为http/https请求信息，所述服务授权码位于所述http/https请求信息的url信息、请求头部信息或请求体部信息中。
16.在一实施例中，所述将所述服务授权码发送至所述请求实体，包括：利用参数传递的方式将所述服务授权码发送至所述请求实体。
17.为实现上述目的，本技术实施例的第二方面提出了一种微服务系统访问控制装置，所述微服务系统至少包括第一后端微服务和第二后端微服务，所述微服务系统被配置
成不同的后端微服务均可根据请求实体的请求信息，生成可用于访问其他后端微服务的服务授权码；所述装置包括：第一请求接收模块，用于第一后端微服务接收请求实体的第一业务请求信息；第一请求响应模块，用于第一后端微服务响应所述第一业务请求信息，生成第一服务响应信息和服务授权码；其中，所述第一服务响应信息为第一后端微服务根据所述第一业务请求信息生成的；所述第一后端微服务用于生成至少一个第二后端微服务对所述请求实体的所述服务授权码；服务授权码发送模块，用于第一后端微服务将所述第一服务响应信息和所述服务授权码发送至所述请求实体；第二请求接收模块，用于第二后端微服务接收所述请求实体基于所述服务授权码生成的第二业务请求信息；权限验证模块，用于所述第二后端微服务对所述服务授权码进行权限校验；第二请求响应模块，用于根据权限校验结果，所述第二后端微服务响应所述第二业务请求信息，生成第二服务响应信息。
18.为实现上述目的，本技术实施例的第三方面提出了一种电子设备，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法。
19.为实现上述目的，本技术实施例的第四方面提出了一种存储介质，所述存储介质为计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法。
20.本技术实施例提出的微服务系统访问控制方法、装置、设备和存储介质，通过第一后端微服务接收请求实体的第一业务请求信息并响应第一业务请求信息，生成第一服务响应信息和服务授权码，然后将服务授权码发送至请求实体，第二后端微服务接收请求实体基于服务授权码生成的第二业务请求信息；利用第二后端微服务对服务授权码进行权限校验，若权限校验通过，则利用第二后端微服务响应第二业务请求信息，生成第二服务响应信息。本技术实施例利用第一后端微服务根据第一业务请求信息生成服务授权码，再需要进行后续操作时，将服务授权码与第二业务请求信息结合发送，使得第二后端微服务利用前述生成的服务授权码直接进行权限校验，避免同一业务需要多个微服务分别参与时，每个微服务均需要完成授权-发送-校验的整个授权过程，克服了访问容易超时的问题，降低不同微服务之间进行权限验证的复杂度，提升微服务系统访问效率。
附图说明
21.图1是本发明实施例提供的微服务系统结构示意图。
22.图2是本发明实施例提供的微服务系统访问控制方法的流程图。
23.图3是图2中的步骤s120的流程图。
24.图4是图3中的步骤s122的流程图。
25.图5是图4中的步骤s1222的流程图。
26.图6是图5中的步骤s1224的流程图。
27.图7是本发明实施例提供的微服务系统访问控制方法的加密过程示意图。
28.图8是本发明实施例提供的微服务系统访问控制方法的分组加密过程示意图。
29.图9是图2中的步骤s150的流程图。
30.图10是图9中的步骤s153的流程图。
31.图11是本发明又一实施例提供的微服务系统访问控制方法的流程图。
32.图12是本发明又一实施例提供的微服务系统访问控制方法的流程图。
33.图13是本发明又一实施例提供的微服务系统访问控制方法的流程图。
34.图14是本发明又一实施例提供的微服务系统访问控制装置结构框图。
35.图15是本发明实施例提供的电子设备的硬件结构示意图。
具体实施方式
36.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
37.需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。
38.除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本发明实施例的目的，不是旨在限制本发明。
39.微服务架构是一种分布式框架，主要用于在云中部署应用和服务。微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署。不同的微服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。
40.申请人发现，相关技术中，微服务架构下的每个服务都运行在一个独立的java虚拟机上，其数据库互相独立，业务互相独立，权限互相独立，除定义的接口外互相之间无依赖关系。而每个服务对外的数据接口是受到该服务的权限控制的，每个服务都有独立的鉴权机制，当前端需要访问某个接口时，当前用户必须具有该服务的权限，否则便没有访问权限。如果一个用户业务需要多个微服务分别提供服务时，此时不同的微服务之间相互独立完成服务过程，需要在不同微服务之间均进行各自的授权过程，否则无法完成对应业务。但是每个微服务之间的授权过程是独立的，如果一个用户业务需要较多微服务参与时，重复进行授权以及权限校验过程，容易导致业务超时。
41.基于此，本发明实施例提供一种微服务系统访问控制方法、装置、设备和存储介质，利用第一后端微服务根据第一业务请求信息生成服务授权码，再需要进行下一步操作时，将服务授权码与第二业务请求信息结合发送，使得第二后端微服务利用前述生成的服务授权码直接进行权限校验，避免同一业务需要多个微服务分别参与时，每个微服务均需要完成授权-发送-校验的整个授权过程，克服了访问容易超时的问题，降低不同微服务之间进行权限验证的复杂度，提升微服务系统访问效率。
42.本发明实施例提供微服务系统访问控制方法、装置、设备和存储介质，具体通过如下实施例进行说明，首先描述本发明实施例中的微服务系统访问控制方法。
43.为了便于理解本技术实施例，下面首先对本技术实施例中微服务系统进行描述。
44.参照图1，微服务系统100包括：多个微服务200（图中以3个微服务进行示例）。
45.在一实施例中，每一个微服务200中均设置有权限控制模块。在另一些实施例中，权限控制模块也可以独立设置，每一个微服务200均与权限控制模块连接，在此不对权限控制模块的具体位置做限定。其中，权限控制模块用于生成服务授权码并进行权限校验。
46.第一后端微服务和第二后端微服务都属于图1中多个微服务200，权限控制模块可以与第一后端微服务和第二后端微服务集成在一起，也可以是独立的模块，本实施例对此不做具体限定。
47.在一实施例中，请求实体10向微服务系统100发送业务请求，业务请求传输到提供业务服务的微服务200，微服务200利用权限控制模块对业务请求进行权限校验，如果权限校验通过，则提供业务服务的微服务200向请求实体提供服务，并返回业务数据。可以理解的是，请求实体可以是移动设备应用或者网络应用等。
48.在一实施例中，微服务系统100需要一个以上微服务200分别提供服务才能实现请求实体发送的业务请求，例如业务实现顺序是：微服务a-微服务b-微服务c，则微服务a首先响应业务请求，完成对应部分的内容，然后将响应数据传递给请求实体，然后请求实体再向微服务b请求服务，微服务b响应业务请求，完成对应部分的内容，然后将响应数据传递给请求实体，请求实体再向微服务c请求服务，微服务c响应业务请求，完成对应部分的内容，在这个过程中，每个微服务均需要利用权限控制模块完成权限校验过程。
49.下面描述本发明实施例中的微服务系统访问控制方法。
50.图2是本发明实施例提供的微服务系统访问控制方法的一个可选的流程图，图2中的方法可以包括但不限于包括步骤s110至步骤s170。同时可以理解的是，本实施例对图2中步骤s110至步骤s170的顺序不做具体限定，可以根据实际需求调整步骤顺序或者减少、增加某些步骤。
51.步骤s110：第一后端微服务接收请求实体的第一业务请求信息。
52.在一实施例中，微服务系统至少包括第一后端微服务和第二后端微服务，并且微服务系统被配置成不同的后端微服务均可根据请求实体的请求信息，生成可用于访问其他后端微服务的服务授权码。该实施例中，第一后端微服务为请求实体第一个发出请求的后端微服务，可以理解的是，本实施例的微服务系统中任一个后端微服务均可作为第一个后端微服务去接收请求实体发送的请求信息。也就是说，可以在微服务系统中预先约定规则：不同的后端微服务之间可以互相授权，某一后端微服务可以作为第一后端微服务接收第一业务请求信息，生成具有访问其他后端微服务的服务授权码。
53.在一实施例中，第一后端微服务生成的服务授权码可以是具有访问一个后端微服务的访问权限，也可以是具有访问多个不同后端微服务的访问权限。
54.在一实施例中，请求实体通过用户界面接收用户的操作信息，根据用户的操作信息生成第一业务请求信息。第一业务请求信息用于表征调用微服务系统完成对应的应用功能，其中包含完成对应功能的所有后端微服务。
55.步骤s120：第一后端微服务响应第一业务请求信息，生成第一服务响应信息和服务授权码。
56.在一实施例中，第一后端微服务用于生成至少一个第二后端微服务对请求实体的
服务授权码。参照图3，是一实施例示出的步骤s120的一种具体实现流程图，在本实施例中微服务响应第一业务请求信息，生成第一服务响应信息和服务授权码的步骤s120，包括：步骤s121：第一后端微服务响应第一业务请求信息，生成第一服务响应信息。
57.在一实施例中，第一业务请求信息中包含业务信息。微服务系统根据业务信息选择执行业务的一个以上微服务，并生成访问顺序。根据访问顺序将访问令牌发送给第一个微服务，第一个微服务即第一后端微服务，第一后端微服务响应第一业务请求信息，生成对应的第一服务响应信息。
58.步骤s122：利用权限控制模块根据第一业务请求信息生成服务授权码。
59.在一实施例中，第一业务请求信息中还包括访问令牌，访问令牌表征请求实体的用户信息。第一后端微服务根据访问令牌向权限控制模块对请求实体的用户身份进行鉴权，生成服务授权码。
60.在一实施例中，参照图4，是一实施例示出的步骤s122的一种具体实现流程图，在本实施例中利用权限控制模块根据第一业务请求信息生成服务授权码的步骤s122，包括：步骤s1221：利用权限控制模块根据访问令牌判断是否进行授权。
61.步骤s1222：若判断结果是进行授权，则权限控制模块根据预设授权码格式生成服务授权码。
62.在一实施例中，访问令牌中包含应用编号，表示为app id，权限控制模块根据应用编号判断发送第一业务请求信息的请求实体是否是授权的请求实体，即该微服务系统能不能实现该应用的业务请求。如果判断结果是进行授权，则对该请求实体的本次业务请求进行授权。
63.在一实施例中，当权限控制模块判断需要对该请求实体进行授权时，则权限控制模块根据预设授权码格式生成服务授权码。
64.在一实施例中，第一业务请求信息的业务信息还包括：请求用户信息、操作文件信息和文件权限信息。
65.其中，请求用户信息为该请求实体请求业务的应用的会话编号。由于http是一种无状态协议，当请求实体向微服务系统发送业务请求时，微服务系统并不知道这是请求实体的第1个还是第n个请求，因此，本实施例通过会话编号进行请求信息关联，会话编号能够作为唯一的用户标识符。例如在如spring等框架或在tomcat等容器下，会话编号都可用于表示不同业务请求对应同一用户的唯一标识信息。
66.在一实施例中，操作文件信息包括：操作文档类名和操作文档编号，即该实施例中，请求实体发送的业务请求与文件操作相关。操作文件信息用于表征本次请求对应服务时所请求数据对应的文档名称，结合“操作文档编号”表示进行权限校验时，权限授予的数据项内容。例如需要下载配置文件1，则操作文档类名可以是：配置文件，操作文档编号可以是：“1”。
67.在一实施例中，文件权限信息表示授权本用户对上述配置文件1进行操作的权限。例如，文件权限信息包括：编辑权限、查看权限或删除权限等，权限可以根据实际需求选取，本实施例对此不进行限定。可以理解的是，文件权限信息表征请求实体不仅可以访问后端微服务中的文件，也可对其进行编辑、删除等操作过程。
68.在一实施例中，参照图5，是一实施例示出的步骤s1222的一种具体实现流程图，在
本实施例中权限控制模块根据预设授权码格式生成服务授权码的步骤s1222，包括：步骤s1223，根据第一业务请求信息生成授权码参数。
69.步骤s1224，基于预设授权码格式，生成授权码参数的服务授权码。
70.在一实施例中，对应于第一业务请求信息的请求用户信息、操作文件信息和文件权限信息，相应的授权码参数包括：请求用户参数（表示为sessionid）、操作文件参数和文件权限参数（表示为文件权限）。可以理解的是，授权码参数是将请求用户信息、操作文件信息和文件权限信息进行参数化，是一种格式转换，将请求用户信息、操作文件信息和文件权限信息转化成系统能够操作的字符格式。
71.在一实施例中，参照图6，是一实施例示出的步骤s1224的一种具体实现流程图，在本实施例中基于预设授权码格式，生成授权码参数的服务授权码的步骤s1224，包括：步骤s1225：根据操作文档类名和操作文档编号生成操作文件参数。
72.在一实施例中，由于操作文件信息包括：操作文档类名和操作文档编号，因此操作文件参数包括：操作文档类参数（表示为文档类名）和操作文档编号参数（表示为文档id）。
73.步骤s1226：将操作文件参数拼接在请求用户参数后，得到第一授权码信息。
74.步骤s1227：将文件权限参数拼接在第一授权码信息后，得到服务授权码。
75.在一实施例中，服务授权码的预设授权码格式为：“请求用户参数；操作文档类参数#操作文档编号参数；文件权限参数”，表示为：“sessionid;文档类名#文档id;文件权限”。
76.在一实施例中，服务授权码中包括至少一个文件权限参数，即该用户请求的服务中包括对文件操作的多种权限，例如既可以编辑也可以删除，因此不同的文件权限参数利用预设分隔符进行分隔。预设分隔符可以是：“/
”“‑”“
&”等符号，只要能够区分不同文件权限参数即可。
77.由上述可知，本技术实施例按照预设授权码的格式，将请求用户参数、操作文件参数和文件权限参数进行排列。
78.在一实施例中，出于安全考虑，将上述得到的服务授权码进行加密操作，例如，利用预设加密算法和预设密钥对服务授权码进行加密，得到加密后的服务授权码。
79.可以理解的是，本技术实施例为了避免生成的密文服务授权码字符串的长度较长，且会随着权限的数量增长而增长的问题，可以选择性地对授权码参数进行加密。
80.在一实施例中，预设加密算法为aes加密算法。aes加密算法又称高级加密标准（advanced encryption standard，aes），属于对称加密算法，对称加密算法的含义是加密过程和解密过程使用相同的预设密钥。具体地，本实施例使用aes加密算法的ecb加密模式，这种模式是将整个明文分成若干段相同的小段，然后对每一小段进行加密。
81.参照图7，为本技术实施例的加密过程示意图。
82.加密方（例如权限控制模块）利用aes加密函数和预设密钥k对明文服务授权码p进行加密，得到加密后的密文服务授权码c。如果后续解密方（例如某微服务）需要对密文服务授权码c进行解密时，利用aes解密函数和与加密过程相同的预设密钥k对密文服务授权码c进行解密，得到明文服务授权码p。进一步地，根据预设授权码的格式，从明文服务授权码中获取请求用户参数、操作文件参数和文件权限参数。
83.在一实施例中，对服务授权码进行加密采用分组加密的过程。参照图8，分组加密
的过程首先将明文服务授权码p按照预设分割长度划分成多个独立的明文块pi，然后将每个明文块pi利用aes加密函数和预设密钥k进行加密，生成对应的密文块ci，将所有的密文块ci按照分割顺序拼接在一起就得到密文服务授权码c。其中，预设分割长度可以是128bit。
84.在一实施例中，如果明文服务授权码p按照预设分割长度分割后，得到的某个明文块的长度小于预设分割长度，则对该明文块进行填充。例如明文服务授权码p的长度是192bit，预设分割长度是128bit，如果按每128bit一个明文块来拆分的话，第二个明文块只有64bit，不足128bit，因此需要在第二个明文块中进行填充。本实施例的填充方式为pkcs5，这种填充方式是：如果明文块缺少的的字节数小于16个字节（128bit），则在明文块末尾补足相应数量的字符，且每个字节的值等于缺少的字符数。可以理解的是，解密时需要根据加密过程使用的填充方式进行解密。
85.可以理解的是，本技术实施例的加密密钥可以自由定义或者放在配置文件中获取。
86.由上述可知，本技术实施例按照预设授权码的格式，将请求用户参数、操作文件参数和文件权限参数进行排列得到明文服务授权码，然后按照预设的加密方式和预设密钥生成加密服务授权码。
87.步骤s130：将第一服务响应信息和服务授权码发送至请求实体。
88.在一实施例中，微服务系统调用第一后端微服务响应第一业务请求信息，生成对应的第一服务响应信息。将第一服务响应信息和服务授权码同时发送至请求实体。
89.在一实施例中，微服务系统的第一后端微服务利用参数传递的方式将服务授权码发送至请求实体，即将服务授权码转化成url参数的形式发送至请求实体。
90.步骤s140：第二后端微服务接收请求实体基于服务授权码生成的第二业务请求信息。
91.在一实施例中，请求实体在接收到服务授权码和第一服务响应信息后，生成第二业务请求信息，其中第二业务请求信息是基于第一服务响应信息生成，并且包含服务授权码。
92.步骤s150：利用第二后端微服务对服务授权码进行权限校验。
93.在一实施例中，微服务系统根据第二业务请求信息选取执行该业务请求的微服务，作为第二后端微服务，第二后端微服务在执行第二业务请求信息之前，需要进行权限校验，以保证安全性。
94.在一实施例中，参照图9，是一实施例示出的步骤s150的一种具体实现流程图，在本实施例中利用第二后端微服务对服务授权码进行权限校验的步骤s150，包括：步骤s151：从第二业务请求信息中提取得到服务授权码，服务授权码位于第二业务请求信息的预设位置。
95.在一实施例中，第二业务请求信息为第二业务请求信息为http/https请求信息，服务授权码位于第二业务请求信息中。例如可以位于http/https请求信息的url信息中、请求头部信息中或请求体部信息中，在此不对服务授权码的位置做限定。
96.步骤s152：获取服务授权码中的授权码参数。
97.在一实施例中，上述得到服务授权码之后，根据预设授权码格式，从服务授权码中
得到：请求用户参数、操作文件参数和文件权限参数，其中操作文件参数包括：操作文档类参数和操作文档编号参数。
98.步骤s153：若授权码参数满足权限校验条件，则权限校验通过。
99.在一实施例中，参照图10，是一实施例示出的步骤s153的一种具体实现流程图，在本实施例中利用第二后端微服务对服务授权码进行权限校验的步骤s153，包括：步骤s1531：根据请求用户参数判断当前用户是授权用户，则第一权限校验通过。
100.在一实施例中，首先要判断用户身份，即根据请求用户参数判断当前用户是否是授权用户，如果是授权用户，则第一权限校验通过。
101.步骤s1532：根据操作文件参数判断请求操作的文件是授权文件，则第二权限校验通过。
102.在一实施例中，在用户身份合法的前提下，根据操作文件参数判断请求操作的文件是否是授权文件，即不能操作权限以外的文件，如果是授权文件，则第二权限校验通过。
103.步骤s1533：根据文件权限参数判断文件操作权限是授权接口，则第三权限校验通过。
104.在一实施例中，与文件操作的多种权限对应，授权接口包括：查看接口、编辑接口或删除接口等。在请求授权文件的前提下，根据文件权限参数判断文件操作权限是否是授权接口，如果操作权限范围接口相符，则第三权限校验通过。
105.步骤s1534：若第一权限校验通过、第二权限校验通过和第三权限校验通过，则权限校验通过。
106.由上述可知，只有第一权限校验通过、第二权限校验通过和第三权限校验通过，这三种权限校验均通过，权限校验才通过。
107.步骤s160：根据权限校验结果，第二后端微服务响应第二业务请求信息，生成第二服务响应信息。
108.在一实施例中，如果权限校验通过，则微服务系统利用第二后端微服务响应第二业务请求信息，生成第二服务响应信息。
109.由上述可知，本技术实施例利用第一后端微服务根据第一业务请求信息生成服务授权码，再需要进行下一步操作时，将服务授权码与第二业务请求信息结合发送，使得第二后端微服务利用前述生成的服务授权码直接进行权限校验，避免同一业务需要多个微服务分别参与时，每个微服务均需要完成授权-发送-校验的整个授权过程，克服了访问容易超时的问题，降低不同微服务之间进行权限验证的复杂度，提升微服务系统访问效率。
110.本技术实施例的服务授权码无需进行存储，避免在授权与鉴权过程进行远程访问或数据存储，导致容易超时的问题。并且同一文档的不同权限授权中均可追加或者叠加该服务授权码，即在单次请求的任意代码位置进行解密后的权限追加，扩展文件授权的使用场景。同时本技术实施例的服务授权码通过前端传输，在请求其它微服务的服务时出示该授权码，其它微服务使用相同加密密钥进行解码后，即可校验其中的各项授权码参数信息，判断授权用户与当前用户是否匹配，授权的文档是否为本次请求的文档，授权的权限是否符合本次请求的接口权限，提升任务处理效率。进一步地，由于请求用户信息为该请求实体请求业务的应用的会话编号，当用户退出登录或本次会话超时后，此服务授权码也自动失效，提升服务授权码的安全性。并且加密的内容可根据实际需求灵活调节，比如无需区分授
权的权限时，则不需要权限的部分。
111.下面通过具体实施例描述本技术实施例的微服务系统访问控制方法具体流程。
112.该实施例中，微服务系统需要2微服务才能实现请求实体发送的业务请求，业务实现顺序是：微服务a（第一后端微服务）-微服务b（第一后端微服务），微服务a-微服务b之间可以不存在关联性，互相独立完成服务过程。则微服务a首先响应业务请求，完成对应部分的内容，然后将响应数据和授权码传递给微服务b，微服务b响应业务请求，完成对应部分的内容，在这个过程中，每个微服务均需要利用权限控制模块完成权限校验过程。
113.参照图11，为本技术实施例中微服务系统访问控制方法的第一后端微服务处理流程示意图。
114.由于请求实体的第一业务请求信息需要第一后端微服务进行处理，因此步骤s1110从请求实体的用户界面获取第一业务请求信息，第一业务请求信息包含业务信息，微服务系统根据业务信息选择执行业务的第一后端微服务，因此将第一业务请求信息的主入口连接第一后端微服务。
115.该实施例中，第一业务请求信息中还包括访问令牌，访问令牌表征请求实体的用户信息。步骤s1120第一后端微服务根据访问令牌向权限控制模块对请求实体的用户身份进行鉴权，步骤s1130利用权限控制模块根据访问令牌判断是否进行授权，若判断结果为是，步骤s1140则进行授权，权限控制模块根据预设授权码格式生成服务授权码；否则步骤s150拒绝授权，并返回本次授权请求的结果至第一后端微服务。
116.该实施例中，步骤s1140进行授权，权限控制模块根据预设授权码格式生成服务授权码的过程具体是：第一业务请求信息的业务信息还包括：请求用户信息、操作文件信息和文件权限信息，对应于第一业务请求信息得到相应的授权码参数包括：请求用户参数（表示为sessionid）、操作文件参数和文件权限参数（表示为文件权限），由于操作文件信息包括：操作文档类名和操作文档编号，因此操作文件参数包括：操作文档类参数（表示为文档类名）和操作文档编号参数（表示为文档id）。授权码参数是将请求用户信息、操作文件信息和文件权限信息进行参数化。
117.服务授权码的预设授权码格式为：“请求用户参数；操作文档类参数#操作文档编号参数；文件权限参数”，表示为：“sessionid;文档类名#文档id;文件权限”。
118.该实施例中，服务授权码的加解密算法为aes加密算法，工作模式：ecb加密模式，填充方式：pkcs5，并对加密后的密文服务授权码进行转化，转化方式为：base64.encodebase64urlsafestring转换，转换的目的是将密文服务授权码转化为url参数形式，后续处理过程中无需进行转码。
119.由上述得到第一后端微服务根据第一业务请求信息生成的第一服务响应信息和服务授权码，将第一服务响应信息和服务授权码发送至请求实体，得到请求实体生成的第二业务请求信息。
120.参照图12，为本技术实施例中微服务系统访问控制方法的第二后端微服务处理流程示意图。
121.由于请求实体的第二业务请求信息需要第二后端微服务（与第一后端微服务不同）进行处理。步骤s1210从请求实体的用户界面获取第二业务请求信息，第二业务请求信
息是基于第一服务响应信息生成，并且包含服务授权码。步骤s1220中第二后端微服务对服务授权码进行权限校验，若权限校验通过，步骤s1230利用第二后端微服务响应第二业务请求信息，步骤s1240返回生成的第二服务响应信息，如果权限校验未通过，则第二服务响应信息为无权限。
122.该实施例中，步骤s1220第二后端微服务对服务授权码进行权限校验的过程为：从第二业务请求信息进行提取得到服务授权码，然后利用与加密方式相同的解密方式获取服务授权码中的授权码参数，若授权码参数满足权限校验条件，则权限校验通过。
123.校验过程为：首先根据请求用户参数（“sessionid”）判断当前用户是授权用户，则第一权限校验通过；然后根据操作文件参数（“文档id”和“文档类名”）判断请求操作的文件是授权文件，则第二权限校验通过；在根据文件权限参数（“文档权限”）判断文件操作权限是授权接口，则第三权限校验通过，若第一权限校验通过、第二权限校验通过和第三权限校验通过，则权限校验通过。由上述可知，只有第一权限校验通过、第二权限校验通过和第三权限校验通过，这三种权限校验均通过，权限校验才通过。权限校验通过即可该“文档id”和“文档类名”进行数据的处理，例如查询。
124.参照图13，本技术又一实施例的微服务系统访问控制方法具体流程。
125.图中包括请求实体、第一后端微服务和第二后端微服务，其中请求实体即业务模块前端，第一后端微服务即业务模块后端，第二后端微服务即附件后端服务。
126.其中，第一后端微服务和第二后端微服务中均集成权限控制模块，因此第一后端微服务包括业务执行模块和权限控制模块，分别执行业务操作和权限控制，同样地，第二后端微服务也包括业务执行模块和权限控制模块，分别执行业务操作和权限控制。
127.首先请求实体通过查看页（即用户界面）发送第一业务请求信息，调用第一后端微服务，将第一业务请求信息发送至第一后端微服务，第一后端微服务的业务处理模块根据第一业务请求信息申请权限控制模块对请求实体进行用户身份鉴权，权限控制模块根据访问令牌进行授权，授权成功，则生成服务授权码，返回至第一后端微服务，第一后端微服务将第一服务响应信息和服务授权码返回至请求实体。
128.然后请求实体基于第一服务响应信息生成第二业务请求信息，调用第二后端微服务的接口，将第二业务请求信息发送至第二后端微服务，第二业务请求信息中包含服务授权码。第二后端微服务的业务执行模块将服务授权码发送至权限控制模块，利用与加密方式相同的解密方式获取服务授权码中的授权码参数，若授权码参数满足权限校验条件，则权限校验通过。权限控制模块将权限校验通过的结果发送至第二后端微服务。第二后端微服务则根据第二业务请求信息生成第二服务响应信息，例如第二后端微服务可以为请求实体提供附件服务的微服务，对应地，第二服务响应信息可以是允许请求实体下载附件。
129.该实施例中，授权码参数表示为：请求用户参数（sessionid）：mguyota5nzmtytcyzc00zmmzltkzm2ytnwq0ywi3ndvlngu0；操作文档类参数（文档类名）：com.landray.sys.xform.core.entity.official.sysxformofficial；操作文档编号参数（文档id）：1g6v5lf07w572w4adw3p08js1slobm02ciw0；
文件权限参数（文件权限）：attachgetall；预设密钥为：{-122,47,-49,-55,-14,-99,-51,-69,-2,124,-80,45,27,76,-17,93}由上述参数根据预设授权码格式“sessionid;文档类名#文档id;文件权限”生成明文服务授权码，然后基于aes加密方式进行加密，利用上述预设密钥得到的密文服务授权码表示为：tpfproyglurxaden1chgxvcgqpw_yrbda6h9kdwzc0ldbagbeof5r0szxvwv4cjzaohi5nghdaaftrfdyzt1pq0yzatmi1wboj0rrgnp5msb2pejoeu0hsugamayweuve193gl7y-bmnw34vsbu0bmmw3hcjt3xbmg6psbbghyxia57duhnlzr7refsqmz5pfmyqxozrqjd-6lo6fz32ta由于附件下载请求协议为https，因此通过参数传递（mechauthtoken）的方式将上述生成的密文服务授权码传递给请求实体，请求实体基于第一服务响应信息生成的第二业务请求信息表示为：https://test.ywork.me/data/sys-attach/checkdownload/1g6v5l3tuw57lwg7dwfpspnbnlcpbp2bjiw0mechauthtoken=tpfproyglurxaden1chgxvcgqpw_yrbda6h9kdwzc0ldbagbeof5r0szxvwv4cjzaohi5nghdaaftrfdyzt1pq0yzatmi1wboj0rrgnp5msb2pejoeu0hsugamayweuve193gl7y-bmnw34vsbu0bmmw3hcjt3xbmg6psbbghyxia57duhnlzr7refsqmz5pfmyqxozrqjd-6lo6fz32ta由上述第二业务请求信息的“mechauthtoken”部分可知，第二业务请求信息中包含密文的服务授权码，服务授权码位于url信息中。
130.同时，上述第二业务请求信息的“x-auth-token”信息表示无状态下的用户身份信息，可以用于下一步校验授权码，其中：x-auth-token =1gf7sauasw89w4eqws9bjnp16h15ork0jbw0利用预设密钥和同样的解密算法对密文服务授权码进行解密，获取服务授权码中的授权码参数，若授权码参数满足权限校验条件，则权限校验。
131.其中请求用户参数（“sessionid”）与当前用户身份信息进行比较，当前用户身份信息即头部信息中携带的用户身份信息x-auth-token，将其与解密服务授权码得到的sessionid进行比较，判断当前用户是授权用户，则第一权限校验通过。然后根据操作文件参数（“文档id”和“文档类名”）判断请求操作的文件是否是第二后端微服务中存在的文件，如果是则第二权限校验通过。在根据文件权限参数（“文档权限”）判断文件操作权限是否与文件的权限一致，如果一致则第三权限校验通过，若第一权限校验通过、第二权限校验通过和第三权限校验通过，则权限校验通过，可以进行文档下载、查询、修改或者删除等操作。
132.可以理解的是，上述实施例以一个第二后端微服务进行说明，实际中如果第二后端微服务处理完成后，还需要调用独立的第三个后端微服务时，可以在会话时间内将第一后端微服务生成的服务授权码添加在第三个后端微服务的业务请求信息中即可，第三个后端微服务对服务授权码进行权限校验的方式与第二后端微服务相同，以此类推，可以用在多个后端微服务的独立处理流程中。
133.例如，当同一个用户界面中的内容由多个不同微服务分别独立提供时，本技术实施例的这种授权方式不需要两个服务间存在依赖关系，从性能上考虑，也要无需存储数据到数据库或是redis等数据存储服务中，也不需要互相调用接口，并且这种授权是临时的和
保密的，一段时间后会自动失效，以及用户将访问链接发送给另一个未得到授权的用户时，未授权用户依然不可访问。
134.本技术实施例提出的微服务系统访问控制方法，通过第一后端微服务接收请求实体的第一业务请求信息并响应第一业务请求信息，生成第一服务响应信息和服务授权码，然后将服务授权码发送至请求实体，第二后端微服务接收请求实体基于服务授权码生成的第二业务请求信息；利用第二后端微服务对服务授权码进行权限校验，若权限校验通过，则利用第二后端微服务响应第二业务请求信息，生成第二服务响应信息。
135.本技术实施例利用第一后端微服务根据第一业务请求信息生成服务授权码，再需要进行下一步操作时，将服务授权码与第二业务请求信息结合发送，使得第二后端微服务利用前述生成的服务授权码直接进行权限校验，避免同一业务需要多个微服务分别参与时，每个微服务均需要完成授权-发送-校验的整个授权过程，克服了访问容易超时的问题，降低不同微服务之间进行权限验证的复杂度，提升微服务系统访问效率。
136.本发明实施例还提供一种微服务系统访问控制装置，可以实现上述微服务系统访问控制方法，所述微服务系统至少包括第一后端微服务和第二后端微服务，所述微服务系统被配置成不同的后端微服务均可根据请求实体的请求信息，生成可用于访问其他后端微服务的服务授权码，参照图14，该装置包括：第一请求接收模块1410，用于第一后端微服务接收请求实体的第一业务请求信息。
137.第一请求响应模块1420，用于第一后端微服务响应所述第一业务请求信息，生成第一服务响应信息和服务授权码；其中，所述第一服务响应信息为第一后端微服务根据所述第一业务请求信息生成的；所述第一后端微服务用于生成至少一个第二后端微服务对所述请求实体的所述服务授权码。
138.服务授权码发送模块1430，用于第一后端微服务将所述第一服务响应信息和所述服务授权码发送至所述请求实体。
139.第二请求接收模块1440，用于第二后端微服务接收所述请求实体基于所述服务授权码生成的第二业务请求信息。
140.权限验证模块1450，用于所述第二后端微服务对所述服务授权码进行权限校验。
141.第二请求响应模块1460，用于根据权限校验结果，所述第二后端微服务响应所述第二业务请求信息，生成第二服务响应信息。
142.本实施例的微服务系统访问控制装置的具体实施方式与上述微服务系统访问控制方法的具体实施方式基本一致，在此不再赘述。
143.本发明实施例还提供了一种电子设备，包括：至少一个存储器；至少一个处理器；至少一个程序；所述程序被存储在存储器中，处理器执行所述至少一个程序以实现本发明实施上述的微服务系统访问控制方法。该电子设备可以为包括手机、平板电脑、个人数字助理（personal digital assistant，简称pda）、车载电脑等任意智能终端。
144.请参阅图15，图15示意了另一实施例的电子设备的硬件结构，电子设备包括：
处理器1501，可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本发明实施例所提供的技术方案；存储器1502，可以采用rom（readonlymemory，只读存储器）、静态存储设备、动态存储设备或者ram(randomaccessmemory，随机存取存储器)等形式实现。存储器1502可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1502中，并由处理器1501来调用执行本发明实施例的微服务系统访问控制方法；输入/输出接口1503，用于实现信息输入及输出；通信接口1504，用于实现本设备与其他设备的通信交互，可以通过有线方式（例如usb、网线等）实现通信，也可以通过无线方式（例如移动网络、wifi、蓝牙等）实现通信；和总线1505，在设备的各个组件（例如处理器1501、存储器1502、输入/输出接口1503和通信接口1504）之间传输信息；其中处理器1501、存储器1502、输入/输出接口1503和通信接口1504通过总线1505实现彼此之间在设备内部的通信连接。
145.本技术实施例还提供了一种存储介质，存储介质为计算机可读存储介质，该存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述微服务系统访问控制方法。
146.存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
147.本发明实施例提出的微服务系统访问控制方法、微服务系统访问控制装置、电子设备、存储介质，通过第一后端微服务接收请求实体的第一业务请求信息并响应第一业务请求信息，生成第一服务响应信息和服务授权码，然后将服务授权码发送至请求实体，第二后端微服务接收请求实体基于服务授权码生成的第二业务请求信息；利用第二后端微服务对服务授权码进行权限校验，若权限校验通过，则利用第二后端微服务响应第二业务请求信息，生成第二服务响应信息。本技术实施例利用第一后端微服务根据第一业务请求信息生成服务授权码，再需要进行下一步操作时，将服务授权码与第二业务请求信息结合发送，使得第二后端微服务利用前述生成的服务授权码直接进行权限校验，避免同一业务需要多个微服务分别参与时，每个微服务均需要完成授权-发送-校验的整个授权过程，克服了访问容易超时的问题，降低不同微服务之间进行权限验证的复杂度，提升微服务系统访问效率。
148.本技术实施例描述的实施例是为了更加清楚的说明本技术实施例的技术方案，并不构成对于本技术实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本技术实施例提供的技术方案对于类似的技术问题，同样适用。
149.本领域技术人员可以理解的是，图中示出的技术方案并不构成对本技术实施例的
限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。
150.以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
151.本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。
152.本技术的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
153.应当理解，在本技术中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：只存在a，只存在b以及同时存在a和b三种情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
154.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
155.上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
156.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
157.集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括多指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例的方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，简称rom)、随
机存取存储器(random access memory，简称ram)、磁碟或者光盘等各种可以存储程序的介质。
158.以上参照附图说明了本技术实施例的优选实施例，并非因此局限本技术实施例的权利范围。本领域技术人员不脱离本技术实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本技术实施例的权利范围之内。