二、微服务核心原则：单一职责、自治性、去中心化、弹性设计

好，咱们直接进入正题。微服务不是把一个大项目拆成几个小项目就完事了。如果拆完以后，服务之间还是你中有我、我中有你，那还不如不拆。我见过太多团队，拆了十几个服务，结果改一个功能要同时上线八个服务——这比单体还痛苦。

所以，要真正用好微服务，你得先吃透四个核心原则。说白了，它们是微服务的“宪法”。今天我就结合自己踩过的坑，跟你聊聊这四个原则到底怎么落地。

2.1 单一职责：一个服务只做一件事

这个原则听起来简单，做起来最难。什么叫“一件事”？我举个例子：订单服务。很多团队把订单、支付、物流、优惠券全塞进一个服务里。理由是“它们都跟交易相关”。嗯，这其实就违背了单一职责。

我个人习惯这样判断：如果这个服务需要修改的原因超过一个，就该拆了。比如，因为支付方式变了要改代码，又因为物流规则变了也要改代码——那这两个职责就应该分开。

我在项目中遇到过这样一个案例：一个“用户服务”包含了用户信息、用户积分、用户等级、用户收藏。结果每次改积分规则，都要全量回归用户登录和收藏功能。后来我们把它拆成了四个服务，每个服务的代码量减少了70%，上线频率从两周一次变成了随时可发。

2.2 自治性：每个服务都是独立的“小王国”

自治性，说白了就是每个服务能自己说了算。它有自己的数据库，有自己的部署流水线，有自己的技术栈选择权。你想想看，如果A服务要改个字段，还得等B服务配合上线，那还叫什么微服务？

自治性有三个关键点：

• 数据自治：绝不共享数据库。服务之间只能通过API通信。
• 部署自治：每个服务可以独立构建、测试、部署。
• 技术自治：允许不同服务使用不同的语言和框架。

我记得有一次，一个团队把订单服务和支付服务共用一个MySQL库。支付服务做了一次大表DDL，结果订单服务挂了整整两个小时。这就是典型的“不自治”带来的灾难。

2.3 去中心化：别让一个点拖垮整个系统

去中心化，核心就是消除单点依赖。我见过最典型的反模式：所有服务都通过一个“中心网关”来通信。结果网关挂了，全系统瘫痪。这跟单体架构有什么区别？

去中心化体现在几个层面：

我个人习惯在服务内部实现熔断和重试逻辑，而不是全扔给网关。这样即使网关挂了，服务之间还能通过直连通信。你想想看，如果每个服务都自带“免疫系统”，整个系统的韧性会强很多。

// 每个服务内置熔断器，不依赖中心组件
@Bean
public CircuitBreakerFactory circuitBreakerFactory() {
    return new Resilience4JCircuitBreakerFactory();
}

// 服务间调用自带重试和降级
@Retryable(value = {TimeoutException.class}, maxAttempts = 3)
public Order getOrder(String orderId) {
    // 直接调用目标服务，不经过中心网关
    return orderServiceClient.getOrder(orderId);
}

2.4 弹性设计：系统要能“带病运行”

弹性设计，说白了就是系统要能容忍失败。微服务架构中，网络延迟、服务宕机、磁盘写满都是常态。你不能指望所有服务永远健康。我经常跟团队说：把失败当成一种预期行为来设计。

弹性设计的核心手段：

• 熔断：当下游服务故障率达到阈值，自动切断调用，快速失败。
• 限流：保护自己不被突发流量冲垮。
• 重试 + 退避：失败后等一会儿再试，别把对方打挂。
• 降级：核心功能保底，非核心功能可以暂时关闭。
• 隔离：线程池隔离、信号量隔离，一个服务出问题不影响其他。

弹性设计还有一个容易被忽略的点：优雅降级。比如，推荐服务挂了，商品详情页可以展示默认推荐，而不是直接报500。用户可能觉得推荐不太准，但至少能正常下单。这比整个页面打不开强太多了。

小结一下

这四个原则，其实是一个整体。单一职责决定了“拆成什么样”，自治性决定了“拆完后怎么管”，去中心化解决了“怎么避免单点”，弹性设计解决了“出问题了怎么办”。

我建议你在做微服务拆分时，拿这四个原则当 checklist。每拆一个服务，就问自己：

• 这个服务职责单一吗？
• 它能独立部署和运行吗？
• 它有没有引入不必要的中心依赖？
• 它挂了以后，系统还能正常运转吗？

如果四个答案都是“是”，那恭喜你，这个服务拆得靠谱。如果有一个“否”，嗯，你可能需要重新考虑一下边界了。

下一章，我会带你实战：如何用领域驱动设计（DDD）来指导微服务拆分。到时候咱们拿一个真实的电商系统来练手。