Protocol file updating method and device, computer readable medium and electronic device

Abstract

The application provides an updating method and device of a protocol file, a computer readable medium and an electronic device. The method comprises the following steps: pushing a target protocol file to a code warehouse, so that the code warehouse synchronizes the target protocol file to a protocol management center when detecting that the target protocol file has changed relative to a predetermined protocol file in the code warehouse; publishing first service code corresponding to the target protocol file to a production environment; after the first service code is published, sending first notification information to the protocol management center, and sending second notification information to an API gateway according to the first notification information, so that the API gateway acquires the target protocol file according to the second notification information and loads the target protocol file to a memory. The application can update the protocol file without restarting the API gateway, thereby reducing the time and labor cost, and can also make the version release iteration faster.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and more specifically, to a method, apparatus, computer-readable medium, and electronic device for updating protocol documents. Background Technology

[0002] An API gateway is an important component of the system architecture, which can use the service's protocol file to handle network requests for the service.

[0003] However, whenever the protocol file changes, the API gateway needs to be restarted manually, which takes a lot of time and manpower, reduces the speed of service version release and iteration, and thus increases the development cost of the project. Summary of the Invention

[0004] The embodiments of this application provide a method, apparatus, computer-readable medium, and electronic device for updating protocol files, which at least to some extent enables API gateways to update protocol files without restarting, thereby reducing the time and manpower overhead and enabling faster version release iterations.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to one aspect of the embodiments of this application, a method for updating a protocol file is provided. The method includes: pushing a target protocol file to a code repository, so that after receiving the target protocol file, the code repository performs change detection on the target protocol file, and if a change is detected in the target protocol file relative to a predetermined protocol file in the code repository, synchronizes the target protocol file to a protocol management center; publishing a first service code corresponding to the target protocol file to a production environment; after the first service code is published, sending a first notification message to the protocol management center, and the protocol management center sending a second notification message to an API gateway based on the first notification message, so that the API gateway obtains the target protocol file based on the second notification message and loads the target protocol file into memory.

[0007] According to one aspect of the embodiments of this application, a method for updating a protocol file is provided. The method is executed by an API gateway as described in the above embodiments. The method includes: when the API gateway starts, comparing a locally stored protocol file with a protocol file in a code repository to obtain information of a matching protocol file and / or information of a new version of the protocol file in the code repository; loading the matching protocol file into memory based on the information of the matching protocol file; and / or, pulling a new version of the protocol file from the code repository based on the information of the new version of the protocol file in the code repository, and loading the new version of the protocol file into memory.

[0008] According to one aspect of the embodiments of this application, a protocol file updating apparatus is provided. The apparatus includes: a file push unit, configured to push a target protocol file to a code repository, so that after receiving the target protocol file, the code repository performs change detection on the target protocol file, and if a change is detected in the target protocol file relative to a predetermined protocol file in the code repository, synchronizes the target protocol file to a protocol management center; a code publishing unit, configured to publish a first service code corresponding to the target protocol file to a production environment; and a notification sending unit, configured to send a first notification message to the protocol management center after the first service code is published, and the protocol management center sends a second notification message to an API gateway based on the first notification message, so that the API gateway obtains the target protocol file based on the second notification message and loads the target protocol file into memory.

[0009] In some embodiments of this application, based on the foregoing scheme, the code publishing unit is configured to: publish the first service code corresponding to the target protocol file to the production environment, so as to deploy the target service corresponding to the first service code in the production environment, and the API gateway is used to provide an access point for at least one service including the target service.

[0010] In some embodiments of this application, based on the foregoing scheme, the target protocol file includes request body structure information; the notification sending unit is configured to: send a first notification message to the protocol management center, and the protocol management center sends a second notification message to the API gateway based on the first notification message, so that the API gateway loads the target protocol file into memory based on the second notification message, and after receiving a target network request matching the target protocol file, encodes the request parameters in the target network request based on the request body structure information in the target protocol file, and sends the encoding result to the target service accessed by the target network request.

[0011] In some embodiments of this application, based on the foregoing scheme, the file push unit is configured to push a first service code including the target protocol file to a code repository, so that when the code repository detects that the target protocol file in the first service code has changed relative to the predetermined protocol file in the second service code, it will synchronize the target protocol file to the protocol management center, wherein the second service code is located in the code repository, and the second service code and the first service code are two adjacent versions of the target service.

[0012] In some embodiments of this application, based on the foregoing scheme, the change detection of the target protocol file includes: determining a first hash value of the target protocol file and a second hash value of a predetermined protocol file in the code repository based on a hash algorithm; if the first hash value is consistent with the second hash value, it is determined that the target protocol file has not been changed relative to the predetermined protocol file; if the first hash value is inconsistent with the second hash value, it is determined that the target protocol file has been changed relative to the predetermined protocol file.

[0013] According to one aspect of the embodiments of this application, a protocol file updating apparatus is provided. The apparatus is located in an API gateway as described in the above embodiments. The apparatus includes: a file comparison unit, configured to compare a locally stored protocol file with a protocol file in a code repository when the API gateway is started, to obtain information of a matching protocol file and / or information of a new version of the protocol file in the code repository; a file loading unit, configured to load the matching protocol file into memory based on the information of the matching protocol file; and / or a file fetching unit, configured to fetch a new version of the protocol file from the code repository based on the information of the new version of the protocol file in the code repository, and load the new version of the protocol file into memory.

[0014] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a path acquisition unit, a request body acquisition unit, a parameter encoding unit, and a result forwarding unit; the path acquisition unit is used to: when a network request is received, acquire the request path in the network request; the request body acquisition unit is used to: if it is determined that a protocol file matching the request path exists in a protocol file loaded in memory, acquire the request body structure information corresponding to the request path from the protocol file; the parameter encoding unit is used to: encode the request parameters in the network request according to the request body structure information; the result forwarding unit is used to: forward the encoding result to the target service accessed by the network request.

[0015] In some embodiments of this application, based on the foregoing scheme, the parameter encoding unit is configured to: for each request parameter in the network request, determine the type and sequence number information corresponding to the request parameter in the request body structure information; and for each request parameter in the network request, encode the request parameter according to the type and sequence number information corresponding to the request parameter.

[0016] In some embodiments of this application, based on the foregoing scheme, the device further includes a prompt information return unit; after obtaining the request path in the network request, the prompt information return unit is used to: if it is determined that there is no protocol file matching the request path in the protocol file loaded in memory, then return a prompt message indicating a path error to the sender of the network request.

[0017] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the protocol file update method as described in the above embodiments.

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the protocol file update method as described in the above embodiments.

[0019] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the protocol file update method as described in the above embodiments.

[0020] In some embodiments of this application, the target protocol file is first pushed to a code repository. Upon receiving the target protocol file, the code repository performs change detection. If a change is detected in the target protocol file relative to a predetermined protocol file in the code repository, the target protocol file is synchronized to the protocol management center. Then, the first service code corresponding to the target protocol file is published to the production environment. After the first service code is published, a first notification is sent to the protocol management center. The protocol management center then sends a second notification to the API gateway based on the first notification. The API gateway retrieves the target protocol file based on the received second notification and loads it into memory. Therefore, in the solution of this application embodiment, whenever a changed target protocol file is pushed to the code repository, the protocol management center can automatically obtain the synchronized target protocol file. Once the first service code corresponding to the target protocol file is published, the API gateway automatically receives the corresponding notification and retrieves the target protocol file based on the notification, loading it into memory after retrieval. Therefore, the solution in this application embodiment realizes hot loading of the protocol file. Whenever the protocol file changes, the changed protocol file can be loaded into memory without restarting the API gateway, thus updating the protocol file. In other words, memory can be updated while the API gateway is running, which can greatly save time and manpower, thereby reducing costs. It can also make service version releases and iterations faster, thereby verifying product features more quickly, reducing experimental costs, and increasing business revenue. In addition, the solution in this application embodiment can also shorten the startup time required for manual restart of the API gateway.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0023] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown;

[0024] Figure 2 A flowchart illustrating a method for updating a protocol file according to an embodiment of this application is shown;

[0025] Figure 3 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 210 in the embodiment;

[0026] Figure 4 A timing diagram of the overall scheme according to one embodiment of this application is shown;

[0027] Figure 5 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 220 in the embodiment;

[0028] Figure 6 A schematic diagram illustrating a user's request to open a page according to an embodiment of this application is shown;

[0029] Figure 7 A schematic diagram is shown of a page that issues a request to a service interface and a window displaying request information according to an embodiment of this application;

[0030] Figure 8 A schematic diagram is shown of a page that makes a request to a service interface according to an embodiment of this application and a display window that shows the request path;

[0031] Figure 9 A schematic diagram is shown of a page that makes a request to a service interface according to an embodiment of this application and a display window that displays the request parameters;

[0032] Figure 10 A flowchart illustrating a method for updating a protocol file according to another embodiment of this application is shown;

[0033] Figure 11 This illustration shows a flowchart of the process of loading a protocol file when an API gateway starts up, according to an embodiment of this application.

[0034] Figure 12 A flowchart illustrating an embodiment of the API gateway processing a network request is shown;

[0035] Figure 13 A schematic diagram illustrating the process of an API gateway converting an HTTP request according to a protocol file, according to an embodiment of this application, is shown.

[0036] Figure 14 An embodiment according to this application is shown. Figure 12 A flowchart detailing step 1230 in the embodiment;

[0037] Figure 15 A block diagram of a protocol document updating apparatus according to an embodiment of this application is shown;

[0038] Figure 16 A block diagram of a protocol file updating apparatus according to another embodiment of this application is shown;

[0039] Figure 17 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0040] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0041] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0042] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0043] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0044] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0045] In related technologies, most API gateways do not support hot reloading of protocol files. In addition, a very small number of API gateways pull protocol files from the code repository through scheduled tasks.

[0046] In addition, when the API gateway is manually restarted, the memory is cleared, and the API gateway will pull the protocol files from the code repository to the local machine, and then the API gateway will load the local protocol files.

[0047] However, the aforementioned technologies have the following drawbacks:

[0048] For API gateways that do not support hot-reloading protocol files, each change to the service's protocol file requires a manual restart of the API gateway, consuming significant time and wasting manpower. This slows down version release iterations and increases development costs. The excessive time consumption is due to the API gateway needing to handle all backend traffic entry points, necessitating a large number of deployed machines. If we calculate based on a 10-step service version canary release restart, with each step taking 10 minutes, this would add an extra 100 minutes to the overall time.

[0049] For API gateways that use scheduled tasks to pull code from the code repository, the timing of these tasks still has some error, affecting the real-time performance of service releases. If the scheduled task runs every 5 minutes, the service release will take an additional 5 minutes.

[0050] Furthermore, when the API gateway is manually restarted, the API gateway service will fetch all protocol files from the code repository to the local machine. This full fetch increases the network I / O overhead of the service, thereby reducing the API gateway's startup time. Fetching one protocol file to the local machine takes 50ms. Therefore, if the API gateway needs to fetch 100 protocol files during startup, manually restarting an API gateway machine will take an additional 5 seconds.

[0051] Therefore, this application first provides a method for updating protocol files. The method for updating protocol files provided in this application can overcome the above-mentioned shortcomings. It not only enables the API gateway to support hot reloading and eliminates scheduled tasks, ensuring high real-time performance and thus accelerating version release iterations and reducing development costs, but also effectively reduces the startup time of manually restarting the API gateway.

[0052] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown. For example... Figure 1As shown, the system architecture 100 may include a developer terminal 110, a cloud 120, a management center server 130, an intranet 140, and a user terminal 150. The intranet 140 specifically includes a gateway device 141, a first backend server 142, a second backend server 143, and a third backend server 143. A code editor is deployed on the developer terminal 110, a code repository is deployed on the cloud 120, a protocol management center is deployed on the management center server 130, a client (browser) runs on the user terminal 150, an API gateway is deployed on the gateway device 141, and each backend server deploys a backend service. The backend services deployed on different backend servers are different; for example, the first backend server 142 may deploy backend service A, the second backend server 143 may deploy backend service B, and the third backend server 143 may deploy backend service C. When the protocol file update method provided in this embodiment is applied... Figure 1 In the system architecture shown, a process can be as follows: First, developers use the code editor deployed on developer terminal 110 to develop a new version of the backend service A's code and push it to the code repository on cloud 120 for storage. Then, the code repository identifies the updated target protocol file in the new version of the backend service A's code and synchronizes the target protocol file to the protocol management center on management center server 130. Next, developer terminal 110 publishes the new version of the backend service A's code to the production environment of the first backend server 142. After the new version of the backend service A's code is published, the new backend service A is deployed on the first backend server 142, and developer terminal 110 sends a first notification message to the protocol management center on management center server 130. Then, the protocol management center on management center server 130 sends a second notification message to the API gateway on gateway device 141 based on the received first notification message. The API gateway retrieves the target protocol file from the protocol management center based on the second notification message and loads the target protocol file into the memory of its gateway device 141.

[0053] In some embodiments of this application, the new version code of backend service A is the code of the feature branch, the code repository stores the code of the main branch, the feature branch is further developed based on the code of the main branch pulled from the code repository, and after the new version code of backend service A is pushed to the code repository, it will be merged into the main branch.

[0054] In some embodiments of this application, the code repository stores an old version of the code for backend service A. The code repository determines that the new version of the code for backend service A contains an updated target protocol file by comparing it with the old version of the code for backend service A.

[0055] In some embodiments of this application, the new version code of backend service A is the code saved to the code repository by the developer terminal 110 through a code submission operation, and the old version code of backend service A and the new version code of backend service A are two versions of code before and after the code submission.

[0056] In some embodiments of this application, the new version code of backend service A is the code of the new version of backend service A released in a canary release.

[0057] It should be understood that Figure 1 The number of terminals and servers shown is merely illustrative. Depending on implementation needs, there can be any number of user terminals and developer terminals, and the number of backend servers within the intranet can also be arbitrary. Furthermore, the actual number of machines included in each type of device can also be arbitrary. That is, there can be a much larger number of user terminals and developer terminals. The management center server and each backend server can be a server cluster consisting of multiple servers, or multiple gateway devices can be set up for deploying API gateways.

[0058] It should be noted that, Figure 1 The illustration shown is merely one embodiment of this application. Although in Figure 1 In the embodiments of this application, both the user terminal and the developer terminal are desktop computers. However, in other embodiments of this application, the user terminal and the developer terminal can also be various types of terminal devices such as smartphones, laptops, tablets, in-vehicle terminals, portable wearable devices, and workstations. Figure 1 In the embodiment, the code repository is deployed in the cloud, while the protocol management center is deployed on a management center server. However, in other embodiments of this application, the deployment locations of both can be arbitrary, and they can be deployed in the same location. For example, the code repository and the protocol management center can be deployed simultaneously in the cloud, with the protocol management center deployed in the cloud while the code repository may not be deployed in the cloud. Although in Figure 1 In the embodiment, the API gateway loads only one protocol file, but in other embodiments of this application, the API gateway can load multiple protocol files; although in Figure 1 In the embodiment, only one backend service is deployed on each backend server, but in other embodiments of this application, multiple backend services can be deployed on a single backend server simultaneously; although Figure 1 The solutions in this embodiment are primarily applied to scenarios involving version updates of an already deployed backend service A. However, in other embodiments of this application, they can also be applied to other scenarios, such as the initial deployment of a backend service. This application does not limit these scenarios in any way, and the scope of protection of this application should not be restricted as a result.

[0059] As is readily understood, the protocol file update method provided in this application embodiment is generally executed by a server, and correspondingly, the protocol file update device is generally located in the server. However, in other embodiments of this application, the terminal device may also have similar functions to the server, thereby executing the protocol file update scheme provided in this application embodiment.

[0060] Therefore, the embodiments of this application can be applied to terminals or servers. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions.

[0061] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0062] Figure 2 A flowchart illustrating a method for updating a protocol file according to an embodiment of this application is shown. This method can be executed by various devices with processing and computing capabilities. Specifically, it can be executed by a target device, such as a user terminal or a cloud server. User terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle terminals, aircraft, smartwatches, etc. For example, the target device can be a developer terminal used by developers. Please refer to... Figure 2 As shown, the method for updating this protocol file includes at least the following steps:

[0063] In step 210, the target protocol file is pushed to the code repository so that after receiving the target protocol file, the code repository can perform change detection on the target protocol file and synchronize the target protocol file to the protocol management center if it detects that the target protocol file has changed relative to the predetermined protocol file in the code repository.

[0064] A code repository is where service code is stored. You can upload local service code to a code repository, or download service code from a code repository to your local machine. The code repository stores a record of each code commit, allowing you to compare your local service code with the corresponding code in the repository using commit history and other information, thus ensuring your local service code is up-to-date. A code repository can be, for example, a version control system (such as Git or SVN). An API gateway is also a service, and the service code for API gateways and various other services can be stored in a code repository.

[0065] A protocol file is a file that defines how data is serialized. Generally, two services need to define their serialization methods through a protocol file to communicate. For example, an API gateway needs to use the protocol files corresponding to each service to communicate with each service.

[0066] The developer terminal can push the modified target protocol file to the code repository. Before pushing the target protocol file, it may not already exist in the code repository. After pushing it, the code repository will store the target protocol file for the first time; at this point, the target protocol file is the first protocol file updated (generated) in the code repository. The pre-defined protocol file and the target protocol file can be two versions of the protocol file, one before and one after the change. The target protocol file can be the new version of the protocol file. Before pushing this new version of the protocol file to the code repository, the pre-defined protocol file (the old version) may already exist in the code repository. The code repository can detect whether the target protocol file has changed relative to the pre-defined protocol file in the code repository by comparing the new version of the protocol file with the old version. The target protocol file can be a new version of the protocol file obtained by updating or modifying the pre-defined protocol file.

[0067] When the code repository detects that the target protocol file is an updated protocol file, it will synchronize it to the protocol management center. After obtaining the target protocol file synchronized from the code repository, the protocol management center can store the target protocol file.

[0068] The Protocol Management Center is used to manage protocol files, which store the protocol files required for communication between all services.

[0069] In one embodiment of this application, the change detection of the target protocol file includes: determining a first hash value of the target protocol file and a second hash value of a predetermined protocol file in the code repository based on a hash algorithm; if the first hash value is consistent with the second hash value, it is determined that the target protocol file has not been changed relative to the predetermined protocol file; if the first hash value is inconsistent with the second hash value, it is determined that the target protocol file has been changed relative to the predetermined protocol file.

[0070] A hash algorithm is an algorithm that converts an input of arbitrary length into a fixed-length output using a hash function. The hash algorithm used in this application's embodiments may be MD5, SHA-256, etc.

[0071] Figure 3 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 210 in the embodiment. Please refer to [link / reference]. Figure 3 As shown, the target protocol file is pushed to the code repository so that after receiving the target protocol file, the code repository performs change detection on the target protocol file. If a change is detected in the target protocol file relative to a predetermined protocol file in the code repository, the target protocol file is synchronized to the protocol management center. Specifically, this may include the following steps:

[0072] In step 210', a first service code including the target protocol file is pushed to a code repository, so that when the code repository detects that the target protocol file in the first service code has changed relative to the predetermined protocol file in the second service code, it will synchronize the target protocol file to the protocol management center. The second service code is located in the code repository, and the second service code and the first service code are two adjacent versions of the target service.

[0073] After receiving the first service code, the code repository will identify that the target protocol file has been updated based on the detection that the target protocol file in the first service code has changed compared to the predetermined protocol file in the second service code.

[0074] Specifically, the first service code may include the target protocol file or other code files. The second service code may be an older version of the target service, with version number V1.0; the first service code may be a newer version of the target service, with version number V1.1. The second service code may be service code that the code repository obtained before receiving the first service code.

[0075] Both the pre-arranged agreement document and the target agreement document can be agreement documents for the target agreement.

[0076] Both the second service code and the first service code may include the protocol file of the target protocol and other code files. The protocol file of the target protocol in the second service code is a pre-defined protocol file, which may be the protocol file of an older version of the target protocol. The protocol file of the target protocol in the first service code is a target protocol file, which may be the protocol file of a newer version of the target protocol. The code repository can determine whether the target protocol file in the first service code has changed relative to the pre-defined protocol file in the second service code by comparing the protocol file of the target protocol in the second service code with the protocol file of the target protocol in the first service code.

[0077] Of course, the target protocol file may not exist in the second service code. In this case, the target protocol file in the first service code can be a protocol file for a protocol that is added for the first time for the target service.

[0078] Both the second service code and the first service code can include multiple protocol files. The code repository can compare corresponding (e.g., files with the same name) protocol files based on information such as the names of the protocol files in the second service code and the first service code, and then identify the target protocol file that has been updated.

[0079] Compared to the second service code, the first service code may have changes in other code files besides the target protocol file. The code repository will only synchronize the protocol files (such as the target protocol file) that have been detected to have changed to the protocol management center.

[0080] Figure 4 A timing diagram of the overall scheme according to one embodiment of this application is shown. Please refer to... Figure 4 As shown, this sequence diagram involves four entities: local service code, code repository, protocol management center, and API gateway. Among them, local service code refers to the service code developed locally on the developer's terminal.

[0081] like Figure 4 As shown, the specific process is as follows: First, the protocol file for the local service code is updated, and the updated protocol file is pushed to the code repository; then, after the code repository detects that the updated protocol file has been updated, it will synchronize and update it to the protocol management center.

[0082] In step 220, the first service code corresponding to the target protocol file is published to the production environment.

[0083] The first service code corresponding to the target protocol file can be a first service code that includes the target protocol file. The correspondence between the target protocol file and the first service code means that the target protocol file is required for communication with the service formed after the first service code is deployed.

[0084] The production environment, as opposed to the development and testing environment, is the formal environment in which software or services are finally deployed and provided to the outside world. It is the final environment that users actually use and rely on. The production environment may include, for example, the servers where the service is deployed.

[0085] In one embodiment of this application, publishing the first service code corresponding to the target protocol file to the production environment includes: after receiving a notification message from the code repository indicating that the target protocol file has been successfully synchronized, publishing the first service code corresponding to the target protocol file to the production environment, wherein the notification message indicating that the target protocol file has been successfully synchronized is obtained and forwarded by the code repository from the protocol management center.

[0086] Please continue reading Figure 4 As shown, when the protocol management center successfully obtains the protocol file synchronized and updated by the code repository, it will generate a notification message to indicate that the protocol file has been successfully synchronized and send the notification message to the code repository, which will then forward it to the developer terminal.

[0087] In this embodiment of the application, by publishing the first service code corresponding to the target protocol file to the production environment only after receiving the notification information returned by the code repository indicating that the target protocol file has been successfully synchronized, the problem of the API gateway being unable to load the target protocol file due to the failure of the target protocol file synchronization can be avoided, ensuring that the API gateway can successfully obtain and load the target protocol file.

[0088] Please continue reading Figure 4 As shown, after receiving a notification from the code repository indicating that the target protocol file has been successfully synchronized, the local service code will be deployed to the production environment.

[0089] Figure 5 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 220 in the embodiment is provided. Please refer to [link / reference]. Figure 5 As shown, deploying the first service code corresponding to the target protocol file to the production environment may specifically include the following steps:

[0090] In step 220', the first service code corresponding to the target protocol file is published to the production environment so as to deploy the target service corresponding to the first service code in the production environment. The API gateway is used to provide an access point for at least one service, including the target service.

[0091] By building, deploying, and configuring the first service code, a target service can be obtained and deployed in the production environment. The target service is the instantiated form of the first service code after it runs in the production environment, and it can receive and respond to external requests. The API gateway can provide access points for the target service and one or more other services.

[0092] In step 230, after the first service code is published, a first notification message is sent to the protocol management center, and the protocol management center sends a second notification message to the API gateway based on the first notification message, so that the API gateway can obtain the target protocol file based on the second notification message and load the target protocol file into memory.

[0093] Once the first service code is successfully deployed to the production environment, the developer's terminal will send a first notification message to the protocol management center. This first notification message may include information related to the target protocol file, such as the file path and file name. The protocol management center can then generate a second notification message based on the first notification message and send it to the API gateway. The second notification message can have the same content as the first notification message; for example, it may also include information related to the target protocol file, such as the file path and file name. The second notification message can be used to notify the API gateway that a new protocol file needs to be updated.

[0094] Therefore, in this embodiment, after the first service code is released to the production environment, the protocol management center notifies the API gateway immediately, instead of the API gateway comparing whether the protocol file has changed through a scheduled task, so the real-time performance is better guaranteed.

[0095] In one embodiment of this application, the step of sending a first notification message to the protocol management center, and having the protocol management center send a second notification message to the API gateway based on the first notification message, so that the API gateway can obtain the target protocol file based on the second notification message, includes: sending a first notification message to the protocol management center, and having the protocol management center send a second notification message to the API gateway based on the first notification message, so that the API gateway can obtain the target protocol file from the protocol management center based on the second notification message.

[0096] Since the protocol management center has already obtained the target protocol file, the API gateway can directly obtain the target protocol file from the protocol management center. Of course, in other embodiments of this application, the API gateway can also obtain the target protocol file from other locations such as code repositories.

[0097] Please continue reading Figure 4 As shown, after the local service code is deployed to the production environment, the developer terminal will notify the protocol management center. Then, the protocol management center will notify the API gateway that there is a new protocol file that needs to be updated. Next, the API gateway will load the corresponding protocol file into memory according to the received notification. When the API gateway successfully completes the loading of the protocol file, it will return the corresponding response information to the protocol management center, which will forward the received response information to the developer terminal.

[0098] The API gateway loads the target protocol file into memory and also stores it locally (such as on a local disk). The API gateway's local storage contains the protocol files required to communicate with one or more services, including the target service.

[0099] After the API gateway loads the target protocol file into memory, when the API gateway restarts, it compares the locally stored protocol file with the protocol file in the code repository to obtain information about the matching protocol file and / or the information about the new version of the protocol file in the code repository. Then, if the information about the matching protocol file is obtained, the API gateway loads the corresponding locally stored protocol file into memory; if the information about the new version of the protocol file is obtained from the code repository, the API gateway pulls the new version of the protocol file from the code repository based on the information about the new version of the protocol file and loads the new version of the protocol file into memory.

[0100] The advantage of doing this is that it reduces the startup time required to restart the API gateway.

[0101] It's easy to understand that the versions of protocol files and other code files in a code repository are usually the latest. Therefore, the information of a new version of a protocol file in a code repository can be the information of the latest version of the protocol file in the code repository.

[0102] Specifically, if there is only one protocol file stored locally, the comparison result can be information about the matching protocol file or information about the new version of the protocol file in the code repository. If there are multiple protocol files stored locally, for each protocol file, the comparison result can be information about the matching protocol file or information about the new version of the protocol file in the code repository. Therefore, for multiple protocol files stored locally, the comparison result obtained by comparing them with the corresponding protocol files in the code repository can include only information about the matching protocol file, only information about the new version of the protocol file in the code repository, or both information about the matching protocol file and information about the new version of the protocol file in the code repository.

[0103] In one embodiment of this application, the target protocol file includes request body structure information; the step of sending a first notification message to the protocol management center, and the protocol management center sending a second notification message to the API gateway based on the first notification message, so that the API gateway obtains the target protocol file based on the second notification message and loads the target protocol file into memory, includes: sending a first notification message to the protocol management center, and the protocol management center sending a second notification message to the API gateway based on the first notification message, so that the API gateway loads the target protocol file into memory based on the second notification message, and after receiving a target network request matching the target protocol file, encoding the request parameters in the target network request based on the request body structure information in the target protocol file, and sending the encoding result to the target service accessed by the target network request.

[0104] The target network request may include the target request path; the API gateway may determine that the target network request matches the target protocol file if it determines that the target protocol file matches the target request path in the target network request.

[0105] The request body structure information is the information on which the API gateway encodes the request parameters in the target network request when it receives a target network request including the target request path; the target request path is the request path that matches the target protocol file; the API gateway is also used to send the encoding result to the target service requested to be accessed by the target request path after encoding the request parameters in the target network request.

[0106] The target protocol file can be in formats such as protobuf or jce. Taking a protobuf target protocol file as an example, the target protocol file can include information such as the interface name and the interface request body structure. The interface can be the interface provided by the target service. The interface name can include package, service, and method. The package is used to organize related interfaces by function or business module. The service is a stateless service layer that abstracts business rules and processes. The method defines the specific operations provided by the service. The interface request body structure information is the message type, which is the definition of the structured data model.

[0107] The target network request can be an HTTP request, and the API gateway can be located within an intranet, such as an internal system. Therefore, the API gateway can be a service connecting the intranet and the internet, and also a unified entry point for external access to the intranet. The API gateway can request the corresponding intranet service based on the request information. Since the communication protocols used by the internet and the intranet are different, the API gateway needs to perform protocol conversion, which requires the use of protocol files.

[0108] Figure 6 A schematic diagram illustrating a user's request to open a page according to an embodiment of this application is shown. See also... Figure 6 As shown, when a user opens a page through a browser, the browser sends an HTTP request to the API gateway. The API gateway converts the HTTP request parameters into internal protocol request parameters and passes the converted request parameters to the service interface on the intranet.

[0109] The reason for performing protocol conversion of request parameters is that the transmission efficiency of HTTP request parameters is low and it is not suitable for direct transmission within the internal system.

[0110] For example, the JSON request parameters carried in an HTTP request can be:

[0111] {

[0112] "category_id":"PC002409XXXXXXXXX",

[0113] "spu_id":"PC012409273XXXXXXXXX",

[0114] }

[0115] These request parameters are encoded into an unreadable byte stream by the API Gateway, but with a higher compression ratio.

[0116] Figure 7A schematic diagram is shown illustrating a page for issuing a request to a service interface and a window displaying request information according to an embodiment of this application. Please refer to... Figure 7 As shown, the left side displays the system's front-end page, through which users can send requests to intranet service interfaces by interacting with the front-end page; the right side displays the developer tools window, which shows the request information corresponding to the requests sent when interacting with the left-side page. This request information can be rendered and displayed to the user.

[0117] Figure 8 A schematic diagram is shown illustrating a page that issues a request to a service interface according to an embodiment of this application and a display window showing the request path. Please refer to... Figure 8 As shown, the dotted line in the right window represents the request path, which includes packages, services, and methods. Among them, trpc.com...XXade is the package, query..._category_spu is the method, and fuact_mall_XX_service is the service.

[0118] Figure 9 A schematic diagram is shown illustrating a page for issuing a request to a service interface according to an embodiment of this application and a display window showing the request parameters. Please refer to... Figure 9 As shown, it displays two request parameters, with fields "category_id" and "spu_id" respectively.

[0119] Figure 10 A flowchart illustrating a method for updating a protocol file according to another embodiment of this application is shown. Figure 10 The steps in the illustrated embodiment may be in Figure 2 The steps in the illustrated embodiment are performed before, or can be performed after, the steps in the illustrated embodiment. Figure 2 The steps shown in the embodiment are executed afterward and can be applied to... Figure 2 The API gateway in the embodiments, that is, the API gateway that can be executed by the API gateway in the above embodiments, please refer to [link to documentation]. Figure 10 As shown, the method for updating this protocol file may specifically include the following steps:

[0120] In step 1010, when the API gateway starts, the locally stored protocol file is compared with the protocol file in the code repository to obtain information of the matching protocol file and / or information of the new version of the protocol file in the code repository.

[0121] The API gateway can be started manually by designated personnel. It can also be restarted.

[0122] The information in the protocol file may include the protocol file name, version number, and of course, storage path.

[0123] When multiple protocol files exist in local storage, all protocol files in local storage need to be compared with all protocol files that the API gateway should load in the code repository. All protocol files that the API gateway should load in the code repository are the protocol files required for the API gateway to communicate with the service provided by the API gateway.

[0124] When multiple protocol files exist in local storage, the API gateway will compare the content of each locally stored protocol file with the protocol files in the code repository that match the information of that protocol file, based on information such as the name of the protocol file.

[0125] The code repository can store protocol files of various versions. You can compare the locally stored protocol file with the latest version of the protocol file in the code repository. If the comparison is consistent, it means that the locally stored protocol file is the latest version of the protocol file. If the comparison is inconsistent, it means that there is a newer version of the protocol file in the code repository.

[0126] Figure 11 A schematic diagram illustrating the process of loading protocol files upon startup of an API gateway according to an embodiment of this application is shown. Please refer to... Figure 11 As shown, the specific steps include:

[0127] Step 1110: Start the API gateway.

[0128] Step 1120: Compare with the code repository. Has the protocol file been updated?

[0129] Compare the local protocol file with the corresponding protocol file in the code repository to determine if there are any differences. If there are, proceed to step 1130; otherwise, proceed to step 1140.

[0130] If the information obtained is a matching protocol file, step 1020 needs to be executed; if the information obtained is a new version of the protocol file in the code repository, step 1030 needs to be executed.

[0131] Therefore, after step 1010 is executed, at least one of steps 1020 and 1030 can be executed. When both steps 1020 and 1030 need to be executed, the execution order of the two steps can be adjusted arbitrarily. That is, step 1020 can be executed first and then step 1030 can be executed, or step 1030 can be executed first and then step 1020 can be executed. The two steps can even be executed simultaneously.

[0132] In step 1020, the matched protocol file is loaded into memory based on the information of the matched protocol file.

[0133] Based on the information from the matching protocol files, the corresponding protocol files stored locally are loaded into memory.

[0134] In step 1030, based on the information of the new version of the protocol file in the code repository, the new version of the protocol file is pulled from the code repository and loaded into memory.

[0135] If the comparison is inconsistent, it means that there is an updated protocol file in the code repository, and the updated protocol file is the latest version of the protocol file. It is necessary to pull the protocol file from the code repository and load it into memory.

[0136] Please continue reading Figure 11 As shown, the following steps are included after step 1120:

[0137] Step 1130: Pull the change agreement file from the code repository to your local machine.

[0138] After completing this step, proceed to step 1140.

[0139] Step 1140: Load the protocol file into memory.

[0140] Load the protocol file into memory.

[0141] Figure 12 A flowchart illustrating an embodiment of the API gateway processing network requests according to this application is shown. See also... Figure 12 As shown, the method for updating this protocol file may also include the following steps:

[0142] In step 1210, when a network request is received, the request path in the network request is obtained.

[0143] A network request can be an HTTP request. The request path in a network request can include packets, services, and methods. Network requests can be sent from a user terminal.

[0144] In step 1220, if it is determined that a protocol file matching the request path exists in the protocol file loaded in memory, then the request body structure information corresponding to the request path is obtained from the protocol file.

[0145] Before performing this step, it is necessary to determine whether a protocol file matching the request path exists in the protocol file loaded in memory.

[0146] The protocol file may include the name of the interface and the request body structure information of the interface. The name of the interface may include the package, service and method, and the request body structure information may correspond to the method.

[0147] The request path also includes packages, services, and methods. Therefore, the protocol file that matches the request path can be found by matching the packages, services, and methods in the request path with the names of the interfaces in the protocol file. Then, based on the methods in the request path, the request body structure information corresponding to the methods in the request path can be found in the request body structure information of each request path, and this information is used as the request body structure information corresponding to the request path.

[0148] In one embodiment of this application, after obtaining the request path in the network request, the method may further include the following steps: if it is determined that there is no protocol file matching the request path in the protocol file loaded in memory, then a prompt message indicating a path error is returned to the sender of the network request.

[0149] If a protocol file matching the requested path does not exist in memory, a message indicating a path error is returned to the sender of the network request (i.e., the user terminal).

[0150] Figure 13 This diagram illustrates a process of an API gateway translating an HTTP request according to a protocol file, based on an embodiment of this application. Please refer to... Figure 13 As shown, the specific process includes the following:

[0151] Step 1310, HTTP request.

[0152] The API gateway received an HTTP request.

[0153] Step 1320: Does the API gateway have this request path?

[0154] The API gateway determines whether a protocol file matching the request path of the HTTP request exists in the local memory; if yes, proceed to step 1330; otherwise, proceed to step 1360.

[0155] When an API gateway is running, it actually stores a mapping in memory between request paths and request structures (i.e., request body structure information). This step is essentially the API gateway checking whether the request path is valid.

[0156] Step 1330: Locate the request structure based on the request path.

[0157] The API gateway obtains the corresponding request body structure information, i.e., the message type, based on the request path.

[0158] In step 1230, the request parameters in the network request are encoded according to the request body structure information.

[0159] Figure 14 An embodiment according to this application is shown. Figure 12 A flowchart detailing step 1230 in the embodiment is provided. Please refer to [link / reference]. Figure 14 As shown, encoding the request parameters in the network request based on the request body structure information can specifically include the following steps:

[0160] In step 1231, for each request parameter in the network request, the type and sequence number information corresponding to the request parameter in the request body structure information are determined.

[0161] The request body structure information can take the following form:

[0162] message QueryGoodsSkuListByCategorySpuReq{

[0163] string category_id = 1; / / Category ID

[0164] string spu_id = 2; / / SPU ID

[0165] }

[0166] In this structure, QueryGoodsSkuListByCategorySpuReq is the name of the data structure, string is the type, category_id and spu_id are the fields, and 1 and 2 are the sequence numbers. The sequence number is the tag, which is a unique identifier for the field and is used for field matching during binary encoding.

[0167] For each request parameter in a network request, the type and sequence number information corresponding to the field of that request parameter will be found in the request body structure information, and used as the type and sequence number information corresponding to that request parameter.

[0168] For example, the category_id field in the HTTP request parameter JSON corresponds to the category_id field in the protocol file.

[0169] In step 1232, for each request parameter in the network request, the request parameter is encoded according to the type and sequence number information corresponding to the request parameter.

[0170] The aforementioned request parameter "PC002409XXXXXXXXX" will be encoded according to the string type of protobuf and the sequence number 1.

[0171] In step 1240, the encoding result is forwarded to the target service accessed by the network request.

[0172] A new interface request is generated based on the encoding result, and the interface request is sent to the target service accessed by the network request.

[0173] Please continue reading Figure 13 As shown, after step 1330, the following steps may also be included:

[0174] Step 1340: Encode the request parameters according to the request structure.

[0175] The API gateway encodes request parameters based on the message type.

[0176] Step 1350: Transmit the encoding result to the downstream.

[0177] An interface request is generated based on the encoded request parameters, and the interface request is forwarded to the downstream actual service.

[0178] Step 1360, path error returned.

[0179] Returns a path error message to the requester.

[0180] In summary, the protocol file update method provided in the embodiments of this application not only enables the API gateway to support hot reloading and has high real-time version release, thereby accelerating the iteration speed of version release, reducing development costs, but also reduces the startup time of manual restart of the API gateway.

[0181] The following describes an apparatus embodiment of this application, which can be used to execute the protocol file update method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the protocol file update method described above.

[0182] Figure 15 A block diagram of a protocol document updating apparatus according to an embodiment of this application is shown. (Refer to...) Figure 15As shown, a protocol file updating apparatus 1500 according to an embodiment of this application includes: a file push unit 1510, a code publishing unit 1520, and a notification sending unit 1530. The file push unit 1510 pushes a target protocol file to a code repository, so that after receiving the target protocol file, the code repository performs change detection on the target protocol file, and if a change is detected in the target protocol file relative to a predetermined protocol file in the code repository, synchronizes the target protocol file to a protocol management center. The code publishing unit 1520 publishes the first service code corresponding to the target protocol file to the production environment. The notification sending unit 1530, after the first service code is published, sends a first notification message to the protocol management center, and the protocol management center sends a second notification message to the API gateway based on the first notification message, so that the API gateway obtains the target protocol file based on the second notification message and loads the target protocol file into memory.

[0183] In some embodiments of this application, based on the foregoing scheme, the code publishing unit 1520 is configured to: publish the first service code corresponding to the target protocol file to the production environment, so as to deploy the target service corresponding to the first service code in the production environment, and the API gateway is used to provide an access point for at least one service including the target service.

[0184] In some embodiments of this application, based on the foregoing scheme, the target protocol file includes request body structure information; the notification sending unit 1530 is configured to: send a first notification message to the protocol management center, and the protocol management center sends a second notification message to the API gateway according to the first notification message, so that the API gateway loads the target protocol file into memory according to the second notification message, and after receiving a target network request matching the target protocol file, encodes the request parameters in the target network request based on the request body structure information in the target protocol file, and sends the encoding result to the target service accessed by the target network request.

[0185] In some embodiments of this application, based on the foregoing scheme, the file push unit 1510 is configured to push a first service code including the target protocol file to a code repository, so that when the code repository detects that the target protocol file in the first service code has changed relative to the predetermined protocol file in the second service code, it will synchronize the target protocol file to the protocol management center, wherein the second service code is located in the code repository, and the second service code and the first service code are two adjacent versions of the target service.

[0186] In some embodiments of this application, based on the foregoing scheme, the change detection of the target protocol file includes: determining a first hash value of the target protocol file and a second hash value of a predetermined protocol file in the code repository based on a hash algorithm; if the first hash value is consistent with the second hash value, it is determined that the target protocol file has not been changed relative to the predetermined protocol file; if the first hash value is inconsistent with the second hash value, it is determined that the target protocol file has been changed relative to the predetermined protocol file.

[0187] Figure 16 A block diagram of a protocol file updating apparatus according to another embodiment of this application is shown. (Refer to...) Figure 16 As shown, a protocol file updating apparatus 1600 according to another embodiment of this application is located in the API gateway as described in the above embodiments. The apparatus includes: a file comparison unit 1610, a file loading unit 1620, and / or a file retrieval unit 1630. The file comparison unit 1610 is used to compare locally stored protocol files with protocol files in a code repository when the API gateway starts, obtaining information about the matching protocol files and / or information about a new version of the protocol files in the code repository. The file loading unit 1620 is used to load the matching protocol files into memory based on the information about the matching protocol files. The file retrieval unit 1630 is used to retrieve a new version of the protocol files from the code repository based on the information about the new version of the protocol files in the code repository, and load the new version of the protocol files into memory.

[0188] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a path acquisition unit, a request body acquisition unit, a parameter encoding unit, and a result forwarding unit; the path acquisition unit is used to: when a network request is received, acquire the request path in the network request; the request body acquisition unit is used to: if it is determined that a protocol file matching the request path exists in a protocol file loaded in memory, acquire the request body structure information corresponding to the request path from the protocol file; the parameter encoding unit is used to: encode the request parameters in the network request according to the request body structure information; the result forwarding unit is used to: forward the encoding result to the target service accessed by the network request.

[0189] In some embodiments of this application, based on the foregoing scheme, the parameter encoding unit is configured to: for each request parameter in the network request, determine the type and sequence number information corresponding to the request parameter in the request body structure information; and for each request parameter in the network request, encode the request parameter according to the type and sequence number information corresponding to the request parameter.

[0190] In some embodiments of this application, based on the foregoing scheme, the device further includes a prompt information return unit; after obtaining the request path in the network request, the prompt information return unit is used to: if it is determined that there is no protocol file matching the request path in the protocol file loaded in memory, then return a prompt message indicating a path error to the sender of the network request.

[0191] Figure 17 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0192] It should be noted that, Figure 17 The computer system 1700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0193] like Figure 17 As shown, the computer system 1700 includes a Central Processing Unit (CPU) 1701, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1702 or programs loaded from storage portion 1708 into Random Access Memory (RAM) 1703, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1703. The CPU 1701, ROM 1702, and RAM 1703 are interconnected via bus 1704. An Input / Output (I / O) interface 1705 is also connected to bus 1704.

[0194] The following components are connected to I / O interface 1705: an input section 1706 including a keyboard, mouse, etc.; an output section 1707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1708 including a hard disk, etc.; and a communication section 1709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1709 performs communication processing via a network such as the Internet. Drive 1710 is also connected to I / O interface 1705 as needed. Removable media 1711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1710 as needed so that computer programs read from them can be installed into storage section 1708 as needed.

[0195] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1709, and / or installed from removable medium 1711. When the computer program is executed by central processing unit (CPU) 1701, it performs various functions defined in the system of this application.

[0196] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0197] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0198] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0199] In one aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0200] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0201] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0202] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0203] The data collection and processing plan outlined in this application must be implemented in strict accordance with the requirements of relevant national laws and regulations, obtaining the informed consent or separate consent of the data subject (or having a legal basis as stipulated by the relevant national laws and regulations), and conducting subsequent data use and processing within the scope authorized by laws and regulations and the data subject.

[0204] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for updating a protocol file, characterized in that, The method includes: The target protocol file is pushed to the code repository so that after receiving the target protocol file, the code repository can perform change detection on the target protocol file and synchronize the target protocol file to the protocol management center if it detects that the target protocol file has changed relative to the predetermined protocol file in the code repository. Deploy the first service code corresponding to the target protocol file to the production environment; After the first service code is published, a first notification message is sent to the protocol management center. The protocol management center then sends a second notification message to the API gateway based on the first notification message, so that the API gateway can obtain the target protocol file based on the second notification message and load the target protocol file into memory.

2. The method for updating the protocol file according to claim 1, characterized in that, The step of deploying the first service code corresponding to the target protocol file to the production environment includes: The first service code corresponding to the target protocol file is published to the production environment to deploy the target service corresponding to the first service code in the production environment. The API gateway is used to provide an access point for at least one service, including the target service.

3. The method for updating the protocol file according to claim 1, characterized in that, The target protocol file includes request body structure information; the step of sending a first notification message to the protocol management center, and the protocol management center sending a second notification message to the API gateway based on the first notification message, so that the API gateway can obtain the target protocol file based on the second notification message and load the target protocol file into memory, includes: A first notification message is sent to the protocol management center, and the protocol management center sends a second notification message to the API gateway based on the first notification message. The API gateway loads the target protocol file into memory based on the second notification message, and after receiving a target network request that matches the target protocol file, it encodes the request parameters in the target network request based on the request body structure information in the target protocol file, and sends the encoding result to the target service accessed by the target network request.

4. The method for updating the protocol file according to claim 2, characterized in that, The step of pushing the target protocol file to the code repository, so that after receiving the target protocol file, the code repository performs change detection on the target protocol file, and if it detects that the target protocol file has changed relative to a predetermined protocol file in the code repository, synchronizes the target protocol file to the protocol management center, includes: The first service code, including the target protocol file, is pushed to the code repository so that when the code repository detects that the target protocol file in the first service code has changed relative to the predetermined protocol file in the second service code, the target protocol file is synchronized to the protocol management center. The second service code is located in the code repository, and the second service code and the first service code are two adjacent versions of the target service.

5. The method for updating the protocol file according to claim 1, characterized in that, The change detection of the target protocol file includes: The first hash value of the target protocol file and the second hash value of the predefined protocol file in the code repository are determined based on the hash algorithm. If the first hash value is consistent with the second hash value, then it is determined that the target protocol file has not been changed relative to the predetermined protocol file; If the first hash value is inconsistent with the second hash value, it is determined that the target protocol file has been changed relative to the predetermined protocol file.

6. A method for updating a protocol file, characterized in that, The method is executed by the API gateway as described in claim 1, and the method includes: When the API gateway starts, it compares the locally stored protocol files with the protocol files in the code repository to obtain information about the matching protocol files and / or information about the new version of the protocol files in the code repository. Based on the information from the matching protocol files, load the matching protocol files into memory; and / or Based on the information of the new version of the protocol file in the code repository, the new version of the protocol file is pulled from the code repository and loaded into memory.

7. The method for updating the protocol file according to claim 6, characterized in that, The method further includes: When a network request is received, the request path in the network request is obtained; If it is determined that a protocol file matching the request path exists in the protocol file loaded in memory, then the request body structure information corresponding to the request path is obtained from the protocol file. The request parameters in the network request are encoded according to the request body structure information; The encoded result is forwarded to the target service accessed by the network request.

8. The method for updating the protocol file according to claim 7, characterized in that, The step of encoding the request parameters in the network request according to the request body structure information includes: For each request parameter in the network request, determine the type and sequence number information corresponding to the request parameter in the request body structure information; For each request parameter in the network request, the request parameter is encoded according to the type and sequence number information corresponding to the request parameter.

9. The method for updating the protocol file according to claim 7, characterized in that, After obtaining the request path in the network request, the method further includes: If it is determined that no protocol file matching the requested path exists in the protocol file loaded in memory, a message indicating a path error is returned to the sender of the network request.

10. An apparatus for updating a protocol document, characterized in that, The device includes: The file push unit is used to push the target protocol file to the code repository, so that after receiving the target protocol file, the code repository can perform change detection on the target protocol file, and if it detects that the target protocol file has changed relative to a predetermined protocol file in the code repository, it can synchronize the target protocol file to the protocol management center. The code deployment unit is used to deploy the first service code corresponding to the target protocol file to the production environment; The notification sending unit is used to send a first notification message to the protocol management center after the first service code is published, and the protocol management center sends a second notification message to the API gateway based on the first notification message, so that the API gateway can obtain the target protocol file based on the second notification message and load the target protocol file into memory.

11. An apparatus for updating a protocol document, characterized in that, The device is located in the API gateway as described in claim 10, and the device includes: The file comparison unit is used to compare the locally stored protocol files with the protocol files in the code repository when the API gateway starts, and obtain information about the matching protocol files and / or information about the new version of the protocol files in the code repository. The file loading unit is used to load the matched protocol file into memory based on the information of the matched protocol file; and / or The file retrieval unit is used to retrieve the new version of the protocol file from the code repository based on the information of the new version of the protocol file in the code repository, and load the new version of the protocol file into memory.

12. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for updating the protocol file as described in any one of claims 1 to 5 or 6 to 9.

13. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method for updating a protocol file as described in any one of claims 1 to 5 or 6 to 9.

14. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the protocol document update method as described in any one of claims 1 to 5 or 6 to 9.

Images