Microservice Theory and Practice (5)-Interaction between Microservices
Posted Jun 15, 2020 • 3 min read
The "open" in the Microservice architecture model is the internal implementation of each service, and the "closed" is the way for each service to communicate with each other
Microservices must use interprocess communication mechanisms to interact. There are two types of IPC mechanisms for microservice architecture, asynchronous message mechanism and synchronous request/response mechanism. When designing the communication mode of a service, several issues need to be considered:how the service interacts, how each service identifies the API, how to upgrade the API, and how to handle partial failures.
- API GateWay mode
When deciding to treat an application as a set of microservices, you need to decide how the application client interacts with the server. There are two ways:
(1) Direct communication between client and server
(2) Using API Gateway, the client interacts with the API Gateway. The API Gateway encapsulates specific service details and provides the API to each client.
1.2 Direct communication between client and server
A client can directly initiate a request to any one of multiple microservices. Every microservice will have an external server. This URL may be mapped to the load balancing of the microservices, which forwards the request to specific nodes.
l The demand of the client does not match the number of fine-grained APIs exposed by the microservices. The client needs to initiate multiple requests to obtain the complete data to be accessed.
l The protocol of the microservice requested by the client may not be web-friendly. For example, the microservice is RPC or AMQP, and neither of them is web-friendly.
l It is difficult to refactor microservices
1.3 API Gateway
APIGateway is a server and the only node to enter the system. API Gateway encapsulates the internal architecture of the system and provides APIs for each client.
1.3.1 The goal of API Gateway
Supports dynamic release and operation of API interfaces, including but not limited to:
(1) Safety certification
a. The public key is generated after the application application is approved, and the open platform needs to provide key management to support the distributed system
The service can be set to two levels of security:authorized access and no authorized access(the latter means that any client can initiate calls), and by default all APIs require authorized access.
b. Applications in abnormal state(disabled, deactivated, blacklisted, etc.) directly throw exceptions and do not allow access-fuse mechanism
c. The number of calls, the frequency of calls, and the number of concurrency can be controlled at runtime to avoid that a certain request volume is too large to affect the calls of other applications.
d. An API can be set to be forced to be blown for an application, and all requests directly throw an exception regardless of the threshold.
(2) API management
All APIs can be managed in the background, including dynamic publishing, parameter mapping configuration, back-end service interface configuration, API disabling, enabling, multi-version, grouping, and classification.
(3) Application management
Manage the applications(third-party applications) accessed by the open platform in the background, including querying, disabling, enabling, and auditing.
(4) Billing charges
a. API call statistics, each request time, response time, response status.
b. API billing calculation, according to the request volume and request resource billing, to achieve a variety of billing models.(Pre-payment, post-payment. According to the amount, according to the time period.)
(6) Traffic statistics and current limit
l Support the dynamic release and operation of the API of the existing subsystem RPC protocol, transparent transmission of external requests.
l Support json, xml response message, you can choose the required message format when you request.
l Support dynamic and direct exposure of back-end SOA services as APIs.
l Support dynamic exposure of common web interface as API.
l Support dynamic exposure of MQ services as APIs.
l Support multiple services to compose and expose as API.
l Request forwarding, synthesis and protocol conversion
l Provide a customized API to the client
1.3.2 Advantages and disadvantages of API Gateway mode
l Specific API. The client only needs to deal with the Gateway, reducing the number of communication between the client and the server, and simplifying the client code.
l The reporting client does not need to be affected by the location of the server instance
l Provide optimal API for each client
l Reduce the number of requests/round trips
l API Gateway is a highly available component that must be developed, deployed, and managed. Developers must update API Gateway to provide new service delivery points to support newly exposed microservices.
l API Gateway will cause redundant network jumps
2.3 API version management