At server level, since our architecture is
Service Oriented Architecture, how API gateway talks to other microservices?
At server level, since our architecture is
An API gateway is a service which is the entry point into the application from the outside world. It’s responsible for request routing, API composition, and other functions, such as authentication.
An API gateway has a layered, modular architecture. Its architecture, which consists of two layers, the API layer and a common layer. The API layer consists of one or more independent API modules. Each API module implements an API for a particular client. The common layer implements shared functionality including edge functions such as authentication.
In this example, the API gateway has three API modules:
- Mobile API, which implements the API for the FTGO mobile client
- Public API, which implements the API for third-party developers.
An API module implements each API operation in one of two ways. Some API operations map directly to single service API operation. An API module implements these operation by routing requests to the corresponding service API operation. It might implement these API operations using a generic routing module that reads a configuration file describing the routing rules.
An API module implements other, more complex API operations using API composition. The implementation of this API operation consist of custom code. Each API operation implementation handles requests by invoking multiple services and combining the results.
Benefits of API-Gateway
- It encapsulates the internal architecture of the application and expose only one entry point to every kind of client.
- Reduces the number of requests/roundtrips. For example, the API gateway enables clients to retrieve data from multiple services with a single round-trip. Fewer requests also means less overhead and improves the user experience. An API gateway is essential for mobile applications.
- Translates from a “standard” public web-friendly API protocol to whatever protocols are used internally
Thanks for the answer but the question is how our own custom api gateway Talk to other microservices of VRT internally.
API Gateway communicates with other microservices using a service discovery mechanism, often referred to as a Service Registry or Service Discovery Server. This server helps the API Gateway locate and communicate with the various microservices in a dynamic and scalable manner. Here’s an overview of how API Gateway typically communicates with other microservices using a service discovery server:
- Registration: When microservices start up, they register themselves with the Service Discovery Server. This registration typically includes information such as the microservice’s hostname, port, and any metadata that may be needed to identify the service or determine its health.
- Heartbeating: Microservices regularly send heartbeats or health checks to the Service Discovery Server. This ensures that the server can keep track of which services are currently running and healthy.
- Service Lookup: When the API Gateway needs to communicate with a particular microservice, it queries the Service Discovery Server for the service’s location. It does this by providing a service name or a unique identifier associated with the target microservice.
- Load Balancing: The Service Discovery Server often provides load balancing capabilities. It can return multiple instances of the target microservice if there are multiple instances registered. The API Gateway can then distribute traffic among these instances to ensure high availability and scalability.
- Dynamic Updates: If a microservice becomes unhealthy or is taken offline for maintenance, the Service Discovery Server can detect this through failed heartbeats or health checks and remove the unhealthy instance from the list of available services. Likewise, when a new microservice instance comes online, it can register itself with the Service Discovery Server, making it available for use.
- Caching: API Gateway may cache the service location information received from the Service Discovery Server to reduce the load on the server and improve performance. However, this cache typically has a TTL (time-to-live) to ensure that it doesn’t become outdated.
- Retry and Circuit Breaking: API Gateway can implement retry mechanisms and circuit breaking strategies when communicating with microservices. If a service is temporarily unavailable, the API Gateway can retry the request or, after a certain number of failures, open a circuit to avoid overloading the service.
- Security: Access control and security considerations are crucial when communicating with microservices. API Gateway can handle authentication, authorization, and encryption of communication between itself and the microservices.