一种多接口数据的调度方法
【专利摘要】本发明涉及一种多接口数据的调度方法，本发明通过建立一个接口调度机制，利用该接口调度机制产生接口调度策略，尽可能多的使用后台处理并发，使得后台的并发数量达到合理的最大值，前台在不影响核心业务展现的前提下请求接口的数量达到最小，使得后台能最大限度的利用cpu多核的优势并发拿到数据而前台只关心渲染和用户交互而不是传输数据，本发明的优势主要包括：前台页面能够以最小的频率和后台交换数据，展示时可以有效地减少页面的重排重绘；后台并发处理了大量的交互接口，保证了核心业务可用，非核心功能最大效率地往前台展示。
【专利说明】
一种多接口数据的调度方法
技术领域
[0001]本发明涉及互联网领域，具体涉及一种多接口数据的调度方法。
【背景技术】
[0002]网站在逐步发展的过程中，每个页面随着业务越来越多，需要的额外数据会越来越多，这些数据往往有各自原生的信息来源，比如数据库、内存、文件，为了让开发更高效，大多数公司中往往会用封装的方式各自封装这些原生的信息来源，每个封装好后的消息来源也叫接口，并且这些接口往往不在一台服务器上，所以每个页面在获得数据的时候，会向多个服务器上的接口请求获得想要的数据。一个页面要展示某些业务要分别请求各种业务提供数据的接口，会有这样几种方式:
[0003 ] (I)完全从后台请求数据
[0004]用户打开页面，向后台发起请求，由后台程序向所有的数据接口发送获取请求，然后打包发送给前台，之后再由前台再负责展示，这种方式下若有一个接口发生问题，会发生多米诺效应，导致整个后台瘫痪，这种问题在一些暂时不支持多线程开发的PHP程序中很常见，接口多时往往不会用这种方法；
[0005](2)完全由前台发送AJAX请求接口获得数据
[0006]用户打开页面，不通过后台，完全由前台发送AJAX请求接口获得数据，最终通过回调函数展现业务逻辑，完全不用后台，但是这种方式由于安全问题并不常用。此外，全部由前台发送请求，如果业务需求请求数量多，或者有相互依赖的情况时，机器配置低的浏览器会因为请求数量过多而出现卡顿很久的现象。
[0007](3)前后台混合方式:
[0008]由后台请求核心业务接口优先展示核心业务，前端发送AJAX使用回调函数展示非核心业务，目前这种方式最为常见。但是，这种方式核心业务的接口一般数据量比较大耗时很长，并发利用率不高；而非核心业务推到前台建立AJAX请求，一旦非核心业务数量过多，前台在处理这些请求的时候会发生卡顿的现象;此外，在业务开发过程中，一个或多个小组负责完成一个业务导致非核心业务越来越多，前台调用的AJAX也越来越多，页面刚刚加载完要去处理许多AJAX并发业务，很有可能会出现卡顿的现象。
[0009]综上所述，需要一个接口控制的方法来管理各种接口的调用，能够在稳定的输出核心业务的同时为页面高效地添加非核心业务。
【发明内容】
[0010]为了解决上述技术问题，本发明提供了一种多接口数据的调度方法，针对当网页请求多个接口时出现的卡顿现象建立一个接口调度机制，尽可能多的使用后台处理并发，从而达到稳定的输出核心业务的同时为页面高效地添加非核心业务的效果。
[0011]本发明是以如下技术方案实现的，
[0012]—种多接口数据的调度方法，包括对于处理核心业务的核心接口和处理非核心业务的非核心接口进行调度，包括以下步骤:
[0013]S1.为接口分类，并将分类后的接口纳入相应的容器:
[0014]将能够被直接调度的核心接口纳入核心接口容器，
[0015]将不能够被直接调度的核心接口纳入有依赖核心接口容器，
[0016]将能够被直接调度的非核心接口纳入非核心接口容器，
[0017]将不能够被直接调度的非核心接口纳入有依赖非核心接口容器；
[0018]S2.获取HTTP请求中的页面参数；
[0019]S3.根据所述页面参数更新有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器；
[0020]S4.对所述核心接口容器和非核心接口容器中的未被调度过的接口进行并发调用；
[0021]S5.根据S4的调用结果，向前端发送数据；
[0022]S6.前端展示S5中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，则对所述非核心接口进行调用；
[0023]S7.向前端展示S6中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，继续对所述非核心接口进行调用，并将调度结果显示在前端。
[0024]优选的，S3中更新有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器包括:
[0025]在已知所述页面参数的前提下，遍历有依赖核心接口容器和有依赖非核心接口容器，
[0026]若有依赖核心接口容器中存在能够被直接调度的核心接口，则将能够被直接调度的核心接口移至所述核心接口容器，
[0027]若有依赖非核心接口容器中存在能够被直接调度的非核心接口，则将所述能够被直接调度的非核心接口移至所述非核心接口容器。
[0028]优选的，S4包括:
[0029]S41.开启线程并行调度所述核心接口容器和非核心接口容器中的未被调度过的接口；
[0030]S42.若获取响应，则判断是否为成功响应，若是，则进行S43，若否，则直接停止所有用于接口调度的线程，直接返回HTTP响应:报文状态502服务器问题或307跳转到对应的页面；
[0031]S43.将获取所述响应的接口标记为已调度接口，查询所述响应结果是否是有依赖核心接口容器和/或有依赖非核心接口容器中的接口所需要的待定参数，如果是，则进行S44，否则，进行S46;
[0032]S44.用所述响应结果替代所述待定参数，并在所述待定参数已知的前提下，判断需要所述待定参数的接口是否能够直接被调度，若能，则进行S45，否则，进行S46;
[0033]S45.若需要所述待定参数的接口为核心接口，则将所述核心接口从有依赖核心接口容器移至核心接口容器，若需要所述待定参数的接口为非核心接口，则将所述非核心接口从有依赖非核心接口容器移至非核心接口容器；
[0034]S46.获得响应的线程继续调度所述核心接口容器和非核心接口容器中的未被调度过的接口，直至全部核心接口均获得响应。
[0035]优选的，S4还包括获取未被调用的核心接口数量N与线程最大并发数tMax，S4中开启的线程的数量不大于tMax;若N不大于tMax，则并行调度的非核心接口数量和核心接口数量比值小于最大并发比，否则，先并行调度核心接口，并实时获取N值，当N小于tMax时，调度过程中满足并行调度的非核心接口数量和核心接口数量比值不大于最大并发比。
[0036]优选的，S4还包括开启并行线程之前，对所述核心接口容器和所述非核心接口容器中的接口按照重要性进行排序，调度过程中依次对所述核心接口容器和所述非核心接口容器中的未被调度过的接口进行调用。
[0037]优选的，S4还包括开启并行线程之前，对所述有依赖核心接口容器和所述有依赖非核心接口容器中的接口按照重要性进行排序。
[0038]优选的，S5包括:
[0039]判断是否存在未获得响应和/或响应失败的非核心接口，若有，则将所述未获得响应和/或响应失败的非核心接口的元素与S4中获取的数据一起打包;否则，只打包S4中获取的数据；
[0040]将打包结果发送到前端。
[0041]优选的，所述元素包括未获得响应和/或响应失败的非核心接口的接口id和调度所述未获得响应和/或响应失败的非核心接口需要的参数。
[0042]优选的，所述有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器中的接口均包含表征所述接口状态的状态标识。
[0043]优选的，S4中通过HTTP请求进行接口调用，S5和S6中ajax进行接口调用。
[0044]本发明的有益效果是:
[0045]本发明提供了一种多接口数据的调度方法，通过建立一个接口调度机制，利用该接口调度机制产生接口调度策略，尽可能多的使用后台处理并发，使得后台的并发数量达到合理的最大值，前台在不影响核心业务展现的前提下请求接口的数量达到最小，使得后台能最大限度的利用cpu多核的优势并发拿到数据而前台只关心渲染和用户交互而不是传输数据，本发明的优势主要还包括:
[0046]前台页面能够以最小频率的和后台交换数据，展示时可以有效地减少页面的重排重绘;后台并发处理了大量的交互接口，保证了核心业务可用，非核心功能最大效率的往前台展示。
【附图说明】
[0047]图1是第一个实施例多接口数据的调度方流程图；
[0048]图2是第一个实施例并行调度接口流程图。
【具体实施方式】
[0049]为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
[0050]实施例1:
[0051]在第一个实施例中，如图1所示，一种多接口数据的调度方法，包括对于处理核心业务的核心接口和处理非核心业务的非核心接口进行调度，本实施例以视频播放网站为例，核心接口为实现网页播放视频功能的相关接口，非核心接口为实现网页其它功能的接口，比如实现评论功能，相关视频列表显示功能、订阅功能和下载功能的接口均为非核心接
□ O
[0052]多接口数据的调度方法包括以下步骤:
[0053]S1.为接口分类，并将分类后的接口纳入相应的队列:
[0054]将能够被直接调度的核心接口纳入核心接口队列，
[0055]将不能够被直接调度的核心接口纳入有依赖核心接口队列，
[0056]将能够被直接调度的非核心接口纳入非核心接口队列，
[0057]将不能够被直接调度的非核心接口纳入有依赖非核心接口队列；
[0058]S2.获取HTTP请求中的页面参数；
[0059]S3.将所述页面参数作为接口所依赖的参数，更新有依赖核心接口队列、核心接口队列、非核心接口队列和有依赖非核心接口队列；
[0060]S4.对所述核心接口队列和非核心接口队列中的未被调度过的接口进行并发调用；
[0061 ] S5.根据S4的调用结果，向前端发送数据；
[0062]S6.前端展示S5中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，则对所述非核心接口进行调用；
[0063]S7.向前端展示S6中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，继续对所述非核心接口进行调用，并将调度结果显示在前端。
[0064]具体地，更新有依赖核心接口队列、核心接口队列、非核心接口队列和有依赖非核心接口队列方法为:
[0065]在已知所述页面参数的前提下，遍历有依赖核心接口队列和有依赖非核心接口队列，
[0066]若有依赖核心接口队列中存在能够被直接调度的核心接口，则将能够被直接调度的核心接口移至所述核心接口队列，
[0067]若有依赖非核心接口队列中存在能够被直接调度的非核心接口，则将所述能够被直接调度的非核心接口移至所述非核心接口队列。
[0068]首先，先介绍几个定义:
[0069]CoreList为核心接口队列，CoreDependList为有依赖核心接口队列、
[0070]AppendList为非核心接口队列,AppendDependList为有依赖非核心接口队列。
[0071]接口均包括如下元素:
[0072]id:接口唯一的请求号；
[0073]state:接口状态，-1表示依赖参数的未参数拿到，O表示未请求，I表示请求进行中，2表示请求完成，3表示请求失败；
[0074]url:请求地址；
[0075]method:请求方法；
[0076]param:请求接口时要带的参数；
[0077]核心接口全部完成标识:CoreListState ；
[0078]CoreListState为O表示核心接口并没有发送完请求并得到返回值，I表示得到了所有的返回值，-1表示存在接口没有响应。
[0079]最大线程数:tMax
[0080]处理并发的最大数量，用来描述物理计算机理论上合理的线程并发量，本实施例提供一个线程数的运算方法，Memery为程序分配的进程内存(注意，这个数量是单个后台程序触发的，如果有多个worker，要乘以worker数量)，本实施例中为128M，用ulimit-s可以查看默认的线程栈大小，一般情况下这个值是8M;则tMax: 128/8 = 16。
[0081 ] 核心业务接口和非核心业务接口的最大并发比:CoreVSAppend
[0082]存在核心业务并发时核心接口往往就几个，本实施例中并未把所有其余的线程都用作非核心线程，线程多了对整个进的程轮询也会慢，核心线程如果完成时会停掉其余的线程，如果非核心业务接口的请求线程过多又没有完成会造成网站的压力;CoreVSAppend这个值的设定由核心接口的平均响应时间CoreTimeAve和非核心接口的平均响应时间AppendTimeAve做比较得到的，这个需要看接口的日志确定各个接口的平均响应时间;假设并发比为2，则允许有2个核心并发请求和4个非核心业务接口的请求。
[0083]调度中心标记:messageDispatch
[0084]一个页面可能有几个调度中心，算法中会产生第二次和第三次的向调度中心发送数据，为了区分是来自于哪个调度中心，每次请求都会带上调度标记，调度标记用[调度器名-第几次请求]来标示；
[0085]用户发送请求:
[0086]用户打开浏览器上的页面后，向接口调度中心发送HTTP请求，报文实体中带有页面参数和参数messageDispatch = playerPage-l，这个值仅仅是表明是第一次请求播放页的调度中心。
[0087]S2和S3中将HTTP报文实体中的页面参数(如果有加密，要先解密后使用)放入到有依赖的接口的参数部分，并检查所有有依赖接口的队列(CoreDependList和AppendDependList)，并将拿到了所有必须参数的接口移出有依赖的接口队列(CoreDependList和AppendDependList)并移入到没有依赖的接口请求队列(CoreList，AppendList)，并改变接口请求状态由-1改为O。
[0088]具体地，如图2所示，S4包括:
[0089]S41.开启线程并行调度CoreList和AppendDependList中的未被调度过的接口 ；
[0090]S42.若获取响应，则判断是否为成功响应，若是，则将获得响应的接口的状态位state由I改为2，进行S43，若否，将获得响应的接口的状态位state由I改为3，直接停止所有用于接口调度的线程，直接返回HTTP响应:报文状态502服务器问题或307跳转到对应的页面；
[0091 ] S43.查询所述响应结果是否是CoreDependList和/或AppendDependList中的接口所需要的待定参数，如果是，则进行S44，否则，进行S46;
[0092] S44.用所述响应结果替代所述待定参数，并在所述待定参数已知的前提下，判断需要所述待定参数的接口是否能够直接被调度，若能，则将需要所述待定参数的接口的state有-1变为0，进行S45，否则，进行S46;
[0093 ] S 4 5.若需要所述待定参数的接口为核心接口，则将所述核心接口从有CoreDependList移至CoreList，若需要所述待定参数的接口为非核心接口，则将所述非核心接口 从 AppendDependList 移至 AppendList ；
[0094]S46.获得响应的线程继续调度CoreList和AppendList中的未被调度过的接口，直至CoreList中的全部接口均获得响应。
[0095]具体地，S4还包括获取未被调用的核心接口数量N与线程最大并发数tMax，S4中开启的线程的数量不大于tMax;若N不大于tMax，则并行调度的非核心接口数量和核心接口数量比值小于最大并发比，否则，先并行调度核心接口，并实时获取N值，当N小于tMax时，调度过程中满足并行调度的非核心接口数量和核心接口数量比值不大于最大并发比。
[0096]具体地，S4还包括开启并行线程之前，对CoreList、CoreDependList、AppendDependList和AppendList中的接口按照重要性进行排序，调度过程中依次对CoreList和AppendList中的未被调度过的接口进行调用。
[0097]S5中通过S4处理了所有的核心业务接口的并发和部分非核心业务的数据，如果AppendList中还有没有获得响应和响应失败的接口元素，把整个AppendList中没有响应和响应失败的元素的id和参数打成一个数据包并加密，同S4获取的数据一起打包，如果AppendList中的元素全部响应了也只发核心业务数据和请求过的非核心业务数据，下面列出发送到前端的数据内容:
[0098]a表示核心业务数据和请求过的非核心业务数据；
[0099]b表示来自于哪个调度中心的标记；
[0100]c表示未请求的非核心业务接口 id和未请求的非核心业务接口需要的数据构成的数据加密包。
[0101]S6中再次处理未响应的请求:
[0102]前端拿到数据后，展示S5发送到前台的a数据到页面，然后判定c中是否有数据，如果有读取b来自于哪个调度中心，再次将c的数据用AJAX发送回接口调度中心；
[0103]相应的调度中心获得了未请求的非核心业务接口id和未请求的非核心业务接口需要的数据加密包，将数据解密，发起并发进程来向剩余的接口发起请求，全部请求的状态变为非O的时候，表示拿到了所有的非核心业务的数据，将数据打包，发送到前端，如果有接口发送请求失败的(state状态为3的)非核心接口，将发送请求失败各个请求分别打包，加密，下面列出发送到前端的数据内容:
[0104]a表示请求过的非核心业务数据；
[0105]b表示来自于哪个调度中心的标记；
[0106]c表示失败的非核心业务接口加密包；
[0107]S7中再次处理未响应的请求:
[0108]拿到a中的非核心业务数据，展现在前端，如果上面的数据块c中有数据，分别向调度中心发起AJAX请求，获得响应数据，再展示到前端。
[0109]实施例2:
[0110]本实施例中使用nginx服务器:nginx服务器中有一个master，M个worker ,master控制worker ο
[0111]使用nginx服务器进行多接口数据的调度方法包括以下步骤:
[0112]S1.为接口分类，并将分类后的接口纳入相应的队列:
[0113]将能够被直接调度的核心接口纳入核心接口队列，
[0114]将不能够被直接调度的核心接口纳入有依赖核心接口队列，
[0115]将能够被直接调度的非核心接口纳入非核心接口队列，
[0116]将不能够被直接调度的非核心接口纳入有依赖非核心接口队列；
[0117]S2.获取HTTP请求中的页面参数；
[0118]S3.将所述页面参数作为接口所依赖的参数，更新有依赖核心接口队列、核心接口队列、非核心接口队列和有依赖非核心接口队列；
[0119]S4.对所述核心接口队列和非核心接口队列中的未被调度过的接口进行并发调用，并发调用的线程的数量由Memery为程序分配的进程内存、线程站的数量和worker的数量M决定；
[0120]S5.根据S4的调用结果，向前端发送数据；
[0121]S6.前端展示S5中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，则对所述非核心接口进行调用；
[0122]S7.向前端展示S6中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，继续对所述非核心接口进行调用，并将调度结果显示在前端。
[0123]具体地，更新有依赖核心接口队列、核心接口队列、非核心接口队列和有依赖非核心接口队列方法为:
[0124]S3中更新有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器包括:
[0125]在已知所述页面参数的前提下，遍历有依赖核心接口容器和有依赖非核心接口容器，
[0126]若有依赖核心接口容器中存在能够被直接调度的核心接口，则将能够被直接调度的核心接口移至所述核心接口容器，
[0127]若有依赖非核心接口容器中存在能够被直接调度的非核心接口，则将所述能够被直接调度的非核心接口移至所述非核心接口容器。
[0128]具体地，S4包括:
[0129]S41.开启线程并行调度所述核心接口容器和非核心接口容器中的未被调度过的接口；
[0130]S42.若获取响应，则判断是否为成功响应，若是，则进行S43，若否，则直接停止所有用于接口调度的线程，直接返回HTTP响应:报文状态502服务器问题或307跳转到对应的页面；
[0131]S43.将获取所述响应的接口标记为已调度接口，查询所述响应结果是否是有依赖核心接口容器和/或有依赖非核心接口容器中的接口所需要的待定参数，如果是，则进行S44，否则，进行S46;
[0132]S44.用所述响应结果替代所述待定参数，并在所述待定参数已知的前提下，判断需要所述待定参数的接口是否能够直接被调度，若能，则进行S45，否则，进行S46;
[0133]S45.若需要所述待定参数的接口为核心接口，则将所述核心接口从有依赖核心接口容器移至核心接口容器，若需要所述待定参数的接口为非核心接口，则将所述非核心接口从有依赖非核心接口容器移至非核心接口容器；
[0134]S46.获得响应的线程继续调度所述核心接口容器和非核心接口容器中的未被调度过的接口，直至全部核心接口均获得响应。
[0135]此外，S4还包括获取未被调用的核心接口数量N与线程最大并发数tMax，S4中开启的线程的数量不大于tMax ；若N不大于tMax，则并行调度的非核心接口数量和核心接口数量比值小于最大并发比，否则，先并行调度核心接口，并实时获取N值，当N小于tMax时，调度过程中满足并行调度的非核心接口数量和核心接口数量比值不大于最大并发比。
[0136]具体地，S5包括:
[0137]判断是否存在未获得响应和/或响应失败的非核心接口，若有，则将所述未获得响应和/或响应失败的非核心接口的元素与S4中获取的数据一起打包;否则，只打包S4中获取的数据；
[0138]将打包结果发送到前端。
[0139]具体地，所述元素包括未获得响应和/或响应失败的非核心接口的接口id和调度所述未获得响应和/或响应失败的非核心接口需要的参数。
[0140]具体地，所述有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器中的接口均包含表征所述接口状态的状态标识。
[0141]本实施例中，S4中通过HTTP请求进行接口调用，S5和S6中通过a jax进行接口调用。
[0142]此外，本实施例中:
[0143](I)所有请求写在一份文件中，所有接口调用清晰明了；
[0144](2)两个或多个非核心业务的接口调用时参数存在依赖关系时，先封装成一个接口再进行调用；
[0145](3)核心业务的接口的平均响应时间不小于非核心业务接口响应时间；
[0146](4)所有接口的响应时间在一个数量级，没有过慢接口的存在，过慢接口将强制使用过期时间；
[0147](5)接口的响应数据不超过3M数据。
[0148]实施例3:
[0149]第三个实施例，与第一个实施例的区别在于:
[0150]将所有接口的请求时间记录下来，如果接口请求失败将用一个非常大的响应时间表示接口调用失败，将所有的接口响应时间记录下来并做排序，这个排序是一个样本;统计至IJn个用户访问网站的接口排序样本后，将每个接口的响应时间取平均值，上报给管理员。如果网站访问量很大，可以用随机抽样的方式记录接口状态，只随机统计A%的样本作为统计量。
[0151 ]本实施例能够及时发现接口的问题，并优化响应慢的接口 ；若接口响应过慢，则把这个接口的状态直接置为3，让前台使用a jax进行调用。
[0152]实施例4:
[0153]第四个实施例，与第一个实施例区别在于:
[0154]对SI进行优化:
[0155]创建队列时，尽可能的将接口在同一台服务器上的请求放在一起，原因在于，当建立http请求的时候，可以在报文头中添加keep-al ive属性，并发时可以建立一次TCP数据传输通道，发送多个HTTP请求用来节约时间。
[0156]实施例5:
[0157]第五个实施例，与第一个实施例区别在于:
[0158]在不知道nginx的配置前提下，没有做反向代理的nginx的子进程本来就占了很大的资源，如果在拉起新进程一起抢资源拉中断，运维并不会允许开过多的进程;那么只能够使用线程；
[0159]1.多线程的优点:
[0160]对象和变量是共享的，可直接进行操作；
[0161]文件描述符是共享的，不同的线程可以对同一个资源直接进行操作；
[0162]2.多线程的缺点:
[0163]操作非局部变量时需要加锁，编程难度高；
[0164]—个线程发生内存错误，整个进程会全部结束。
[0165]然而，如果网站在某个时期接口经常不稳定，可能会发生调度过程中某线程中断从而导致整个调度进程中断，因此，对S4进行优化，优化方式为:
[0166](I)要求Nginx使用反向代理技术，将请求转发给多个网络服务器;在多个网络服务器上部署接口调度器；
[0167](2)后台改用多进程并发而不再使用多线程并发请求接口，这时候的调度器是一个父进程，并发的请求进程是其子进程，可以提高整个父进程的稳定性。
[0168]这种优化方式也有不足之处，进程消耗的内存过高，不考虑资源的可以用进程来替代线程实现接口并发。
[0169]实施例6:
[0170]第六个实施例，与第一个实施例的区别在于:
[0171 ]本实施例使用node.js实现并发拿到数据。
[0172]实施例7:
[0173]第七个实施例，与第一个实施例的区别在于:
[0174]本实施例使用nginx，nginx中有一个 mas ter ,M^hworker ,master 控制 worker。
[ΟΙ75]前台使用worker的!15新特性扩展a jax的并发量。
[0176]以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。
【主权项】
1.一种多接口数据的调度方法，包括对于处理核心业务的核心接口和处理非核心业务的非核心接口进行调度，其特征在于，包括以下步骤: 51.为接口分类，并将分类后的接口纳入相应的容器: 将能够被直接调度的核心接口纳入核心接口容器， 将不能够被直接调度的核心接口纳入有依赖核心接口容器， 将能够被直接调度的非核心接口纳入非核心接口容器， 将不能够被直接调度的非核心接口纳入有依赖非核心接口容器； 52.获取HTTP请求中的页面参数； 53.根据所述页面参数更新有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器； S4.对所述核心接口容器和所述非核心接口容器中的未被调度过的接口进行并发调用； 55.根据S4的调用结果，向前端发送数据； 56.前端展示S5中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，则对所述非核心接口进行调用； 57.向前端展示S6中接口的调用结果，并判断是否存在待处理的非核心接口，若存在，继续对所述非核心接口进行调用，并将调度结果显示在前端。2.根据权利要求1所述的一种多接口数据的调度方法，其特征在于，S3中更新有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器包括: 在已知所述页面参数的前提下，遍历有依赖核心接口容器和有依赖非核心接口容器， 若有依赖核心接口容器中存在能够被直接调度的核心接口，则将所述能够被直接调度的核心接口移至所述核心接口容器， 若有依赖非核心接口容器中存在能够被直接调度的非核心接口，则将所述能够被直接调度的非核心接口移至所述非核心接口容器。3.根据权利要求2所述的一种多接口数据的调度方法，其特征在于，S4包括: 541.开启线程并行调度所述核心接口容器和非核心接口容器中的未被调度过的接口； 542.若获取响应，则判断是否为成功响应，若是，则进行S43，若否，则直接停止所有用于接口调度的线程，直接返回HTTP响应:报文状态502服务器问题或307跳转到对应的页面； 543.将获取所述响应的接口标记为已调度接口，查询所述响应结果是否是有依赖核心接口容器和/或有依赖非核心接口容器中的接口所需要的待定参数，如果是，则进行S44，否贝1J，进行S46; 544.用所述响应结果替代所述待定参数，并在所述待定参数已知的前提下，判断需要所述待定参数的接口是否能够直接被调度，若能，则进行S45，否则，进行S46; 545.若需要所述待定参数的接口为核心接口，则将所述核心接口从有依赖核心接口容器移至核心接口容器，若需要所述待定参数的接口为非核心接口，则将所述非核心接口从有依赖非核心接口容器移至非核心接口容器； 546.获得响应的线程继续调度所述核心接口容器和非核心接口容器中的未被调度过的接口，直至全部核心接口均获得响应。4.根据权利要求3所述的一种多接口数据的调度方法，其特征在于，S4还包括获取未被调用的核心接口数量N与线程最大并发数tMax，S4中开启的线程的数量不大于tMax;若N不大于tMax，则并行调度的非核心接口数量和核心接口数量比值小于最大并发比，否则，先并行调度核心接口，并实时获取N值，当N小于tMax时，则调度过程中需满足并行调度的非核心接口数量和核心接口数量比值不大于最大并发比。5.根据权利要求3所述的一种多接口数据的调度方法，其特征在于，S4还包括开启并行线程之前，对所述核心接口容器和所述非核心接口容器中的接口按照重要性进行排序，调度过程中依次对所述核心接口容器和所述非核心接口容器中的未被调度过的接口进行调用。6.根据权利要求3所述的一种多接口数据的调度方法，其特征在于，S4还包括开启并行线程之前，对所述有依赖核心接口容器和所述有依赖非核心接口容器中的接口按照重要性进行排序。7.根据权利要求3所述的一种多接口数据的调度方法，其特征在于，S5包括: 判断是否存在未获得响应和/或响应失败的非核心接口，若有，则将所述未获得响应和/或响应失败的非核心接口的元素与S4中获取的数据一起打包;否则，只打包S4中获取的数据； 将打包结果发送到前端。8.根据权利要求7所述的一种多接口数据的调度方法，其特征在于，所述元素包括未获得响应和/或响应失败的非核心接口的接口 id和调度所述未获得响应和/或响应失败的非核心接口需要的参数。9.根据权利要求8所述的一种多接口数据的调度方法，其特征在于，所述有依赖核心接口容器、核心接口容器、非核心接口容器和有依赖非核心接口容器中的接口均包含表征所述接口状态的状态标识。10.根据权利要求1所述的一种多接口数据的调度方法，其特征在于，S4中通过HTTP请求进行接口调用，S5和S6中通过ajax进行接口调用。
【文档编号】H04L29/08GK105893160SQ201610474688
【公开日】2016年8月24日
【申请日】2016年6月24日
【发明人】史荣琦, 邢斐, 董京涛, 李明杰, 顾思斌, 潘柏宇, 谢菲
【申请人】合信息技术（北京）有限公司, 合一信息技术（北京）有限公司