CN118113460A - Service aggregation method based on micro-service - Google Patents
Service aggregation method based on micro-service Download PDFInfo
- Publication number
- CN118113460A CN118113460A CN202410085438.8A CN202410085438A CN118113460A CN 118113460 A CN118113460 A CN 118113460A CN 202410085438 A CN202410085438 A CN 202410085438A CN 118113460 A CN118113460 A CN 118113460A
- Authority
- CN
- China
- Prior art keywords
- service
- micro
- request
- aggregation
- api gateway
- 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
- 230000002776 aggregation Effects 0.000 title claims abstract description 55
- 238000004220 aggregation Methods 0.000 title claims abstract description 55
- 238000000034 method Methods 0.000 title claims abstract description 40
- 238000012360 testing method Methods 0.000 claims abstract description 25
- 230000006870 function Effects 0.000 claims abstract description 21
- 230000008569 process Effects 0.000 claims abstract description 18
- 238000012544 monitoring process Methods 0.000 claims abstract description 13
- 238000012545 processing Methods 0.000 claims abstract description 11
- 238000013461 design Methods 0.000 claims abstract description 8
- 238000004364 calculation method Methods 0.000 claims abstract description 6
- 230000003993 interaction Effects 0.000 claims abstract description 5
- 238000012423 maintenance Methods 0.000 claims description 5
- 230000004044 response Effects 0.000 abstract description 6
- 230000005540 biological transmission Effects 0.000 abstract description 2
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000178 monomer Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention relates to the technical field of Internet, in particular to a service aggregation method based on micro services, which comprises the following steps: s1: identifying a business process, and defining a target and a range of service aggregation; s2: the interaction between the client and the micro-service embodiment is realized according to the requirement design API GATEWAY; s3: setting a load balancing algorithm, and dispersing the request of the client into a plurality of micro service instances; s4: integrating the aggregation logic with the associated microserver instance; s5: and testing, verifying, monitoring and maintaining the aggregation function. In the invention API GATEWAY distributes the request to a plurality of micro service examples through a weighted polling algorithm, thereby improving the concurrency processing capacity and expandability of the system; and the common request result is cached, so that repeated calculation and network transmission are avoided, the response speed and usability of the system are improved, and the collaborative work capability between the micro service instance and API GATEWAY is verified through writing unit test and integrated test, so that the stability of the system is improved.
Description
Technical Field
The invention relates to the technical field of Internet, in particular to a service aggregation method based on micro services.
Background
With the rapid development of the internet and the mobile internet, the data and business processes that an enterprise needs to process become more and more complex, and the conventional monomer application cannot meet the requirements. To address this challenge, micro-service architectures have evolved. A micro-service architecture is a mechanism that breaks up large applications into a series of small, independent services. Each service is independently deployed, and different programming languages and storage techniques can be used, so that high flexibility and expandability are realized, and service aggregation is an important link in a micro-service architecture. Through service aggregation, a plurality of micro services can be combined together to form a unified service interface, thereby providing richer functions. Service aggregation can not only simplify the complexity of the system, but also improve the performance and usability of the system. In the prior art, the failure to distribute the request to the client into multiple micro service instances causes the micro service instance to be overloaded, thereby affecting the performance of the whole system, and when one micro service instance fails, it may affect other services associated with it. In view of the above, the present invention proposes a service aggregation method based on micro services to solve the above problems.
Disclosure of Invention
The main objective of the present invention is to provide a service aggregation method based on micro-services, so as to solve the problems in the related art.
In order to achieve the above object, according to one aspect of the present invention, there is provided a service aggregation method based on micro services, comprising the steps of:
s1: identifying a business process, and defining a target and a range of service aggregation;
S2: the interaction between the client and the micro-service embodiment is realized according to the requirement design API GATEWAY;
S3: setting a load balancing algorithm, and dispersing the request of the client into a plurality of micro service instances;
S4: integrating the aggregation logic with related micro-service examples;
s5: and testing, verifying, monitoring and maintaining the aggregation function.
Further, the design API GATEWAY in S2 requires a process of determining the ingress and interface of the aggregated service and routing the request to the corresponding microservice instance.
Further, the portal of the aggregation service is accessed through a URL path, wherein the URL path comprises the name, version number, context information of the aggregation service and a specific interface path in the aggregation service; the interface of the aggregation service is realized through an API end point of the HTTP protocol, and the interface defines the request type which can be sent by the client and the mode of responding to the request by the aggregation service.
Further, the specific steps of routing the request to the corresponding micro service instance are as follows:
s21: defining routing rules tells the gateway how to route the request to the corresponding micro service instance;
s22: the state of the routing logic checking request is realized;
s23: setting a correct service address and a correct routing rule in a client;
s24: the corresponding gateway is started to route the request to the correct micro service instance.
Further, API GATEWAY can receive the request from the client and send the request to the related micro-service instance, where the micro-service instance transmits the result to API GATEWAY, API GATEWAY and then transmits the result to the client according to the user's requirement.
Further, a timeout parameter and a monitoring parameter are added in the invocation of the micro service instance.
Further, the load balancing algorithm is set in S3, and the requests are distributed according to the weight of each microservice instance based on a weighted polling algorithm, and the calculation formula is as follows:
wherein s i represents the request number obtained by the ith micro-service instance in the polling sequence, and sum represents the total request number; n represents the total number of micro-service examples, s i-1 represents the request number obtained by the i-1 th micro-service example in the polling sequence, and d represents the weight of the micro-service example.
Further, the step of integrating the aggregation logic with the related micro service instance in S4 is as follows:
S41: defining and implementing aggregation logic;
S42: API GATEWAY communicates with the micro-service instance;
s43: service logic is implemented in the micro-service embodiment, and API GATEWAY can correctly process the returned data;
s44: unit tests and integrated tests are written to verify the service logic and API GATEWAY data processing capabilities of the microservice instance.
Further, the objective of the test verification of the aggregate functionality is to ensure API GATEWAY that the data and functionality of multiple micro-service instances can be properly aggregated and that the results can be returned as expected.
Further, the monitoring and maintenance of the aggregation function is realized by setting log records, the log records are classified into different levels according to the importance and the potential risk of the aggregation function, and the log record files have authority and access control.
Compared with the prior art, the invention has the following beneficial effects:
In the invention API GATEWAY distributes the request to a plurality of micro service examples through a weighted polling algorithm, thereby improving the concurrency processing capacity and expandability of the system; and the common request results are cached, so that repeated calculation and network transmission are avoided, the response speed and the usability of the system are improved, and the collaborative work capability between the micro service instance and API GATEWAY is verified through writing unit tests and integrated tests, so that the micro service instance and API GATEWAY can work normally in a real environment, and the stability of the system is improved.
Drawings
FIG. 1 is a flow chart of the method of the present invention.
Detailed Description
In order to further describe the technical means and effects adopted by the present invention for achieving the intended purpose, the following detailed description will refer to the specific implementation, structure, characteristics and effects according to the present invention with reference to the accompanying drawings and preferred embodiments.
Referring to fig. 1, there is provided a service aggregation method based on micro services, including the steps of:
s1: identifying a business process, and defining a target and a range of service aggregation;
S2: the interaction between the client and the micro-service embodiment is realized according to the requirement design API GATEWAY;
S3: setting a load balancing algorithm, and dispersing the request of the client into a plurality of micro service instances;
S4: integrating the aggregation logic with related micro-service examples;
s5: and testing, verifying, monitoring and maintaining the aggregation function.
The design API GATEWAY in S2 requires a process of determining the ingress and interface of the aggregated service and routing the request to the corresponding microservice instance.
The portal of the aggregation service is accessed through a URL path, and the URL path comprises the name, version number, context information and a specific interface path in the aggregation service; the interface of the aggregation service is realized through an API end point of the HTTP protocol, and the interface defines the request type which can be sent by the client and the mode of responding to the request by the aggregation service.
The specific steps of routing the request to the corresponding micro service instance are as follows:
s21: defining routing rules tells the gateway how to route the request to the corresponding micro service instance;
s22: the state of the routing logic checking request is realized;
s23: setting a correct service address and a correct routing rule in a client;
s24: the corresponding gateway is started to route the request to the correct micro service instance.
The API GATEWAY can receive the request from the client and send the request to the related micro-service instance, and the micro-service instance transmits the result to API GATEWAY, APIGATEWAY and then transmits the result to the client according to the user's requirement.
And adding a timeout parameter and a monitoring parameter in the call of the micro service instance.
The load balancing algorithm is set in the step S3, based on a weighted polling algorithm, requests are distributed according to the weight of each micro service instance, and the calculation formula is as follows:
Wherein s i represents the request number obtained by the ith micro-service instance in the polling sequence, and sum represents the total request number; n represents the total number of micro-service instances; s i-1 represents the request number obtained by the i-1 th micro-service instance in the polling sequence; d represents the micro-service instance weight.
The step of integrating the aggregation logic with the related micro-service instance in S4 is as follows:
S41: defining and implementing aggregation logic;
S42: API GATEWAY communicates with the micro-service instance;
s43: service logic is implemented in the micro-service embodiment, and API GATEWAY can correctly process the returned data;
S44: unit tests and integrated tests are written to verify the service logic and APIGATEWAY data processing capabilities of the microservice instance.
The goal of the test verification of the aggregate functionality is to ensure API GATEWAY that the data and functionality of multiple micro-service instances can be properly aggregated and that the results can be returned as expected.
The monitoring and maintenance of the aggregation function is realized by setting log records, the log records are classified into different levels according to the importance and the potential risk of the aggregation function, and log record files have authority and access control.
In this embodiment, the business process is first identified, the goal and scope of service aggregation are defined, which services are necessary and which services can be aggregated, then the business function is split into multiple independent micro services according to the result of demand analysis, each micro service should pay attention to only one business function, so as to realize high cohesion, where the micro service is a framework mode that splits a large application into a group of small services, each service runs in its own process, and the services can communicate with each other. Each service is built around a specific business function, can be deployed and expanded independently, and then each split micro service is designed in detail, interaction between a client and a micro service embodiment is realized through a design API GATEWAY, and API GATEWAY is a service of an API (application program interface) for managing a plurality of micro services in a micro service architecture; it requires a process of determining the ingress and interface of the aggregated service and routing the request to the corresponding micro service instance.
The portal to an aggregated service is the interface that the service consumer invokes the aggregated service, and in general, the portal to an aggregated service should be designed as a single, easily understood and used interface that should be published so that any service can access it, by providing it with a URL path through an API gateway, which refers to an address on the internet that identifies a particular resource, that contains the name, version number, context information, and specific interface path in the aggregated service. For example, an aggregated service entry may be/API/v 1/aggregate/MYAGGREGATE, where API is the root path of the API gateway, v1 is the version number of the service, aggregate is the name of the aggregated service, and MYAGGREGATE is the specific interface path in the aggregated service.
The interface of an aggregated service typically requires the transfer of data, which is implemented by API endpoints of the HTTP protocol provided by an API gateway, which are typically defined and maintained by a developer for specifying access addresses of specific functions or resources, the interface defining the types of requests that a client can send and the manner in which the aggregated service responds to the requests, and the specific steps of routing the requests to the corresponding micro-service instance are: defining routing rules tells the gateway how to route the request to the corresponding micro service instance; the state of the routing logic checking request is realized; setting a correct service address and a correct routing rule in a client; the corresponding gateway is started to route the request to the correct micro service instance.
API GATEWAY is capable of receiving a request from a client and sending the request to an associated micro-service instance, which transmits the result to API GATEWAY, APIGATEWAY and then to the client according to the user's needs. To monitor the performance of the micro-service in real time, monitoring parameters such as tracking ID, time stamp, etc. are added in the invocation of the micro-service instance. This facilitates performance analysis and troubleshooting; in order to timely stop service call when a problem occurs, the condition of infinite waiting or resource exhaustion is avoided; adding timeout parameters in a micro service instance, when a certain micro service fails, call to the service is cut off to prevent the fault from diffusing to other services, and there are many methods for adding timeout parameters, for example, using a with statement, the code is:
import requests
with requests.get(′http://example.com′，timeout＝10)as r：
print(r.text)
Where 'http:// sample.com' is the target web site that wants to access, the requests.get () function is used to send the request to the specified web site and return the response object r, if no response is obtained within 10 seconds, the requests.get () function will throw a timeout exception, i.e. end the process of the micro-service instance.
Further, a load balancing algorithm is arranged in API GATEWAY, and is used for dispersing the request of the client into a plurality of micro service instances, so that the concurrency processing capacity and expandability of the system are improved; the load balancing algorithm is based on a weighted polling algorithm, and can uniformly distribute requests to a plurality of servers, and adjust the distributed request quantity according to the weight of each server, so that the high-performance servers can be ensured to obtain more requests, and the servers with lower performance can obtain fewer requests, thereby realizing the balancing and optimization of the system, and the calculation formula is as follows:
Wherein s i represents the request number obtained by the ith micro-service instance in the polling sequence, and sum represents the total request number; n represents the total number of micro-service instances; s i-1 represents the request number obtained by the i-1 th micro-service instance in the polling sequence; d represents the micro-service instance weight. The ith microservice instance in the polling sequence refers to the microservice instance currently being polled, and the (i-1) th microservice instance in the polling sequence refers to the microservice instance previously being polled. Through the formula, each node can be ensured to obtain the request number corresponding to the weight of the node, so that load balancing is realized.
Then, integrating the aggregation logic with related micro-service examples; firstly, determining a micro server and data which need to be aggregated; defining how to aggregate data and functions of a plurality of micro-servers according to requirements; according to the defined aggregation logic, the aggregation function of API GATEWAY is implemented. API GATEWAY communicates with the micro-service instance; implementing service logic in the micro-service embodiment, including processing requests, querying databases, returning data, etc., and API GATEWAY being able to correctly process the returned data; unit testing and integration testing is ultimately written to verify the service logic and API GATEWAY data processing capabilities of the microservice instance, with the focus being on its invocation and data translation capabilities of the microservice instance for the unit testing of API GATEWAY to verify whether API GATEWAY properly handled the request and returned the expected response. For the integration test of API GATEWAY, a focus is on how it properly processes data from a micro-service instance and converts it into a format acceptable to the client. The actual data is used to verify API GATEWAY that the data can be properly parsed and converted. Because API GATEWAY is the interface between the micro-service and the client, its data processing capabilities directly affect the performance and user experience of the micro-service. Verifying API GATEWAY's data processing capability by writing unit tests and integrated tests can ensure that API GATEWAY can correctly process various requests and responses, ensuring the normal operation of micro services.
And finally, testing and verifying the aggregation function and monitoring and maintaining the aggregation function. The goal of test verification is to ensure API GATEWAY that the data and functionality of multiple micro-service instances can be properly aggregated and that the results can be returned as expected; monitoring maintenance is accomplished by setting log records to discover and resolve potential problems in time. Maintenance and optimization is performed as needed to ensure performance and reliability of service aggregation. Where the logging is classified into different levels according to the importance and potential risk of the aggregate functionality, for example, for critical business logic and data processing paths, detailed logging information should be recorded, including time stamps, operation objects, operation results, etc. For general operation, more concise log information can be recorded. And the log record file has rights and access controls to prevent unauthorized access and modification.
The present invention is not limited to the above embodiments, but is capable of modification and variation in detail, and other modifications and variations can be made by those skilled in the art without departing from the scope of the present invention.
Claims (10)
1. A method for service aggregation based on micro-services, comprising the steps of:
S1: identifying a business process, and defining a target and a range of service aggregation;
S2: the interaction between the client and the micro-service embodiment is realized according to the requirement design API GATEWAY;
S3: setting a load balancing algorithm, and dispersing the request of the client into a plurality of micro service instances;
S4: integrating the aggregation logic with related micro-service examples;
s5: and testing, verifying, monitoring and maintaining the aggregation function.
2. The method of claim 1, wherein the design API GATEWAY in S2 requires a procedure of determining the portal and interface of the aggregated service and routing the request to the corresponding micro service instance.
3. The method of claim 2, wherein the portal of the aggregated service is accessed via a URL path, the URL path including a name, version number, context information of the aggregated service, and a specific interface path in the aggregated service; the interface of the aggregation service is realized through an API end point of the HTTP protocol, and the interface defines the request type which can be sent by the client and the mode of responding to the request by the aggregation service.
4. The method for service aggregation based on micro services according to claim 1, wherein the specific step of routing the request to the corresponding micro service instance is as follows:
s21: defining routing rules tells the gateway how to route the request to the corresponding micro service instance;
s22: the state of the routing logic checking request is realized;
s23: setting a correct service address and a correct routing rule in a client;
s24: the corresponding gateway is started to route the request to the correct micro service instance.
5. The method of claim 1, wherein API GATEWAY is capable of receiving a request from a client and sending the request to an associated micro-service instance, and the micro-service instance transmits API GATEWAY, API GATEWAY the result to the client according to the user's requirement.
6. The method of claim 5, wherein a timeout parameter and a monitoring parameter are added to the invocation of the micro service instance.
7. The service aggregation method based on micro services according to claim 1, wherein the setting of the load balancing algorithm in S3 is based on a weighted polling algorithm, and the request is allocated according to the weight of each micro service instance, and the calculation formula is as follows:
Wherein s i represents the request number obtained by the ith micro-service instance in the polling sequence, and sum represents the total request number; n represents the total number of micro-service instances; s i-1 represents the request number obtained by the i-1 th micro-service instance in the polling sequence; d represents the micro-service instance weight.
8. The method for service aggregation based on micro services according to claim 1, wherein the step of integrating the aggregation logic with the related micro service instance in S4 is as follows:
S41: defining and implementing aggregation logic;
S42: API GATEWAY communicates with the micro-service instance;
s43: service logic is implemented in the micro-service embodiment, and API GATEWAY can correctly process the returned data;
s44: unit tests and integrated tests are written to verify the service logic and API GATEWAY data processing capabilities of the microservice instance.
9. The method of claim 1, wherein the objective of testing and verifying the aggregated functionality is to ensure API GATEWAY that the data and functionality of multiple microservices instances can be properly aggregated and that the results can be returned as expected.
10. The method of claim 1, wherein the monitoring and maintenance of the aggregated functions is performed by setting log records, the log records are classified into different levels according to importance and potential risk of the aggregated functions, and the log record files have authority and access control.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410085438.8A CN118113460A (en) | 2024-01-21 | 2024-01-21 | Service aggregation method based on micro-service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410085438.8A CN118113460A (en) | 2024-01-21 | 2024-01-21 | Service aggregation method based on micro-service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118113460A true CN118113460A (en) | 2024-05-31 |
Family
ID=91211376
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410085438.8A Pending CN118113460A (en) | 2024-01-21 | 2024-01-21 | Service aggregation method based on micro-service |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118113460A (en) |
-
2024
- 2024-01-21 CN CN202410085438.8A patent/CN118113460A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6996500B2 (en) | Method for communicating diagnostic data | |
| Zheng et al. | Investigating QoS of real-world web services | |
| US7502850B2 (en) | Verifying resource functionality before use by a grid job submitted to a grid environment | |
| US8005979B2 (en) | System and method for uniquely identifying processes and entities in clusters | |
| US6173322B1 (en) | Network request distribution based on static rules and dynamic performance data | |
| US8447881B2 (en) | Load balancing for services | |
| US5742607A (en) | Method and apparatus for controlling two way communication via disparate physical media | |
| US20090300180A1 (en) | Systems and methods for remote management of networked systems using secure modular platform | |
| US7761527B2 (en) | Method and apparatus for discovering network based distributed applications | |
| US20070005739A1 (en) | Method and apparatus for dynamically controlling the selection and redundancy of web service components | |
| TW200412736A (en) | Dynamic binding and fail-over of comparable web service instances in a services grid | |
| CN103248670B (en) | Connection management server and connection management method under computer network environment | |
| US20060069777A1 (en) | Request message control method for using service and service providing system | |
| US11362912B2 (en) | Support ticket platform for improving network infrastructures | |
| US7523492B2 (en) | Secure gateway with proxy service capability servers for service level agreement checking | |
| US7191232B2 (en) | Extendable provisioning mechanism for a service gateway | |
| CN111556135A (en) | Request scheduling method, system and device and electronic equipment | |
| US7334038B1 (en) | Broadband service control network | |
| CA2624273A1 (en) | Next site for distributed service connections | |
| CN115250233B (en) | Gray scale routing control method, gray scale routing assembly and computer equipment | |
| CN118113460A (en) | Service aggregation method based on micro-service | |
| CN116361172A (en) | Development joint debugging method and system | |
| US9967308B2 (en) | System and method for fault management in a service-oriented architecture | |
| CN104753774B (en) | A kind of distributed enterprise comprehensive access gate | |
| CN116132250A (en) | Operation and maintenance system, operation and maintenance method, storage medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication |