CN116436724A - 一种按需分布式树形云边端协同扩展架构 - Google Patents

Abstract

本发明公开了一种按需分布式树形云边端协同扩展架构，包括新型云边端协同扩展架构中心、域、主功能服务器、功能服务器组、本地功能解析服务器、解析器；新型云边端协同扩展架构中心对整个融合服务计算框架实行集中式管理，功能服务器以域为管理单元并与解析器通信连接；在融合服务计算框架中，将整个网络服务的重心偏向用户，通过对用户发布的需求进行细粒度划分，使得用户发布的需求在数据的传输过程中就能被树形分布的各个功能服务器解决，不一定要和远程的专用服务器建立连接，提高了响应速度和资源利用率，实现了一种更为主动和灵活的信息服务模式。

Description

一种按需分布式树形云边端协同扩展架构

技术领域

本发明涉及云边端协同技术领域，具体为一种按需分布式树形云边端协同扩展架构。

背景技术

随着社会信息化进程的加快，Internet正在前所未有地改变着我们的生活，迅速增长的网络信息形成了海量的信息资源，无论是企业、个人还是进行科学研究，都对资源获取的准确性、实时性、信息处理的高效性和用户使用的便捷性有较高的要求。现有的网络信息服务模式是由用户自身跟不同的远程服务器交互完成复杂的业务需求，在这种服务模式下，用户不能有效利用各式各样的网络资源且效率不高。随着物联网等技术的不断发展、数据规模的不断增大，云边端协同技术应运而生，采用云计算和边缘计算结合的方案，更好的处理现实生活中的各种复杂的需求场景，最大化云计算和边缘计算的应用价值。虽然云计算提供了随需应变的可扩展性，但是仍然具有一定的局限性。一方面，为了适应现有边缘部署的扩展，需要不断增加设备和边缘节点的数量，增加了大量的成本。另一方面，边缘计算是高度分布式的，分布在办公室、工厂、校园等场所，有些甚至分布在遥远的、难以访问的地方，因此需要专设管理员对这些设备进行管理和维护。

发明内容

本发明设计一种按需分布式树形云边端协同扩展架构，目的是为了改变现有的网络信息服务模式，建立一种面向用户需求的、更为主动的、高效的分布式计算架构，提高当前计算架构在资源利用率，信息过滤的准确性，实时性，用户使用便捷性等方面的性能。

为实现上述目的，本发明采用的技术方案是：一种按需分布式树形云边端协同扩展架构，包括新型云边端协同扩展架构中心、域、主功能服务器、功能服务器组、本地功能解析服务器、解析器；新型云边端协同扩展架构中心对整个融合服务计算框架实行集中式管理，功能服务器以域为管理单元并与解析器通信连接；

所述的新型云边端协同扩展架构中心用于对整体框架实行集中式的管理，以虚拟化和调度技术为手段，针对下层划分的不同区域进行模块化管理，实现新型云边端协同扩展架构中各个功能服务器管理、服务分发，区域管理功能；

所述的域是一个分布式的数据库，用来对某个特定区域内的所有通信记录进行管理，这种结构允许对整体数据库的各个部分进行本地控制；将IP地址和提供的服务相互映射，并且在各个部分中的数据通过客户端/服务器模式变得对整个网络都可用，所有的功能服务器都可以选择加入任何一个域中；

所述的主功能服务器是一个区域内的权威服务器，主功能服务器拥有某个域的完整信息，并管辖整个区域的所有功能服务器；当收到用户请求时，先看自身能否应答，如果自身无法回答时，就从其主机上的文件中读取区域数据并轮询功能服务器组，直到得到应答；

所述的功能服务器组由多个功能服务器组成，每个功能服务器用来执行用户的不同需求，包括计算服务，通信服务等，功能服务器可以从区域的主功能服务器上申请获取区域数据；

所述的本地功能解析服务器是在本地设置的功能服务器，用来记录已经获取的查询数据，当客户再次对相同服务发起请求时，直接通过本地功能解析服务器进行解析，不需要经过迭代查询，提升了解析和访问速度；

所述的解析器就是访问服务器的客户端程序，当用户需要在网络上发布需求时就会使用到解析器，解析器需要将用户的需求按功能进行细粒度划分并发布给对应的服务器，解析响应信息，最终将信息返回给查询解析器的用户。

本发明的有益效果：

本发明设计一种按需分布式树形云边端协同扩展架构，是一种面向用户需求的、更为主动的、高效的分布式计算架构，对现有的计算架构进行了改进和优化，主要有以下三个方面的特点：

(1)从服务发布方式看，在传统的计算架构下，需要由用户自身跟不同的远程服务器交互完成复杂的业务需求，用户不能有效利用各式各样的网络资源且效率不高。在融合服务计算框架中，整个网络服务的重心更加偏向用户，用户只需要关注自己的需求发布是否详细和最终得到的结果是否满意。用户的需求一经发布就会被解析器细分成多个小型的独立需求，例如计算需求，管理需求等。这些需求被托管到独立的功能服务器中，单独进行处理，最终由功能服务器进行整合，完成用户的整体业务需求。其本质是实现“信息找人，按需提供服务”。

(2)从服务提供方式看，在传统计算架构的自由网络环境下，本机上用户访问服务时是直接和远程服务器建立连接传输数据，灵活性较差且网络资源利用率不高。在融合服务计算框架中，将IP地址和提供的服务相互映射，用户发布的需求在数据的传输过程中就能被树形分布的各个功能服务器解决，不一定要和远程的专用服务器建立连接，提高了响应速度和资源利用率，实现了一种更为主动和灵活的信息服务模式。

(3)从拓扑结构看，融合服务计算框架采用树形的拓扑结构，能够对整体数据库的各个部分进行本地控制且易于扩展，便于在网络中加入新的分支或新的节点。在安全性方面，采用树形拓扑结构易于隔离故障，如果某一线路或某一分支节点出现故障，它主要影响局部区域，能够将故障部位跟整个系统隔离开。因此在树形拓扑结构下，如果要创建新的功能服务器、服务器功能发生变更或者功能服务器宕机，只需要对相应功能服务器的区域数据进行更新即可。

综上，本发明设计融合服务计算框架相较于传统的计算架构主要有以下创新点，第一，实现了一种更为主动的服务发布方式。第二，在功能上将IP地址和提供的服务相映射，实现了一种更为灵活的服务提供方式。第三，采用树形的拓扑结构便于管理。

附图说明

图1是本发明一种按需分布式树形云边端协同扩展架构图。

图2是本发明用户与功能服务器之间“发布需求/需求响应”的数据流传输过程图。

图3是本发明主功能服务器与功能服务器组之间的区域数据传输图。

图4是本发明基于融合服务计算框架的数据包结构图。

图5是用户申请一个计算业务时整个融合服务计算框架的工作流程以及各个功能服务器之间协同工作图。

图6是用户申请不同计算业务时，整体流程所花费时间统计图。

具体实施方式

下面将结合附图对本发明中的技术方案进行清楚、完整地描述。应该强调的是，所描述的实施例仅仅是本发明一部分实施例，而不是为了限制本发明的范围以及其应用。

本发明提供一种技术方案：一种按需分布式树形云边端协同扩展架构；

如图1所示，从上到下，第一部分是新型云边端协同扩展架构中心，用于对框架实行集中式的管理，以虚拟化和调度技术为手段，针对下层划分的不同区域进行模块化管理，实现新型云边端扩展框架中服务规划，区域管理等功能。同时，设置分布式云节点管理、服务分发等模块，保障区域内功能服务器规划的合理性和区域数据的一致性。第二部分是域，为了克服功能服务器出现单点失效的问题，该框架中将功能服务器划分为不同的域，每个域由对应的主功能服务器进行管理。从总体来看，域相当于是一个分布式的数据库，用来对某个特定区域内的所有通信记录进行管理，这种结构允许对整体数据库的各个部分进行本地控制，将IP地址和提供的服务相互映射，并且在各个部分中的数据通过客户端/服务器模式变得对整个网络都可用，所有的功能服务器都可以选择加入任何一个域中。在域的管理模式下，主功能服务器管理整个区域的文件称为区域数据，当功能服务器中的资源发生迁移,那么原先的IP地址就无效了,只需要更新主功能服务器中的主机记录即可，方便管理并且能够保持网络数据的一致性。第三部分是主功能服务器和功能服务器组。主功能服务器是一个区域内的权威服务器，它拥有某个域的完整信息，并管辖整个区域的所有功能服务器，当收到用户请求时，先看自身能否应答，若它可以对该需求进行处理，则直接由主功能服务器作出响应，提高应答效率。如果自身无法回答的话，就从其主机上的文件中读取区域数据并轮询功能服务器组或者跨区域向其它区域内的主功能服务器发出请求，直到得到应答。功能服务器组由多个功能服务器组成，每个功能服务器用来执行用户的不同需求，例如：计算服务，通信服务，它可以从区域的主功能服务器上申请获取区域数据。第四部分是本地功能解析服务器，本地功能解析服务器是在本地设置的功能服务器，用来记录已经获取的查询数据，主功能服务器在处理递归查询时可能需要发送多次查询才能找到对应的答案，然而在此过程中，每当它被指引到一组功能服务器组时，它能够发现这些功能服务器属于哪个域并且能够处理哪些业务并将这些数据储存起来，以备后用。因此当客户再次对同服务发起请求时，直接通过本地功能解析服务器进行解析，不需要经过迭代查询，极大提升解析和访问速度。第五部分是解析器，用户将需求发布之后，解析器需要将用户层面的需求进行细粒度划分并转化为代码层面的客户端程序，用于访问对应的功能服务器，并且在功能服务器将处理结果返回后，解析该响应信息，将信息返回给查询它的用户。第六部分是用户端，在该新型架构下，用户只需要关注自己的需求发布是否详细和最终得到的结果是否满意，一些复杂的数据处理等工作都留给功能服务器来处理，并且用户在本机上的访问服务不需要直接和远程服务器建立专用连接传输数据，在数据传输过程中就已经被各功能服务器解决，这样既简化了用户的工作为用户节省了大量时间，也提高了资源信息的利用率。

如图2所示，是在融合服务计算架构下用户与功能服务器之间“发布需求/需求响应”的交互过程图：

与传统的信息服务模式的不同之处在于，在融合服务计算框架下，在本机上的用户发布的业务由数据传输路径中各个功能服务器来完成，将不同的功能与IP地址相互映射，其本质是实现“信息找人，按需提供服务”，用户只需要关注自己的需求发布是否详细和最终得到的结果是否满意，用户的需求被托管到独立的功能服务器中，由各个功能服务器来帮助他们完成各项复杂的任务，本机上的访问服务不需要和远程服务器建立专用连接传输数据，提高了资源利用率和响应速度。

用户发布需求后，首先由解析器将用户发布的需求按功能进行细粒度划分并转化为对应的客户端程序，将用户需求转化到代码层面，以此来对用户的需求进行处理。客户端程序首先会查询本地功能解析服务器，若本地功能解析服务器已经在之前缓存过相同的查询数据，则本地功能解析服务器可以直接将信息传给解析器，这样可以大大缩短解析的过程。若本地功能解析服务器没有缓存过该查询数据，则继续向上查询主功能服务器，并且本地功能解析服务器会将此次返回的信息保存，以便下次响应相同类型的查询信息。若主功能服务器能够对该请求进行处理，则可以直接由其本身对解析器发来的请求作出响应。若其无法对该请求进行处理，则需要将该请求指引到对应的功能服务器或者跨区域向其它区域的功能服务器发出请求，主功能服务器之前已经查询过该区域的数据并且拥有了该区域内的全部信息，因此它知道每一个功能服务器的位置和IP地址。并且为了防止由于主功能服务器向功能服务器发送查询后，这个查询被下层网络延误或遗失，或者功能服务器主机正忙于处理其他业务未能立刻接收到该查询，使得解析器超时未得到响应结果又向主功能服务器发送同样的查询。因此会对每台功能服务器查询两次，以确保得到响应结果。对于重复的查询，主功能服务器会在它仍然试图对原来的查询作出回应时，检测出该查询是否重复。因为主功能服务器还在处理解析器的第1次查询，收到和第1次查询一模一样的查询内容后，它才能检测到这是重复的查询。但是因为1号功能服务器已经对功能服务器的前一个查询做出了应答，所以1号功能服务器没有能检测到来自主功能服务器的重复查询。在功能服务器接收到来自1号功能服务器的第1次响应后，所有其他响应都作为重复响应而被丢弃。

下面结合图3，对功能服务器中的资源发生迁移或服务器状态发生变化时主功能服务器与功能服务器组之间的区域数据传输做详细分析：

区域数据是整个区域的管理文件，其中包含了描述整个区域信息的资源记录。资源记录包括区域中每个功能服务器的相关信息，并记录了各个功能服务器和其功能之间的相互映射。由于区域可能很大而且由于网络或者硬件设备原因，资源数据很可能发生更改，在每台主功能服务器上单独手动编辑区域数据，会花费大量时间，并且有很大的概率会出现错误。因此就需要在主功能服务器与功能服务器之间进行区域数据传输，这样既能分散负载，又能方便对整个区域进行管理。当一个新的功能服务器添加到区域中并配置为功能服务器、服务器功能发生变更或者功能服务器宕机时，主功能服务器需在本地主机中加载区域数据并进行更新。需做更新的功能服务器向主功能服务器发出传送请求，功能服务器收到请求后，若回复允许更新，则功能服务器将需要更新的数据发送给主功能服务器，由主功能服务器在本地主机中加载区域数据的文件并进行更新。功能服务器也可以申请从主功能服务器数据文件中加载区域数据。当功能服务器死机或者重新启动时，它会先读取之前的区域数据文件，然后检查它的区域数据是否最新，若为最新的，只需要更改自己的这一部分，这样做可以避免传送未做更改的区域数据，保证数据同步。

下面结合图4，对本发明基于融合服务计算框架的数据包结构做详细分析：

用户与功能服务器之间“发布需求/需求响应”的交互过程可以大体分为两个步骤，第一个步骤是用户发布需求经解析器向本地功能解析服务器发出一个请求报文，报文里面携带需要申请的业务；第二个步骤是功能服务器将用户的业务进行处理之后向本机回应一个响应报文，里面包含相对应的解析结果。整个报文格式可以主要分为3部分内容，即首部、需求计数部分、资源记录部分。其中标识、标志、问题计数、回答资源计数、主功能服务器计数、附加资源记录数这六个字段是报文的首部。该部分中每个字段含义如下：

标识：用于区分应答的报文是具体对那个请求进行相应的。

标志：用于标明该报文是基于融合服务计算框架的数据包。

问题计数：用户查询请求的数目。

回答计数：功能服务器进行响应的数目。

功能服务器计数：功能服务器的数目。

附加资源记录数：各个服务器对应业务的数目。

查询问题区域属于需求计数部分，该部分中每个字段含义如下；

查询功能名：一般为用户所要申请的业务。

查询类型：用户申请需求业务的资源类型，用来标明该报文是用户申请业务并需要获取响应结果的报文。

查询类：表明该报文是互联网数据。

其余属于资源记录部分，该部分中每个字段含义如下:

选择业务：用户请求的业务名称。

类型：资源记录的类型，与需求计数部分中的查询类型值是一样的。

类：地址类型，与需求计数部分中的查询类值是一样的。

生存时间：以秒为单位，表示资源记录的生命周期，一般用于当主功能服务器收到响应记录后决定保留还是丢弃以及使用缓存数据的时间。

资源数据：表示按照查询部分要求功能服务器返回的相关数据。

下面结合图5，对用户申请一个计算业务时整个融合服务计算框架的工作流程以及各个功能服务器之间的协作做详细分析：

当用户申请一个计算业务时，融合服务计算框架会将计算业务进行划分，将一个大的需求划为若干个子需求，例如当用户给出一个计算公式时，公式如下，其中x是特征输入，w是参数，y是输出：

对于该公式，融合服务计算框架会将该计算业务分为四个子功能，一个是乘法功能计算-w^Tx一个是指数功能计算

一个是加法功能计算/>

最后一个是除法功能计算/>

用户申请计算业务之后，首先由解析器将用户需求转化到服务器能处理的代码层面，以此来对用户的业务需求进行处理。客户端程序首先会查询本地功能解析服务器，若本地功能解析服务器已经在之前进行过加法、乘法、除法、指数等相应的计算并对结果数据进行了缓存，则本地功能解析服务器可以直接将解析信息传给解析器。若本地功能解析服务器不能对这些业务进行解析，则需要继续向上查询主功能服务器，并且本地功能解析服务器会将此次返回的信息保存，以便下次直接响应相同类型的查询信息。若主功能服务器能够对加法、乘法、除法、指数功能进行解析，则直接由主功能服务器对各个分步计算式进行计算，并将结果返回。若主功能服务器无法对该请求进行处理或只能处理其中的一部分计算式，则需要将其余请求指引到对应的功能服务器。在进行请求指引之前，主功能服务器需要与功能服务器组进行区域文件传输获取该区域内每一个功能服务器的位置和IP地址以便进行轮询。在主功能服务器进行轮询的时候，各个计算业务是分步进行的，首先进行乘法运算，当轮询到乘法功能服务器时，该请求能够被解析并返回结果；接着进行指数运算，当轮询到指数功能服务器时，该请求能够被解析并返回结果；接着进行加法运算，当轮询到加法功能服务器时，该请求能够被解析并返回结果；最后进行除法运算，当轮询到除法功能服务器时，该请求能够被解析并返回结果。至此，所有的计算业务都被处理完毕，主功能服务器将所有的结果进行整合并返回给解析器，由解析器对结果进行处理返回给用户。

下面结合图6，对用户申请不同计算业务时，整体流程所花费时间作详细说明。

在该业务流程中包含三个功能服务器，分别是主功能服务器、加法功能服务器和减法功能服务器。当用户申请减法和加法业务时，首先会请求主功能服务器，分别花费了6ms和4ms。当请求到达后主功能服务器发现无法对减法和加法请求进行处理，则需要将该请求指引到对应的加法功能服务器和减法功能服务器，减法功能服务器处理减法业务需要5ms，加法功能服务器处理加法业务需要4ms。若用户申请的业务主功能服务器能够处理的话，则直接由其对解析器发来的请求作出响应，例如当用户请求作除法运算时，主功能服务器能够解决，则直接由主功能服务器进行处理并返回结果，整个过程花费了1ms，提高了查询的速度。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (4)

1.一种按需分布式树形云边端协同扩展架构，其特征在于：包括新型云边端协同扩展架构中心、域、主功能服务器、功能服务器组、本地功能解析服务器、解析器；新型云边端协同扩展架构中心对整个融合服务计算框架实行集中式管理，功能服务器以域为管理单元并与解析器通信连接；

所述的新型云边端协同扩展架构中心用于对整体框架实行集中式的管理，以虚拟化和调度技术为手段，针对下层划分的不同区域进行模块化管理，实现新型云边端协同扩展架构中各个功能服务器管理、服务分发，区域管理功能；

所述的域相当于是一个分布式的数据库，用来对某个特定区域内的所有通信记录进行管理，这种结构允许对整体数据库的各个部分进行本地控制；

所述的主功能服务器是一个区域内的权威服务器，拥有某个域的完整信息，并管辖整个区域内的所有功能服务器；

所述的功能服务器组由多个功能服务器组成，每个功能服务器用来执行用户的不同需求，包括计算服务，通信服务，功能服务器可以从区域的主功能服务器上申请获取区域数据；

所述的本地功能解析服务器是在本地设置的功能服务器，用来记录已经获取的查询数据；

所述的解析器就是访问服务器的客户端程序，当用户需要在网络上发布需求时就会使用到解析器，解析器需要将用户的需求按功能进行细粒度划分并发布给对应的功能服务器，解析响应信息，最终将信息返回给查询解析器的用户。

2.根据权利要求1所述的一种按需分布式树形云边端协同扩展架构，其特征在于，融合服务计算框架将整个网络服务的重心偏向用户，对用户发布的需求按功能进行细粒度划分并托管到对应的功能服务器中进行处理。

3.根据权利要求1所述的一种按需分布式树形云边端协同扩展架构，其特征在于，融合服务计算框架将IP地址和提供的服务相互映射，使用户发布的需求在数据的传输过程中就能被树形分布的各个功能服务器解决。

4.根据权利要求1所述的一种按需分布式树形云边端协同扩展架构，其特征在于，融合服务计算框架采用树形的分布式拓扑结构。

Images