WO2022188205A1 - 一种支持事务一致性的微服务动态更新方法 - Google Patents

一种支持事务一致性的微服务动态更新方法 Download PDF

Info

Publication number
WO2022188205A1
WO2022188205A1 PCT/CN2021/082368 CN2021082368W WO2022188205A1 WO 2022188205 A1 WO2022188205 A1 WO 2022188205A1 CN 2021082368 W CN2021082368 W CN 2021082368W WO 2022188205 A1 WO2022188205 A1 WO 2022188205A1
Authority
WO
WIPO (PCT)
Prior art keywords
version
service
request
traffic
transaction
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.)
Ceased
Application number
PCT/CN2021/082368
Other languages
English (en)
French (fr)
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.)
Nanjing University
Nanjing Tech University
Original Assignee
Nanjing University
Nanjing Tech University
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 Nanjing University, Nanjing Tech University filed Critical Nanjing University
Publication of WO2022188205A1 publication Critical patent/WO2022188205A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • 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/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Definitions

  • the invention relates to a microservice dynamic update method supporting transaction consistency, and belongs to the technical field of software maintenance.
  • microservice architecture As a new technology for deploying applications and services in the cloud, microservice architecture has become the latest popular architecture. Microservices architecture divides a complex software application into several smaller services, each of which can be deployed, upgraded, extended, and replaced independently. The microservices in the whole system are distributed, and users can obtain corresponding results by accessing the interfaces exposed by the system. The internal implementation of the system is transparent to users. At the same time, the low coupling between microservices effectively shortens the software development cycle and reduces the Software maintenance costs are more in line with the current requirements for rapid iteration and continuous delivery of Internet applications.
  • the traditional software update needs to stop, update and restart the software, but as users become more and more dependent on the system, the system interruption caused by the traditional update will bring great inconvenience to users and cause a significant increase in management costs, such as Some highly reliable service platforms hope to provide users with uninterrupted services throughout the day. Therefore, it is necessary to dynamically update the software system without interrupting the normal operation of the software. Dynamic update needs to ensure security, timeliness, low interference and other aspects in the update process.
  • the current common microservice update deployment scheme usually adopts the method of launching a new version, coexisting the old and new versions, and gradually diverting user requests to the new version. Although these schemes ensure the availability of the software during the update process, due to the uncertainty of the update timing, it may cause the runtime distributed transaction to call different versions of the target update service, thereby destroying the security of dynamic update, that is, consistent sexual demands.
  • the present invention proposes a microservice dynamic update method that supports transaction consistency.
  • the information is identified, recorded and managed, so that the system can correctly guide the flow of user requests during the update process and ensure the consistency in the dynamic update process.
  • using the recorded distributed transaction information it is determined when the old version of the service can be safely withdrawn.
  • the method not only ensures the consistency in the dynamic update process, but also reduces the disturbance of the update process to the system.
  • the technical solution adopted by the present invention is: a method for dynamically updating microservices that supports transaction consistency, including the following contents:
  • Step 1 go online with the new version: deploy the new version of the target microservice online, and complete the switch between the old and new versions of the target service by modifying the relevant routing rules;
  • Step 2 revoke the old version: initiate a request to revoke the old version, complete the revocation of the old version service instance in time, and complete the dynamic update of the target service;
  • step 1 specifically includes:
  • Step 1-1 deploy a new version of the target microservice online and wait for it to be ready;
  • Step 1-2 add a new version of the routing rule, preferentially forward traffic according to the relevant fields in the header information, and the traffic is forwarded to the old version by default;
  • Steps 1-3 modify the routing rules, forward the traffic to the new version by default, and the rest of the rule entries remain unchanged to complete the service version switching;
  • the above step 2 specifically includes:
  • Step 2-1 initiate a request to revoke the old version, block access to the old version, and ensure that no new user request will call the old version service instance, and the new version service instance will handle the new user request;
  • Step 2-2 synchronizing the distributed transaction identifier set in the old version service instance and the microservice system entry, and identifying the distributed transaction that has not yet ended;
  • Step 2-3 revoke the old version, use the synchronized distributed transaction identifier set to judge, after all the distributed transactions that have called the old version have ended, perform the undo operation on the old version of the service instance;
  • Steps 2-4 revoke the old version of the service instance, clean up and reset the relevant routing rules, and finally complete the dynamic update of the target service;
  • the present invention has the following advantages:
  • the method of the present invention has the advantages of high transparency and strong adaptability. By inserting a traffic proxy, the dynamic update process is kept transparent to the user, and the system can ensure a better user experience. At the same time, this method can be applied to different microservice systems, without requiring developers to write too much non-business logic code.
  • Figure 1 is a schematic diagram of the internal module of the traffic proxy inserted into the entrance of the entire microservice system
  • Figure 2 is a schematic diagram of the internal module of a traffic proxy inserted by a microservice instance
  • FIG. 3 is a flow chart of dynamic update corresponding to the method of the present invention.
  • the traffic proxy Insert a traffic proxy for the user request entry of the entire microservice system and for each microservice.
  • the traffic proxy intercepts and takes over the user request, forwards the request according to the rules, and manages the transaction of the request.
  • the traffic proxy safely guides user requests to the new version, completes the switch between the old and new versions, and then follows the transaction consistency principle. Revoke the old version if the conditions are met to complete the dynamic update of the target service.
  • the inserting a traffic proxy specifically includes:
  • the Proxy module is responsible for taking over all incoming requests and further forwarding the requests to the target service according to the corresponding routing rules. At the same time, when the request occurs, a unique distributed transaction identifier is added to it; when the request ends, the context information of the request is sent to TraceManager;
  • the TraceManager module interacts with the Proxy module to obtain the context information of the request, extracts the corresponding service call chain from the header information of this request, and records the corresponding distributed transaction identifiers respectively to form each service.
  • Each version of corresponds to a set of distributed transaction identifiers, representing the set of distributed transactions that have ended.
  • the Proxy module is responsible for taking over all incoming requests and forwarding them to different target services according to the corresponding routing rules: if the requested target service is the current service, the request is forwarded to its own service instance SvcInstance; otherwise, the request is forwarded to The corresponding target service; at the same time, when the request occurs, the context information of the request is sent to the TraceManager;
  • the TraceManager module interacts with the Proxy module to obtain the context information of the request, extracts the corresponding distributed transaction identifier from the header information of this request, and records it to form a distributed transaction identifier set, indicating that the service has been called.
  • the distributed transaction collection of the instance
  • SvcInstance is a module that actually executes the key business logic of microservices, and is responsible for processing and responding to user requests. And the inserted traffic proxy is transparent to this module, which minimizes the interference to this service instance.
  • the system completes the initial deployment and creates the initial routing rules and version information; or after the system completes a dynamic update, the relevant routing rules have been reset.
  • the service is in Normal state at this time and can be dynamically updated for the target service. The specific steps are:
  • Step 1 go online with the new version: deploy the new version of the target microservice online, and complete the switch between the old and new versions of the target service by modifying the relevant routing rules, including:
  • Step 1-1 Deploy the new version of the target microservice online and wait for it to be ready. If the new version is not ready for deployment, proceed to the subsequent update steps, and the system will return an error;
  • step 1-2 a new version of the routing rule is added, and traffic is forwarded preferentially according to the relevant fields in the header information.
  • the service instance When the service instance completes processing the response request, it will add the corresponding service information and version information to the header information, such as x-version: s-v1, so the subsequent requests of this distributed transaction can use this header information for traffic flow Forward.
  • the current service traffic is forwarded to the old version by default, and no requests have been forwarded to the new version of the service instance;
  • Steps 1-3 modify the routing rules to forward the new traffic to the new version by default, and the rest of the rule entries remain unchanged.
  • a request to the target service s after the new rule takes effect will include the following situations:
  • the distributed transaction T If the distributed transaction T has not called the target service s during the running process, its request header information will not contain the version information related to the target service s. According to our revised routing rules, the distributed transaction T will The request for the target service s will be forwarded to the new version;
  • the request header information must contain the relevant version information, such as x-version: s-v1.
  • the routing rule will preferentially forward the request to the target service s of the same version based on this version information;
  • step 1 the system has completed the switch between the old and new versions of the target service;
  • Step 2 revoke the old version: initiate a request to revoke the old version.
  • the old version of the service instance should be revoked in time, and the dynamic update of the target service should be completed, including:
  • Step 2-1 block access to the old version of the service instance: when receiving the old version revocation request, block all new requests calling the old version of the service instance, that is, the request for which there is no relevant version information in the header information, and the old version has been called. Version service requests are allowed to pass. The blocked request is retry mechanism on the caller side, and the retry request will be forwarded to the new version of the service instance according to the updated routing rules in steps 1-3, ensuring that there will be no new distribution The transaction identifier is recorded and processed by the traffic proxy module of the old version of the service instance;
  • Step 2-2 Synchronization Set:
  • the traffic proxy module of each service instance has a distributed transaction ID set indicating that this instance has been called, and the traffic proxy module of the entire microservice system entrance has a set of IDs that have been identified.
  • a collection of distributed transaction IDs. Use the set L1 saved in all the old version service instances to synchronize with the set L2 saved by the entire microservice system entry, and the obtained difference set D represents all the distributed transaction identifiers that have called the old version service but have not yet returned the result. gather;
  • Step 2-3 use the difference set D to complete the revocation of the old version: Step 2-1 ensures that the L1 set will not continue to increase, and since the running distributed transaction will always end, when the corresponding distributed transaction ends, it will be deleted. The identities are removed from the difference set D. The content of the difference set D will continue to decrease. Finally, when the difference set D becomes an empty set, the target service becomes Free, indicating that there is no distributed transaction that has called the old version of the service instance and has not yet ended. The old version of the service Instances can be safely revoked;
  • Step 2-4 revoke the old version of the service instance, clean and reset the relevant routing rules, delete the relevant entries for traffic forwarding based on the header information, forward all traffic to the new version of the service instance by default, and finally complete the dynamic update,
  • the target service changes to the Normal state again, providing initial conditions for the next dynamic update operation;
  • the present invention proposes a micro-service dynamic update method that supports transaction consistency, so that the micro-service system can still correctly process external requests when updating, while maintaining transparency to users. Since this method considers modifying the content in the request header information, it correctly divides and routes distributed transactions involving service instances of different versions, and satisfies the security aspects of dynamic updates compared to common microservice deployment schemes. requirements. At the same time, the method utilizes the inserted traffic proxy to manage distributed transactions, which effectively achieves a better balance between timeliness and interference.
  • the method provided by the present invention can be applied to different micro-service systems, has a wide range of adaptation, and has high application value.

Landscapes

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

Abstract

本发明公开一种支持事务一致性的微服务动态更新方法，属于软件维护技术领域，包括以下内容：流量代理的插入以及支持事务一致性的动态更新流程；其中通过采用插入流量代理的方式，对用户请求进行接管，拦截并提取出其中的分布式事务信息，添加对应的分布式事务标识，并对其进行管理；支持事务一致性的动态更新流程描述如何从新版本上线到撤销旧版本，对目标服务进行动态更新的同时保证系统的持续可用性。本方法在微服务动态更新方面，相比较于常见的部署方案，在满足一致性要求的同时，在及时性和干扰性两方面取得了较好的平衡，可应用于不同的微服务系统，有较高的应用价值。

Description

一种支持事务一致性的微服务动态更新方法 技术领域
本发明涉及一种支持事务一致性的微服务动态更新方法，属于软件维护技术领域。
背景技术
随着软件系统规模的扩大，系统维护和演化也变得越来越复杂。传统的应用程序将所有功能都打包成一个独立的单元，称为单体应用。单体应用架构简单、部署方便，但不够灵活，无法保证软件应用的快速持续交付，因此微服务架构应运而生。
微服务架构作为一项在云中部署应用和服务的新技术己成为当下最新的热门架构。微服务架构通过将复杂的软件应用划分成若干个更小的服务，每个服务都可以独立地进行部署、升级、扩展和替换。整个系统中的微服务是分布式的，用户通过访问系统暴露的接口得到对应的结果，系统内部实现对用户保持了透明，同时微服务间的低耦合有效地缩短了软件的开发周期，降低了软件维护成本，更加符合当前互联网应用快速迭代、持续交付的需求。
传统的软件更新需要对软件进行停止、更新再启动，但随着用户越来越依赖于系统，传统更新所导致的系统中断会给用户带来很大的不便，引起管理代价的显著提高，比如一些高可靠的服务平台希望为用户提供全天不间断的服务。因此需要在不中断软件正常运行的前提下，对软件系统进行动态更新。动态更新在更新过程中需要对安全性、及时性、低干扰性等多方面进行保证。当前常见的微服务更新部署方案通常采用上线新版本，新旧版本共存并逐渐将用户请求往新版本分流的方法。这些方案尽管都保证了更新过程中软件的可用性，但由于更新时机的不确定性，便有可能导致运行时分布式事务调用到目标更新服务的不同版本，从而破坏动态更新对于安全性，即一致性的要求。
发明内容
本发明的目的是：现有的微服务更新部署方案侧重于新旧版本流量的快速切换，但忽略了更新过程中对于运行时分布式事务的一致性的保证，若某一分布式事务前后调用到新旧版本的服务存在不可兼容性，便会产生错误。本发明针对现有更新方案的不足，针对动态更新过程对于一致性等多方面的要求，提出一种支持事务一致性的微服务动态更新方法，通过插入流量代理的方式，对运行时分布式事务信息进行标识、记录和管理，使得系统可在更新过程中对用户请求进行正确的流量导向，保证动态更新过程中的一致性。同时，利用记录的分布式事务信息，确定何时旧版本服务可以被安全地完成撤销。该方法不仅保证了动态更新过程中的一致性，而且降低了更新过程对系统的干扰性。
为了实现上述目的，本发明所采用的技术方案为：一种支持事务一致性的微服务动态更新方法，包括以下内容：
(1)插入流量代理
(101)为整个微服务系统的入口插入流量代理，一方面将系统的接口对外暴露出来供用户进行访问，对用户请求进行转发；另一方面，拦截所有的用户请求并添加唯一的分布式事务标识，对相关的分布式事务标识进行记录和管理；
(102)为每一个微服务实例插入流量代理，接管请求流量并依据相关的路由规则进行流量的转发，同时对相关的分布式事务标识进行记录和管理。
(2)支持事务一致性的动态更新流程
初始状态下当整个软件系统部署完成，为每个微服务创建初始的路由规则和版本信息；或者系统完成一次动态更新后，相关的路由规则已重置，系统中的服务可正常处理用户请求。当需要对目标微服务进行动态更新时，按如下步骤进行操作：
步骤1，上线新版本：上线部署目标微服务的新版本，通过修改相关的路由规则，完成目标服务新旧版本的切换；
步骤2，撤销旧版本：发起撤销旧版本请求，及时完成旧版本服务实例的撤销，完成目标服务的动态更新；
上述步骤1具体包括：
步骤1-1，上线部署目标微服务的新版本，并等待其就绪；
步骤1-2，添加新版本路由规则，优先依据头信息中的相关字段进行流量的转发，流量默认转发往旧版本；
步骤1-3，修改路由规则，将流量默认转发往新版本，其余规则条目不变，完成服务版本的切换；
上述步骤2具体包括：
步骤2-1，发起撤销旧版本请求，阻塞访问旧版本，保证不会再有新的用户请求调用到旧版本服务实例，由新版本服务实例来处理新的用户请求；
步骤2-2，对旧版本服务实例中与微服务系统入口中的分布式事务标识集合进行同步，标识当前尚未结束的分布式事务；
步骤2-3，撤销旧版本，利用同步后的分布式事务标识集合进行判断，所有调用过旧版本的分布式事务均已结束之后，对旧版本的服务实例执行撤销操作；
步骤2-4，撤销旧版本服务实例，并对相关路由规则进行清理重置，最终完成目标服务的动态更新；
有益效果：与现有技术方案相比，本发明具有以下优点：
(1)在动态更新的过程中，保证了运行时分布式事务的一致性，即不存在同一个分布式事务涉及同一服务的不同版本实例，因此当目标服务的新旧版本存在不可兼容性时，确保了系统的持续可用性；
(2)使用接管流量和拦截请求的方式，利用流量代理来对分布式事务进行记录和管理，然后反映到具体的路由规则上，从而避免对用户请求进行阻塞，降低了因采用动态更新算法对系统造成的干扰性，；
(3)本发明的方法具有透明性高，适应性强的优点，通过插入流量代理的方式，使得动态更新过程对用户保持透明，系统能保证较好的用户体验。同时该方法可应用于不同的微服务系统，无需开发人员编写过多的非业务逻辑代码。
附图说明
图1为整个微服务系统入口插入的流量代理的内部模块示意图；
图2为某一微服务实例插入的流量代理的内部模块示意图；
图3为本发明方法所对应的动态更新流程图。
具体实施方式
下面结合具体实施例，进一步阐明本发明，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围，在阅读了本发明之后，本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。
以下结合附图和具体实施例对本发明作进一步详细说明。
一种支持事务一致性的微服务动态更新方法，其特征在于，包括以下内容：
(1)通过流量代理管理服务请求
为整个微服务系统的用户请求入口和每一个微服务分别插入流量代理。流量代理拦截并接管用户请求，依据规则对请求进行转发并对请求进行事务管理。
(2)支持事务一致性的动态更新流程
支持对系统中的某个微服务进行动态更新，在部署系统中某个微服务的新版本上线时，流量代理将用户请求安全地导向新版本，完成新旧版本的切换，然后根据事务一致性原则在满足条件的情况下撤销旧版本，以完成对目标服务的动态更新。
所述插入流量代理，具体包括：
(1)为整个微服务系统的入口插入流量代理，一方面将系统的接口对外暴露出来供用户进行访问，对用户请求进行转发；另一方面，拦截所有的用户请求并添加跨多个微服务的分布式事务标识，对相关的分布式事务标识进行记录和管理；
(2)为每一个微服务插入流量代理，接管请求流量并依据相关的路由规则进行流量的转发，同时对相关的分布式事务标识进行记录和管理。
对于为整个微服务系统入口插入的流量代理的内部模块如图1所示，具体解释如下：
(1)Proxy模块负责接管所有外来请求，依据相对应的路由规则，将请求进一步地转发往目标服务。同时当请求发生时，为其添加唯一的分布式事务标识；当请求结束时，将请求的上下文信息发送至TraceManager中；
(2)TraceManager模块通过与Proxy模块进行交互，得到请求的上下文信息，从本次请求的头信息中提取出对应的服务调用链，将对应的分布式事务标识，分别记录下来，形成每一服务的每一版本对应于一个分布式事务标识集合，表示已结束的分布式事务集合。
对于为每一个微服务实例的内部模块如图2所示，具体解释如下：
(1)Proxy模块负责接管所有外来请求，依据相对应的路由规则，转发往不同的目标服务：若请求的目标服务为当前服务，则将请求转发往自身的服务实例SvcInstance；否则将请求转发往对应的目标服务；同时当请求发生时，将请求的上下文信息发送至TraceManager中；
(2)TraceManager模块通过与Proxy模块进行交互，得到请求的上下文信息，从本次请求的头信息中提取出对应的分布式事务标识，记录下来形成一个分布式事务标识集合，表示调用过此服务实例的分布式事务集合；
(3)SvcInstance为真正执行微服务关键业务逻辑的模块，负责对用户请求进行处理和响应。并且插入的流量代理对此模块保持透明，较大程度地减轻了对此服务实例的干扰。
在本实施例中，对系统中的某一服务进行动态更新，流程如图3所示，包括以下内容和步骤：
系统完成初始的部署就绪，并创建初始的路由规则和版本信息；或者系统完成一次动态更新后，相关的路由规则已重置。服务此时处于Normal状态，可针对目标服务进行动态更新，具体步骤为：
步骤1，上线新版本：上线部署目标微服务的新版本，通过修改相关的路由规则，完成目标服务新旧版本的切换，具体包括：
步骤1-1，上线部署目标微服务的新版本，并等待其就绪，若新版本部署未就绪则进行后续的更新步骤，系统将返回错误；
步骤1-2，添加新版本路由规则，优先依据头信息中的相关字段进行流量的转发。当服务实例完成处理响应请求时，会在头信息中添加相应的服务信息和版本信息，如x-version：s-v1，因此本次分布式事务的后续请求就可以利用此头信息进行流量的转发。当前服务流量默认转发往旧版本，暂时还无请求被转发往新版本的服务实例；
步骤1-3，修改路由规则，将新流量默认转发往新版本，其余规则条目不变。对于任一分布式事务T，在新规则生效后对目标服务s发起请求，将包括如下几种情况：
①若分布式事务T在运行的过程中还未调用过目标服务s，则其请求头信息中将不包含和目标服务s相关的版本信息，依据我们修改过后的路由规则，分布式事务T对于目标服务s的请求将被转发往新版本；
②若分布式事务T在运行的过程已调用过目标服务s，则其请求头信息中必然包含了相关的版本信息，如x-version：s-v1。此时路由规则将优先依据此版本信息，将请求转发往同一版本的目标服务s；
综上两种情况，都保证了分布式事务T不会调用到目标服务s的不同版本的实例，从而保证了动态更新过程中的一致性。完成步骤1，系统便完成了目标服务新旧版本的切换；
步骤2，撤销旧版本：发起撤销旧版本请求，为了避免旧版本的服务实例长时间地占用系统资源，应及时完成旧版本服务实例的撤销，完成目标服务的动态更新，具体包括：
步骤2-1，阻塞访问旧版本服务实例：当收到旧版本的撤销请求时，阻塞所有调用旧版本服务实例的新请求，即头信息中不存在相关版本信息的请求，而已经调用过旧版本服务的请求则允许通过。被阻塞的请求在调用方侧执行重试机制，重试的请求将依据步骤1-3中更新后的路由规则，进而被转发到新版本的服务实例中，保证了不会再有新的分布式事务标识被旧版本服务实例的流量代理模块记录处理；
步骤2-2，同步集合：由前述可知，每个服务实例的流量代理模块都存在表示已调用过此实例的分布式事务标识集合，整个微服务系统入口的流量代理模块则存在标识已完成的分布式事务标识集合。利用所有旧版本服务实例中保存的集合L1，与整个微服务系统入口所保存的集合L2进行同步，得到的差集D，便代表所有调用过旧版本服务但还未返回结果的分布式事务标识集合；
步骤2-3，利用差集D完成旧版本的撤销：步骤2-1保证了L1集合不会继续增加，同时由于运行的分布式事务总会结束，因此当对应分布式事务结束时，将其标识从差集D中删除。差集D的内容将会不断减少，最终当差集D变为空集时，目标服务变为Free状态，表示不存在已调用过旧版本服务实例且还未结束的分布式事务，旧版本的服务实例可被安全地撤销；
步骤2-4，撤销旧版本服务实例，并对相关路由规则进行清理重置，删去依据头信息进行流量转发的相关条目，将所有流量默认转发往新版本的服务实例，最终完成动态更新，目标服务重新变为Normal状态，为下一次的动态更新操作提供初始条件；
本发明针对动态更新过程对于一致性等多方面的要求，提出支持事务一致性的微服务动态更新方法，使得微服务系统在进行更新时仍然能够正确地处理外来请求，同时对用户保持 透明。由于本方法考虑对请求头信息中的内容进行修改，正确地将涉及不同版本服务实例的分布式事务进行划分和路由导向，相比较于常见的微服务部署方案，满足了动态更新在安全性方面的要求。同时，本方法利用插入的流量代理对分布式事务进行管理，有效的在及时性和干扰性两方面取得了较好的平衡。使用本发明提供的方法可应用于不同的微服务系统中，适应范围广，具有较高的应用价值。

Claims (5)

  1. 一种支持事务一致性的微服务动态更新方法，其特征在于，包括以下内容：
    (1)通过流量代理管理服务请求
    为整个微服务系统的用户请求入口和每一个微服务分别插入流量代理，流量代理拦截并接管用户请求，依据规则对请求进行转发并对请求进行事务管理；
    (2)支持事务一致性的动态更新流程
    支持对系统中的某个微服务进行动态更新，在部署系统中某个微服务的新版本上线时，流量代理将用户请求安全地导向新版本，完成新旧版本的切换，然后根据事务一致性原则在满足条件的情况下撤销旧版本，以完成对目标服务的动态更新。
  2. 根据权利要求1所述的支持事务一致性的微服务动态更新方法，其特征在于，所述插入流量代理，具体包括：
    (1)为整个微服务系统的入口插入流量代理，一方面将系统的接口对外暴露出来供用户进行访问，对用户请求进行转发；另一方面，拦截所有的用户请求并添加跨多个微服务的分布式事务标识，对相关的分布式事务标识进行记录和管理；
    (2)为每一个微服务插入流量代理，接管请求流量并依据相关的路由规则进行流量的转发，同时对相关的分布式事务标识进行记录和管理。
  3. 根据权利要求1所述的支持事务一致性的微服务动态更新方法，其特征在于，所述支持事务一致性的动态更新流程包括：
    步骤1，上线新版本：上线部署目标微服务的新版本，通过修改相关的路由规则，保证事务一致性，完成目标服务新旧版本的切换；
    步骤2，撤销旧版本：发起撤销旧版本请求，及时完成旧版本服务实例的撤销，完成目标服务的动态更新；
  4. 根据权利要求3所述的支持事务一致性的微服务动态更新方法，其特征在于，所述上线新版本的流程包括：
    步骤1.1，上线部署目标微服务的新版本，并等待其就绪，若新版本部署未就绪则进行后续的更新步骤，系统将返回错误；
    步骤1.2，添加新版本路由规则，优先依据头信息中的相关字段进行流量的转发；当服务实例完成处理响应请求时，会在头信息中添加相应的服务信息和版本信息，因此本次分布式事务的后续请求能够利用此头信息进行流量的转发；当前服务流量默认转发往旧版本，暂时还无请求被转发往新版本的服务实例；所述服务信息和版本信息为：x-version和s-v1；
    步骤1.3，修改路由规则，将新流量默认转发往新版本，其余规则条目不变；对于任一分布式事务T，在新规则生效后对目标服务s发起请求，将包括如下几种情况：
    ①若分布式事务T在运行的过程中还未调用过目标服务s，则其请求头信息中将不包含和目标服务s相关的版本信息，依据我们修改过后的路由规则，分布式事务T对于目标服务s的请求将被转发往新版本；
    ②若分布式事务T在运行的过程已调用过目标服务s，则其请求头信息中必然包含了相关的版本信息，此时路由规则将优先依据此版本信息，将请求转发往同一版本的目标服务s。
  5. 根据权利要求3所述的支持事务一致性的微服务动态更新方法，其特征在于，所述撤销旧版本的流程包括：
    步骤2.1，阻塞访问旧版本服务实例：当收到旧版本的撤销请求时，阻塞所有调用旧版本服务实例的新请求，即头信息中不存在相关版本信息的请求，而已经调用过旧版本服务的请求则允许通过；被阻塞的请求在调用方侧执行重试机制，重试的请求将依据更新后的路由规则，进而被转发到新版本的服务实例中，保证了不会再有新的分布式事务标识被旧版本服务实例的流量代理模块记录处理；
    步骤2.2，同步集合：由前述可知，每个服务的流量代理模块都存在表示已调用过此实例的分布式事务标识集合，整个微服务系统入口的流量代理模块则存在标识已完成的分布式事务标识集合；利用所有旧版本服务实例中保存的集合L1，与整个微服务系统入口所保存的集合L2进行同步，得到的差集D，便代表所有调用过旧版本服务但还未返回结果的分布式事务标识集合；
    步骤2.3，利用差集D完成旧版本的撤销：步骤1保证了L1集合不会继续增加，同时由于运行的分布式事务总会结束，因此当对应分布式事务结束时，将其标识从差集D中删除；差集D的内容将会不断减少，最终当差集D变为空集时，目标服务变为Free状态，表示不存在已调用过旧版本服务实例且还未结束的分布式事务，旧版本的服务实例可被安全地撤销；
    步骤2.4，撤销旧版本服务实例，并对相关路由规则进行清理重置，删去依据头信息进行流量转发的相关条目，将所有流量默认转发往新版本的服务实例，最终完成动态更新，目标服务重新变为Normal状态，为下一次的动态更新操作提供初始条件。
PCT/CN2021/082368 2021-03-11 2021-03-23 一种支持事务一致性的微服务动态更新方法 Ceased WO2022188205A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110263875.0 2021-03-11
CN202110263875.0A CN113055465B (zh) 2021-03-11 2021-03-11 一种支持事务一致性的微服务动态更新方法

Publications (1)

Publication Number Publication Date
WO2022188205A1 true WO2022188205A1 (zh) 2022-09-15

Family

ID=76511516

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/082368 Ceased WO2022188205A1 (zh) 2021-03-11 2021-03-23 一种支持事务一致性的微服务动态更新方法

Country Status (2)

Country Link
CN (1) CN113055465B (zh)
WO (1) WO2022188205A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116302369A (zh) * 2023-03-20 2023-06-23 兴业银行股份有限公司 微服务流水信息对齐方法、装置、计算机设备和存储介质
CN119135776A (zh) * 2024-08-23 2024-12-13 中国科学院软件研究所 一种基于rest api执行链的微服务应用执行时延优化方法
CN119254840A (zh) * 2024-12-04 2025-01-03 天翼云科技有限公司 微服务应用访问方法、装置、计算机设备、介质和产品

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113641400A (zh) * 2021-08-10 2021-11-12 广州鲁邦通智能科技有限公司 一种多版本服务共用微服务公共资源的方法、api网关和管理系统
CN115237443A (zh) * 2022-07-18 2022-10-25 中国科学院深圳先进技术研究院 一种一致性微服务在线更新方法及装置
CN115904408A (zh) * 2022-11-11 2023-04-04 南京大学 一种基于时间窗口划分的微服务版本安全撤销系统和方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108268271A (zh) * 2016-12-29 2018-07-10 华为技术服务有限公司 微服务的升级方法与升级装置
CN110716815A (zh) * 2019-10-11 2020-01-21 集奥聚合(北京)人工智能科技有限公司 基于Spring Gateway的微服务各版本定向调用方法
CN111580846A (zh) * 2020-05-15 2020-08-25 厦门靠谱云股份有限公司 一种基于混合框架的微服务灰度发布方法
WO2020251828A1 (en) * 2019-06-12 2020-12-17 Cisco Technology, Inc. Systems and methods providing a multi-cloud microservices gateway using a sidecar proxy
CN112333096A (zh) * 2020-10-16 2021-02-05 济南浪潮数据技术有限公司 一种微服务流量调度方法及相关组件

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101963913B (zh) * 2010-11-04 2013-03-27 南京大学 一种基于事务的构件在线演化方法
CN103500084B (zh) * 2013-07-11 2017-03-29 南京大学 一种支持软件动态更新的服务构件架构方法
US10348838B2 (en) * 2016-07-22 2019-07-09 Cisco Technology, Inc. Scaling service discovery in a micro-service environment
CN106874130A (zh) * 2017-02-06 2017-06-20 西多多信息科技(北京)有限公司 一种微服务架构中分布式事务的处理方法
CN109408096A (zh) * 2018-12-05 2019-03-01 国云科技股份有限公司 一种分布式应用热更新的方法
CN109981789B (zh) * 2019-04-03 2021-09-07 浪潮云信息技术股份公司 一种基于代理模式的微服务引擎
CN110401696B (zh) * 2019-06-18 2020-11-06 华为技术有限公司 一种去中心化处理的方法、通信代理、主机以及存储介质
CN111930758A (zh) * 2020-07-14 2020-11-13 广西东信互联科技有限公司 一种基于Paxos算法的微服务配置数据实时更新方法
CN112181458B (zh) * 2020-09-25 2024-10-25 中国建设银行股份有限公司 灰度规则的配置、灰度路由方法、装置、设备及存储介质
CN112363954B (zh) * 2020-12-08 2021-07-30 南京大学 基于对象状态一致性的软件动态更新测试方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108268271A (zh) * 2016-12-29 2018-07-10 华为技术服务有限公司 微服务的升级方法与升级装置
WO2020251828A1 (en) * 2019-06-12 2020-12-17 Cisco Technology, Inc. Systems and methods providing a multi-cloud microservices gateway using a sidecar proxy
CN110716815A (zh) * 2019-10-11 2020-01-21 集奥聚合(北京)人工智能科技有限公司 基于Spring Gateway的微服务各版本定向调用方法
CN111580846A (zh) * 2020-05-15 2020-08-25 厦门靠谱云股份有限公司 一种基于混合框架的微服务灰度发布方法
CN112333096A (zh) * 2020-10-16 2021-02-05 济南浪潮数据技术有限公司 一种微服务流量调度方法及相关组件

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116302369A (zh) * 2023-03-20 2023-06-23 兴业银行股份有限公司 微服务流水信息对齐方法、装置、计算机设备和存储介质
CN119135776A (zh) * 2024-08-23 2024-12-13 中国科学院软件研究所 一种基于rest api执行链的微服务应用执行时延优化方法
CN119254840A (zh) * 2024-12-04 2025-01-03 天翼云科技有限公司 微服务应用访问方法、装置、计算机设备、介质和产品

Also Published As

Publication number Publication date
CN113055465A (zh) 2021-06-29
CN113055465B (zh) 2022-04-22

Similar Documents

Publication Publication Date Title
WO2022188205A1 (zh) 一种支持事务一致性的微服务动态更新方法
US20230106118A1 (en) Distributed processing of transactions in a network using timestamps
CN111597015B (zh) 事务处理方法、装置、计算机设备及存储介质
US11726984B2 (en) Data redistribution method and apparatus, and database cluster
CN113419823B (zh) 一种适用于高并发事务的联盟链系统及其设计方法
WO2020134115A1 (zh) 一种数据存储方法、装置、设备及存储介质
US20090037422A1 (en) Combining capture and apply in a distributed information sharing system
US7636868B2 (en) Data replication in a distributed system
CN102098342A (zh) 一种基于事务级的数据同步方法、装置及系统
CN108182121B (zh) 一种Android中控大屏系统模块间通信方法及系统
CN116303346B (zh) 数据库迁移方法以及系统
CN110727550B (zh) 数据复制处理方法、装置、容灾系统、设备及存储介质
US20130006930A1 (en) Transference control method, transference control apparatus and recording medium of transference control program
CN107483631A (zh) 一种采用配置文件控制缓存实现移动互联网络服务访问的系统及方法
CN112698792A (zh) 分布式存储系统的数据迁移方法、装置及电子设备
WO2021109777A1 (zh) 一种数据文件的导入方法及装置
CN114756357A (zh) 一种基于jvm的非阻塞分布式计划任务调度方法
CN114490570A (zh) 生产数据同步方法、装置、数据同步系统及服务器
CN106294033A (zh) 一种多机房缓存同步功能的测试方法及装置
CN115495436A (zh) 数据库升级方法及装置
CN108390919A (zh) 一种用于高可靠双机热备的消息同步系统及方法
CN112966047B (zh) 一种基于分布式数据库的复制表功能实现方法
EP0655182B1 (en) Centralized command system for a telecommunications network
CN119322678A (zh) 一种面向一体化硬件对等部署的集群配置同步系统及方法
CN111897839A (zh) 一种数据处理方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21929677

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21929677

Country of ref document: EP

Kind code of ref document: A1