在开发一个电商后台系统时，团队最初把所有功能塞进一个应用里，用户管理、订单处理、商品展示全混在一起。随着功能变多，改一处代码就得重新部署整个系统，测试也得从头跑一遍，效率低得像老式拨号上网。后来我们决定拆成多个小服务，用户归用户，订单管订单，各自独立更新，互不干扰。
为什么选Dubbo
Dubbo是阿里巴巴开源的服务框架，擅长处理服务之间的调用和治理。它不像Spring Cloud那样依赖HTTP，而是用更高效的RPC通信，默认使用Netty做网络层，响应更快。我们在服务数量达到二十多个后，明显感觉到注册、发现、负载均衡这些事不能再靠人工维护了，必须有个“管家”，Dubbo就扮演了这个角色。
基础配置实战
先引入Maven依赖：
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>3.2.0</version>
</dependency>接着在配置文件中指定注册中心，我们用的是ZooKeeper：
dubbo:
application:
name: order-service
registry:
address: zookeeper://127.0.0.1:2181
protocol:
name: dubbo
port: 20880服务暴露与引用
比如订单服务要提供接口给前端调用，只需加个@DubboService注解：
@DubboService
public class OrderServiceImpl implements OrderService {
public String createOrder(String userId, String itemId) {
// 具体逻辑
return "ORDER-" + System.currentTimeMillis();
}
}用户服务如果需要调用订单服务，用@DubboReference注入即可：
@RestController
public class UserController {
@DubboReference
private OrderService orderService;
@GetMapping("/buy")
public String buy() {
return orderService.createOrder("U001", "I002");
}
}流量控制与降级
有一次促销活动，订单服务突然被大量请求冲垮，连带用户服务也卡住。我们加上了限流和降级策略，在dubbo配置中启用熔断：
dubbo:
provider:
loadbalance: leastactive
actives: 10
executes: 20
cluster: failfast同时通过Sentinel对接，设置每秒最多处理100个调用，超出就快速失败，避免雪崩。
灰度发布尝试
新版本订单服务上线前，我们不想影响全部用户。Dubbo支持基于标签的路由规则，给部分机器打上“beta”标签，再通过条件路由让特定请求走新版本。这样运维可以在后台动态切流，验证稳定后再全量发布。
实际运行中，Dubbo的治理能力让我们少了很多半夜救火的场景。服务自动上下线、调用链追踪、超时重试都有默认保障。虽然学习曲线比直接写单体程序陡一点，但长远看，系统的可维护性提升了不少。