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

In view of how to use API Gateway in micro-service practice, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

When you decide to use an application as a set of microservices, you need to decide how the application client interacts with the microservice. In monolithic programs, there is usually only one set of redundant or load-balanced service delivery points. In the micro-service architecture, each micro-service exposes a set of fine-grained service delivery points. Let's take a look at how it affects client-to-server communication and propose a method of API Gateway.

Introduction

Suppose you are developing a native mobile client for online shopping applications. You need to implement a product final page to display product information.

For example, the following figure shows the information you see when you slide the final page of the product on the Amazon Android client.

Although this is a smartphone application, the final page of this product shows a lot of information. For example, there is not only basic product information (name, description, and price), but also the following:

Number of items in the shopping cart

Order issuing history

User comments

Low inventory warning

Express delivery option

A variety of recommendations, including products that are often purchased with this item, products purchased by other customers who buy the item, and which other products have been browsed by the customer who bought the product.

Optional shopping options

When using a monolithic application architecture, a mobile client will obtain this data through an REST request (GET api.company.com/productdetails/productId). A load balancer distributes requests to one of multiple application instances. The application will query various databases and return the request to the client.

In contrast, if the micro-service architecture is adopted, the data on the page will eventually be distributed on different micro-services. Here are some micro-services that may be related to the final page data of the product:

Shopping cart service-number of items in the shopping cart

Order placing Service-order History

Classified services-basic product information, such as name, picture and price

Comment service-user comments

Inventory service-low inventory warning

Express delivery services-express delivery options, deadlines, costing from different express API

Recommendation service-recommendation product

We need to decide how mobile clients access these services. Please look at the following ways

Direct client-to-microservice communication

In theory, a client can initiate a request directly to any one of multiple microservices. Every microservice has an external server (https://serviceName.api.company.name)). This URL may be mapped to the load balancer of the microservice, which forwards the request to a specific node. In order to search for product details, the mobile side needs to send requests to the above micro-services one by one.

Unfortunately, this scheme has many difficulties and limitations. One of the problems is that the demand of the client does not match the number of fine-grained API exposed by each micro-service. As shown in the figure, the client needs 7 separate requests. In more complex scenarios, more requests may be required. For example, Amazon's final product page requests hundreds of microservices. Although a client can initiate many requests through LAN, it will be inefficient on the public network, especially on the mobile Internet. This solution can also lead to very complex client-side code.

Another problem is that the protocols that clients request microservices directly may not be web-friendly. One service may use Thrift's RPC protocol, while another service may use the AMQP message protocol. None of them are browsing or firewall friendly and are preferably used internally. Applications should use protocols like HTTP or WEBSocket outside the firewall.

Another drawback of this scheme is that it is difficult to reconstruct micro-services. Over time, we may need to change the current segmentation scheme for system microservices. For example, we might need to merge two services or split a service into multiple services. However, if the client interacts directly with the microservice, this refactoring is difficult to implement.

Because of the above three problems, the way that the client communicates directly with the server is seldom used in practice.

Adopt an API Gateway

Generally speaking, a better solution is to adopt the API Gateway approach. API Gateway is a server, or the only node that enters the system. This is very similar to the Facade pattern in object-oriented design patterns. API Gateway encapsulates the architecture of the internal system and provides API to each client. It may also have other functions, such as authorization, monitoring, load balancing, caching, request fragmentation and management, static response processing, and so on. The following figure shows an API Gateway that adapts to the current architecture.

API Gateway is responsible for request forwarding, composition, and protocol conversion. All requests from the client go through the API Gateway and are then routed to the corresponding microservice. API Gateway will often process a request and aggregate the results of multiple services by invoking multiple microservices. It can convert between web protocol and non-Web-friendly protocol used internally, such as HTTP protocol and WebSocket protocol.

API Gateway can provide a customized API to the client. It exposes a coarse-grained API to mobile clients. Take the usage scenario of the final product page as an example. API Gateway provides a service provider point (/ productdetails?productid=xxx) that enables mobile clients to retrieve all the data on the final page of the product in a single request. API Gateway processes this request and returns the result by invoking multiple services, involving product information, recommendations, reviews, and so on.

A good example of API Gateway is Netfix API Gateway. Netflix streaming service provides hundreds of different micro-services, including televisions, set-top boxes, smartphones, game systems, tablets and so on. At first, the Netflix view provides an API for the whole scene. However, they find this form difficult to use because it involves a wide variety of devices and their unique needs. Now, they use an API Gateway to provide fault-tolerant API with code for different types of devices. In fact, an adapter processes an average of six to eight back-end services per request. Netflix API Gateway processes billions of requests every day.

Advantages and disadvantages of API Gateway

As you might expect, adopting API Gateway also has both advantages and disadvantages. One of the biggest benefits of API Gateway is that it encapsulates the internal structure of the application. It is easier for the client to interact directly with gatway than to invoke the specified service. API Gateway provides each client with a specific API, which reduces the number of communications between the client and the server and simplifies the client code.

API Gateway also has some drawbacks. It is a highly available component that must be developed, deployed, and managed. There is another problem, which can become a bottleneck in development. Developers must update API Gateway to provide new service providers to support newly exposed microservices. API Gateway must be updated as lightweight as possible. Otherwise, developers will queue up for updating Gateway. However, in addition to these shortcomings, API Gateway is effective for most applications.

Implement an API Gateway

Now that we know the motivations and pros and cons of adopting API Gateway, let's take a look at what needs to be considered when designing it.

Performance and scalability

Only a few companies need to deal with a scale the size of Netflix, processing billions of requests every day. However, for most applications, the performance and scalability of API Gateway are also very important. Therefore, it makes sense to create an API Gateway that supports synchronous, non-blocking IZP O. There are different technologies that can be used to implement an extensible API Gateway. On JVM, a framework based on NIO technology, such as Netty,Vertx,Spring Reactor or JBoss Undertow, is adopted. Node.js is a popular non-JVM platform, which is based on Chrome's JavaScript engine. One alternative is NGINX Plus. NGINX Plus provides a mature, scalable, high-performance web server and reverse proxy, which are easy to deploy, configure and redevelop. NGINX Plus can manage authorization, permission control, load balancing, caching, and provide application health check and monitoring.

Adopt reactive programming model

For some requests, API Gateway can handle them by routing the request directly to the corresponding back-end service. For other requests, it needs to invoke multiple back-end services and merge the results to process. For some requests, such as the product final page request, the requests to the back-end service are independent of each other. To minimize response time, API Gateway should process independent requests concurrently. However, sometimes there are dependencies between requests. API Gateway may need to authenticate the request through the authorization service before routing to the back-end service. Similarly, in order to get a customer's product wish list, you need to get the user's information first, and then return the product information on the list. One such API component is Netflix Video Grid.

Using the traditional synchronous callback method to implement API merge code will get you into the nightmare of callback functions. This code will be very difficult and difficult to maintain. An elegant solution is to implement it in a reactive programming mode. Similar response abstractions implement CompletableFuture for Scala's Future,Java8 and Promise for JavaScript. Based on Microsoft. Net platform is Reactive Extensions (Rx). Netflix created RxJava for the JVM environment to use their API Gateway. Similarly, the JavaScript platform has RxJS, which can run on browsers and Node.js platforms. Reactive programming can help to quickly realize an efficient API Gateway code.

Service invocation

A micro-service-based application is a distributed system and must adopt the mechanism of communication between threads. There are two ways to communicate between threads. One is to use asynchronous mechanism, message-based approach. Such implementations include JMS and AMQP. Others, such as Zeromq, belong to direct communication between services. There is also a synchronous mechanism for inter-thread communication, such as Thrift and HTTP. In fact, a system will use both synchronous and asynchronous mechanisms. Because it can be implemented in many ways, API Gateway needs to support a variety of communication methods.

Service discovery

API Gateway needs to know the IP and port of each microservice. In traditional applications, you might hard-code these addresses, but in today's cloud-based micro-service applications, this will be a simple problem. The basic service usually uses a static address, which can be specified by the operating system environment variable. However, it is not so easy to detect the address of the application service. Application services usually assign addresses and ports dynamically. Similarly, the instance of the service will change dynamically as a result of expansion or upgrade. Therefore, API Gateway needs to adopt systematic service discovery mechanism, either server-side discovery or client-side discovery. This part will be described in more detail in a subsequent article. If the client discovery service is used, API Gateway must query the service registry, that is, the database of the microservice instance address.

Failed to process part

Another issue to consider in implementing API Gateway is partial failure. This problem occurs in a distributed system when one service invokes another service times out or is unavailable. API Gateway should not be blocked and wait for downstream services indefinitely. However, how to deal with this failure depends on specific scenarios and specific services. For example, if the recommendation service module on the product details page is not responding, then API Gateway should return the rest of the information to the user because it is also useful. The recommended part can be returned empty or the fixed top 10 can be returned to the user. However, if the product information service is not responding, then API Gateway should return an error to the client.

When the cache is valid, API Gateway should be able to return the cache. For example, because product prices do not change frequently, API Gateway should return the value in the cache when the pricing service is not available. This type of data can be cached by API Gateway itself or by external caches such as Redis or Memcached. API Gateway ensures that system errors do not affect the user experience by returning cached data or default data.

Netflix Hystrix is a very useful library for implementing remote service invocation code. Hystrix records calls that exceed a preset limit. It implements the circuit break pattern so that the client can be stopped from the endless wait of an unresponsive service. If the error rate of a service exceeds the preset value, Hystrix will interrupt the service and all requests will be invalidated immediately for a period of time. Hystrix can define a fallback operation for request failure, such as reading the cache or returning default values. If you are using JVM, you should consider using Hystrix. If you are using a non-JVM environment, you should consider using libraries with similar features.

For most micro-service-based applications, it makes sense to implement an API Gateway, which is like a service provider point into the system. API Gateway is responsible for request forwarding, request composition, and protocol conversion. It provides a custom API to the application client. API Gateway can cover up errors in the back-end service by returning caches or default values. In

This is the answer to the question about how to use API Gateway in micro-service practice. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.