Microservice Service Splitting Principles and Remote Call Implementation with Spring Boot

In any distributed architecture, services must be split and refined; the same applies to microservices. This article introduces the basic principles of microservice service splitting and illustrates them with a simple demo consisting of order-service and user-service projects.

Service‑splitting principles :

Different microservices should not contain overlapping business logic to ensure low coupling.

Each microservice should own its own independent database.

Microservices communicate through exposed RESTful interfaces.

The demo structure shows order-service handling order queries and user-service handling user queries. Both services have their own databases (e.g., tables cloud-order and cloud-user ).

Remote call implementation :

To enrich order data with user information, the order service needs to call the user service via HTTP. The required steps are:

Register a RestTemplate bean in the order service’s Spring Boot application class and annotate it with @LoadBalanced for client‑side load balancing.

Inject the RestTemplate into OrderService .

In queryOrderById , after retrieving the order from the database, build the URL http://userservice/user/{userId} and call restTemplate.getForObject(url, User.class) to obtain the user data.

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

@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);
        return order;
    }
}

The article also explains the concepts of service provider (the service offering functionality) and consumer (the service invoking it), noting that roles can switch depending on business scenarios.

Finally, the author encourages readers to explore the demo, join the architecture community, and provides links to additional resources and interview question collections.