CN111966482A - 边缘计算系统 - Google Patents

Abstract

本申请提供一种边缘计算系统，应用于医疗，所述系统包括：边缘模块，包括：多个边缘节点；每个边缘节点包括一容器集群，通过容器编排工具进行管理，所述容器编排工具实现有用于进行边缘计算工作的执行单元；服务分配模块，用于执行全局负载均衡工作，以将用户服务请求路由到目的的边缘节点；服务管理模块，用于对应所述用户服务请求的服务的管理。解决了由于网络时延问题会严重影响医疗领域用户的体验，同时也制约有低时延需求的应用的发展，并且只能对静态内容进行缓存，而无法对动态内容进行缓存使得内存等计算资源被闲置利用率不高的问题，本申请进一步降低时延并有效提高了计算机资源的利用率，因而提升了用户体验。

Description

边缘计算系统

技术领域

本申请涉及一种信息与通信工程，特别是涉及一种边缘计算系统。

背景技术

随着云计算和大数据技术在医疗领域和医院等机构的应用越来越广泛，从用户体验和安全的角度出发，网络的时延和带宽问题始终是医院最关心的问题。网络带宽可以伴随网络基础设施的完善不断提高，但是网络时延问题由于受到信号传播时延和路由器、交换机引起的处理时延等物理上的限制，很难持续优化，网络时延过高会严重影响用户体验，同时也制约有低时延需求的应用的发展。

CDN(内容分发网络)在地域上分散部署多个缓存服务器节点，然后将互联网内容发布到这些网络边缘节点上，使网络内容在地域上更加接近用户。当用户发起请求时，经由全局负载均衡系统，将用户请求导向到CDN边缘节点。用户可以直接从CDN边缘节点获取所需要的数据，降低了响应时延。CDN可以从一定程度上的缓解时延问题，但是仍存在其局限性。现有的CDN系统只能对静态内容(服务器中真实存在的文件，如图片，视频，脚本文件等)进行缓存，而无法对动态内容(每次请求动态生成的内容，例如各种接口调用)进行缓存。此外，传统的CDN节点只起到内容缓存的作用，CDN节点的CPU，内存等计算资源被闲置，硬件资源利用率较低。

发明内容

鉴于以上所述现有技术的缺点，本申请的目的在于提供一种边缘计算系统，用于解决现有技术中由于网络时延问题会严重影响医疗领域用户的体验，同时也制约有低时延需求的应用的发展，并且只能对静态内容进行缓存，而无法对动态内容进行缓存使得内存等计算资源被闲置利用率不高的问题。

为实现上述目的及其他相关目的，本申请提供一种边缘计算系统，应用于医疗，所述系统包括：边缘模块，包括：多个边缘节点；每个边缘节点包括一容器集群，通过容器编排工具进行管理，所述容器编排工具实现有用于进行边缘计算工作的执行单元；服务分配模块，用于执行全局负载均衡工作，以将用户服务请求路由到目的的边缘节点；服务管理模块，用于对应所述用户服务请求的服务的管理。

于本申请的一实施例中，所述边缘模块、服务分配模块、及服务管理模块中的一个或多个实现于一台或多台服务器。

于本申请的一实施例中，所述容器为Docker容器。

于本申请的一实施例中，所述容器编排工具为Kubernetes。

于本申请的一实施例中，所述用户服务请求为网页网址用户请求。

于本申请的一实施例中，所述边缘计算系统，所述数据库包括对应所述用户服务请求的服务状态。

于本申请的一实施例中，所述数据库为Mysql数据库。

于本申请的一实施例中，所述用户服务请求为读取请求或写入请求。

于本申请的一实施例中，所述边缘模块包括：阈值保护单元，用于根据Windows-LFU算法记录和实时更新与各个时间对应的边缘节点服务请求的访问量记录。

于本申请的一实施例中，所述Windows-LFU步骤包括：(1)将用户服务请求分为所述用户服务请求的边缘计算服务已启动服务和未启动服务两种类型，根据近期访问频率分别进行排序；(2)从所述未启动服务的应用中选择访问频率最高的应用，作为待启动应用，然后从所述已启动服务的应用列表中选择满足替换要求的候选容器集群的应用，其中，选取标替换要求为准替换后是否能够满足待启动的服务所需的资源；(3)从所述候选容器集群列表中选择访问量最小的应用。

如上所述，本申请的边缘计算系统，具有以下有益效果：解决了由于网络时延问题会严重影响医疗领域用户的体验，同时也制约有低时延需求的应用的发展，并且只能对静态内容进行缓存，而无法对动态内容进行缓存使得内存等计算资源被闲置利用率不高的问题，本申请进一步降低时延并有效提高了计算机资源的利用率，因而提升了用户体验。

附图说明

图1显示为本申请一实施例中的边缘计算系统的结构示意图。

元件标号说明

11 边缘模块

12 服务分配模块

13 服务管理模块

具体实施方式

以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。本申请还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

在通篇说明书中，当说某部分与另一部分“耦接”时，这不仅包括“直接连接”的情形，也包括其它元件置于其间而“间接连接”的情形。另外，当说某种部分“包括”某种构成要素时，只要没有相反的记载，则并非将其它构成要素排除在外，而是意味着可以还包括其它构成要素。

其中提到的第一、第二及第三等术语是为了说明多样的部分、成份、区域、层及/或段而使用的，但并非限定于此。这些术语只用于把某部分、成份、区域、层或段区别于其它部分、成份、区域、层或段。因此，以下叙述的第一部分、成份、区域、层或段在不超出本申请范围的范围内，可以言及到第二部分、成份、区域、层或段。

再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包含”、“包括”表明存在所述的特征、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“A、B或C”或者“A、B和/或C”意味着“以下任一个：A；B；C；A和B；A和C；B和C；A、B和C”。仅当元件、功能或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。

随着云计算和大数据技术在医疗领域和医院等机构的应用越来越广泛，从用户体验和安全的角度出发，网络的时延和带宽问题始终是医院最关心的问题。网络带宽可以伴随网络基础设施的完善不断提高，但是网络时延问题由于受到信号传播时延和路由器、交换机引起的处理时延等物理上的限制，很难持续优化，网络时延过高会严重影响用户体验，同时也制约有低时延需求的应用的发展，CDN可以从一定程度上的缓解时延问题，但是仍存在其局限性。现有的CDN系统只能对静态内容(服务器中真实存在的文件，如图片，视频，脚本文件等)进行缓存，而无法对动态内容(每次请求动态生成的内容，例如各种接口调用)进行缓存。此外，传统的CDN节点只起到内容缓存的作用，CDN节点的CPU，内存等计算资源被闲置，硬件资源利用率较低。

因此本申请提供一种边缘计算系统，用于解决由于网络时延问题会严重影响医疗领域用户的体验，同时也制约有低时延需求的应用的发展，并且只能对静态内容进行缓存，而无法对动态内容进行缓存使得内存等计算资源被闲置利用率不高的问题，本申请进一步降低时延并有效提高了计算机资源的利用率，因而提升了用户体验。

所述系统包括：边缘模块，包括：多个边缘节点；每个边缘节点包括一容器集群，通过容器编排工具进行管理，所述容器编排工具实现有用于进行边缘计算工作的执行单元；服务分配模块，用于执行全局负载均衡工作，以将用户服务请求路由到目的的边缘节点；服务管理模块，用于对应所述用户服务请求的服务的管理。

下面以附图1为参考，针对本申请得实施例进行详细说明，以便本申请所述技术领域的技术人员能够容易地实施。本申请可以以多种不同形态体现，并不限于此处说明的实施例。

如图1所示，为本申请实施例中的一种边缘计算系统的结构示意图。

所述边缘计算系统包括：边缘模块11，所述边缘模块11包括：多个边缘节点；每个边缘节点包括一容器集群，所述容器集群包括一或多个容器，一个容器集群内部的容器可以共享储存和网络资源。

所述容器编排工具对所述容器集群进行管理，容器编排工具提供调度和管理容器集群的技术，提供用于基于容器应用可扩展性的基本机制。这些工具使用容器服务，并编排他们以决定容器之间如何进行交互，所述容器编排工具实现有用于进行边缘计算工作的执行单元，所述执行单元可以为一执行器，接收到边缘计算工作的指令后，储存容器镜像并运行容器虚拟机提供计算服务，快速响应用户的动态内容请求。

所述服务分配模块12，用于执行全局负载均衡工作，当接收到用户服务请求，根据所述用户服务请求进行查询，直到找到解析结果或返回相应的错误信息，其中查询方式为递归查询和迭代查询，所述递归查询是当发起查询请求时，收到回复后再向下一级发起远程请求，直到获得结果。所述迭代查询是指只向用户返回自己知道最适合的答案，后续查询由用户来发起。在查询过后，根据就近原则将所述边缘节点的边缘节点IP返回给用户，根据各服务器边缘计算服务的实际运行情况，调度用于响应用户请求的具体容器虚拟机。举例来说，所述服务分配模块12为DNS服务器，当用户服务请求为www.cdn.com时，所述服务分配模块12接收到所述用户服务请求，向DNS系统进行查询解析，根据返回com域名服务器列表，再从所述列表中选择一个IP地址，向这个地址发送域名解析请求,然后根据.com的域名信息再向cdn.com的权威服务器发起解析请求，再根据类似的方法向www.cdn.com的服务器IP地址返回，再将解析结果返回给用户。

所述服务管理模块13，用于对应所述用户服务请求的服务的管理，所述服务管理模块13是整个边缘计算系统的控制中心，负责管理边缘计算服务的创建、更新和删除等管理接口。具体的，所述服务管理模块13主要负责处理所述边缘计算系统与外界系统交互所必须的一些工作，包括：边缘计算服务状态管理，所述服务分配模块12的配置，所述容器镜像及对应域名关系的绑定，具体的，所述服务管理模块先将使用边缘计算的域名解析权交给所述服务分配模块12，并部署一个源站，用于边缘节点部分情况下的回源操作，然后构建容器镜像，并将所述容器镜像上传到镜像仓库，上传完成后，配置对应的容器镜像及域名绑定关系。

可选的，所述边缘模块11、服务分配模块12、及服务管理模块13中的一个或多个实现于一台或多台服务器，具体的，所述边缘模块11进行工作的场所、所述服务分配模块12实现功能的场所以及所述服务管理模块13进行管理动作的场所，这三个场所中的一种或多种在一台或多台服务器中实现；服务器之间可以进行通信，举例当多台服务器时，服务器经过路由上相应的远程端口进行通信，若是服务器之间走的内网路由方式连接，可以用内网IP连接起来，需要注意的是，服务器之间的通信方式在本申请中不进行限定。

举例来说，当所述边缘模块11进行工作的场所、所述服务分配模块12实现功能的场所以及所述服务管理模块13进行管理动作的场所在一台服务器中实现，其中服务器包括处理所述边缘模块11、服务分配模块12及服务管理模块13工作的软件系统，其中三个模块相互进行通信，在一台服务器中，所述服务管理模块13接收到用户发来的用户服务请求时，对所述用户服务请求的域名信息进行递归查询然后根据地理可就近行原则将边缘节点IP返回给客户，边缘节点接收到用户服务请求后，获取所述用户服务请求的域名，检查是否已经启动所述服务，若没有启动，找到域名对应镜像并启动容器。当所述边缘模块11进行工作的场所、所述服务分配模块12实现功能的场所以及所述服务管理模块13进行管理动作的场所在两台服务器中实现，令所述两台服务器为全局服务器和本地节点服务器，首先全局服务器处理所述服务分配模块12和所述服务管理模块13，所述本地节点服务器负责所述边缘模块11，当全局服务器接收到用户服务请求时，解析过后将边缘节点IP地址发给用户，用户向所述边缘节点的本地节点服务器提起服务请求，所述本地节点服务器根据接收到的所述用户服务请求解析出域名信息，进而向所述全局服务器提出检查该服务是否启动，若没有启动需要从镜像仓库下载相应的镜像找到相应的容器工作并发布工作指令令所述本地服务器实现目的容器的边缘计算工作。

可选的，所述容器为Docker容器；Docker是dotCloud开源的一个基于LXC的轻量级容器虚拟化引擎，容器执行采用沙箱机制，每个容器之间存在系统级隔离，相互之间不存在接口。Docker还对镜像存储进行了优化，采用分层存储模式，如果不同Docker镜像采用同样的基础镜像，基础镜像可以复用，从而节省存储空间。Docker容器虚拟化具备的隔离性，高性能，文件存储优化等几个显著特点，与边缘计算平台的需求相契合。采用Docker作为基础相对于这些完全虚拟化方式有很多优势。一方面，Docker避免了硬件虚拟化及维护客户机操作系统的资源开销，具备更高的虚拟化性能。另一方面、更高的存储利用率以满足在边缘节点支持多用户的需求。

可选的，所述容器编排工具为Kubernetes，Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性，在Kubernetes中，Service是分布式集群架构的核心，虽然service通常由多个相关的服务进程来提供服务。每个服务进程都有一个独立的endpoint(IP+port)访问点，但我们通过service(虚拟cluster IP+Port)连接指定的service进程上。由于容器提供了强大了隔离功能，所以有必要把为service提供服务的这组进程放入容器中。为此，k8s设计了pod对象(容器组)，将每个服务进程包装到相应的pod中，使其成为pod中运行的一个容器。为了建立service和pod的关联关系，为pod贴上一个标签(label)，比如给运行mysql的pod贴上name＝mysql标签，给运行PHP的贴上name＝php标签。给相应的service定义标签选择器(labelselector)，比如mysql的service的标签选择器的选择条件为name＝mysql，意味着该service要作用于所有包含name＝mysql label的pod上。解决了service和pod关联问题。至于pod，首先其运行在一个我们称之为节点Node的环境中，Node既可以是物理机，也可以是云的一个虚拟机。通常在一个节点上运行几百个pod。其次每个pod中运行着许多容器，但只有一个特殊的pause容器，其他容器为业务容器，这些业务容器共享pause容器的网络栈和volume挂载卷。因为它们之间的数据交换更为高效。在设计时可以充分利用这一特性，将一组密切相关的服务进程放入到同一个pod中。最后需要注意的是，并不是每个pod和其中运行的容器都能映射到一个service上，只有那些提供服务(无论对内还是对外)的一组pod才会被映射为一个服务。在集群管理方面，k8s将集群的机器划分为一个master节点和一群工作节点(Node)，在master节点上运行集群管理相关的一组进程kube-apiserver，kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、pod调度、弹性伸缩、系统监控等管理功能，且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在node上k8s管理的最小运行单元是pod。node上运行kubelet、kube-proxy服务进程，这些负责pod的创建、启动，重启，销毁等Kubernetes集群的各个组件之间通过APi Server进行交互，当接收到用户服务请求时，通过APi Server写入数据库中，当监听到请求时分析所述用户服务请求时，如果集群中没有对应的Pod，根据请求携带的Pod模板创建Pod对象。

可选的，所述用户服务请求为网页网址用户请求，所述服务分配模块12和所述边缘模块可以对所述网页网址用户请求进行解析得到相应的域名信息。当接收到用户服务请求，根据所述用户服务请求的网页网址进行查询，直到找到解析结果或返回相应的错误信息，其中查询方式为递归查询和迭代查询，所述递归查询是当发起查询请求时，收到回复后再向下一级发起远程请求，直到获得结果。所述迭代查询是指只向用户返回自己知道最适合的答案，后续查询由用户来发起。在查询过后，根据就近原则将所述边缘节点的边缘节点IP返回给用户，根据各服务器边缘计算服务的实际运行情况，调度用于响应用户请求的具体容器虚拟机。举例来说，利用DNS服务器查询，当用户服务请求为www.cdn.com时，所述服务分配模块12接收到所述用户服务请求，向DNS系统进行查询解析，根据返回com域名服务器列表，再从所述列表中选择一个IP地址，向这个地址发送域名解析请求,然后根据.com的域名信息再向cdn.com的权威服务器发起解析请求，再根据类似的方法向www.cdn.com的服务器IP地址返回，再将解析结果返回给用户

可选的，所述边缘模块包括数据库，所述边缘计算系统还包括数据库，所述数据库包括对应所述用户服务请求的服务状态，首先在数据中心建立一个中心数据库，作为主数据库，边缘数据库作为主数据库的附属从数据库，从数据库与主数据间配置主从同步策略，自动从主库中同步数据，自动从主库中同步数据数据库为边缘数据库作为主数据库的附属从数据库，所述数据库包括对应所述用户服务请求的服务状态。

可选的，所述数据库为Mysql数据库，Mysql是一种关系数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。

可选的，所述用户服务请求为读取请求或写入请求，当用户发起读取请求时，边缘节点直接从本地的数据库中读取数据生成内容。当用户提交表单请求数据写入时，连接到中心数据库进行写入。写入完成后，数据又将采用数据库的主从同步机制，自动同步给边缘节点的从数据库。现有的成熟数据库系统，都具备主从同步的功能，可以通过系统配置实现。当采用边缘计算的应用对数据的需求是少量写入且采用了读写分离策略。占大多数的数据读取操作都可以在边缘节点本地完成，只有少量写入请求被发送到远程的中心数据库中，边缘计算性能得到保障，同时也可以较好地解决了中心数据库和远程数据库之间的数据同步问题

可选的，所述边缘模块包括：阈值保护单元，用于根据Windows-LFU算法记录和实时更新与各个时间对应的边缘节点服务请求的访问量记录。所述Windows-LFU算法记录一定时间窗口内元素的访问历史。这里的元素指域名，同时也是服务的名称，既包括集群中已经启动了服务的，也包括未启动边缘计算服务的。访问历史记录由为实时更新过去一段时间中对应的各个域名访问量记录。

可选的，所述Windows-LFU步骤包括：(1)将用户服务请求分为所述用户服务请求的边缘计算服务已启动服务和未启动服务两种类型，根据近期访问频率分别进行排序；(2)从所述未启动服务的应用中选择访问频率最高的应用，作为待启动应用，然后从所述已启动服务的应用列表中选择满足替换要求的候选容器集群的应用，其中，选取标替换要求为准替换后是否能够满足待启动的服务所需的资源；(3)从所述候选容器集群列表中选择访问量最小的应用；算法带阈值保护是指，候选对象中访问频率最小的对象，并不是一定被淘汰，还要将尚未启动的服务的最大访问频率与选择的对象的访问频率进行比较。如果尚未启动的服务的最大访问频率小于所有候选淘汰对象的频率，则本次算法不执行淘汰，算法直接结束。例如，已经启动了A，B，C三个服务，在过去的十分钟内，C的访问次数最少，只被访问了10次。此外，D、E、F是尚未启动的服务，其中E的访问次数最多，访问了8次。因此，在这种情况下，即使用E替换掉C也不会提高系统的性能。因此，对window-LFU算法进行一定的阈值保护，避免误淘汰。

实施例1：根据所述的边缘计算系统，具体举例实际应用中的实施例。

所述边缘计算系统包括：服务管理模块、边缘模块，服务分配模块，边缘模块，包括：多个边缘节点；每个边缘节点包括一pod，通过Kubernetes进行管理，有用于进行边缘计算工作的执行器，服务分配模块，为一DNS服务器，用于执行全局负载均衡工作，以将用户服务请求路由到目的的边缘节点；所述服务管理模块是整个边缘计算系统的控制中心，负责管理边缘计算服务的创建、更新和删除等管理接口。创建服务前，开发者需修改域名的授权DNS解析服务器为之前自建的DNS解析服务器，将解析权交给CDN系统，以实现基于地理就近原则的DNS解析。应用开发者开发完成后，将镜像Push到中心镜像仓库中，然后在后台管理模块配置域名所对应的具体Pod描述文件。对应关系存储在Mysql数据库中。服务创建采用异步Pull策略，系统不主动在边缘节点分发边缘计算服务。当边缘节点接收到请求后，根据URL中指定的域名，主动从服务管理接口获取对应的配置文件来启动服务；边缘节点启动容器时，首先就检查本地资源保有量是否可以满足新的服务的创建，在资源足够的情况下直接建立容器。否则，系统将先调用容器淘汰算法清理使用频率较低的容器。当镜像发生更新时，应当主动通知边缘节点进行镜像更新操作，以保证现有应用可以得到及时更新。服务更新可以通过镜像仓库发生镜像后的webhook钩子自动调用或在后台管理界面手动调用。服务更新过程为了保证边缘节点的及时更新，运接收到更新请求后依次远程调用边缘节点Kubernetes集群的Restful API接口，通知边缘节点发生镜像更新，请求进行对现有容器进行更新操作。边缘节点收到请求后，立即更新当前指定服务。更新过程可分为停机更新和滚动更新。停机更新时，需要先停止运行的容器，再重新部署，这样会产生业务的中断。大部分情况下，可以采用滚动更新机制以满足业务高可用性需求。滚动更新机制是一种不中断业务的更新升级方式。在Kubernetes系统实现中，rolling update就是每次只更新一个pod，逐个进行更新，而不是一次性停止所有pod，以保障业务的持续性和稳定性，边缘模块的主要单元为EC Proxy，其中Controller是它的控制中心，负责与各个模块交互。除Controller外，包括一个代理工具类Proxifer、一个访问历史记录器以及一个缓存淘汰算法Windows-LFU。Proxifer是一个代理类，由Java实现，可以实现HTTP请求代理功能。访问历史记录器记录各个域名的访问历史，作为资源不足时淘汰容器的数据基础。EC Proxy运行在每个边缘节点的Master主机上。进程启动后，EC Proxy监听80端口。所有发往Master的80端口上的请求都将交由EC Proxy进行处理。EC Proxy处理请求时，首先解析URL请求，从URL中获取所请求服务对应的域名。然后，EC Proxy经由Kubernetes的API Server从etcd存储中查找当前域名所对应的Pod及相应的Endpoint。此时将可能会得到两种查询结果:

(1)结果返回当前已经存在对应的服务，那么EC Proxy从API server中获取对应的Endpoint列表，包括Pod所在的节点IP及对应的Nodeport的集合。之后，EC Proxy根据负载均衡算法，将请求转发到某个Pod中进行处理。EC Proxy会将API Server的查询结果缓存到内存，以避免频繁查询Etcd引起的不必要的资源消耗。Pod处理完成后将生成最终的动态内容结果，EC Proxy将最终结果返回给用户。

(2)结果返回目前不存在所对应的服务，则说明边缘应用尚未启动。在启动应用前，EC Proxy需要先向EC Master节点请求域名所对应的RC和Service描述文件。描述文件下载完成后，EC Proxy根据得到的RC和Service描述文件。

根据相关描述文件，分析本地集群的资源使用情况。如果资源足够，直接向Kubernetes集群请求C动相成的服务，否则需要调用容器淘汰算法释放资源。服务启动完成后，后续步骤与之前提到的结果返回已存在服务的步骤相同。为了避免少量访问就启动容器导致资源浪费，可以为启动过程设定阈值。EC Proxy检查过去一段时间内该域名对应的访问量情况，在访问量达到预先设定的阈值时，再启动边缘计算服务来处理请求。

综上所述，本申请边缘计算系统，所述系统包括：边缘模块，包括：多个边缘节点；每个边缘节点包括一容器集群，通过容器编排工具进行管理，所述容器编排工具实现有用于进行边缘计算工作的执行单元；服务分配模块，用于执行全局负载均衡工作，以将用户服务请求路由到目的的边缘节点；服务管理模块，用于对应所述用户服务请求的服务的管理。解决了由于网络时延问题会严重影响医疗领域用户的体验，同时也制约有低时延需求的应用的发展，并且只能对静态内容进行缓存，而无法对动态内容进行缓存使得内存等计算资源被闲置利用率不高的问题，本申请进一步降低时延并有效提高了计算机资源的利用率，因而提升了用户体验。所以，本申请有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本申请的原理及其功效，而非用于限制本申请。任何熟悉此技术的人士皆可在不违背本申请的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本申请所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本申请的权利要求所涵盖。

Claims (10)

1.一种边缘计算系统，其特征在于，应用于医疗，包括：

边缘模块，包括：多个边缘节点；每个边缘节点包括一容器集群，通过容器编排工具进行管理，所述容器编排工具实现有用于进行边缘计算工作的执行单元；

服务分配模块，用于执行全局负载均衡工作，以将用户服务请求路由到目的的边缘节点；

服务管理模块，用于对应所述用户服务请求的服务的管理。

2.根据权利要求1所述的边缘计算系统，其特征在于，所述边缘模块、服务分配模块、及服务管理模块中的一个或多个实现于一台或多台服务器。

3.根据权利要求1所述的边缘计算系统，其特征在于，所述容器为Docker容器。

4.根据权利要求1所述的边缘计算系统，其特征在于，所述容器编排工具为Kubernetes。

5.根据权利要求1所述的边缘计算系统，其特征在于，所述用户服务请求为网页网址用户请求。

6.根据权利要求1所述的边缘计算系统，其特征在于，所述边缘计算系统还包括数据库，所述数据库包括对应所述用户服务请求的服务状态。

7.根据权利要求1所述的边缘计算系统，其特征在于，所述数据库为Mysql数据库。

8.根据权利要求1所述的边缘计算系统，其特征在于，所述用户服务请求为读取请求或写入请求。

9.根据权利要求1所述的边缘计算系统，其特征在于，所述边缘模块包括：阈值保护单元，用于根据Windows-LFU算法记录和实时更新与各个时间对应的边缘节点服务请求的访问量记录。

10.根据权利要求9所述的边缘计算系统，其特征在于，所述Windows-LFU步骤包括：

(1)将用户服务请求分为所述用户服务请求的边缘计算服务已启动服务和未启动服务两种类型，根据近期访问频率分别进行排序；

(2)从所述未启动服务的应用中选择访问频率最高的应用，作为待启动应用，然后从所述已启动服务的应用列表中选择满足替换要求的候选容器集群的应用，其中，选取标替换要求为准替换后是否能够满足待启动的服务所需的资源；

(3)从所述候选容器集群列表中选择访问量最小的应用。

Images