preface
As systems grow in size and complexity, microservice architectures become mainstream. Problems arise when a single application is broken down into many micro-service applications. Some functions that are not strongly relevant to the business, such as permission control, log output, data encryption, fuse limiting, etc., are required by every microservice application, so there is a lot of repetitive code implementation. In addition, due to the iteration of the system and the replacement of personnel, the implementation details of these functions in various micro-services are greatly different, resulting in higher maintenance costs. On the other hand, interface management, which was easy to do under single application, is not centralized after service separation. It is impossible to count existing interfaces, interface definitions, and running status.
Gateways are designed to solve these problems. As the core infrastructure in micro service system, generally need to have the interface management, protocol adapter, current limiting fuse, safety protection, and other functions, various open source gateway products (such as zuul) provides excellent high extensibility architecture, can easily realize we need some function, such as authentication, logging, monitoring, current limiting fuse, etc.
However, these features alone are not enough. The internal system of an enterprise is generally heterogeneous and has interfaces of various protocols, while the external service interface is still HTTP protocol. Therefore, protocol transformation is a very real requirement. There is also the ability of data aggregation. Open source products provide one-to-one routing functions, but do not directly provide the ability of aggregation and orchestration. In the actual development, it is very common to aggregate some small interfaces. If you need to write code and release it will be very tedious, and the upgrade of small interfaces will have to be synchronized in the future.
Therefore, we refer to the excellent design concept of The SpringCloud gateway product to support multiple downstream protocols, support service choreography, and provide a visual configuration platform on the basic gateway function.
1 Technology selection
1.1 Comparison of Schemes
We choose Zuul1, Zuul2 and SpringCloud Gateway, three mainstream API Gateway frameworks in Java microservice system, and compare them in aspects of threading model, protocol adaptation, fusing flow limiting, and service choreography.
The advantages and disadvantages of the three frameworks are obvious, but they lack the support of Dubbo and the ability of data aggregation (service choreography), so we borrowed their excellent architecture and developed our own business gateway. Let’s take a look at the system architecture of Zuul2.
1.2 System Architecture
This is a typical gateway architecture consisting of three functional filters and exception filters. Inbound Filters are mainly responsible for verifying, processing, and intercepting requests. Endpoint Filter is responsible for routing and calling downstream interfaces. Outbound Filters are responsible for verifying, processing, and log monitoring response. Exception Filter is responsible for Exception handling in function Filter. This architecture is simple, clear, and extensible. It can be easily modularized, and there is no coupling between each module (Filter), which is similar to the independence of Plugin.
2 Architecture
Take a look at the gateway architecture.
The checksum interception layer provides the basic capabilities of a gateway, implemented through Inbound and Outbound Filters, and is infinitely scalable.
The service scheduling layer and interface communication layer provide core capabilities, implemented through EndPoint Filter.
Exception processing is processed by an Exception Filter, which is then rerouted to Outbound Filters.
3. Innovation
3.1 Protocol Conversion
The company’s internal RPC services are developed on the basis of the DuBBo solution. A large number of micro-services use duBBO protocol, and the gateway must support the forwarding of DuBBO interface. Dubbo’s generalized call is well suited to the gateway scenario, requiring both interface definition and interface configuration (ZkAddress, Group, Version, and so on). Filling in the interface definition information manually is tedious. To avoid configuration errors caused by human factors, the gateway pulls and scans the JAR package according to the Maven coordinates of the JAR package to obtain the specific method signature of the interface.
The gateway manages all Dubbo references, monitors push messages of the configuration platform, and dynamically manages the life cycle and operating parameters of The Reference, such as adjusting the timeout period of the Dubbo interface and upgrading the version of the Dubbo interface in real time. All Reference objects are delivered to the executor after initialization to ensure the execution efficiency of the interface.
3.2 Service Orchestration
In microservice architecture, a complete business process will be realized through the collaboration between microservices, which is service choreography. Orchestration involves RPC, distributed transactions, etc., which requires a perfect orchestration framework to support.
The implementation of choreography needs to address four key points:
- Complex dependencies: there are M:N dependencies
- Execution timing: How to parallelize, how to avoid blocking wait
- Data passing: How do you build downstream parameters from upstream data
- Exception handling: Should an exception interrupt the entire service or degrade the service
Complex dependencies and execution timing are the difficulties.
Complex dependencies: Take the idea of service autonomy by defining the services that each service cares about. Through analysis, it is found that this graph is a directed acyclic graph, and unreasonable dependence can be found through loop formation detection.
Execution timing: A cooperation-oriented approach is adopted to control the interaction of each service through the sequence of message interactions. The services involved in the interaction are all peer without centralized control. As shown in the figure above, all services share event notifications through the message bus to decide whether to execute themselves.
3.3 Embedded Gateway
Why embedded? What problems are to be solved?
The main business interface usually comes with a number of small interfaces that are called and returned to the caller along with the data from the main interface. The main business interface is generally stable, but the iteration of the small interface is relatively frequent. At this point, because iteration of the small interface leads to modification of the project where the main business interface resides, it becomes redundant. We hope that the small interface that is not coupled with the main business interface can be passed through to achieve the goal of upgrading the small interface and having no perception of the main interface.
We abstracted the core capabilities of the gateway into a JAR package, including configuration synchronization, service choreography, and protocol transformation, called “embedded gateway”. The host project introduces the embedded gateway and changes the place where the downstream interface is called to the embedded gateway’s execution entry. All that is left is to configure the platform to configure the information related to this interface. If it is a Dubbo interface, you can also drop the dependent API JAR package, because the generalization call does not need to import the JAR package.
Embedded gateway provides the capability of host engineering transmission transformation, which can realize the pure data transmission of non-strongly coupled downstream interfaces, reduce the business complexity of host engineering, and enjoy all the capabilities of the gateway system.
4 High availability exploration
How to evaluate the strengths and weaknesses of a gateway product? Common performance indicators include throughput, time consuming, and error rate. There is one key metric: high availability, the fabled number of nines.
High availability covers a variety of internal and external uncertainties. Here is the gateway system’s efforts in high availability.
5 Landing Effect
5.1 the effect
After the gateway goes live, the most direct benefit is human efficiency. Because there is one less collaborative team, there is a corresponding reduction in development and testing time.
I chose several independent businesses for data analysis, saving about 27% of man-hours on the whole.
Note: Saving time includes “API layer service team development, self-test joint commissioning, and corresponding QA time”. Note: “Commodity sales” is decouped from the main interface through the embedded gateway, and there is no release of the main project in the iterative process.
5.2 Troubleshooting
As the gateway has the ability to adjust data, it provides a means of fast recovery for some faults caused by data irregularities or missing.
Fault cases:
6 Typical Cases
1. Develop a pure pass-through interface
General: Write code that calls the downstream interface, defines the bean, and adds the result to the Response. Code iteration is required as fields are added downstream.
Gateway: Configure downstream services on the configuration platform, without defining beans, pure transparent transmission, and without any changes to add fields to downstream interfaces.
2. Activity home page configuration access interface, add a dimension of configuration, the configuration data provided by a new interface (data aggregation)
General: Write code that calls the new downstream interface and adds the result to response.
Gateway: Add a downstream service to the configuration platform and mount the result into Response without any changes for subsequent iterations.
3. Cross-domain solution of touch interface
General: ng forwarding is performed for downstream interfaces, or cross-domain processing is performed by downstream interfaces. There may also be XSS vulnerabilities when JSONP is used downstream.
Gateway: added/GW location configuration under company touch domain, developers do not need to consider cross-domain issues. It also supports JSONP and does XSS vulnerability defense.
4. Get a list of hotels from one interface and add review information for each hotel from another interface
General: call the first interface to get the list of hotels, after making a simple business judgment, loop call the second comment interface to the list, and add data to it.
Gateway: Define two downstream interfaces, set the second comment interface to depend on the “first hotel list interface”, and specify the field path to be used in a loop, and you can also specify the degraded content in case of failure.