Abstract: This article discusses the role of API gateways in hosting the rapidly evolving API ecosystem.

The preface

API economic ecological chain has been covered in the global scope, the vast majority of enterprises have gone on the road of digital transformation, API has become the core carrier of enterprises to connect business, and generate huge profit space. The rapid growth in API size and usage has brought more architectural and modal challenges to enterprise IT. The next part of this article looks at the role that API gateways play in hosting the existing, rapidly evolving API ecosystem.

What is the API

An Application Programming Interface (API) is a contract by which the different components of a software system join together. A simple example: every time you log in WeChat, you need to provide account information to access, WeChat provides this authentication carrier is an API. API has been everywhere, finance, IT, Internet of Things, etc., the development trend is quite rapid, invisible through our life.

Over the years, there have been several common trends in API iterations:

1. The number of API openings continues to increase

There’s no doubt that as companies evolve in terms of data and microservices, APIs from different domains are emerging. Back in 2014 ProgrammableWeb predicted that the API vector would reach 100,000 to 200,000 and continue to grow. The increase in the number of API developments presented opportunities for the edge system, which in turn led to the emergence of API gateways. Large-scale API management system becomes the core development trend.

Image Source: The API Economy Disruption and The Business of APIs, Nordic APIs

2. Diversified API service platforms

Originally designed for information exchange between network units of different applications, APIs have evolved into fast communication between services. With the continuous evolution of AI EI and IoT, and the continuous updating of API-dependent platforms, such as Web, Mobile, terminal, etc., more service systems will appear in the future.

3. Replace the service mode of the original enterprise gradually, and API is commodity

Selling computing, software and capabilities will gradually transform the sales model of the enterprise. The ability will be realized, the data value will be released, and new profits will be created by relying on different API management platforms.

Why was the API Gateway born

As the overall trend of APIs has evolved, each historical era has faced different challenges and the architecture has changed accordingly. Consider the following:

Image courtesy of API Economy From Systems to Business Services

From the most original “transport protocol communication” -> “simple interface integration” -> “message-oriented middleware” -> “standard REST”, we can see that the development of API tends to be more concise, integrated and standardized, which also encourages more system boundary components to emerge constantly. Under the background of carrying trillion level API economy, API Gateway was born.

The Gartner report states that API economy is not possible without proper API management tools. At the same time, the definition of life cycle of API management system is put forward: (1) Planning, Design, Implementation, Publication, Operation (Operation), Consumption (Consumption), Maintenance (Maintenance) and Retirement of APIs (Source: Magic Quadrant for Full Life Cycle API Management, Gartner, 2016-10-27

The API gateway runs through the entire process and provides rich administrative features.

  • High performance, horizontal scalability
  • High reliability, no interruption of business
  • Plug-in API security controls
  • Flexible data choreography
  • Fine flow control
  • API versioning
  • API data analysis
  • Efficient plug-in routing algorithm
  • Security authentication, anti-attack
  • API access control
  • Import and export Swagger

Core practices for API gateway design

To provide a high-performance API gateway architecture for reference, the design of the API gateway is divided into two planes, the API Consumer is called the data plane, the API Provider is called the management plane, which can effectively isolate the business request from the management request to a certain extent.

Let’s talk about the data plane first

The core design concept of API gateway is to ensure that the business on the data surface will not be interrupted. Due to the variety of services connected to API gateways and the uncontrollable design of client APIs and applications, it is difficult for you to require fault tolerance for every service and client accessed, especially for some more traditional services. This requires the gateway to ensure that it can handle each request normally and meet a high SLA (Serice-Level Agreement). Now the API gateway in the industry is divided into several types: Direct use of cloud services, NGINX series, Golang series, Java series, etc., there are a lot of choices, if you want to self-build, it is recommended to use NGINX system, the main considerations are as follows:

1. Support hot restart

Upgrade of a component on the data surface is a high risk action. An exception can result in a broken connection, a system exception, unless your front-end LB (load balancing) is capable of draining fast, and even then, it can result in a forced interruption of the requests being processed. So a hot restart of the data surface is critical.

2. Supports subscription-based dynamic routing

API routing changes relatively frequently and requires high timeliness. If regular synchronization scheme is adopted, tens of thousands of data will be synchronized at one time, which will slow down your system. Therefore, it is critical to add a subscription-based routing service center, so that we can quickly subscribe the routing data in ETCD and take effect in real time. And taking only incremental data doesn’t put too much pressure on performance.

3. Support plug-in management

Nginx provides a rich ecology in terms of plug-ins. Different API, different users need different processing flow is not completely consistent, if every request comes over in accordance with the same process, will bring related redundant operations. Plug-in management can improve performance to a certain extent and also ensure that processing chains can be added quickly during the upgrade process.

4. High performance forwarding ability

API gateways generally work in the multi-back-end API reverse proxy mode. Many self-developed API gateways are prone to bottlenecks in performance. Therefore, Nginx’s excellent performance and efficient throughput are its core competitiveness.

5. Stateless and scalable horizontally

API gateway is the collection of all requests of the whole system, which needs to be flexible and scalable according to the business scale. The service center and NGINX configuration management can be used to quickly add and delete existing clusters, and synchronize them to LVS, so as to realize rapid horizontal expansion.

Let’s talk about the management side

Compared with the data side, the constraints of the management side are not so obvious, and the management side should be more concerned with the storage and display of data. It is very important to define a good specification of the API from the beginning. As the most mainstream API description mode, Swagger has a very complete ecology. The entire API gateway model of AWS is built with reference to Swagger.

–

Core Architecture Practices

The implementation of the API gateway is described today in terms of flow control and routing traversal, and other related core designs will be provided in future articles.

Refined second level flow control

Minute-level and above flow control is relatively easy to handle, but it is a big challenge for system performance and processing capacity to upgrade to second-level flow control. There are many network flow control schemes, both synchronous and asynchronous have their own advantages, but they all encounter the same problem: performance and accuracy.

The following is the most common flow control scheme (cluster flow control), which uses Redis shared storage to record all flow control requests and access them in real time. There is an obvious problem with this architecture: when the number of clusters and requests is large, the cluster performance of Redis will become a big bottleneck.

We redesigned a set of API flow control architecture, mixing various flow control solutions and automatically adjusting them according to business requirements. Here we split into local flow control and cluster flow control. For flow-sensitive applications, the more accurate the flow control precision is, the higher the timeliness of the calculation, the lower the time dimension (second level), and the local flow control is required. For the API with long time cycle and low access frequency, we adopt cluster flow control to reduce the operation frequency of shared storage.

Note: The diagram above shows the specific flow control architecture. For integration with API Gateway, please refer to the API Gateway Architecture Panorama at the beginning of this section.

Local flow control

Single machine flow control, suitable for flow sensitive business. The API calculates the Hash values for the API-core cluster nodes, ensuring that each API can be loaded on one of the cluster nodes. Suppose there are three API-cores: A, B, and C. If the consistent hash value calculated by an API is node A, when the request is sent to node A, it will be directly forwarded from this node and A flow control value will be recorded. When the request is sent to node B/C, it will be forwarded to node A and A flow control value will be calculated and forwarded later. In this way, all flow control requests from the same API will be logged to an API-core. You can leverage the stand-alone flow control capabilities of API-Core. Single machine flow control algorithm is also plug-in, can use counting, leakage bucket, etc.

Of course, local flow control can also cause problems. When all the APIs are loaded on one node, if one API is particularly heavy, the load can be uneven. Also, if the flow control time is recorded very long, such as 12 cycles per day, the count time cycle is too long and is not suitable for local flow control.

Cluster flow control

Cluster flow control is suitable for the services with long counting cycle and low requirement of flow control precision. It is complementary to the local flow control. Different flow control is selected according to different businesses. The relevant flow control processing process is basically the same as the above local flow control, but the flow control data will be cached locally for a period of time before being uniformly reported to the flow control center.

Routing traversal algorithm based on tree structure

The main process of API gateway data surface includes routing matching algorithm, and all the routing data will be cached in ETCD. In order to improve the performance of data surface, the storage structure is very important. We divide the stored procedure into two parts: the domain name tree and the URI tree

From the first tree we can traverse the following domains: www.apig.com, test.com,.apig.com, and.com. Domain names are stored from the last “.” Start traversing. For example:

Matches: www.test.com, first matches COM, and continues to traverse test. If the match is successful, traverse WWW, and fails if the match is not successful. Match: test.apig.com, match com first, and continue traversing apig, match test, no test, traversal number, match target:.apig.com, the URL match is a pre-order match, which is opposite to the domain name matching pattern, but the traversing algorithm is the same.

conclusion

There are many mainstream open source API gateway architectures in the industry, but open source software has a common feature: magnitude, security, operation and maintenance analysis is relatively deficient, and to really meet the requirements of production environment, it also needs to invest high research and development costs. It is very important to find a perfect API management solution for the realization of enterprise ability.

Huawei Cloud API Gateway Service provides a complete API life cycle management solution, supporting a variety of usage scenarios, providing convenient management services. Make the process of API on-line, release, management and final sale no longer complicated, and quickly realize the realization of enterprise capability. Welcome to experience: Huawei cloud -API gateway

Welcome to continue to pay attention to Huawei cloud DevCloud, search the official account: HWDevCloud, get more dry goods information!

Click on the attention, the first time to understand Huawei cloud fresh technology ~