Microservice Service Splitting Principles and Remote Call Implementation with Spring Boot

Regardless of the distributed architecture, services must be split and refined; microservices are no exception. This article introduces microservice service‑splitting principles and demonstrates a small demo to illustrate service division and remote invocation.

1 Service Splitting

1.1 Service Splitting Principles

Different microservices should avoid overlapping business logic to ensure low coupling.

Each microservice should have its own independent database.

Microservices interact through exposed business APIs.

1.2 Service Splitting Example

1.2.1 Demo Project Structure

The demo consists of a parent project cloud-demo with two services:

order-service : handles order‑related operations (demo only provides a query function).

user-service : handles user‑related operations (also minimal).

According to the splitting principles, the conclusions are:

Both services must expose RESTful interfaces for other services to call.

One service may call another only via its RESTful API, never directly accessing the other’s database.

Each service must maintain its own database.

1.2.2 Database Table Structure

Example: the cloud_order table contains a cloud_user ID field.

2 Remote Call

2.1 Remote Call Example

The demo requires the order-service to retrieve user information when querying an order. The required interface is a simple order‑query endpoint.

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;

    public Order queryOrderById(Long orderId) {
        // 1. Query order
        Order order = orderMapper.findById(orderId);
        return order;
    }
}

After starting the services, the console shows that the user field is empty, indicating the need for a remote call to the user service.

2.2 Implementation Steps

Register a RestTemplate bean in the order module’s startup class and inject it into the Spring container.

Modify OrderService.queryOrderById to fetch user data via the user service’s REST endpoint.

Use restTemplate.getForObject(url, User.class) to obtain and wrap the user data.

Set the retrieved User object into the Order and return the enriched order.

Step 1: Register RestTemplate

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    /**
     * Create RestTemplate for load balancing and inject into Spring container
     */
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Step 2: Remote Call and Data Wrapping

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1. Query order
        Order order = orderMapper.findById(orderId);
        // 2. Query user via remote call
        String url = "http://userservice/user/" + order.getUserId();
        User user = restTemplate.getForObject(url, User.class);
        // 3. Set user into order
        order.setUser(user);
        // 4. Return enriched order
        return order;
    }
}

The final result displays the order together with its associated user information.

2.3 Service Provider and Consumer

In a service call relationship there are two roles:

Provider (service provider, the "seller").

Consumer (service caller, the "buyer").

In this demo, user-service acts as the provider and order-service as the consumer. Roles can switch depending on business needs.

Source: blog.csdn.net/qq_54217349/article/details/127955490