Spring Cloud

Spring Cloud Common Components

• Eureka is a service registration component that synchronizes data between multiple Eureka Servers, ensuring consistent status.
• Ribbon can convert REST template (RestTemplate) requests for service-oriented REST to client load balancing service invocations.
• Feign is a declarative REST client in Spring Cloud that simplifies the interaction with HTTP services. By using annotations, we can declare request parameters, methods, and headers, making the use of clients more convenient and concise.
• Hystrix is a framework provided by Spring Cloud with a fault-tolerant mechanism. Since in microservice systems, multiple microservices collaborate to complete the same operation, there will be many mutual calls between microservices. Due to the frequent occurrence of node failures in distributed environments, call failures may occur. The fuse module provides a mechanism to ensure normal program operation without getting stuck during a call, similar to the try-catch structure in Java programs.
• Zuul/Gateway acts as an API gateway for microservice architecture, supporting dynamic routing and filtering capabilities. The API gateway provides a unified entry point for services in a microservice architecture, enabling clients to access related services through the API gateway. Gateway is a high-performance API gateway component that provides a simple and effective way to route API services and provides various enhancements such as security, monitoring, and scalability.

What are Service Registration and Discovery? How does Spring Cloud implement it?

Service registration and discovery is a service governance mechanism in distributed systems that allows multiple service instances to register themselves automatically with a service registry during runtime and automatically retrieve information about other service instances from the service registry, thereby achieving dynamic discovery and load balancing of services.

Spring Cloud provides various ways to implement service registration and discovery. The most commonly used one is Eureka. Eureka is an open-source service registration and discovery component that provides a REST API for managing service instances. In Spring Cloud, we can use the @EnableEurekaServer annotation to start an Eureka Server and specify its address in the application configuration file. When a service provider starts, it registers its information with the Eureka Server; when a service consumer starts, it retrieves all available service instance information from the Eureka Server and selects an appropriate instance for invocation based on load balancing policies. Service providers send heartbeats to eureka every 30 seconds to report health status, and if eureka fails to receive a heartbeat for 90 seconds, it removes it from the list.

Similar functionality can also be achieved using Alibaba's Nacos. However, Nacos only provides a registration center; Eureka has only a registry. This was one of the reasons why our previous company chose to use Nacos.

How is Load Balancing implemented?

Load balancing in microservices mainly uses a component called Ribbon. For example, when using feign for remote calls, the underlying load balancing uses Ribbon.

Ribbon offers several load balancing strategies:

• RoundRobinRule: Simply round-robins through the list of services to select a server.
• WeightedResponseTimeRule: Selects servers based on response time weighted. The longer the response time, the lower the weight.
• RandomRule: Selects a random available server.
• ZoneAvoidanceRule: Uses zone-sensitive strategies to select servers based on the availability of zones. It considers zones as physical areas like server rooms or racks and performs round-robin selection within each zone.

Custom load balancing strategies can be globally configured by creating a class that implements IRule interface and specifying the load balancing strategy. Locally, you can configure a specific service's load balancing strategy in its client's configuration file.

What is Server Avalanche and how can it be solved?

Server avalanche refers to a scenario where the failure of one service leads to the failure of all services in the entire chain. There are two ways to solve this issue: service degradation and service failure recovery.

• Service degradation is a self-protection mechanism for services or a way to protect downstream services from excessive request surges to ensure that services remain available and do not crash. It is commonly integrated with feign interfaces in actual development and involves writing degradation logic.
• Service failure recovery involves turning on service熔断. By default, it is turned off and needs to be manually enabled. If the rate of failed requests exceeds 50% within 10 seconds, it triggers the mechanism of melting down. Afterward, it tries to make requests to microservices every 5 seconds. If the microservices cannot respond, it continues to fall under the mechanism of melting down. If the microservices are reachable, it turns off the mechanism of melting down and resumes normal request processing.

Business-related

CAP and BASE

The CAP theorem states that in a distributed system, only two out of the three characteristics can be simultaneously satisfied: consistency (Consistency), availability (Availability), and partition tolerance (Partition Tolerance). Consistency refers to having the same data copy at the same time for all nodes; availability means that nodes can respond to requests at any time; partition tolerance means that the system can still operate normally even in a network partition situation. The BASE theory is the result of the trade-off between consistency and availability in CAP. Its core idea is that although strong consistency cannot be achieved, each application can choose an appropriate method according to its own business characteristics to achieve eventual consistency. The BASE consists of three elements: Basically Available (AB), Soft State (SS), and Eventual Consistency (EC).

Basically Available (AB) means that the distributed system allows for some loss of availability when unforeseen faults occur, but it does not lead to system unavailability. For example, in response time, there may be a delay of 12 seconds due to faults. In normal circumstances, an online search engine needs to return query results to users within 0.5 seconds, but due to faults, the response time increases by 12 seconds.

Soft State (SS) refers to the fact that data in the system is not strictly consistent but has some delay or uncertainty. For example, in social networks, users' statuses may be "online," "offline," or "hidden," rather than absolute states like "using WeChat" or "listening to music." In this state, the system can accept some degree of inconsistency and uncertainty.

Eventual Consistency (EC) means that all nodes in the system have the same data copy at the same time. However, in practice, due to network delays, node failures, and other factors, data may exist temporarily inconsistently. In this case, the system needs to ensure eventual consistency through asynchronous replication and other methods.

There are two approaches to solving distributed transactions:

The first approach is eventual consistency thinking, where each branch transaction executes and commits independently. If there is any inconsistency, data recovery (AP) is performed.

The second approach is strong consistency thinking, where each branch transaction does not commit but awaits the result of others. Then, either all commit or rollback together (CP).

Which distributed transaction solution to use?

Distributed transactions need to be controlled whenever multiple service writes occur. This can be achieved using the MQ pattern for distributed transactions. When a service writes data, it needs to send a message to another transaction within the same transaction. This is asynchronous and has the best performance.

How to design idempotent APIs for distributed services?

Idempotence refers to calling a method or interface multiple times without changing the business state, ensuring that repeated calls have the same result as a single call.

For adding new data, a unique index can be used in the database.

For modifying data, a distributed lock can be used, but its performance is lower. For better performance, tokens and Redis can be used. First, generate a unique token and store it in Redis when making the first request. Return the token to the front-end. When making subsequent requests for business processing, carry the previous token to Redis for verification. If it exists, perform the business operation and delete the token. If it does not exist, directly return without processing the business.