application.yml 示例
从0到1搭建Spring Cloud Alibaba微服务架构：一个技术负责人的实战笔记
去年年底，我们团队接手了一个从单体应用迁移到微服务架构的项目。说实话，一开始大家都挺“懵”的——虽然之前都有接触过 Spring Cloud 的基本概念，但真正要把它用在生产环境下，并且是基于阿里的一整套生态（也就是 Spring Cloud Alibaba），那感觉就完全不同了。
这篇文章我会以一个技术负责人的视角，结合我们项目中的真实经历，聊一聊我们在迁移过程中如何选型、遇到哪些坑、踩了哪些雷，以及最终落地后带来的好处和一些经验总结。
为什么选择Spring Cloud Alibaba？
我们的项目本身是一个中大型的电商平台，业务逻辑复杂，接口调用量非常大。原先的单体架构已经支撑不了快速增长的流量，系统经常出现性能瓶颈和部署不便的问题。
我们做了一轮技术调研，对比了几种方案：
- Spring Cloud Netflix（Eureka + Feign + Zuul）：虽然生态成熟，但是Netflix 系列组件基本处于“停止维护”状态，社区活跃度也不如以前。
- Dubbo + Zookeeper：性能不错，但我们团队对 Dubbo 的熟悉程度不够，且希望继续使用 Spring Boot 的开发体验。
- Kubernetes + Service Mesh（Istio）：理想很丰满，但实际落地成本太高，尤其是在当时的人员配置和时间窗口下不太现实。
权衡之下，我们最终决定采用 Spring Cloud Alibaba（SCA），一方面是因为它兼容 Spring Cloud 标准 API，学习成本低；另一方面是它集成了 Nacos、Sentinel、Seata 等阿里巴巴自研中间件，非常适合国内互联网环境下的生产级部署。
迁移过程中的挑战与抉择
在正式推进项目重构前，我们梳理出了几个核心问题：
- 服务注册与发现怎么选？Nacos vs Eureka
- 服务间通信用Rest还是Feign？负载均衡策略怎么定？
- 数据库拆分怎么做？如何处理分布式事务？
- 系统高可用设计怎么做？熔断限流怎么落地？
- 日志、监控、链路追踪怎么实现？
这些问题不解决，后面的微服务根本走不通。
技术选型与实现思路
1. 服务注册中心：Nacos 成为首选
我们一开始考虑过 Eureka，但发现它的集群部署复杂、管理麻烦，文档也更新缓慢。而 Nacos 不仅支持服务注册发现，还内置了配置中心，这对我们来说简直是一举两得。
后来我们也尝试对比了 Consul，但 Nacos 的中文社区和阿里生态的支持让我们更安心。
spring:
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 # Nacos Server地址
2. 服务通信：Feign+Ribbon 是最佳实践
我们最初想用 RestTemplate，但代码写起来太繁琐，于是选择了 Feign 做声明式调用。配合 Ribbon 实现客户端负载均衡，默认使用的是轮询策略，也可以通过自定义规则实现灰度发布等功能。
// 示例：FeignClient 调用商品服务
@FeignClient(name = "product-service")
public interface ProductServiceClient {
@GetMapping("/products/{id}")
Product getProductById(@PathVariable("id") Long id);
}
3. 分布式事务：Seata 解决一致性难题
这是整个项目中最难啃的一块骨头。原来的下单流程涉及到多个数据库的操作，比如库存减少、订单创建等。如果不处理好事务一致性，很容易出现数据混乱。
我们在前期试用了本地消息表 + 定时补偿的方式，虽然可行但代码量太大，后期难以维护。
最终选择了 Seata，在 AT 模式下只需要加个注解，就能自动进行事务回滚或提交，非常方便。
// 使用 @GlobalTransactional 开启全局事务
@GlobalTransactional
@Transactional
public void placeOrder(OrderDTO orderDTO) {
// 下单逻辑
inventoryService.reduceStock(orderDTO.getProductId(), orderDTO.getCount());
orderMapper.createOrder(orderDTO);
}
不过要注意，AT 模式依赖 undo_log 表，所有的数据变更都要在这张表里记录，所以表结构设计上需要额外增加这张辅助表。
4. 熔断降级：Sentinel 打通最后一公里
早期我们没有集成 Sentinel，结果上线一次压测的时候，某个下游服务挂了导致整个链路崩溃，用户请求直接超时返回失败页面。
后来接入了 Sentinel，不仅可以通过控制台设置熔断阈值、线程池隔离，还可以结合 Sleuth 和 Zipkin 实现链路级别的精细化监控。
配置示例：
feign.sentinel.enabled: true
同时我们在业务层也做了兜底的 fallback：
@FeignClient(name = "order-service", fallback = OrderServiceFallback.class)
5. 日志与监控：ELK + SkyWalking 大显身手
我们采用了 ELK（Elasticsearch + Logstash + Kibana）来做集中式日志分析，所有服务都统一将日志输出到 Logstash，再由 Kibana 做图形化展示。
另外，为了更好地观察分布式调用链，我们引入了 Apache SkyWalking，它完美兼容 SCA，还能自动收集指标、追踪异常。
踩过的坑和解决办法
坑1：服务实例频繁上下线导致Feign调用失败
现象：某个服务节点重启之后，Feign 调用仍然指向旧地址，导致调用失败。
原因：Spring Cloud 默认的服务刷新延迟是30秒，而我们很多场景都是实时性强的操作。
解决方案：
- 设置心跳间隔和服务剔除间隔缩短：
spring.cloud.nacos.discovery.heartbeat-interval: 5000
spring.cloud.nacos.discovery.deregister-timeout: 10000
- 同时开启主动服务探测机制，比如使用 HealthCheck 监控节点状态。
坑2：Sentinel 控制台看不到任何数据
现象：明明有请求，Sentinel 控制台却显示无资源。
原因：忘记在入口添加 SentinelWebMvcConfig 配置类，导致 Web 请求没有被识别。
解决：加入如下类即可：
@Configuration
public class SentinelConfig implements WebMvcConfigurer {
@PostConstruct
public void init() {
WebMvcConfigRegistry.registerWebMvcConig(new SentinelWebMvcConfig());
}
}
坑3：Seata 在并发下单时出现脏写
我们初期把库存服务和订单服务作为两个分支，Seata 没有问题。但在压测时发现在极端并发情况下会出现重复减库存的情况。
排查发现是因为数据库行锁冲突没触发事务回滚，而是抛出异常未被捕获。
解决方式：
- 使用
select ... for update显式加锁 - 对于异常捕获要严格处理，避免漏掉关键 error code
上线后的效果与收益
项目上线至今已运行超过半年，整体表现超出预期：
- 部署效率提升：得益于 Spring Cloud Alibaba 的开箱即用能力，新服务构建时间减少了 60%
- 故障隔离性增强：每个服务独立部署，即使某一个服务宕机也不会影响其他模块
- 运维成本下降：结合 Nacos 的动态配置推送和 Sentinel 的限流策略，日常运维工作变得轻松许多
- 可扩展性强：后续新增会员服务、推荐服务都无需改动原有架构，只需按规范接入即可
最重要的是，团队成员的技术成长非常明显。大家从最初的“摸着石头过河”，到现在能独立主导服务的设计与部署，甚至开始反向推动其他项目的微服务化改造。
经验分享：给正在入坑SCA的你几点建议
不要盲目追求新技术：Spring Cloud Alibaba 并不是万能的，一定要根据自己的业务场景来判断是否真的需要引入这么多组件。
组件版本要谨慎升级：SCA 的版本更新快，不同版本之间的兼容性问题比较多，我们曾因升级到某个 Spring Boot + SCA 的组合版本导致 Nacos 注册不上，花了一天才定位清楚。
提前规划好服务边界和接口粒度：服务拆得太细容易带来复杂的治理问题，接口设计不合理也会让调用链变长。建议前期做好业务域划分，遵循DDD的思想。
重视可观测性建设：日志、链路、监控一定要尽早纳入基础设施，否则后面会追悔莫及。
保持与社区同步：阿里云每年都会推出新的功能和优化点，订阅 GitHub 仓库和相关公众号，及时了解最新动向很有必要。
写在最后：微服务不是银弹，但它是通往规模化发展的必经之路
回顾这段旅程，其实并不是一帆风顺的。我们踩了很多坑，也曾因为技术决策反复争论不休。但正是这些磨合，才让我们团队的技术能力和协作水平迈上了一个新台阶。
如今，我们不仅用好了 Spring Cloud Alibaba，也在逐步朝着云原生的方向迈进。我相信未来的架构演进会更智能、更轻量，但无论如何，微服务仍然是我们这个阶段最合适的选项之一。
如果你也在微服务的路上探索前行，欢迎留言交流。我们一起成长，一起“踩坑”。
评论 0