Web应用与RESTful服务复用类：多独立REST服务部署方案咨询

Hey there! Let's break down the best approaches for your scenario—running multiple RESTful services on different ports while reusing your existing repository, service, and core resources. We'll cover both single-project and multi-project options, plus concrete implementation steps.

First: Core Recommendation for Your Case #

Since your primary goal is to reuse existing resources (services, repositories) without duplication, a single-project setup is the most efficient choice initially. It keeps your codebase unified, avoids redundant maintenance, and simplifies dependency management. A multi-project setup makes sense only if your services are destined to become fully independent (with separate dependencies, deployment pipelines, etc.) down the line.

Option 1: Single-Project Implementation (Recommended) #

We'll use Spring Boot's @Profile feature and configurable ports to launch multiple isolated service instances from the same codebase, each loading only its specific controllers while sharing the core service/repo layers.

Step 1: Isolate Service-Specific Controllers with Profiles #

Tag each service's controller(s) with a unique profile to ensure they only load when their corresponding service is active:

// User Service Controller
@RestController
@Profile("user-service")
@RequestMapping("/api/users")
public class UserController {
    @Autowired
    private UserService userService;

    // Your REST endpoints here
}

// Order Service Controller
@RestController
@Profile("order-service")
@RequestMapping("/api/orders")
public class OrderController {
    @Autowired
    private OrderService orderService;

    // Your REST endpoints here
}

Step 2: Ensure Shared Resources Are Always Loaded #

Create a shared configuration class to guarantee your repository and service layers are scanned regardless of the active profile:

@Configuration
@ComponentScan(basePackages = {"project.repository", "project.service"})
public class SharedCoreConfig {
    // No extra code needed—this ensures your core resources are loaded
}

Step 3: Launch Services (Two Ways) #

Method A: Use a Single Main Application with Command-Line Params

Keep your existing MainApplication and launch instances with different ports and profiles:

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

Then run these commands in separate terminals:

# Start User Service on port 8080
java -jar your-app.jar --server.port=8080 --spring.profiles.active=user-service

# Start Order Service on port 8081
java -jar your-app.jar --server.port=8081 --spring.profiles.active=order-service

Method B: Create Separate Application Entry Points

For easier IDE testing, create dedicated main classes for each service (each sets its default port and profile):

// User Service Entry Point
@SpringBootApplication
@Import(SharedCoreConfig.class)
@Profile("user-service")
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(UserServiceApplication.class);
        app.setDefaultProperties(Map.of("server.port", "8080"));
        app.run(args);
    }
}

// Order Service Entry Point
@SpringBootApplication
@Import(SharedCoreConfig.class)
@Profile("order-service")
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(OrderServiceApplication.class);
        app.setDefaultProperties(Map.of("server.port", "8081"));
        app.run(args);
    }
}

Now you can run each entry point directly in your IDE to launch the corresponding service.

Option 2: Multi-Project Implementation (For Future Independence) #

If you anticipate your services will grow into fully independent components (with separate dependencies, deployment schedules, etc.), split your codebase into a multi-module Maven project:

Project Structure #

your-root-project/
├── pom.xml (Parent POM: manages shared dependency versions)
├── shared-core/
│   ├── pom.xml (Depends on parent; contains project.repository and project.service)
│   └── src/main/java/
├── user-service-web/
│   ├── pom.xml (Depends on shared-core; contains UserController and UserServiceApplication)
│   └── src/main/java/
└── order-service-web/
    ├── pom.xml (Depends on shared-core; contains OrderController and OrderServiceApplication)

Key Benefits #

• Each service can be independently built, packaged, and deployed
• You can add service-specific dependencies without affecting others
• Clear separation of concerns for long-term scalability

Drawbacks #

• Higher maintenance overhead (managing multiple modules, syncing dependency updates)
• More complex setup compared to the single-project approach

Final Verdict #

Start with the single-project setup—it aligns perfectly with your current goal of reusing resources and keeps things simple. If your services later need to diverge significantly, you can refactor to the multi-project structure without losing core functionality.

内容的提问来源于stack exchange，提问作者Florent06