CN116931976A - 微服务的管理方法、电子设备和计算机可读存储介质 - Google Patents
微服务的管理方法、电子设备和计算机可读存储介质 Download PDFInfo
- Publication number
- CN116931976A CN116931976A CN202210351720.7A CN202210351720A CN116931976A CN 116931976 A CN116931976 A CN 116931976A CN 202210351720 A CN202210351720 A CN 202210351720A CN 116931976 A CN116931976 A CN 116931976A
- Authority
- CN
- China
- Prior art keywords
- micro
- services
- namespace
- deployed
- service
- 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
Links
- 238000007726 management method Methods 0.000 title abstract description 28
- 238000000034 method Methods 0.000 claims abstract description 28
- 230000006870 function Effects 0.000 claims description 21
- 238000012795 verification Methods 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 5
- 230000008569 process Effects 0.000 claims description 5
- 239000004973 liquid crystal related substance Substances 0.000 claims 2
- 230000000739 chaotic effect Effects 0.000 abstract description 6
- 238000004891 communication Methods 0.000 abstract description 2
- 238000013508 migration Methods 0.000 description 10
- 230000005012 migration Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 7
- 238000012360 testing method Methods 0.000 description 6
- 238000013500 data storage Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000005096 rolling process Methods 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 101150053844 APP1 gene Proteins 0.000 description 1
- 101100055496 Arabidopsis thaliana APP2 gene Proteins 0.000 description 1
- 101100189105 Homo sapiens PABPC4 gene Proteins 0.000 description 1
- 102100039424 Polyadenylate-binding protein 4 Human genes 0.000 description 1
- 101100016250 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) GYL1 gene Proteins 0.000 description 1
- 102100038359 Xaa-Pro aminopeptidase 3 Human genes 0.000 description 1
- 101710081949 Xaa-Pro aminopeptidase 3 Proteins 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Abstract
本申请实施例涉及通信技术领域，公开了一种微服务的管理方法、电子设备和计算机可读存储介质。上述微服务的管理方法包括：建立与第一命名空间对应的第二命名空间；其中，所述第一命名空间内部署有n个第一版本的微服务，n大于1；在所述第二命名空间内部署n个第二版本的所述微服务；在需要对所述第一命名空间内的微服务升级时，以命名空间为单位将所述第一命名空间内部署的第一版本的微服务升级为所述第二命名空间内部署的第二版本的微服务，使得可以在进行微服务升级的同时，避免n个微服务之间版本不同带来的混乱状态，确保业务逻辑正常进行。
Description
技术领域
本申请实施例涉及通信技术领域，特别涉及一种微服务的管理方法、电子设备和计算机可读存储介质。
背景技术
在以容器技术为基础的集群上，多个微服务彼此独立，共同协作为客户提供服务。Kubernetes目前提供的微服务的升级方式为：在Kubernetes集群中，通过滚动更新(Rolling Updates)完成微服务升级。滚动更新通过使用新的实例逐步更新Pod实例，新的Pod采用新的版本，逐步代替旧版本的Pod。当所有的Pod实例更新为新版本后，升级完成。
但是，上述Kubernetes提供的升级方式较为简单，单独升级多个微服务中的某一个后，可能会因多个微服务之间版本不同带来混乱状态，破坏业务逻辑正常进行。
发明内容
本申请实施例的主要目的在于提出一种微服务的管理方法、电子设备和计算机可读存储介质，使得可以在进行微服务升级的同时，避免n个微服务之间版本不同带来的混乱状态，确保业务逻辑正常进行。
为至少实现上述目的，本申请实施例提供了一种微服务的管理方法，包括：建立与第一命名空间对应的第二命名空间；其中，所述第一命名空间内部署有n个第一版本的微服务，n大于1；在所述第二命名空间内部署n个第二版本的所述微服务；在需要对所述第一命名空间内的微服务升级时，以命名空间为单位将所述第一命名空间内部署的第一版本的微服务升级为所述第二命名空间内部署的第二版本的微服务。
为至少实现上述目的，本申请实施例提供了一种电子设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的微服务的管理方法。
为至少实现上述目的，本申请实施例提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述的微服务的管理方法。
本申请实施例提供的微服务的管理方法中，第一命名空间内部署有n个第一版本的微服务，通过建立与第一命名空间对应的第二命名空间，在第二命名空间内部署n个第二版本的所述微服务。即对于相同的微服务，在不同的命名空间中部署有不同版本，由于第一命名空间和第二命名空间是两个不同的命名空间，所以同时部署微服务时不会冲突。在需要对第一命名空间内的微服务升级时，以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务。由于微服务的部署和升级是以命名空间为单位，这样同一个命名空间内部的n个微服务也是同时升级的，避免n个微服务之间版本不同带来的混乱状态，确保业务逻辑正常进行。当n个微服务之间的具有相互依赖关系时，本申请实施例可以在进行微服务升级的同时，避免打破微服务升级之前的n个微服务之间的依赖关系，即保护了n个微服务之间的依赖关系，确保业务逻辑正常进行。
附图说明
图1是本申请实施例中提到的微服务的管理方法的流程图；
图2是本申请实施例中提到的第一命名空间和第二命名空间内部署的微服务的示意图；
图3是本申请实施例中提到的实现微服务的管理方法的架构示意图；
图4是本申请实施例中提到的业务流量通过网关实现迁移的示意图；
图5是本申请实施例中提到的DNS服务器实现迁移的示意图；
图6是本申请实施例中提到的电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
本申请实施例涉及一种微服务的管理方法，应用于电子设备，该电子设备可以为微服务的管理设备，比如可以为运维中心。微服务可以为以容器技术为基础的容器编排平台Kubernetes集群上的微服务，即微服务可以部署在容器中。运维中心对微服务的管理也可以理解为对微服务集群的管理。微服务本身也可以理解为实现预设业务功能的应用(Application，APP)。本实施例的微服务的管理方法的流程图可以参阅图1，包括：
步骤101：建立与第一命名空间对应的第二命名空间；其中，第一命名空间内部署有n个第一版本的微服务，n大于1。
步骤102：在第二命名空间内部署n个第二版本的所述微服务。
步骤103：在需要对第一命名空间内的微服务升级时，以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务。
本实施例中，对于相同的微服务，在不同的命名空间中部署有不同版本，由于第一命名空间和第二命名空间是两个不同的命名空间，所以同时部署微服务时不会冲突。在需要对第一命名空间内的微服务升级时，以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务。由于微服务的部署和升级是以命名空间为单位，这样同一个命名空间内部的n个微服务也是同时升级的，避免n个微服务之间版本不同带来的混乱状态，确保业务逻辑正常进行。当n个微服务之间的具有相互依赖关系时，本申请实施例可以在进行微服务升级的同时，避免打破微服务升级之前的n个微服务之间的依赖关系，即保护了n个微服务之间的依赖关系，确保业务逻辑正常进行。
下面对本实施例的微服务的管理方法的实现细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本方案的必须。
本实施例以命名空间为单位，把一个命名空间内的多个微服务合并在一起部署和升级。命名空间可以理解为：Kubernetes集群下的一组微服务，共同分享Kubernetes集群资源，是一种划分集群资源的单位。即第一命名空间和第二命名空间可以理解为Kubernetes集群下的两组微服务，第一命名空间可以为Kubernetes集群下正在运行的一组微服务，这一组微服务中包括n个第一版本的微服务。n个第一版本的微服务之间可以存在相互依赖关系，比如，n个第一版本的微服务包括用于实现接单功能的微服务，用于实现发单功能的微服务、和用于实现订单信息存储功能的微服务。然而，本实施例对微服务之间的相互依赖关系不做具体限定，n个第一版本的微服务之间也可以不存在相互依赖关系。其中，正在运行的一组微服务可以理解为已经能够实现某种预设业务功能的微服务。
在步骤101中，管理设备可以建立与第一命名空间对应的第二命名空间。比如可以通过命令行或脚本实现第二命名空间的建立。当管理设备为具有人机交互界面的运维中心时，通过该运维中心的人机交互界面可以方便且直观的建立与第一命名空间对应的第二命名空间。第二命名空间下可以部署的微服务的数量与第一命名空间下部署的微服务的数量相同。
在步骤102中，管理设备可以在第二命名空间内部署n个第二版本的所述微服务。第二命名空间内部署的微服务和第一命名空间内部署的微服务的区别在于版本不同，第一命名空间内部署的每个第一版本的微服务，在第二命名空间内均具有第二版本的微服务。即对于同一微服务，在第一命名空间和第二命名空间内分别部署有第一版本和第二版本。
为便于理解，下面参考图2对上述的第一命名空间和第二命名空间内部署的微服务进行说明：
第一命名空间可以理解为原命名空间，记为NS_v1，第二命名空间可以理解为新的命名空间，记为NS_v2。当n＝3时，NS_v1内和NS_v2内部署的3个微服务分别记为APP1、APP2、APP3。如果第一版本(旧版本)记为v1，第二版本(新版本)记为v2，则如图2所示，NS_v1内部署的3个第一版本的微服务分别记为APP1_v1、APP2_v1、APP3_v1，NS_v2内部署的3个第二版本的微服务分别记为APP1_v2、APP2_v2、APP3_v2。
在步骤103中，在需要对第一命名空间内的微服务升级时，以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务。本实施例中，对于第一命名空间NS_v1内的微服务升级可以理解为将业务流量从NS_v1切换到NS_v2。切换可以是通过接入网关完成，也可以是通过域名系统(Domain Name System，DNS)服务器修改NS_v2的DNS域名完成。
本实施例中，由于NS_v1和NS_v2是两个不同的命名空间，所以同时部署而不会冲突。当NS_v2出了问题，可以瞬时切回NS_v1，而不用重新部署一次NS_v1，减少了回滚时间。而且，由于部署和切换的单位是命名空间，这样同一个命名空间内部的微服务是同时升级的，避免了微服务之间版本不同带来的混乱状态。也就是说，新旧版本的微服务在不同的命名空间下可以共存，使得微服务部署和业务切换分离，可以按需切换或者回退。
在一些实施例中，在执行步骤103中的以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务之前，还包括：确定第二命名空间内部署的n个第二版本的微服务通过预设的功能验证。其中，预设的功能验证可以根据实际需要进行设置，旨在对第二命名空间内部署的第二版本的微服务完成必要的自检和通过相关测试用例的测试。预设的功能验证也可以理解为对第二命名空间内部署的n个第二版本的微服务执行内部健康检查，确保第二命名空间内部署的n个第二版本的微服务后续能够准确实现相关业务功能。
本实施例中，实际采用了基于命名空间的蓝(第一版本V1)绿(第二版本V2)部署方式，即在已有NS_APP_V1的情况下，部署第二版本的微服务NS_APP_V2。NS_APP_V2部署完成后，在业务流量切换之前，首先完成必要的自检和通过相关测试用例测试，以通过预设的功能验证。第二命名空间NS_v2内第二版本的微服务部署完成后，通过先执行预设的功能验证以进行内部健康检查，而不切换业务流量，减轻了升级的风险。
在一些实施例中，上述的步骤103中以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务，包括：向第一网关发送命名空间的切换指令；在切换指令为将第一命名空间切换为第二命名空间的指令的情况下，控制第一网关将接收到的对目标微服务的访问指令中的第一部分访问指令，发送至第一命名空间内部署的目标微服务，并将访问指令中的第二部分访问指令，发送至第二命名空间内部署的目标微服务。
在一些实施例中，管理设备可以在适当的时机向第一网关发送命名空间的切换指令。适当的时机可以为确定第二命名空间内的n个第二版本的微服务部署完成，也可以为第二命名空间内的n个第二版本的微服务部署完成且通过预设的功能验证。切换指令可以为第一切换指令或第二切换指令，第一切换指令为将第一命名空间切换为第二命名空间的指令，第二切换指令为将第二命名空间切换为第一命名空间的指令。
第一网关在接收到管理设备发送的命名空间的切换指令后，执行对命名空间的切换，比如当第一网关接收到第一切换指令，第一网关将当前的命名空间配置为第二命名空间，当第一网关接收到第二切换指令，第一网关将当前的命名空间配置为第一命名空间。
在切换指令为将第一命名空间切换为第二命名空间的指令的情况下，第一网关在接收到客户端对目标微服务的访问指令后，可以根据预设的分配规则将接收到的访问指令划分成第一部分访问指令和第二部分访问指令，然后将第一部分访问指令发送给第一命名空间内部署的目标微服务，即发送至第一版本的目标微服务，将第二部分访问指令发送给第二命名空间内部署的目标微服务，即发送至第二版本的目标微服务。其中，预设的分配规则可以根据实际需要设置，比如分配规则可以为：根据预先设置的不同的命名空间能够承担的流量的权重进行分配，或者还可以为：根据业务类型进行分配。然而，本实施例对流量的分配规则不做具体限定。
在一些实施例中，如在刚部署完第二版本的微服务后的一段时间内，第二部分访问指令的数量小于第一部分访问指令，即第二命名空间承担的业务流量小于第一命名空间承担的业务流量，以实现通过第一网关逐渐将业务流量从第一命名空间切换到第二命名空间。在此过程中，可以观测第二命名空间对业务的执行效果，以减少因微服务升级可能对业务的冲击。
本实施例中，通过网关逐渐迁移流量：微服务均通过网关对外提供服务，蓝绿部署的情况下，新旧版本的微服务同时接入网关，网关流量切换可以按照百分比逐步断流旧版本微服务。也就是说，第一命名空间NS_v1到第二命名空间NS_v2的流量切换，可以通过第一网关逐渐切换，方便观测效果，减少可能对业务的冲击。
在一些实施例中，在切换指令为将第二命名空间切换为第一命名空间的指令的情况下，第一网关在接收到客户端对目标微服务的访问指令后，可以将访问指令发送至第一命名空间内部署的目标微服务，即发送至第一版本的目标微服务。如果微服务升级后业务出现问题需要回滚，则可以直接通过网关将业务流量切回至第一命名空间内，而不需要一个逐渐创建旧版本即第一版本的过程，避免回滚耗时过长，影响业务。
在一些实施例中，上述的步骤103中以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务，包括：向第一DNS服务器发送命名空间的切换指令；在切换指令为将第一命名空间切换为第二命名空间的指令的情况下，通过第一DNS服务器查询待访问的目标微服务的访问地址；其中，目标微服务的访问地址指向第二命名空间中部署的目标微服务的地址。在具体实现中，目标微服务的访问地址可以包括目标微服务的IP地址和端口号。DNS服务器查询的访问地址可以形如：
<svc name>.SVC.<namespace>.CLUSTER.LOCAL，然而，本实施例对此不做具体限定。
在一些实施例中，管理设备可以在适当的时机向第一DNS服务器发送命名空间的切换指令。适当的时机可以为确定第二命名空间内的n个第二版本的微服务部署完成，也可以为第二命名空间内的n个第二版本的微服务部署完成且通过预设的功能验证。切换指令可以为第一切换指令或第二切换指令，第一切换指令为将第一命名空间切换为第二命名空间的指令，第二切换指令为将第二命名空间切换为第一命名空间的指令。
第一DNS服务器在接收到管理设备发送的命名空间的切换指令后，执行对命名空间的切换，比如当第一DNS服务器接收到第一切换指令，第一DNS服务器将当前的命名空间配置为第二命名空间，当第一DNS服务器接收到第二切换指令，第一DNS服务器将当前的命名空间配置为第一命名空间。
客户端可以向第一DNS服务器发送待访问的目标微服务的访问地址的查询请求，第一DNS服务器接收到该查询请求后，查询目标微服务的访问地址，并将查询到的访问地址返回给客户端，以供客户端根据接收到的访问地址访问目标微服务。在切换指令为将第一命名空间切换为第二命名空间的指令的情况下，目标微服务的访问地址指向第二命名空间中部署的目标微服务的地址。也就是说，本实施例中可以通过DNS服务器将业务流量从第一命名空间切换到第二命名空间，以实现业务流量的一次性切换，一次性切换能够带来一致性保证，且加快了业务流量的切换速度。
在一些实施例中，在第一DNS服务器接收的切换指令为将第二命名空间切换为第一命名空间的指令的情况下，通过第一DNS服务器查询待访问的目标微服务的访问地址；其中，目标微服务的访问地址指向第一命名空间中部署的目标微服务的地址。如果微服务升级后业务出现问题需要回滚，则可以直接通过DNS将业务流量切回至第一命名空间内，而不需要一个逐渐创建旧版本即第一版本的过程，避免回滚耗时过长，影响业务。
本实施例中，通过DNS来一步切换：集群中的微服务均注册为DNS服务，通过运维中心，可以把APP.SVC.NS_APP.CLUSTER.LOCAL导向新版本的APP.SVC.NS_APP_V2.CLUSTER.LOCAL或者旧版本的APP.SVC.NS_APP_V1.CLUSTER.LOCAL。
在一些实施例中，第一命名空间包括第一应用命名空间和第一状态命名空间，第一应用命名空间内部署的微服务为第一版本的无状态微服务，第一状态命名空间内部署的微服务为第一版本的状态微服务，第一版本的状态微服务用于存储第一版本的无状态微服务的状态数据。第二命名空间包括第二应用命名空间和第二状态命名空间，第二应用命名空间内部署的微服务为第二版本的无状态微服务，第二状态命名空间内部署的微服务为第二版本的状态微服务，第二版本的状态微服务用于存储第二版本的无状态微服务的状态数据。
本实施例，将命名空间分为两类，一类是应用命名空间Application，应用命名空间下部署的微服务均为无状态微服务。另一类是状态命名空间Data，状态命名空间下部署的微服务专门用来存储无状态微服务的状态数据。也就是说，本实施例中，将微服务的状态外置，即微服务的状态数据(如数据库)部署在另外一个命名空间，即把应用和状态分置为不同的命名空间，以实现逻辑和数据的分离，避免因微服务故障其内部的状态数据消失而影响后续业务功能的实现。
在一些实施例中，在需要对第一应用命名空间内部署的微服务和第一状态命名空间内部署的微服务升级的情况下，以命名空间为单位将第一命名空间内部署的第一版本的微服务升级为第二命名空间内部署的第二版本的微服务，包括：将第一应用命名空间内部署的微服务升级为第二应用命名空间内部署的微服务。在确认对第一应用命名空间内部署的微服务升级成功后，将第一状态命名空间内部署的微服务升级为第二状态命名空间内部署的微服务。
本实施例中，第一应用命名空间记为NS_APP_V1，第一状态命名空间记为NS_DATA_V1，第二应用命名空间记为NS_APP_V2，第二状态命名空间记为NS_DATA_V2。考虑到新版本V2的APP可以兼容旧版本V1的DATA，因此，如果NS_APP_V1和NS_DATA_V1中的微服务都需要升级，则可以先升级NS_APP_V1中的微服务，确认NS_APP_V1无误后再升级NS_DATA_V1中的微服务。有利于在不影响业务功能实现的基础上，依次实现NS_APP_V1和NS_DATA_V1中的微服务的升级。
在一些实施例中，在第二应用命名空间内部署的无状态微服务需要访问目标状态微服务的情况下，通过第二DNS服务器查询目标状态微服务的访问地址；其中，目标状态微服务的访问地址指向第二版本的目标状态微服务的地址；或者，在第二应用命名空间内部署的无状态微服务需要访问目标状态微服务的情况下，通过第二网关将访问目标状态微服务的请求，发送给第二版本的目标状态微服务。在具体实现中，目标状态微服务的访问地址可以包括目标状态微服务的IP和端口号。
其中，无状态微服务需要访问目标状态微服务，说明无状态微服务需要访问后台的数据存储，此时无状态微服务可以发起对第二网关的调用，以通过第二网关实现对目标状态微服务中存储的状态数据的访问。或者无状态微服务可以发起对第二DNS服务器的调用，以通过第二DNS服务器查询目标状态微服务的访问地址，从而实现对目标状态微服务中存储的状态数据的访问。
在一些实施例中，实现微服务的管理方法的架构示意图可以参阅图3，包括：
运维中心：负责网关的配置以及DNS服务器的配置。其中，配置可以理解为网关或DNS服务器在接收到命名空间的切换指令后，对当前的命名空间的配置。需要说明的是，运维中心可以作为微服务管理的操作入口，但并不是绝对必须，也可以通过API接口完成微服务管理的操作。
DNS服务器：负责注册，查询各个微服务的地址，返回微服务的IP和端口号。
网关：负责代表微服务对外提供访问接口，将业务流量导向不同的微服务。
NS_APP：应用命名空间，即无状态微服务APP所在的命名空间，包含多个APP。图3中的APP的版本为第一版本V1，因此部署有第一版本V1的APP的应用命名空间记为NS_APP_V1。
NS_DATA：状态命名空间，即状态微服务DATA所在的命名空间，可以包含多个用于存储状态数据的微服务，是APP存放状态的地方。图3中的微服务的版本为第一版本V1，因此部署有第一版本V1的DATA的应用命名空间记为NS_DATA_V1。
容器编排系统可以为Kubernetes。
在一些实施例中，微服务的管理方法中涉及业务流量的迁移，业务流量的迁移通过网关实现，业务流量通过网关实现迁移的示意图可以参阅图4，包括：
步骤0.外部用户通过网关1访问内部微服务。
步骤1.该微服务由部署在第一应用命名空间NS_APP_V1的微服务提供。
步骤2.NS_APP_V1中的微服务访问后台的数据存储，发起对网关2的调用。
步骤3.NS_APP_V1中的微服务访问后台的数据存储，由部署在第一状态命名空间NS_DATA_V1的微服务提供。
步骤4.待V2版本的微服务部署通过用户的功能验证后，网关1将一部分流量导向第二应用命名空间NS_APP_V2的V2版本的微服务。
步骤5.NS_APP_V2中的微服务访问后台的数据存储，发起对网关2的调用。
步骤6.NS_APP_V2中的微服务访问后台的数据存储，由部署在第二状态命名空间NS_DATA_V2的微服务提供。
从上述步骤看出，蓝(V1版本的部署)绿(V2版本的部署)部署同时存在，导流通过网关控制，可以方便的在不同命名空间之间，按照权重，或者业务类型切换流量。
在一些实施例中，微服务的管理方法中涉及业务流量的迁移，业务流量的迁移通过DNS服务器实现，业务流量通过DNS服务器实现迁移的示意图可以参阅图5，包括：
步骤0.客户端通过DNS服务器1获取待访问的微服务的IP地址和端口。客户端查询的服务地址为APP.SVC.NS_APP.CLUSTER.LOCAL。
步骤1.如果当前版本是V1，则APP.SVC.NS_APP.CLUSTER.LOCAL指向NS_APP_V1中部署的微服务的地址。其中，如果DNS服务器1将当前的命名空间配置为第一命名空间NS_V1，则当前版本是V1。如果DNS服务器1将当前的命名空间配置为第二命名空间NS_V2，则当前版本是V2。
步骤2.第一应用命名空间NS_APP_V1中的微服务访问后台的数据存储，查询DNS服务器2获取DATA.SVC.NS_DATA.CLUSTER.LOCAL微服务的IP地址和端口。
步骤3.如果当前版本是V1，则DATA.SVC.NS_DATA.CLUSTER.LOCAL指向第一状态命名空间NS_DATA_V1中部署的微服务的地址。
步骤4.待V2版本部署通过用户的功能验证后，DNS服务器1更新对命名空间的配置，将当前的命名空间配置为第二命名空间NS_V2，把微服务地址指向第二应用命名空间NS_APP_V2的V2版本的微服务。此时，用户仍然访问APP.SVC.NS_APP.CLUSTER.LOCAL，但此时APP.SVC.NS_APP.CLUSTER.LOCAL指向NS_APP_V2中部署的微服务的地址。
步骤5.NS_APP_V2中的微服务通过DNS服务器2获取DATA.SVC.NS_DATA.CLUSTER.LOCAL微服务的IP地址和端口。
步骤6.此时，DATA.SVC.NS_DATA.CLUSTER.LOCAL指向第二状态命名空间NS_DATA_V2中部署的微服务。
从上述步骤看出，蓝绿部署同时存在，导流通过DNS服务器控制，可以方便的在不同命名空间之间切换流量。
本申请的发明人发现Kubernetes目前提供的微服务的升级方式，存在如下问题：
1、当多个微服务之间有相互依赖，单独升级某一个微服务，可能打破之前的依赖关系，破坏业务逻辑。
2、很多微服务只支持单个副本，单一副本的应用，在删除旧版本和新建新版本之间，避免不了窗口期的业务影响。
3、升级一旦完成，旧版本的微服务即全部消失，若此时出现问题需要降级，则需要完整走完降级过程，业务影响比较大。
4、升级过程和服务切换几乎同时进行。万一出现问题，为现场运维带来很大压力。
本申请实施例提供的微服务的管理方法，可以较好的解决上述问题。具体的：
1、本实施例是基于命名空间级别进行微服务的部署和升级，粒度更大，较好的解决了命名空间内微服务相互依赖带来的升级问题。也就是说，以命名空间为单位的升级，减少了微服务版本交叉依赖带来的升级难题。
2、本实施例中，新旧版本的微服务在不同的命名空间下可以共存，并不会删除旧版本的微服务，使得微服务部署和业务切换分离，可以按需切换或者回退，避免了窗口期的业务影响。
3、本实施例中在将微服务升级为新版本后，保留保留旧版本的微服务，方便在需要时快速回滚，降低对业务的影响。
4、本实施例中在流量切换之前，首先可以完成必要的自检和通过相关测试用例的测试，减轻了升级的风险。或者说，本实施例通过先部署新版本的微服务，通过功能验证后，再切换流量，减少了一步直接升级带来的不确定性，以减小现场运维压力。
而且，本实施例将NS_APP和NS_DATA分开，因为APP的升级通常远比DATA来的频繁，更多的时候，用户只需要升级APP即可。可见，将NS_APP和NS_DATA分开有助于APP的快速升级，从而更好的满足用户的升级需求。
需要说明的是，本申请实施例中的上述各示例均为为方便理解进行的举例说明，并不对本发明的技术方案构成限定。
上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。
本申请实施例还提供了一种电子设备，如图6所示，包括至少一个处理器201；以及，与至少一个处理器201通信连接的存储器202；其中，存储器202存储有可被至少一个处理器201执行的指令，指令被至少一个处理器201执行，以使至少一个处理器201能够执行上述的微服务的管理方法。
其中，存储器202和处理器201采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器201和存储器202的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器201处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器201。
处理器201负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器202可以被用于存储处理器201在执行操作时所使用的数据。
本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。
即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。
Claims (10)
1.一种微服务的管理方法，其特征在于，包括：
建立与第一命名空间对应的第二命名空间；其中，所述第一命名空间内部署有n个第一版本的微服务，n大于1；
在所述第二命名空间内部署n个第二版本的所述微服务；
在需要对所述第一命名空间内的微服务升级时，以命名空间为单位将所述第一命名空间内部署的第一版本的微服务升级为所述第二命名空间内部署的第二版本的微服务。
2.根据权利要求1所述的微服务的管理方法，其特征在于，所述以命名空间为单位将所述第一命名空间内部署的第一版本的微服务升级为所述第二命名空间内部署的第二版本的微服务，包括：
向第一网关发送命名空间的切换指令；
在所述切换指令为将所述第一命名空间切换为所述第二命名空间的指令的情况下，控制所述第一网关将接收到的对目标微服务的访问指令中的第一部分访问指令，发送至所述第一命名空间内部署的所述目标微服务，并将所述访问指令中的第二部分访问指令，发送至所述第二命名空间内部署的所述目标微服务。
3.根据权利要求1所述的微服务的管理方法，其特征在于，所述以命名空间为单位将所述第一命名空间内部署的第一版本的微服务升级为所述第二命名空间内部署的第二版本的微服务，包括：
向第一DNS服务器发送命名空间的切换指令；
在所述切换指令为将所述第一命名空间切换为所述第二命名空间的指令的情况下，通过所述第一DNS服务器查询待访问的目标微服务的访问地址；其中，所述目标微服务的访问地址指向所述第二命名空间中部署的所述目标微服务的地址。
4.根据权利要求3所述的微服务的管理方法，其特征在于，所述方法还包括：
在所述切换指令为将所述第二命名空间切换为所述第一命名空间的指令的情况下，通过所述第一DNS服务器查询待访问的目标微服务的访问地址；其中，所述目标微服务的访问地址指向所述第一命名空间中部署的所述目标微服务的地址。
5.根据权利要求1至4任一项所述的微服务的管理方法，其特征在于，在所述以命名空间为单位将所述第一命名空间内部署的第一版本的微服务升级为所述第二命名空间内部署的第二版本的微服务之前，还包括：
确定所述第二命名空间内部署的n个第二版本的所述微服务通过预设的功能验证。
6.根据权利要求1至4任一项所述的微服务的管理方法，其特征在于，所述第一命名空间包括第一应用命名空间和第一状态命名空间，所述第一应用命名空间内部署的微服务为第一版本的无状态微服务，所述第一状态命名空间内部署的微服务为第一版本的状态微服务，所述第一版本的状态微服务用于存储所述第一版本的无状态微服务的状态数据；
所述第二命名空间包括第二应用命名空间和第二状态命名空间，所述第二应用命名空间内部署的微服务为第二版本的无状态微服务，所述第二状态命名空间内部署的微服务为第二版本的状态微服务，所述第二版本的状态微服务用于存储所述第二版本的无状态微服务的状态数据。
7.根据权利要求6所述的微服务的管理方法，其特征在于，在需要对所述第一应用命名空间内部署的微服务和所述第一状态命名空间内部署的微服务升级的情况下，所述以命名空间为单位将所述第一命名空间内部署的第一版本的微服务升级为所述第二命名空间内部署的第二版本的微服务，包括：
将所述第一应用命名空间内部署的微服务升级为所述第二应用命名空间内部署的微服务；
在确认对所述第一应用命名空间内部署的微服务升级成功后，将所述第一状态命名空间内部署的微服务升级为所述第二状态命名空间内部署的微服务。
8.根据权利要求6所述的微服务的管理方法，其特征在于，
在所述第二应用命名空间内部署的无状态微服务需要访问目标状态微服务的情况下，通过第二DNS服务器查询所述目标状态微服务的访问地址；其中，所述目标状态微服务的访问地址指向所述第二版本的所述目标状态微服务的地址；
或者，
在所述第二应用命名空间内部署的无状态微服务需要访问目标状态微服务的情况下，通过第二网关将访问所述目标状态微服务的请求，发送给所述第二版本的所述目标状态微服务。
9.一种电子设备，其特征在于，包括：至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至8中任一所述的微服务的管理方法。
10.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一所述的微服务的管理方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210351720.7A CN116931976A (zh) | 2022-04-02 | 2022-04-02 | 微服务的管理方法、电子设备和计算机可读存储介质 |
| PCT/CN2023/075289 WO2023185267A1 (zh) | 2022-04-02 | 2023-02-09 | 微服务的管理方法、电子设备和计算机可读存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210351720.7A CN116931976A (zh) | 2022-04-02 | 2022-04-02 | 微服务的管理方法、电子设备和计算机可读存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116931976A true CN116931976A (zh) | 2023-10-24 |
Family
ID=88199109
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210351720.7A Pending CN116931976A (zh) | 2022-04-02 | 2022-04-02 | 微服务的管理方法、电子设备和计算机可读存储介质 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN116931976A (zh) |
| WO (1) | WO2023185267A1 (zh) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10516672B2 (en) * | 2016-08-05 | 2019-12-24 | Oracle International Corporation | Service discovery for a multi-tenant identity and data security management cloud service |
| CN107515776B (zh) * | 2017-07-18 | 2021-04-09 | 深信服科技股份有限公司 | 业务不间断升级方法、待升级节点和可读存储介质 |
| CN113572689A (zh) * | 2021-09-24 | 2021-10-29 | 深圳市信润富联数字科技有限公司 | 微服务网关管理方法、系统、设备、可读存储介质及产品 |
| CN114040009B (zh) * | 2021-10-18 | 2024-04-30 | 浪潮云信息技术股份公司 | 微服务管理平台网关的实现方法、存储介质及电子设备 |
-
2022
- 2022-04-02 CN CN202210351720.7A patent/CN116931976A/zh active Pending
-
2023
- 2023-02-09 WO PCT/CN2023/075289 patent/WO2023185267A1/zh unknown
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023185267A1 (zh) | 2023-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2019184727A1 (zh) | 一种服务升级管理的方法、装置及存储介质 | |
| EP3291499A1 (en) | Method and apparatus for network service capacity expansion | |
| CN107967140B (zh) | 软件修改的发起方法、发布元数据的方法及装置 | |
| US9161239B2 (en) | Network access point management | |
| WO2018024204A1 (zh) | 虚拟网元的管理方法及装置 | |
| EP3883183A1 (en) | Virtualization management method and device | |
| EP4050850A1 (en) | Service upgrading method, device and system | |
| CN110391940A (zh) | 服务地址的响应方法、装置、系统、设备和存储介质 | |
| CN115185647A (zh) | virtio设备直通方法及相关装置 | |
| US10078532B2 (en) | Resource management method and device for terminal system among multiple operating systems | |
| CN109857464A (zh) | 用于平台部署与操作移动操作系统的系统及其方法 | |
| CN113079098B (zh) | 路由更新的方法、装置、设备和计算机可读介质 | |
| EP4258609A1 (en) | Container cluster management method and apparatus | |
| CN111726367B (zh) | 一种用户设备cpe接入绑定方法、装置、系统及设备 | |
| EP3843361A1 (en) | Resource configuration method and apparatus, and storage medium | |
| CN116931976A (zh) | 微服务的管理方法、电子设备和计算机可读存储介质 | |
| CN116095145A (zh) | 一种vpc集群的数据控制方法和系统 | |
| US11057463B2 (en) | Method for synchronizing context data of network functions in a mobile network | |
| CN109257201B (zh) | 一种License的发送方法和装置 | |
| CN111585795A (zh) | 一种通信设备的软件存储、加载与升级方法及系统 | |
| US11442756B2 (en) | Common service resource application method, related device, and system | |
| CN109981365A (zh) | 数据监听方法、装置、用户设备及存储介质 | |
| JP7184097B2 (ja) | ネットワーク機能仮想化システム及びオペレーティングシステム更新方法 | |
| US11853560B2 (en) | Conditional role decision based on source environments | |
| CN112003731B (zh) | 配置方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication |