一种服务配置文件处理方法、装置、存储介质及电子设备

摘要

本发明公开了一种服务配置文件处理方法、装置、存储介质及电子设备，通过检测待启动容器的容器启动请求，响应于容器启动请求，发送获取待启动容器的配置文件的文件获取请求，接收响应于文件获取请求的响应信息，响应信息用于示出待启动容器的配置文件的获取结果，并根据响应信息，判断待启动容器的启动结果，在启动结果示出待启动容器成功启动的情况下，更新容器的服务配置文件，上传更新后的服务配置文件，以固化服务配置文件。由此，可以在实现云原生部署的同时，不对外暴露任何连接端口，安全可靠的跨机进行配置存取，而且无需修改业务节点的容器中的主体业务应用程序，实现高效的实时配置文件同步保存。

权利要求

1.一种服务配置文件处理方法，其特征在于，应用于业务服务，所述方法包括：检测待启动容器的容器启动请求；

响应于所述容器启动请求，发送获取所述待启动容器的配置文件的文件获取请求至文件存储服务；

接收所述文件存储服务响应于所述文件获取请求的响应信息，所述响应信息用于示出所述待启动容器的配置文件的获取结果；

根据所述响应信息，判断所述待启动容器的启动结果；

在所述启动结果示出所述待启动容器成功启动的情况下，更新容器的服务配置文件；

上传更新后的服务配置文件至文件存储服务，以固化所述服务配置文件；

其中，所述在所述启动结果示出所述待启动容器成功启动的情况下，更新容器的服务配置文件，包括：

通过Linux系统的inotify机制监听容器的服务配置文件的变化；

在监听到所述容器的服务配置文件变化的情况下，上传所述容器的最新服务配置文件，以更新所述容器的服务配置文件；

检测容器的应用程序运行情况；

在所述应用程序退出的情况下，上传所述容器的最新配置文件，以更新所述容器的服务配置文件。

2.根据权利要求1所述的方法，其特征在于，所述根据所述响应信息，判断所述待启动容器的启动结果，包括：

在所述响应信息示出以下之一的情况下，判定所述待启动容器启动成功：所述待启动容器的服务配置文件获取成功；

所述待启动容器的服务配置文件为空。

3.根据权利要求2所述的方法，其特征在于，在所述响应信息示出所述待启动容器的服务配置文件获取成功的情况下，所述响应信息还包括所述待启动容器的服务配置文件。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：在所述应用程序退出后，间隔设定时间，结束容器运行。

5.根据权利要求1所述的方法，其特征在于，在所述响应信息示出所述待启动容器的服务配置文件获取成功的情况下，在监听容器的服务配置文件的变化之前，所述根据所述响应信息，更新所述待启动容器的服务配置文件，还包括：

从所述响应信息中提取服务配置文件，以覆盖所述待启动容器的默认配置文件。

6.根据权利要求1所述的方法，其特征在于，所述根据所述响应信息，判断所述待启动容器的启动结果，包括：

在所述响应信息示出以下之一的情况下，判定所述待启动容器启动失败：所述待启动容器的服务配置文件获取过程连接失败；

所述待启动容器的服务配置文件获取过程连接错误。

7.根据权利要求6所述的方法，其特征在于，所述方法，还包括：在判定所述待启动容器启动失败的情况下，重启所述待启动容器。

8.一种服务配置文件处理装置，其特征在于，应用于业务服务，所述装置包括：启动检测模块，用于检测待启动容器的容器启动请求；

文件获取模块，用于响应于所述容器启动请求，发送获取所述待启动容器的配置文件的文件获取请求至文件存储服务；

接收模块，用于接收所述文件存储服务响应于所述文件获取请求的响应信息，所述响应信息用于示出所述待启动容器的配置文件的获取结果；

启动判断模块，用于根据所述响应信息，判断所述待启动容器的启动结果；

更新模块，用于在所述启动结果示出所述待启动容器成功启动的情况下，更新容器的服务配置文件；

固化模块，用于上传更新后的服务配置文件至文件存储服务，以固化所述服务配置文件；

其中，所述更新模块包括：

监听子模块，用于通过Linux系统的inotify机制监听容器的服务配置文件的变化；

第一更新子模块，用于在监听到容器的服务配置文件变化的情况下，上传容器的最新服务配置文件，以更新容器的服务配置文件；

检测子模块，用于检测容器的应用程序运行情况；

第二更新子模块，用于在应用程序退出的情况下，上传容器的最新配置文件，以更新容器的服务配置文件。

9.一种计算机可读存储介质，其特征在于，所述存储介质包括一组计算机可执行指令，当所述指令被执行时用于执行权利要求1‑7中任一项所述的服务配置文件处理方法。

10.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现权利要求1‑7中任一项所述的服务配置文件处理方法。

说明书

一种服务配置文件处理方法、装置、存储介质及电子设备

技术领域

[0001] 本发明涉及通信技术领域，尤其涉及一种服务配置文件处理方法、装置、存储介质及电子设备。

背景技术

[0002] 对于应用程序的部署，传统的方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，不利于应用的升级更新
和回滚等操作。由此，提出了通过创建虚拟机进行应用程序部署的方式，但是虚拟机的可移
植性非常差。

[0003] 在传统应用程序部署方式和虚拟机均不能满足要求的情况下容器化技术应运而生。容器占用资源少、部署快，在应用程序的部署过程中得到的广泛的应用。Kubernetes是
Google开源的一个容器编排引擎，它支持多机集群、自动化部署、大规模可伸缩管理，并且
提供完善的管理工具。因此，目前基于Kubernetes的集群方案已成为云原生中主流的方案
之一。

发明内容

[0004] 本发明实施例提供一种服务配置文件处理方法、装置、存储介质及电子设备。

[0005] 根据本发明第一方面，提供了一种服务配置文件处理方法，所述方法包括：检测待启动容器的容器启动请求；响应于所述容器启动请求，发送获取所述待启动容器的配置文
件的文件获取请求；接收响应于所述文件获取请求的响应信息，所述响应信息用于示出所
述待启动容器的配置文件的获取结果；根据所述响应信息，判断所述待启动容器的启动结
果；在所述启动结果示出所述待启动容器成功启动的情况下，更新容器的服务配置文件；上
传更新后的服务配置文件，以固化所述服务配置文件。

[0006] 根据本发明一实施方式，所述根据所述响应信息，判断所述待启动容器的启动结果，包括：在所述响应信息示出以下之一的情况下，判定所述待启动容器启动成功：所述待
启动容器的服务配置文件获取成功；所述待启动容器的服务配置文件为空。

[0007] 根据本发明一实施方式，在所述响应信息示出所述待启动容器的服务配置文件获取成功的情况下，所述响应信息还包括所述待启动容器的服务配置文件。

[0008] 根据本发明一实施方式，所述在所述启动结果示出所述待启动容器成功启动的情况下，更新容器的服务配置文件，包括：监听容器的服务配置文件的变化；在监听到所述容
器的服务配置文件变化的情况下，上传所述容器的最新服务配置文件，以更新所述容器的
服务配置文件。

[0009] 根据本发明一实施方式，所述在所述启动结果示出所述待启动容器成功启动的情况下，更新容器的服务配置文件，还包括：检测容器的应用程序运行情况；在所述应用程序
退出的情况下，上传所述容器的最新配置文件，以更新所述容器的服务配置文件。

[0010] 根据本发明一实施方式，所述方法还包括：在所述应用程序退出后，间隔设定时间，结束容器运行。

[0011] 根据本发明一实施方式，在所述响应信息示出所述待启动容器的服务配置文件获取成功的情况下，在监听容器的服务配置文件的变化之前，所述根据所述响应信息，更新所
述待启动容器的服务配置文件，还包括：从所述响应信息中提取服务配置文件，以覆盖所述
待启动容器的默认配置文件。

[0012] 根据本发明一实施方式，所述根据所述响应信息，判断所述待启动容器的启动结果，包括：在所述响应信息示出以下之一的情况下，判定所述待启动容器启动失败：所述待
启动容器的服务配置文件获取过程连接失败；所述待启动容器的服务配置文件获取过程连
接错误。

[0013] 根据本发明一实施方式，所述方法，还包括：在判定所述待启动容器启动失败的情况下，重启所述待启动容器。

[0014] 根据本发明第二方面，还提供了一种服务配置文件处理装置，所述装置包括：启动检测模块，用于检测待启动容器的容器启动请求；文件获取模块，用于响应于所述容器启动
请求，发送获取所述待启动容器的配置文件的文件获取请求；接收模块，用于接收响应于所
述文件获取请求的响应信息，所述响应信息用于示出所述待启动容器的配置文件的获取结
果；启动判断模块，用于根据所述响应信息，判断所述待启动容器的启动结果；更新模块，用
于在所述启动结果示出所述待启动容器成功启动的情况下，更新容器的服务配置文件；固
化模块，用于上传更新后的服务配置文件，以固化所述服务配置文件。

[0015] 根据本发明第三方面，还提供了一种计算机可读存储介质，所述存储介质包括一组计算机可执行指令，当所述指令被执行时用于执行上述服务配置文件处理方法。

[0016] 根据本发明第四方面，还提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；存储器，用于
存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现上述服务配置文件处理
方法。

[0017] 本发明实施例服务配置文件处理方法、装置、计算机可读存储介质及电子设备，通过检测待启动容器的容器启动请求，响应于容器启动请求，发送获取待启动容器的配置文
件的文件获取请求，接收响应于文件获取请求的响应信息，响应信息用于示出待启动容器
的配置文件的获取结果，并根据响应信息，判断待启动容器的启动结果，在启动结果示出待
启动容器成功启动的情况下，更新容器的服务配置文件，上传更新后的服务配置文件，以固
化服务配置文件。如此，可以部署一个云端的文件存储服务，实现云原生私有化部署，使得
业务节点检测到容器启动请求时，从文件存储服务获取服务配置文件。由此，可以在实现云
原生部署的同时，不对外暴露任何连接端口，安全可靠的跨机进行配置存取，而且无需修改
业务节点的容器中的主体业务应用程序，实现高效的实时配置文件同步保存。此外，该方法
还可以通过主备机制，实现服务配置文件的多机备份，有效保障数据安全。

[0018] 需要理解的是，本发明的教导并不需要实现上面所述的全部有益效果，而是特定的技术方案可以实现特定的技术效果，并且本发明的其他实施方式还能够实现上面未提到
的有益效果。

附图说明

[0019] 通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若
干实施方式，其中：

[0020] 在附图中，相同或对应的标号表示相同或对应的部分。

[0021] 图1示出了本发明实施例服务配置文件处理方法的应用场景示意图；

[0022] 图2示出了本发明实施例服务配置文件处理方法的实现流程示意图一；

[0023] 图3示出了本发明实施例服务配置文件处理方法的实现流程示意图二；

[0024] 图4示出了本发明实施例服务配置文件处理方法具体应用示例的实现流程示意图；

[0025] 图5示出了本发明实施例服务配置文件处理装置的组成结构示意图；

[0026] 图6示出了本发明实施例电子设备的组成结构示意图。

具体实施方式

[0027] 下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方
式限制本发明的范围。相反，提供这些实施方式是为使本发明更加透彻和完整，并能够将本
发明的范围完整地传达给本领域的技术人员。

[0028] 下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

[0029] 图1示出了本发明实施例服务配置文件处理方法的应用场景示意图。本发明实施例服务配置文件处理方法应用于如图1所示的系统架构中。如图1所示，建立一个基于HTTP
（Hypertext Transfer Protocol，超文本传输协议）的文件存储服务，支持上传和下载操
作，并为之配置数据卷。业务服务不直接挂载数据卷，而是通过HTTP请求实现文件的存储和
获取。如此，有效避免了业务服务被本地存储的主机限定和影响，使得业务服务能够自由的
在Kubemetes集群内的任意节点运行。

[0030] 本发明中业务服务容器“POD‑业务服务1”在执行容器启动操作时，可以先通过HTTP向文件存储服务容器“POD‑文件存储服务”请求获取配置文件。如果请求成功，文件存
储服务返回包括配置文件获取成功的标识的报文，例如：“200 OK”，并在报文中携带配置文
件的内容。业务服务容器替换对应配置文件。如果业务服务容器的配置文件不存在，则文件
存储服务容器返回包括配置文件为空的标识的报文，例如：“404 Not Found”，此时业务服
务容器可以确定该容器的配置文件尚未归档过，并继续执行启动过程。如果文件存储服务
容器返回包括其他异常报错或业务服务无法与文件存储服务正常连接的报文，则认为业务
服务启动失败，业务服务容器处于运行结束状态，等待Kubernetes稍后重启容器，并再次请
求获取配置文件。

[0031] 业务服务容器启动成功后，可以通过Linux（操作系统名称）系统的inotify（Linux特性，监控文件系统操作）机制监听指定应用程序文件的创建和修改等事件。当事件触发
时，Linux操作系统在内核层面会给予回调；业务服务容器收到回调后，触发通过HTTP上传
最新的配置文件到文件服务容器的操作。

[0032] 当应用程序结束时，可以根据实际业务场景，选择每次都同步最新配置文件至文件存储服务容器，或在应用程序结束后等待指定时间，例如：1‑2秒，以保证应用程序退出之
前可能产生的配置文件同步完毕。

[0033] 如此，业务服务容器对服务配置文件进行处理的整个过程，无需修改应用程序本身所执行的操作，依靠应用程序的外围的脚本或应用，即可实现服务配置文件固化和读取
的操作。

[0034] 具体的服务配置文件处理流程在下文中结合图2‑4进行更具体的描述，此处不再赘述。

[0035] 需要说明的是，图1仅仅是给出了本发明实施例服务配置文件处理方法的应用场景示例，并不用于限制本发明服务配置文件处理方法的应用场景，还可以将本发明服务配
置文件处理方法应用于其他适用的场景。

[0036] 另外，在对文件存储服务的工作负载进行配置时，应当符合以下标准：

[0037] 1）在业务服务进行私有化部署时，主要采用本地模式，即将服务配置文件固化到物理机器的可写区上。因为只要部署NFS（Net File System，网络文件服务），就会产生对外
端口，在服务更新较慢的私有化部署环境下，使用NFS安全隐患很高。

[0038] 但是，如果有专业团队持续维护或使用公有云租赁专业的存储服务，可以使用NFS服务提供更多样的服务。此时，业务服务无需关注配置文件的实际存储类型，能够有效简化
业务服务配置文件的存储过程，有效提升算力，节省计算和存储资源。

[0039] 2）在对业务服务进行网络部署时，避免采用HOST（主机网络）模式，从而有效避免通讯端口对外暴露所引发得到安全隐患。而按照Kubernetes的机制，使用非HOST模式，默认
配置为监听端口不对外暴露监听，仅可以在Kubernetes集群内连接。

[0040] 3）对于存储类型为NFS之外的其他情况，文件存储服务的Pod（容器）数量不应当大于1。在Kubernetes机制的超大型集群情况下，可以部署一个或多个文件存储服务，以实现
负载均衡。

[0041] 4）如果文件存储服务的存储类型为NFS，文件存储服务可以挂载具有多个实际指向不同PV（Persistent Volume，持久卷）的PVC（Persistent Volume Claim，持久卷申领），
以保证服务配置文件的安全性。并设置主备文件存储服务，即实际上配置文件同步存储不
同的物理节点。

[0042] 5）采用图1所示的业务服务、文件存储服务和虚拟化网络等配置方式对Kubemetes系统进行配置，当主节点的存储设备异常时，主节点的业务服务容器会因为没有满足启动
要求而无法启动。运维人员只需要将主节点的服务配置路径的绑定PVC从原有的主PVC切换
到备份PVC，并移除备份配置路径的卷映射关系，即可保证存储服务的继续正常运行，从而
保证业务服务能够正常运行。

[0043] 文件存储服务的工作负载配置完毕后，还需要为之配置服务发现，服务发现是指在虚拟化网络中添加一条域名记录，将预设的名称指向到文件存储服务的工作负载。服务
发现的作用范围仅限于集群内；当工作负载对应的Pod数大于1时，服务发现还可以起到负
载均衡的作用。

[0044] 假设文件存储服务工作负载的服务发现名称为configsvr。当一个名为business的无状态业务服务请求获取自身的配置文件config.ini，那么该业务服务请求的地址可以
是http://configsvr/bussiness/config.ini。即可以按照以下规则配置存储：http://文
件存储服务的服务发现名/业务服务的工作负载名/配置文件名。如果为单实例工作的业务
服务，可以利用上述的规则进行写入操作。

[0045] 如果为多实例工作的业务服务，需要进行负载均衡操作，可以在云原生化后变为Pod数大于1的无状态服务，通常会有一个调度服务进行伸缩计算，所有的配置文件写入由
调度服务完成，或通过在无状态服务启动后通过业务上的信令协议完成通讯；工作服务在
运行时，不再监听本地配置文件变化，通过重新启动工作服务或追加协议让工作服务重新
拉取完成同步。

[0046] 在一些场景中，例如：某个平台接入网关服务，需要连接不同的外部主机节点，为每个Pod独立配置外部主机的IP、账户、密码等信息。因此，需要将业务服务的模式设置为有
状态服务，利用有状态服务的固定Pod名，区分不同节点；以一个名为business的业务服务
为例，第一个Pod实例名为business‑0,第二个Pod实例名为business‑1。那么第一个Pod的
配置文件config.ini对应的地址为http://configsvr/bussiness/business‑0/
config.ini  ,即按以下规则配置存储：http://文件存储服务的服务发现名/业务服务的工
作负载名/Pod名/配置文件名，实现不同Pod独立配置文件的需求。

[0047] 图2示出了本发明实施例服务配置文件处理方法的实现流程示意图一。参考图2，本发明这一实施例服务配置文件处理方法，至少包括如下操作流程：操作201，检测待启动
容器的容器启动请求；操作202，响应于容器启动请求，发送获取待启动容器的配置文件的
文件获取请求；操作203，接收响应于文件获取请求的响应信息，响应信息用于示出待启动
容器的配置文件的获取结果；操作204，根据响应信息，判断待启动容器的启动结果；操作
205，在启动结果示出待启动容器成功启动的情况下，更新容器的服务配置文件；操作206，
上传更新后的服务配置文件，以固化服务配置文件。

[0048] 在操作201，检测待启动容器的容器启动请求。

[0049] 在本发明这一实施方式中，业务服务每间隔设定间隔时间自动检自身的启动请求。例如：节点1的POD‑业务服务1自动检测其容器启动请求。可以根据实际情况设置设定间
隔时间，还可以设置为实时检测。

[0050] 操作202，响应于容器启动请求，发送获取待启动容器的配置文件的文件获取请求。

[0051] 在本发明这一实施方式中，在业务服务容器检测到自身的容器启动请求时，尝试从文件存储服务获取当前最新的服务配置文件。因此，业务服务将向文件存储服务发送容
器的配置文件的文件获取请求。文件获取请求中可以携带文件名称。

[0052] 操作203，接收响应于文件获取请求的响应信息，响应信息用于示出待启动容器的配置文件的获取结果。

[0053] 在本发明这一实施方式中，响应信息可以包括用于示出以下之一的获取结果标识：待启动容器的服务配置文件获取成功；待启动容器的服务配置文件为空；待启动容器的
服务配置文件获取过程连接失败；待启动容器的服务配置文件获取过程连接错误。

[0054] 操作204，根据响应信息，判断待启动容器的启动结果。

[0055] 在本发明这一实施方式中，可以在响应信息示出以下之一的情况下，判定待启动容器启动成功：待启动容器的服务配置文件获取成功；待启动容器的服务配置文件为空。

[0056] 在本发明这一实施方式中，可以在响应信息示出以下之一的情况下，判定待启动容器启动失败：待启动容器的服务配置文件获取过程连接失败；待启动容器的服务配置文
件获取过程连接错误。

[0057] 其中，响应信息中包括的用于示出服务配置文件获取结果的标识可以示出以上用于判断待启动容器启动成功或失败的各种情况。例如：文件存储服务将响应信息以报文形
式发送至业务服务，报文的设定位置的信息是服务配置文件获取结果的标识，可以用标识
“200 OK”表示待启动容器的服务配置文件获取成功，标识“404 Not Found”表示未找到相
应的服务配置文件，也即待启动容器的服务配置文件为空。

[0058] 操作205，在启动结果示出待启动容器成功启动的情况下，更新容器的服务配置文件。

[0059] 在业务服务容器成功启动的情况下，例如：图1所示的“POD‑业务服务1”，需要根据容器的配置文件变化，更新容器的服务配置文件。例如：业务服务可以通过监听容器的服务
配置文件的变化的方式，在监听到容器的服务配置文件变化的情况下，上传容器的最新服
务配置文件，以更新容器的服务配置文件。

[0060] 在本发明这一实施方式，在响应信息示出待启动容器的服务配置文件获取成功的情况下，响应信息还包括待启动容器的服务配置文件。这种情况下，在监听容器的服务配置
文件的变化之前，还从响应信息中提取服务配置文件，以覆盖待启动容器的默认配置文件。

[0061] 在本发明另一实施方式中，在启动结果示出待启动容器成功启动的情况下，还可以检测容器的应用程序运行情况，并在应用程序退出的情况下，上传容器的最新配置文件，
以更新容器的服务配置文件。

[0062] 这里，应用程序的退出包括正常退出和应用程序出错时的非正常退出。

[0063] 为了保证应用程序退出后，服务配置文件能够更新并上传完毕，可以在应用程序退出后，间隔设定时间，再结束容器运行。

[0064] 操作206，上传更新后的服务配置文件，以固化服务配置文件。

[0065] 在本发明这一实施方式，将更新后的配置文件上传至文件存储服务。这样，有效降低业务服务对部署环境的要求，实现业务服务和文件存储服务的高度可移植性。使得无论
是基于容器的私有化部署、公有化部署还是传统的非容器化部署方案，业务服务的主程序
均可以适应服务配置文件的不同的物理存储位置和存储方式。有效提高服务配置文件处理
方法的可用性和安全性。

[0066] 在本发明一实施方式中，还在判定待启动容器启动失败的情况下，终止当前容器运行，并等待kubemetes重启待启动容器。

[0067] 图3示出了本发明实施例服务配置文件处理方法的实现流程示意图二。参考图3，本发明这一实施例服务配置文件处理方法，至少包括如下操作流程：

[0068] 操作301，容器启动。

[0069] 举例说明，业务服务容器自动检测自身的启动。

[0070] 操作302，请求获取容器的配置文件。

[0071] 在业务服务容器执行启动操作时，请求从文件存储服务容器中获取容器当前的配置文件。业务服务容器发送获取容器的配置文件的请求可以携带文件名称。

[0072] 操作3031，返回包括配置文件获取成功标识和服务配置文件的响应信息，执行操作304。

[0073] 文件存储服务容器接收到获取容器的配置文件的请求，可以向业务服务容器返回报文。报文内容能够示出配置文件是否获取成功，在文件获取成功时，报文内容还包括业务
服务容器当前的最新配置文件。

[0074] 操作3032，返回包括配置文件为空标识的响应信息，执行操作305。

[0075] 文件存储服务容器向业务服务容器返回配置文件为空标识，则执行操作305。

[0076] 操作3033，返回包括服务配置文件获取过程连接失败的响应信息,终止容器运行，等待重启。

[0077] 文件存储服务容器向业务服务容器返回服务配置文件获取过程连接失败,终止容器运行，等待重启。

[0078] 操作3034，返回包括服务配置文件获取过程连接错误的响应信息,终止容器运行，等待重启。

[0079] 文件存储服务容器向业务服务容器返回服务配置文件获取过程连接错误的响应信息，终止容器运行，等待重启。

[0080] 操作304，从响应信息中提取服务配置文件，以覆盖待启动容器的默认配置文件。

[0081] 操作305，监听容器的服务配置文件的变化。

[0082] 操作306，在监听到容器的服务配置文件变化的情况下，上传容器的最新服务配置文件，以更新容器的服务配置文件。

[0083] 操作307，检测容器的应用程序运行情况。

[0084] 操作308，在应用程序退出的情况下，上传容器的最新配置文件，以更新容器的服务配置文件。

[0085] 操作309，在应用程序退出后，间隔设定时间，结束容器运行。

[0086] 图4示出了本发明实施例服务配置文件处理方法具体应用示例的实现流程示意图。参考图4，本发明这一实施例服务配置文件处理方法的具体应用示例，至少包括如下操
作流程：

[0087] 操作401，容器启动。

[0088] 具体的，业务服务容器执行启动操作。

[0089] 操作402，发送获取配置文件请求。

[0090] 具体的，业务服务容器向文件存储服务发送获取配置文件请求。

[0091] 操作403，判断配置文件请求的返回值。

[0092] 具体的，文件服务容器响应于配置文件请求，发送返回值至业务服务容器。业务服务容器根据返回值进行判断，以确定后续操作。

[0093] 若返回值为“200 OK”，则执行操作404；若返回值为“400 Not Found”，则执行操作405；若返回值示出“业务服务容器与文件存储服务容器连接失败或其他错误”，则终止容器
启动操作，并在Kubernetes重启容器的情况下，返回执行操作401。

[0094] 操作404，覆盖默认配置文件。

[0095] 具体的，若返回值为“200 OK”，则说明文件存储服务容器中包括待启动的业务服务容器的当前的最新服务配置文件，文件存储服务在返回“200 OK”的同时发送当前的最新
服务配置文件至业务服务容器。业务服务容器接收到当前的最新服务配置文件时，利用当
前的最新服务配置文件覆盖业务服务容器的应用程序的默认配置文件。

[0096] 操作405，监听配置文件。

[0097] 具体的，若返回值为“400 Not Found”，则说明文件存储服务容器中未查找到待启动的业务服务容器的当前的最新服务配置文件，该待启动的业务服务容器的服务配置文件
未在文件存储服务容器中存档。但是，该业务服务容器能够正常启动，业务服务容器包括的
应用程序能够正常运行。此时，可以监听该业务服务容器的配置文件，在配置文件发生变化
时，执行操作406。监听操作可以通过Linux系统的inotify机制实现，也可以采用其他适用
的方式。本发明对此不作具体限定。

[0098] 操作406，上传最新配置文件。

[0099] 具体的，业务服务容器在监听到服务配置文件的变化时，将最新配置文件上传至文件存储服务。

[0100] 操作407，启动应用程序。

[0101] 举例说明，业务服务容器成功启动后，业务服务容器所包括的应用程序即可启动。

[0102] 操作408，检测应用程序运行状态。

[0103] 具体的，业务服务容器检测其应用程序的运行状态。

[0104] 操作409，在应用程序退出的情况下，上传最新配置文件或等待设定时间。

[0105] 具体的，这里应用程序退出包括应用程序正常退出和应用程序出错时等情况下的非正常退出，在应用程序退出的情况下，为了保证业务服务容器的最新配置文件能够上传
至文件存储服务。这里需要在确认上传最新配置文件完成后再执行操作410，将容器运行结
束。通常配置文件上传为毫秒级别的，这里等待设定时间可以设置为1s、1.5s或者2s等。

[0106] 操作410，容器运行结束。在Kubernetes重启容器的情况下，返回执行操作401。

[0107] 其中，操作401‑411的其他具体实现过程可参考图1 3所示实施例中相应的具体实~
现过程，此处不再赘述。

[0108] 本发明实施例服务配置文件处理方法、装置、计算机可读存储介质及电子设备，通过检测待启动容器的容器启动请求，响应于容器启动请求，发送获取待启动容器的配置文
件的文件获取请求，接收响应于文件获取请求的响应信息，响应信息用于示出待启动容器
的配置文件的获取结果，并根据响应信息，判断待启动容器的启动结果，在启动结果示出待
启动容器成功启动的情况下，更新容器的服务配置文件，上传更新后的服务配置文件，以固
化服务配置文件。如此，可以部署一个云端的文件存储服务，实现云原生私有化部署，使得
业务节点检测到容器启动请求时，从文件存储服务获取服务配置文件。由此，可以在实现云
原生部署的同时，不对外暴露任何连接端口，安全可靠的跨机进行配置存取，而且无需修改
业务节点的容器中的主体业务应用程序，实现高效的实时配置文件同步保存。此外，该方法
还可以通过主备机制，实现服务配置文件的多机备份，有效保障数据安全。

[0109] 同理，基于上文服务配置文件处理方法，本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有程序，当程序被处理器执行时，使得处理器至少执行如
下的操作步骤：操作201，检测待启动容器的容器启动请求；操作202，响应于容器启动请求，
发送获取待启动容器的配置文件的文件获取请求；操作203，接收响应于文件获取请求的响
应信息，响应信息用于示出待启动容器的配置文件的获取结果；操作204，根据响应信息，判
断待启动容器的启动结果；操作205，在启动结果示出待启动容器成功启动的情况下，更新
容器的服务配置文件；操作206，上传更新后的服务配置文件，以固化服务配置文件。

[0110] 进一步，基于如上文服务配置文件处理方法，本发明实施例还提供一种服务配置文件处理装置，如图5，该装置50包括：启动检测模块501，用于检测待启动容器的容器启动
请求；文件获取模块502，用于响应于容器启动请求，发送获取待启动容器的配置文件的文
件获取请求；接收模块503，用于接收响应于文件获取请求的响应信息，响应信息用于示出
待启动容器的配置文件的获取结果；启动判断模块504，用于根据响应信息，判断待启动容
器的启动结果；更新模块505，用于在启动结果示出待启动容器成功启动的情况下，更新容
器的服务配置文件；固化模块506，用于上传更新后的服务配置文件，以固化服务配置文件。

[0111] 根据本发明一实施方式，启动判断模块504，包括：第一判断子模块，用于在响应信息示出以下之一的情况下，判定待启动容器启动成功：待启动容器的服务配置文件获取成
功；待启动容器的服务配置文件为空。

[0112] 根据本发明一实施方式，在响应信息示出待启动容器的服务配置文件获取成功的情况下，响应信息还包括待启动容器的服务配置文件。

[0113] 根据本发明一实施方式，更新模块505包括：监听子模块，用于监听容器的服务配置文件的变化；第一更新子模块，用于在监听到容器的服务配置文件变化的情况下，上传容
器的最新服务配置文件，以更新容器的服务配置文件。

[0114] 根据本发明一实施方式，更新模块505还包括：检测子模块，用于检测容器的应用程序运行情况；第二更新子模块，用于在应用程序退出的情况下，上传容器的最新配置文
件，以更新容器的服务配置文件。

[0115] 根据本发明一实施方式，装置50还包括：容器结束模块，用于在应用程序退出后，间隔设定时间，结束容器运行。

[0116] 根据本发明一实施方式，更新模块505还包括：替换子模块，用于在响应信息示出待启动容器的服务配置文件获取成功的情况下，在监听容器的服务配置文件的变化之前，
从响应信息中提取服务配置文件，以覆盖待启动容器的默认配置文件。

[0117] 根据本发明一实施方式，启动判断模块504还包括：第二判断子模块，用于在响应信息示出以下之一的情况下，判定待启动容器启动失败：待启动容器的服务配置文件获取
过程连接失败；待启动容器的服务配置文件获取过程连接错误。

[0118] 根据本发明一实施方式，装置50还包括：重启模块，用于在判定待启动容器启动失败的情况下，重启待启动容器。

[0119] 更进一步，基于如上文服务配置文件处理方法，本发明实施例还提供一种电子设备，如图6所示，电子设备60包括：处理器601、通信接口602、存储器603和通信总线604，其
中，处理器601，通信接口602，存储器603通过通信总线604完成相互间的通信；存储器603，
用于存放计算机程序；处理器601，用于执行存储器603上所存放的程序时，实现上述服务配
置文件处理方法。

[0120] 这里需要指出的是：以上对针对服务配置文件处理装置及电子设备实施例的描述，与前述图1至4所示的方法实施例的描述是类似的，具有同前述图1至4所示的方法实施
例相似的有益效果，因此不做赘述。对于本发明服务配置文件处理装置实施例中未披露的
技术细节，请参照本发明前述图1至4所示的方法实施例的描述而理解，为节约篇幅，因此不
再赘述。

[0121] 需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而
且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有
的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该
要素的过程、方法、物品或者装置中还存在另外的相同要素。

[0122] 在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，单元的划分，仅仅为一种
逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以
集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相
互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通
信连接，可以是电性的、机械的或其它形式的。

[0123] 上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单
元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

[0124] 另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述
集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

[0125] 本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在
执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存
储器（Read Only Memory，ROM）、磁碟或者光盘等各种可以存储程序代码的介质。

[0126] 或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施
例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，
该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以
是个人计算机、服务器、或者网络设备等）执行本发明各个实施例方法的全部或部分。而前
述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

[0127] 以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在
本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。