边缘计算系统中有状态应用的访问方法、装置及电子设备与流程

1.本申请涉及边缘计算和计算机技术领域，尤其涉及一种边缘计算系统中有状态应用的访问方法、装置、电子设备及存储介质。


背景技术：

2.相关技术中，在部署的包括多个站点或地域集群内，当位于站点内节点的最小单元pod中所运行的应用，去访问运行于pod的有状态应用时，往往返回的是该集群内所有运行该有状态应用的pod的互联网协议地址，并不区分站点或者地域，从而出现跨地域或者站点访问的情况，而有些业务的应用并不希望或不允许进行跨站点访问。


技术实现要素：

3.本申请实施例提供一种边缘计算系统中有状态应用的访问方法、装置、电子设备及存储介质，能够在应用之间互相访问时，避免出现跨站点访问的情况。
4.本申请实施例的技术方案是这样实现的：
5.本申请实施例提供一种边缘计算系统中有状态应用的访问方法，所述边缘计算系统包括至少两个站点，每个所述站点包括至少一个边缘节点，每个所述边缘节点包括至少一个最小单元，所述方法包括：
6.接收到运行于目标最小单元中的状态应用发送的访问请求，所述访问请求用于访问目标有状态应用；
7.解析所述访问请求，得到用于标识最小单元的目标单元标识；
8.获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于所述域名解析文件，在所述目标最小单元所归属的目标站点内，查找对应所述目标单元标识的目标互联网协议地址；
9.发送所述目标互联网协议地址至所述状态应用，以使所述状态应用基于所述目标互联网协议地址访问所述目标有状态应用。
10.本申请实施例还提供一种边缘计算系统中有状态应用的访问装置，所述边缘计算系统包括至少两个站点，每个所述站点包括至少一个边缘节点，每个所述边缘节点包括至少一个最小单元，所述装置包括：
11.接收模块，用于接收到运行于目标最小单元中的状态应用发送的访问请求，所述访问请求用于访问目标有状态应用；
12.解析模块，用于解析所述访问请求，得到用于标识最小单元的目标单元标识；
13.获取模块，用于获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于所述域名解析文件，在所述目标最小单元所归属的目标站点内，查找对应所述目标单元标识的目标互联网协议地址；
14.发送模块，用于发送所述目标互联网协议地址至所述状态应用，以使所述状态应用基于所述目标互联网协议地址访问所述目标有状态应用。
15.上述方案中，各所述站点分别部署有对应目标业务的至少一个有状态应用，每个所述有状态应用运行于一个最小单元中；
16.所述接收模块，还用于接收到运行于目标最小单元中的状态应用发送的、用于访问部署于所述至少两个站点的有状态应用中目标有状态应用的访问请求。
17.上述方案中，所述边缘计算系统基于无头服务部署，所述无头服务绑定有各所述站点内包括的最小单元；
18.所述接收模块，还用于接收到运行于目标最小单元中的状态应用发送的、携带所述无头服务的服务名称的访问请求；
19.其中，所述服务名称用于指示所述访问请求对应的服务类型为无头服务。
20.上述方案中，所述解析模块，还用于对所述访问请求进行解析，得到所述访问请求中包含的运行所述目标有状态应用的最小单元的单元名称；
21.其中，所述单元名称包括：所述目标有状态应用的应用名称、所述最小单元的单元序号以及所述无头服务的服务名称；
22.将所述运行所述目标有状态应用的最小单元的单元名称，作为用于标识最小单元的目标单元标识。
23.上述方案中，各所述站点内运行所述目标有状态应用的最小单元的目标单元标识之间相一致，所述装置还包括：
24.第一访问模块，用于接收到运行于第一最小单元中的第一状态应用发送的第一访问请求，所述第一最小单元与所述目标最小单元归属于不同的站点，所述第一访问请求用于访问目标有状态应用；
25.解析所述第一访问请求，得到用于标识最小单元的第一单元标识，所述第一单元标识与所述目标单元标识相同；
26.获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于所述域名解析文件，在所述第一最小单元所归属的站点内，查找对应所述第一单元标识的第一互联网协议地址；
27.发送所述第一互联网协议地址至所述第一状态应用，以使所述第一状态应用基于所述第一互联网协议地址访问所述目标有状态应用。
28.上述方案中，所述边缘节点还包括文件维护组件，所述文件维护组件用于维护相应边缘节点所归属站点的域名解析文件；
29.所述获取模块，还用于确定所述目标最小单元所归属的目标边缘节点、以及所归属的目标站点；
30.从所述目标边缘节点的文件维护组件中，获取所述目标站点对应的域名解析文件。
31.上述方案中，所述域名解析文件与所述站点为一一对应关系，所述站点还包括：用于维护相应站点的域名解析文件的文件维护节点；
32.所述获取模块，还用于确定所述目标最小单元所归属的目标站点；
33.从所述文件维护节点中，获取所述目标站点对应的域名解析文件。
34.上述方案中，所述文件维护节点，为相应站点内不同于所述边缘节点的节点；
35.或者，所述文件维护节点，为通过选举机制，从所述站点内包括的至少一个边缘节
点内选举得到的节点。
36.上述方案中，所述文件维护组件，用于监测到针对所述域名解析文件的更新事件时，基于所述更新事件更新所述域名解析文件；
37.所述获取模块，还用于获取基于所述更新事件更新后的、存储有单元标识与互联网协议地址间映射关系的域名解析文件。
38.上述方案中，所述装置还包括：
39.第二访问模块，用于接收到运行于第二最小单元中的第二状态应用发送的第二访问请求，所述第二访问请求用于访问所述目标有状态应用；
40.解析所述第二访问请求，得到用于标识最小单元的第二单元标识；
41.将所述第二单元标识重命名为归属于所述第二最小单元所在站点的、运行所述目标有状态应用的最小单元的真实单元标识；
42.基于所述无头服务，对所述真实单元标识进行域名解析，得到对应所述真实单元标识的第二互联网协议地址；
43.发送所述第二互联网协议地址至所述第二状态应用，以使所述第二状态应用基于所述第二互联网协议地址访问所述目标有状态应用。
44.上述方案中，所述边缘计算系统还包括：有状态应用控制节点；
45.所述有状态应用控制节点，用于当监测到节点创建事件时，在各所述站点内创建至少一个边缘节点，并在各所述边缘节点上部署运行有状态应用的至少一个最小单元。
46.上述方案中，所述有状态应用控制节点，还用于当监测到节点更新事件时，更新各所述站点内的边缘节点，以及
47.更新各所述边缘节点上所部署的运行有状态应用的最小单元。
48.本申请实施例还提供一种电子设备，包括：
49.存储器，用于存储可执行指令；
50.处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的边缘计算系统中有状态应用的访问方法。
51.本申请实施例还提供一种计算机可读存储介质，存储有可执行指令，所述可执行指令被处理器执行时，实现本申请实施例提供的边缘计算系统中有状态应用的访问方法。
52.本申请实施例具有以下有益效果：
53.在包括至少两个站点的边缘计算系统中，每个站点所包括的至少一个边缘节点上均部署有至少一个最小单元，当接收到运行于目标最小单元的状态应用所发送的、用于访问目标有状态应用的访问请求时，对该访问请求进行解析，得到目标单元标识，从而基于该目标单元标识，在存储有单元标识与互联网协议地址间映射关系的域名解析文件中，查找到属于目标最小单元所归属的目标站点内、且与目标单元标识存在映射关系的目标互联网协议地址，将该目标互联网协议地址发送至状态应用，以使该状态应用基于目标互联网协议地址访问目标有状态应用；如此，所返回状态应用的目标互联网协议地址是在目标最小单元所归属的目标站点内查找到的，在状态应用在访问有状态应用时，能够避免出现跨站点访问的情况。
附图说明
54.图1是本申请实施例提供的边缘计算系统中有状态应用的访问系统100的架构示意图；
55.图2是本申请实施例提供的边缘计算系统中有状态应用的访问方法的电子设备500的结构示意图；
56.图3是本申请实施例提供的边缘计算系统中有状态应用的访问方法的流程示意图；
57.图4是本申请实施例提供的边缘计算系统的结构示意图；
58.图5是本申请实施例提供的有状态应用的部署示意图；
59.图6是本申请实施例提供的文件维护组件维护域名解析文件的示意图；
60.图7是本申请实施例的在不同站点内访问具有相应单元标识的有状态应用的示意图；
61.图8是本申请实施例提供的边缘计算集群的架构示意图；
62.图9是本申请实施例提供的边缘计算系统中有状态应用的访问装置555的结构示意图。
具体实施方式
63.为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
64.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
65.在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
66.除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
67.对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
68.1)边缘计算，是一种分散式运算的架构。在这种架构下，将应用程序、数据资料与服务的运算，由网络中心节点，移往网络逻辑上的边缘节点来处理。或者说，边缘运算将原本完全由中心节点处理大型服务加以分解，切割成更小与更容易管理的部分，分散到边缘节点去处理。边缘节点更接近于用户终端装置，可以加快资料的处理与传送速度，减少延迟。也就是以前由服务器作计算的部分，现在改由信息采集的设备直接计算了，再把计算的结果，直接输出到服务器中。服务器只要结果，并不需要过程的数据。
69.2)kubernetes，简称k8s，是一个开源的、用于管理云平台中多个主机上的容器化
的应用，kubernetes的目标是让部署容器化的应用简单并且高效，kubernetes提供了应用部署，规划，更新，维护的一种机制。
70.3)pod，kubernetes集群中的最小单元。
71.4)无头服务(headless service)，相较于一般service的区别在于不分配虚拟ip(即culsterip)；解析headless service通过core
‑
dns返回所有pod的地址和集群内域名。
72.5)端口服务器apiserver，是一个负责监听指定的端口的服务器，提供k8s各类资源对象的增，删，改等事件的监听。
73.6)标签label，是kubernetes系列中的一个核心概念。是一组绑定到k8s资源对象上的key/value对。同一个对象的labels属性的key必须唯一。label可以附加到各种资源对象上，通过给指定的资源对象捆绑一个或多个不用的label来实现多维度的资源分组管理功能，以便于灵活，方便地进行资源分配，调度，配置，部署等管理工作。
74.7)标签选择器label selector，是kubernetes核心的分组机制，通过label selector客户端/用户能够识别一组有共同特征或属性的资源对象。
75.8)有状态应用，一般服务器端都要保存与请求的相关信息，每个请求可以默认地使用之前的请求信息。
76.9)无状态应用，一般服务器端所能够处理的过程全部来自于请求所携带的信息或者其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息。
77.10)全限定域名(fully qualified domain name，fqdn)：同时带有主机名和域名的名称。
78.11)statefulset，有状态的集合，管理所有有状态应用，所管理的pod拥有固定的pod名称，启停顺序，在statefulset中，pod名字称为网络标识。在statefulset中与之对应的还有headless service，statefulset在headless service的基础上又为statefulset控制的每个pod副本创建了一个dns域名。
79.12)hosts，是一个没有扩展名的系统文件，可以用记事本等工具打开，其作用就是将一些常用的网址域名与其对应的ip地址建立一个关联“数据库”，当用户在浏览器中输入一个需要登录的网址时，系统会首先自动从hosts文件中寻找对应的ip地址，一旦找到，系统会立即打开对应网页，如果没有找到，则系统会再将网址提交dns域名解析服务器进行ip地址的解析。
80.13)yaml，是一个可读性高，用来表达数据序列化的格式。
81.14)operator，是一个感知应用状态的控制器，通过扩展kubernetes api来自动创建、管理和配置应用实例。operator基于crd(custom resource definition)扩展资源对象，并通过控制器来保证应用处于预期状态。
82.15)用户自定义资源(crd，custom resource definition)。
83.16)coredns，是一种快速灵活的dns服务，可通过插件的方式实现。
84.基于上述对本申请实施例中涉及的名词和术语的解释，下面说明本申请实施例提供的边缘计算系统中有状态应用的访问系统。参见图1，图1是本申请实施例提供的边缘计算系统中有状态应用的访问系统100的架构示意图，该边缘计算系统包括：至少两个站点，每个站点包括至少一个边缘节点和域名解析服务节点，每个边缘节点包括至少一个最小单元。为实现支撑一个示例性应用，边缘节点(如边缘节点400
‑
1和边缘节点400
‑
2)通过网络
300连接域名解析服务节点200，网络300可以是广域网或者局域网，又或者是二者的组合，使用无线或有线链路实现数据传输。
85.边缘节点(如边缘节点400
‑
1)部署有运行状态应用的目标最小单元，用于发送运行于目标最小单元中的状态应用针对目标有状态应用的访问请求；
86.域名解析服务节点200，用于接收到运行于目标最小单元中的状态应用发送的访问请求；解析访问请求，得到用于标识最小单元的目标单元标识；获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于域名解析文件，在目标最小单元所归属的目标站点内，查找对应目标单元标识的目标互联网协议地址；发送目标互联网协议地址至状态应用；
87.边缘节点(如边缘节点400
‑
1)部署的目标最小单元中所运行的状态应用，用于接收目标互联网协议地址，基于目标互联网协议地址访问目标有状态应用。
88.本申请实施例可以借助于云技术(cloud technology)实现，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。
89.云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、以及应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源。
90.在实际应用中，域名解析服务节点200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。
91.参见图2，图2是本申请实施例提供的边缘计算系统中有状态应用的访问方法的电子设备500的结构示意图。在实际应用中，电子设备500可以为图1示出的服务器或终端，以电子设备500为图1示出的域名解析节点为例，对实施本申请实施例的边缘计算系统中有状态应用的访问方法的电子设备进行说明，本申请实施例提供的电子设备500包括：至少一个处理器510、存储器550、至少一个网络接口520和用户接口530。电子设备500中的各个组件通过总线系统540耦合在一起。可理解，总线系统540用于实现这些组件之间的连接通信。总线系统540除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统540。
92.处理器510可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(dsp，digital signal processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
93.用户接口530包括使得能够呈现媒体内容的一个或多个输出装置531，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口530还包括一个或多个输入装置532，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
94.存储器550可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器550可选地包括在物理位置上远离处理器510的一
个或多个存储设备。
95.存储器550包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(rom，read only me mory)，易失性存储器可以是随机存取存储器(ram，random access memor y)。本申请实施例描述的存储器550旨在包括任意适合类型的存储器。
96.在一些实施例中，存储器550能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
97.操作系统551，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
98.网络通信模块552，用于经由一个或多个(有线或无线)网络接口520到达其他计算设备，示例性的网络接口520包括：蓝牙、无线相容性认证(wifi)、和通用串行总线(usb，universal serial bus)等；
99.呈现模块553，用于经由一个或多个与用户接口530相关联的输出装置531(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；
100.输入处理模块554，用于对一个或多个来自一个或多个输入装置532之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
101.在一些实施例中，本申请实施例提供的边缘计算系统中有状态应用的访问装置可以采用软件方式实现，图2示出了存储在存储器550中的边缘计算系统中有状态应用的访问装置555，其可以是程序和插件等形式的软件，包括以下软件模块：接收模块5551、解析模块5552、获取模块5553和发送模块5554，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分，将在下文中说明各个模块的功能。
102.在另一些实施例中，本申请实施例提供的边缘计算系统中有状态应用的访问装置可以采用软硬件结合的方式实现，作为示例，本申请实施例提供的边缘计算系统中有状态应用的访问装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的边缘计算系统中有状态应用的访问方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(asic，application specific integrated circuit)、dsp、可编程逻辑器件(pld，programmable logic device)、复杂可编程逻辑器件(cpld，complex progra mmable logic device)、现场可编程门阵列(fpga，field
‑
programmable gatearray)或其他电子元件。
103.基于上述对本申请实施例提供的边缘计算系统中有状态应用的访问系统及电子设备的说明，下面说明本申请实施例提供的边缘计算系统中有状态应用的访问方法。本申请实施例提供的边缘计算系统包括至少两个站点，每个站点包括至少一个边缘节点，每个边缘节点包括至少一个最小单元，参见图3，图3是本申请实施例提供的边缘计算系统中有状态应用的访问方法的流程示意图，本申请实施例提供的边缘计算系统中有状态应用的访问方法包括：
104.步骤101：域名解析服务接收到运行于目标最小单元中的状态应用发送的访问请求。
105.其中，该访问请求用于访问目标有状态应用。
106.这里，该边缘计算系统包括至少两个站点，每个站点包括至少一个边缘节点，每个边缘节点包括至少一个最小单元，该最小运行单元中运行有预先部署的有状态应用和无状态应用，所部署的有状态应用包括上述目标有状态应用。该域名解析服务可以是位于边缘计算系统中各站点内所包含的域名解析服务节点，也可以是各站点内每个边缘节点中所集成的域名解析服务组件。
107.在一些实施例中，可通过如下方式部署该边缘计算系统：该边缘计算系统还包括有状态应用控制节点；该有状态应用控制节点，用于当监测到节点创建事件时，在各站点内创建至少一个边缘节点，并在各边缘节点上部署运行有状态应用的至少一个最小单元。
108.在实际应用中，针对目标微服务(该目标微服务对应一组有业务逻辑联系的有状态应用)，在各个站点内部署有状态应用statefulset，具体是将有状态应用statefulset部署在各站点内包括的各个边缘节点上，以使该多个边缘节点共同运行一组有业务逻辑联系的有状态应用。这里，每个站点内部署的有状态应用statefulset的名称相一致。在实际应用中，将有状态应用statefulset部署到各边缘节点的具体过程是，将有状态应用statefulset部署到各个边缘节点包括的最小单元pod上，以使每个pod运行所部署的有状态应用。在实际实施时，各个po d运行的应用之间可以通过pod对应的ip地址进行互相调用。参见图4，图4是本申请实施例提供的边缘计算系统的结构示意图。这里，该边缘计算集群中包括3个站点，每个站点内包括3个边缘节点，各站点包括3个边缘节点，该站点所包括的各个边缘节点共同运行部署在最小单元pod上的一组有状态应用，该一组有状态应用有业务逻辑联系，用于实现目标微服务。
109.在一些实施例中，有状态应用控制节点，还用于当监测到节点更新事件时，更新各站点内的边缘节点，以及更新各边缘节点上所部署的运行有状态应用的最小单元。
110.在实际应用中，该有状态应用控制节点还可以控制边缘节点的更新、以及各边缘节点上所部署的运行有状态应用的最小单元的更新。该节点更新事件包括边缘节点的增加、删除、和修改事件，以及所部署的运行有状态应用的最小单元的增加、删除、和修改事件。
111.参见图5，图5是本申请实施例提供的有状态应用的部署示意图。这里，可通过如下方式部署有状态应用statefulset：在云端部署有状态应用控制节点(即statefulset
‑
grid controller)。当statefulsetgrid资源创建时，即监测到节点创建事件时，有状态应用控制节点statefulset
‑
grid controller在不同的地域或站点内(如图5所示，包括3个站点)，通过节点选择器node selector的命名指示信息(包括zone:zone
‑
1、zone:zone
‑
2以及zone:zone
‑
3)在各站点的节点上部署有状态应用statefulset，各节点上的有状态应用的名称分别为statefulset
‑
zone
‑
1、statefulset
‑
zone
‑
2、以及statefulset
‑
zone
‑
3。
112.继续地，通过监听节点node、有状态应用statefulset、statefulsetgrid这三类资源的增加add、删除delete、更新update事件，将各地域或站点内的statef ulset保持和statefulsetgrid声明的状态相一致。具体地，比如statefulsetgrid中的statefulset
‑
template字段发生了变化，则表明会触发一个update事件，statef ulset
‑
grid controller就会在各个地域或者站点内更新statefulset的template字段，以使得各地域或者站点内的statefulset的template字段，保持和statefulsetgrid中的statefulset
‑
template字段相一致。
113.当运行于目标最小单元的状态应用需要访问目标有状态应用时，可以向域名解析服务发送用户访问目标有状态应用的访问请求，该状态应用可以是有状态应用，也可以是无状态应用。此时，域名解析服务接收到状态应用发送的访问请求。
114.在一些实施例中，各站点分别部署有对应目标业务的至少一个有状态应用，每个有状态应用运行于一个最小单元中；相应的，域名解析服务可通过如下方式接收到运行于目标最小单元中的状态应用发送的访问请求：接收到运行于目标最小单元中的状态应用发送的、用于访问部署于至少两个站点的有状态应用中目标有状态应用的访问请求。
115.这里，在边缘计算系统部署完成后，各站点分别部署有对应目标业务的至少一个有状态应用，每个有状态应用运行于一个最小单元中，域名解析服务则接收到运行于目标最小单元中的状态应用发送的、用于访问部署于至少两个站点的有状态应用中目标有状态应用的访问请求。
116.在一些实施例中，边缘计算系统基于无头服务部署，无头服务绑定有各站点内包括的最小单元；相应的，域名解析服务可通过如下方式接收到运行于目标最小单元中的状态应用发送的访问请求：接收到运行于目标最小单元中的状态应用发送的、携带无头服务的服务名称的访问请求；其中，该服务名称用于指示访问请求对应的服务类型为无头服务。
117.在实际应用中，该边缘计算系统是基于无头服务模式所部署的，该无头服务通过label selector绑定有各站点内、部署于相应边缘节点上的至少一个最小单元。基于此，在发送访问请求时，该访问请求中需要携带无头服务的服务名称，此时，域名解析服务接收到运行于目标最小单元中的状态应用发送的、携带无头服务的服务名称的访问请求。这里，该服务名称用于指示访问请求对应的服务类型为无头服务。
118.步骤102：解析访问请求，得到用于标识最小单元的目标单元标识。
119.当域名解析服务接收到该访问请求后，对访问请求进行解析，得到用于标识最小单元的目标单元标识，该目标单元标识可以是运行该目标有状态应用的最小单元的单元名称，比如最小单元pod的全限定域名fqdn。
120.在一些实施例中，域名解析服务可通过如下方式解析访问请求，得到用于标识最小单元的目标单元标识：对访问请求进行解析，得到访问请求中包含的运行目标有状态应用的最小单元的单元名称；将运行目标有状态应用的最小单元的单元名称，作为用于标识最小单元的目标单元标识。其中，该单元名称包括：目标有状态应用的应用名称、最小单元的单元序号以及无头服务的服务名称。
121.在实际应用中，当域名解析服务接收到该访问请求后，对访问请求进行解析，得到访问请求中包含的运行目标有状态应用的最小单元的单元名称。这里，该运行目标有状态应用的最小单元的单元名称，基于目标有状态应用的应用名称、最小单元的单元序号以及无头服务的服务名称组成，比如该单元名称可以是最小单元pod的全限定域名fqdn：<statefulsetgrid
‑
name>
‑
<id>.<headless
‑
ser vice
‑
name>.default.svc.cluster.local。然后将该运行目标有状态应用的最小单元的单元名称，作为用于标识最小单元的目标单元标识。
122.步骤103：获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于域名解析文件，在目标最小单元所归属的目标站点内，查找对应目标单元标识的目标互联网协议地址。
123.在本申请实施例中，预先设置了存储有单元标识与互联网协议地址间映射关系的域名解析文件。当域名解析服务解析访问请求得到目标单元标识时，基于该域名解析文件，在目标最小单元所归属的目标站点内(即运行状态应用的最小单元所归属的站点)，查找对应目标单元标识的目标互联网协议地址。该目标互联网协议地址，用于供该状态应用基于该目标互联网协议地址访问目标有状态应用。
124.在一些实施例中，边缘节点还包括文件维护组件，该文件维护组件用于维护相应边缘节点所归属站点的域名解析文件；相应的，域名解析服务可通过如下方式获取存储有单元标识与互联网协议地址间映射关系的域名解析文件：确定目标最小单元所归属的目标边缘节点、以及所归属的目标站点；从目标边缘节点的文件维护组件中，获取目标站点对应的域名解析文件。
125.这里，在每个边缘节点内均设置有文件维护组件，用于维护相应边缘节点所归属站点的域名解析文件。当域名解析服务需要获取域名解析文件时，可以先确定目标最小单元所归属的目标边缘节点、以及所归属的目标站点，然后从目标边缘节点的文件维护组件中，获取目标站点对应的域名解析文件。
126.在一些实施例中，该文件维护组件，用于监测到针对域名解析文件的更新事件时，基于更新事件更新域名解析文件；相应的，域名解析服务可通过如下方式获取存储有单元标识与互联网协议地址间映射关系的域名解析文件：获取基于更新事件更新后的、存储有单元标识与互联网协议地址间映射关系的域名解析文件。
127.这里，该文件维护组件还可以监测针对域名解析文件的更新事件，该更新事件包括域名解析文件中的最小单元的增加事件、删减事件以及修改事件。当文件维护组件监测到针对域名解析文件的更新事件时，基于更新事件更新域名解析文件。此时，域名解析服务则可以获取基于更新事件更新后的域名解析文件，从而基于更新后的域名解析文件进行目标互联网协议地址的查找。
128.参见图6，图6是本申请实施例提供的文件维护组件维护域名解析文件的示意图。这里，在每个边缘节点上还部署有statefulset
‑
grid
‑
daemon组件(即上述文件维护组件)，该statefulset
‑
grid
‑
daemon组件通过监听云端的apiserver维护(包括更新、删除、增加)域名解析文件，该域名解析文件中存储了pod fqdn(即pod的单元标识)与本站点(当前边缘节点所在站点)的pod的真实ip的映射关系。通过每个边缘节点的域名解析服务coredns的hosts插件加载域名解析文件。如此便达到了一个效果，即不同的站点访问相同的pod fqdn，返回的pod ip是不同的，都是属于本站点或区域的pod的ip。
129.在一些实施例中，域名解析文件与站点为一一对应关系，站点还包括：用于维护相应站点的域名解析文件的文件维护节点；相应的，域名解析服务可通过如下方式获取存储有单元标识与互联网协议地址间映射关系的域名解析文件：确定目标最小单元所归属的目标站点；从文件维护节点中，获取目标站点对应的域名解析文件。
130.这里，在实际应用中，还可以在各个站点内设置用于维护相应站点的域名解析文件的文件维护节点。当域名解析服务需要获取域名解析文件时，可以先确定目标最小单元所归属的目标站点，然后从文件维护节点中，获取目标站点对应的域名解析文件。
131.在一些实施例中，文件维护节点，为相应站点内不同于边缘节点的节点；或者，文件维护节点，为通过选举机制，从站点内包括的至少一个边缘节点内选举得到的节点。
132.在实际应用中，该文件维护节点可以是相应站点内不同各边缘节点的节点，也可以是通过选举机制，从站点内包括的至少一个边缘节点内选举得到的节点。
133.这里，该文件维护节点也可以监测针对域名解析文件的更新事件，该更新事件包括域名解析文件中的最小单元的增加事件、删减事件以及修改事件。当文件维护节点监测到针对域名解析文件的更新事件时，基于更新事件更新域名解析文件。此时，域名解析服务则可以获取基于更新事件更新后的域名解析文件，从而基于更新后的域名解析文件进行目标互联网协议地址的查找。
134.步骤104：发送目标互联网协议地址至状态应用，以使状态应用基于目标互联网协议地址访问目标有状态应用。
135.这里，当域名解析服务查找到对应目标单元标识的目标互联网协议地址后，将该目标互联网协议地址发送至状态应用；该状态应用接收该目标互联网协议地址，从而基于目标互联网协议地址访问目标有状态应用。
136.在一些实施例中，各站点内运行目标有状态应用的最小单元的目标单元标识之间相一致，基于此，域名解析服务接收到运行于第一最小单元中的第一状态应用发送的第一访问请求，该第一最小单元与目标最小单元归属于不同的站点，该第一访问请求用于访问目标有状态应用；解析第一访问请求，得到用于标识最小单元的第一单元标识，第一单元标识与目标单元标识相同；获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于域名解析文件，在第一最小单元所归属的站点内，查找对应第一单元标识的第一互联网协议地址；发送第一互联网协议地址至第一状态应用，以使第一状态应用基于第一互联网协议地址访问目标有状态应用。
137.在实际应用中，该各站点内运行目标有状态应用的最小单元的目标单元标识之间相一致，当位于不同于目标站点的其他站点内的第一最小单元运行的第一状态应用，也需要访问该目标有状态应用时，发送用于访问目标有状态应用的第一访问请求至域名解析服务。该域名解析服务接收到运行于第一最小单元中的第一状态应用发送的第一访问请求，对第一访问请求进行解析，得到用于标识最小单元的第一单元标识，该第一单元标识可以是运行该目标有状态应用的最小单元的单元名称，比如最小单元pod的全限定域名fqdn。
138.继续地，域名解析服务获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于域名解析文件，在第一最小单元所归属的站点内，查找对应第一单元标识的第一互联网协议地址；发送第一互联网协议地址至第一状态应用；第一状态应用接收到该第一互联网协议地址，从而基于第一互联网协议地址访问目标有状态应用。
139.参见图7，图7是本申请实施例的在不同站点内访问具有相应单元标识的有状态应用的示意图。这里，通过有状态应用控制节点statefulset
‑
grid control ler分别在两个站点(包括站点1(即nodeunit1)和站点2(即nodeunit2))内部署了两个有状态应用statefulset，分别是边缘节点1部署的有状态应用1(名称可以为statefulsetgrid
‑
demo
‑
nodeunit1)和边缘节点2部署的有状态应用2(名称可以为statefulsetgrid
‑
demo
‑
nodeunit2)，该有状态应用1具体部署于边缘节点1上的最小单元pod1(名称为statefulsetgrid
‑
demo
‑
nodeunit1
‑
0)和最小单元po d2(名称为statefulsetgrid
‑
demo
‑
nodeunit1
‑
1)；该有状态应用2具体部署于边缘节点2上的最小单元pod3(名称为statefulsetgrid
‑
demo
‑
nodeunit2
‑
0)和最小单元pod4(名称为statefulsetgrid
‑
demo
‑
nodeunit2
‑
1)。同时创建了一个headless service纳管这两个有状态应用，名称为svc
‑
demo。这里，该有状态应用1和有状态应用2为针对同一微服务的有状态应用。
140.在不同的站点内，状态应用1(即client1)和状态应用3(即client3)访问相同的最小单元的单元标识(比如pod的fqdn)，如最小单元的单元标识1(即statefulsetgrid
‑
demo
‑
0.svc
‑
demo.default.svc.cluster.local)，域名解析服务coredns会返回不同最小单元pod的互联网协议地址ip，比如在站点1内，会返回最小单元的互联网协议地址1(即pod：statefulsetgrid
‑
demo
‑
nodeunit1
‑
0的ip)；在站点2内，会返回最小单元的互联网协议地址2(即pod：statefulsetgrid
‑
demo
‑
nodeunit2
‑
0的ip)。
141.在一些实施例中，边缘计算系统基于无头服务部署，无头服务绑定有各站点内包括的最小单元；最小单元的单元标识，由目标有状态应用的应用名称、最小单元的单元序号以及无头服务的服务名称构成；基于此，域名解析服务接收到运行于第二最小单元中的第二状态应用发送的第二访问请求，该第二访问请求用于访问目标有状态应用；解析第二访问请求，得到用于标识最小单元的第二单元标识；将目标单元标识重命名为归属于第二最小单元所在站点的、运行目标有状态应用的最小单元的真实单元标识；基于无头服务，对真实单元标识进行域名解析，得到对应真实单元标识的第二互联网协议地址；发送第二互联网协议地址至第二状态应用，以使第二状态应用基于第二互联网协议地址访问目标有状态应用。
142.这里，除了可以通过域名解析文件查找运行目标有状态应用的最小单元的ip地址外，还可以通过如下方式实现：域名解析服务接收到运行于第二最小单元中的第二状态应用发送的第二访问请求，然后对第二访问请求进行解析，得到用于标识最小单元的第二单元标识；将第二单元标识，通过重命名插件(即rename插件)重命名为归属于第二最小单元所在站点的、运行目标有状态应用的最小单元的真实单元标识；基于无头服务，对真实单元标识进行域名解析，得到对应真实单元标识的第二互联网协议地址；发送第二互联网协议地址至第二状态应用，以使第二状态应用基于第二互联网协议地址访问目标有状态应用。
143.具体地，域名解析服务的rename插件，将访问的pod fqdn重命名为真实的pod的fqdn。例如：在nodeunit1站点上将pod fqdn：statefulset
‑
demo
‑
0.svc
‑
demo.default.svc.cluster.local重命名为真实的pod fqdn：statefulset
‑
demo
‑
nodeunit1
‑
0.svc
‑
demo.default.svc.cluster.local；然后再通过coredns对真实的pod fqdn进行域名解析，得到pod的真实ip。
144.应用本申请上述实施例，在包括至少两个站点的边缘计算系统中，每个站点所包括的至少一个边缘节点上均部署有至少一个最小单元，当接收到运行于目标最小单元的状态应用所发送的、用于访问目标有状态应用的访问请求时，对该访问请求进行解析，得到目标单元标识，从而基于该目标单元标识，在存储有单元标识与互联网协议地址间映射关系的域名解析文件中，查找到属于目标最小单元所归属的目标站点内、且与目标单元标识存在映射关系的目标互联网协议地址，将该目标互联网协议地址发送至状态应用，以使该状态应用基于目标互联网协议地址访问目标有状态应用；如此，所返回状态应用的目标互联网协议地址是在目标最小单元所归属的目标站点内查找到的，在状态应用在访问有状态应用时，能够避免出现跨站点访问的情况。
145.下面将说明本申请实施例在一个实际的应用场景中的示例性应用。
146.在本申请实施例中，考虑如下场景：在一个用于边缘计算的集群中，每个拥有多个边缘节点的站点内都运行一组有业务逻辑联系的有状态服务，每个站点内的有状态服务组成一套完整的微服务以向用户提供服务；这里，每个站点内包括多个边缘节点，由于受到网络限制，有业务联系的有状态服务之间不希望或者不能跨站点访问。
147.基于此，本申请实施例首先提供一种边缘计算集群的部署方法，该方法是使用原生的kubernetes对statefulset和headless service按照站点进行名称的区分，具体方案如下：针对处于不同站点内的节点所部署的有状态应用statefulset和对应的headless service，设置不同的名称。如图8所示，图8是本申请实施例提供的边缘计算集群的架构示意图，这里，该边缘计算集群内包括：两个he adless service服务和两个有状态应用statefulset，在站点1(即site
‑
1)和站点2(即site
‑
2)内分别命名为无头服务a(headless
‑
svc
‑
a)，有状态应用a(statef ulset
‑
a)和无头服务b(headless
‑
svc
‑
b)，有状态应用b(statefulset
‑
b)。
148.如此，当对服务和负载进行访问时，根据headless service和有状态应用st atefulset的特点，用户可采用<statefulsetgrid
‑
name>
‑
<id>.<headless
‑
service
‑
name>.default.svc.cluster.local的方式对服务和负载进行访问。而为了将各服务之间的访问锁定在同一个站点内，不同站点的用户需要访问不同的域名，如站点site
‑
1中的用户需要访问域名statefulset
‑
a
‑
0.headless
‑
svc
‑
a.default.svc.cluster.local，站点site
‑
2中的用户需要访问域名statefulset
‑
b
‑
0.headless
‑
svc
‑
b.default.svc.clust er.local。
149.但是，申请人在实施过程中发现，服务和有状态应用在不同站点名字不同，因而服务之间不能简单地通过相同的服务名来调用，而是在站点site
‑
1中使用statefulset
‑
a
‑
id.headless
‑
svc
‑
a.default.svc.cluster.local，在站点site
‑
2中使用state fulset
‑
b
‑
0.headless
‑
svc
‑
b.default.svc.cluster.local。可见，上述方案对于调用方的复杂度极高，对业务极为不友好；同时对于部署而言，如果站点、有状态应用、headless service的数量非常多，鉴于这三者需要通过标签选择器label selector和节点选择器node selector等进行关联，最终部署的时候，会产生这三者数量相乘数量的部署yaml文件，对于部署的难度极大。
150.因此，为解决上述存在的问题，本申请实施例还提供一种边缘计算系统的部署方法、以及边缘计算系统中有状态应用的访问方法，即提出和实现了边缘计算场景下有状态应用和headless service的管理方案。该方法通过两个yaml文件即可轻松实现多个站点(甚至于上百站点或地域)的有状态应用的部署，且不需要应用的适配和改造，可以方便地在共属同一个集群的不同站点或区域中各自部署一组有状态应用；同时能够使对有状态应用匹配的headless service的访问请求在本站点内或本地域内即可完成，避免服务跨地域和站点访问。
151.在本申请中，如图4所示，图4描述了在边缘计算集群包括的多个站点内部署微服务，该边缘计算集群中包括3个边缘站点，每个边缘站点内包括至少一个边缘节点。针对目标微服务(该目标微服务对应一组有业务逻辑联系的有状态应用)，在各个站点内部署有状态应用statefulset，具体是将有状态应用sta tefulset部署在各站点内包括的各个边缘节点上，以使该多个边缘节点共同运行一组有业务逻辑联系的有状态应用。这里，每个站点
内部署的有状态应用state fulset的名称相一致。在实际应用中，将有状态应用statefulset部署到各边缘节点的具体过程是，将有状态应用statefulset部署到各个边缘节点包括的最小单元pod上，以使每个pod运行所部署的有状态应用。在实际实施时，各个pod运行的应用之间可以通过pod对应的ip地址进行互相调用和访问。
152.具体地，如图5所示，可通过如下方式部署有状态应用statefulset：首先，在云端部署有状态应用控制组件statefulset
‑
grid controller，该statefulset
‑
grid controller组件是基于kubernetes的operator技术。本申请实施例中，创建了名称为statefulsetgrid的crd资源对象，其形式如下所示：
153.api版本apiversion:superedge.io/v1；
154.种类kind:statefulsetgrid；
155.元数据metadata:
156.名称name:statefulsetgrid
‑
demo；
157.命名空间namespace:default；
158.crd的组spec:
159.站点或地域griduniqkey:<nodelabel key>
160.有状态应用标准字段<statefulset
‑
template>
161.上述形式的crd资源对象中可以包含边缘计算系统的创建指示信息，比如边缘计算系统包含的站点的名称和数量、节点的名称和数量、有状态应用的名称、最小单元的数量等信息，除了griduniqkey字段用于指定地域或站点的划分，其余字段与有状态应用statefulset标准的字段一致。这里，首先，当statefulset grid资源(即上述crd资源对象)创建时，即监测到节点创建事件时，有状态应用控制节点statefulset
‑
grid controller在不同的地域或站点内创建具有不同node selector的有状态应用statefulset；然后，通过监听节点node、有状态应用statefulset、statefulsetgrid这三类资源的增加add、删除delete、更新update事件，将各地域或站点内的statefulset保持和statefulsetgrid声明的状态相一致。具体地，比如statefulsetgrid中的statefulset
‑
template字段发生了变化，则表明会触发一个update事件，statefulset
‑
grid controller就会在各个地域或者站点内新statefulset的template字段，以使得各地域或者站点内的statefulset的templat e字段，保持和statefulsetgrid中的statefulset
‑
template字段相一致。
162.同时，还创建用于管理各个站点的有状态应用statefulset(具体是每个运行有状态应用的pod)的无头服务headless service，该headless service会通过la bel selector包含所有地域的有状态应用statefulset。该headless service为一个虚拟概念，当其他pod访问运行有状态应用的目标pod时，通过访问headless service实现。具体是其他pod针对headless service的访问，实际上是访问hea dless service管理的多个运行有状态应用的pod，即通过访问headless service，得到待访问的真实pod的ip。
163.进一步地，为了实现在站点内对有状态应用statefulset对应的headless ser vice的访问也能限制在本站点内，不会跨站点访问，即为了达到边缘节点访问该headless service时，只返回与边缘节点所处地域或站点的pod的ip的目的，如图6所示，在每个边缘节点上还部署有文件维护组件statefulset
‑
grid
‑
daemon组件，该statefulset
‑
grid
‑
daemon组件通过监听apiserver维护(包括更新、删除、增加)一个本地文件，该本地文件存
储了pod fqdn(即pod的名称)与本站点(当前边缘节点所在站点)的pod的真实ip的映射关系。通过每个边缘节点的coredns的hosts插件加载。如此便达到了一个效果，即不同的站点访问相同的pod fqdn，返回的pod ip是不同的，都是属于本站点或区域的pod的ip。
164.参见图7，图7是本申请实施例的在不同站点内访问具有相应单元标识的有状态应用的示意图。这里，通过有状态应用控制节点statefulset
‑
grid control ler分别在两个站点(包括站点1(即nodeunit1)和站点2(即nodeunit2))内部署了两个有状态应用statefulset，分别是边缘节点1部署的有状态应用1(名称可以为statefulsetgrid
‑
demo
‑
nodeunit1)和边缘节点2部署的有状态应用2(名称可以为statefulsetgrid
‑
demo
‑
nodeunit2)，该有状态应用1具体部署于边缘节点1上的最小单元pod1(名称为statefulsetgrid
‑
demo
‑
nodeunit1
‑
0)和最小单元po d2(名称为statefulsetgrid
‑
demo
‑
nodeunit1
‑
1)；该有状态应用2具体部署于边缘节点2上的最小单元pod3(名称为statefulsetgrid
‑
demo
‑
nodeunit2
‑
0)和最小单元pod4(名称为statefulsetgrid
‑
demo
‑
nodeunit2
‑
1)。同时创建了一个headless service纳管这两个有状态应用，名称为svc
‑
demo。这里，该有状态应用1和有状态应用2为针对同一微服务的有状态应用。
165.在不同的站点内，状态应用1(即client1)和状态应用3(即client3)访问相同的最小单元的单元标识(比如pod的fqdn)，如最小单元的单元标识1(即statefulsetgrid
‑
demo
‑
0.svc
‑
demo.default.svc.cluster.local)，域名解析服务coredns会返回不同最小单元pod的互联网协议地址ip，比如在站点1内，会返回最小单元的互联网协议地址1(即pod：statefulsetgrid
‑
demo
‑
nodeunit1
‑
0的ip)；在站点2内，会返回最小单元的互联网协议地址2(即pod：statefulsetgrid
‑
demo
‑
nodeunit2
‑
0的ip)。
166.具体实施时，文件维护组件(即statefulset
‑
grid
‑
daemon组件)除了维护po d fqdn与pod ip的映射，还可以借用coredns的重命名插件(即rename插件)，将访问的pod fqdn重命名为真实的pod的fqdn。例如：在nodeunit1站点上将pod fqdn：statefulset
‑
demo
‑
0.svc
‑
demo.default.svc.cluster.local重命名为真实的pod fqdn：statefulset
‑
demo
‑
nodeunit1
‑
0.svc
‑
demo.default.svc.cluster.local；然后再通过coredns对真实的pod fqdn进行域名解析，得到pod的真实ip。这里，该client可以是边缘节点包括的某个pod内运行的应用，可以是有状态应用，也可以是无状态应用。
167.如此，保证了相同站点或者区域内的服务的互相访问一定会限制在当前站点范围内，避免了跨节点组或者跨机房跨地域访问的问题。
168.应用本申请上述实施例，可以便捷地在边缘计算场景中的不同地域或站点内分别部署有状态应用statefulset，同时能够便捷地使对有状态应用statefulset对应的headless service的访问，限制在有状态应用statefulset所部署的节点所在的地域或站点内，弥补了当前边缘计算场景下有状态应用和headless service的管理方案的缺失；另外，虽然原生kubernetes可以实现对这种功能的支持，但是实现的代价非常大，不论是部署还是使用代价都很高，通过本申请实施例，可以大大降低有状态应用和headless service在边缘计算场景的落地难度和使用难度。
169.下面继续说明本申请实施例提供的边缘计算系统中有状态应用的访问装置555，在一些实施例中，边缘计算系统中有状态应用的访问装置可采用软件模块的方式实现。参见图9，图9是本申请实施例提供的边缘计算系统中有状态应用的访问装置555的结构示意
图，本申请实施例提供的边缘计算系统中有状态应用的访问装置555包括：
170.接收模块5551，用于接收到运行于目标最小单元中的状态应用发送的访问请求，所述访问请求用于访问目标有状态应用；
171.解析模块5552，用于解析所述访问请求，得到用于标识最小单元的目标单元标识；
172.获取模块5553，用于获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于所述域名解析文件，在所述目标最小单元所归属的目标站点内，查找对应所述目标单元标识的目标互联网协议地址；
173.发送模块5554，用于发送所述目标互联网协议地址至所述状态应用，以使所述状态应用基于所述目标互联网协议地址访问所述目标有状态应用。
174.在一些实施例中，各所述站点分别部署有对应目标业务的至少一个有状态应用，每个所述有状态应用运行于一个最小单元中；
175.所述接收模块5551，还用于接收到运行于目标最小单元中的状态应用发送的、用于访问部署于所述至少两个站点的有状态应用中目标有状态应用的访问请求。
176.在一些实施例中，所述边缘计算系统基于无头服务部署，所述无头服务绑定有各所述站点内包括的最小单元；
177.所述接收模块5551，还用于接收到运行于目标最小单元中的状态应用发送的、携带所述无头服务的服务名称的访问请求；
178.其中，所述服务名称用于指示所述访问请求对应的服务类型为无头服务。
179.在一些实施例中，所述解析模块5552，还用于对所述访问请求进行解析，得到所述访问请求中包含的运行所述目标有状态应用的最小单元的单元名称；
180.其中，所述单元名称包括：所述目标有状态应用的应用名称、所述最小单元的单元序号以及所述无头服务的服务名称；
181.将所述运行所述目标有状态应用的最小单元的单元名称，作为用于标识最小单元的目标单元标识。
182.在一些实施例中，各所述站点内运行所述目标有状态应用的最小单元的目标单元标识之间相一致，所述装置还包括：
183.第一访问模块，用于接收到运行于第一最小单元中的第一状态应用发送的第一访问请求，所述第一最小单元与所述目标最小单元归属于不同的站点，所述第一访问请求用于访问目标有状态应用；
184.解析所述第一访问请求，得到用于标识最小单元的第一单元标识，所述第一单元标识与所述目标单元标识相同；
185.获取存储有单元标识与互联网协议地址间映射关系的域名解析文件，并基于所述域名解析文件，在所述第一最小单元所归属的站点内，查找对应所述第一单元标识的第一互联网协议地址；
186.发送所述第一互联网协议地址至所述第一状态应用，以使所述第一状态应用基于所述第一互联网协议地址访问所述目标有状态应用。
187.在一些实施例中，所述边缘节点还包括文件维护组件，所述文件维护组件用于维护相应边缘节点所归属站点的域名解析文件；
188.所述获取模块5553，还用于确定所述目标最小单元所归属的目标边缘节点、以及
所归属的目标站点；
189.从所述目标边缘节点的文件维护组件中，获取所述目标站点对应的域名解析文件。
190.在一些实施例中，所述域名解析文件与所述站点为一一对应关系，所述站点还包括：用于维护相应站点的域名解析文件的文件维护节点；
191.所述获取模块5553，还用于确定所述目标最小单元所归属的目标站点；
192.从所述文件维护节点中，获取所述目标站点对应的域名解析文件。
193.在一些实施例中，所述文件维护节点，为相应站点内不同于所述边缘节点的节点；
194.或者，所述文件维护节点，为通过选举机制，从所述站点内包括的至少一个边缘节点内选举得到的节点。
195.在一些实施例中，所述文件维护组件，用于监测到针对所述域名解析文件的更新事件时，基于所述更新事件更新所述域名解析文件；
196.所述获取模块5553，还用于获取基于所述更新事件更新后的、存储有单元标识与互联网协议地址间映射关系的域名解析文件。
197.在一些实施例中，所述装置还包括：
198.第二访问模块，用于接收到运行于第二最小单元中的第二状态应用发送的第二访问请求，所述第二访问请求用于访问所述目标有状态应用；
199.解析所述第二访问请求，得到用于标识最小单元的第二单元标识；
200.将所述第二单元标识重命名为归属于所述第二最小单元所在站点的、运行所述目标有状态应用的最小单元的真实单元标识；
201.基于所述无头服务，对所述真实单元标识进行域名解析，得到对应所述真实单元标识的第二互联网协议地址；
202.发送所述第二互联网协议地址至所述第二状态应用，以使所述第二状态应用基于所述第二互联网协议地址访问所述目标有状态应用。
203.在一些实施例中，所述边缘计算系统还包括：有状态应用控制节点；
204.所述有状态应用控制节点，用于当监测到节点创建事件时，在各所述站点内创建至少一个边缘节点，并在各所述边缘节点上部署运行有状态应用的至少一个最小单元。
205.在一些实施例中，所述有状态应用控制节点，还用于当监测到节点更新事件时，更新各所述站点内的边缘节点，以及
206.更新各所述边缘节点上所部署的运行有状态应用的最小单元。
207.应用本申请上述实施例，在包括至少两个站点的边缘计算系统中，每个站点所包括的至少一个边缘节点上均部署有至少一个最小单元，当接收到运行于目标最小单元的状态应用所发送的、用于访问目标有状态应用的访问请求时，对该访问请求进行解析，得到目标单元标识，从而基于该目标单元标识，在存储有单元标识与互联网协议地址间映射关系的域名解析文件中，查找到属于目标最小单元所归属的目标站点内、且与目标单元标识存在映射关系的目标互联网协议地址，将该目标互联网协议地址发送至状态应用，以使该状态应用基于目标互联网协议地址访问目标有状态应用；如此，所返回状态应用的目标互联网协议地址是在目标最小单元所归属的目标站点内查找到的，在状态应用在访问有状态应用时，能够避免出现跨站点访问的情况。
208.本申请实施例还提供一种电子设备，所述电子设备包括：
209.存储器，用于存储可执行指令；
210.处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的边缘计算系统中有状态应用的访问方法。
211.本申请实施例还提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例提供的边缘计算系统中有状态应用的访问方法。
212.本申请实施例还提供一种计算机可读存储介质，存储有可执行指令，所述可执行指令被处理器执行时，实现本申请实施例提供的边缘计算系统中有状态应用的访问方法。
213.在一些实施例中，计算机可读存储介质可以是fram、rom、prom、ep rom、eeprom、闪存、磁表面存储器、光盘、或cd
‑
rom等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
214.在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
215.作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(html，hyper text markup language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
216.作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
217.以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。