Design and Implementation of API Resource Isolation System


(Horsehoneycomb technology original content, public ID: mfwtech)

Part 1 Background

Large transport business needs external supply chain to dock air ticket, train ticket, car rental, shuttle and other business. Most of the supplier’s data interface communicates through HTTP, HTTPS and other protocols.

In order to ensure development progress and support multi-scenario support for integration testing, we often need to MOCK the vendor interface. Previously, we had no unified control over the external interface calls in the development environment and test environment, and could not realize the call switch, nor could we make statistics and restrictions on the amount of calls.

In order to solve these problems, we design an API resource isolation system.JARVIS_ (Join Api Resource Virtual Isolation System), I hope it can help us solve the problem of resource control like Jarvis in Iron Man.

Part 2 Design Principles

  1. Graphical operation, providing management background, to develop and test the interaction of students to be friendly.
  2. No intrusion to the business, no need to modify the business system code, to ensure that the test code is consistent with the release.
  3. Business Linkage, which serves business, needs to provide the necessary business linkages.
  4. It supports rich matching rules and can be used in most usage scenarios.
  5. The management rules can take effect immediately.
  6. Request response is traceable, providing detailed logging and query functions.

Design and Implementation of Part 3

Overall thinking

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

Design and Implementation of API Resource Isolation System

The resource management and control system consists of two parts:

  1. Config CenterIt mainly implements the configuration management of MOCK rules corresponding to business lines, environment, suppliers, suppliers API and API.
  2. API ServerMainly responsible for receiving requests, matching MOCK rules, responding to MOCK rules and logging.

Key functions

  • Support cluster deployment with configuration center and API server separated structure
  • Simultaneous support for both simulated response and proxy access
  • Supporting Mock Rules to take effect immediately after modification
  • Automatically adapted environment isolation for upstream services
  • The same API supports multiple scenarios in the same environment and has priority differentiation
  • Mock rules relate business systems, such as business lines, environments, suppliers, suppliers’APIs, and so on.
  • It counts the number of calls to a Mock request and supports over-fusing and over-alarming.
  • Logging and visual queries for Mock calls are supported.

Rule Configuration and Management

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

Design and Implementation of API Resource Isolation System

1. “Business Line” refers to business types such as domestic air tickets, international air tickets, train tickets, car rental, shuttle flights, etc.

2. “Environment” has two meanings:

  • The first is the deployment environment, which is divided into dev development environment, QA Test environment, SIM pre-delivery environment and prod production environment. It can be understood as the following four isolated clusters.
  • Secondly, in order to distinguish multiple projects in the QA environment, environmental isolation is carried out, such as open platform code kfpt, passenger code cjr.

3. “Supplier” refers to a variety of businesses with business access, which can be attributed to a line of business.

4. “Vendor” API refers to a series of HTTP or HTTPS-based interfaces provided by vendors.

5. “MOCK Rules” refers to rules configured to simulate or proxy vendor interfaces for subsequent rule matching and return response information. MOCK rules belong to a vendor API and also to an environment.

6. “Scene” is used to distinguish different scenarios in the same vendor API under the same environment. It can be divided into two categories: general scenario and concrete scenario. When matching rules, the concrete scenario is matched first, and if the concrete scenario is not matched successfully, the common scenario matching is carried out.

Matching and Response Processes of Response Rules

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

Design and Implementation of API Resource Isolation System

1. Rule loading and refreshing, after receiving the call from the internal system, will determine whether the current rule cache is empty, if it is empty, will load all available MOCK rules into the cache.

2. Environmental isolation identification is adaptive. Internal services are usually deployed in an environment isolation manner. Environmental isolation identification (envTag) can affect the matching of rules.

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

4. Result response, if no Mock rule is matched, returns the default error information directly. If a Mock rule is matched, the Mock type or Proxy type will be judged first. For Mock type, the state code and response content will be returned according to the configuration of the rule. For Proxy type, the real interface of the supplier will be invoked first, and then the acquired content will be returned to the caller. The number of calls on the interface day is displayed. If the threshold is exceeded, the alarm will be triggered and the service will be fused.

Main Features

1. Multiple Matching Conditions

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

2. Mock Rules Entry into Force Thermally

Mock rules will take effect when they are added or modified to achieve WYG. After adding and modifying the message, it will trigger the aspect of rule change, and then send the rule change message through RocketMQ. The message will be sent in the form of broadcast. API Server will monitor the message and trigger the rule refresh after receiving it.

3. Environmental isolation support

Internal gateway services are usually deployed in an environment-isolated manner. We use the envTag attribute in HttpHeader to pass the environment identification. It determines whether envTag is empty, if it is empty, it does not reassemble the URL, and if it is empty, it replaces the {env} part of the above URL with the actual corresponding envTag.

Design and Implementation of API Resource Isolation System

Environmental isolation is mainly achieved in two steps:

  • At the level of our access gateway, envTag, an environment isolation identifier from upstream, is automatically extracted and passed through join-common and written into HTTP Header.
  • When we receive the request in API Server, we will determine whether the request carries the envTag identity. If the request carries, the {env} part of the URL will be replaced by the actual corresponding envTag, which will eventually be matched to the rules corresponding to the environment. If envTag is not carried, the default environment rules are matched.

4. Multi-scenario support

  • Each rule corresponds to an environment and a vendor interface, but it can be divided into several scenarios, such as request success, request failure, and so on.
  • Conflicts arise when multiple people develop and test on the same project

To deal with this problem, we propose the concept of “scenario”, which is divided into general scenario and concrete scenario.

  • The generic scenario is used to respond to normal requests. It usually opens the Proxy switch and requests directly to the supplier’s interface.
  • Representational scenarios are used to query a specific case, such as Beijing Flying Shanghai Adult 1 Child, and we match them with more detailed parameters.

At the matching level, the rule of matching concrete scenes is given priority, and if the matching fails, the rule of matching general scenes will continue.

5. Overrun fuse and alarm

According to the request ceiling set at the supplier API level, if the request exceeds the limit on that day, the rules will be degraded, and the alarm message will be sent through the enterprise Wechat.

6. Automatic Encryption and Decryption of Messages

Some vendors’message transmission is in the form of ciphertext. In JARVIS system, according to the corresponding vendors, the message is plaintext when edited and encrypted as ciphertext when saved according to the protocol.

7. Request Logging and Query

All requests will record the request message, response message, hit rule and other information. Because of the large size of the message and the large amount of calls, we use Elastic Search for storage.

Part 4 Project Practice

Currently, all vendor interfaces have been brokered in the development and testing environment:

1. Domestic Open Platform Development Support

Recently, in our domestic ticket open platform, we provided standard connection in the early stage, and the interface was not fully implemented by the supplier. We generated all the Mock data according to the document and customized the Mock rules for various scenarios of each interface, which guaranteed the development progress of the project and realized the coverage of multiple scenarios.

2. Summer Stress Test Support

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

Part 5 Follow-up Roadmap

Follow-up main plans are to improve and optimize in the following directions:

  1. Vendor Interface ManagementIt implements the definition and management of interface Schema, and verifies the request parameters and response content.
  2. Increase template responseTo reduce manual configuration and improve the efficiency of use.
  3. Improving the Statistical SystemVisualize the use of resources.
  4. Easy to useTo collect the problems we encounter in the use process and make continuous improvement so as to make it usable, easy to use and easy to use.

Part 6 Concluding remarks

At present, JARVIS system has been integrated into international airline ticket, domestic airline ticket and shuttle business. It has also undergone several major project development and test process tests. It has also been optimized many times in terms of performance and availability. There is still a lot of room for improvement, and we will continue to improve it.

Finally, the Transportation Team is recruiting Java Architects. Interested students are welcome to send their resumes to [email protected]

Author: Anzidong, R&D technical expert of Honeycomb Transportation Team.

Design and Implementation of API Resource Isolation System

Recommended Today

SQL exercise 20 – Modeling & Reporting

This blog is used to review and sort out the common topic modeling architecture, analysis oriented architecture and integration topic reports in data warehouse. I have uploaded these reports to GitHub. If you are interested, you can have a lookAddress: recorded a relatively complete development process in my hexo blog deployed on GitHub. You can […]