(Hornet’s Nest Technology original content, public ID: MFWtech)

Part 1 background

Large transportation services need to connect with external supply chains of air ticket, train ticket, car rental, airport pickup and other services. Data interfaces of suppliers mostly communicate with each other through PROTOCOLS such as HTTP and HTTPS.

To ensure progress and support for multiple scenarios during integration testing, we often need to MOCK the vendor interface. Before, there was no unified control on the invocation of external interfaces in the development environment and test environment, so we could not realize the switch of invocation, nor could we conduct statistics and limit the amount of invocation.

In order to solve these problems, we designed the Join API Resource Virtual Isolation System (JARVIS), hoping that it could help us solve the problem of Resource management and control just like JARVIS in Iron Man.

Part 2 Design principles

  1. Graphical operation, provide 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, ensure that the test code and the release is consistent.

  3. Business relevance. This system serves the business and needs to provide the necessary business relevance.

  4. Supports rich matching rules, which can be used in most scenarios.

  5. The management rules can take effect immediately.

  6. Request response traceability, providing detailed logging and query functions.

Part 3 Design and implementation

The overall train of thought

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

The resource management and control system consists of two parts:

  1. Config Center: implements configuration management of business lines, environments, vendors, vendor apis, and MOCK rules corresponding to apis.

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

Key features

  • The configuration center and API server are separated, and cluster deployment is supported

  • Both simulated response and proxy access are supported

  • Mock rule modification takes effect immediately

  • Automatically adapt to environmental isolation of upstream services

  • The same API supports multiple scenarios in the same environment and is prioritized

  • Mock rules associate business systems, such as lines of business, environments, vendors, vendors’ apis, and so on

  • Counts the number of Mock requests called, and supports overrun fuses and overrun alarms

  • Logging and visual queries for Mock calls are supported.

Configure and manage rules

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

1. “Line of Business” refers to business types such as domestic air tickets, international air tickets, train tickets, car rentals, airport transfers, etc

2. “Environment” has two meanings:

  • One is the deployment environment, which is divided into dev development environment, QA testing environment, SIM pre-delivery environment, and PROD production environment, which can be understood as the following four isolated clusters.

  • Secondly, in the QA environment, environmental isolation was carried out to distinguish multiple projects, for example, the open platform code was KFPT and the passenger code was CJR.

3. “Supplier” refers to a variety of businesses that are connected to a business line

4. A “Vendor” API means a set of HTTP or HTTPS based interfaces provided by a vendor

5. “MOCK rules” are rules that are configured to emulate or proxy a vendor’s interface for subsequent rule matching and return response information. MOCK rules belong to a vendor API as well as an environment.

6. “Scenario” is used to distinguish different scenarios in the same vendor API and in the same environment, which can be divided into two categories: general scenario and concrete scenario. When matching rules, concrete scenario is matched first.

Response rule matching and response process

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

1. Rule load and refresh. Upon receiving the call from the internal system, it determines whether the current rule cache is empty, and if so, it loads all available MOCK rules into the cache.

2. Environment isolation Tag Adaptive. Internal services are usually deployed in environment isolation mode, and envTag affects rule matching.

3. Rule matching: Matches rules based on the requested URL. Multiple rules may be matched. The matched rules are divided into two groups: concrete scene rules and general scene rules. MOCK rules for representational scenarios match against request parameters and return if they hit. MOCK rules for generic scenarios match against request parameters and return if hit.

4. The result response returns the default error message if no Mock rule is matched. If the Mock rule is matched, the Mock or Proxy type is determined first. For the Mock type, the status code and response content are returned according to the configuration of the rule. If the Mock type is Proxy, the real interface of the supplier is called first and the obtained content is returned to the caller. Displays the number of calls on the interface in the current day. If the number exceeds the threshold, the alarm will be triggered and service fuse will be performed.

The main Feature

1. Multiple matching conditions

Supports parameter extraction and matching based on header, PARam, JsonPath, and body.

2. Mock rules take effect

Mock rules take effect when they are added or modified, and the implementation is what you get. When a message is added or modified, it triggers the section of the rule change, and then sends the rule change message through RocketMQ. The message is sent in the form of broadcast, and the API Server listens for the message and triggers the rule refresh after receiving it.

3. Environmental isolation support

Internal gateway services are typically deployed in environment isolation, and we pass the environment identity by adding an envTag attribute to the HttpHeader. It determines whether envTag is empty. If it is empty, the URL will not be reassembled. If it is empty, the {env} part in the URL will be replaced with the actual envTag.

Environmental isolation can be achieved in two steps:

  • At our access gateway level, the environment isolation identifier envTag from upstream is automatically extracted and passed via join-common and written to the HTTP Header.

  • After receiving the request, the API Server will determine whether the request carries envTag. If it does, the {env} part in the URL will be replaced with the actual envTag, and finally match the rules corresponding to the environment. If no envTag is carried, the default environment rules will be matched.

4. Multiple scenarios are supported

  • Each rule corresponds to an environment and a vendor interface, but can be divided into request success and request failure scenarios

  • Conflicts arise when multiple people are developing and testing on the same project

To deal with this problem, we put forward the concept of “scene”, which can be divided into general scene and concrete scene:

  • The name of the common scenario is used to respond to normal requests. Generally, the Proxy switch is released and the request is directly sent to the supplier’s interface

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

Above the matching hierarchy, the rules of concrete scenarios are matched preferentially. If the matching fails, the rules of general scenarios are matched.

5. Over-limit fusing and alarm

Verification is performed according to the request upper limit set at the supplier API level. If the request exceeds the limit on that day, the rule will be degraded and an alarm message will be sent through the wechat of the enterprise.

6. Automatically encrypt and decrypt packets

Some suppliers’ packets are transmitted in ciphertext. In JARVIS system, we edit the packets in plaintext according to the corresponding suppliers, and encrypt them into ciphertext according to the protocol when saving.

7. Request logging and query

All requests are recorded, such as request packets, response packets, and matching rules. ElasticSearch is used to store the packets because the packet volume is large and the request volume is large.

Part 4 Actual combat of project

Currently, all vendor interfaces are represented in the development and test environment:

1. Domestic open platform development support

Recently, we launched an open platform for domestic air tickets. In the early stage, we provided standard connection, but the interface was not fully realized by the supplier. We generated all Mock data according to the documents and customized Mock rules for various scenarios of each interface, ensuring the development progress of the project and realizing the coverage of multiple scenarios.

2. Summer stress test support

A recent summer stress test isolated access to external vendors with Mock functionality and simulated the response time of the vendor’s interface under different conditions by setting response latency.

Part 5 Follow-up Roadmap

The follow-up plan is to improve and optimize in the following directions:

  1. Supplier interface management, implement the definition and management of interface Schema, and realize the verification of request parameters and response content.

  2. Add template response, reduce manual configuration, improve efficiency.

  3. Improve the statistical system to realize the visualization of resource usage.

  4. Ease of use optimization, collection of problems encountered in the use of continuous improvement, so as to be usable, easy to use, easy to use.

Part 6 conclusion

At present, the international, domestic and airport ticket services have all been connected to JARVIS system, which has undergone the testing and development of several major projects and has been optimized for many times in terms of performance and availability. At present, there is still a lot of room for improvement, and we will continue to make improvements.

Finally, the transportation team is looking for a Java architect. If you are interested, please send your resume to [email protected]

Author: An Zidong, research and development technology expert of Hornet’s Nest transportation team.