CN113608768A - Service interface updating method and system based on gPRC micro service - Google Patents
Service interface updating method and system based on gPRC micro service Download PDFInfo
- Publication number
- CN113608768A CN113608768A CN202110913338.6A CN202110913338A CN113608768A CN 113608768 A CN113608768 A CN 113608768A CN 202110913338 A CN202110913338 A CN 202110913338A CN 113608768 A CN113608768 A CN 113608768A
- Authority
- CN
- China
- Prior art keywords
- git
- dependency
- update
- server
- new version
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 38
- 230000001419 dependent effect Effects 0.000 claims description 16
- 238000004891 communication Methods 0.000 claims description 8
- 238000013507 mapping Methods 0.000 claims description 5
- 239000000284 extract Substances 0.000 claims description 4
- 238000011161 development Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Stored Programmes (AREA)
Abstract
The utility model provides a service interface updating method and system based on gPC micro service, which simplifies the coordination process of upgrading the service interface of gPC micro service by managing the proto files of all services through a centralized git warehouse instead of adopting engineering, so that the interface upgrading management of each service is simpler, and the change of the service interface depending on can be checked more clearly.
Description
Technical Field
The application relates to the technical field of code development, in particular to a service interface updating method and system based on gRPC micro service.
Background
The micro-service is a fine-grained architecture mode, an application program is divided into a group of small services, each service runs independently, and the services are coordinated and matched with each other. gPCs are RPC frameworks developed by Google based on the Protobuf serialization protocol, and interface calls thereof are all based on proto prototype files. In the existing development process, the proto file of the dependent gPC micro service is generally copied into a project, and then the cooperation is carried out in a mode of generating client codes through protoc compiling.
However, each project is independent and is responsible for its own development team, and when the version of the service interface is upgraded, the service responsible personnel is required to orally notify each group calling the service, and then the other party pulls the latest code copy proto file from the service project. When one service is called by many other services, the proto file of the service can be copied into the projects of many other services, and once the proto file changes due to the interface upgrading, the copying mode is time-consuming and labor-consuming and is easy to cause confusion in collaboration.
Disclosure of Invention
Therefore, it is necessary to provide a service interface updating method and system based on gRPC microservice, aiming at the problems that the conventional service interface updating method is time-consuming and labor-consuming and is easy to cause confusion in cooperation.
The application provides a service interface updating method based on gRPC micro service, which comprises the following steps:
the first client sends the proto file with the new version to a git warehouse of a git hosting server;
the method comprises the steps that a main server monitors a git warehouse, when proto files in the git warehouse generate version updating, a dependency data packet corresponding to the proto files of a new version is generated according to the proto files of the new version, and updating records and dependency information are generated at the same time;
the main server uploads the dependency data package corresponding to the proto file of the new version to a dependency management warehouse for storage;
and the second client acquires the update record and the dependency information and updates the proto file of the new version according to the update record and the dependency information.
Further, the first client sending the new version of the proto file to the git repository of the git hosting server, comprising:
a first client generates a tag which has a mapping relation with a proto file of a new version, wherein the tag comprises a service code and a version number corresponding to the proto file of the new version;
and the first client sends the tag and the new version proto file to a git warehouse of a git hosting server and correspondingly stores the tag and the new version proto file.
Further, the main server monitors the git warehouse, and when the proto file in the git warehouse generates version update, according to the dependent data packet corresponding to the proto file of the new version, the update record and the dependent information are generated at the same time, and the method comprises the following steps:
the git hosting server monitors the git warehouse and judges whether a new tag label appears in the git warehouse or not;
if a new tag appears in the git warehouse, the git hosting server pushes the new tag to the main server;
and the main server calls the proto file corresponding to the new tag label from the git warehouse to serve as the proto file of the new version.
Further, the main server monitors the proto file in the git warehouse, and when the proto file in the git warehouse generates version update, generates an update record and dependency information according to a dependency data packet corresponding to the proto file of the new version, and further includes:
the main server compiles the proto file of the new version through a protoc tool to generate a dependent data packet;
the main server sends the dependency data packet to a dependency management repository for storage.
Further, when a proto file of a new version is compiled through a protoc tool and a dependency data packet is generated, the main server also generates an update record and dependency information, wherein the update record records the update information of the current update;
after sending the dependency data package to the dependency management repository for storage, the main server stores the update record and the dependency information to the main server.
Further, the update information includes an upgrade time; the dependency information includes an item name and a version number.
Further, after the gRPC micro-service server uploads the dependency information of the new version of the proto file to the dependency management repository for storage, the method further includes:
the main server extracts the updated information and the dependency information;
and the main server distributes the updated update information and the dependency information in a broadcast mode so as to be received by the second client.
Further, the second client obtains the update record and the dependency information, and updates the proto file of the new version according to the update record and the dependency information, including:
the second client receives the updating information and the dependency information which are released by the main server in a broadcasting mode;
and the second client updates the proto file according to the update information and the dependency information.
Further, when the first client sends the new version of the proto file to the git repository of the git hosting server, the proto file of one of the plurality of services of the application is sent.
The present application further provides a service interface updating system based on a gRPC microservice, configured to perform the service interface updating method based on a gRPC microservice as mentioned in the foregoing, where the service interface updating system based on a gRPC microservice includes:
a main server;
the first client is in communication connection with the main server;
the git hosting server is provided with a git warehouse and is in communication connection with the first client; the git hosting server is also in communication connection with the main server;
at least one second client in communication connection with the main server;
a dependency information server communicatively coupled to the main server; the dependency information server is also communicatively coupled to each of the second clients.
The utility model provides a service interface updating method and system based on gPC micro service, which simplifies the coordination process of upgrading the service interface of gPC micro service by managing the proto files of all services through a centralized git warehouse instead of adopting engineering, so that the interface upgrading management of each service is simpler, and the change of the service interface depending on can be checked more clearly.
Drawings
Fig. 1 is a flowchart illustrating a service interface updating method based on a gRPC microservice according to an embodiment of the present application.
Fig. 2 is a schematic structural diagram of a service interface updating system based on a gRPC microservice according to an embodiment of the present application.
Reference numerals:
100-a primary server; 200-a first client; 300-git hosting server; 310-git warehouse
400-a second client; 500-dependent information Server
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
The application provides a service interface updating method based on gRPC micro service. It should be noted that the service interface updating method based on the gRPC microservice provided by the present application is applied to updating of any type of service.
As shown in fig. 1, in an embodiment of the present application, the method includes the following steps S100 to S700:
s100, the first client sends the proto file of the new version to a git warehouse of a git hosting server.
Specifically, the gPRC microservice may include a plurality of services, and the application splits the code of 1 application into a plurality of services, and manages the services in coordination with each other. When the service interface of a service needs to be updated, the application realizes the update of the service interface through the update of the proto file.
S300, the main server monitors the git warehouse. And when the proto file in the git warehouse generates version updating, generating a dependent data packet corresponding to the proto file of the new version according to the proto file of the new version, and simultaneously generating updating records and dependent information.
Specifically, the git warehouse is stored in a git hosting server, which may be a public server such as github or a private server built inside a company. The git warehouse has the advantages that the git warehouse is a distributed storage system, and when the version of the service interface is upgraded, the webhook can be called back in time when an upgrade message is pushed, and the traditional scheme that each group calling the service is orally informed by a service responsible person and then the other party pulls the latest code copy update file from a service project is not needed.
S500, the main server uploads the dependency data package corresponding to the proto file of the new version to a dependency management warehouse for storage.
Specifically, the subsequent second client needing to be upgraded can complete the upgrade only according to the dependency data packet without pulling the server engineering code.
S700, the second client acquires the update record and the dependency information, and updates the proto file of the new version according to the update record and the dependency information.
In the embodiment, proto files of all services are managed through a centralized git warehouse instead of engineering, so that the coordination process of upgrading the service interfaces of the gPC micro-service is simplified, the interface upgrading management of each service is simpler, and the change of the service interfaces depending on can be checked more clearly.
In an embodiment of the present application, the S100 includes the following S110 to S120:
s110, the first client generates tag labels which have mapping relation with the proto files of the new version. The tag label comprises a service code and a version number corresponding to the proto file of the new version.
S120, the first client sends the tag and the proto file with the new version to a git warehouse of a git hosting server, and correspondingly stores the tag and the proto file with the new version.
In particular, it is mentioned in the foregoing that the git repository has the advantage that the git repository is a distributed storage system and that when the service interface version is upgraded, a callback webhook can be configured that can be timely when an upgrade message is pushed.
The embodiment sets tag label pushing. After the tag pushing is set, a callback webhook when the tag is pushed can be provided, so that an interface is configured for the main server, the interface can judge whether the tag pushing is directed at a git warehouse of a git hosting server or not, whether the format of the tag can be analyzed or not, and further judge whether the service interface of a certain service needs to be upgraded or not.
In this embodiment, by using this new manner, the first client only needs to generate a tag having a mapping relationship with the proto file of the new version and push the tag to the main server, the main server automatically compiles and packages the tag to generate a dependent data package and an upgrade message (the upgrade message includes an update record and dependent information), and notifies the second client that needs to call the service of the upgrade message, and the second client only needs to check the upgrade message to obtain the dependent data package for upgrading without pulling the service engineering code.
In an embodiment of the present application, the S300 includes the following S310 to S330:
s310, the git hosting server monitors the git warehouse and judges whether a new tag label appears in the git warehouse or not.
S320, if a new tag appears in the git warehouse, the git hosting server pushes the new tag to the main server.
S330, the main server calls the proto file corresponding to the new tag label from the git warehouse to serve as the proto file of the new version.
Specifically, the embodiment sets tag pushing. After the tag pushing is set, a callback webhook when the tag is pushed can be provided, so that an interface is configured for the main server, the interface can judge whether the tag pushing is directed at a git warehouse of a git hosting server or not, whether the format of the tag can be analyzed or not, and further judge whether the service interface of a certain service needs to be upgraded or not.
Further, S320 includes:
s321, if a new tag appears in the git warehouse, the git hosting server analyzes the new tag and judges whether the analysis is successful.
S322, if the analysis fails, the tag label is illegal, and the subsequent steps are terminated.
S323, if the analysis is successful, further judging whether the git warehouse has proto files corresponding to the tag labels;
s234, if the git repository has the proto file corresponding to the tag, then execute the following S330, and the main server retrieves the proto file corresponding to the new tag from the git repository as the proto file of the new version.
S235, if the git warehouse does not have the proto file corresponding to the tag label, the ag label is also determined to be illegal, and the subsequent steps are terminated.
It can be seen that the tag must be successfully parsed, and when the proto file corresponding to the new tag exists in the git repository, the subsequent steps of retrieving the proto file are executed, otherwise, the tag is considered to be illegal. Because the tag represents the mapping relationship between the tag and the proto file, the proto file corresponding to the tag must be found in the git repository.
In an embodiment of the present application, the S300 further includes the following steps:
s340, the main server compiles the proto file of the new version through a protoc tool to generate a dependent data package.
And S350, the main server sends the dependency data packet to a dependency management warehouse for storage. ,
specifically, the development language can adopt java and can adopt maven to perform dependency management. In this embodiment, a maven compiling plug-in may be used during compiling, and the core is to call a protoc tool for compiling.
In an embodiment of the present application, in S340, when the host server compiles the proto file of the new version through the protoc tool and generates the dependency data package, the host server further generates an update record and dependency information, where the update record records the update information of the current update. :
after sending the dependency data package to the dependency management repository for storage, i.e. after S350, S360 is further included: the primary server stores the update record and the dependency information to the primary server.
In an embodiment of the present application, the update information includes an upgrade time. The dependency information includes an item name and a version number.
Specifically, the update information may also include the ID number of the updated administrator.
In an embodiment of the present application, after S500 and before S700, the method for updating a service interface of a gRPC microservice further includes S610 to S620:
s610, the main server extracts the updated information and the dependency information of the current update.
And S620, the main server distributes the updated information and the dependency information in the current time in a broadcast mode so that the second client can receive the updated information and the dependency information.
In particular, the form of the broadcast facilitates the distribution of information.
In an embodiment of the present application, the S700 includes the following S710 to S720:
and S710, the second client receives the updating information and the dependency information which are released by the main server in a broadcasting mode.
S720, the second client updates the proto file according to the update information and the dependency information.
Specifically, in S340, the main server compiles the proto file of the new version by using a protoc tool to generate a dependent data package, where the dependent data package actually belongs to the code package, and the dependent data package includes interface calling mode information. And the second client extracts the updated dependency data packet from the dependency management warehouse for use according to the update information and the dependency information.
In an embodiment of the application, when the first client sends the new version of the proto file to the git repository of the git hosting server, the proto file of one of the plurality of services of the application is sent.
Specifically, in this embodiment, when opening an application, the code of the application may be split into multiple services, and the services are managed in coordination with each other. Thus, only the proto file of one of the plurality of services is upgraded at a time.
Of course, a plurality of services can be updated and upgraded synchronously, that is, the service interface updating method based on the gRPC microservice provided by the present application is executed simultaneously.
The application provides a service interface updating system based on gRPC micro service.
As shown in fig. 2, in an embodiment of the present application, the service interface updating system based on a gRPC microservice is configured to perform the service interface updating method based on a gRPC microservice in any one of the foregoing embodiments. The service interface updating system based on the gRPC microservice includes a main server 100, a first client 200, a git hosting server 300, at least one second client 400, and a dependency information server 500.
A first client 400 is communicatively connected to the main server 100. The git hosting server 300 is provided with a git repository 310. The git hosting server 300 is communicatively connected with the first client 400. The git hosting server 300 is also communicatively connected to the main server 100. Each second client 200 is communicatively connected to the main server 100. The dependency information server 500 is communicatively coupled to the main server 100. The dependency information server 500 is also communicatively coupled to each of the second clients 400.
It should be noted that, the service interface updating method based on the gRPC microservice provided in the foregoing embodiment and the service interface updating system based on the gRPC microservice in this embodiment have the same name of the device, and for the sake of brevity, only the reference numerals are given in this embodiment, but not in the foregoing embodiment, which does not affect that they have the same meaning.
Specifically, the first client 200 is an upgrade client and is used by upgrade managers. The second client 200 may be plural for use by an ordinary developer. In the upgrade scenario provided in this embodiment, the first client 100 serves as the only master upgrade client, and the other second clients 200 depending on the first client serve as slave clients, and the upgraded dependent packet upgrade service interface is used.
The technical features of the embodiments described above may be arbitrarily combined, the order of execution of the method steps is not limited, and for simplicity of description, all possible combinations of the technical features in the embodiments are not described, however, as long as there is no contradiction between the combinations of the technical features, the combinations of the technical features should be considered as the scope of the present description.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present application. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present application shall be subject to the appended claims.
Claims (10)
1. A service interface updating method based on gRPC micro service is characterized in that the method comprises the following steps:
the first client sends the proto file with the new version to a git warehouse of a git hosting server;
the method comprises the steps that a main server monitors a git warehouse, when proto files in the git warehouse generate version updating, a dependency data packet corresponding to the proto files of a new version is generated according to the proto files of the new version, and updating records and dependency information are generated at the same time;
the main server uploads the dependency data package corresponding to the proto file of the new version to a dependency management warehouse for storage;
and the second client acquires the update record and the dependency information and updates the proto file of the new version according to the update record and the dependency information.
2. The gRPC microservice-based service interface update method of claim 1, wherein the first client sends a new version of the proto file to a git repository of a git hosting server, comprising:
a first client generates a tag which has a mapping relation with a proto file of a new version, wherein the tag comprises a service code and a version number corresponding to the proto file of the new version;
and the first client sends the tag and the new version proto file to a git warehouse of a git hosting server and correspondingly stores the tag and the new version proto file.
3. The gRPC microservice-based service interface updating method according to claim 2, wherein the master server monitors the git repository, and when a proto file in the git repository generates a version update, an update record and dependency information are generated simultaneously according to a dependency data packet corresponding to the proto file of a new version, including:
the git hosting server monitors the git warehouse and judges whether a new tag label appears in the git warehouse or not;
if a new tag appears in the git warehouse, the git hosting server pushes the new tag to the main server;
and the main server calls the proto file corresponding to the new tag label from the git warehouse to serve as the proto file of the new version.
4. The gRPC microservice-based service interface updating method according to claim 3, wherein a master server monitors proto files in the git repository, and when a proto file in the git repository generates a version update, an update record and dependency information are generated simultaneously according to a dependency data packet corresponding to a proto file of a new version, further comprising:
the main server compiles the proto file of the new version through a protoc tool to generate a dependent data packet;
the main server sends the dependency data packet to a dependency management repository for storage.
5. The service interface updating method based on the gRPC micro-service according to claim 4, wherein when a proto file of a new version is compiled by a protoc tool and a dependency data packet is generated, the main server further generates an update record and dependency information, and the update record records the update information of the update;
after sending the dependency data package to the dependency management repository for storage, the main server stores the update record and the dependency information to the main server.
6. The gRPC microservice-based service interface update method of claim 5, wherein the update information includes an upgrade time; the dependency information includes an item name and a version number.
7. The gRPC microservice-based service interface update method of claim 6, wherein after the gRPC microservice server uploads dependency information for a new version of the proto file to a dependency management repository for storage, the method further comprises:
the main server extracts the updated information and the dependency information;
and the main server distributes the updated update information and the dependency information in a broadcast mode so as to be received by the second client.
8. The gRPC microservice-based service interface updating method according to claim 7, wherein the second client obtains an update record and dependency information, and updates the new version of the proto file according to the update record and dependency information, including:
the second client receives the updating information and the dependency information which are released by the main server in a broadcasting mode;
and the second client updates the proto file according to the update information and the dependency information.
9. The gRPC microservice-based service interface update method of claim 8, wherein the proto file of one of the plurality of services of the application is sent when the first client sends a new version of the proto file to the git repository of the git hosting server.
10. A gRPC microservice-based service interface update system for performing the gRPC microservice-based service interface update method of any of claims 1-9, the gRPC microservice-based service interface update system comprising:
a main server;
the first client is in communication connection with the main server;
the git hosting server is provided with a git warehouse and is in communication connection with the first client; the git hosting server is also in communication connection with the main server;
at least one second client in communication connection with the main server;
a dependency information server communicatively coupled to the main server; the dependency information server is also communicatively coupled to each of the second clients.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110913338.6A CN113608768A (en) | 2021-08-10 | 2021-08-10 | Service interface updating method and system based on gPRC micro service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110913338.6A CN113608768A (en) | 2021-08-10 | 2021-08-10 | Service interface updating method and system based on gPRC micro service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113608768A true CN113608768A (en) | 2021-11-05 |
Family
ID=78307910
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110913338.6A Pending CN113608768A (en) | 2021-08-10 | 2021-08-10 | Service interface updating method and system based on gPRC micro service |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113608768A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114860225A (en) * | 2022-05-20 | 2022-08-05 | 北京智源人工智能研究院 | Type safety system based on git submodule, implementation method and electronic equipment |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111324619A (en) * | 2020-02-18 | 2020-06-23 | 苏州达家迎信息技术有限公司 | Object updating method, device, equipment and storage medium in micro service system |
| CN111736891A (en) * | 2020-06-16 | 2020-10-02 | 北京嘀嘀无限科技发展有限公司 | Method, system and readable storage medium for version control based on Git |
| US20200351373A1 (en) * | 2019-05-03 | 2020-11-05 | Munish Kumar Gupta | Systems and methods for managing profile updates |
-
2021
- 2021-08-10 CN CN202110913338.6A patent/CN113608768A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200351373A1 (en) * | 2019-05-03 | 2020-11-05 | Munish Kumar Gupta | Systems and methods for managing profile updates |
| CN111324619A (en) * | 2020-02-18 | 2020-06-23 | 苏州达家迎信息技术有限公司 | Object updating method, device, equipment and storage medium in micro service system |
| CN111736891A (en) * | 2020-06-16 | 2020-10-02 | 北京嘀嘀无限科技发展有限公司 | Method, system and readable storage medium for version control based on Git |
Non-Patent Citations (1)
| Title |
|---|
| HAN-YA-JUN: "微服务架构下RPC IDL及代码如何统一管理", pages 1 - 14, Retrieved from the Internet <URL:https://studygolang.com/articles/31749> * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114860225A (en) * | 2022-05-20 | 2022-08-05 | 北京智源人工智能研究院 | Type safety system based on git submodule, implementation method and electronic equipment |
| CN114860225B (en) * | 2022-05-20 | 2023-11-10 | 北京智源人工智能研究院 | Type security system based on git sub-module, implementation method and electronic equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101863398B1 (en) | Method and system for synchronization mechanism on multi-server reservation system | |
| US7516167B2 (en) | Data synchronization | |
| CN111866191A (en) | Message event distribution method, distribution platform, system and server | |
| CN101325509B (en) | Method, system and apparatus for installing software component | |
| CN111416736A (en) | Configuration management method and device of network equipment, computing equipment and storage medium | |
| CN102427409A (en) | Configuration data submission method based on network configuration (NETCONF) protocol and server thereof | |
| CN109542865A (en) | Distributed cluster system configuration file synchronous method, device, system and medium | |
| US9514498B2 (en) | Method and system for centralized reservation context management on multi-server reservation system | |
| CN112422709B (en) | Identification management method, terminal equipment, identification analysis secondary node and medium | |
| US20080301640A1 (en) | Method and system for allocating id of software component | |
| US20220413937A1 (en) | Node management method, device and apparatus, storage medium, and system | |
| CN112650742A (en) | Cross-link data verification method, device, equipment and storage medium | |
| CN116915829A (en) | Optical communication system | |
| CN113608768A (en) | Service interface updating method and system based on gPRC micro service | |
| WO2016026329A1 (en) | Terminal upgrade method and apparatus | |
| CN115422036A (en) | Vehicle-end SOA service call chain tracking method based on OpenTelemetry | |
| US8244844B2 (en) | Tool for data generation for simple network management protocol (SNMP) | |
| CN111654534A (en) | Private cloud task management system, method and storage medium | |
| US20050188104A1 (en) | Methods, systems, and computer program products for dynamic inter-operability of nodes in service grids | |
| CN102098190B (en) | Automatic development test system and method of Web project | |
| US20070220157A1 (en) | Simple network management protocol (SNMP) agent system and method | |
| US20230376329A1 (en) | Systems and methods for automatically generating guided user interfaces (guis) for tracking and migrating legacy networked resources within an enterprise during a technical migration | |
| US20110078403A1 (en) | Method and terminal device for erasing data of terminal | |
| CN114172821B (en) | Service state synchronization method and device and server | |
| CN100502301C (en) | Node controlling method in network management system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |