The industry ramble about API Gateway

Reference Links:

Http://www.infoq.com/cn/news/2016/07/API-background-architecture-floo

APIGW In addition to ensure the exchange of data, but also to achieve identity authentication, anti-message replay and anti-data tampering, function call business authentication, response data desensitization, traffic and concurrency control, even based on the API call metering or billing.

First, Primeton 1, Application scenario category 1.1, Web-oriented app

Such scenes, in physical form similar to the front and back end separation, at this time the Web app is not a full-featured web app, but based on the scene customized, scene of the app.

1.2. For mobile apps

In this scenario, the mobile app is the user of the backend service, and the API GW also needs to assume a portion of MDM (here, mobile device management, not master data management) functions.

1.3, for partner OpenAPI

This kind of scenario, mainly in order to satisfy the business form to open up, with the enterprise external partners to establish the ecosystem, at this time the API GW need to increase the quota, flow control, token and so on a series of security control functions.

1.4, for partner Externalapi

This kind of scene, the industry to mention less, many times the construction of the system, are to meet the needs of enterprises ' own business, to achieve the enterprise's own business mapping. When the Internet form gradually affects the traditional enterprise, many systems will be to import traffic or content, rely on the ability of external partners, some typical examples are the use of "partner account Login", "use of third-party payment platform payment" and so on, which for the enterprise internal, are some external capabilities. At this point, the API GW need to be on the boundary, for the Enterprise internal Service unified Call external API for unified authentication, (multi-tenant form) authorization, and access control.

1.5. For IoT SmartDevice

This kind of scenario, the industry to mention less, but in traditional enterprises, especially industrial enterprises, sensors, physical equipment from industrial control protocol to IP conversion, resulting in information processing capacity of " Smart Products "in the process of being activated by the customer until the end of retirement, the transmission of information can no longer be based on VPN or enterprise internal leased line, resulting in a part of the physical link on the public network link. At this time, the API GW needs to meet is not the first three kinds of unidirectional data flow from the outside, nor is the fourth data flow from the inside out, "internal and external repair" bidirectional data flow, for enterprise systems, terminal equipment is not a direct connection gateway, but into a " Customer-side "centralized gateway communicates with the enterprise's Access gateway.

2, the ability of API Gateway

API GW itself

• NIO Access, asynchronous connection
• Flow control and shielding
• Secret key exchange
• Client authentication and message encryption and decryption
• Business Routing Framework
• Message conversion
• HTTP Dns/direct IP

API GW Client Sdk/library

• Basic communication
• Secret key exchange and cache
• Identity authentication and message encryption and decryption

Supporting online self-service platform

• Code generation
• Document Generation
• Sandbox commissioning

3. Best practices

Backend API granularity: can and atomic business ability to find the best mapping, must avoid "universal interface" appearance.

The implementation of the business routing and the API with the message conversion support the non-stop release, the information needed to store the business route in the message header, to avoid the analysis of the newspaper style.

After the API GW comes online, the big question is how the backend services can be self-publishing to the outside, while the Gateway service cannot be restarted to ensure continuous business. In this process, if it involves the conversion of the message format, the API Gateway implementation of the technical requirements are relatively high. If you let the gateway complete the message conversion,

• In the first scenario, the gateway needs to know the specific format of the message (that is, the metadata of the message, or the class definition), which is supported by the hot update.
• The second scenario, the client needs additional metadata in the message, the gateway through the runtime loading metadata to parse the message in the conversion of the message, this scheme performance will not be very good.
• The third scheme is to generate the message conversion code and load according to the meta-data when the first message is converted, which requires high technology implementation and is not low in support of the peripheral platform of the gateway.

Client secret Key Management

Many people will be the security problem with a simple encryption algorithm to solve, this is a serious misunderstanding, many times there is a key to the system management of the short board.

For example, the encryption algorithm is like the home of the safe, and the key is the key to the safe, and the lack of secret key management of the security scheme, like the key in the Living room table on your own. Moreover, the security solution Riga decryption is only part of it.

4, a good API gateway

In the design of API gateways, it is not enough to have an "access-oriented" runtime framework like Zuul, because a complete, "Access-oriented" API GW needs to include the following features:

Run-time oriented

• Authenticating the client
• Secret key negotiation of communication session, encryption and decryption of message
• Daily flow control and emergency shielding
• Scene clipping of internal response messages
• An integrated framework that supports pre-positive back model
• Conversion of message Formats
• Support for business routing
• Client-first timeout mechanism
• Generation and application of global serial number
• Client-side support for HTTP Dns/direct IP

For the development period

• Self-service sandbox test environment
• Client-friendly Sdk/library and examples
• Ability to generate client business code framework directly from back-end code
• Perfect message description capability (meta data), support configuration-based message clipping

For operation and maintenance

• Support for independent deployments and rapid horizontal scaling for the access side
• Self-service API provisioning for business scenarios or partners
• External interface performance and on-line environment fault location self-service platform

Ii. Other viewpoints 1, API Gateway is responsible for service request routing, combination and protocol conversion.

All requests to the client go through the API Gateway first, and then it routes the request to the appropriate microservices. API network management often processes 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.

For example, consider a scenario where product details are considered. 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.

2. Advantages and disadvantages of API

The biggest advantage of using an API gateway 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 type of client. This reduces the number of interactions between the client and the application and simplifies the client code.
API Gateways also have some shortcomings, which adds a high-availability component that we must develop, deploy, and maintain. To expose the endpoints of each microservices, the developer must update the API gateway. It is important that the API Gateway update process be as simple as possible. Otherwise, in order to update the gateway, developers will have to wait in line. However, despite these shortcomings, it is reasonable to use an API gateway for most real-world applications.

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 agents such as JMS or AMQP, while others do not have 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 the application service is dynamically allocated. Also, a set of instances of a single service will 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.

5, the problem record

When implementing an API gateway, there is another problem that needs to be addressed, which is the problem of partial failure. This problem occurs in all distributed systems, whenever a service invokes another service that responds slowly or is not available. API gateways can never be blocked by waiting 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, for example, 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, because product prices do not change frequently, the API gateway can return cached price data if the price service is unavailable. The data can be cached by the API gateway itself, or it can be stored in an external cache like Redis or memcached. By returning default data or caching data, the API gateway ensures that a system failure does not affect the user's experience.

6. API Directory Management

When you need to edit the definition of an API, if the API has been published, changes to the definition will not affect the line, and the definition will need to be published again to synchronize the modified definition to the online environment.
When you want to delete an API, if the API has already been published, it is not allowed to delete the API definition directly, you need to go offline and then delete the API.
Provides functionality for replication definitions. You can overwrite the current definition from the definition on the test environment/online environment copy line, and then click Edit again to modify it.

The industry ramble about API Gateway