Shulou(Shulou.com)06/02 Report--

This article mainly introduces "the design and implementation of API resource isolation system". In daily operation, I believe many people have doubts about the design and implementation of API resource isolation system. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "the design and implementation of API resource isolation system". Next, please follow the editor to study!

Part 1 background

Large transportation business needs to connect the external supply chain of air tickets, train tickets, car rental, pick-up and pick-up machines, and most of the data interfaces of suppliers communicate through HTTP, HTTPS and other protocols.

In order to ensure the progress of development and support multi-scenario support for integration testing, we often need to MOCK the vendor interface. Previously, we did not have unified control over the invocation of the external interface in the development environment and the test environment, and we were unable to implement the call switch, nor was it possible to count and limit the amount of call.

In order to solve these problems, we designed to access the API resource isolation system JARVIS (Join Api Resource Virtual Isolation System), hoping that it can help us solve the problem of resource management and control like the Jarvis in Iron Man.

Part 2 Design principles

Graphical operation, provide management background, be friendly to the interaction of development and testing students.

There is no intrusion into the business, and there is no need to modify the business system code to ensure that the tested code is consistent with the released code.

Business association, this system is for business services, need to provide the necessary business relevance.

Support rich matching rules, which can be used in most usage scenarios.

What is allocated is what you get, and the management rules can take effect immediately.

The request response is traceable and provides detailed logging and query functions.

The whole idea of Design and implementation of Part 3

The supplier resource management and control system is located between the internal access gateway and the external vendor interface, and provides a global agent for external supplier resources in the development and test environment. The location in the system is as follows:

The resource management and control system is divided into two parts:

Config Center: mainly implements the configuration management of MOCK rules corresponding to business line, environment, supplier, supplier API and API.

API Server: mainly responsible for request acceptance, MOCK rule matching, MOCK rule response and logging.

Key function

The configuration center and API server are separated to support cluster deployment.

Both simulated response and proxy access are supported.

Support for Mock rules to take effect immediately after modification

Environmental isolation that automatically adapts to upstream services

The same API supports multiple scenarios in the same environment, and there are priorities.

Mock rules relate to business systems, such as line of business, environment, supplier, supplier's API, etc.

The number of Mock request calls is counted, and excess circuit breakers and alarm are supported.

Supports logging and visual queries for Mock calls.

Rule configuration and management

It mainly includes business line information configuration, environment configuration, supplier configuration, supplier API configuration, Mock rule configuration. The relationship between business information is as follows:

1. "Business line" refers to the types of business, such as domestic air tickets, international air tickets, train tickets, car rental, pick-up and shuttle, etc.

2. "Environment" has two meanings:

One is the deployment environment, which is divided into dev development environment, qa test environment, sim pre-release environment and prod production environment, which can be understood as the following four isolated clusters.

Second, environmental isolation is carried out in order to distinguish multiple projects in the qa environment, such as the open platform code is kfpt and the passenger code is cjr.

3. "supplier" refers to all kinds of businesses with business access, and merchants can belong to a certain line of business.

4. "supplier" API means a series of HTTP or HTTPS-based interfaces provided by the supplier.

5. "MOCK rules" refer to rules configured for emulation or proxy of vendor interfaces for subsequent rule matching and return response information. MOCK rules belong to a vendor API as well as to an environment.

6. "scenario" is used to distinguish the same vendor API and different scenarios in the same environment. It is divided into two categories: general scene and concrete scene. When matching rules, it is preferred to match the concrete scene, and if the concrete scene does not match successfully, then the general scene matching is carried out.

Matching of response rules and response process

The process of rule matching and content response is as follows:

1. Rules are loaded and refreshed. After receiving a call from the internal system, it will determine whether the current rule cache is empty. If it is empty, all available MOCK rules will be loaded into the cache.

two。 The environment isolation identification is adaptive, and the internal services are usually deployed in the environment isolation mode. The environment isolation identification (envTag) will affect the matching of rules.

3. Rule matching, matching rules according to the requested URL, which may eventually match multiple rules. The matching rules are divided into two groups: concrete scene rules and general scene rules. The MOCK rule for the concrete scenario is matched according to the request parameters and is returned if it is hit. The MOCK rules for general scenarios are matched according to the request parameters and are returned if they are hit.

4. The result response is that if there is no match to the Mock rule, the default error message is returned directly. If the Mock rule is matched, first determine whether it is the Mock type or the Proxy type. For the Mock type, the status code and response content will be returned according to the configuration of the rule. If it is the Proxy type, the actual API of the provider will be called first and the obtained content will be returned to the caller. The number of calls on the day of the interface is displayed. If the threshold is exceeded, an alarm will be triggered and a service circuit breaker will be carried out.

Main Feature

1. Multiple matching conditions

Support for parameter extraction and matching according to header, param, JsonPath, body and other methods.

2. Hot entry into force of Mock rules

When new or modified Mock rules are added or modified, they will come into effect to achieve what you get. When the message is added or modified, the aspect of the rule change will be triggered, and then the rule change message will be sent through RocketMQ. The message will be sent in the form of broadcast. API Server will listen to the message and trigger the refresh of the rule when it is received.

3. Environmental isolation support

Internal gateway services are usually deployed in an environment-isolated manner, and we add an envTag attribute to the HttpHeader to pass the environment identity. It determines whether the envTag is empty. If it is empty, it does not reassemble the URL. If it is empty, the {env} part of the above URL will be replaced with the actual corresponding envTag.

Environmental isolation is mainly achieved in two steps:

At the level of our access gateway, the environment isolation ID envTag from the upstream is automatically extracted and transferred through join-common, and it is written to HTTP Header.

After receiving the request in API Server, we will determine whether the request carries the envTag logo. If we do, we will replace the {env} part of the URL with the actual corresponding envTag, and finally match it to the rules corresponding to the environment. If you do not carry envTag, it will match the default environment rules.

4. Multi-scene support

Each rule corresponds to an environment and a vendor interface, but it is divided into scenarios such as request success and request failure.

Conflicts occur when multiple people develop and test in the same project

In order to deal with this problem, we put forward the concept of "scene", which is divided into general scene and concrete scene:

The generic scenario is used to deal with normal requests. It usually releases the Proxy switch and requests directly to the vendor's interface.

The concrete scenario is used to correspond to a specific Case, such as the query of one adult and one child from Beijing to Shanghai. We match it with more detailed parameters.

Priority is given to matching the rules of the concrete scene above the matching level, and the rules of the general scene will not be matched until the match fails.

5. Out-of-limit fuse and alarm

Check according to the upper limit of the request set at the supplier API level. If the request for the day exceeds the limit, the rule will be degraded and an alarm message will be sent through WeCom.

6. Automatic encryption and decryption of messages

The message transmission of some suppliers is in the form of ciphertext. In the JARVIS system, according to the corresponding supplier, it is plaintext when editing, and it will be encrypted into ciphertext according to the protocol when saving.

7. Request logging and query

Request messages, response messages, hit rules and other information are recorded for all requests. Due to the large size of messages and large call volume, we use ElasticSearch to store them.

Part 4 project actual combat

Currently, all vendor interfaces have been proxied in the development and test environment:

1. Domestic open platform development support

Recently, we have an open platform for air tickets in China, and the standard connection is provided by us in the early stage, and the interface is not fully realized by the supplier. We have generated all the Mock data according to the documents and customized Mock rules for various scenarios of each interface, ensuring the development progress of the project and achieving multi-scene coverage.

two。 Summer stress test support

Recently, a summer stress test was carried out, during which the access to external suppliers was isolated through the Mock function, and the response time under different conditions of the supplier interface was simulated by setting the response delay time.

Part 5 follow-on roadmap

Subsequent major improvements and optimizations are planned in the following areas:

The supplier interface management realizes the definition and management of the interface Schema and verifies the request parameters and response contents.

Increase templating response, reduce manual configuration, and improve use efficiency.

Improve the statistical system to achieve the visualization of resource usage.

Ease of use optimization, collect the problems encountered in the process of use for continuous improvement, so as to be available, easy to use, easy to use.

Part 6 conclusion

At present, international air tickets, domestic air tickets, pick-up and pick-up machines and other services are all connected to the JARVIS system, have also gone through the development and testing process of several large projects, and have made many optimizations in terms of performance and usability. At present, there is still a lot of room for improvement, and we will continue to improve it.

At this point, the study on "the design and implementation of API resource isolation system" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.