CN111913713A - 一种基于服务调用追踪的异构服务集成方法 - Google Patents

Abstract

本发明公开了一种基于服务调用追踪的异构服务集成方法，其步骤包括：1)根据设定服务厂商的API的名称、版本和位置信息，收集各设定服务厂商的API语义信息；2)基于获取的API语义信息解析输入的DSL配置文件，得到泛化API与设定服务厂商API之间的映射规则；3)基于有序树构造算法对步骤2)处理后的DSL配置文件进行处理，得到基于有序树的API集成。本发明在异构环境中迁移时不需要重新编译，可以在运行时直接修改或按照策略更新，这种智能方法可以无缝对接新版本API，解决API同步问题，能够支持电子商务、互联网金融等实时性要求较高的场景。

Description

一种基于服务调用追踪的异构服务集成方法

技术领域

本发明属于软件技术领域，具体涉及基于反射方法的异构服务API智能集成系统。

背景技术

随着边缘计算、无服务计算等新型服务场景的出现，通过异构混合服务场景部署各类不同技术栈、不同业务功能的服务实例可以有效保障服务质量、提升开发效率以及提供细粒度运维监测数据。同时将多个业务部署在不同软件系统上能够应对“单点失效”问题，同时可根据业务负载特点、厂商服务类型选择性价比最高的若干家服务厂商。当前市场的发展呈现出主流服务厂商引领、开源框架定制服务的两个特点。一方面，以Alibaba、Azure、AWS等为代表的一线服务厂商提出了HotSopt、LoadBalance、SDN等一系列成熟产品并具有大量的商用成功案例，其技术成熟度高，通用性好，但是定制化成本较高；另外一方面，以Kubernetes、OpenShift、Docker等为代表的开源社区主流框架经过商用集成改造后大量使用在企业私有服务环境，其可定制化程度高，由于社区支持其成本较低，能够针对数十台至数十万台集群按需定制需要的UI、部署模型、监控工具等。企业级混合软件系统往往使用AWS等公有服务环境提供基础设施，定制Kubernetes等提供PaaS和SaaS等上层服务，在接入第三方服务厂商服务和定制开源框架，开发人员面临的核心问题是如何能够统一协调处理不同风格、不同层次和参数的各类软件系统API，如何高效整合异构服务API、提升开发效率直接关系到服务提供商的核心竞争力，是控制成本、保持产品稳定性的关键。

然而，通过分析全球市场十几年来的发展趋势，软件系统异构服务API集成问题仍然没有得到有效解决。首先，由于国内外技术发展水平、开发习惯和产业发展特点的差异，各个服务厂商对服务实例、服务控制器、私有网络隔离等业务组织层次有着不同的定义，导致其API的设计原则、参数命名、逻辑执行轨迹甚至文档质量等都有较大差异，难以自动化集成异构服务API；此外，由于上述新型服务场景的不断出现，其对软件系统应用需要的各类存储网络基础设施、Devops流程和部署方式带来了持续需求，主流服务厂商的API一般一年需要更新40次以上，开源框架一年至少更新10个以上的小版本，API集成需要大量的人工同步工作，企业需要耗费大量的人力、物力成本去维护自身产品的稳定性。因此，如何能够智能化、自动化地去集成异构服务并提供统一泛化且功能覆盖全面的API成为当前服务计算研究的重点。虽然当前工业和学术领域的主流研究成果能够通过初级的半自动化API集成在一定程度上减少人工工作量，但是由于厂商封闭和API更新等原因，这些研究成果仍然难以大规模真实商业使用。服务异构API集成方法的研究进展和其局限性主要有以下几个方面。

(1)解决异构服务API的集成问题，其最直观的方案是通过制定统一的标准来统一各个厂商和开源框架的API，较为成熟和具有一定使用率的标准主要有三个。其中CAMP标准(CAMP：G.P.T.R.Jacques Durand,Adrian Otto,“Cloud Application Management forPlatforms Version 1.1,”2014,http://docs.oasis-open.org/camp/camp-spec/v1.1/camp-spec-v1.1.pdf)仅在国外Solum、Brooklyn等PaaS平台上小规模使用，CAMP的使用要求、适用环境等和国内差异较大，在国内难以大规模推广；TOSCA标准(TOSCA：T.Binz,U.Breitenbucher,O.Kopp,and F.Leymann,“TOSCA:¨portable automated deploymentand management of cloud applications,”in Advanced Web Services.Springer,2014,pp.527–549.)虽然其定义较为全面，且基于XML能够快速建模实现自动化服务部署，但其较为复杂，可操作性差，主流软件系统都难以支持此标准；OCCI标准(OCCI：A.P.T.M.RalfNyren,Andy Edmonds,“Open Cloud Computing Interface-Core,”2011)通过基于Restful的远程管理API来代理各类服务实现自动部署、弹性伸缩和监测等功能，其架构较为合理，但粒度较粗，为了支撑新的第三方服务需要大量繁琐、低质量的开发工作。因此，通过指定统一服务厂商服务API标准的方式在市场现阶段难以有效推进，由于厂商版权、市场份额竞争和技术门槛等原因，统一API标准只能在小型和特定场景中使用，其价值有限。

(2)服务集成研究项目一般通过语义注解来系统管理异构软件系统。PaaSPort项目(N.Bassiliades,M.Symeonidis,G.Meditskos,E.Kontopoulos,P.Gouvas,andI.Vlahavas,“A semantic recommendation algorithm for the PaaSport platform-as-a-service marketplace,”Expert Systems with Applications,vol.67,pp.203–227,2017.)提供语义cloud-broker来部署、管理和迁移各类服务，它需要PaaS API通过OWL拓扑结构进行语义注解，其构造的API同样遵循CAMP和Cloud4SOA标准；MDE框架(F.Gonidis,I.Paraskakis,and A.J.Simons,“Leveraging platform basic services in cloudapplication platforms for the development of cloud applications,”in 2014 IEEE6th International Conference on Cloud Computing Technology and Science(CloudCom).IEEE,2014,pp.751–754.)可以屏蔽异构服务的多样性，基于语义拓扑和元数据模型提供泛化API，能够处理异构API的共同属性，难以处理独特属性。这些研究项目往往基于受限的语言表达模型，其语义输入需要大量的人工标注和修正校验，不支持一些主流厂商的定制功能，不能应对国内企业复杂多变的需求。

(3)近年来发展较为迅速的解决是对外提供统一的泛化API，在后台构造不同厂商的集成器达到异构服务统一管理的目的。策略驱动中间件PaaSHopper(S.Walraven,D.VanLanduyt,A.Rafique,B.Lagaisse,and W.Joosen,“PaaSHopper:Policy-drivenmiddleware for multiPaaS environments,”Journal of Internet Services andApplications,vol.6,no.1,p.1,2015.)针对服务在开发和部署阶段的问题，用API抽象层来集成异构服务，用策略驱动层来管理服务的部署运维，其技术较为成熟，但是存在非开源、手工化集成等问题；STAGER框架(Khattab,Sherif,Fatma A.Omara,and HishamHassan."STAGER:Semantic-based Framework for Generating Adapters of Service-based Generic-API for Portable Cloud Applications."IEEE Transactions onServices Computing(2018).)则是近年来最早提出使用半自动化代码生成技术构造泛化API的典型代表，通过定义软件系统提供者、厂商API注入器、泛化API设计者和服务开发者四类角色来明确自动化生成和人工工作的边界，能够较好应对API更新，在一定程度上较少人工工作，仅在GCE和Azure上进行了初步时间，其模型集成性和代码生成开销扔需要继续测试验证。

异构服务API集成通过统一行业标准、第三方人工集成项目和泛化API等方法解决，由于技术水平和推广程度的差异，其发展情况不一致，没有主导性的解决方案，一个较为成熟的产品或框架需要能够以低成本较好应对上述三方面存在的问题。首先，集成方法能够符合市场需求，具有可推广性，不能违背现有服务的发展趋势和产业格局；然后集成方法必须保持足够的可用性，能够兼容主流服务厂商的核心功能，可快速扩展接入各类异构服务；最后面向实际发人员，其培训周期、开发流程、使用方法要简单可控，在成本和性能开销可控的情况下集成不同行业、不同技术栈等的多源异构环境。因此，需要智能的软件系统异构服务API集成方法来准确定义软件和人工的边界与协同工作流程，最大限度减少人工工作，且能根据集成场景和API的变化自动调整相关参数和服务管理策略。

发明内容

为了解决集成时标准难以统一、集成模型难以覆盖主流服务厂商功能、手工集成工作量大准确性不足、集成代码不能随API变化自动更新等问题，本发明的目的在于提供一种基于服务调用追踪的异构服务集成方法。

本发明的技术原理：本发明结合高级编程语言的反射特性和面向切面编程技术实现高效集成，追踪服务调用的过程。

本发明技术解决方案具体包括以下步骤：

(1)服务调用反射分析：其功能是收集主流服务厂商的API服务调用的语义信息，其目的在于克服一般人工标注和手动收集文档的不全面、不准确的问题，分析的可用性在于主流服务厂商均采用统一的开发和组织规范来生产供第三方开发的API服务调用。第三方开发人员输入服务厂商API服务调用的名称、版本、位置等基础信息以及若干启发式搜索规则，服务调用反射分析根据规则和基础信息从服务调用中反向查找所有的API及参数信息，并导出格式化文档，输出文档作为开发人员编写基于领域特定语言(DSL)的配置文件参考，提供相较于官方文档更为安全和准确的服务调用数据，其过程如下：

1)服务描述及校验，面向本发明之后不断新增的各类API，从开发人员的输入数据中得到特定服务厂商服务调用的API资源描述符向量RIV＝{metadata_v,uri_s,addiset_s}其中：metadata_v代表需要分析的服务厂商的服务调用API的标准SDK描述信息；uri_s代表服务调用资源获取的协议和位置信息，默认直接通过类加载尝试获取；addiset_s可选，用于填充符合JDBC或OWL规范的身份认证等信息；然后基于JSR 303规范，通过正则匹配和注解机制，完成RIV信息的静态校验；

2)如果静态校验通过，就根据服务厂商的RIV信息，输入服务集成的若干启发式规则HR，这些规则由第三方开发人员按需导入，其格式的形式化定义如下：

HR＝{HR₁,HR₂,...,HR_m}

式中，HR_i代表面向资源i中同一类API的具体的启发式规则，所有规则构成服务厂商的服务调用API预期分析的集合HR，HR中包含m个元素，分别通过下标1至m进行标示，每个规则按照不同类型的资源类型下标i进行区分，由一个独立的偏序关系→进行刻画：首先通过搜索SDK中每类API的匹配前缀prefix_i、标示接口int erface_i、URL名称identifier_i确定SDK的反射搜索入口；接着，通过执行指针的增量操作Δ不断增加一类API的反射索引，将新索引pointer_n添加到指针集合D中，其中n表示当前指针代表类的属性property_j与方法method_j个数，所有的n构成完备的n∈D，其中j代表类中的属性及方法编号，每次增量都会触发反射创建新的实例，其中+表示属性和方法的并集操作，×表示启发规则每次增量操作的操作对象，即属性和方法的局部集合；

3)所有启发式规则装载完毕后，从服务调用远程方法调用client端的入口基础类开始反射实例化，执行整个分析过程APR：

分析过程依次遍历所有的资源类型i，针对每一类资源类型，首先使用2)中装载的启发式规则HR_i对资源类型i对应的一类API进行反射分析链(深层嵌套的复杂对象设置顺序)的初始化，在遇到嵌套对象(https://www.tutorialspoint.com/java/java_innerclasses.htm)或复杂类型(除java基本数据类型https://www.w3schools.com/java/java_data_types.asp之外的类型)时执行增量操作；增量操作作为递归运算，只有其当所有子资源(嵌套对象和复杂类型)遍历完成后才会继续分析下一种资源类型i+1，当所有i≤m种资源的反射分析链都正常终止时，返回当前资源的根指针；如果出现异常，则返回异常终止位置，异常提示信息中的子属性位置、分析进度等信息统一由errhandler_ij记录，exporter_ij存放目前资源、属性的离散关系和具体类型并最终以文档形态导出分析结果。步骤3)将启发式规则、异常处理和结果输出三个核心功能剥离，可随时调整目标服务调用，更改规则，能够及时追踪异常位置并验证分析结果，同时分析结果还可以与官方文档对比，校验官方文档完整性和服务调用编码规范，分析结果能够表达一类资源所有API的内部属性和方法，即作为服务集成语义信息，为后续二次研发人员的解析调用等操作提供支撑。

(2)服务追踪描述语言解析：按照(1)中获取的语义信息，面向二次研发人员输入的DSL配置文件，使用java Properties操作接口，解析DSL配置文件中的属性及方法映射规则，实现泛化API到厂商特定API的转化，可以在服务集成软件首次启动时按照java环境变量配置解析所有的DSL文件，或者按需在运行时更新DSL及相关缓存。DSL解析结果以KV键值对的形式在缓存中存放，作为API集成(即步骤(3))的输入数据。服务追踪描述语言的解析调用如下：

1)基本语法校验：服务集成映射描述语言完成泛化API方法、属性名称(企业内部研发规范中得到及扩展)到实际服务调用服务、属性名(步骤(1)中得到)的映射，这种DSL采用基础的“prefix-key＝value”形式书写，其中prefix-key的取值为泛化API的方法或属性，由第三方开发人员结合企业实际情况设置；value代表其prefix-key所映射的厂商特定SDK服务参数的类名称或反射分析链；

2)DSL信息提取解析：根据1)中等号左侧的字符取值进行解析，有以下几种情况：以“key”字面值为结尾的部分，有且仅有两个映射关系，分别表达泛化API和厂商服务调用API的保留关键字，是DSL开始两行的内容；以普通小写字符串标记的部分，注明泛化API最外层参数对应服务调用的类型名称或者反射分析链；以“-”开头的部分为内层参数，如内层有多个则通过多个-分割；以$开头的部分为自定义变量，用于开发人员扩展映射规则时的保留配置，按照上述规则解析所有DSL配置文件，得到泛化API和厂商特定API之间的映射规则。

3)导出缓存：上述映射关系直接表达服务厂商一类或多类资源与泛化API的映射层次，在服务集成方法运行时通过全局变量缓存所有DSL的解析结果，需要时可以通过下标、key值等直接访问，同时使用java字节码技术进行版本的热升级和更新。

(3)基于有序树的API集成：使用启发式规则优化的有序树(Heuristic Order-based Tree)算法进行不同厂商API的统一集成。API集成使用有序树构造算法，将平台无关的参数转化为特定厂商服务调用需要的格式(JSON或XML)，并最终转发步骤(4)。构造有序树对泛化API参数依次进行处理，使用参数重新命名、数组及字符串分割、对象嵌套赋值、集合构造等缺省操作和开发人员自定义的参数映射方法，支持多源异构服务API简单数据类型和复杂数据对象的接口集成，可以避免API版本更新导致的维护问题。面向任何厂商的每次API调用，其基于有序树算法实现集成的步骤如下：

1)初始化有序树的头结点tree_key，以及头结点的两个固定后继节点node_target和node_main，其中node_target记录厂商特定服务的认证信息和URL地址，node_main记录集成后服务调用相关的请求参数；

2)开始依次遍历泛化API中的每个参数node_p，参数符合Json格式，可以实现和java原生数据格式的映射(基本数据类型、对象和数组)，每个参数node_p的命名与DSL中的prefix-key对应，可以根据其命名在DSL中找到厂商特定的分析链(即DSL中对应的value值)。针对每个参数按照以下顺序执行步骤3)～5)，当参数遍历完毕且没有异常时，执行过程7)，即一次集成结束；

3)如果当前参数node_p按照DSL中的配置信息，能通过反射找到了对应key值的开发人员自定义方法，则集成算法将该参数传递给该自定义方法，基于方法名称和参数找到该方法，然后使用Java invoke接口实现对该方法的反射调用，方法的返回值约定为node_p本身的引用(否则会出现异常)，node_main会在自定义方法执行完毕后新增node_p作为有序树子节点(自定义方法需要保障node_p前驱、后继的正确性，否则也会出现异常)，如果此过程没有异常，则日志记录，返回新增的node_p，并返回过程2)遍历下一个参数，否则执行异常处理过程6)；

4)如果当前参数node_p没有找到自定义方法且参数是一个数组，说明该参数是有序树的中间节点，先反射实例化node_p并记录为当前父亲节点node_current；然后继续按照顺序遍历该数组中的每个元素，每个元素的特征及对应处理逻辑同样由集成步骤2)递归处理(https://baike.baidu.com/item/％E9％80％92％E5％BD％92％E5％87％BD％E6％95％B0/5634537？fr＝aladdin)，即当元素是基本数据类型、对象和数组时，对该元素执行步骤3)-5)，如果递归处理没有异常，将步骤步骤3)-5)中返回的node_p作为node_current的子节点，并返回node_current作为新的node_p；

5)如果当前参数node_p没有找到自定义方法且参数是一个简单数据类型或者对象(HashMap)时，说明该参数是有序树的叶子节点，直接将node_p添加为node_main的直接后继节点，记录日志返回node_p，并再次回到步骤2)遍历下一个参数；如果缓存中没有对应数据，执行异常处理过程6)；

6)记录异常产生位置，输出当前node_main、node_current信息和显示集成完成比例，查询DSL缓存中的异常部分；

7)按照有序树的前序遍历算法(https://baike.baidu.com/item/％E5％89％8D％E5％BA％8F％E9％81％8D％E5％8E％86/757319？fr＝aladdin)遍历有序树tree_key(tree_key已经通过步骤2)-6)完成了初始化)，将有序树tree_key以Json文本或其他格式导出，每个Json元素的key是厂商服务调用API相关的类型或设置方法(与DSL配置中的Value对应)，value是真实业务请求参数(在步骤4中会更新)中的字符串、数值和集合。相较于STRGER等半自动框架生成的代码，其不需要在运行前预生成，且可以随服务调用的更新而自动调整，此基于Json的服务集成产物具有运行时动态更新和自动化同步的特点。

(4)用户特定的反射执行：当用户特定服务请求(包含特定执行规则，即tree_key中node_target的描述信息，以及node_main中的参数信息，是(3)中集成结果的子集)到来时，根据步骤(3)中泛化API和厂商特定API的集成结果，填充(3)最后获得到的JSON中的真实业务请求参数，然后基于反射驱动(Reflection-driven)引擎来智能化执行多个服务厂商和开源框架的API，从而完成一类厂商一类资源(都在tree_key中node_target进行了描述)的API适配过程。其过程如下所示：

1)服务远程方法调用环境初始化：从Json数据中的node_target域读取上下文相关信息，根据URI和认证信息{URI,Certifications}获取服务远程方法调用远程操作入口，由于主流厂商的服务模式和认证机制相对完善且不容易变化，这部分代码通过人工集成完成，远程操作入口实例作为Json数据node_main域中反射执行的起点；

2)反射语义执行：首先根据特定服务请求确认泛化API的操作对象和操作方法，然后通过深度优先遍历依次填充需要的参数：如果Json对象的key是类名，就在反射起点的基础上实例化新的对象；如果Json对象的key是以-开头的反射链，则执行key分割，按照先进先出的顺序依次实例化上层对象，并最后调用setter方法结束反射；

3)服务请求处理：根据2)中执行后的已经实例化过的操作对象和操作方法，基于restful方式，发起服务请求，本方法对提供商的请求结果(资源操作结果及基于HTTP协议的状态码)基于java多层try catch机制和注解技术进行二次封装，提升服务请求结果的可读性，满足国际化和客户定制等需求。

综上，本发明基于异构服务的服务调用及API，形成如图1所示的执行过程：首先分析特定厂商服务的资源种类、操作规范和API信息，定制启发式分析规则智能化导出各类异构服务的语义反射链，继而由开发人员根据泛化API格式，书写服务集成映射关系，通过有序树构造算法实现泛化API到服务调用API的参数转换，最后由反射执行器实际调用服务调用，封装异构服务的管理空间，通过日志监测智能方法的性能和开销，实现在多厂商、API自动同步情况下的软件系统运维。

本发明与现有技术相比具有如下优点：

(1)不需要统一的API标准，开发人员可以自定义映射规则：相关开发人员可以继承符合本公司开发规范的API，不需要进行额外设计，只需要使用DSL描述与标准API的映射关系，从而提供与底层技术无关的应用层API，可以显著减低开发团队的培训成本和重复性工作；

(2)基于反射的API分析器与执行器充分利用高级语言的动态编程特性，除DSL外不需要生成代码，在异构环境中迁移时不需要重新编译，可以在运行时直接修改或按照策略更新，这种智能方法可以无缝对接新版本API，解决API同步问题；

(3)本方法兼顾功能性与扩展性的统一，在开发效率层面，不需要提供厂商API语义和集成器接口，通过包、类和方法的命名规则反射实现少数难以自动化的映射，通过大量缺省规则处理服务厂商绝大多数API特性；在运行效率层面，使用字节码缓存、内存高性能数据库和基于线程的P/S模型来约束DSL解析和反射驱动的开销，能够支持电子商务、互联网金融等实时性要求较高的场景；

(4)智能集成方法重新定义开发流程中角色和职责，将STRGER框架中的四个角色减少为服务提供商和开发人员两个，不需要特别设计泛化API和语义注解，从不同角度进行服务集成。

附图说明

图1为本方法的执行过程；

图2为本方法的典型部署环境。

具体实施方式

如图2所示的场景，服务调用分析器作为独立的工具部署在Machine1上，DSL解析器、API集成和反射执行器作为独立的第三方SDK包在第三方私有服务管理平台上使用，并以容器方式运行。所管理的资源有：

(1)已付费经过认证的阿里云账号，能够创建若干ECS实例，ECS实例之间通过专有网络连接；

(2)可以通过Ansible方式安装的Kubernetes与OpenShift；

(3)待部署的一套微服务应用，可以兼容kubernetes方式部署的image及相关配置参数。

通过在ECS上分别部署两套集群，验证本智能集成方法在ECS、Kubernetes和OpenShift集群上的集成能力，可以充分发挥本方法在不同层次上基于厂商服务调用的集成效果和性能开销。其中服务调用分析工具使用maven构建，其余组件使用spring boot方式构建，能够接受Json格式的参数，并通过AOP方式根据服务厂商种类切入，进行参数转换、反射执行和结果封装，混合服务管理平台通过注解方式使用本方法，最大限度避免侵入性；请求其实施方式如下所示：

(1)确认ECS、Kubernetes和OpenShift的配置版本及对应较为成熟稳定的服务调用开发包，书写服务调用分析器需要的基础参数，执行服务调用分析，导出服务调用相关API的语义文档；

(2)根据ECS和Kubernetes的分析文档制定书写DSL的表达规则，撰写DSL映射关系，生成ECS中createInstance，Kubernetes中createDeployment，OpenShift中createDeploymentConfig三个分别创建虚拟机实例和微服务实例的泛化API到厂商API的映射规则；

(3)发起7台创建ECS实例的请求，进行API映射和反射驱动，获取实际的执行调用关系，界面显示创建结果；并调用Ansible分别创建各个地区的Kubernetes与OpenShift集群，返回访问集群的API地址和认证token，混合服务管理平台能够按照区域筛选全部的基础设施；

(4)分别调用Kubernetes和Openshift的创建接口，在Kubernetes集群中部署微服务业务实例(github地址)并对外创建Ingress访问入口；在Openshift集群中部署需要的文件系统、数据库和缓存等基础服务，并对外创建nginx负载均衡器，混合服务管理平台能够在同一UI下展示两个异构软件系统之上的一个应用；

(5)创建相关的私有网络和负载均衡器，验证API集成对其他资源的集成效果，并在后台查询实际的隔离和访问情况。

提供以上实施例仅仅是为了描述本发明的目的，而并非要限制本发明的范围。本发明的范围由所附权利要求限定。不脱离本发明的精神和原理而做出的各种等同替换和修改，均应涵盖在本发明的范围之内。

Claims (8)

1.一种基于服务调用追踪的异构服务集成方法，其步骤包括：

1)根据设定服务厂商的API的名称、版本和位置信息，收集各设定服务厂商的API语义信息；

2)基于获取的API语义信息解析输入的DSL配置文件，得到泛化API与设定服务厂商API之间的映射规则；

3)基于有序树构造算法对步骤2)处理后的DSL配置文件进行处理，得到基于有序树的API集成。

2.如权利要求1所述的方法，其特征在于，收集各设定服务厂商的API语义信息的方法为：

11)生成每一设定服务厂商的API资源描述符向量RIV＝{metadata_v,uri_s,addiset_s}；其中metadata_v代表设定服务厂商的服务调用API的标准SDK描述信息，uri_s代表服务调用API的资源获取协议和位置信息，addiset_s为可选项，用于填充符合JDBC或OWL规范的身份认证信息；然后对RIV信息进行静态校验；

12)静态校验通过后，根据设定服务厂商的RIV信息对每一资源类型设置一启发式规则；

13)依次遍历所有的资源类型，其中针对每一资源类型i，使用该资源类型i对应的启发式规则HR_i对资源类型i中的API进行反射实例化，得到该资源类型i的API语义信息。

3.如权利要求2所述的方法，其特征在于，当资源类型i有子资源时，遍历完资源类型i的所有子资源后继续分析下一种资源类型i+1的API语义信息。

4.如权利要求2所述的方法，其特征在于，资源类型i对应的启发式规则HR_i为：

其含义为：首先通过搜索SDK描述信息中资源类型i的API的匹配前缀prefix_i、标示接口interface_i、URL名称identifier_i确定SDK的反射搜索入口；然后通过执行指针的增量操作Δ生成API的反射索引pointer_n并添加到指针集合D中，property_j表示当前指针代表类的第j个属性，method_j表示当前指针代表类的第j个方法method_j，其中+表示属性和方法的并集操作，×表示启发规则每次增量操作的操作对象。

5.如权利要求2所述的方法，其特征在于，如果对资源类型i中的API进行反射实例化时出现异常，则返回异常终止位置，并记录异常提示信息中的子属性位置和分析进度信息。

6.如权利要求1所述的方法，其特征在于，步骤2)中，所述DSL配置文件包括多个“prefix-key＝value”；其中prefix-key的取值为泛化API的方法或属性，由第三方开发人员结合企业实际情况设置；value代表prefix-key所映射的设定服务厂商SDK服务参数的类名称或反射分析链；得到泛化API与设定服务厂商API之间的映射规则的方法为：对“prefix-key＝value”中等号左侧的字符取值进行解析，得到泛化API和设定服务厂商API的保留关键字；注明泛化API最外层参数对应服务调用的类型名称或者反射分析链；以“-”开头的部分为内层参数；以$开头的部分为自定义变量，用于开发人员扩展映射规则时的保留配置。

7.如权利要求1所述的方法，其特征在于，步骤3)中，得到基于有序树的API集成的方法为：

31)对于每一泛化API，初始化有序树的头结点tree_key，以及头结点的两个固定后继节点node_target和node_main，其中node_target记录设定服务厂商API的认证信息和URL地址，node_main记录集成后服务调用相关的请求参数；

32)开始依次遍历泛化API中的每个参数node_p，针对每个参数node_p，执行步骤33)～35)，当参数遍历完毕且没有异常时，执行过程37)，即一次集成结束；

33)如果当前参数node_p按照DSL中的配置信息，能通过反射找到对应key值的自定义方法，则将该参数node_p传递给该自定义方法并对该自定义方法进行反射调用，如果方法的返回值是约定的参数node_p本身，则node_main在自定义方法执行完毕后新增node_p作为有序树子节点；如果出现异常，则执行步骤36)；

34)如果当前参数node_p没有找到自定义方法且参数node_p是一个数组，则先反射实例化node_p并记录为当前父亲节点node_current；然后继续按照顺序遍历该数组中的每个元素，将元素作为参数node_p，根据元素是基本数据类型、对象或数组选择执行对应的步骤33)、34)或35)，如果递归处理没有异常，则将返回的node_p作为node_current的子节点，并返回node_current作为新的node_p；

35)如果当前参数node_p没有找到自定义方法且参数是一个简单数据类型或者对象时，则直接将node_p添加为node_main的直接后继节点，记录日志返回node_p；如果缓存中没有对应数据，执行异常处理过程36)；

36)记录异常产生位置，输出当前node_main、node_current信息和显示集成完成比例，查询DSL缓存中的异常部分；

37)遍历当前生成的有序树tree_key，将有序树tree_key以Json文本导出，每个Json元素的key是设定服务厂商API的类型或设置方法，value是真实业务请求参数中的字符串、数值和集合。

8.一种基于权利要求1所述异构服务集成的服务调用执行方法，其步骤包括：

1)对于收到的异构软件系统应用的服务请求，该服务请求包含node_target的描述信息以及node_main中的参数信息，服务远程方法调用环境初始化：从Json数据中的node_target域读取上下文相关信息，根据URI和认证信息获取服务远程方法调用远程操作入口，将远程操作入口实例作为Json数据node_main域中反射执行的起点；

2)反射语义执行：首先根据该服务请求确认泛化API的操作对象和操作方法，然后通过深度优先遍历依次填充需要的参数：如果Json对象的key是类名，则在反射起点的基础上实例化新的对象；如果Json对象的key是以-开头的反射链，则执行key分割，按照先进先出的顺序依次实例化上层对象，并最后调用setter方法结束反射；

3)服务请求处理：基于步骤2)中实例化的操作对象和操作方法，向对应的设定服务厂商发起服务请求，并返回该服务请求的处理结果。

Images