In the previous article , I have shared some basic information that I learned about Microservice model.
Unlike a monolithic architecture with only one input and one output, the Microservices model is a collection of many small blocks with separate functions with separate input and output. And in order to work, the blocks must be closely linked to create a unity, which directly affects the customer application communication and the application.
And one of the methods proposed here would be to use API Gateway.
So how was it created, how it works and its advantages and disadvantages, we will analyze more closely
1. Introduction
Imagine you’re developing a mobile shopping app product now. In it you will need an interface screen that displays details of any product.
For example: Here are the familiar interfaces of Shopee:
Although this is a smartphone application, the product details page displays a lot of information, for example: not only basic product information (such as name, description, price) but this page also show both:
- Number of products in the cart
- Order history
- Customer Feedback
- Warning low stock existence
- Shipping options
- Other promotions
- Alternative option
Using the monolithic architecture, the client side retrieves this data by making a REST () request for the application. A routing load balancer requires up to one of N identical application cases. The application will then query different database tables and return them to the client.
In contrast, when using the Microservices model, data is displayed on the product details screen owned by many microservices.
Some potential services that own the data are displayed on the screen in detail, such as:
- Shopping cart service – Number of items in the cart
- Order service – Purchase history
- Catalog services – Basic product information such as name, price, photos
- Service rating – Customer reviews
- Inventory service – low inventory alert
- Shipping service – Shipping options, term, shipping cost
- Proposed service – Recommended items
2. Direct Client ‑ to ‑ Microservice Communication
The above term can be understood that users in the model can directly interact with each small internal service. Imagine each microservice will have a public endpoint called api url (https: // serviceName. Api. Company. Name). This URL will affect the load balancer of the microservices, distributing requests across the available versions. To get product details, the client requests each of the services listed above.
But that is only a theory, unfortunately it will have problems arising with this option. First, it will not fit between customer needs and the detailed APIs represented by each of these small service blocks. The customers in this example require separate, while applications are more complex, so it has to create more.
Another problem with customers calling directly to microservice is that some may use non-web-friendly protocols. One service can use the RPC binary Thrift while the other can use the AMQP messaging protocol. No protocol in particular is browser or firewall, friendly and best used internally. An application should use protocols such as HTTP and WebSocket outside the firewall.
Another downside to this approach is that it makes it difficult to restructure micro services. Over time, we may want to change the way the system is partitioned into services. For example, we may merge two services or split a service into two or more services. However, if the customer communicates directly with the services, then implementing this type of restructuring can be extremely difficult.
Due to these types of issues, it is rarely meaningful for clients to talk directly to the microservice.
3. API Gateway
From the disadvantages of the above approaches, we have a new approach using API Gateway. In essence, it is still the communication between client and microservice, but we will not communicate directly but through a guy called Gateway, it’s like a butler. From authentication, monitoring, storage, load balancing or response processing, …. all done.
API Gateway is responsible for routing requests, components, and protocol translation. All requests from the client must first pass through the API Gateway. Then it routes the request to the appropriate microservice. The API Gateway will typically process a request by invoking many microservices and aggregating the results. It can translate between web protocols like HTTP and WebSocket and non-web-friendly protocols used internally.
API Gateway can also provide each customer a custom API. It usually displays raw granular APIs for mobile clients. Consider, for example, detailed product scenarios. The API gateway can provide an endpoint (/ productdetails? Productid = xxx) that allows the client to retrieve all product details with just one request. API Gateway processes requests by invoking various services – product information, suggestions, reviews, etc. – and combining the results.
It seems that the real way has solved the disadvantages of the direct link method, but it will still have some disadvantages.
3. Cons
- It is another very readily available component that must be developed, implemented and managed.
- There is also the risk that API Gateway becomes a development bottleneck. Developers must update the API Gateway to display each microservice endpoint.
- It is important that the API Gateway update process be as light as possible. If not, developers will be forced to wait in line to update the port
Although there are still disadvantages, it also has some advantages that people still use it.
5. Advantages
- A major benefit of using API Gateway is that it encapsulates the internal structure of the application. Instead of having to call specific services, the client just needs to talk to the port.
- API Gateway provides each customer type with a specific API. This reduces the number of round trips between the client and the server. It also simplifies client code
6. Implementation
When implementing a microservice implementation using the API Gateway, we will have to pay attention to the following:
Performance and scalability
Build API Gateway on asynchronous, non-blocking I / O support platform.
Use reactive programming model
Write API Gateway code in the style of the declaration using the response method.
Service request
Use message-based, asynchronous, or synchronous mechanisms like HTTP or Thrift.
Discover the service
The API Gateway needs to know the location (IP address and port) of each microservice it communicates with.
Handling partial errors
The API Gateway can return cached data if it is available, helping to prevent partial error.
7. Summary
For most microservice-based applications, the implementation of the API Gateway acts as a single entry point into the system. API Gateway is responsible for routing requests, components, and protocol translators. It provides each client of the application with a custom API. API Gateway can also hide errors in backend service by returning cached or default data.
Some of them shared their hope to be able to answer some of your questions about Microservice model.
Thank you for reading this article 