0102-building microservices with API gateways

First, how mobile clients access these services

1.1, the client and the micro-service direct communication "rarely used"

In theory, a client can send a request directly to each micro-service. Each micro-service has a public endpoint (https://.api.company.name). The URL maps to the microservices load balancer, which is responsible for distributing requests between the available instances. In order to obtain product details, the mobile client will send requests to the N services listed above one after the other.

Unfortunately, there are challenges and limitations to this approach. One problem is that the client requirements and the fine-grained APIs exposed by each microservices do not match. In this example, the client needs to send 7 separate requests. In more complex applications, you may want to send more requests, and according to Amazon, they call hundreds of services when they display their product pages. However, the client sends many requests over the LAN, which can be inefficient on the public network and is simply not feasible on mobile networks. This approach also makes client-side code very complex.

Another problem with clients calling MicroServices directly is that the protocols used by some services are not friendly to the web. One service may use Thrift binary RPC, while another service may use the AMQP messaging protocol. Regardless of which protocol is not friendly to the browser or firewall, it is best to use it internally. Outside the firewall, applications should use protocols such as HTTP and WebSocket.

Another drawback of this approach is that it makes microservices difficult to refactor. Over time, we may want to change how the system splits into services. For example, we might merge two services, or split a service into two or more services. However, if the client communicates directly with the microservices, it is very difficult to perform such refactoring.

Due to the above three problems, the way the client communicates directly with the server is seldom used in practice.

1.2. Using API gateway to build MicroServices "recommended"

In general, using an API gateway is a better solution. An API gateway is a server or a unique node that enters the system. This is similar to the facade pattern in object-oriented design mode. The API Gateway encapsulates the architecture of the internal system and provides APIs to individual clients. It may also have functions such as authorization, monitoring, load balancing, caching, request fragmentation and management, and static response processing. Shows an API gateway that adapts to the current schema.

Richardson-microservices-part2-3_api-gateway

The API Gateway is responsible for service request routing, composition, and protocol conversions. All requests to the client go through the API Gateway first, and then it routes the request to the appropriate microservices. API gateways often process a request by invoking multiple microservices and merging the results. It can be converted between Web protocols, such as HTTP and WebSocket, and non-web-friendly protocols that are used internally.

The API Gateway can also provide a custom API for each client. Typically, it exposes a coarse-grained API to mobile clients. In the case of product details, the API gateway can provide an endpoint (/PRODUCTDETAILS?PRODUCTID=XXX) that allows the mobile client to obtain all the product details through a single request. API gateways process requests by invoking individual services (product information, recommendations, comments, and so on) and merging results.

The Netflix API Gateway is a good example of an API gateway. Netflix streaming services are available to hundreds of different types of devices, including TVs, set-top boxes, smartphones, gaming systems, tablets, and more.

Initially, Netflix tried to provide a common API for their streaming services. However, they found that this approach did not work well because of the unique needs of various devices. Today, they use an API gateway to provide customized APIs for each device by running the adapter code for specific devices. Typically, an adapter processes each request by calling an average of 6 to 7 back-end services. The Netflix API gateway processes billions of requests per day.

Second, the API gateway

2.1. Advantages and Disadvantages

The advantage is that it encapsulates the internal structure of the application. The client only needs to interact with the gateway without having to invoke a specific service. API gateways provide specific APIs for each class of clients, which reduces the number of interactions between the client and the application and simplifies client-side code.

Insufficient API gateways: Highly available components that need to be developed, deployed, and maintained. The API gateway becomes a development bottleneck. To expose the endpoints of each microservices, the developer must update the API gateway. The API Gateway update process is as simple as possible, otherwise, in order to update the gateway, developers will have to wait in line.

2.2. Implement API Gateway

1 "Performance and Scalability

Only a handful of companies have the size of Netflix, requiring daily processing of billions of of requests per day. However, for most applications, the performance and scalability of the API gateway are important. Therefore, it is reasonable to build an API gateway on a platform that supports asynchronous, I/O non-blocking. There are a number of different technologies that can implement an extensible API gateway. On the JVM, you can use a NIO-based framework, such as one of the Netty, Vertx, Spring Reactor, or JBoss undertow. A very popular non-JVM option is node. js, which is a platform built on the Chrome JavaScript engine.

Another method is to use NGINX Plus. NGINX Plus provides a sophisticated, scalable, high-performance Web server and an easy-to-deploy, configurable, and programmable reverse proxy. NGINX Plus can manage authentication, access control, load balancing requests, cache responses, and provide application-aware health checks and monitoring.

2 using the Responsive programming model
The API gateway processes a partial request by simply routing the request to the appropriate backend service, while processing other requests by invoking multiple backend services and merging the results. For some requests, such as multiple requests related to product details, their requests to the backend service are independent of the other requests. To minimize response time, the API gateway should concurrently execute separate requests.

Sometimes, however, there is a dependency between requests. Before the request is routed to the backend service, the API gateway may first need to invoke the legitimacy of the Authentication Service authentication request. Similarly, in order to obtain product information from a customer wish list, the API gateway must first obtain the customer profile that contains the information and then  about each product. Another interesting example of the API mix is the Netflix Video Grid.

Writing API mix code with a traditional asynchronous callback method will let you quickly fall into a callback hell. Code can become confusing, incomprehensible, and error-prone. A better approach is to use a responsive approach to write API Gateway code in a declarative style. Examples of responsive abstractions are the future in Scala, completablefuture in Java 8 and P romise in JavaScript, and reactive Extensions (RX), originally developed by Microsoft for the. NET platform. 。 Netflix created the RxJava for JVM, dedicated to their API gateways. In addition, there is RxJS for JavaScript, which can run either in the browser or in node. js. Using a responsive approach allows you to write simple but efficient API gateway code.

3 "Service invocation

A microservices-based application is a distributed system that must use an inter-process communication mechanism. There are two types of interprocess communication mechanisms to choose from. One is the use of asynchronous, message-based mechanisms. Some implementations use message proxies such as JMS or AMQP, while other implementations (such as ZEROMQ) have no proxies and direct communication between services.

Another type of interprocess communication is a synchronization mechanism such as HTTP or Thrift. Typically, one system uses both asynchronous and synchronous types. It may even use multiple implementations of the same type. In summary, API gateways need to support multiple communication mechanisms.

4 "Service discovery

The API gateway needs to know the location (IP address and port) of each micro-service it communicates with. In traditional applications, this location may be hardwired, but in modern, cloud-based microservices applications, this is not an easy problem to solve. Infrastructure services, such as message brokers, typically have a static location that can be specified through an OS environment variable. However, determining the location of an application service is not so simple. The location of application services is dynamically allocated, and a set of instances of a single service can change dynamically as auto-scaling or upgrades occur.

In summary, like other service clients in the system, API gateways need to use the system's service discovery mechanism, either server-side discovery or client discovery. If the system uses client-side discovery, then the API gateway must be able to query the service registry, which is a database that contains all the microservices instances and their locations.

5 "Handling Local failures

When implementing an API gateway, you also need to deal with problems with local failures. This problem occurs in all distributed systems. This problem occurs when a service invokes another service, and the latter responds slowly or is not available. API gateways cannot be blocked because they wait indefinitely for downstream services. However, how to handle the failure depends on the particular scenario and which service failed. For example, in the product detail scenario, if the referral service is unresponsive, the API gateway should return the other content of the product details to the client because they are still useful to the user. The recommended content can be empty or replaced with a fixed TOP 10 list. However, if the product information service is unresponsive, the API gateway should return an error message to the client.

If the cached data is available, the API gateway can also return cached data. For example, the API gateway can return cached price data, given that the product price does not change frequently and if the price service is unavailable. The data can be cached by the API gateway itself or in an external cache such as Redis or Memcached. By returning default data or caching data, the API gateway ensures that system failures do not affect the user experience.

Netflix Hystrix is an exceptionally useful library for writing code to invoke remote services. Hystrix pauses a call that exceeds a specific threshold. It implements a "circuit breaker (Circuit breaker)" mode that prevents clients from waiting unnecessarily for unresponsive services. If the error rate of the service exceeds the set threshold, then Hystrix initiates the breaker, and all requests fail immediately and last for a certain amount of time. Hystrix allows a user to define a backup operation after a failed request, such as reading data from the cache, or returning a default value. If you are using the JVM, then you should consider using Hystrix; If you are using a non-JVM environment, you can use a library with the same functionality.

Summarize
For most microservices-based applications, it is necessary to implement an API gateway as the only entry for the system. The API Gateway is responsible for service request routing, composition, and protocol conversions. It provides a custom API for each application client. The API gateway can also fail by returning cached data or the default data masking back-end service.

Original address: http://blog.daocloud.io/microservices-2/

English Address: Https://www.nginx.com/blog/building-microservices-using-an-api-gateway

0102-building microservices with API gateways