CN114840222A - Gray scale publishing method based on ESOP system and related equipment - Google Patents

Gray scale publishing method based on ESOP system and related equipment Download PDF

Info

Publication number
CN114840222A
CN114840222A CN202210447442.5A CN202210447442A CN114840222A CN 114840222 A CN114840222 A CN 114840222A CN 202210447442 A CN202210447442 A CN 202210447442A CN 114840222 A CN114840222 A CN 114840222A
Authority
CN
China
Prior art keywords
service request
gray
field
mark
unit
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
CN202210447442.5A
Other languages
Chinese (zh)
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.)
Shenzhen Futu Network Technology Co Ltd
Original Assignee
Shenzhen Futu 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 Shenzhen Futu Network Technology Co Ltd filed Critical Shenzhen Futu Network Technology Co Ltd
Priority to CN202210447442.5A priority Critical patent/CN114840222A/en
Publication of CN114840222A publication Critical patent/CN114840222A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45562Creating, deleting, cloning virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/4557Distribution of virtual machine instances; Migration and load balancing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45587Isolation or security of virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45595Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The application discloses a gray scale publishing method based on an ESOP system and related equipment, wherein the method comprises the following steps: acquiring a service request, wherein the service request comprises a mark field, the mark field corresponds to the gray release requirement of a tenant, and comprises a gray field or a formal field which indicates whether the current service request needs to be forwarded to a gray environment or not; forwarding the service request to a unit cluster corresponding to the mark field through a preset forwarding rule, wherein the unit cluster is used for collecting the service request, and the unit clusters corresponding to different mark fields are mutually independent; and receiving an execution result returned after the service layer of the unit cluster executes the service request. According to the method and the device, the service request is forwarded to the corresponding unit cluster through the mark field which is contained in the service request and corresponds to the gray level release requirement, so that independent gray level release or formal release is realized by taking the tenant as a basic level, the association among tenant services is reduced, and the disaster tolerance capability of the system is improved.

Description

Gray scale publishing method based on ESOP system and related equipment
Technical Field
The application relates to the technical field of computers, in particular to a gray scale publishing method based on an ESOP system and related equipment.
Background
The existing mode of issuing new functions needs to be fully issued and effective when the issuing relates to the simultaneous transformation of the foreground and the background of the system, namely, the full issuing is carried out after the testing and the pre-issuing environment are confirmed. If a BUG is introduced to release a new function, the BUG will affect all tenants, which results in an expanded BUG affecting range, and after some tenants' services which may cause the system service performance to be reduced are completed, the BUG will adversely affect the services of other tenants, thereby affecting the overall performance of the system.
Disclosure of Invention
In order to solve the above technical problem, embodiments of the present application provide a gray scale publishing method and apparatus based on an ESOP system, an electronic device, and a computer-readable storage medium.
According to an aspect of an embodiment of the present application, there is provided a gray scale issuing method based on an ESOP system, including: acquiring a service request, wherein the service request comprises a mark field, the mark field corresponds to the gray release requirement of a tenant, and comprises a gray field or a formal field which indicates whether the current service request needs to be forwarded to a gray environment; forwarding the service request to a unit cluster corresponding to the mark field through a preset forwarding rule, wherein the unit cluster is used for collecting the service request, and the unit clusters corresponding to different mark fields are mutually independent; and receiving an execution result returned after the service layer of the unit cluster executes the service request.
In another exemplary embodiment, the method further comprises: the method comprises the steps that unit clusters are deployed in advance in an ESOP system, wherein the unit clusters comprise gray level unit clusters and formal unit clusters, physical resource isolation is carried out on the gray level unit clusters and the formal unit clusters through an intermediate program, and the intermediate program comprises middleware or external services.
In another exemplary embodiment, the forwarding the service request to the unit cluster corresponding to the tag field by a preset forwarding rule includes: adding a flow mark corresponding to a mark field into the service request; and forwarding the service request to the corresponding unit cluster which is deployed in advance through the flow mark and the forwarding rule.
In another exemplary embodiment, the forwarding the service request to the unit cluster corresponding to the tag field by a preset forwarding rule includes: if the traffic label included in the service request is a gray level traffic label, forwarding the service request to the gray level cell cluster; and if the traffic mark contained in the service request is a formal traffic mark, forwarding the service request to the formal unit cluster.
In another exemplary embodiment, the service request further includes a configuration file, and before receiving an execution result returned after the service layer of the cell cluster executes the service request, the method further includes: and routing the service request to a service layer in the unit cluster through the service identifier and the tenant identifier contained in the configuration file.
In another exemplary embodiment, the service request includes the tag field corresponding to the gray scale issue requirement in a middle instruction issued by a tenant; if the gray release requirement is a gray requirement, the mark field is a gray field; and if the gray release requirement is a non-gray requirement, the mark field is a formal field.
In another exemplary embodiment, the service layer in the grayscale cell cluster is deployed using a containerization deployment strategy.
According to an aspect of an embodiment of the present application, there is provided a gray scale issuing apparatus based on an ESOP system, including: the receiving module is used for acquiring a service request, wherein the service request comprises a mark field, the mark field corresponds to the gray release requirement of a tenant, and comprises a gray field or a formal field which indicates whether the current service request needs to be forwarded to a gray environment or not; the distribution module is used for forwarding the service request to the unit cluster corresponding to the mark field through a preset forwarding rule, wherein the unit cluster is used for collecting the service request, and the unit clusters corresponding to different mark fields are mutually independent; and the issuing module is used for receiving an execution result returned after the service layer of the unit cluster executes the service request.
According to an aspect of an embodiment of the present application, an electronic device includes: one or more processors; a storage device for storing one or more programs, which when executed by the one or more processors, cause the electronic device to implement the gray scale publishing method based on the ESOP system.
According to an aspect of embodiments of the present application, a computer-readable storage medium has stored thereon computer-readable instructions, which, when executed by a processor of a computer, cause the computer to execute the gray scale distribution method based on an ESOP system.
In the technical scheme provided by the embodiment of the application, the service request is forwarded to the unit cluster corresponding to the mark field through the mark field which is contained in the service request and corresponds to the gray release requirement of the tenant, so that the gray release or formal release is supported according to the tenant as the basic level, the unit clusters are mutually independent, the mutual independence can reduce the association between the tenants, the resource isolation is realized, and the disaster tolerance capability of the applied ESOP system and the overall performance of the system are improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:
FIG. 1 is a schematic illustration of an implementation environment to which the present application relates;
fig. 2 is a schematic structural diagram of a tenant terminal and an ESOP system in an exemplary embodiment in an implementation environment of the embodiment shown in fig. 1;
FIG. 3 is a flow chart illustrating a gray scale publishing method in accordance with an exemplary embodiment of the present application;
FIG. 4 is a schematic diagram of a service architecture of an analog front end employed by the embodiment of FIG. 3 in an exemplary embodiment;
FIG. 5 is a flow chart illustrating a gray scale publishing method in accordance with an exemplary embodiment of the present application;
FIG. 6 is a flow chart of step S200 in the embodiment shown in FIG. 3 in an exemplary embodiment;
FIG. 7 is a schematic diagram of a service architecture of an analog backend applied by the embodiment shown in FIG. 3 in an exemplary embodiment;
FIG. 8 is a flow chart of step S200 in the embodiment shown in FIG. 3 in an exemplary embodiment;
FIG. 9 is a back end script logic diagram illustrating a gray scale publishing method in accordance with an exemplary embodiment of the present application;
fig. 10 is a block diagram illustrating a gradation issuance apparatus according to an exemplary embodiment of the present application;
FIG. 11 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
Reference to "a plurality" in this application means two or more. "and/or" describe the association relationship of the associated objects, meaning that there may be three relationships, e.g., A and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
In the related art, the ESOP (employee shareheestockownship plan) is a new type of stock right form, which means that a company grants stocks or stock rights of the company to the company operators (high management, core employees, etc.), so that the company owners can obtain rights and interests for sharing company profits and participating in company operation decisions. Compared with the stock right incentive system which takes the stock of the company as a mark and carries out long-term incentive on the employees of the company, ESOP is an organization form that the employees of the company pay for subscription of the stock right or the stock and then entrust the company to carry out unified management, and the related aspects are wide and relatively loose in the system. ESOP also has the following advantages: the staff has the double identities of the laborers and the stockholders, so that the staff interests and the company interests are unified; the enterprise stock structure is facilitated to be optimized; the method can be effectively applied to enterprise financing and expansion; providing an internal trading market for stocks of non-public holding companies, etc.
The gray release refers to a release mode capable of smoothly transitioning between black and white, and the flow of the gray release can include the flows of defining a target, selecting a strategy, screening users, deploying a system, releasing a summary, perfecting a product and the like. The selected strategies comprise user scale, release frequency, function coverage, rollback strategies, operation strategies, new and old system deployment strategies and the like; screening users comprises screening user characteristics, user quantity, user common functions, user range and the like; the deployment system comprises a new deployment system, a user behavior analysis system (webaytics) deployment, distribution rule setting, operation data analysis, distribution rule fine adjustment and the like; the publishing summary includes publishing user behavioral analysis reports, user questionnaires, socialized media opinion collections, forming product functionality improvement lists, and the like.
The A/B test can be carried out on the system for releasing new functions of the system, namely, tenants of a part of the system continue to use the product characteristics A, and tenants of a part of the system start to use the product characteristics B.
Through the gray scale distribution, the problem can be found and adjusted in the initial gray scale so as to ensure that the influence degree of the problem is not further expanded. Therefore, certain release risk is avoided, the range influenced by iterative upgrade of products is reduced, feedback opinions of users are quickly obtained, product functions are perfected, product quality is improved, and inconvenience brought to the users due to stop releasing is avoided.
However, in the existing method of issuing new functions through gray-scale distribution, all the distributions need to be effective when the foreground and the background of the system are simultaneously modified, that is, the full distribution is performed after the test and the pre-distribution environment are confirmed. If a BUG is introduced to release a new function, the BUG will affect all tenants, resulting in an expanded BUG impact range, and after some tenants' services that may cause a reduction in system service performance are completed, the BUG will also adversely affect the services of other tenants, thereby affecting the overall performance of the system.
In order to solve the above problem, embodiments of the present application propose a gray scale distribution method, apparatus, electronic device and storage medium based on an ESOP system, and the embodiments will be described in detail below.
Referring first to fig. 1, fig. 1 is a schematic diagram of an implementation environment related to the present application. The implementation environment includes a terminal 10 and a server 20, and communication between the terminal 10 and the server 20 is performed through a wired or wireless network. After receiving the service request sent by the terminal 10, the server 20 distributes traffic according to the mark field corresponding to the gray scale publishing requirement included in the service request, forwards the service request to the unit cluster corresponding to the mark field for gray scale publishing or formal publishing, obtains a returned execution result, and transmits the obtained execution result to the terminal 10 for displaying.
Referring to fig. 2, fig. 2 is a schematic structural diagram of a tenant terminal and an ESOP system applied in the gray scale publishing method in an exemplary embodiment in the implementation environment shown in fig. 1, where the ESOP system is deployed with an analog front end and an analog back end and a unified access layer connecting the analog front end and the analog back end. The tenant terminal sends a service request to an ESOP system, the simulation front end acquires the service request, the service contained in the simulation front end distributes the service request through the mark field contained in the service request, after the service request is distributed to the unified access layer, the service requests of different mark fields are forwarded to a unit cluster corresponding to the mark field in the simulation rear end according to forwarding rules in the unified access layer, the service request is executed in the simulation rear end for gray release or formal release to obtain an execution result, and finally the obtained execution result is transmitted to the tenant terminal for display.
Compared with the gray level release scheme in the prior art, the gray level release method provided by the implementation environment can realize gray level release by taking the tenant as a basic level, reduce the association between tenant services, and improve the disaster tolerance capability of the applied ESOP system and the overall performance of the system.
It should be noted that the terminal 10 in the implementation environment shown in fig. 1 may be any electronic device such as a smart phone, a tablet, a notebook, a computer, etc.; the server 20 may be an independent server, or may be a cloud server that provides basic cloud computing services such as cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, content distribution network (CdN), big data, and artificial intelligence platform, which is not limited herein.
Fig. 3 is a flowchart illustrating a gray scale issuing method based on an ESOP system according to an exemplary embodiment of the present application. The method may be applied to the implementation environment shown in fig. 1 and is specifically performed by the server 20 in the embodiment environment shown in fig. 1. In other embodiments, the method may be performed by a device in other embodiments, and the embodiment is not limited thereto.
As shown in fig. 3, in an exemplary embodiment, the gray scale distribution method may include steps S100 to S300, which are described in detail as follows:
step S100, a service request is obtained, wherein the service request comprises a mark field, the mark field corresponds to the gray release requirement of the tenant, and the mark field comprises a gray field or a formal field and indicates whether the current request needs to be forwarded to a gray environment.
When the tenants have the release requirements of gray release or formal release, service requests are generated and sent, the gray release requirements of the tenants are acquired before the service requests are sent, different mark fields contained in different service requests are acquired according to different gray release requirements of each tenant, and the acquired mark fields can be pre-added in fields or other forms and stored in session (time domain) objects of the service requests. When the tenant generates the service request, the service request carries tenant information containing a session object. The session object is generally used for storing user information, has the characteristic that data is not easy to lose, and can maintain the user information on a server for being accessed from a page on any equipment at any time.
For example, in this embodiment, the tenant may include a company registered in the ESOP system, and there are two kinds of ESOP users below the tenant, that is, an administrator user and an employee user, where corresponding identifiers of the users on the ESOP system have uniqueness. When a user requests to log in, the ESOP system can set whether the user needs to have gray scale according to the gray scale setting field of the tenant to which the user belongs, and the setting information is stored in session.
And step S200, forwarding the service request to the unit cluster corresponding to the mark field through a preset forwarding rule.
In this embodiment, after receiving a service request sent by a tenant terminal, the ESOP system may obtain tenant information in the service request, extract a session object included in the tenant information, and further query the session object to obtain a tag field corresponding to the service request. And when the value of the mark field contained in the service request is confirmed to be the needed gray level, forwarding the service request containing the gray level field to the unit cluster corresponding to the mark field according to a forwarding rule preset by an ESOP system.
It should be noted that the unit clusters corresponding to different mark fields are independent from each other, that is, the unit cluster corresponding to the gray field and the unit cluster corresponding to the official field are independent from each other, so that the association between tenants can be reduced, and the influence between service requests of different tenants can be avoided when the service requests of different tenants are executed, thereby realizing resource isolation between the unit clusters and between the tenants.
Step S300, receiving the execution result returned by the service layer of the unit cluster after executing the service request.
In this embodiment, the unit cluster of the ESOP system is separately deployed with a service layer, and the service layer is packaged with a plurality of services for executing service requests. And after receiving the forwarded service request, the unit cluster routes the service request to a service layer for execution, if the service request corresponds to the gray field, the service layer of the unit cluster executes the database change, and after the execution of the service request is completed, a corresponding execution result is obtained and returned to the tenant terminal. The unit clusters correspond to the mark fields and the unit clusters corresponding to different mark fields are independent of each other, so that each unit cluster only processes data of tenants containing corresponding mark fields, namely, a service request containing a gray mark only upgrades a corresponding tenant database and a public database when executed in the corresponding unit cluster, and a service request containing a formal mark also upgrades a non-gray tenant database when executed in the corresponding unit cluster.
As can be seen from the above, in the gray scale publishing method based on the ESOP system provided in this embodiment, after receiving a service request, tenant information in the service request is obtained, a session object included in the tenant information is extracted, and the session object is further queried to obtain a tag field corresponding to the service request, and the service request is forwarded to a unit cluster corresponding to the tag field according to the tag field, so that gray scale publishing or formal publishing is supported on the basis of the tenant, and the unit clusters are independent of each other, which can reduce the association between tenants, and can avoid the influence between service requests when the ESOP system executes service requests of different tenants, thereby realizing resource isolation between the unit clusters and between the tenants, and thus improving the disaster tolerance capability of the applied ESOP system and the overall performance of the system.
Referring to fig. 4, fig. 4 is a schematic diagram of a service architecture of an analog front end of an ESOP system in a structural schematic diagram of a tenant terminal and the ESOP system applied to the gray scale publishing method shown in fig. 2 in an exemplary embodiment.
In this embodiment, for example, a service framework of a pre-deployed analog front end in an ESOP system is deployed by using k8s, and a grayscale container and a formal container corresponding to a grayscale release requirement are deployed. k8s is called kubernets completely, is an open-source container cluster management system, can realize the functions of automatic deployment, automatic expansion and contraction, maintenance and the like of a container cluster, and has the characteristics of mobility (public cloud, private cloud, mixed cloud, polymorphic cloud), expandability (modularization, plug-in, mounting and combination), self-repairing (automatic deployment, automatic restart, automatic copy, automatic expansion and the like). Since kubernets has an initial k, 8 characters in total between the initial and the last letter, and the last letter is s, it is often abbreviated as k8 s.
In this embodiment, the analog front end includes a php and a node technology stack, and performs traffic distribution on the service request after the ESOP system receives the service request. Firstly, flow distribution is carried out through the nginx access layer of the php, the flow distribution is realized by a reverse proxy at the code level after the flow is transmitted to the node access layer, and the flow is distributed to a gray level container or a formal container according to the mark field.
The technology stack is an IT term, and a general term of a series of skill combinations required to be mastered for a certain job or a certain position generally refers to combining N technologies with each other (N > 1) as an organic whole to achieve a certain purpose or function, and may also refer to mastering the technologies and experience of cooperating with the technologies, and the functions of the technology stack in the present application include, but are not limited to, traffic distribution functions mentioned in the application contents. Wherein php (Hypertextpreprocessor, Chinese name: hypertext preprocessor) is a universal open source script language, php technology stack is a technology stack constructed by the universal open source script language; in addition, the node technology stack is a technology stack constructed by node.
It should be noted that, in order to provide no access to the outside, the nginx access layer of the php technology stack is not deployed in gray scale and formal as shown in fig. 4, so that the service request including the formal field is prevented from being allocated to the gray scale container. The node access layer is deployed with a gray node and a formal node, and corresponds to a gray container and a formal container, that is, the gray node of the node access layer corresponds to the gray container, the formal container corresponds to the formal node in the node access layer, the formal node transparently transmits a service request including the gray field to the gray node by inquiring a mark field included in the service request, retains the service request including the formal field in the formal node, and distributes the service request to the gray container or the formal container according to the mark field.
In the service architecture of the analog front end provided in this embodiment, after the analog front end acquires a service request sent by a tenant terminal, a tag field may be obtained by pulling a company list of the tenant terminal that sends the service request, if the tag field of the tenant acquired from the list is a gray tag, the gray tag is written in a small text file (cookie) of the service request, traffic distribution of the service request is completed at a nginx access layer and a node access layer according to the tag field and the cookie, a cmld-id of a CMLB route is changed according to env injected by a gray container and a formal container, and then the service request is forwarded to the analog back end through a unified access layer connected to the back end and the CMLB route. Where env commands are used to display the environment variables already present in the system and to execute instructions in a defined environment, CMLB routing is a service gateway.
Referring to fig. 5, fig. 5 is a schematic flowchart illustrating a service architecture of the analog front end shown in fig. 4, in an exemplary embodiment, after receiving a service request including a gray scale flag, a gray scale publishing method based on an ESOP system according to the present application is implemented, as shown in fig. 5, including steps S501 to S506:
in step S501, the tenant terminal sends a service request to the nginx access layer.
In step S502, the nginx access layer transparently transmits the service request to the regular node of the node access layer.
In step S503, the formal node queries the service request, and obtains the gray label included in the service request.
In step S504, the service request is transmitted to the grayscale node according to the grayscale flag.
In step S505, the grayscale node forwards the service request to the service layer of the corresponding cell cluster, and executes the service request.
In step S506, the execution result obtained by executing the service request is transmitted back to the Web server through each service in the front end in sequence, and the page data is generated by combining the static resource and the execution result to be returned and displayed, so that data flow rollback is realized, the stability of the production environment is ensured, and the release accident is reduced.
In the above embodiment, the provided analog front end deploys the service architecture by using k8s, and k8s can implement functions of automated deployment, automatic scaling, maintenance, and the like of the container cluster, and has the following characteristics: fault migration, when a certain node is shut down or hung up, services on the node can be automatically transferred to another node, and all services are not interrupted in the process; resource scheduling, when cpu and memory on a node are not enough, the node can be extended, and a newly-built pod (the smallest deployable computing unit managed by the creation in k8 s) is scheduled to the newly-extended node; the method comprises the following steps of isolating resources, creating three namespaces of development, operation and maintenance and testing, and switching contexts, wherein developers can only see all the pod of the developed namespaces and cannot see the pod of the operation and maintenance namespaces, so that influence is avoided and mutual interference is avoided; docker containers are adopted, and processes are not affected mutually. Therefore, isolation of the tenants and the service resources of the tenants in the embodiment can be better realized, association among the tenants is reduced, no influence is caused, and mutual interference is avoided.
In an exemplary embodiment of the present application, a mark field included in a service request sent by a tenant terminal corresponds to a gray scale issue requirement in a middle station instruction sent by the tenant, a function of setting a gray scale switch is provided on a tenant management page of the middle station of the tenant terminal, the tenant sends the middle station instruction through the function of the middle station, and the middle station instruction includes the gray scale issue requirement. If the gray release requirement is a gray requirement, the mark field of the service request is a gray field, if the gray release requirement is a non-gray requirement, the mark field of the service request is a formal field, and when an administrator or a tenant logs in, the mark field set before again is stored in a session object of the tenant, and the preparation is made for sending the service request for the purpose that the subsequent tenant needs to release the function.
Referring to fig. 6, fig. 6 is a flowchart of step S200 in the embodiment shown in fig. 3 in an exemplary embodiment. As shown in fig. 6, step S200 may specifically include steps S201 to S202, and the service request is forwarded to the unit cluster corresponding to the tag field through the above steps, which are described in detail as follows:
step S201, add the traffic tag corresponding to the tag field to the service request.
The added traffic flag is used for traffic forwarding of the service request, and is applicable to the traffic forwarding rule in step S202, if the flag field is a gray field, the gray traffic flag is added to the service request, if the flag field is a formal field, the formal traffic flag is added to the service request, and the traffic flag added to the service request is used for subsequent traffic forwarding at the unified access layer. For example, after the traffic flag is increased by applying the grayscale issuing method based on the ESOP system provided in this embodiment, the service request including the grayscale field will carry a specific httprod (x-sufficient-client-grayscale flag ═ 1) as the traffic flag, the service request including the formal field will also carry a specific httprod, the unified access layer will determine whether the service request is a service request requiring grayscale issuing or a service request not requiring grayscale issuing according to the httprod, and then forward the service request according to the determination result.
Step S202, the service request is forwarded to the corresponding unit cluster which is deployed in advance through the flow mark and the forwarding rule.
In this embodiment, before the service request is obtained, a cell cluster is pre-deployed in the ESOP system, where the grayscale cell cluster and the formal cell cluster are physically isolated by an intermediate program, and the intermediate program includes middleware or external services.
In the embodiment, the unit cluster is applied to a SET architecture design scheme, and when the unit cluster is applied to the unit cluster architecture of the present application, a central cluster is abandoned, and only a gray level unit cluster and a formal unit cluster which are also divided into SETs and an intermediate program are deployed through the SET architecture design scheme. The SET architecture design is designed to solve the problem that a single large distributed cluster has certain expandability through splitting the machine + the interior of the cluster, but as the service volume further increases, the main key of the whole cluster scale becomes huge, so that a bottleneck can be reached at a certain point, the requirement of the expandability cannot be met, and the core service in the large cluster has problems and can influence the users of the whole network.
Under the SET architecture design, each unit cluster has the characteristic of only needing to be responsible for flow processing in the unit, flow splitting and fault isolation can be realized by combining an intermediate program under the SET architecture design, transaction data generated by the unit is only stored in the front period of each unit cluster, and bidirectional data synchronization can be performed subsequently through the intermediate program, so that the disaster recovery switching requirement is realized, the problems of expansibility and disaster recovery encountered by services are solved, and the high-speed development of system services is supported.
Fig. 7 is a schematic diagram of a service architecture of a simulation backend for implementing the gray scale publishing method based on the ESOP system according to this embodiment, in which a gray scale unit cluster and a formal unit cluster are shown, and the gray scale unit cluster and the formal unit cluster are isolated from each other by using external services, such as external services like rabbitmq (message queue), redis (cache), tdsql (distributed database), and sba (service based architecture), that is, the same external services are respectively deployed in the gray scale unit cluster and the formal unit cluster and used for task execution in the unit cluster.
In addition, the middleware can also be a middleware, and the middleware under the SET architecture design can include RPC (remote procedure call), KV, MQ and the like, wherein the RPC (remote procedure call) calls the service enclosed in the cluster for the cluster service; for non-clustered services, existing routing logic is used; KV (Key-Value, distributed storage), supports data generation and query of the unit cluster; MQ (MessageQueue), supports message production and consumption by clusters of units. The middleware is a set of universal parts oriented to information system interaction in the integration process, complex and universal functions of bottom layer communication, interaction, connection and the like are shielded, the middleware is provided in a product form, and during interaction, the middleware is directly adopted for connection and interaction, so that a large amount of code development and labor cost can be avoided, and the effect of physical resource isolation can be realized.
In this way, forwarding the service request in step S202 specifically includes forwarding the service request to a gray scale unit cluster if a traffic label included in the service request is a gray scale traffic label based on a gray scale unit cluster and a formal unit cluster that are deployed in advance; and if the traffic mark contained in the service request is a formal traffic mark, forwarding the service request to a formal unit cluster.
In this embodiment, the service layer in the grayscale unit cluster is deployed by using a containerization (docker) deployment strategy, and the docker is an open-source engine and can easily create a lightweight, portable, and self-sufficient container for any application. docker is commonly used for automated packaging and publishing of web applications; automatic testing and continuous integration and release; databases or other background applications are deployed and adapted in a service-type environment. Meanwhile, the docker can solve the problem of environment configuration and isolate the processes, and the isolated processes are independent of the host operating system and other isolated processes, so that the allocated resources are ensured to be isolated among the containers. The docker deployment strategy is applied to the deployment of the gray level unit cluster in the embodiment, so that resource isolation of the gray level unit cluster and the formal unit cluster is further achieved, docker deployment is convenient for capacity expansion, and system performance is improved.
Five major advantages of docker include sustainable deployment, version control support, portability, isolation and security. The sustainable deployment means that the docker maintains all configuration and dependency relationships in the container because the docker can maintain consistency in different environments, so that the same container can be used from development to production, and the same container can also be operated on different instances. The docker has flexibility, no difference or manual intervention between environments is ensured, and a developer is not required to configure a set of environment the same as a production environment.
The supporting of version control means that a docker container standardizes the use environment and ensures the environmental consistency between different developers and the release cycle. The docker container works just like a GIT (open source distributed version control system) warehouse, and can receive submitted modifications to a docker image and perform version control. Assuming that a component upgrade is performed, and this upgrade destroys the entire application environment, it can be rolled back to the previous version of the docker image in a few minutes. Compared with the common virtual machine backup and image creation process, the docker has higher speed, can quickly copy containers and realize environment redundancy.
Portability means that the docker container can run in a cloud server or a virtual machine, and only an operating system run by a host needs to support the docker. In this way, containers running on a certain cloud service instance can be easily migrated between environments, such as to virtual machines, to achieve consistent functionality.
Isolation means that docker ensures that each container has its own resources and is isolated from other containers. Completely different infrastructures can be run for different applications, and it is also ensured that each application uses only the resources (CPU, memory and disk space) allocated to them. The exhaustion of resources usually causes performance degradation or causes other applications to be completely unavailable, with resource isolation, a specific application no longer occupies all available resources, and the overall availability and stability of the service are improved.
Security refers to the fact that docker mounts the sensitive mount points (e.g.,/proc and/sys) of the host as read-only in the containers, and uses a set of copy-on-write file systems to ensure that the containers cannot read each other's data. It also restricts applications within the container from making system calls to the host and remains well compatible with such Security measures as SELinux (Security-enhanced Linux), and AppArmor (Linux system Security applications). In addition, all docker images on docker's multiport transponders are digitally signed to ensure that the images used by the subscribers are complete and unmodified by third parties. Because the docker containers are isolated and the resources of the containers are limited, even if one application is invaded or crashed, the application running on the other docker containers is not affected.
Therefore, the docker deployment strategy is applied to the deployment of the gray level unit cluster in the embodiment, and is used for realizing the gray level release method, further realizing the resource isolation of the gray level unit cluster and the formal unit cluster, and the docker deployment is convenient for capacity expansion, thereby improving the service performance and stability of the system, and ensuring the sustainable development and more possibilities of the ESOP system.
Referring to fig. 8, fig. 8 is a flowchart of step S200 in the embodiment shown in fig. 3 in an exemplary embodiment. As shown in fig. 8, step S200 may further include step S203, by which the service request is forwarded to the unit cluster corresponding to the tag field, which is described in detail as follows:
step S201, add the traffic tag corresponding to the tag field to the service request.
If the marked field is a gray field, adding a gray flow mark into the service request, if the marked field is a formal field, adding a formal flow mark into the service request, wherein the flow mark added by the service request is used for carrying out flow forwarding on a unified access layer subsequently.
Step S202, the service request is forwarded to the corresponding unit cluster which is deployed in advance through the flow mark and the forwarding rule.
In this embodiment, before the service request is obtained, a cell cluster is pre-deployed in the ESOP system, where the grayscale cell cluster and the formal cell cluster are physically isolated by an intermediate program, and the intermediate program includes middleware or external services.
The service request further includes a configuration file, and after the service request is forwarded to the cell cluster in step S202, the grayscale issuing method of this embodiment further includes step S203, where the service request is routed to the service layer in the cell cluster through the service identifier and the tenant identifier included in the configuration file.
After each unit cluster receives the forwarded service request, a configuration file contained in the service request is obtained, where the configuration file includes identification information such as a service identifier and a tenant identifier (service id), and the service request is routed to a service in a service layer (espo 2-service, espo 2-associations) separately deployed by each unit cluster as shown in fig. 7 through the service identifier. The service identifier serviceid corresponds to a service requested by the service request, and the tenant identifier appid corresponds to a tenant and has uniqueness.
As can be seen from the above, in the method provided in this embodiment, after the unified access layer receives the service request transmitted by the front-end service, the traffic forwarding is performed on the unified access layer through the added traffic flag corresponding to the flag field, the service request including the gray level traffic flag and the formal traffic flag is respectively forwarded to the gray level unit cluster and the formal unit cluster which are deployed in advance, the service request is routed to the service layer in the corresponding unit cluster based on the configuration file included in the service request, the service request is executed, and the obtained execution result is returned. Meanwhile, resource isolation is ensured in multiple aspects through SET framework gray level unit clusters and formal unit clusters, gray level unit cluster and formal unit cluster intermediate programs and container deployment strategy of the gray level unit clusters, so that isolation of tenant-level service resources is realized, gray level release is supported by taking tenants as units, association among the tenants is reduced, disaster tolerance capability of an applied ESOP system is improved, and utilization of system resources is maximized.
In another embodiment of the present application, a back-end script logic diagram of a gray scale publishing method for back-end services in an ESOP system production environment is provided, as shown in FIG. 9, after db (service request), respectively forwarding the corresponding service request to the gray level cell cluster and the formal cell cluster based on the mark field, executing the task script of the unit cluster in each unit cluster, as shown in fig. 9, executing the data of the company which only processes the unit cluster in different unit clusters by the timed task script, consuming the tasks of the unit cluster queue by the queue consumption script, supporting the message production and consumption of each unit cluster through the respective middleware MQ, therefore, in the practical application scene, the gray level publishing method provided by the application can realize the gray level publishing according to the tenants through the mark field, the physical resource isolation of the unit clusters and the resource isolation between the tenants are realized through the deployment of the unit clusters.
Further, in the embodiment, in the process that the queue consumption script consumes the task of the unit cluster queue, the task parameter corresponding to the task is determined according to the task information. Specifically, the task information in this embodiment includes a target weight Tar _ wei, a task aging Tar _ tim, and a processing difficulty coefficient Tar _ dic corresponding to the task target, and the task parameter Tar _ par is determined based on the above information as:
Tar_par=α·Tar_wei·e Tar_tim ·Tar_dic
where α represents a task factor.
And then, sequencing the tasks according to the task parameters, and sending the tasks to the corresponding unit cluster queues according to the sequence, so that the queue consumption script can sequentially process the tasks based on the sequence in the unit cluster queues, and further the task processing efficiency is improved.
Fig. 10 is a block diagram of a gray scale issuing apparatus 1000 based on an ESOP system according to an exemplary embodiment of the present application. As shown in fig. 10, the apparatus includes:
a receiving module 1001, configured to obtain a service request, where the service request includes a tag field corresponding to a gray release requirement of a tenant, and the tag field includes a gray field or a formal field;
a distributing module 1002, configured to forward the service request to the unit clusters corresponding to the tag fields according to a preset forwarding rule, where the unit clusters corresponding to different tag fields are independent of each other;
the issuing module 1003 is configured to receive an execution result returned after the service layer of the cell cluster executes the service request.
The device uses the gray level publishing method provided by the application, after receiving a service request, tenant information in the service request is obtained through a receiving module 1001, a session object contained in the tenant information is extracted, the session object is further inquired to obtain a mark field corresponding to the service request, the service request is forwarded to a unit cluster corresponding to the mark field through a distributing module 1002 according to the mark field, so that gray level publishing or formal publishing is supported by taking the tenant as a basic level, all the unit clusters are mutually independent, the mutual independence can reduce the association among the tenants, the influence among all the service requests can be avoided when the ESOP system executes the service requests of different tenants, and therefore, the resource isolation among the unit clusters and among the tenants is realized, and the disaster tolerance capability of the applied ESOP system and the overall performance of the system are improved
In another exemplary embodiment, the apparatus further comprises:
the system comprises a deployment module, a service module and a service module, wherein the deployment module is used for pre-deploying a unit cluster in an ESOP system, the unit cluster comprises a gray level unit cluster and a formal unit cluster, the gray level unit cluster and the formal unit cluster are isolated by physical resources through an intermediate program, and the intermediate program comprises a middleware or an external service;
a marking unit, configured to add a traffic mark corresponding to the mark field to the service request;
the forwarding unit is used for forwarding the service request to the gray level unit cluster when the flow mark included in the service request is the gray level flow mark; when the traffic mark included in the service request is a formal traffic mark, forwarding the service request to a formal unit cluster;
the routing unit is used for routing the service request to a service layer in the unit cluster through the service identifier and the tenant identifier contained in the configuration file;
the deployment module is further configured to deploy a service layer in the gray-scale unit cluster by using a containerization deployment strategy.
It should be noted that the gray scale issuing device provided in the foregoing embodiment and the gray scale issuing method provided in the foregoing embodiment belong to a unified concept, and specific ways of performing operations by each module and unit have been described in detail in the method embodiment, and are not described herein again. In practical applications, the gray scale issuing device provided in the above embodiment may distribute the above functions by different functional modules according to needs, that is, divide the internal structure of the device into different functional modules to complete all or part of the above described functions, which is not limited herein.
An embodiment of the present application further provides an electronic device, including: one or more processors; the storage device is configured to store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device is enabled to implement the traffic condition updating method provided in each of the embodiments.
FIG. 11 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application. It should be noted that the computer system 1100 of the electronic device shown in fig. 11 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 11, the computer system 1100 includes a Central Processing Unit (CPU)1101, which can perform various appropriate actions and processes, such as performing the methods in the above-described embodiments, according to a program stored in a Read-only memory (ROM) 1102 or a program loaded from a storage section 1108 into a Random Access Memory (RAM) 1103. In the RAM1103, various programs and data necessary for system operation are also stored. The CPU1101, ROM1102, and RAM1103 are connected to each other by a bus 1104. An Input/Output (I/O) interface 1105 is also connected to bus 1104.
The following components are connected to the I/O interface 1105: an input portion 1106 including a keyboard, mouse, and the like; an output portion 1107 including a Cathode Ray Tube (CRT), a liquid crystal display (LCd), and the like, and a speaker and the like; a storage section 1108 including a hard disk and the like; and a communication section 1109 including a network interface card such as a LAN (local area network) card, a modem, or the like. The communication section 1109 performs communication processing via a network such as the internet. A driver 1110 is also connected to the I/O interface 1105 as necessary. A removable medium 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like, is mounted on the drive 1110 as necessary, so that a computer program read out therefrom is mounted into the storage section 1108 as necessary.
In particular, according to embodiments of the application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication portion 1109 and/or installed from the removable medium 1111. When the computer program is executed by a Central Processing Unit (CPU)1101, various functions defined in the system of the present application are executed.
It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (Cd-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer-readable signal medium may comprise a propagated data signal with a computer-readable computer program embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.
Another aspect of the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the foregoing road condition refreshing method. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist separately without being incorporated in the electronic device.
The present invention is not intended to be limited to the particular embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed.

Claims (10)

1. The gray scale issuing method based on the ESOP system is characterized by comprising the following steps:
acquiring a service request, wherein the service request comprises a mark field, the mark field corresponds to the gray release requirement of a tenant, and comprises a gray field or a formal field which indicates whether the current service request needs to be forwarded to a gray environment;
forwarding the service request to a unit cluster corresponding to the mark field through a preset forwarding rule, wherein the unit cluster is used for collecting the service request, and the unit clusters corresponding to different mark fields are mutually independent;
and receiving an execution result returned after the service layer of the unit cluster executes the service request.
2. A gray scale publishing method according to claim 1, further comprising:
the method comprises the steps that unit clusters are deployed in advance in an ESOP system, wherein the unit clusters comprise gray level unit clusters and formal unit clusters, physical resource isolation is conducted on the gray level unit clusters and the formal unit clusters through an intermediate program, and the intermediate program comprises middleware or external services.
3. The gray scale publishing method according to claim 2, wherein the forwarding the service request to the cell cluster corresponding to the tag field according to a preset forwarding rule comprises:
adding a flow mark corresponding to a mark field into the service request;
and forwarding the service request to the corresponding unit cluster which is deployed in advance through the flow mark and the forwarding rule.
4. The gray scale publishing method according to claim 3, wherein the forwarding the service request to the cell cluster corresponding to the tag field according to a preset forwarding rule comprises:
if the traffic label included in the service request is a gray level traffic label, forwarding the service request to the gray level cell cluster;
and if the traffic mark contained in the service request is a formal traffic mark, forwarding the service request to the formal unit cluster.
5. The gray scale publishing method of claim 1, wherein the service request further comprises a configuration file, and before receiving an execution result returned after the service layer of the cell cluster executes the service request, the method further comprises:
and routing the service request to a service layer in the unit cluster through the service identifier and the tenant identifier contained in the configuration file.
6. The gray scale issuing method according to claim 1, wherein the service request includes the tag field corresponding to the gray scale issuing requirement in a middling instruction issued by a tenant; if the gray release requirement is a gray requirement, the mark field is a gray field; and if the gray release requirement is a non-gray requirement, the mark field is a formal field.
7. The gray scale publishing method according to any one of claims 1 to 6, wherein the service layer in the gray scale unit cluster is deployed using a containerization deployment strategy.
8. The gray scale release device based on ESOP system is characterized by comprising:
the receiving module is used for acquiring a service request, wherein the service request comprises a mark field, the mark field corresponds to the gray release requirement of a tenant, and comprises a gray field or a formal field which indicates whether the current service request needs to be forwarded to a gray environment or not;
the distribution module is used for forwarding the service request to the unit cluster corresponding to the mark field through a preset forwarding rule, wherein the unit cluster is used for collecting the service request, and the unit clusters corresponding to different mark fields are mutually independent;
and the issuing module is used for receiving an execution result returned after the service layer of the unit cluster executes the service request.
9. An electronic device, comprising:
one or more processors;
storage means for storing one or more programs that, when executed by the one or more processors, cause the electronic device to implement the ESOP system-based grayscale publication method of any one of claims 1-7.
10. A computer-readable storage medium having stored thereon computer-readable instructions, which, when executed by a processor of a computer, cause the computer to execute the gray scale issuing method based on the ESOP system according to any one of claims 1 to 7.
CN202210447442.5A 2022-04-26 2022-04-26 Gray scale publishing method based on ESOP system and related equipment Pending CN114840222A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210447442.5A CN114840222A (en) 2022-04-26 2022-04-26 Gray scale publishing method based on ESOP system and related equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210447442.5A CN114840222A (en) 2022-04-26 2022-04-26 Gray scale publishing method based on ESOP system and related equipment

Publications (1)

Publication Number Publication Date
CN114840222A true CN114840222A (en) 2022-08-02

Family

ID=82566686

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210447442.5A Pending CN114840222A (en) 2022-04-26 2022-04-26 Gray scale publishing method based on ESOP system and related equipment

Country Status (1)

Country Link
CN (1) CN114840222A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115185582A (en) * 2022-09-15 2022-10-14 畅捷通信息技术股份有限公司 Gray scale publishing method and device for multiple tenants and storage medium
CN117215596A (en) * 2023-08-02 2023-12-12 广州优谷信息技术有限公司 Helm-based gray level publishing method and device, electronic equipment and medium

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115185582A (en) * 2022-09-15 2022-10-14 畅捷通信息技术股份有限公司 Gray scale publishing method and device for multiple tenants and storage medium
CN115185582B (en) * 2022-09-15 2022-11-18 畅捷通信息技术股份有限公司 Gray scale publishing method and device for multiple tenants and storage medium
CN117215596A (en) * 2023-08-02 2023-12-12 广州优谷信息技术有限公司 Helm-based gray level publishing method and device, electronic equipment and medium

Similar Documents

Publication Publication Date Title
CN112118565B (en) Multi-tenant service gray level publishing method, device, computer equipment and storage medium
US20200081745A1 (en) System and method for reducing cold start latency of serverless functions
US11409719B2 (en) Co-locating microservice persistence containers within tenant-specific database
CN110727653B (en) Multi-project load balancing method and device
CN114840222A (en) Gray scale publishing method based on ESOP system and related equipment
CN105897946A (en) Obtaining method and system of access address
CN112866333A (en) Cloud-native-based micro-service scene optimization method, system, device and medium
US11461119B2 (en) Virtual containers configured to support multiple machine learning models
US11714747B2 (en) Executing integration scenario regression tests in customer landscapes
US7512941B2 (en) Method and system for distributing and updating heterogeneous resources
CN112035213A (en) Multi-tenant network car booking system and dynamic isolation method
CN109814978A (en) Across cluster moving method and system based on more OpenStack platforms
CN113204368B (en) Application processing method, server and storage medium
US11580008B2 (en) Method and system for synchronous development and testing of live, multi-tenant microservices based SaaS systems
CN115168162B (en) Multi-gray-scale issuing method and device based on ingess controller in container environment and storage medium
Arora et al. Lightweight edge slice orchestration framework
Mena et al. Towards high-availability cyber-physical systems using a microservice architecture
US20110289041A1 (en) Systems and methods for managing assignment templates
CN111447076B (en) Container deployment method and network element of network function virtualization (NVF) system
CN115834600B (en) Multi-cloud nanotube data synchronization method and device, electronic equipment and storage medium
US11789973B2 (en) Software-defined database replication links
CN111131472A (en) Building method of Apollo configuration center
CN115237818A (en) Method and system for realizing multi-environment multiplexing based on full link identification
DE112022000347T5 (en) EDGE TIME SHARING ACROSS CLUSTER THROUGH DYNAMIC TASK MIGRATION
CN117579480B (en) Cloud distributed resource data model expansion and labeling method and system

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