CN116094897A - 一种网页配置方法、装置及存储介质 - Google Patents

一种网页配置方法、装置及存储介质 Download PDF

Info

Publication number
CN116094897A
CN116094897A CN202310031852.6A CN202310031852A CN116094897A CN 116094897 A CN116094897 A CN 116094897A CN 202310031852 A CN202310031852 A CN 202310031852A CN 116094897 A CN116094897 A CN 116094897A
Authority
CN
China
Prior art keywords
container set
webpage
server
set information
web page
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310031852.6A
Other languages
English (en)
Inventor
杨海迎
闫向超
庄子钰
沈健
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Mafengwo Network Technology Co ltd
Original Assignee
Beijing Mafengwo Network Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Mafengwo Network Technology Co ltd filed Critical Beijing Mafengwo Network Technology Co ltd
Priority to CN202310031852.6A priority Critical patent/CN116094897A/zh
Publication of CN116094897A publication Critical patent/CN116094897A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0253—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using browsers or web-pages for accessing management information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/10—Packet switching elements characterised by the switching fabric construction
    • H04L49/103—Packet switching elements characterised by the switching fabric construction using a shared central buffer; using a shared memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开是关于一种网页配置方法、装置及存储介质。网页配置方法，应用于网页服务器，包括：创建网页组的容器集，所述容器集中包括可挂载所述网页组对应单体代码数据卷的一个或多个容器，并同步创建对应所述一个或多个容器的空目录用于存放临时文件和日志；响应于所述网页组对应单体代码存入数据卷，将所述网页组单体代码数据卷挂载于所述一个或多个容器；将所述网页组单体代码同步挂载于所述网页服务器的共享存储空间。通过本公开可以解决大单体代码加入容器集后出现的网页服务器与网页代理服务器间信息无法同步问题。

Description

一种网页配置方法、装置及存储介质
技术领域
本公开涉及服务器部署领域，尤其涉及一种网页配置方法、装置及存储介质。
背景技术
容器化方案主要针对微服务，实现代码的快速迭代和平滑上线，但针对传统的大单体代码效果不是很好，主要问题在于过大的镜像容量，导致在容器规模较大的情况下，构建，发布流程都相当缓慢，且占用过多存储资源，和微服务的理念相背离。
现有技术中，大多数的做法是把大体量代码部署到物理机或者虚拟机上，但存在三大痛点：1.网站集群规模过大时，由于代码体积过大，每次发布传输的数据量过大，耗时长还有可能出现发布不完全的情况；2.在节假日或流量高峰前扩容繁杂且耗时；3.虚拟机部署服务时，如果遇到宿主机硬件故障，虚拟机无法快速漂移，故障恢复时间较长。
发明内容
为克服相关技术中存在的问题，本公开提供一种网页配置方法、装置及存储介质。
根据本公开实施例的第一方面，提供一种网页配置方法，应用于网页服务器，所述方法包括：
创建网页组的容器集，所述容器集中包括可挂载所述网页组对应单体代码数据卷的一个或多个容器，并同步创建对应所述一个或多个容器的空目录用于存放临时文件和日志；响应于所述网页组对应单体代码存入数据卷，将所述网页组单体代码数据卷挂载于所述一个或多个容器；将所述网页组单体代码同步挂载于所述网页服务器的共享存储空间。
一种实施方式中，所述方法还包括：
将容器集信息注册于服务注册发现节点。
一种实施方式中，所述方法还包括：
响应于确定容器集发生更新，更新所述服务注册发现节点的容器集信息；
所述容器集发生更新包括新创建容器集和/或销毁容器集。
一种实施方式中，所述确定容器集中的容器发生更新，包括：
定时监测所述服务注册发现节点的容器集信息与所述容器集信息的一致性；
若监测到所述服务注册发现节点的容器集信息与所述容器集信息的不一致，则确定容器集发生更新并同步于服务注册发现节点。
一种实施方式中，所述方法还包括：
将所述服务注册发现节点中所注册的容器集信息，发送至网页代理服务器。
根据本公开实施例的第二方面，提供一种网页配置方法，应用于网页代理服务器，所述方法包括：
获取服务注册发现节点中所注册的容器集信息；同步更新所述网页代理服务器的所述容器集信息。
一种实施方式中，所述获取服务注册发现节点中所注册的容器集信息，包括：
监测服务注册发现节点中的容器集信息；
响应于监测到所述服务注册发现节点中的容器信息发生更新，更新已获取到的容器集信息。
根据本公开实施例的第三方面，提供一种网页配置装置，应用于网页服务器，所述装置包括：
创建单元，用于创建网页组的容器集，所述容器集中包括可挂载所述网页组对应单体代码数据卷的一个或多个容器，并同步创建对应所述一个或多个容器的空目录用于存放临时文件和日志；
挂载单元，用于响应于所述网页组对应单体代码存入数据卷，将所述网页组单体代码数据卷挂载于所述一个或多个容器；还用于将所述网页组单体代码同步挂载于所述网页服务器的共享存储空间。
一种实施方式中，所述装置还包括：
注册单元，用于将容器集信息注册于服务注册发现节点。
一种实施方式中，所述装置还包括：
更新单元，用于响应于确定容器集发生更新，更新所述服务注册发现节点的容器集信息；
所述容器集发生更新包括新创建容器集和/或销毁容器集。
一种实施方式中，所述更新单元采用如下方式确定容器集中的容器发生更新：
定时监测所述服务注册发现节点的容器集信息与所述容器集信息的一致性；
若监测到所述服务注册发现节点的容器集信息与所述容器集信息的不一致，则确定容器集发生更新并同步于服务注册发现节点。
一种实施方式中，所述注册单元还用于：
将所述服务注册发现节点中所注册的容器集信息，发送至网页代理服务器。
根据本公开实施例的第四方面，提供一种网页配置装置，应用于网页代理服务器，所述装置包括：
获取单元，用于获取服务注册发现节点中所注册的容器集信息；
同步单元，用于同步更新所述网页代理服务器的所述容器集信息。
一种实施方式中，所述获取单元采用如下方式获取服务注册发现节点中所注册的容器集信息，包括：
监测服务注册发现节点中的容器集信息；
响应于监测到所述服务注册发现节点中的容器信息发生更新，更新已获取到的容器集信息。
根据本公开实施例第五方面，提供一种网页配置装置，包括：
处理器；用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：执行第一方面或者第一方面任意一种实施方式中所述的方法。
根据本公开实施例第六方面，提供一种网页配置装置，包括：
处理器；用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：执行第二方面或者第二方面任意一种实施方式中所述的方法。
根据本公开实施例第七方面，提供一种存储介质，所述存储介质中存储有指令，当所述存储介质中的指令由网页服务器的处理器执行时，使得网页服务器能够执行第一方面或者第一方面任意一种实施方式中所述的方法。
根据本公开实施例第八方面，提供一种存储介质，所述存储介质中存储有指令，当所述存储介质中的指令由网页代理服务器的处理器执行时，使得网页代理服务器能够执行第二方面或者第二方面任意一种实施方式中所述的方法。
本公开的实施例提供的技术方案可以包括以下有益效果：通过创建网页组的容器集，并同步创建对应所述一个或多个容器的空目录用于存放临时文件和日志；响应于所述网页组对应单体代码存入数据卷，将所述网页组单体代码数据卷挂载于所述一个或多个容器；将所述网页组单体代码同步挂载于所述网页服务器的共享存储空间。通过本公开可以解决大单体代码加入容器集后出现的网页服务器与网页代理服务器间信息无法同步的问题并简化架构。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
图1是本公开实施例提供的服务器配置方法的示意图。
图2是根据一示例性实施例示出的一种网页配置方法的流程图。
图3是根据一示例性实施例示出的一种网页配置方法的流程图。
图4是根据一示例性实施例示出的一种网页配置方法的流程图。
图5是根据一示例性实施例示出的一种网页配置方法的流程图。
图6是根据一示例性实施例示出的一种网页配置方法的流程图。
图7是根据一示例性实施例示出的一种网页配置方法的示意图。
图8是根据一示例性实施例示出的一种容器集结构图。
图9是根据一示例性实施例示出的一种网页配置装置框图。
图10是根据一示例性实施例示出的一种网页配置装置框图。
图11是本公开电子设备一个应用实施例的结构示意图。
图12示出了本公开的电子设备的一个实施例的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。
相关技术中，容器化方案主要针对微服务，实现代码的快速迭代和平滑上线。然而针对传统的大单体代码支持不是很好，主要问题在于大单体代码过大的镜像容量，导致在容器规模较大的情况下，构建、发布流程都相当缓慢，且占用过多存储资源，和微服务的理念相背离，因此业内大多数的做法是把大体量代码部署到物理机或者虚拟机上。
本公开以容器(docker)技术，k8s(Kubernetes)容器编排技术为基础，配合开源的动态负载均衡(upsync)模块，服务注册发现节点(consul)的自动注册和发现，再结合Golang语言开发的定制化工具，将体量较大的单体代码打包到容器中并解决诸多网页痛点问题。
本公开的网页(web)应用包括但不限于各种大中型网站，如旅游网站、视频播放网站、在线考试网站等。
本公开中K8s是用于自动化部署、扩展和管理容器化应用的开源容器编排器技术。针对每个Kubernetes集群都由一个主控节点(Master)负责管理和控制。通过Master对每个节点(Node)发送命令，Node可以是一台机器或者一台虚拟机。在Node上面可以运行多个容器集(Pod)，同时每个Pod可以包含多个容器(Docker)。Pod是Kubernetes集群中资源调度的最小单位，每次的调度都是以Pod为单位进行而不是直接调度一个容器。其中还包括连接各个容器的共享存储卷以及各个容器的共享命名空间，每个容器都会在特定的端口上运行。Kubernetes中的每一个Pod都有自己的独立IP地址(Internet Protocol Address)，也就是这个Pod命名空间对应的IP。Pod由Kubernetes统一创建、调度和管理，一般是利用复制控制器(Replication Controller)进行部署，包括部署一个或多个Pod。通常通过命令行工具(kubectl)对Kubernetes下命令，通过应用程序界面服务(Application ProgramInterface server，API Server)调用各个进程来完成对Node的部署和控制。API Server的核心功能是对核心对象(例如：Pod)的增删改查操作，同时也是集群内模块之间数据交换的枢纽。它包括了常用的API，访问(权限)控制，注册，信息存储(etcd)等功能。调度器(Scheduler)将待调度的Pod绑定到Node上，并将绑定信息写入etcd中。etcd包含在APIServer中，用来存储资源信息。定义请求转发规则的配置文件(ingress)是K8s中的一个API对象，一般用另一种标记语言(YAML Ain't Markup Language，YAML)配置，作用是定义请求转发的规则，可以理解为配置模板或者配置文件。Pod创建或销毁和IP地址信息存储在API Server中，Pod启动注册和停止前解注册信息写入服务注册与发现consul中。由于微服务的部署都是分布式的，所以对应的Pod以及容器的部署也是如此。
图1是本公开实施例提供的网页配置方法的示意图。如图1所示，由于网站所有网页服务代码都是一致的，所以采用容器共享宿主机存储的方式，所有容器共享本地一份代码，这样就大大减少了发布服务器的数量。Golang语言开发的中间件用于网页服务器和云服务器之间信息同步更新，实现了前端反向代理，到后端网页应用的全自动串联。
图2是根据一示例性实施例示出的一种网页配置方法的流程图，如图2所示，该方法用于网页服务器，包括以下步骤。
在步骤S11中，创建网页组的容器集，容器集中包括可挂载网页组对应单体代码数据卷的一个或多个容器，并同步创建对应一个或多个容器的空目录用于存放临时文件和日志。
在步骤S12中，响应于网页组对应单体代码存入数据卷，将网页组单体代码数据卷挂载于一个或多个容器。
在步骤S13中，将网页组单体代码同步挂载于网页服务器的共享存储空间。
本公开实施例中，通过创建网页组的容器集，并同步创建对应一个或多个容器的空目录用于存放临时文件和日志；响应于网页组对应单体代码存入数据卷，将网页组单体代码数据卷挂载于一个或多个容器；将网页组单体代码同步挂载于网页服务器的共享存储空间。通过本公开可以解决大单体代码加入容器集后出现的信息无法同步并简化架构。
本公开实施例中，容器集即Pod，容器集包含一个或多个容器，网页组对应的单体代码存入数据卷挂载在一个或多个容器上，数据卷是宿主机中的一个目录或文件。同时创建多个空目录存放运行时所产生的临时文件和日志数据；并且将网页组单体代码挂载在宿主机的共享存储空间。
本公开实施例中，网页组即网站中实现不同功能多个代码块组成的网页组；容器集即Pod，容器集包含一个或多个容器；数据卷(Data Volumes)是宿主机中的一个目录或文件，数据卷的设计目的就是数据的持久化，完全独立于容器的生存周期，因此Docker不会在容器删除时删除其挂载的数据卷。当容器目录和数据卷目录绑定后，对方的修改会立即同步，一个数据卷可以被多个容器同时挂载，一个容器也可以被挂载多个数据卷。单体代码为实现多个功能和逻辑的代码组合。
本公开实施例中，宿主机即物理机，宿主机可以是云服务器，可以是个人计算机，也可以是物理服务器，虚拟主机。宿主机主要取决于应用安装在哪种服务器上，这个服务器叫宿主机。比如在云服务器安装Docker，云服务器就叫宿主机。本公开实施例中的宿主机为网页服务器，共享存储空间为网页服务器的物理磁盘。
本公开实施例中，用于存放临时文件和日志的目录的特点是随着容器的创建写入数据，随着容器销毁数据随之清空。
本公开实施例中，将Web应用大单体代码存入数据卷中并挂载于Pod中的容器上。
本公开实施例中，通过K8s的配置文件，启动某一个web组的Pod，配置文件是启动K8s pod的部署(deployment)文件，它用于创建对象，创建资源等。根据配置文件定义并启动Web Pod，它会执行限制计算机处理器(Central Processing Unit，CPU)，限制内存，定义日志目录等，将这些配置在一个文件里面，通过这个文件创建启动Pod。
本公开实施例中，在创建启动某一个网页组的Pod的过程中，会同步创建多个空目录(EmptyDir)，分别存放临时/tmp目录的内容，以及网页代理服务器Nginx，PHP运行产生的临时文件和日志，同时代码目录通过主机路径(HostPath)的形式，挂载到宿主机上的大单体代码目录，实现代码共享。其中，这些所创建的目录的特点是随着容器的创建写入数据，随着容器销毁数据随之清空，所以它是存放日志的临时目录。但是临时目录特点之一是可以控制目录的大小，因此可以避免某一个web应用业务不断往所在目录写日志，把这个宿主机整个磁盘占满。如果用传统的挂载方式就会无限制地往目录内写日志，且无法得到有效控制。HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。
本公开实施例中，Web组即网站，一般大型网站可分成多个Web组，例如旅游网站，一个Web组是为手机端提供服务，一个Web组提供交易相关的服务，另外一个Web组提供新用户注册等方面的功能，多个Web组形成一个大的单体代码块。本公开所要解决的问题就是对原先的代码把所有的功能全都融合在一个大单体里存入数据卷并挂载于容器上。
本公开实施例中，Docker中的代码目录以HostPath的形式，挂载到宿主机代码目录，且此目录权限为只读，保证代码目录不被篡改，临时文件和日志以空目录(emptydir)的形式挂载，在Pod销毁的时候同时销毁，这样可以有效减少大体积代码在发布时的发布数量，提升发布速度和成功率。
下面是容器集创建或销毁、提供或停止服务和同步信息的过程。
本公开实施例中，将容器集信息注册于服务注册发现节点。服务注册发现节点即Consul，Consul作为Nginx的数据库，利用Consul的关键字和值(key-value)服务，每个NginxWork进程独立的获取各个upstream的配置，并更新各自的路由信息。
本公开实施例中，在K8s的启动前(prestart)配置中的程序会感知到Pod即将创建，并同步更新Consul中的对应Web组信息，Consul中的数据以Key-Value的形式保存，其中Key即Web组信息，Value就是存放Web组对应的Pod IP。Web组和Pod IP之间存在一一对应关系。
根据本公开的实施例，当容器集创建或销毁时，将其创建或销毁的信息包括IP地址等更新于服务注册发现节点Consul中。
图3是根据一示例性实施例示出的一种网页配置方法的流程图，如图3所示，该方法用于网页服务器，包括以下步骤。
在步骤S21中，响应于确定容器集发生更新，更新服务注册发现节点中的容器集信息。
在步骤S22中，容器集发生更新包括新创建容器集和/或销毁容器集。
本公开实施例中，容器集更新包括容器集的创建、销毁或漂移，容器集信息包括容器集的创建、销毁或漂移信息和IP地址的变化等。
本公开实施例中，通过K8s的配置文件销毁Pod或因故障Pod发生销毁漂移时，存放临时文件的空目录会被清空。由于Pod生命周期短暂，随时可能会被创建和销毁，使得Pod会产生漂移问题，所谓漂移就是指Pod会在不同的节点上创建和运行，而这个变化是时刻存在的，那么Pod IP也会随之动态发生变化。例如，提供交易的一组Web Pod，因为节假日业务量增加将其扩到30个Pod，等到节假日结束之后业务量减少，因此需要把将30个Pod恢复减少为原来的15个Pod，这样另外15个Pod就会面临着被销毁，销毁就是一种主动销毁，也就是说服务器缩容，服务器不需要如此多Pod并将其销毁。如果物理机故障、硬盘故障或机器宕机，服务器上的所有Pod都会发生漂移，相当于原来这些Pod就销毁了。由于K8s机制它会漂移到其他容器组，两种情况都会导致原来的Pod销毁。
本公开实施例中，Pod是无状态运行的，任何时候有Pod销毁或漂移，就会有其他Pod接替。如果用户访问量陡增，现有的Pod规模不足，那么会自动创建一批新的Pod，以适应当前的需求。反之亦然，当负载下降，K8s也会自动缩减Pod的数量。
本公开实施例中，K8s中的API Server中记录容器集的创建或销毁等信息，提供了k8s各类资源对象(如pod)的增删改查，是整个系统的数据总线和数据中心。
根据本公开的实施例，需要新的机制定时检查K8s框架中API server变化的容器集信息和服务注册发现节点的容器集信息。
图4是根据一示例性实施例示出的一种网页配置方法的流程图，如图4所示，该方法用于网页服务器，包括以下步骤。
在步骤S31中，定时监测服务注册发现节点的容器集信息与容器集信息的一致性。
本公开实施例中，Golang语言编写的中间件定时监测服务注册发现节点的容器集信息与容器集信息的一致性。
本公开实施例中，在K8s框架中放弃Ingress中间层，将Golang语言编写的中间件替代Ingress。Nginx作为一个高性能的超文本传输协议(Hyper Text Transfer Protocol，HTTP)和反向代理Web服务器，需要根据域名或者域名后面的统一资源标识符(UniformResource Identifier，URI)来进行向后端的转发，即在Nginx内部配置代理服务器路径(Proxy path)，path需要具体设置后端的IP地址。但是将Web应用大单体代码挂载于容器之后，这些后端的IP地址就是容器集Pod的IP，而Pod的IP会随着容器的生命周期发生变化，此时前端用传统意义上的Nginx，就无法感知后端pod的创建或者销毁，此时相当于前后端无法对接。K8s架构中的Ingress是在K8s整套体系里的类似于此功能的软件，它可以实时监听K8s集群的API server，能感知到后端的变化，所以在K8s体系里用Ingress来代替Nginx，相当于实现一个能自动感知后端Pod变化的功能。但是这种开源的方案，在实际的过程中存在两点问题，第一是在最前端有一层Nginx代理，上面实现了很多的功能，不只是与后端K8s对接的功能。如果用Ingress彻底替换Nginx，有些工作Ingress无法实现，如果加上ingress这层存在很多问题。例如，加上Ingress之后每当有一个业务上线会申请一个新的域名，需要在最前端的Nginx代理把这个域名配置上，同时还要在Ingress上再配置一遍，也就是说这个架构就会变得非常臃肿，而ingress这一层其实只是为了和K8s信息同步。第二就是Ingress也有一些无法实现的功能，在大单体Web代码加入Pod场景下会出现一些故障(Bug)无法处理。基于这两点编写一个新的中间件和API server对接感知Pod变化，另一边和Nginx对接将IP进行动态的变更，使架构简单可控，便于维护。
在步骤S32中，若监测到服务注册发现节点的容器集信息与容器集信息的不一致，则确定容器集发生更新并同步于服务注册发现节点。
本公开实施例中，中间件为替换Ingress的组件，实际上并没有一个对它工作是否正常的保障机制，中间件使用服务实时注册、实时解注册和注册校验，相当于一个旁路监听的程序，用来保证中间件是否正常工作，中间件的工作原理是实时地去感知K8s pod IP的变化，并且将其同步到Consul。也就是说中间件用来避免K8s内部的Pod生命周期发生变化，但是由于网络的抖动，中间件没有感知到，前端的Nginx并没有把旧的IP去掉也没有把新的IP加上，这样就出现了最前端的Nginx和后端K8s不同步，这个程序其实是实时定期的去检测两端的数据是否一致，如果不一致它会去判断哪些数据是新的，哪些数据是正确的，把不正确的数据一一进行修复，中间件即完成这样一个功能。
根据本公开的实施例，当网页服务器中容器集信息发生变化需要同步到网页代理服务器内。当服务注册发现节点Consul中所注册的容器集信息发生变化，即Pod的生命周期发生变化和IP地址的变化，将变化的信息发送至网页代理服务器，保证网页服务器中的Pod信息和网页代理服务器中对应Pod信息保持一致。
图5是根据一示例性实施例示出的一种网页配置方法的流程图，如图5所示，该方法用于网页代理服务器，包括以下步骤。
在步骤S41中，获取服务注册发现节点中所注册的容器集信息。
在步骤S42中，同步更新网页代理服务器的容器集信息。
本公开实施例中，获取服务注册发现节点Consul中所注册的网页单体代码的容器集信息，Nginx-upsync模块同步更新网页代理服务器中网页平台(Openresty)的upstream列表的容器集信息。网页代理服务器中包括Nginx-upsync模块，用于向openresty内的upstream列表中写入或删除数据。
本公开实施例中，Upsync是开源的基于Nginx实现动态配置的三方模块。Nginx-Upsync-Module的功能是获取Consul的后端服务器(server)的列表，并动态更新Nginx的路由信息。此模块不依赖于任何第三方模块。Consul作为Nginx的数据库，利用Consul的关键字和值(Key-Value，KV)服务，每个Nginx Work进程独立的去获取各个Upstream的配置，并更新各自的路由。动态Upstream模块会动态的变更配置，同时会动态的往Consul里注册。
本公开实施例中，Upsync把Upstream的列表同步到Openresty，Upstream对Nginx来说就是它后端的服务组IP，现在对应的是每组Web的Pod IP。Upsync会把Pod IP同步到Openresty内，一旦K8s的Pod的发生了生命周期的变化，有的Pod销毁或漂移、有的Pod创建，Pod后端提供服务IP即发生变化，中间件就会把这个变化的Pod IP同步到Consul，同时Consul内的K-Value即发生变化，Consul变化之后Upsync模块前端对接Openresty后端对接Consul，因为Consul内数据变化，Upsync模块感知到之后就把它同步到Openresty的列表内。如此，即链条式的反应，K8s中的Pod创建或销毁IP等数据发生变化，Consul就随之发生变化，Consul变化后，Openresty也随之更新数据。
图6是根据一示例性实施例示出的一种网页配置方法的流程图，如图6所示，该方法用于网页代理服务器，包括以下步骤。
在步骤S51中，监测服务注册发现节点中的容器集信息。
在步骤S52中，响应于监测到服务注册发现节点中的容器信息发生更新，更新已获取到的容器集信息。
本公开实施例中，网页代理服务器的Upsync模块监测服务注册发现节点Consul中的容器集信息，当监测到Consul中的容器信息发生更新，更新已获取到的容器集信息。即Upsync模块将更新的Pod信息同步到Openresty的Upstream的列表，Upstream对Nginx来说就是它后端的服务组IP，现在对应的是每组Web的Pod IP，Upsync会把Pod IP同步到Openresty内。一旦K8s的Pod的发生了生命周期的变化,有Pod创建有的Pod销毁，Pod后端提供服务IP即发生变化，中间件就会把这个变化的Pod IP同步到Consul，同时Consul内的K-Value即发生变化，Consul变化之后Upsync模块前端对接Openresty后端对接Consul，因为Consul内数据变化，Upsync模块感知到之后就把它同步到openresty的列表内。如此，即链条式的反应，K8s中的Pod创建或销毁IP等数据发生变化，Consul就随之发生变化，Consul变化后，Openresty也随之更新数据。
图7是根据一示例性实施例示出的一种网页配置方法的示意图，如图7所示，运用开源的技术架构，Nginx的Upsync模块，服务注册发现节点Consul，K8s集群并搭配Golang语言编写的中间件，实现了前端反向代理，到后端Web应用的全自动串联。
本公开实施例中，Linux虚拟服务器(Linux Virtual Server，LVS)是一个虚拟的服务器集群系统，LVS主要用于多服务器的负载均衡。它工作在传输层，可以实现高性能，高可用的服务器集群技术。
本公开实施例中，Master是Kubernetes集群中的核心组件，是一整个集群的主控节点，它负责整个集群的任务调度和部署，Kubernetes中所有执行命令的操作都是发送给Master去执行的。Master节点一般为一台物理机，也可以是虚拟机，但是为了防止主节点宕机而造成整个集群任务执行失效，大部分情况下会选择稳定性强的物理机。
本公开实施例中，除了主节点之外，Kubernetes其它所有的节点都是Node节点(从节点)。在Kubernetes集群当中，Node都是具体的工作执行者，也是任务的承担者，承担着主节点所分配的调度任务。如果某个Node节点宕机了，主控节点会按照调度策略重新将任务调度到其它合适的Node节点之上。
本公开实施例中，Pod是Kubernetes集群中资源调度的最小单位，每次的调度都是以Pod为单位进行的而不是直接调度一个容器。Pod是由一个或多个容器组成的，其中还包括连接各个容器的共享存储卷以及各个容器的共享命名空间，每个容器都会在特定的端口上运行。Kubernetes中的每一个Pod都有自己的独立IP，也就是这个Pod命名空间对应的IP。Pod由Kubernetes统一创建、调度和管理，一般是利用Replication Controller进行部署，部署一个或多个Pod。Pod资源对象类似于物理机中的进程，逻辑上表示某个或多个应用程序的一个实例。每个Pod资源对象由一个或者多个容器组成，Pod中的容器类似与进程中的线程，同一个Pod资源对象中的容器共享自己所在的Pod资源对象中得各种计算资源。同时，当某个Pod资源对象中的存在多个容器时，内部容器之间的通信采用Localhost的方式进行。
本公开实施例中，PHP-FastCGI进程管理器(FastCGI Process Manager，FPM)是一个PHP FastCGI管理器，旨在将FastCGI进程管理整合进PHP包中。
本公开实施例中，API Server是Kubernetes集群中各个板块之间的交通枢纽，它主要的作用是对集群中的各个对象实施具体的操作，给资源对象提供增、删、改、查等服务。也是各类资源操作的API接口，用以提供内部调用或外部用户使用，使各个组件可以通过其完成数据传输与通信。
本公开实施例中，Container sync即的中间件，它是连接Consul集群和K8S集群中间的组件。Container sync会定时执行检测Consul集群和API Server中数据的一致性，如果不一致的话，会把API server中的数据向consul内进行同步。一旦出现数据不一致，以当前K8S中Master中的数据为准，由于各种原因Consul里边没有感知数据变化，所以对其数据进行更新。如果Consul集群和API Server中数据的保持一致，则不进行数据更新操作。
本公开实施例中，数据卷(Volume)是宿主机中的一个目录或文件，当容器目录和数据卷目录绑定后，对方的修改会立即同步。一个数据卷可以被多个容器同时挂载，一个容器也可以被挂载多个数据卷。
本公开实施例中，Upsync是开源的基于Nginx实现动态配置的三方模块。Nginx-Upsync-Module的功能是获取Consul的后端server的列表，并动态更新Nginx的路由信息。此模块不依赖于任何第三方模块。Consul作为Nginx的数据库，利用Consul的Key-Value服务，每个Nginx Work进程独立的去获取各个Upstream的配置，并更新各自的路由。动态Upstream模块会动态的变更配置，同时会动态的往Consul里注册。
本公开实施例中，Upsync把Upstream的列表同步到Openresty，Upstream对Nginx来说就是它后端的服务组IP，现在对应的是每组Web的Pod IP。Upsync会把Pod IP同步到Openresty内，一旦K8s的Pod的发生了生命周期的变化,有的Pod销毁有的Pod创建，Pod后端提供服务IP地址即发生变化，中间件就会把这个变化的Pod IP同步到Consul，同时Consul内的K-Value即发生变化，Consul变化之后Upsync模块前端对接Openresty后端对接Consul，因为Consul内数变化，Upsync模块感知到之后就把它同步到Openresty的列表内。如此即链条式的反应，K8s中的Pod创建或销毁IP等数据发生变化，Consul就随之发生变化，Consul变化后，Openresty也随之更新数据。
图8是根据一示例性实施例示出的一种容器集结构图，如图8所示，容器集Pod是一组一个或多个容器(例如Docker容器)的封装，一个Pod中保存着有关如何运行容器的规范，Pod中的所有容器具有共享的网络(例如IP)和存储(Volume)。Pod是Kubernetes中最小的可部署单位，也是Kubernetes中的实际工作负载。Pod的生命短暂，Kubernetes数据卷使得数据能够跨容器和主机重启实现持久化。Pod可以手动创建，也可以通过ReplicationController创建多份拷贝。Pod重启后IP可能会发生改变，可以使用Service完成IP地址的对外映射。
本公开通过创建网页组的容器集，并同步创建对应一个或多个容器的空目录用于存放临时文件和日志；响应于网页组对应单体代码存入数据卷，将网页组单体代码数据卷挂载于一个或多个容器；将网页单体代码同步挂载于网页服务器的共享存储空间。通过本公开可以解决大单体代码加入容器集后出现的网页服务器与网页代理服务器信息无法同步问题并简化服务器间的架构，还可以提高假日或流量高峰前扩容效率，如遇到宿主机宕机，可快速实现服务漂移，减少故障恢复时间
基于相同的构思，本公开实施例还提供一种服务器配置装置。
可以理解的是，本公开实施例提供的服务器配置装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。结合本公开实施例中所公开的各示例的单元及算法步骤，本公开实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同的方法来实现所描述的功能，但是这种实现不应认为超出本公开实施例的技术方案的范围。
图9是根据一示例性实施例示出的一种网页配置装置框图100。参照图9，该装置包括创建单元101和挂载单元102。
创建单元101，用于创建网页组的容器集，容器集中包括可挂载网页组对应单体代码数据卷的一个或多个容器，并同步创建对应一个或多个容器的空目录用于存放临时文件和日志；
挂载单元102，用于响应于网页组对应单体代码存入数据卷，将网页组单体代码数据卷挂载于一个或多个容器；还用于将网页组单体代码同步挂载于网页服务器的共享存储空间。
一种实施方式中，装置还包括：
注册单元103，用于将容器集信息注册于服务注册发现节点。
一种实施方式中，装置还包括：
更新单元104，用于响应于确定容器集发生更新，更新服务注册发现节点的容器集信息；
容器集发生更新包括新创建容器集和/或销毁容器集。
一种实施方式中，更新单元104采用如下方式确定容器集中的容器发生更新：
定时监测服务注册发现节点的容器集信息与容器集信息的一致性；
若监测到服务注册发现节点的容器集信息与容器集信息的不一致，则确定容器集发生更新并同步于服务注册发现节点。
一种实施方式中，注册单元103还用于：
将服务注册发现节点中所注册的容器集信息，发送至网页代理服务器。
图10是根据一示例性实施例示出的一种网页配置装置框图200。参照图10，该装置包括获取单元201和同步单元202。
获取单元201，用于获取服务注册发现节点中所注册的容器集信息；
同步单元202，用于同步更新网页代理服务器的容器集信息。
一种实施方式中，获取单元201采用如下方式获取服务注册发现节点中所注册的容器集信息，包括：
监测服务注册发现节点中的容器集信息；
响应于监测到服务注册发现节点中的容器信息发生更新，更新已获取到的容器集信息。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
图11是本公开电子设备一个应用实施例的结构示意图。下面参考图11，其示出了适于用来实现本申请实施例的终端设备或服务器的电子设备的结构示意图。如图11所示，该电子设备包括存储器，用于存储计算机程序以及一个或多个处理器，用于执行存储器中存储的计算机程序。在一例中，存储器可以是只读存储器(ROM)和/或随机访问存储器(RAM)。
在一例中，一个或多个处理器可以是一个或多个中央处理单元(CPU)，和/或一个或多个图像处理器(GPU)等，处理器可以根据存储在ROM中的可执行指令或者从存储部分加载到RAM中的可执行指令而执行各种适当的动作和处理。在一例中，电子设备还可以包括通信部，通信部可包括但不限于网卡，网卡可包括但不限于IB(Infiniband)网卡，处理器可与ROM和/或RAM中通信以执行可执行指令，通过总线与通信部相连、并经通信部与其他目标设备通信，从而完成本申请实施例提供的任一方法对应的操作，例如，基于时间衰减系数，计算得到用户活跃度；基于贡献内容的认可数量，计算得到用户受欢迎度；基于用户活跃度、用户受欢迎度，计算得到用户知识贡献能力。
此外，在RAM中，还可存储有装置操作所需的各种程序和数据。CPU、ROM以及RAM通过总线彼此相连。在有RAM的情况下，ROM为可选模块。RAM存储可执行指令，或在运行时向ROM中写入可执行指令，可执行指令使处理器执行本发明上述任一方法对应的操作。输入/输出(I/O)接口也连接至总线。通信部可以集成设置，也可以设置为具有多个子模块(例如多个IB网卡)，并在总线链接上。
以下部件连接至I/O接口：包括键盘、鼠标等的输入部分；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分；包括硬盘等的存储部分；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分。通信部分经由诸如因特网的网络执行通信处理。驱动器也根据需要连接至I/O接口。可拆卸介质，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器上，以便于从其上读出的计算机程序根据需要被安装入存储部分。
需要说明的，如图11所示的架构仅为一种可选实现方式，在具体实践过程中，可根据实际需要对上述图9的部件数量和类型进行选择、删减、增加或替换；在不同功能部件设置上，也可采用分离设置或集成设置等实现方式，例如GPU和CPU可分离设置或者可将GPU集成在CPU上，通信部可分离设置，也可集成设置在CPU或GPU上，等等。这些可替换的实施方式均落入本发明公开的保护范围。
图12示出了本公开的电子设备的一个实施例的结构示意图。下面参考图12，其示出了适于用来实现本申请实施例的终端设备或服务器的电子设备的结构示意图。如图12所示，该电子设备该电子设备包括处理器和存储器。电子设备也可以包括输入输出装置。存储器、输入输出装置均通过总线与处理器连接。其中，存储器，用于存储处理器执行的指令；处理器，用于调用存储器存储的指令，并执行上述实施例涉及的标签关联内容的方法。
本公开实施例中处理器可调用存储器存储的指令，进行确定待关联标签；根据待关联标签与数据内容所标注的词语标签的语义匹配结果，在数据内容中确定圈选内容；将圈选内容关联至待关联标签。其中，电子设备执行标签关联内容的过程，可参阅上述实施例描述的标签关联内容的方法实施过程，在此不再赘述。
本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，计算机可执行指令在计算机上运行时，执行上述实施例涉及的标签关联内容的方法。
本公开实施例还提供一种包含指令的计算机程序产品，当包含指令的计算机程序产品在计算机上运行时，使得计算机执行上述实施例涉及的标签关联内容的方法。
在一个或多个可选实施方式中，本公开实施例还提供了一种计算机可读存储介质，用于存储计算机可读指令，该指令被执行时使得计算机执行上述任一可能的实现方式中的标签关联内容的方法。在另一个可选例子中，该计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。
尽管在附图中以特定的顺序描述操作，但是不应将其理解为要求按照所示的特定顺序或是串行顺序来执行这些操作，或是要求执行全部所示的操作以得到期望的结果。在特定环境中，多任务和并行处理可能是有利的。
本公开的方法和装置能够利用标准编程技术来完成，利用基于规则的逻辑或者其他逻辑来实现各种方法步骤。还应当注意的是，此处以及权利要求书中使用的词语“装置”和“模块”意在包括使用一行或者多行软件代码的实现和/或硬件实现和/或用于接收输入的设备。
此处描述的任何步骤、操作或程序可以使用单独的或与其他设备组合的一个或多个硬件或软件模块来执行或实现。在一个实施方式中，软件模块使用包括包含计算机程序代码的计算机可读介质的计算机程序产品实现，其能够由计算机处理器执行用于执行任何或全部的所描述的步骤、操作或程序。
出于示例和描述的目的，已经给出了本公开实施的前述说明。前述说明并非是穷举性的也并非要将本公开限制到所公开的确切形式，根据上述教导还可能存在各种变形和修改，或者是可能从本公开的实践中得到各种变形和修改。选择和描述这些实施例是为了说明本公开的原理及其实际应用，以使得本领域的技术人员能够以适合于构思的特定用途来以各种实施方式和各种修改而利用本公开。
可以理解的是，本公开中“多个”是指两个或两个以上，其它量词与之类似。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
进一步可以理解的是，术语“第一”、“第二”等用于描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开，并不表示特定的顺序或者重要程度。实际上，“第一”、“第二”等表述完全可以互换使用。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。
进一步可以理解的是，除非有特殊说明，“连接”包括两者之间不存在其他构件的直接连接，也包括两者之间存在其他元件的间接连接。
进一步可以理解的是，本公开实施例中尽管在附图中以特定的顺序描述操作，但是不应将其理解为要求按照所示的特定顺序或是串行顺序来执行这些操作，或是要求执行全部所示的操作以得到期望的结果。在特定环境中，多任务和并行处理可能是有利的。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利范围来限制。

Claims (13)

1.一种网页配置方法，其特征在于，应用于网页服务器，所述方法包括：
创建网页组的容器集，所述容器集中包括可挂载所述网页组对应单体代码数据卷的一个或多个容器，并同步创建对应所述一个或多个容器的空目录用于存放临时文件和日志；
响应于所述网页组对应单体代码存入数据卷，将所述网页组单体代码数据卷挂载于所述一个或多个容器；
将所述网页组单体代码同步挂载于所述网页服务器的共享存储空间。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
将容器集信息注册于服务注册发现节点。
3.根据权利要求2所述的方法，其特征在于，所述方法还包括：
响应于确定容器集发生更新，更新所述服务注册发现节点的容器集信息；
所述容器集发生更新包括新创建容器集和/或销毁容器集。
4.根据权利要求3所述的方法，其特征在于，所述确定容器集中发生更新，包括：
定时监测所述服务注册发现节点的容器集信息与所述容器集信息的一致性；
若监测到所述服务注册发现节点的容器集信息与所述容器集信息的不一致，则确定容器集发生更新并同步于服务注册发现节点。
5.根据权利要求2至4中任意一项所述的方法，其特征在于，所述方法还包括：
将所述服务注册发现节点中所注册的容器集信息，发送至网页代理服务器。
6.一种网页配置方法，其特征在于，应用于网页代理服务器，所述方法包括：
获取服务注册发现节点中所注册的容器集信息；
同步更新所述网页代理服务器中的所述容器集信息。
7.根据权利要求6所述的方法，其特征在于，所述获取服务注册发现节点中所注册的容器集信息，包括：
监测服务注册发现节点中的容器集信息；
响应于监测到所述服务注册发现节点中的容器信息发生更新，更新已获取到的所述容器集信息。
8.一种网页配置装置，其特征在于，应用于网页服务器，所述装置包括：
创建单元，用于创建网页组的容器集，所述容器集中包括可挂载所述网页组对应单体代码数据卷的一个或多个容器，并同步创建对应所述一个或多个容器的空目录用于存放临时文件和日志；
挂载单元，用于响应于所述网页组对应单体代码存入数据卷，将所述网页组单体代码数据卷挂载于所述一个或多个容器；还用于将所述网页组单体代码同步挂载于所述网页服务器的共享存储空间。
9.一种网页配置方法，其特征在于，应用于网页代理服务器，所述方法包括：
获取单元，用于获取服务注册发现节点中所注册的容器集信息；
同步单元，用于同步更新所述网页代理服务器中的所述容器集信息。
10.一种网页配置装置，其特征在于，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：执行权利要求1至5中任意一项所述的方法。
11.一种网页配置装置，其特征在于，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：执行权利要求6至7中任意一项所述的方法。
12.一种存储介质，其特征在于，所述存储介质中存储有指令，当所述存储介质中的指令由网页服务器的处理器执行时，使得网页服务器能够执行权利要求1至5中任意一项所述的方法。
13.一种存储介质，其特征在于，所述存储介质中存储有指令，当所述存储介质中的指令由网页代理服务器的处理器执行时，使得网页代理服务器能够执行权利要求6至7中任意一项所述的方法。
CN202310031852.6A 2023-01-10 2023-01-10 一种网页配置方法、装置及存储介质 Pending CN116094897A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310031852.6A CN116094897A (zh) 2023-01-10 2023-01-10 一种网页配置方法、装置及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310031852.6A CN116094897A (zh) 2023-01-10 2023-01-10 一种网页配置方法、装置及存储介质

Publications (1)

Publication Number Publication Date
CN116094897A true CN116094897A (zh) 2023-05-09

Family

ID=86200507

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310031852.6A Pending CN116094897A (zh) 2023-01-10 2023-01-10 一种网页配置方法、装置及存储介质

Country Status (1)

Country Link
CN (1) CN116094897A (zh)

Similar Documents

Publication Publication Date Title
CN112118565B (zh) 多租户服务灰度发布方法、装置、计算机设备和存储介质
CN107515776B (zh) 业务不间断升级方法、待升级节点和可读存储介质
US10237118B2 (en) Efficient application build/deployment for distributed container cloud platform
US8850430B2 (en) Migration of virtual machines
US6745241B1 (en) Method and system for dynamic addition and removal of multiple network names on a single server
CN112099918A (zh) 容器化环境中的集群的实时迁移
US11853816B2 (en) Extending the Kubernetes API in-process
CN110088733A (zh) 虚拟机迁移的基于存储层的编排
US20100318608A1 (en) Systems and methods for efficient live application migration within bandwidth constrained networks
US9256463B2 (en) Method and apparatus to replicate stateful virtual machines between clouds
CN101271409A (zh) 用于迁移逻辑分区的装置和方法以及产品
US11531526B1 (en) Creating portable serverless applications
US20210089379A1 (en) Computer system
US20190317840A1 (en) Integrating transaction processing system interfaces with event-driven polyglot runtime modules
CN113315754A (zh) 容器出访防火墙智能联动方法及装置、设备、介质
US9893936B2 (en) Dynamic management of restful endpoints
US11494184B1 (en) Creation of transportability container files for serverless applications
CN114356504A (zh) 集群中数据迁移方法、装置、电子设备和存储介质
CN112035062B (zh) 云计算的本地存储的迁移方法、计算机设备及存储介质
US20130283297A1 (en) Shared versioned workload partitions
CN111581285B (zh) 数据信息的同步方法、装置、电子设备和介质
CN111459619A (zh) 一种基于云平台实现服务的方法和装置
CN105653566B (zh) 一种实现数据库写访问的方法及装置
US11513833B1 (en) Event listener interface for container-based execution of serverless functions
US11803448B1 (en) Faster restart of task nodes using periodic checkpointing of data sources

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination