Collaborative note access method and device, storage medium and computer program product

Abstract

The invention discloses a collaborative note access method and device, a storage medium and a computer program product. The collaborative note access method comprises the steps that a network agent cluster of a server container management system receives a first collaborative note access request of a first client; the network proxy cluster distributes the data to a first network proxy server according to a polling strategy; the first network proxy server performs Hash operation according to the request parameter to obtain a Hash addressing routing identifier ID, determines an upstream service endpoint address, and forwards the access request to a first upstream service server; and the first upstream service server executes the access request according to the session state, and returns an execution result to the first client through the first network proxy server. By applying the scheme of the embodiment of the invention, the network agent cluster and the upstream service cluster are both container clusters, the network agent cluster receives and distributes the access request, the upstream service cluster executes the access request, and extension is performed, so that the bottleneck in storage and performance is avoided, and the actual demand is met.

Description

Technical Field

[0001] The present application relates to the field of Internet technologies, and in particular, to a method for accessing collaborative notes, an apparatus for accessing collaborative notes, a computer-readable storage medium, and a computer program product. Background Art

[0002] With the development of the Internet, collaborative office work has become a new development trend. Among them, a document jointly completed by multiple people is called a collaborative note. Collaborative notes allow multiple clients to edit, update, and comment on the same document, and the content is updated in real time, greatly improving work efficiency and the convenience of collaboration.

[0003] In order to enable multiple clients to perform operations such as editing, updating, and commenting on the same document, it is necessary to ensure that multiple clients access the same document. Collaborative notes usually have stateful session management, using a session flag (sessionKey) to identify the session state, and requiring that when a client accesses a stateful session marked with the same sessionKey, the session state should be the same. Horizontal expansion of stateful sessions usually adopts centralized state management, such as redis storage state management. Redis storage state management centrally stores the mapping relationship between the sessionKey mark and the session state in the redis in-memory database, and directly obtains the corresponding session state through the sessionKey mark when needed, ensuring the consistency of the session state of different clients for the same collaborative note. However, in the existing technology, this centralized state management method will make redis itself become a bottleneck in storage and performance as the number and complexity of session states increase, making it difficult to meet actual needs. Summary of the Invention

[0004] In view of the above-mentioned prior art, embodiments of the present invention disclose a method for accessing collaborative notes, which can overcome the performance bottleneck defect of centralized storage state management, achieve extended performance, and meet the browsing needs of users.

[0005] In view of this, embodiments of the present application propose a method for accessing collaborative notes, and the method includes:

[0006] A network proxy cluster in a server container management system receives a first collaborative note access request from a first client. The network proxy cluster includes M network proxy servers. The first collaborative note access request of the first client belongs to the application layer and uses a first collaborative note identifier as a request parameter. The network proxy cluster is a container cluster generated by the server container management system, and each of the network proxy servers is used to run an instance for implementing network proxy.

[0007] The network proxy cluster distributes the first collaborative note access request of the first client to one of the network proxy servers according to a polling strategy, as the first network proxy server;

[0008] The first network proxy server performs a hash operation on the request parameters to obtain a hash addressing routing identifier ID, determines the corresponding upstream service endpoint address according to the pre-stored mapping relation table by the hash addressing routing identifier ID, and forwards the first collaborative note access request of the first client to the first upstream service server according to the upstream service endpoint address. The first upstream service server is a service server in the upstream service cluster for implementing the first collaborative note service. The upstream service cluster is a container cluster generated by the server container management system, including N service servers, and each of the service servers is used to run an instance for implementing the collaborative note service;

[0009] The first upstream service server obtains its own session state, which is the current overall content of the first collaborative note, executes the first collaborative note access request of the first client according to the session state, and returns the execution result to the first client through the first network proxy server.

[0010] In view of the above prior art, an embodiment of the present invention discloses an access device for collaborative notes, which can overcome the performance bottleneck defect of centralized storage state management, achieve the purpose of expanding performance and meeting the browsing needs of users.

[0011] In view of this, an embodiment of the present application proposes an access device for collaborative notes, and the device includes:

[0012] A network proxy cluster module, configured to receive a first collaborative note access request of a first client. The network proxy cluster includes M network proxy servers. The first collaborative note access request of the first client belongs to the application layer and uses the first collaborative note identifier as a request parameter. The network proxy cluster is a container cluster generated by the server container management system, and each of the network proxy servers is used to run an instance for implementing network proxy; distribute the first collaborative note access request of the first client to one of the network proxy servers according to a polling strategy, as the first network proxy server; the first network proxy server performs a hash operation on the request parameters to obtain a hash addressing routing identifier ID, determines the corresponding upstream service endpoint address according to the pre-stored mapping relation table by the hash addressing routing identifier ID, and forwards the first collaborative note access request of the first client to the first upstream service server;

[0013] An upstream service cluster module is used to obtain its own session state, where the session state is the current overall content of the first collaborative note. It executes the access request of the first collaborative note of the first client according to the session state, and returns the execution result to the first client through the first network proxy server. The first upstream business server is a business server in the upstream service cluster for implementing the first collaborative note service. The upstream service cluster module is a container cluster generated by the server container management system, including N business servers, and each business server is used to run an instance for implementing the upstream service.

[0014] In view of the above-mentioned prior art, an embodiment of the present invention discloses a computer-readable storage medium, which can overcome the performance bottleneck defect of centralized storage state management, achieve the purpose of expanding performance and meeting the browsing needs of users.

[0015] A computer-readable storage medium has computer instructions stored thereon, and when the instructions are executed by a processor, the steps of the above-mentioned access method for collaborative notes can be implemented.

[0016] In view of the above-mentioned prior art, an embodiment of the present invention discloses a computer program product, which can overcome the performance bottleneck defect of centralized storage state management, achieve the purpose of expanding performance and meeting the browsing needs of users.

[0017] A computer program product includes computer instructions, and when the computer instructions are executed by a processor, the access method for collaborative notes as described above is implemented.

[0018] In summary, in the embodiment of the present application, the server container management system generates a network proxy cluster and an upstream service cluster. The network proxy cluster has multiple network proxy servers, and the upstream service cluster has multiple business servers. A mapping relationship table of the hash addressing routing identifier ID and the upstream service endpoint address is also automatically set. When any client accesses the collaborative note service in the business server, the network proxy cluster distributes the access request to one of the network proxy servers, and the network proxy server forwards the access request to the business server running the collaborative note service to realize the access of the collaborative note. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0020] Figure 1 It is a flowchart of the first embodiment of the access method for collaborative notes implemented by the present application.

[0021] Figure 2 It is a flowchart of the second embodiment of the method for implementing collaborative note access in this application.

[0022] Figure 3 It is a flowchart of generating a mapping relation table in the third embodiment of the method in this application.

[0023] Figure 4 It is a flowchart of updating the mapping relation table in the fourth embodiment of the method in this application.

[0024] Figure 5 It is a system architecture diagram of the fifth embodiment of the method.

[0025] Figure 6 It is a flowchart of the fifth embodiment of the method for implementing collaborative note access in this application.

[0026] Figure 7 It is an internal structure diagram of the first embodiment of the device for implementing collaborative note access in this application. Detailed implementation manners

[0027] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of this application.

[0028] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present invention and the above accompanying drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments of the present invention described here can be implemented in an order other than those illustrated or described here. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these process, method, product or device.

[0029] Next, the technical solutions of the present invention will be described in detail with specific embodiments. The following several specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0030] The prior art adopts centralized state management. In the case of an increase in the number and complexity of session states, Redis will become a storage and performance bottleneck. In view of the defects of the prior art, the embodiments of the present application abandon centralized state management and use a container management system on the server side to implement access to collaborative notes. The container management system on the server side generates a network proxy cluster and an upstream service cluster. Containers in the network proxy cluster run instances that implement network proxies, and containers in the upstream service cluster run instances that implement upstream business services. Any collaborative note access request is assigned to a certain network proxy instance in the network proxy cluster by a polling strategy, the corresponding upstream service is determined by a mapping relation table, and the collaborative note access request is forwarded to the upstream service for processing, thereby breaking the disadvantages of the centralized state management method. The session state of collaborative notes can be easily expanded, greatly meeting the actual needs.

[0031] In the embodiments of the present application, the container management system is a container orchestration platform used to manage and automate the deployment, scaling, and running of containerized applications. The core functions and features of the container management system include: container orchestration, managing large-scale container clusters, automatically deploying, scheduling, and performing lifecycle management on containers; service discovery and load balancing, automatically assigning IP addresses and DNS names, providing service discovery and load-based traffic distribution for containers; automatic scaling, automatically expanding or reducing the number of containers (horizontal scaling) according to workload requirements, and supporting automatic adjustment of container resources (vertical scaling); self-healing ability, monitoring the running status of containers, and when a problem occurs in the running of a certain container, restarting it or scheduling it to other containers. In addition, the container management system also includes functions and features such as storage orchestration, key and configuration management, rolling updates and rollbacks, and various runtime supports, which will not be elaborated here. In practical applications, the container management system can be implemented using Kubernetes (abbreviated as K8s). In the container management system, a Pod is the smallest resource management component and can contain one or more containers. A container is an application instance running in a Pod, and each container encapsulates a separate application or process. In addition, the server side in the embodiments of the present application is placed in the cloud, and the client interacts with the server side through an application layer protocol, such as the HyperText Transfer Protocol (HTTP) or the full-duplex WebSocket protocol.

[0032] Figure 1 It is a flowchart of the first embodiment of the method for implementing access to collaborative notes in the present application. As Figure 1 shown, the method includes:

[0033] Step 101: The network proxy cluster in the server container management system receives the first collaborative note access request from the first client. The network proxy cluster includes M network proxy servers. The first collaborative note access request of the first client belongs to the application layer and uses the first collaborative note identifier as a request parameter. The network proxy cluster is a container cluster generated by the server container management system, and each network proxy server is used to run an instance that implements network proxying.

[0034] In this embodiment, the server container management system is deployed in the cloud and interacts with the client through the HTTP protocol or the WebSocket protocol. For horizontal expansion, the server container management system generates a container cluster. Among them, the network proxy cluster described in this step includes M network proxy servers (M is a natural number greater than 1). Each network proxy server is essentially a Pod generated by the server container management system and is used to run an instance that implements network proxying. Since it runs an instance that implements network proxying, such a Pod is also called a network proxy server in the embodiments of this application. It should be noted that the network proxy server here is not a physically independent server, but a resource management component, and can also be regarded as a virtual network proxy server or a soft network proxy server. Since there are M such network proxy servers, they are combined and called a network proxy cluster.

[0035] In the embodiments of this application, multiple different clients are allowed to access the same collaborative note. To distinguish the access of other clients, the client in this step is called the first client, and the access of other clients in the future is called the second client. However, this does not mean that only two clients can access the collaborative note. Instead, the first client and the second client are used to distinguish the access of different clients. In fact, the solution of the embodiments of this application allows thousands of clients to access. For the same reason, the collaborative note to be accessed in this step is called the first collaborative note. In fact, the embodiments of this application allow access to thousands of different collaborative notes.

[0036] Step 102: The network proxy cluster distributes the first collaborative note access request of the first client to one of the network proxy servers according to the round-robin strategy as the first network proxy server.

[0037] To achieve load balancing, the network proxy cluster in this step distributes the received access requests to a certain network proxy server according to the round-robin strategy. The round-robin strategy here can be implemented using any round-robin technology in the prior art, as long as load balancing can be achieved. To distinguish it from other network proxy servers, it is called the first network proxy server here. Since the network proxy cluster is a container cluster generated by the server container management system, including M network proxy servers, even if multiple clients access simultaneously, it can be scaled according to requirements, distributing multiple accesses to different network proxy servers to avoid the bottleneck problem of the performance of the network proxy server.

[0038] Step 103: The first network proxy server performs a hash operation on the request parameters to obtain a hash addressing routing identifier ID, and determines the corresponding upstream service endpoint address according to the pre-saved mapping relation table by the hash addressing routing identifier ID. Then, it forwards the first collaborative note access request of the first client to the first upstream service server according to the upstream service endpoint address. The first upstream service server is a service server in the upstream service cluster for implementing the first collaborative note service. The upstream service cluster is a container cluster generated by the server container management system, including N service servers, and each service server is used to run an instance for implementing the upstream service.

[0039] In this step, a hash operation is performed on the request parameters in the access request to obtain a hash addressing routing identifier ID, and then the upstream service endpoint address is determined through the mapping relation table, and the access request is forwarded to the corresponding upstream service server according to the upstream service endpoint address. To distinguish it from other upstream service servers, the upstream service server for implementing the first collaborative note service is called the first upstream service server in this step.

[0040] To perform horizontal scaling, a container cluster is generated by the server container management system. Among them, the upstream service cluster described in this step includes N service servers (N is a natural number greater than 1). Similarly, each service server is essentially a Pod generated by the server container management system and is used to run an instance for implementing the collaborative note service. Since it runs an instance for implementing the collaborative note service, such a Pod is also called a service server in the embodiments of this application. It should be noted that the service server here is not an independent server in the physical sense, but a resource management component, and can also be considered a virtual service server or a soft service server. Since there are N such service servers, all implementing the upstream service, they are combined and called the upstream service cluster.

[0041] In the embodiments of the present application, multiple different collaborative notes are allowed. To distinguish different collaborative notes, the collaborative note to be accessed in this step is referred to as the first collaborative note, and the business server that implements the business service of the first collaborative note is referred to as the first upstream business server.

[0042] Step 104: The first upstream business server obtains its own session state, where the session state is the current overall content of the first collaborative note. According to the session state, the first upstream business server executes the first collaborative note access request of the first client and returns the execution result to the first client through the first network proxy server.

[0043] In the embodiments of the present application, the current overall content of each collaborative note is separately stored in each upstream business server. The current overall content of the first collaborative note is stored in the first upstream business server, and the current overall content of the second collaborative note is stored in the second upstream business server, and so on. For the collaborative note service described in the present application, the session state is the overall content of the collaborative note. The first collaborative note access request may be operations such as reading, modifying, deleting, updating, etc. The first upstream business server executes the access request according to the current overall content of the first collaborative note and returns the execution result to the first client through the first network proxy server.

[0044] Applying the solution of the embodiments of the present application, the server container management system generates a network proxy cluster and an upstream service cluster. Both the network proxy cluster and the upstream service cluster are container clusters. The network proxy cluster receives and distributes access requests, and the upstream service cluster executes access requests. Since the network proxy cluster includes M network proxy servers and the upstream service cluster includes N business servers, it is expanded, thereby avoiding bottlenecks in storage and performance and meeting actual requirements.

[0045] In practical applications, when multiple different clients access the same collaborative note, that is, multiple users need to perform editing operations (such as adding, deleting, modifying, etc.) on the same collaborative note, it is necessary to ensure that these access requests from different clients are all targeted at the same collaborative note. For example, the first client sends a first collaborative note access request, indicating that it needs to access the first collaborative note, and the first network proxy server forwards the access request to the first upstream business server. At this time, assume that the second client sends a first collaborative note access request, also indicating that it needs to access the first collaborative note, and the second network proxy server receives the first collaborative note access request sent by the second client. In this case, it is also required that the second network proxy server forwards the first collaborative note access request sent by the second client to the first upstream business server, so as to accurately access the first collaborative note. Different clients access the same upstream business server through different network proxy servers, which is also referred to as sticky access in the embodiments of the present application.

[0046] In the prior art, to achieve sticky access and maintain the consistency of session states, usually only one network proxy server is set up to ensure that different clients access the same upstream service server. If multiple network proxy servers are set up, the mapping relation tables inside different network proxy servers are different, and the access requests of different clients may be forwarded to different upstream service servers, resulting in multiple users being unable to access the same collaborative note simultaneously, or accessing the collaborative note in different session states. Different from the sticky access of other prior arts, in the embodiments of the present application, the same mapping relation table is saved in different network proxy servers, and the same hash addressing routing identifier ID is calculated through hash operation, and the same upstream service endpoint address is mapped to by using the mapping relation table. That is to say, no matter which network proxy server in the network proxy cluster receives the access request of the client, it can be forwarded to the same upstream service server, so as to achieve sticky access.

[0047] In order to illustrate the technical solution for achieving sticky access in the embodiments of the present application, based on the first method embodiment above, other embodiments will be introduced below.

[0048] Figure 2 It is a flowchart of the second method embodiment for accessing collaborative notes in the present application. As Figure 2 shown, the method includes:

[0049] Step 201: The network proxy cluster in the server container management system receives the first collaborative note access request of the second client. The first collaborative note access request of the second client belongs to the application layer and uses the first collaborative note identifier as a request parameter. The second client is different from the first client.

[0050] This step is similar to step 101 in the first method embodiment, except that the access request in this step is initiated by the second client.

[0051] Step 202: The network proxy cluster distributes the first collaborative note access request of the second client to one of the network proxy servers according to the polling strategy. This network proxy server is used as the second network proxy server, and the second network proxy server is different from the first network proxy server.

[0052] This step is similar to step 102 in the first method embodiment, except that the access request in this step is distributed to the second network proxy server.

[0053] Step 203: The second network proxy server performs a hash operation on the request parameters to obtain a hash addressing routing identifier ID, determines the corresponding upstream service endpoint address according to the pre-saved mapping relation table by the hash addressing routing identifier ID, and forwards the first collaborative note access request of the second client to the first upstream service server according to the upstream service endpoint address. The mapping relation tables saved by the first network proxy server and the second network proxy server are the same. In the mapping relation table, the same hash addressing routing identifier ID corresponds to the same upstream service endpoint address, and the hash operation is a stable hash algorithm.

[0054] This step is similar to step 103 in Method Embodiment 1, the difference being that in this step, the second network proxy server maps and forwards the access request. It should be noted that the mapping relation tables in the first network proxy server and the second network proxy server are synchronized. As long as the request parameter is the first collaborative note identifier, the same hash addressing routing identifier ID can be obtained through the hash operation, and then mapped to the same upstream service endpoint address, that is, forwarded to the same service server (the first upstream service server).

[0055] Step 204: The first upstream service server obtains its own session status, executes the first collaborative note access request of the second client according to the session status, and forwards the execution result to the second client through the second network proxy server.

[0056] This step is similar to step 104 in Method Embodiment 1, the difference being that the execution result of this step is forwarded to the second client by the second network proxy server.

[0057] Applying the solution of this application embodiment, when different clients access the same collaborative note, the access requests can be distributed to different network proxy servers, but different network proxy servers can accurately forward different access requests to the upstream service server where the same collaborative note is located through hash operation and the mapping relation table, realizing sticky access.

[0058] In Method Embodiment 1 and Method Embodiment 2 above, each network proxy server in the network proxy cluster saves the same mapping relation table. The generation and maintenance of the mapping relation table will be introduced in detail below.

[0059] As described above, the server container management system generates a container cluster, including M network proxy servers and N business servers. Each business server is a Pod generated by the server container management system and is used to run an instance for implementing an upstream service. In practical applications, each Pod can run one or more instances. If there are Q collaborative notes (Q is a natural number greater than 1) providing services in the server container management system, then the services of these Q collaborative notes will be provided by these N business servers. Here, M, N, and Q are set according to the actual situation and can be the same or different. For example, if N is large enough, that is, enough business servers are set, each business server can run only one application instance of a collaborative note. And if the number of collaborative notes is relatively large, then one business server can run multiple application instances of collaborative notes, where one application instance corresponds to one collaborative note. Additionally, due to the characteristics of collaborative notes themselves, such as temporary and real-time access, etc., it is not suitable to manually set a fixed mapping table in advance. The embodiment of the present application provides a method for generating a mapping relationship table, which can be automatically set and ensure that access requests for the same collaborative note are forwarded to the same business server.

[0060] Figure 3 It is a flowchart of generating a mapping relationship table in the third embodiment of the method of the present application. As Figure 3 shown, before accessing the collaborative note, the method includes:

[0061] Step 301: The server container management system generates a container cluster, uses M of them as network proxy servers, and uses N of them as business servers for collaborative note business services.

[0062] As described above, the embodiment of the present application generates a container cluster by the server container management system, including a network proxy cluster and an upstream service cluster. Among them, the network proxy cluster includes M network proxy servers, and the upstream service cluster includes N business servers for collaborative note business services. Both M and N are natural numbers greater than 1. Each network proxy server and each business server are Pods generated by the server container management system and run instances.

[0063] Step 302: Assign upstream service endpoint addresses to the N business servers respectively to determine N upstream service endpoint addresses.

[0064] To accurately locate the business server for subsequent access requests, in this step, an upstream service endpoint address is assigned to each business server. The upstream service endpoint address mentioned here includes the IP address and the service port number, and they are concatenated by a colon, that is, IP:port. Its form is similar to the entity network address, except that the object here is the virtual business server. Suppose the IP address of a certain business server A is 10.0.4.78 and its service port number is 9090. Then the upstream service endpoint address of this business server A is 10.0.4.78:9090. In this way, the upstream service endpoint addresses can be assigned to N business servers in advance. The step of assigning upstream service endpoint addresses to N business servers respectively can be automatically assigned by the server container management system when the business servers are generated.

[0065] Step 303: Assign collaborative note identifiers to Q collaborative notes respectively to determine Q collaborative note identifiers.

[0066] As mentioned above, the solution of the embodiment of the present application allows multiple different collaborative notes to be provided. To distinguish different collaborative notes, different identifiers are set for each collaborative note here. For example, the collaborative note identifier "#1" is set for the first collaborative note, the collaborative note identifier "#2" is set for the second collaborative note, and so on.

[0067] The assignment of N upstream service endpoint addresses and the setting of Q collaborative note identifiers in the embodiment of the present application can be executed according to the actual situation, and there is no strict order. For example, the upstream service endpoint address can be assigned to the business server when it is generated, and the collaborative note identifier can be assigned when a new collaborative note is created.

[0068] Step 304: Use the consistent hashing algorithm to perform hashing operations on Q collaborative note identifiers one by one to determine the hash addressing routing ID.

[0069] The collaborative note identifier (such as "#1") can be a string, which is used as the sessionKey value in the sticky session of the server container management system. Then, the stable hashing algorithm is used to perform a hashing operation on the sessionKey value to obtain a hashing result. Additionally, due to resource and performance limitations, there is usually an upper limit value L for the number of business servers generated by the server container management system. Then, taking the modulus (mod) operation of the hashing result and the upper limit value L of the number of business servers can obtain a value within [0, L), which is used as the corresponding hash addressing routing ID. That is to say, any collaborative note identifier can obtain the hash addressing routing ID through stable hashing operation and then taking the modulus (mod) operation with the upper limit value L of the number of business servers. Since the result calculated by the stable hashing operation always maps to an unsigned 64-bit integer, the same collaborative note identifier can always be mapped to the same hash addressing routing ID through the above calculation.

[0070] Step 305: Corresponding the hash addressing routing ID to N upstream service endpoint addresses to form a mapping relationship table and save it in the database.

[0071] As mentioned above, Q and N are natural numbers greater than 1, and Q and N can be the same or different. If N is large enough, that is, N >= Q, a business server can run an application instance of a collaborative note. If N < Q, then a business server can run multiple application instances of collaborative notes simultaneously. That is to say, in another embodiment, if the number of collaborative notes is very large, that is, the value of P is very large, and there is an upper limit value L for the number of business servers, after performing stable hashing on the collaborative note identifier and taking the modulus of the upper limit value L, there may be multiple collaborative note identifiers corresponding to the same hash addressing routing ID, and the number of hash addressing routing IDs obtained after calculation may be smaller than Q. Regardless of which situation, the embodiments of the present application can allocate Q collaborative notes to N business servers for running. Such a corresponding relationship is called a mapping relationship table in the embodiments of the present application. Once the mapping relationship table is established, the server container management system can store it in the database (mysql database) for preservation.

[0072] The Pod generated by the server - side container management system is essentially a resource management component. During the operation of an instance, due to bugs in the internal program logic of the instance or excessive load, the Pod resources may not be able to bear the load, resulting in the container or the business server being unable to work properly. This situation is usually regarded as the death of the instance, the death of the container, or even the death of the business server. The container management system can capture the status of the instance, the container, and the business server in real - time. If a certain collaborative note cannot continue to run on the original business server due to the death of the instance, the container, or the business server, a new business server needs to be configured for this collaborative note, and the original mapping relationship table also needs to be updated to avoid subsequent client access failures.

[0073] In another embodiment, the server - side container management system also generates another Pod, and the container therein is specifically used for monitoring and managing the operation of the business server, which is called a monitor in the embodiments of the present application. The monitor can set an API service management interface for interaction with the server - side container management system. That is to say, when the server - side container management system captures a change in the status of the instance, the container, and the business server it manages, the monitor can obtain the status change through the API service management interface. Since the mapping relationship table in the embodiments of the present application is a mapping between the hash - addressed routing ID and the upstream service endpoint address of the business server, only the status change of the business server is concerned here.

[0074] Figure 4 It is the flowchart for updating the mapping relationship table in the fourth embodiment of the method of the present application. As Figure 4 shown, the method includes:

[0075] Step 401: When the first preset time interval arrives, the monitor in the server - side container management system determines the surviving business servers through the API service management interface as the surviving business servers, and obtains the upstream service endpoint addresses of the surviving business servers.

[0076] Here, the surviving business server refers to the business server with a normal - running instance in the upstream service cluster, rather than a dead business server. The monitor is a Pod generated by the server - side container management system and is used for monitoring and managing the operation of the business server. The monitor can check which business servers are in a surviving state when the first preset time interval arrives. The first preset time interval is set according to the actual situation, such as set to 10 seconds.

[0077] Step 402: Query the database based on the upstream service endpoint address of the surviving business server to determine whether there is an invalid mapping relationship. If there is, delete the invalid mapping relationship, remap the hash addressing routing ID in the invalid mapping relationship to the upstream service endpoint address of the surviving business server, generate a new mapping relationship table, and replace the original mapping relationship table in the database; otherwise, do nothing.

[0078] If a certain business server is in a dead state, it can be determined that the instances and containers in it cannot work properly for some reason. At this time, the mapping relationship between the original hash addressing routing ID and the upstream service endpoint address of this business server is invalid. For example, a certain business server A runs the first collaborative note service, the identifier of the first collaborative note is "#1", its hash addressing routing ID is "1", and the upstream service endpoint address of business server A is "10.0.7.25:9090", and its mapping relationship is "1 ——> 10.0.7.25:9090". When the client accesses the first collaborative note again, if the network proxy server still sends the access request to the address 10.0.7.25:9090, and the business server A where this address is located cannot work properly, the client cannot receive a normal feedback result.

[0079] In this embodiment, querying the database based on the upstream service endpoint address of the surviving business server can determine which business servers corresponding to the upstream service endpoint addresses in the mapping relationship table are in a surviving state and which are in a dead state, and delete the invalid mapping relationships related to the business servers in the dead state.

[0080] In another embodiment, the server container management system can automatically regenerate a Pod (business server) according to the actual situation, and migrate the instances running in the containers of the dead Pod to the new Pod, which is equivalent to migrating the instances of the original collaborative note service to the new business server. In this case, the upstream service endpoint address of the new business server has changed, so it is necessary to re - establish the mapping relationship from the hash addressing routing ID in the invalid mapping relationship to the upstream service endpoint address of the surviving business server. Suppose the server container management system can automatically regenerate a Pod according to the actual situation, that is, the business server B, whose upstream service endpoint address is "10.0.7.78:9090", then a new mapping relationship "1 -> 10.0.7.78:9090" can be established. After that, when the client accesses the first collaborative note again, it can send the access request to the business server B at the address "10.0.7.78:9090" according to "1 -> 10.0.7.78:9090", and the business server B continues to implement the access to the collaborative note. The mapping relationship table in the embodiments of the present application can be uniformly stored in the mysql database and obtained by the network proxy server itself. Of course, if there is no situation of invalid mapping relationship, there is no need to update the mapping relationship table and no processing is done.

[0081] After the established mapping relationship is saved in the database, each network proxy server in the network proxy cluster can obtain the mapping relationship table from the database by itself. In practical applications, in order to ensure that the mapping relationship table is up - to - date, a second preset time interval can be set. Each network proxy server in the network proxy cluster obtains the mapping relationship table from the database when the second preset time interval arrives, and replaces its original mapping relationship table with the newly obtained mapping relationship table. The second preset time interval described here can be set according to the actual situation, such as 2 seconds.

[0082] To better illustrate the solution of the embodiments of the present application, the following uses a preferred embodiment for detailed description. Figure 5 It is the system architecture diagram of the fifth method embodiment, including: a server container management system 51, a network proxy cluster 52, an upstream service cluster 53, a monitor 54, an API service management interface 55, a mysql database 56, and a client 57. As Figure 5As shown in the figure, it is assumed that the server container management system 51 is implemented by Kubernetes (abbreviated as K8s) and deployed in the cloud. The client 57 interacts with the server container management system 51 in the cloud through the HTTP protocol or the WebSocket protocol. K8s has functions and features such as container orchestration, service discovery and load balancing, automatic scaling, self-healing ability, storage orchestration, key and configuration management, rolling updates and rollbacks, and various runtime supports. K8s automatically generates a number of Pods as needed. Among them, M Pods form a network proxy cluster 52, and each Pod is a network proxy server 521 for running an instance implementing the network proxy; in addition, N Pods form an upstream service cluster 53, and each Pod is a business server 531 for running an instance implementing the collaborative note service. Among them, p1 to p3 are 3 network proxy servers in the network proxy cluster 52, and s1 to s4 are 4 business servers in the upstream service cluster 53. K8s automatically generates a Pod as a monitor 54 for monitoring and managing the operation of the business server, and sets an API service management interface 55 for the monitor 54 for interaction with the server container management system. In addition, the embodiments of the present application provide Q (Q = 6) collaborative notes q1 to q6, which are respectively placed in 4 business servers s1 to s4 for operation, and the upper limit value L of the number of business servers in the upstream service cluster 53 is 5. Of course, M, N, Q, and L here can be set according to actual situations and are not limited to the values in the embodiments of the present application.

[0083] In the embodiments of the present application, the isomorphic monitor and the network proxy server in the network proxy cluster 52 can be written in the rust language. Among them, the network proxy cluster 52 can be completed using the Pingora framework. The Pingora framework is a high-performance HTTP proxy service framework mainly designed for network communication in distributed systems and microservice architectures. The Pingora framework has the following characteristics: high-performance HTTP proxy; supports multiple protocols such as HTTP / 1, HTTP / 2, and HTTP / 3, allowing the optimal communication method between the client and the server; low latency; strong scalability, capable of handling large-scale traffic and adapting to growing request loads.

[0084] In the embodiments of the present application, the upstream service cluster 53 generated by K8s has the following characteristics: load balancing, and the service can automatically distribute processes among multiple Pods; service discovery, providing a DNS name for the service, and other services can access through this name; stability, assigning a virtual IP address to the service, which is not affected by the Pod life cycle, ensuring the availability and stability of the application.

[0085] In the initial stage of operation, K8s will automatically allocate business servers for the collaborative note services according to the number of collaborative note services, and run 5 collaborative note services in a total of 4 business servers s1 to s4. Assume that the collaborative note identifiers of the 5 collaborative notes are: q1 = "#1", q2 = "#2", q3 = "#3", q4 = "#4", q5 = "#5", q6 = "#6". According to step 304 in the above method embodiment three, perform stable hashing on the collaborative note identifiers and take the modulus of the upper limit value L to determine that the hash addressing routing IDs corresponding to the collaborative note identifiers are: after hashing and taking the modulus, "#1" corresponds to partition_id1, "#2" corresponds to partition_id2, "#3" corresponds to partition_id3, "#4" corresponds to partition_id4, "#5" corresponds to partition_id5, and "#6" also corresponds to partition_id1 after hashing and taking the modulus. According to step 302 in the above method embodiment three, determine that the upstream service endpoint addresses upstream of the 4 business servers are: 10.0.4.78:9090, 10.0.4.79:9090, 10.0.4.80:9090, 10.0.7.25:9090. The corresponding relationship is shown in Table 1:

[0086] Hash Addressing Routing ID (partition_id) Upstream Service Endpoint Address (upstream) partition_id1 10.0.4.78:9090 partition_id2 10.0.4.79:9090 partition_id3 10.0.4.80:9090 partition_id4 10.0.7.25:9090 partition_id5 10.0.7.25:9090

[0087] Table 1

[0088] Among them, 10.0.4.78:9090 is the address of business server s1, 10.0.4.79:9090 is the address of business server s2, 10.0.4.80:9090 is the address of business server s3, and 10.0.7.25:9090 is the address of business server s4. It should be noted that the collaborative note identifiers "#1" and "#6" correspond to the same hash addressing routing ID after calculation, and partition_id1 corresponds to the address of business server s1, which means that both "#1" and "#6" collaborative notes will be provided by business server s1. And partition_id4 and partition_id5 are not the same hash addressing routing ID, but both correspond to the address of business server s4, indicating that both "#4" and "#5" collaborative notes will be provided by business server s4 at the same time. Of course, in actual applications, when there are enough business servers, one business server can also provide only one collaborative note.

[0089] After establishing the mapping relationship table, the mapping relationship table can be saved in the mysql database 56. At the same time, the proxy network servers p1 to p3 respectively obtain the mapping relationship table from the mysql database 56 and save it in themselves.

[0090] Figure 6 This is the flowchart of the fifth embodiment of the method for implementing collaborative note access in this application. As Figure 1 shown, assume that client 1 wants to access collaborative note q1. The method includes:

[0091] Step 601: The network proxy cluster 52 receives the collaborative note access request y1 of client 57 (client 1). The collaborative note access request y1 of client 1 is an HTTP protocol request, and its request parameter is "#1".

[0092] This step is the same as step 101 in the first embodiment of the above method. Assume that the collaborative note access request y1 is http: / / 127.0.0.1:3000 / example?#1, where "#1" is the request parameter.

[0093] Step 602: The network proxy cluster 52 distributes the collaborative note access request y1 of client 1 to the network proxy server p1 according to the polling strategy.

[0094] Step 603: The network proxy server p1 performs a hash operation based on the request parameter "#1" to obtain the hash addressing routing identifier ID (partition_id1), and determines the corresponding upstream service endpoint address (upstream = 10.0.4.78:9090) from the pre-saved mapping relationship table according to the hash addressing routing identifier ID (partition_id1). The collaborative note access request y1 of client 1 is forwarded to the business server s1 according to the upstream service endpoint address.

[0095] When forwarding, the network proxy server p1 actually replaces the target address in the collaborative note access request y1 of client 1 with the address of the business server s1, that is, http: / / 10.0.4.78:9090 / example?#1, so as to forward the collaborative note access request y1 of client 1 to the business server s1.

[0096] Step 604: The business server s1 obtains its own session state. The session state is the current overall content of the collaborative note x1. The collaborative note access request y1 of client 1 is executed according to the session state, and the execution result is returned to client 1 through the network proxy server p1.

[0097] So far, client 1 has completed the access to the collaborative note q1.

[0098] Similarly, if client 2 wants to access the collaborative note q1, it can continue as follows:

[0099] Step 605: The network proxy cluster 52 receives the collaborative note access request y2 from the client 57 (Client 2). The collaborative note access request y2 of Client 2 is an HTTP protocol request, and its request parameter is "#1".

[0100] This step is the same as step 101 in the first method embodiment above. Assume that the collaborative note access request y2 is http: / / 190.168.0.1:3000 / example?#1, where "#1" is the request parameter.

[0101] Step 606: The network proxy cluster 52 distributes the collaborative note access request y2 of Client 2 to the network proxy server p3 according to the round-robin strategy.

[0102] Step 607: The network proxy server p3 performs a hash operation based on the request parameter "#1" to obtain the hash addressing routing identifier ID (partition_id1), and determines the corresponding upstream service endpoint address (upstream = 10.0.4.78:9090) from the pre-saved mapping relationship table according to the hash addressing routing identifier ID (partition_id1). The collaborative note access request y2 of Client 2 is forwarded to the business server s1 according to the upstream service endpoint address.

[0103] Step 608: The business server s1 obtains its own session state, and the session state is the current overall content of the collaborative note x1. The collaborative note access request y2 of Client 1 is executed according to the session state, and the execution result is returned to Client 2 through the network proxy server p3.

[0104] Although Client 1 and Client 2 are two completely different clients, and the access requests are distributed to different network proxy servers, their access request parameters are the same, both being "#1". Therefore, the same hash addressing routing ID can be calculated through stable hash operation and modulo operation, and mapped to the same business server s1 through the mapping relationship table shown in Table 1 above, so as to access the same collaborative note ("#1") and achieve sticky access.

[0105] If a business server in the upstream service cluster 53 fails to work properly and is in a dead state, the monitor 54 can obtain the surviving business servers regularly (every 10 seconds) through the API service management interface 55. For example, if the business server s1 is dead at a certain moment, the services of the collaborative notes q1 and q6 can be migrated to other business servers capable of hosting containers, or a new Pod can be regenerated as a new business server. In short, when the business server s1 is dead, the collaborative notes q1 and q6 need to be migrated to other business servers. Here, it is assumed that K8s generates a new Pod as the business server s5, whose upstream service endpoint address upstream is 10.0.10.78:9090, and the collaborative notes q1 and q6 will be migrated to the business server s5. Then, the monitor 54 will delete the first mapping relationship in Table 1 and form a mapping relationship between the new upstream service endpoint address 10.0.10.78:9090 and the hash addressing routing ID partition_id1. The new mapping relationship table is shown in Table 2:

[0106] Hash Addressing Routing ID (partition_id) Upstream Service Endpoint Address (upstream) partition_id2 10.0.4.79:9090 partition_id3 10.0.4.80:9090 partition_id4 10.0.7.25:9090 partition_id5 10.0.7.25:9090 partition_id1 10.0.10.78:9090

[0107] Table 2

[0108] The proxy network servers p1 - p3 will automatically obtain the new mapping relationship table from the mysql database 56 regularly (every 2 seconds), so as to ensure that the proxy network servers p1 - p3 can accurately forward the access requests of clients.

[0109] In the embodiment of the present application, K8s is used to implement the server - side container management system 51, and the Pingora framework is used to implement the network proxy servers in the network proxy cluster 52. In practical applications, other methods can also be used to implement, and it is not limited thereto.

[0110] Applying the solution of the embodiment of the present application, since the network proxy cluster includes multiple network proxy servers and the upstream service cluster includes multiple business servers, and has been expanded, the bottlenecks in storage and performance can be avoided. At the same time, different network proxy servers accurately forward the access requests of different clients to the upstream business server where the same collaborative note is located through hash operations and the mapping relationship table, so as to achieve sticky access. In addition, the mapping relationship table can be automatically updated according to the status of the business server to ensure the effectiveness of accessing the collaborative note.

[0111] Based on the above method, the present application also discloses an access device for collaborative notes. Figure 7 It is the internal structure diagram of the first embodiment of the access device for collaborative notes implemented by the present application. As Figure 7 shown, the device includes: a network proxy cluster module 701 and an upstream service cluster module 702.

[0112] The network proxy cluster module 701 is used to receive the first collaborative note access request of the first client. The network proxy cluster includes M network proxy servers. The first collaborative note access request of the first client belongs to the application layer and uses the first collaborative note identifier as a request parameter. The network proxy cluster is a container cluster generated by the server container management system, and each network proxy server is used to run an instance that implements network proxying. The first collaborative note access request of the first client is distributed to one of the network proxy servers according to a polling strategy, which serves as the first network proxy server. The first network proxy server performs a hash operation on the request parameter to obtain a hash addressing routing identifier ID, and determines the corresponding upstream service endpoint address based on the pre-saved mapping relation table according to the hash addressing routing identifier ID. The first collaborative note access request of the first client is forwarded to the first upstream service server according to the upstream service endpoint address.

[0113] The upstream service cluster module 702 is used to obtain its own session state. The session state is the current overall content of the first collaborative note. The first collaborative note access request of the first client is executed according to the session state, and the execution result is returned to the first client through the first network proxy server. The first upstream service server is one of the business servers in the upstream service cluster that is used to implement the first collaborative note service. The upstream service cluster module is a container cluster generated by the server container management system, including N such business servers, and each of the business servers is used to run an instance that implements the upstream service.

[0114] In another embodiment, the network proxy cluster module 701 is further used for:

[0115] Receiving the first collaborative note access request of the second client. The first collaborative note access request of the second client belongs to the application layer and uses the first collaborative note identifier as a request parameter. The second client is different from the first client. The first collaborative note access request of the second client is distributed to one of the network proxy servers according to a polling strategy, and this network proxy server serves as the second network proxy server, which is different from the first network proxy server. A hash operation is performed on the request parameter to obtain a hash addressing routing identifier ID, and the corresponding upstream service endpoint address is determined based on the pre-saved mapping relation table according to the hash addressing routing identifier ID. The first collaborative note access request of the second client is forwarded to the first upstream service server according to the upstream service endpoint address. The mapping relation tables saved by the first network proxy server and the second network proxy server are the same. In the mapping relation table, the same hash addressing routing identifier ID corresponds to the same upstream service endpoint address, and the hash operation is a stable hash algorithm.

[0116] In another embodiment, the upstream service cluster module 702 is further used for:

[0117] The first upstream service server obtains its own session state, executes the first collaborative note access request of the second client according to the session state, and forwards the execution result to the second client through the second network proxy server.

[0118] In another embodiment, the device further includes: a monitor 703 (not shown in the figure), which is used to determine the surviving service servers as the surviving service servers through the API service management interface when the first preset time interval arrives, and obtain the upstream service endpoint addresses of the surviving service servers; the surviving service servers refer to the service servers of the normal running instances in the upstream service cluster; the monitor is generated by the server-side container management system and is used to monitor and manage the operation of the service servers; query the database according to the upstream service endpoint addresses of the surviving service servers to determine whether there is an invalid mapping relationship. If there is, delete the invalid mapping relationship, remap the hash addressing routing ID in the invalid mapping relationship to the upstream service endpoint address of the surviving service server, generate a new mapping relationship table, and replace the original mapping relationship table in the database; otherwise, do nothing.

[0119] In another embodiment, each network proxy server in the network proxy cluster module 701 obtains the mapping relationship table from the database when the second preset time interval arrives, and replaces its own original mapping relationship table with the newly obtained mapping relationship table.

[0120] Applying the solution of the embodiment of the present application, since the network proxy cluster includes multiple network proxy servers and the upstream service cluster includes multiple service servers, expansion is performed, and the bottlenecks in storage and performance can be avoided. At the same time, different network proxy servers accurately forward the access requests of different clients to the upstream service server where the same collaborative note is located through hash operations and the mapping relationship table, so as to achieve sticky access. In addition, the mapping relationship table can be automatically updated according to the service server status to ensure the effectiveness of the access to the collaborative note.

[0121] The embodiments of the present application further provide a computer-readable medium. The computer-readable storage medium stores instructions which, when executed by a processor, can execute the steps in the access method of the collaborative note as described above. In practical applications, the computer-readable medium may be included in the device / device / system described in the above embodiments, or may exist separately without being assembled into the device / device / system. The above computer-readable storage medium carries one or more programs which, when the above one or more programs are executed, can implement the access method of the collaborative note described in the above embodiments. According to the embodiments disclosed in the present application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: portable computer disks, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the above, but is not used to limit the scope of protection of the present application. In the embodiments disclosed in the present application, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program can be used by or combined with an instruction execution system, device, or device.

[0122] The embodiments of the present application further provide a computer program product. The computer program product includes computer instructions which, when executed by a processor, implement the method as described in any of the above embodiments.

[0123] The flowcharts and block diagrams in the drawings of the present application illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments disclosed in the present application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the above module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in the order marked in different drawings. For example, two consecutively represented blocks may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0124] Those skilled in the art will understand that the features recited in the various embodiments and / or claims of the present disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly recited in the present application. In particular, without departing from the spirit and teachings of the present application, the features recited in the various embodiments and / or claims of the present application can be combined and / or combined in various ways, and all such combinations and / or combinations fall within the scope disclosed in the present application.

[0125] In this article, specific embodiments are used to elaborate on the principles and implementation manners of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention, and is not used to limit the present application. For those skilled in the art, based on the idea, spirit and principle of the present invention, changes can be made in the specific implementation manner and application scope, and any modifications, equivalent replacements, improvements, etc. made by them should be included within the scope of protection of the present application.

Claims

1. A collaborative note access method, characterized in that: The method includes: A network proxy cluster in a server-side container management system receives a first collaborative note access request from a first client, the network proxy cluster includes M network proxy servers, the first collaborative note access request from the first client belongs to the application layer and takes a first collaborative note identifier as a request parameter, the network proxy cluster is a container cluster generated by the server-side container management system, wherein each of the network proxy servers is used to run an instance of a network proxy; The network proxy cluster distributes the first collaborative note access request of the first client to one of the network proxy servers as the first network proxy server according to a polling strategy; The first network proxy server performs a hash operation according to the request parameters to obtain a hash addressing routing identifier ID, and determines the corresponding upstream service endpoint address from the hash addressing routing identifier ID according to a pre-stored mapping relationship table, and forwards the first collaborative note access request of the first client to the first upstream business server according to the upstream service endpoint address. The first upstream business server is a business server in an upstream service cluster for implementing a first collaborative note business service. The upstream service cluster is a container cluster generated by the server-side container management system, including N business servers, each of which is used to run an instance that implements a collaborative note service; The first upstream business server obtains its own session state, which is the current overall content of the first collaborative note, executes the first collaborative note access request of the first client according to the session state, and returns the execution result to the first client through the first network proxy server.

2. The method according to claim 1, characterized in that The method further comprises: The network proxy cluster in the server-side container management system receives the first collaborative note access request from a second client, the first collaborative note access request from the second client belongs to the application layer and uses the first collaborative note identifier as a request parameter, and the second client is different from the first client; The network proxy cluster distributes the first collaborative note access request of the second client to one of the network proxy servers according to the polling strategy, and the network proxy server serves as a second network proxy server, and the second network proxy server is different from the first network proxy server; The second network proxy server performs a hash operation according to the request parameters to obtain the hash addressing routing identifier ID, and determines the corresponding upstream service endpoint address from the hash addressing routing identifier ID according to the mapping relationship table saved in advance, and forwards the first collaborative note access request of the second client to the first upstream business server according to the upstream service endpoint address. The mapping relationship table saved by the first network proxy server is the same as the mapping relationship table saved by the second network proxy server. In the mapping relationship table, the same hash addressing routing identifier ID corresponds to the same upstream service endpoint address, and the hash operation is a stable hash algorithm; The first upstream business server obtains the session state of itself, executes the first collaborative note access request of the second client according to the session state, and forwards the execution result to the second client through the second network proxy server.

3. The method according to claim 1 or 2, characterized in that: Before the step of receiving the first collaborative note access request from the first client by the network proxy cluster in the server-side container management system, the method further comprises: The server-side container management system generates a container cluster, including the network proxy cluster and the upstream service cluster, the network proxy cluster includes M network proxy servers, and the upstream service cluster includes N business servers for collaborative note-taking services; Allocating the upstream service endpoint addresses to the N business servers respectively, and determining the N upstream service endpoint addresses; Assigning the collaborative note identifiers to P collaborative notes respectively, and determining P collaborative note identifiers; Using the stable hash algorithm to perform hash operations on the P collaborative note identifiers one by one to determine the corresponding hash addressing routing ID; The hash addressing routing ID is mapped to the N upstream service endpoint addresses to form the mapping relationship table, which is stored in the database.

4. The method according to claim 3, characterized in that The method further comprises: When the first preset time interval arrives, the monitor in the server-side container management system determines the surviving business server through the API service management interface as the surviving business server, and obtains the upstream service endpoint address of the surviving business server; the surviving business server refers to the business server of the normally running instance in the upstream service cluster; the monitor is generated by the server-side container management system and is used to monitor and manage the operation of the business server; Query the database according to the upstream service endpoint address of the surviving business server to determine whether there is an invalid mapping relationship. If so, delete the invalid mapping relationship, remap the hash addressing routing ID in the invalid mapping relationship to the upstream service endpoint address of the surviving business server, generate a new mapping relationship table, and replace the original mapping relationship table in the database; otherwise, do nothing.

5. The method according to claim 3, characterized in that: When the second preset time interval is reached, each network proxy server in the network proxy cluster obtains the mapping relationship table from the database, and replaces its own original mapping relationship table with the newly obtained mapping relationship table.

6. The method according to claim 1, characterized in that The server-side container management system is deployed in the cloud and implemented by K8s; The network proxy cluster is implemented using the Pingora framework.

7. A collaborative note access device, characterized in that: The device includes: A network proxy cluster module is used to receive a first collaborative note access request from a first client, the network proxy cluster includes M network proxy servers, the first collaborative note access request from the first client belongs to the application layer and uses a first collaborative note identifier as a request parameter, the network proxy cluster is a container cluster generated by the server-side container management system, wherein each of the network proxy servers is used to run an instance of a network proxy; the first collaborative note access request from the first client is distributed to one of the network proxy servers as a first network proxy server according to a polling strategy; the first network proxy server performs a hash operation according to the request parameter to obtain a hash addressing routing identifier ID, and determines a corresponding upstream service endpoint address from the hash addressing routing identifier ID according to a pre-stored mapping relationship table, and forwards the first collaborative note access request from the first client to a first upstream business server according to the upstream service endpoint address; An upstream service cluster module is used to obtain its own session state, where the session state is the current overall content of the first collaborative note, execute the first collaborative note access request of the first client according to the session state, and return the execution result to the first client through the first network proxy server; the first upstream business server is a business server in the upstream service cluster for implementing the first collaborative note business service, and the upstream service cluster module is a container cluster generated by the server-side container management system, including N business servers, each of which is used to run an instance of the upstream service.

8. The device according to claim 7, characterized in that The network proxy cluster module is further used to receive the first collaborative note access request of the second client, the first collaborative note access request of the second client belongs to the application layer and takes the first collaborative note identifier as a request parameter, and the second client is different from the first client; distribute the first collaborative note access request of the second client to one of the network proxy servers according to the polling strategy, the network proxy server serves as the second network proxy server, and the second network proxy server is different from the first network proxy server; perform a hash operation according to the request parameter to obtain the hash addressing routing identifier ID, and determine the corresponding upstream service endpoint address by the hash addressing routing identifier ID according to the mapping relationship table saved in advance, and forward the first collaborative note access request of the second client to the first upstream service server according to the upstream service endpoint address, the mapping relationship table saved by the first network proxy server is the same as the mapping relationship table saved by the second network proxy server, in the mapping relationship table, the same hash addressing routing identifier ID corresponds to the same upstream service endpoint address, and the hash operation is a stable hash algorithm; The upstream service cluster module is also used for the first upstream business server to obtain its own session status, execute the first collaborative note access request of the second client according to the session status, and forward the execution result to the second client through the second network proxy server.

9. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the instructions are executed by the processor, the steps of the collaborative note access method described in any one of claims 1 to 6 can be implemented.

10. A computer program product, comprising computer instructions, which, when executed by a processor, implement the collaborative note access method as described in any one of claims 1 to 6.

Images