网络服务的调度方法、装置、智能终端及存储介质与流程

1.本技术涉及互联网技术领域，特别是涉及一种网络服务的调度方法、装置、智能终端及存储介质。


背景技术：

2.在互联网发展的初期，后台网络架构几乎都是单体服务，也即所有业务逻辑都写在一个或几个后台进程中。然而，单体服务因存在有多人协作困难、故障无法隔离、不利于水平扩展的缺陷，随着互联网业务复杂度的越来越高，单体服务的缺陷慢慢被放大，而逐渐被一种新的微服务架构，也即将业务按照水平和垂直两个维度拆分成一个一个的小块，每一小块业务用一种服务进程来实现，进程与进程间通过网络通讯协作完成整体业务流程的网络架构所替代。
3.而随着微服务架构在互联网技术领域的发展和流行，通过微服务架构取代单体服务架构也逐渐成为主流，主要即是因为微服务架构切实的解决了单体服务多人协作困难、故障无法隔离、不利于水平扩展的问题。
4.但微服务架构同样也存在有一些缺陷：服务进程数量过多带来的高昂运维成本、多余的网络通讯对整体硬件性能的浪费、请求响应时延较高。
5.随着摩尔定律失效，硬件性能提升进入瓶颈，互联网用户群体爆炸式的增长，导致各大互联网公司后台服务器的数量越来越多，有些公司甚至达到数十万台的规模。在这样的体量背景下，微服务架构对硬件性能的浪费所带来的额外成本开销已变得非常庞大。
6.且随着互联网行业的突飞猛进，激烈的竞争环境让业务复杂度不得不更进一步提高，导致了各大互联网公司后台的微服务进程数量爆炸式增长，运维工作难度越来也高，运维成本也越来越高。


技术实现要素：

7.本技术主要解决的技术问题是提供一种网络服务的调度方法、装置、智能终端及存储介质，以解决现有技术中单体服务存在多人协作困难、故障无法隔离、不利于水平扩展的问题，而微服务架构存在服务进程数量过多带来的高昂运维成本、多余的网络通讯对整体硬件性能的浪费、请求响应时延较高的问题。
8.为了解决上述问题，本技术第一方面提供了一种网络服务的调度方法，其中，该网络服务的调度方法包括：启动至少一个引擎进程，并加载至少一个业务流程函数；将业务流程函数确定为父业务流程函数，并将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中；将子业务流程函数确定为父业务流程函数，重复执行将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中的步骤，直至形成的单体服务的网络业务不符合设定条件；运行单体服务的网络业务。
9.其中，启动至少一个引擎进程，并加载至少一个业务流程函数之前，还包括：获取满足标椎接口规范的初始代码；将初始代码构建为可执行的业务流程函数。
10.其中，将初始代码构建为可执行的业务流程函数，包括：对初始代码进行源码解析，以获取初始代码的函数名和函数签名，并对应生成具有固定签名的初始函数；将初始函数追加至初始代码的源码末端，得到初加工源代码；将初加工源代码编译为可执行的字节码形式的业务流程函数，并保存至数据库中。
11.其中，启动至少一个引擎进程，并加载至少一个业务流程函数，包括：从数据库中下载至少一个业务流程函数，以将业务流程函数加载至对应启动的至少一个引擎进程中。
12.其中，将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中，包括：根据每一业务流程函数的网络地址，将在稳定调用关系中处于被调用关系的至少一个子业务流程函数加载至对应处于调用关系的父业务流程函数的引擎进程中。
13.其中，加载至引擎进程中的业务流程函数的数量为至少两个，启动至少一个引擎进程，并加载至少一个业务流程函数之后，将业务流程函数确定为父业务流程函数，并将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中之前，包括：获取每一业务流程函数调用其他业务流程函数的调用关系数据；基于调用关系数据将至少两个业务流程函数对应形成为调用关系树；其中，调用关系树包括至少一条调用链，每一调用链最上游的业务流程函数为调用关系树的根节点，位于每一调用链下游的业务流程函数为调用关系树的子节点；将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中，包括：遍历调用关系树中的每一业务流程函数，以将至少一个子节点对应的子业务流程函数加载到与其对应的根节点对应的父业务流程函数的引擎进程中。
14.其中，在引擎进程中被调用次数较多的调用关系树的子节点位于的调用关系树的根节点的其中一侧，被调用次数较少的调用关系树的子节点位于的调用关系树的根节点的相对另一侧。
15.其中，直至形成的单体服务的网络业务不符合设定条件，包括：直至形成的单体服务的网络业务达到单进程的负载上限。
16.其中，网络服务的调度方法应用于处理器，处理器与服务器集群中的每一服务器均通信连接，至少一个引擎进程运行在服务器上，启动至少一个引擎进程，并加载至少一个业务流程函数，包括：获取服务器集群中每一服务器的资源占用率；其中，资源占用率为服务器的使用率；在服务器集群中资源占用率低于第一预设资源占用率的服务器上启动至少一个引擎进程，并加载至少一个业务流程函数。
17.其中，网络服务的调度方法还包括：将运行在服务器集群中资源占用率超过第二预设资源占用率的服务器上的部分引擎进程迁移至其他服务器，并保证服务器集群中的每一服务器的资源占用率均低于第一预设资源占用率；其中，第二预设资源占用率大于第一预设资源占用率。
18.其中，网络服务的调度方法还包括：在服务器集群中的每一服务器的资源占用率均低于第三预设资源占用率时，将其中资源占用率最小的服务器上运行的所有引擎进程均迁移至其他服务器上。
19.其中，在服务器集群中资源占用率低于第一预设资源占用率的服务器上启动至少一个引擎进程对应加载每一业务流程函数，之后还包括：根据每一服务器的资源占用率对服务器集群中的每一服务器进行排序；在排名后10％的任一服务器上启动至少一个引擎进程，并加载每一新获取的业务流程函数。
20.为了解决上述问题，本技术第二方面提供了一种网络服务的调度装置，其中，该网络服务的调度装置包括：处理模块，用于启动至少一个引擎进程，并加载至少一个业务流程函数；调度模块，用于将业务流程函数确定为父业务流程函数，并将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中，以将子业务流程函数确定为父业务流程函数，重复执行将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中的步骤，直至形成的单体服务的网络业务不符合设定条件；运行模块，用于运行单体服务的网络业务。
21.为了解决上述问题，本技术第三方面提供了一种智能终端，其中，该智能终端包括相互耦接的存储器和处理器，处理器用于执行存储器中存储的程序指令，以实现上述第一方面的网络服务的调度方法。
22.为了解决上述问题，本技术第四方面提供了一种计算机可读存储介质，其上存储有程序指令，程序指令被处理器执行时，实现上述第一方面的网络服务的调度方法。
23.本发明的有益效果是：区别于现有技术的情况，本技术的网络服务的调度方法在启动至少一个引擎进程，并加载至少一个业务流程函数后，通过将业务流程函数确定为父业务流程函数，并将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中，进而将子业务流程函数确定为父业务流程函数，并重复执行将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中的步骤，直至形成的单体服务的网络业务不符合设定条件，从而能够依次将分属于不同引擎进程中的具有调用关系的子、父业务流程函数调取到同一引擎进程中，也便能够将子、父业务流程函数之间的网络通讯转变为进程内通讯，以能够对应将微服务的网络业务转换为单体服务的网络业务进行运行，从而有效降低了网络运维服务的成本，且降低了网络通讯对整体硬件性能的浪费，相应的请求响应时延也得以降低。
附图说明
24.图1是本技术网络服务的调度方法第一实施例的流程示意图；
25.图2是网络管理平台一实施例的框架示意图；
26.图3是图1中s11一实施例的流程示意图；
27.图4是本技术网络服务的调度方法第二实施例的流程示意图；
28.图5是图4中s22一实施例的流程示意图；
29.图6是本技术网络服务的调度方法第三实施例的流程示意图；
30.图7是本技术网络服务的调度装置一实施例的框架示意图；
31.图8是本技术智能终端一实施例的框架示意图；
32.图9是本技术计算机可读存储介质一实施例的框架示意图。
具体实施方式
33.发明人经长期研究发现，在互联网发展的初期，后台架构几乎都是单体服务：所有业务逻辑都写在一个或几个后台引擎进程中。
34.单体服务的优势是硬件性能有极高的利用率、请求响应时延极低，缺陷是多人协作困难、故障无法隔离、不利于水平扩展。
35.早年间摩尔定律依然生效，硬件性能不断翻倍、互联网业务复杂度也越来越高，单体服务的优势越来越不明显，缺陷慢慢被放大。直至微服务架构的大规模推广，也即将业务按照水平和垂直两个维度拆分成一个一个的小块，每一小块业务用一种服务进程来实现，进程与进程间通过网络通讯协作完成整体业务流程网络服务架构。
36.随着微服务架构在业内流行了十几年，微服务架构逐渐取代单体服务架构成为主流，主要还是因为它切实解决了单体服务的一些痛点。
37.微服务架构的优势是极为高效的多人协作、故障范围可控、极易水平扩展，但同样也有着一些缺陷：服务进程数量过多带来的高昂运维成本、多余的网络通讯对整体硬件性能的浪费、请求响应时延较高。
38.而随着摩尔定律失效，硬件性能提升进入瓶颈，但互联网用户群体爆炸式的增长，导致各大互联网公司后台服务器的数量越来越多，有些公司甚至达到数十万台的规模。在这样的体量背景下，微服务架构对硬件性能的浪费所带来的额外成本开销已经非常可观。
39.再往后互联网行业突飞猛进，激烈的竞争环境让业务复杂度不得不更进一步提高，导致了各大互联网公司后台的微服务进程数量爆炸式增长，运维工作难度越来也高，运维成本也越来越高。
40.2014年左右部分大型互联网公司提出了“服务治理”的概念：用一套或多套极为复杂的系统来帮助运维和开发人员完成梳理服务间的关系、采集日志与调用数据、产出数据报表、自动化报告故障、分析故障链路等工作，从而减轻人治的负担。这通常需要投入几十位甚至几百位开发人员来完成这项开发工作，并长期从事相关维护工作，成本极为高昂，效果也不尽理想。
41.同时，大型互联网公司还上线了lambda(匿名函数)：一个serverless(无服务器)开发平台；让后台服务在“拆”的路上更进一步，拆分到了函数级。serverless提出的noops(无运维)策略解决了运维难的问题，但是lambda的实现方式带来了更加严重的“组合”问题：函数与函数间很难交互，无法形成合力完成复杂业务逻辑。这并不是lambda的开发者不够聪明，而是lambda作为一个商业项目，最开始的业务定位就在“简单业务”、“业务粘合剂”方面，瞄准的是“非专业后台开发者”开发简单后台业务的需求。虽然serverless没有解决微服务的痛点，反而成为了微服务架构的一部分，但让我们从中看到了一丝希望。
42.为了解决微服务架构存在服务进程数量过多带来的高昂运维成本、多余的网络通讯对整体硬件性能的浪费、请求响应时延较高的问题，本技术提供了一种网络服务的调度方法。下面结合附图和实施例，对本技术作进一步的详细描述。特别指出的是，以下实施例仅用于说明本技术，但不对本技术的范围进行限定。同样的，以下实施例仅为本技术的部分实施例而非全部实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本技术保护的范围。
43.在本技术中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
44.请参阅图1，图1是本技术网络服务的调度方法第一实施例的流程示意图。具体而言，可以包括如下步骤：
45.s11：启动至少一个引擎进程，以加载至少一个业务流程函数，并将业务流程函数确定为父业务流程函数。
46.随着微服务架构的快速发展，基于微服务架构的网络服务逐渐取代单体服务架构成为主流。其中，对于互联网公司而言，在不改变微服务架构极度高效的多人协作、故障范围可控、极易水平扩展的前提下，如何解决服务进程数量过多带来的高昂运维成本、多余的网络通讯对整体硬件性能的浪费、请求响应时延较高的问题，这是影响互联网公司运营成本的一个关键点，也是影响用户享受网络服务的一个关键因素，这一因素也极大地影响了互联网平台的发展。
47.可理解的，引擎(engine)是电子平台上开发程序或系统的核心组件。利用引擎，开发者可迅速建立、铺设程序所需的功能，或利用其辅助程序的运转。
48.而进程(process)是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。程序是指令、数据及其组织形式的描述，进程是程序的实体。
49.业务流程函数是指能够对应完成网络业务的程序函数，也即脚本(script，是使用一种特定的描述性语言，依据一定的格式编写的可执行文件)，以在提交给后台服务器后，能够自动构建生成可执行体。且当函数被外部调用时，服务器将按需启动一个或多个引擎进程加载对应的函数，以对外提供服务。
50.在本实施例，该引擎进程具体是指运行在服务器上的对应于各种类型的微服务架构的网络业务。
51.具体地，在服务器上启动至少一个引擎进程，以对应将当前需要提供网络服务所对应的至少一个业务流程函数依次加载至一个或多个不同的引擎进程中。
52.需说明的是，在一个或多个引擎进程中添加业务流程函数具体是依据相应的网络业务请求的顺序而逐步累加的，且基于微服务架构的特征，网络业务将按照水平和垂直两个维度被拆分成一个一个的小块，每一小块业务用一种服务进程，也即引擎进程来实现，进程与进程间通过网络通讯协作完成整体业务流程。
53.因此，对于大量的用户来说，可能会在同一时段对服务器发出大量同类的网络请求任务，比如，向同一家网购店请求购买不同的商品，从而使得大量的不同业务流程函数可能存在有其中至少两个彼此处于稳定调用关系的业务流程函数，但分属于不同的引擎进程中的情况产生。
54.其中，为有效减少依次启动的引擎进程数量过多而带来的高昂运维成本、多余的网络通讯对整体硬件性能的浪费、请求响应时延较高的问题，在本实施例中，具体是将首先加入引擎进程中的业务流程函数确定为父业务流程函数。
55.s12：将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中。
56.进一步地，在一引擎进程中加载了一业务流程函数，并将该业务流程函数确定为父业务流程函数后，可依据该父业务流程函数与后续依次添加的业务流程函数之间可能存在的调用关系，将处于该父业务流程函数的调用下游的子业务流程函数依次加载到该引擎进程中，以避免重新启动另一引擎进程加载该子业务流程函数。
57.需说明的是，该父业务流程函数与其对应的子业务流程函数具体可理解为，处于稳定的调用上、下游关系的两业务流程函数，且子业务流程函数处于被调用关系。
58.而在将子业务流程函数依次加载到父业务流程函数的引擎进程中的过程中，即可将原本需启动不同引擎进程，以分别加载父业务流程函数和子业务流程函数的微服务架构转换为一个单体服务，而仅对应启动一个引擎进程即可，也便能够将原本需要网络通讯，以用于不同引擎进程之间的调度通信转变为进程内通信，从而有效降低了网络运维服务的成本，且降低了网络通讯对整体硬件性能的浪费，相应的请求响应时延也得以降低。
59.s13：判断引擎进程形成的单体服务的网络业务是否符合设定条件。
60.可理解的，受单引擎进程能够容纳的业务流程函数的负载容量限制，在依次将至少一个子业务流程函数加载到其对应的父业务流程函数的引擎进程中，以形成单体服务后，还需判断该单体服务的网络业务是否符合设定条件，比如，确定该单体服务的网络业务是否达到单进程负载上限；或，是否在设定时间内未查询到或不存在相应的子业务流程函数；或，对应形成的该单体服务的网络业务是否达到单进程处理器、内存、带宽的任一或多个因素的容纳上限等任一合理的场景设定，本技术对此不做限定。
61.其中，如果引擎进程形成的单体服务的网络业务不符合设定条件，则执行s14，如果引擎进程形成的单体服务的网络业务符合设定条件，则执行s15。
62.s14：将子业务流程函数确定为父业务流程函数。
63.具体地，在将子业务流程函数加载到其对应的父业务流程函数的引擎进程中后，且该引擎进程形成的单体服务的网络业务还不符合设定条件时，还能够将该子业务流程函数确定为父业务流程函数，以进而能够将后续处于被调用关系，也即更下游的子业务流程函数也加载到该引擎进程中，且在执行s14之后，需重复执行s13，直至相应形成的单体服务的网络业务不符合设定条件时终止。
64.s15：运行单体服务的网络业务。
65.具体地，在相应形成的单体服务的网络业务符合设定条件后，则可对应运行该单体服务的网络业务，以向用户提供相应的网络服务。
66.可理解的，在后续仍需要加载业务流程函数时，则可再启动一引擎进程，以进行业务流程函数的加载。
67.由此可知，开发者具体能够按照约定的标准格式编写多个相互协作完成的业务流程函数(也可以称为脚本)，以分别提交至后台服务器系统，并由后台服务器系统自动构建生成可执行体。而当业务流程函数被外部调用时，服务器将按需启动一个或多个引擎进程加载对应的业务流程函数，以对外提供服务。
68.且当业务流程函数与业务流程函数之间的调用关系相对稳定时，处于调用关系上游的引擎进程即可额外加载处于调用关系下游的函数到同一个引擎进程内，并将两个业务流程函数的通讯方式从网络通讯变为进程内通讯，重复这一步骤，就可以将整条调用链路上的所有函数全部加载到同一个(或少量几个)引擎进程中，而组成一个巨型的单体服务。由于这样的单体服务是由调度系统智能组装而成，在开发者的代码库中不存在这样的服务，因此，在本技术中，可称之为“虚拟服务”，而由上述系统组成的架构，我称之为“虚拟服务架构”。
69.其中，在开发阶段，由于代码单元拆分的粒度足够细，多人协作方面的成本极低，
同时不必学习开发框架，开发的成本比微服务架构更低。由于是运行时组装代码，多语言协作也变得十分简单。
70.在运行时，虚拟服务作为一个容纳了整个调用链的单体服务，有着传统单体服务架构一样的高性能和超低的响应延迟。
71.在运维层面，智能的调度系统可以按需自动启动、关闭引擎进程，真正实现noops(无运维)，开发者不必关系部署问题，从而能够降低心智负担，运维人力成本也不再和服务数量呈正相关。
72.因此，虚拟服务架构能够解决目前业内流行的微服务架构的运维成本高、硬件性能浪费、请求响应时延高等一系列问题，有望替代微服务架构成为新一代互联网后台架构。
73.上述方案，通过将业务流程函数确定为父业务流程函数，并将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中，进而将子业务流程函数确定为父业务流程函数，并重复执行将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中的步骤，直至形成的单体服务的网络业务不符合设定条件，从而能够依次将分属于不同引擎进程中的具有调用关系的子、父业务流程函数调取到同一引擎进程中，也便能够将子、父业务流程函数之间的网络通讯转变为进程内通讯，以能够对应将微服务的网络业务转换为单体服务的网络业务进行运行，从而有效降低了网络运维服务的成本，且降低了网络通讯对整体硬件性能的浪费，相应的请求响应时延也得以降低。
74.在一个具体的实施例中，如图2所示，图2是网络管理平台一实施例的框架示意图。上述引擎进程具体是通过执行引擎来启动运行，其中，该执行引擎具体是用来加载、运行函数的载体，而由四个主要模块构成：网络通讯模块、虚拟机、路由模块、管理模块。
75.且该网络通讯模块、管理模块、路由模块，具体可选用一个微服务框架，其中，网络通讯模块和路由模块用于通过网络通讯调用上、下游的业务流程函数，管理模块用于处理发送到执行引擎的用户请求，以对应使执行引擎装载一个新的业务流程函数进来，以装载或卸载业务流程函数。而虚拟机采用开源的llvm(low level virtual machine，底层虚拟机)项目中提供的虚拟机，就可以满足c++语言方面的字节码加载运行需求，以用于业务流程函数的下载和执行。
76.如图2所示，通过该引擎进程对应实现的网络服务的调度方法即可对应于图2中的构造函数过程，以进而能够被网络管理平台的其他各功能单元，比如，构建服务、路由服务、节点管理、负载服务、调度服务等进行相应的调度、处理，以进行满足用户的网络业务需求。
77.请结合参阅图3，图3是图1中s11一实施例的流程示意图。在一实施例中，本技术的网络服务的调度方法除了包括上述s11
‑
s15之外，还进一步包括一些更为具体的步骤。具体地，上述s11具体还可以包括如下步骤：
78.s111：获取服务器集群中每一服务器的资源占用率。
79.可理解的，本技术的网络服务的调度方法具体应用于处理器，而该处理器可理解为后台调度系统的控制中枢，且该处理器与服务器集群中的每一服务器均通信连接，而至少一个引擎进程运行在服务器上。
80.需说明的是，当用户请求到来时，需要由资源调度系统在已有的机器池(服务器集群)中选到一个合适的位置(服务器)启动一个执行引擎进程来加载、运行对应的业务流程函数。那么，怎么选到一个合适的位置，这就是资源调度系统的算法要解决的核心问题之
一。
[0081]“选位置”是一个看似简单实则非常复杂的问题：最先需要满足的一个条件就是不能超过单机cpu(central processing unit，中央处理器)核数上限和内存负载上限，同时机器的磁盘容量、磁盘接口、cpu
‑
loadaverage(cpu平均负载)、网卡带宽等各项资源都需要通盘考量，其次要考虑“选位置”这个操作的并发问题；最后还需要在“机器的负载均衡”与“机器池总成本”两者之间做权衡。
[0082]
另外，“选位置”是一个有着时间维度的问题，当前选中的最优解，在一段时间以后可能就不再是最优解，甚至可能会变成一个很差的解。所以还要需要考虑如何把慢慢变差的解，重新调整为较优的解。
[0083]
具体地，获取当前提供网络业务服务的服务器集群中每一服务器的资源占用率。
[0084]
其中，该资源占用率具体可理解为服务器的使用率，也即有多少用于运行引擎进程的运算资源被使用。
[0085]
s112：在服务器集群中资源占用率低于第一预设资源占用率的服务器上启动至少一个引擎进程，并加载至少一个业务流程函数。
[0086]
可理解的，为保证服务器启动相应引擎进程后，能够运行顺畅，可为服务器集群中的每一服务器设定一条单机负载安全线，以能够基于该单机负载安全线确定当前需使用哪一服务器对应启动当前的引擎进程。
[0087]
其中，该负载安全线需满足1个稳定性要求：单机负载低于安全线时，业务可以稳定运行；该负载安全线还需满足1个经济性要求：负载安全线通常决定了整个集群的资源使用率上限。
[0088]
具体地，在获取到服务器集群中每一服务器的资源占用率后，即可确定需对应在其中资源占用率低于第一预设资源占用率的服务器上启动至少一个引擎进程，进而在引擎进程中加载至少一个业务流程函数。
[0089]
由此可知，该第一预设资源占用率即为单机负载安全线，以能够在服务器的某项负载超过安全线时，不再分配新的引擎进程到该服务器上。
[0090]
可选地，该第一预设资源占用率为0.8、0.85或0.9等任一合理的数，本技术对此不做限定。
[0091]
进一步地，在一实施例中，在上述s112中，具体还可以包括：将运行在服务器集群中资源占用率超过第二预设资源占用率的服务器上的部分引擎进程迁移至其他服务器，并保证服务器集群中的每一服务器的资源占用率均低于第一预设资源占用率。
[0092]
可理解的，在为每一服务器设定一条单机负载安全线后，还需为各项资源，也即各服务器设定一条单机负载迁移线，也即第二预设资源占用率，比如：cpu使用率设定在0.95。当服务器的某项负载超过迁移线时，要选出一些引擎进程迁移到其他服务器上：在其他服务器上启动新的引擎进程，并关闭该服务器上的同类引擎进程，同时修改路由数据把请求路由到新的引擎进程。直到该服务器的负载低于安全线，也即第一预设资源占用率时，停止进程迁移工作，从而保证服务器集群中的每一服务器的资源占用率均低于第一预设资源占用率。
[0093]
其中，该迁移线必须高于安全线，也即第二预设资源占用率大于第一预设资源占用率，且还需满足2个稳定性要求：首先安全线以上、迁移线以下的缓冲区能够给业务负载
留出一定的波动空间，避免频繁而不必要的迁移；其次在业务向上波动时，迁移线以上的缓冲区能够给系统预留出一定的调度时间；
[0094]
可选地，第二预设资源占用率比第一预设资源占用率大0.3、0.5或0.6等任一合理的数，本技术对此不做限定。
[0095]
可选地，第二预设资源占用率为0.93、0.95或0.96等任一合理的数，本技术对此不做限定。
[0096]
进一步地，在一实施例中，在上述s112中，具体还可以包括：在服务器集群中的每一服务器的资源占用率均低于第三预设资源占用率时，将其中资源占用率最小的服务器上运行的所有引擎进程均迁移至其他服务器上。
[0097]
可理解的，为合理的使用服务器集群中的每一服务器，还可以为各项资源设定一条集群缩容线，也即第三预设资源，比如：cpu使用率设定在0.4。而当服务器集群中的每一服务器的总使用率都低于集群缩容线时，即可选择其中最轻载的一台服务器，以将该服务器上的引擎进程全部迁移到其他服务器上，并将该服务器退还给供应商。
[0098]
其中，缩容线决定了服务器集群的资源利用率下限，且集群缩容不是仅可以通过划线的方式来触发，也有着更多更优的方式来触发，本技术对此不做限定。
[0099]
可选地，该缩容线，也即第三预设资源为0.35、0.4或0.45等任一合理的数，本技术对此不做限定。
[0100]
进一步地，在一实施例中，上述s13具体还可以包括：根据每一服务器的资源占用率对服务器集群中的每一服务器进行排序；在排名后10％的任一服务器上启动至少一个引擎进程，并加载每一新获取的业务流程函数。
[0101]
可理解的，为规避可能存在的服务器并发的问题，在用户请求到来时，还能够根据每一服务器的资源占用率对服务器集群中的每一服务器进行排序，以在排名后10％的任一服务器上启动至少一个引擎进程，并加载每一新获取的业务流程函数；或，将负载处于安全线以下的服务器，按照剩余资源做排序，以在排名前10％的服务器中随机选择一个服务器启动引擎进程，以加载每一新获取的业务流程函数。
[0102]
请参阅图4，图4是本技术网络服务的调度方法第二实施例的流程示意图。本实施例的网络服务的调度方法是图1中的视频播放方法的一细化实施例的流程示意图，包括如下步骤：
[0103]
s21：获取满足标椎接口规范的初始代码。
[0104]
可理解的，在业务流程函数的开发阶段，通过本技术的网络服务的调度方法提供的网络服务，由于代码单元拆分的粒度足够细，在多人协作方面的成本极低，同时不必学习开发框架，开发的成本比微服务架构更低。且因是运行时组装代码，多语言协作也变得十分简单。
[0105]
但也因为需考虑多语言协作的开发场景，因而需对构建得到相应业务流程函数的初始代码进行规范化。比如，通过向每一开发者下发标准化的接口规范，以保证在后续从该开发者处获取的初始代码能够满足相应的标椎接口规范。
[0106]
可理解的，该标椎接口规范具体是指初始代码对应的业务流程函数的函数签名、参数类型、返回值类型、兼容性升级都必须遵守jce(java cryptography extension，数据代码)协议规范(也可以选择其他跨语言的通讯协议)，这是函数间可以简洁通讯的基石。
[0107]
例如：
[0108][0109]
这是一个最简单的、符合规范的c++函数，完成了“乘以2”的功能，可以直接提交到构建系统中进行构建，导出一个名为multi2的函数，可以被其他函数或外部调用。
[0110]
此时可以再编写另一个函数来调用它：
[0111][0112]
上述函数完成了“乘以4”的功能，且提交到构建系统中进行构建后会导出一个名为multi4的函数，multi4与multi2两个函数组成了一个调用链，共同协作完成用户请求。
[0113]
s22：将初始代码构建为可执行的业务流程函数。
[0114]
进一步地，在获取到的初始代码满足标椎接口规范时，即可将该初始代码构建为可执行的业务流程函数。
[0115]
s23：启动至少一个引擎进程，以加载至少一个业务流程函数，并将业务流程函数确定为父业务流程函数。
[0116]
s24：将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中。
[0117]
s25：判断引擎进程形成的单体服务的网络业务是否符合设定条件。
[0118]
s26：将子业务流程函数确定为父业务流程函数。
[0119]
s27：运行单体服务的网络业务。
[0120]
其中，s23、s24、s25、s26以及s27与图1中的s11、s12、s13、s14以及s15相同，具体请参阅s11、s12、s13、s14以及s15及其相关的文字描述，在此不再赘述。
[0121]
请结合参阅图5，图5是图4中s22一实施例的流程示意图。具体地，上述s22具体还可以包括如下步骤：
[0122]
s221：对初始代码进行源码解析，以获取初始代码的函数名和函数签名，并对应生成具有固定签名的初始函数。
[0123]
可理解的，为将开发者提供的初始代码构建成相应的可执行体，还需对该初始代码进行加工，比如，对初始代码进行源码解析，以获取初始代码的函数名和函数签名，并基于该初始代码对应生成具有固定签名的初始函数。
[0124]
为方便理解，在一实施例中，例如，上述的multi2函数代码提交后，可首先根据“c++语法标准”做源码解析，生成ast，找出导出的函数名和函数签名，以生成一个名为export_multi2的固定签名的函数：
[0125][0126]
s222：将初始函数追加至初始代码的源码末端，得到初加工源代码。
[0127]
进一步地，在得到具有固定签名的初始函数后，将该初始函数追加至初始代码的源码末端，以得到初加工源代码，从而能够提供给外部调用。
[0128]
s223：将初加工源代码编译为可执行的字节码形式的业务流程函数，并保存至数据库中。
[0129]
又进一步地，为使得该初加工源代码能够被服务器的虚拟机加载执行，还需将初加工源代码编译为可执行的字节码形式的业务流程函数，以保存至服务器的数据库中，等待调取、加载。
[0130]
进一步地，在一实施例中，上述s23具体还可以包括：从数据库中下载至少一个业务流程函数，以将业务流程函数加载至对应启动的至少一个引擎进程中。
[0131]
可理解的，在将业务流程函数保存至数据库中后，当服务器获取到相应的用户请求时，即可从该数据库中下载相应的至少一个业务流程函数，并将该业务流程函数加载至对应启动的至少一个引擎进程中。
[0132]
进一步地，在一实施例中，上述s24具体还可以包括：根据每一业务流程函数的网络地址，将在稳定调用关系中处于被调用关系的至少一个子业务流程函数加载至对应处于调用关系的父业务流程函数的引擎进程中。
[0133]
可理解的，当服务器中存在有调用关系的多个业务流程函数已依次被加载至多个不同的引擎进程中后，则可知，不同的引擎进程具体是通过网络通信的方式实现通讯，因而会对应具有不同的网络地址，服务器能够根据每一业务流程函数的网络地址，将在稳定调用关系中处于被调用关系的至少一个子业务流程函数加载至对应处于调用关系的父业务流程函数的引擎进程中，以将二者对应的网络通信的方式转变为进程内通信，从而能够有效降低后续请求响应的时延。
[0134]
请参阅图6，图6是本技术网络服务的调度方法第三实施例的流程示意图。本实施例的网络服务的调度方法是图1中的视频播放方法的一细化实施例的流程示意图，包括如下步骤：
[0135]
s31：启动至少一个引擎进程，以加载至少两个业务流程函数。
[0136]
具体地，在服务器上启动至少一个引擎进程后，以对应将当前需要提供网络服务的至少两个业务流程函数依次加载至当前已启动的一个或多个不同的引擎进程中。
[0137]
s32：获取每一业务流程函数调用其他业务流程函数的调用关系数据。
[0138]
进一步地，在加载至少两个业务流程函数至引擎进程中后，为减少引擎进程的启动数量，具体可以获取每一业务流程函数调用其他业务流程函数的调用关系数据。
[0139]
可理解的，该调用关系数据即是其中每一业务流程函数与其他业务流程函数之间具体处于调用链的上、下游位置信息，也即是处于调用还是被调用关系的数据信息。
[0140]
s33：基于调用关系数据将至少两个业务流程函数对应形成为调用关系树。
[0141]
又进一步地，在获取到调用关系数据后，为理清，或更鲜明的显示出每一业务流程函数对应的调用关系，即可根据该调用关系数据将至少两个业务流程函数对应形成为调用关系树，也即按照调用链的上、下游关系将至少两个业务流程函数对应汇总成至少一个树形结构。
[0142]
其中，该调用关系树包括至少一条调用链，而每一调用链最上游的业务流程函数为调用关系树的根节点，位于每一调用链下游的业务流程函数为调用关系树的子节点；
[0143]
也即，每条调用链即是依据调用关系依次连接的至少两个业务流程函数，而每条调用链的最上游作为调用关系树的根节点，下游作为上游的子节点。
[0144]
可理解的，该调用关系树的根节点具体可对应于父业务流程函数，而对应于该根节点的子节点即对应为相应的子业务流程函数。
[0145]
s34：遍历调用关系树中的每一业务流程函数，以将至少一个子节点对应的子业务流程函数加载到与其对应的根节点对应的父业务流程函数的引擎进程中。
[0146]
可理解的，在基于调用关系数据对应形成调用关系树后，为减少服务器中实际启动的引擎进程的总数量，便能够遍历调用关系树中的每一业务流程函数，以进而依次将每一子节点所对应的子业务流程函数加载到与其对应的根节点所对应的父业务流程函数的引擎进程中。
[0147]
其中，所谓遍历(traversal)，是指沿着某条搜索路线，依次对树(或图)中每个节点均做一次访问。访问结点所做的操作依赖于具体的应用问题，具体的访问操作可能是检查节点的值、更新节点的值等。不同的遍历方式，其访问节点的顺序是不一样的。
[0148]
需说明的是，对其中的每一颗调用关系树进行遍历，具体是从根节点开始，做广度优先遍历，以累加每一业务流程函数的所需资源(cpu、内存、带宽等)，直到触达单引擎进程负载的上限，将遍历过的业务流程函数都装载到根节点所对应的父业务流程函数所在的引擎进程中。而未完成遍历的节点作为新的根，重复上述步骤，直至整棵调用关系树都遍历完成。
[0149]
s35：判断引擎进程形成的单体服务的网络业务是否符合设定条件。
[0150]
s36：将子业务流程函数确定为父业务流程函数。
[0151]
s37：运行单体服务的网络业务。
[0152]
其中，s35、s36以及s37与图1中的s13、s14以及s15相同，具体请参阅s13、s14以及s15及其相关的文字描述，在此不再赘述。
[0153]
进一步地，在一实施例中，在上述s33中，具体还可以包括：在引擎进程中被调用次数较多的调用关系树的子节点位于的调用关系树的根节点的其中一侧，被调用次数较少的调用关系树的子节点位于的调用关系树的根节点的相对另一侧。
[0154]
可理解的，为对调用次数不同的业务流程函数加以区分，以确定加载至引擎进程中的优先级，在对应形成调用关系树的过程中，还能够将在引擎进程中被调用次数较多的子节点形成在调用关系树的根节点的其中一侧，而将被调用次数较少的调用关系树的子节点形成于调用关系树的根节点的相对另一侧，比如，调用次数多的放在左边，调用次数少的
放在右边，以此类推直至调用链的最末端，以组成相应的调用关系树。
[0155]
请参阅图7，图7是本技术网络服务的调度装置一实施例的框架示意图。该网络服务的调度装置41包括：处理模块411，用于启动至少一个引擎进程，并加载至少一个业务流程函数；调度模块412，用于将业务流程函数确定为父业务流程函数，并将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中，以将子业务流程函数确定为父业务流程函数，重复执行将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中的步骤，直至形成的单体服务的网络业务不符合设定条件；运行模块413，用于运行单体服务的网络业务。
[0156]
上述方案，通过将业务流程函数确定为父业务流程函数，并将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中，进而将子业务流程函数确定为父业务流程函数，并重复执行将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中的步骤，直至形成的单体服务的网络业务不符合设定条件，从而能够依次将分属于不同引擎进程中的具有调用关系的子、父业务流程函数调取到同一引擎进程中，也便能够将子、父业务流程函数之间的网络通讯转变为进程内通讯，以能够对应将微服务的网络业务转换为单体服务的网络业务进行运行，从而有效降低了网络运维服务的成本，且降低了网络通讯对整体硬件性能的浪费，相应的请求响应时延也得以降低。
[0157]
在一些实施例中，调度模块412具体还可以用于：获取满足标椎接口规范的初始代码；将初始代码构建为可执行的业务流程函数。
[0158]
在一些实施例中，调度模块412具体还可以用于：对初始代码进行源码解析，以获取初始代码的函数名和函数签名，并对应生成具有固定签名的初始函数；将初始函数追加至初始代码的源码末端，得到初加工源代码；将初加工源代码编译为可执行的字节码形式的业务流程函数，并保存至数据库中。
[0159]
在一些实施例中，调度模块412具体还可以用于：从数据库中下载至少一个业务流程函数，以将业务流程函数加载至对应启动的至少一个引擎进程中。
[0160]
在一些实施例中，调度模块412具体还可以用于：根据每一业务流程函数的网络地址，将在稳定调用关系中处于被调用关系的至少一个子业务流程函数加载至对应处于调用关系的父业务流程函数的引擎进程中。
[0161]
在一些实施例中，调度模块412具体还可以用于：获取每一业务流程函数调用其他业务流程函数的调用关系数据；基于调用关系数据将至少两个业务流程函数对应形成为调用关系树；其中，调用关系树包括至少一条调用链，每一调用链最上游的业务流程函数为调用关系树的根节点，位于每一调用链下游的业务流程函数为调用关系树的子节点；遍历调用关系树中的每一业务流程函数，以将至少一个子节点对应的子业务流程函数加载到与其对应的根节点对应的父业务流程函数的引擎进程中。
[0162]
在一些实施例中，调度模块412具体还可以用于：在引擎进程中被调用次数较多的调用关系树的子节点位于的调用关系树的根节点的其中一侧，被调用次数较少的调用关系树的子节点位于的调用关系树的根节点的相对另一侧。
[0163]
在一些实施例中，调度模块412具体还可以用于：将子业务流程函数确定为父业务流程函数，重复执行将父业务流程函数的至少一个子业务流程函数加载到业务流程函数的引擎进程中的步骤，直至形成的单体服务的网络业务达到单进程的负载上限。
[0164]
在一些实施例中，调度模块412具体还可以用于：获取服务器集群中每一服务器的资源占用率；其中，资源占用率为服务器的使用率；在服务器集群中资源占用率低于第一预设资源占用率的服务器上启动至少一个引擎进程，并加载至少一个业务流程函数。
[0165]
在一些实施例中，调度模块412具体还可以用于：将运行在服务器集群中资源占用率超过第二预设资源占用率的服务器上的部分引擎进程迁移至其他服务器，并保证服务器集群中的每一服务器的资源占用率均低于第一预设资源占用率；其中，第二预设资源占用率大于第一预设资源占用率。
[0166]
在一些实施例中，调度模块412具体还可以用于：在服务器集群中的每一服务器的资源占用率均低于第三预设资源占用率时，将其中资源占用率最小的服务器上运行的所有引擎进程均迁移至其他服务器上。
[0167]
在一些实施例中，调度模块412具体还可以用于：根据每一服务器的资源占用率对服务器集群中的每一服务器进行排序；在排名后10％的任一服务器上启动至少一个引擎进程，并加载每一新获取的业务流程函数。
[0168]
请参阅图8，图8是本技术智能终端一实施例的框架示意图。该智能终端51包括相互耦接的存储器511和处理器512，处理器512用于执行存储器511中存储的程序指令，以实现上述任一网络服务的调度方法实施例的步骤。
[0169]
在一个具体的实施场景中，智能终端51可以包括但不限于：计算机、平板电脑、智能手机以及智能手表等任一合理的智能终端中的一种，本技术对此不做限定。
[0170]
具体而言，处理器512用于控制其自身以及存储器511以实现上述任一视频显示方法实施例的步骤。处理器512还可以称为cpu(central processing unit，中央处理单元)。处理器512可能是一种集成电路芯片，具有信号的处理能力。处理器512还可以是通用处理器、数字信号处理器(digital signal processor,dsp)、专用集成电路(application specific integrated circuit,asic)、现场可编程门阵列(field
‑
programmable gate array,fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器512可以由集成电路芯片共同实现。
[0171]
请参阅图9，图9是本技术计算机可读存储介质一实施例的框架示意图。计算机可读存储介质61存储有能够被处理器运行的程序指令611，程序指令611用于实现上述任一网络服务的调度方法实施例的步骤。
[0172]
在本技术所提供的几个实施例中，应该理解到，所揭露的方法、装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。
[0173]
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
[0174]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以
是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0175]
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施方式方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。