application.yml
技术探索与实践：从“能跑”到“跑得稳”的那些事儿
一、引言：一次上线事故带来的反思
事情要从两年前的一个项目说起。那会儿我们团队在做一个电商平台的重构项目，目标是把一个单体架构逐渐向微服务过渡。当时的背景是业务增长迅速，老系统已经支撑不了高并发和快速迭代的需求了。
我们选用了Spring Cloud Alibaba这一套技术栈作为后端基础，整体结构也还算清晰。但在第一次上线的时候，出现了非常严重的问题——新服务上线不到三分钟，QPS直接打爆，大量接口出现超时，甚至影响到了老系统的部分功能。当时我们在会议室里集体盯着监控面板，心里直冒冷汗。
这件事给我很大触动，它让我意识到：技术方案选得好，不一定就能跑得好；而技术落地的过程，远比“选什么”更重要。
于是后来我们就踏上了这段边踩坑、边优化、边沉淀技术方案的实践之路。这篇文章就是想和大家分享一下这个过程中的经验教训、关键技术点以及我们的思考方式。
二、问题描述：服务雪崩？还是架构设计的问题？
那次事故之后，我们开始复盘整个流程。问题的根本原因其实并不是代码层面的Bug，而是多个维度的技术决策叠加起来产生的副作用：
注册中心压力大，请求阻塞
我们一开始使用Eureka做服务注册发现，由于微服务数量较多（十几个），再加上刚上线时心跳密集，导致注册中心频繁报出连接超时和拒绝服务的情况。服务调用链路长，缺乏熔断机制
在一次促销活动中，某个依赖服务出现异常但未及时降级，结果引发连锁反应，最终造成整个交易链条崩溃。数据库连接池不够，SQL效率低下
数据层用的是MySQL+MyBatis，但很多SQL没加索引，或者逻辑复杂导致执行时间过长，拖垮了整个服务。监控和报警系统形同虚设
虽然接入了Prometheus+Grafana，但由于配置不全、告警阈值设置不合理，出了问题根本没人知道。
这些问题归结起来，其实就是一个关键词：稳定性。
我们当时面临的核心挑战就是：在快速迭代的前提下，如何构建一套稳定可控、可伸缩、可观测的技术体系？
三、解决方案：技术选型的权衡与架构升级
1. 技术选型调整：不再盲目追求热门
从Eureka换成了Nacos
Eureka虽然是老牌注册中心，但它本身没有配置管理能力，而且官方已经停止维护。换成Nacos后，除了服务注册发现以外，还能顺带解决动态配置的问题。引入Sentinel进行流控与熔断
我们之前只用了Ribbon+Feign做负载均衡和远程调用，但一旦下游服务不可用，整个链路就会被堵死。后来我们统一接入了Alibaba Sentinel，设置了熔断规则和限流策略，有效防止了级联故障。数据库连接池更换为HikariCP + SQL优化
原先用的Druid虽然功能强大，但性能不如HikariCP，在高并发下表现不够稳定。我们通过SQL慢查询分析工具（如SkyWalking）找出耗时语句，并加上合适的索引，效果非常明显。全面升级监控体系
引入SkyWalking实现链路追踪，Prometheus+Granfana继续保留作为基础设施监控手段，同时也对接了阿里云ARMS进行异常检测。
2. 架构分层设计思路
我们采用了典型的四层架构模型：
API 层 → 业务服务层 → 基础设施层（数据/缓存/中间件）→ 系统支撑层（日志/监控/配置）
每一层都有各自的边界和职责划分。比如：
- API 层主要做参数校验、权限控制、路由转发；
- 业务服务之间采用RPC通信，封装成独立模块便于管理；
- 基础设施层使用多租户设计，不同环境隔离；
- 所有公共组件（例如日志、缓存、定时任务）都抽象成SDK供业务方调用。
这种设计让每个团队可以专注于自己的核心业务逻辑，同时又能共享底层能力。
四、关键代码实践：看看我们是怎么写的
为了让大家更直观地理解我们的做法，我贴一段实际开发中用到的Sentinel限流配置示例：
public class OrderService {
private static final String ORDER_FLOW_KEY = "order-create";
public void createOrder(OrderRequest request) {
try {
Entry entry = SphU.entry(ORDER_FLOW_KEY, EntryType.OUT);
// 业务逻辑处理
processOrder(request);
entry.exit();
} catch (BlockException ex) {
// 被限流或降级时的兜底处理
fallbackHandler.handle(ex);
}
}
// 熔断规则初始化（一般放在初始化类中）
public void initRule() {
List<DegradeRule> rules = new ArrayList<>();
DegradeRule rule = new DegradeRule();
rule.setResource("order-create");
rule.setGrade(CircuitBreakerStrategy.RT);
rule.setCount(500); // 响应时间超过500ms触发熔断
rule.setTimeWindow(10); // 熔断窗口期10秒
rules.add(rule);
DegradeRuleManager.loadRules(rules);
}
}
再来看一下Nacos配置中心的核心初始化代码：
spring:
cloud:
nacos:
config:
server-addr: 127.0.0.1:8848
extension-configs:
- data-id: common-config.yaml
group: DEFAULT_GROUP
refresh: true
这样我们就可以在各个微服务中统一读取common-config.yaml里的配置信息，比如数据库连接串、缓存开关、第三方服务地址等。
五、踩坑经验分享：那些年我们一起走过的弯路
1. Nacos集群部署的坑
最开始我们只是在本地单机运行Nacos，感觉挺稳定的。等到上测试环境的时候，简单搭了一个两节点的小集群，结果遇到数据同步不同步的问题，服务有时候能发现有时候发现不了，特别头疼。
后来查文档才知道，Nacos默认的CP一致性模式下，必须奇数个节点才能保证可用性。我们果断扩容到三个节点，加上合理的选举机制配置后才彻底解决问题。
2. SkyWalking采集器太吃资源
刚开始我们为了全面监控，所有服务都接入了SkyWalking Agent，结果线上服务器CPU突增，甚至有些低配的机器直接挂掉了。这说明什么呢？
不是所有场景都需要埋点，也不是越细致越好。后来我们做了分级采集，对于核心链路进行完整埋点，非核心服务仅开启基础指标采集，资源消耗下降明显。
3. 没有考虑灰度发布机制
早期我们服务上线要么全量发布，要么就停掉全部服务重来一遍。后来在某次发版过程中，不小心把一个兼容性有问题的版本推上去了，导致用户支付失败比例剧增。
我们吸取教训后，增加了K8s滚动更新+流量染色的能力，结合OpenTelemetry实现了灰度发布和回滚机制，大大降低了风险。
六、效果总结：从“怕上线”到“敢上线”
这套体系搭建完成后，我们经历了很多次大促和灰度发版，整体稳定性有了明显提升：
- QPS承载能力提升了约 3倍
- 故障响应时间从之前的十几分钟压缩到 2分钟内
- 平均MTTR（平均修复时间）从 2小时 下降到 20分钟以内
- 新人入职后熟悉成本降低，开发效率显著提高
更重要的是，大家都从以前那种“上线怕炸”的心态中走了出来，现在反而觉得：只要做好预案和保障，任何变更都不再可怕。
七、几点建议：写给同行朋友们的心里话
1. 技术选型要务实，不能光看宣传
现在很多框架都号称自己“支持百万级QPS”，“零延迟”，“开箱即用”。但实际上呢？真正适合你的，一定是那个你能驾驭得了、社区活跃、有明确文档和技术支持的。
2. 不要一开始就追求“完美架构”
我见过太多团队上来就想搞中台、微服务、分布式事务、异地多活……最后什么都做不成。真正的架构演进应该是随着业务发展逐步推进的，而不是为了架构而架构。
3. 重视运维体系建设
再牛的系统，如果缺少良好的运维支撑，上线后也撑不过三天。日志、监控、链路追踪、自动化部署这些，才是系统稳定性的真正根基。
4. 给自己留一条退路
每次上线前，一定要准备好降级预案和回滚路径。哪怕是一个简单的配置开关，都能让你在关键时刻从容应对。
5. 别怕犯错，关键是能快速恢复
我记得我们有一次把Redis缓存误删了，整整半小时服务都在缓慢恢复。但正是这次事件让我们意识到：容错机制的价值远高于防错机制。
八、结语：技术这条路，越走越宽
回顾这些年的工作经历，我发现做技术最难的不是学习新技术，而是如何把技术用好、用准、用得恰到好处。我们不需要每一个人都精通每一种语言、每一套框架，但我们要有能力去判断哪些技术适合当下的业务需求。
每一次上线事故背后，都是一个成长的机会；每一次技术选型的背后，也都是一次对业务价值的深度思考。
如果你也在做类似的技术改造或者架构升级，希望这篇来自实战经验的文章能给你一点启发和参考。技术路上，愿我们都少些焦虑，多些底气。
共勉。
评论 0