Architectural Evolution and Microservices

Modern software engineering has transitioned from monolithic architectures, where all components share a single database and deployment unit, to distributed systems. While Service-Oriented Architecture (SOA) abstracted common functionalities into services, Microservices architecture refines this by breaking down applications into smaller, independent processes. This granular approach supports diverse client platforms but increases operational complexity.

Nacos Overview

Nacos serves as a dynamic service discovery and configuration management platform. Its core functionalities include:

• Dynamic Service Discovery and Health Checking: Services register via DNS or HTTP APIs. Nacos performs real-time health checks to prevent routing traffic to unhealthy instances.
• Dynamic Configuration Management: Centralized configuration management allows for updates without redeploying applications.
• Dynamic DNS Service: Supports DNS-based service discovery for heterogeneous language environments.
• Service and Metadata Management: Manages service lifecycle, dependencies, traffic routing, and security policies from a microservices platform perspective.

Service Discovery and the CAP Theorem

In a microservices environment, services (consumers) must dynamically locate other services (providers) via a Service Registry. The process involves:

1. Registration: Provider instances start and register their network location (IP:Port) with the registry, forming a service registration table.
2. Synchronization: Consumer instances periodically pull and cache the registration table.
3. Invocation: When calling a service, the consumer uses the cached table to locate an instance, applying a load-balancing algorithm if multiple instances exist.

Distributed registries must adhere to the CAP theorem, which states a system can only simultaneously guarantee two of the following three properties:

• Consistency (C): All nodes see the same data simultaneously.
• Availability (A): Every request receives a response (success or fail) without guaranteed consistency.
• Partition Tolerance (P): The system continues to operate despite network failures.

In practice, service registries must ensure Partition Tolerance (P), forcing a trade-off between Consistency and Availability (AP or CP).

RESTful Service Discovery and Load Balancing

RESTful APIs rely on standard HTTP methods (GET, POST, PUT, DELETE) to manipulate resources. Integration with Spring Cloud Alibaba simplifies service discovery via spring-cloud-starter-alibaba-nacos-discovery.

Load Balancing Strategies

Load balancing distributes traffic across multiple instances to ensure high availability. It is categorized into:

• Server-Side Load Balancing (e.g., Nginx): A central proxy maintains the list of service instances and routes client requests to one.
• Client-Side Load Balancing (e.g., Ribbon/Nacos): The consumer client maintains the instance list and selects a target instance before sending the request.

The following example demonstrates client-side load balancing using DiscoveryClient to select an instance manually:

@RestController
@RequestMapping("/api/v1")
public class OrderController {

    private static final String INVENTORY_SERVICE_ID = "inventory-service";
    private final RestTemplate restTemplate;
    private final DiscoveryClient discoveryClient;

    public OrderController(RestTemplate restTemplate, DiscoveryClient discoveryClient) {
        this.restTemplate = restTemplate;
        this.discoveryClient = discoveryClient;
    }

    @GetMapping("/purchase")
    public String placeOrder() {
        // 1. Fetch available instances from the local cache (synced with Nacos)
        List<ServiceInstance> instances = discoveryClient.getInstances(INVENTORY_SERVICE_ID);

        if (instances == null || instances.isEmpty()) {
            return "Error: Inventory service unavailable";
        }

        // 2. Implement a simple load balancing strategy (e.g., Random)
        ServiceInstance targetInstance = instances.get(ThreadLocalRandom.current().nextInt(instances.size()));
        String baseUrl = targetInstance.getUri().toString();

        // 3. Make the remote call
        String response = restTemplate.getForObject(baseUrl + "/stock/deduct", String.class);
        return "Order processed | " + response;
    }
}

Load Balancing Rules

Client-side balancers like Ribbon support various algorithms:

RPC and Dubbo Service Discovery

Remote Procedure Call (RPC) is a technique where a computer program causes a subroutine to execute in another address space (commonly on another computer) without the programmer explicitly coding the details for this remote interaction.

REST vs. RPC

In a typical enterprise architecture (e.g., Payment Systems), RPC is used for internal high-frequency communication (e.g., Application Layer calling Microservice Layer), while RESTful APIs are exposed externally (e.g., Gateway to Client) for compatibility.

Nacos Data Model and Management

Nacos organizes data using a hierarchical model to ensure isolation and manageability.

Namespace Isolation

Namespaces provide tenant-level isolation. They are commonly used to separate environments such as development, testing, and production. Configurations and services in different namespaces are logically isolated and do not interfere with each other.

Service-Cluster-Instance Hierarchy

The management model follows a three-layer structure:

1. Service: A logical collection of capabilities providing a specific function.
2. Cluster: A subset of service instances, often grouped by physical deployment regions or availability zones. Instances within the same cluster can communicate more efficiently.
3. Instance: A specific process with a network address (IP:Port) providing the service.

This hierarchy allows for granular control over traffic routing and metadata management.