从天气项目看Spring Cloud微服务治理

从天气项目看Spring Cloud微服务治理

微服务架构的核心不在于技术栈的选择，而在于“如何拆分”。很多开发者在转型微服务时，容易陷入“微服务拆得越细越好”的误区，导致系统架构变成了“分布式单体”，运维成本爆炸而性能却未见提升。实际上，服务边界的划分应当遵循高内聚、低耦合的原则，并严格限定在业务领域的上下文之内。通过构建一个“天气服务”系统，我们可以清晰地演示如何从需求分析到代码落地，进行科学的服务拆分。

在设计初期，我们可能会构思一个单一的“天气应用”。但随着需求演进，我们会发现系统包含了两个截然不同的业务关注点：

气象数据中心：负责从第三方气象局、传感器收集原始数据，进行清洗、存储，并提供精确的经纬度查询。这是一类典型的写多读少或数据密集型场景。用户推送服务：管理用户的城市订阅、推送频率偏好，并根据数据中心的数据触发消息推送。这是一类交互密集型场景，关注用户行为和触达时效性。根据领域驱动设计（DDD）的思想，我们应当将系统拆分为天气数据服务和用户订阅服务。这两个服务拥有各自独立的数据库，通过定义良好的 API 进行交互。而在它们之上，需要一个前端聚合服务或 API Gateway 来组装数据，供移动端调用。这样，即使数据服务的查询压力剧增，也不会影响用户订阅消息的发送；反之亦然。

下面我们将使用 Spring Cloud 技术栈来实现这一设计。假设场景如下：用户查询订阅的城市的天气，这需要用户服务先查用户列表，再调用天气服务获取数据。

首先，定义天气数据服务。它只负责提供天气数据查询能力，不关心谁在调用。

// 天气数据服务 Controller @RestController @RequestMapping("/weather") public class WeatherDataController {

@GetMapping("/city")
public WeatherDTO getWeatherByCity(@RequestParam String city) {
    // 模拟数据库查询或第三方 API 调用
    if ("Beijing".equalsIgnoreCase(city)) {
        return new WeatherDTO(city, "Sunny", 25);
    }
    return new WeatherDTO(city, "Rainy", 18);
}

}

// 数据传输对象 @Data @AllArgsConstructor @NoArgsConstructor class WeatherDTO { private String city; private String condition; private int temperature; } 接下来是用户订阅服务。它拥有用户的订阅关系数据。在 Spring Cloud 中，服务间调用最推荐的方式是使用 OpenFeign，它像调用本地方法一样调用远程服务。

首先，定义 Feign 客户端接口（通常放在一个公共模块中，以便各服务共享）：

// Feign Client 接口，指定要调用的服务名称 @FeignClient(name = "weather-data-service") public interface WeatherDataClient { @GetMapping("/weather/city") WeatherDTO getWeatherByCity(@RequestParam("city") String city); } 然后，在用户订阅服务中实现聚合逻辑：

// 用户订阅服务 Controller @RestController @RequestMapping("/subscription") public class UserSubscriptionController {

@Autowired
private WeatherDataClient weatherDataClient;

// 模拟：查询 ID 为 101 的用户订阅的城市天气
@GetMapping("/user/{userId}/dashboard")
public Map<String, Object> getUserDashboard(@PathVariable Long userId) {
    // 1. 从本地数据库获取用户订阅的城市（模拟）
    String subscribedCity = "Beijing"; 

    // 2. 关键点：通过 Feign 远程调用天气数据服务
    // 代码看起来像是在调用本地方法，屏蔽了 HTTP 请求细节
    WeatherDTO weather = weatherDataClient.getWeatherByCity(subscribedCity);

    // 3. 聚合数据返回
    Map<String, Object> result = new HashMap<>();
    result.put("userId", userId);
    result.put("city", subscribedCity);
    result.put("weatherInfo", weather);
    
    return result;
}

} 在上述代码中，UserSubscriptionController 并没有直接查询天气数据库，而是依赖于 WeatherDataClient。这正是微服务边界设计的精髓所在：服务不应窥探其他服务的内部实现，只能通过明确声明的接口进行协作。

这种拆分带来的好处是显而易见的。如果“天气数据服务”需要更换数据源（比如从爬虫改为对接专业气象接口），只要接口 WeatherDTO 不变，用户服务完全不需要修改代码。此外，我们可以独立地对“天气数据服务”进行扩容（例如增加缓存层），而不会影响“用户订阅服务”的运行。

当然，微服务拆分也引入了新的挑战，例如分布式事务。在这个案例中，如果用户取消订阅了一个城市，我们不需要修改天气服务的数据，因此不涉及跨服务事务。但如果涉及跨服务的数据一致性（如：扣费服务与天气服务），就需要引入 Seata 等分布式事务解决方案。

总结来说，从天气服务的案例中我们看到，微服务的边界不应是按技术层（如 DAO 层、Service 层）切分，而应按业务能力切分。利用 Spring Cloud 的组件（如 Eureka 进行服务发现、Feign 进行声明式调用），我们可以优雅地维护这些边界，构建出既灵活又健壮的分布式系统。

从天气项目看Spring Cloud微服务治理

mWQDtL9yS0

评论(0)