Introduction to Microservices Architecture

In this article, we will explore microservices architecture through the lens of Java backend technology, with a particular focus on service discovery and registration - a critical component of any microservices ecosystem. We'll progress from basic concepts to advanced implementations, providing valuable insights for both beginners and experienced professionals.

Monolithic vs. Microservices Architecture

Monolithic Architecture

Let's first examine traditional monolithic architecture. In this approach, an application is typically packaged as a single archive file (such as a WAR) that contains all aplication functions and logic. This structure is referred to as a monolithic application because all functional modules are bundled together for easy deployment and management.

Microservices Architecture

The core principle of microservices is to decompose a traditional monolithic application into multiple independent services based on business requirements, achieving complete decoupling. Each microservice focuses on a specific function or business logic, following the "one service, one responsibility" principle, similar to processes in an operating system. This design allows each service to be deployed independently and can even have its own database, improving system flexibility and maintainability.

Advantages

1. Small and Cohesive Services: Microservices break applications into multiple independent services, each focused on specific functionality, making the system more flexible and maintainable.
2. Simplified Development: Different teams can develop and deploy their respective services in parallel, increasing development efficiency and release frequency.
3. Scalability on Demand: The loose coupling of microservices allows independent scaling and deployment of services based on business needs, optimizing performance based on traffic changes.
4. Frontend-Backend Separation: As Java developers, we can focus on backend interface security and performance without concerning ourselves with frontend user experience.
5. Fault Tolerance: Failure of one service doesn't affect the entire system's availability, improving reliability.

Disadvantages

1. Increased Operational Complexity: Managing multiple services increases operational complexity beyond managing a single WAR file, involving more complex technology stacks like Kubernetes, Docker, and Jenkins.
2. Communication Overhead: Inter-service communication requires network communication, potentially causing delays and performance issues.
3. Data Consistency Challenges: In distributed systems, maintaining data consistency and handling distributed transactions becomes more difficult.
4. Performance Monitoring and Issue Localization: More monitoring tools and strategies are needed to track performance across services, making problem troubleshooting more complex.

Use Cases

Microservices aren't suitable for all projects. They excel in specific scenarios such as:

1. Large, complex projects: By breaking the system into smaller services, each service's complexity is reduced, allowing teams to focus on their functional modules.
2. Rapid iteration projects: Different teams can independently develop and deploy their services, achieving higher iteration frequency and faster market response.
3. High-concurrency projects: Microservices provide flexible scaling capabilities where individual services can be expanded based on demand.

Service Registration Centers

As discussed, the core of microservices architecture lies in separating modules for better flexibility and maintainability. However, this modular design introduces network communication overhead, making it essential to understand how microservices interact with each other.

Communication Methods

Let's consider a critical question: In microservices architecture, how do we effectively maintain complex calling relationships to ensure smooth communication between services?

Hardcoded Calls

The simplest approach is to hardcode IP addresses or domain names in our code for direct calls. For example:

// Service calls via RestTemplate with hardcoded URLs
String url = "http://localhost:8020/order/findOrderByUserId/" + userId;
User result = restTemplate.getForObject(url, User.class);

// Similar HTTP tool calls
String url = "http://localhost:8020/order/findOrderByUserId/" + userId;
OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder()
    .url(url)
    .build();
try (Response response = client.newCall(request).execute()) {
    String jsonResponse = response.body().string();
    // Process jsonResponse
}

While hardcoding IP addresses or domains seems simple, it's not a practical solution. Just as we use domain names instead of IP addresses to visit websites, microservices should have unique service names. This is where service discovery and registration centers come into play - acting as the "DNS" for microservices, storing service names and their network locations.

Service Name-Based Calls

With service discovery, calls become more intuitive:

// Call using microservice name
String url = "http://mall-order/order/findOrderByUserId/" + userId;
List<Order> orderList = restTemplate.getForObject(url, List.class);

Design Principles

A registration center's primary functon is to maintain information about various microservices, such as their IP addresses. Since the registration center is itself a service, it's a critical component in microservices architecture. Each microservice must be properly configured before registering and discovering other services.

Health monitoring plays a crucial role in ensuring clients are aware of server status, especially when servers fail. In microservices architectures, modules typically have multiple instances with the same functionality to distribute request load, but their availability may vary.

Load balancing is another important consideration. Each service node only registers its IP address with the registration center; the center itself doesn't decide which IP to call. This responsibility lies with the client implementation.

Practical Implementation

Let's now explore a practical implementation using Spring Cloud Alibaba with Nacos as our service discovery and registration center.

Preparation

• JDK: Essential development environment
• Maven: For dependency management
• Nacos Server: To be set up locally

Nacos Setup

You can quickly set up a Nacos instance using Docker or locally. For local setup, download from the official GitHub repository and run:

startup.cmd -m standalone

Access the Nacos console at http://127.0.0.1:8848/nacos/index.html

Spring Boot Application Setup

Let's create two services: a user module and an order module, along with a common module for shared functionality.

Dependencies

Both services need the following dependencies:

<dependencies>
    <dependency>
        <groupId>com.example.ecommerce</groupId>
        <artifactId>ecommerce-common</artifactId>
        <version>0.0.1-SNAPSHOT</version>
        <scope>compile</scope>
    </dependency>

    <!-- Nacos service registration and discovery -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

Configuration

Each service needs a configuration file specifying its service name and Nacos registration center address:

server:
  port: 8040

spring:
  application:
    name: mall-user  # Microservice name
  
  # Configure Nacos registration center address
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        namespace: 9f545878-ca6b-478d-8a5a-5321d58b3ca3

Namespaces allow resource isolation between different environments. If not specified, resources are deployed in the public namespace.

Example Code

First, configure a RestTemplate with load balancing:

@Bean
@LoadBalanced  # mall-order => ip:port
public RestTemplate restTemplate() {
    return new RestTemplate();
}

Then implement the service call logic:

@RequestMapping("/findOrderByUserId/{userId}")
public Response findOrderByUserId(@PathVariable("userId") Integer userId) {
    log.info("Finding orders for userId: " + userId);
    # Ribbon implementation with RestTemplate requiring @LoadBalanced
    # mall-order ip:port
    String url = "http://mall-order/order/findOrderByUserId/" + userId;
    Response result = restTemplate.getForObject(url, Response.class);
    return result;
}

Using OpenFeign

For cleaner service calls, we can use OpenFeign, a declarative HTTP client. First, add the dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

Enable Feign clients in the main application class:

@SpringBootApplication
@EnableFeignClients
public class UserFeignDemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserFeignDemoApplication.class, args);
    }
}

Define a service interface:

@FeignClient(value = "mall-order", path = "/order")
public interface OrderFeignService {
    @RequestMapping("/findOrderByUserId/{userId}")
    Response findOrderByUserId(@PathVariable("userId") Integer userId);
}

Then use the Feign client in your controller:

@Autowired
OrderFeignService orderFeignService;

@RequestMapping("/findOrderByUserId/{userId}")
public Response findOrderByUserId(@PathVariable("userId") Integer userId) {
    # Feign call
    Response result = orderFeignService.findOrderByUserId(userId);
    return result;
}

Advanced Concepts

gRPC in Nacos

Since Nacos 2.1, gRPC has been recommended over HTTP for communication. gRPC is an RPC framework that uses HTTP/2 as the transport protocol and Protocol Buffers as the message format, offering efficient data serialization and deserialization.

Key advantages of gRPC include:

• Performance optimization through HTTP/2 multiplexing
• Binary payload for compact data transmission
• Stream control and bidirectional streaming
• Reduced GC pressure through persistent connections

Service Registration

When a service starts, it registers with Nacos. The key code involves:

@Override
public void register(Registration registration) {
    NamingService namingService = namingService();
    String serviceId = registration.getServiceId();
    String group = nacosDiscoveryProperties.getGroup();
    
    Instance instance = getNacosInstanceFromRegistration(registration);
    
    try {
        namingService.registerInstance(serviceId, group, instance);
        log.info("Nacos registry, {} {} {}:{} register finished", group, serviceId,
                instance.getIp(), instance.getPort());
    } catch (NacosException e) {
        # Error handling
    }
}

Heartbeat Monitoring

Nacos 2.1 introduced a more efficient heartbeat mechanism. The client runs a scheduled task to send heartbeats:

public void run() {
    while (true) {
        try {
            if (isShutdown()) {
                break;
            }
            
            ReconnectContext reconnectContext = reconnectionSignal.poll(keepAliveTime, TimeUnit.MILLISECONDS);
            
            if (reconnectContext == null) {
                # Check alive time
                if (System.currentTimeMillis() - lastActiveTimeStamp >= keepAliveTime) {
                    boolean isHealthy = healthCheck();
                    if (!isHealthy) {
                        # Handle unhealthy service
                    }
                }
            }
        } catch (Exception e) {
            # Error handling
        }
    }
}

The server also runs a scheduled task to check client status:

public void start() {
    initConnectionEjector();
    
    # Start unhealthy connection expulsion task
    RpcScheduledExecutor.COMMON_SERVER_EXECUTOR.scheduleWithFixedDelay(() -> {
        runtimeConnectionEjector.doEject();
        MetricsMonitor.getLongConnectionMonitor().set(connections.size());
    }, 1000L, 3000L, TimeUnit.MILLISECONDS);
}

Load Balancing

When multiple instances of a service exist, load balancing determines which instance receives the request. This is handled by Ribbon, not Nacos directly.

Service Discovery

Clients periodically query the registration center for service information:

public void run() {
    if (serviceObj == null) {
        serviceObj = namingClientProxy.queryInstancesOfService(serviceName, groupName, clusters, 0, false);
        serviceInfoHolder.processServiceInfo(serviceObj);
        lastRefTime = serviceObj.getLastRefTime();
        return;
    }
    
    if (serviceObj.getLastRefTime() <= lastRefTime) {
        serviceObj = namingClientProxy.queryInstancesOfService(serviceName, groupName, clusters, 0, false);
        serviceInfoHolder.processServiceInfo(serviceObj);
    }
}

Load Balancing Algorithms

Ribbon provides various load balancing strategies. You can configure them globally or per service:

# Global configuration
@Bean
public IRule ribbonRule() {
    return new NacosRule();
}

# Per-service configuration
mall-order:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule

Conclusion

Through this exploration of microservices architecture, we've gained a comprehensive understanding of service discovery and registration mechanisms. From the limitations of monolithic architecture to the flexibility of microservices, we've witnessed the evolution of system architecture. Service discovery and registration, as the foundation of microservices communication, play an indispensable role in ensuring system scalability and reliability.

The implementation of Nacos demonstrates how registration centers can effectively manage service instances, providing high availability and stability through mechanisms like heartbeat monitoring and load balancing. These implementations not only enhance system scalability and fault tolerance but also provide a solid foundation for the rapid development of microservices.