一种规范化RESTful微服务交互方法与流程

本发明涉及微服务架构、服务交互规范技术，具体的说是一种规范化restful微服务交互方法。

背景技术

随着微服务、容器等新技术理念的涌现，轻量级的应用架构、前后台分离技术架构已经成为主流，以restful微服务架构能很好的支持多种形态的上层应用展示(web应用、手机app、ipad、微信等)，已经成为信息化建设中服务交互主要采用的技术实现。但restful软件架构风格，只是提供了一组设计原则和约束条件，不是实际的规范化标准，导致采用restfulapi+json服务交互在实际的应用实践中存在以下问题或弊病：

1、restful形式的微服务api对应uri定义没有统一的规范或语义，各应用子系统按照自己的理解去表述微服务的uri，导致uri定义和使用比较混乱，对于调用者容易产生歧义或二义性，同时，不容易微服务的统一治理；uri(uniformresourceidentifier)是统一资源标识符,用来唯一的标识一个资源；

2、在restful架构中，业界通常每个网址代表一种资源(resource)，对于资源的具体操作类型表述，一般由http动词(get、post、put、patch、delete)表示。此种表述适用于以数据资源目录形式的开放服务或者单一资源(单表)的操作表述，而稍微复杂的应用系统的业务操作表述，是微服务应用中最重要或最需要的表述部分，比如多种资源(多表)的关联操作表述、业务系统对应的统计分析表述没有相关的规定和指引；

3、在微服务的安全访问控制方面，业界通常以基于token的认证方式，有token即可访问，访问安全等级比较低，安全访问控制粒度比较粗，无法满足高安全等级、细粒度的安全访问控制需求。

技术实现要素：

本发明针对目前技术发展的需求和不足之处，提供一种一种规范化restful微服务交互方法。

本发明所述一种规范化restful微服务交互方法，解决上述技术问题采用的技术方案如下：所述一种规范化restful微服务交互方法，采用微服务规范化组件restfulapiuri规则配置器实现规范化restfulapiuri定义，采用微服务规范化组件资源操作表述规则配置器实现规范化资源操作表述，采用微服务规范化组件安全访问控制规则配置器实现规范化微服务安全访问控制；

通过规范化restfulapiuri定义，解决uri表述混乱的问题；通过规范化一套restful资源操作表述，满足实际应用场景中多种资源的关联操作表述；通过规范化微服务安全访问控制，解决微服务高安全等级、细粒度的访问控制问题；

规范化restfulapiuri定义：定义uri结构为“通信协议+部署域名+服务版本+资源路径+资源操作表述”五部分；

规范化资源操作表述：资源操作表述采用类数据访问层数据操作表述，资源操作类型包括：查询、新增、修改、删除；

规范化微服务安全访问控制：定义微服务的请求报文、响应报文规范。

具体的，所述通信协议：表示微服务api与用户的通信协议，使用https/http协议，根据具体微服务协议进行扩展；所述部署域名：应该微服务部署的专用域名；所述服务版本：微服务的版本采用v+数字的形式，支持微服务版本升级以及对外提供多版本服务；所述资源路径：具体资源路径表述，根据微服务应用约定的粒度进行分级路径表述；所述资源操作表述：用来对资源的具体操作类型表述。

具体的，所述操作类型查询，采用get表述根据主键字段进行查询；采用getall表述查询全部记录；采用queryby***表述条件查询****；采用count表述获取记录总数；采用exists表述是否存在记录；

所述操作类型新增，采用insert表述单条记录插入；采用batchinsert表述批量记录插入；

所述操作类型修改，采用update表述单条记录更新；采用batchupdate表述批量记录更新；采用updatesatus表述记录状态更新；

所述操作类型删除，采用delete表述单条记录删除；采用batchdelete表述批量记录删除。

具体的，对于条件查询queryby***操作类型表述，若查询实体为doc,queryby后剩下的属性含义解析方法如下：

第一步：先判断taskprojectname是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，继续第二步；

第二步：从右往左截取第一个大写字母开头的字符串此处为name，然后检查剩下的字符串是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，则重复第二步，继续从右往左截取；最后假设task为查询实体person的一个属性；

第三步：接着处理剩下部分projectname，先判断task所对应的类型是否有projectname属性，如果有，则表示该方法最终是根据“person.task.projectname”的取值进行查询；否则继续按照步骤2的规则从右往左截取，最终表示根据“person.task.project.name”的值进行查询。

具体的，所述服务请求报文包括三部分：请求基本信息、请求扩展信息、请求业务信息，其中服务请求基本信息在请求头基本信息节点内，请求扩展信息和请求业务信息在服务体节点内。

具体的，所述服务请求报文属性详细说明：

appkey：请求方系统代码key；

trantime：交易请求时间,格式yyyymmddhhmmss；

transeq：交易流水号；交易流水号的产生规则：发起请求方负责产生交易流水号，流水号的编码规则遵循统一的编码规范；采用32位的uuid；

signatureinfo：数据签名；

body：业务数据，请求信息、响应信息都在该参数下。

具体的，在数据签名时，服务请求方将token、trantime、transeq三个参数进行字典序排序拼接成一个字符串，利用sha1加密算法对该字符串进行加密生成数据签名证书；服务提供方接收到请求后再将token、timestamp、transeq三个参数进行字典序排序拼接成一个字符串并进行sha1加密，加密后的值与signatureinfo比对确保请求来自有效的业务系统。

具体的，所述服务响应报文包括四部分：响应基本信息、响应执行结果信息、响应扩展信息、响应业务信息，其中响应基本信息、响应执行结果信息在响应头基本信息节点内，响应扩展信息、响应业务信息在服务体节点内。

具体的，所述服务响应报文参数详细说明：

rtncode：返回代码大类，“0”代表成功；

code：返回代码小类；

message：返回信息。

本发明所述一种规范化restful微服务交互方法，与现有技术相比具有的有益效果是：本发明通过规范化restful微服务api的uri定义规则，解决uri表述混乱的问题；通过抛弃业界对资源操作通常采用的http动词形式表述，重新定义一套restful资源操作表述规范，解决http动词形式表述的不足，来满足实际应用场景中多种资源(多表)的关联操作表述；通过自描述的消息的定义规范，解决微服务高安全等级、细粒度的访问控制问题；

适用于各种以restful软件架构风格设计的应用系统，包括以restful风格的服务交互的微服务平台、saas云平台、前后台分离的应用系统；结合现有业界技术的发展趋势，通过标准化restful微服务交互规范，避免各微服务之间采用非标准化访问方式导致的各种弊病，使用微服务平台的服务交互更加的高效统一、合理规范，同时也有助于微服务平台的服务治理，提高微服务的治理效能。

附图说明

为了更清楚的说明本发明实施例或现有技术中的技术内容，下面对本实用新型实施例或现有技术中所需要的附图做简单介绍。显而易见的，下面所描述附图仅仅是本发明的一部分实施例，对于本领域技术人员来说，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，但均在本发明的保护范围之内。

附图1为一种规范化restful微服务交互方法的示意图；

附图2为知识存储及索引架构的示意图；

附图3为知识推荐系统结构的示意图。

具体实施方式

为使本发明的技术方案、解决的技术问题和技术效果更加清楚明白，以下结合具体实施例，对本发明的技术方案进行清查、完整的描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下获得的所有实施例,都在本发明的保护范围之内。

实施例

本实施例提出一种规范化restful微服务交互方法，如附图1所示，参考roythomasfielding博士《架构风格与基于网络的软件架构设计》文献，对rest接口约束来定义：资源的识别(identificationofresources)、通过表述对资源执行的操作、自描述的消息(self-descriptivemessages)、以及作为应用状态引擎的超媒体，本实施例分别针对restfulapiuri定义规范、资源操作表述规范、安全访问控制规范做微服务规范化标准定义。

本实施例规范化restful微服务交互方法，如附图1所示，采用微服务规范化组件restfulapiuri规则配置器实现规范化restfulapiuri定义，采用微服务规范化组件资源操作表述规则配置器实现规范化资源操作表述，采用微服务规范化组件安全访问控制规则配置器实现规范化微服务安全访问控制。

本实施例规范化restful微服务交互方法，通过规范化restfulapiuri定义，进行资源识别，解决uri表述混乱的问题；通过抛弃业界对资源操作通常采用的http动词形式表述，重新规范化一套restful资源操作表述，解决http动词形式表述的不足，来满足实际应用场景中多种资源(多表)的关联操作表述；通过规范化微服务安全访问控制，解决微服务高安全等级、细粒度的访问控制问题。这里，rest(representationalstatetransfer，简称rest)指的是一组架构约束条件和原则。restful是满足这些约束条件和原则的应用程序或设计。api(applicationprogramminginterface,应用程序编程接口)是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力。

1)规范化restfulapiuri定义：

定义uri结构为“通信协议+部署域名+服务版本+资源路径+资源操作表述”五部分；其中，通信协议：表示微服务api与用户的通信协议，比如http、ftp、snmp等，此部分一般使用https/http协议，可根据具体微服务协议进行扩展；部署域名：应该微服务部署的专用域名；服务版本：微服务的版本采用v+数字的形式，如v1、v3，主要是考虑微服务版本升级以及对外提供多版本服务支持；资源路径：具体资源路径表述，根据微服务应用约定的粒度进行分级路径表述，比以“应用系统/子系统/功能”三级表述、“应用系统/功能”二级表述；资源操作表述：用来对资源的具体操作类型表述。

2)规范化资源操作表述：

资源操作表述采用类数据访问层数据操作表述，统一并简化了业务逻辑处理层、数据访问层表述方法命名差异，资源操作类型包括查询、新增、修改、删除，其资源操作类型表述做如下规范约定：

对于条件查询(queryby***)操作类型表述，容易产生歧义操作类型表述，假设查询实体为doc,queryby后剩下的属性含义解析方法如下：

第一步：先判断taskprojectname(根据pojo规范，首字母变为小写)是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，继续第二步；

第二步：从右往左截取第一个大写字母开头的字符串此处为name)，然后检查剩下的字符串是否为查询实体的一个属性，如果是，则表示根据该属性进行查询；如果没有该属性，则重复第二步，继续从右往左截取；最后假设task为查询实体person的一个属性；

第三步：接着处理剩下部分(projectname)，先判断task所对应的类型是否有projectname属性，如果有，则表示该方法最终是根据“person.task.projectname”的取值进行查询；否则继续按照步骤2的规则从右往左截取，最终表示根据“person.task.project.name”的值进行查询；

第四步：可能会存在一种特殊情况，比如person包含一个task的属性，也有一个projectname属性，此时会存在混淆。可以明确在属性之间加上“_”以显式表达意图，比如“findbytask_projectname()”

这里以实体为user，有firstname和lastname,age，支持的规范表达式举例如下：

3)规范化微服务安全访问控制：

在微服务的安全访问控制方面，业界通常以基于token的认证方式，安全访问控制粒度比较粗，在实际的应用中，微服务的安全访问控制方面需要考虑细粒度、分层次、分级别的访问控制。为实现细粒度、高安全级别的访问控制，在微服务平台后台设置相应的安全访问策略，同时在微服务平台确认服务请求的相关信息。

规范化微服务安全访问控制，主要是指定义微服务的请求报文、响应报文规范；定义微服务的请求报文、响应报文规范如下：

附图2为服务请求报文结构示意图，如附图2所示，一个服务请求报文包括三部分内容：请求基本信息、请求扩展信息、请求业务信息，其中服务请求基本信息在请求头基本信息(header)节点内，请求扩展信息和请求业务信息在服务体(body)节点内，如下表所示：

属性详细说明：

appkey：请求方系统代码key；

trantime：交易请求时间(timestamp),格式yyyymmddhhmmss；

transeq：交易流水号，利用流水信息能够实现对整体交易的业务级监控，交易流水号是标识流水信息唯一性的凭证，所有交易在技术报文中都需要包含交易流水号。交易流水号的产生规则：谁发起请求谁负责产生交易流水号，流水号的编码规则遵循统一的编码规范。采用32位的uuid，以保证全局唯一；

signatureinfo：数据签名，服务请求方将token、trantime、transeq三个参数进行字典序排序拼接成一个字符串，利用sha1加密算法对该字符串进行加密生成数据签名证书；服务提供方接收到请求后再将token、timestamp、transeq三个参数进行字典序排序拼接成一个字符串并进行sha1加密，加密后的值与signatureinfo比对，确保请求来自有效的业务系统。(token为各接入商与服务提供方线下约定好的秘钥)；

body：业务数据，请求信息、响应信息都在该参数下，类型格式不做要求，以具体业务为准。

请求报文示例：

附图3为服务响应报文结构示意图，如附图3所示，一个服务响应报文包括四部分内容：响应基本信息、响应执行结果信息、响应扩展信息、响应业务信息，其中响应基本信息、响应执行结果信息在响应头基本信息(header)节点内，响应扩展信息、响应业务信息在服务体(body)节点内；如下表所示：

参数详细说明：

rtncode：返回代码大类，“0”代表成功；

code：返回代码小类；

message：返回信息。

响应报文示例：

以上应用具体个例对本发明的原理及实施方式进行了详细阐述，这些实施例只是用于帮助理解本发明的核心技术内容，并不用于限制本发明的保护范围，本发明的技术方案不限制于上述具体实施方式内。基于本发明的上述具体实施例，本技术领域的技术人员在不脱离本发明原理的前提下，对本发明所作出的任何改进和修饰，皆应落入本发明的专利保护范围。