示例：Istio VirtualService 配置
从单体到云原生：我在架构演进中的实战记录
我是李航，现在一家中型互联网公司负责后端架构。我们团队最早从一个典型的单体应用起步，那时候功能不算多、用户也不算大，日子过得倒也清闲。但随着业务发展，系统开始暴露出各种问题——性能瓶颈、维护成本飙升、上线周期漫长……这些都成了我们不得不面对的挑战。
今天想和大家分享一下这几年里，我们在后端架构上的演化过程。这条路走得不容易，但我们从中获得的经验非常宝贵，希望能对你有所启发。
背景与起点：曾经那个“简单”的单体时代
项目刚启动的时候，一切都很“标准”。使用的是Spring Boot搭建的Java单体应用，部署在两台ECS服务器上，前端通过Nginx做负载均衡。数据库是MySQL单实例，Redis用来做缓存，整个技术栈简洁清晰。
当时我们的日均请求量大概也就几十万次，接口响应时间稳定在100ms以内，上线流程也很简单——本地测试完直接打包上传服务器，重启Tomcat就完成了。虽然代码逐渐有些混乱，比如业务逻辑和数据访问混在一起，但大家都觉得这不是问题，毕竟人少、活不多。
第一次阵痛：当单体架构撑不住了
事情在上线周年庆活动之后发生了变化。那天为了推广新产品，我们搞了个限时折扣。结果短短几个小时，流量暴涨了10倍以上，服务频繁出现502错误，MySQL CPU飙到98%，Redis连接池被打满。
那次故障持续了将近4个小时。我们临时扩容了服务器，手动把部分请求做了分流，最后才勉强扛过去。事后复盘时，我意识到不能再走老路了，必须重构系统架构。
这时候摆在面前的有几种选择：
- 继续优化单体结构（加缓存、分库分表）
- 拆微服务
- 推进容器化 + 云原生方案
综合考虑长期发展和运维成本，我们选择了第三条路——向云原生靠拢，同时进行服务拆分。
架构升级路线图：从拆分开始
第一阶段：服务拆分 & 数据解耦
我们先对系统核心业务进行了梳理，把订单、商品、用户这几个模块拆出来作为独立服务。每个服务都是基于Spring Cloud搭建的标准微服务架构，使用OpenFeign做服务间通信，注册中心是Eureka，配置中心用Spring Cloud Config。
拆分过程中最大的难点其实是数据库的解耦。原本的单体应用里很多地方直接跨表查询，现在要改成服务调用。举个例子，原来下单需要同时操作订单表和用户余额表，现在要先调用用户服务扣余额，再写入订单。
// 原来下单的伪代码
public Order createOrder(User user, Product product) {
// 扣用户余额
user.balance -= product.price;
// 创建订单
Order order = new Order();
...
return order;
}
// 微服务改造后的做法
public OrderDTO createOrder(Long userId, Long productId) {
// 先调用用户服务扣余额
userService.deductBalance(userId, price);
// 再创建订单
Order order = new Order(...);
return convertToDTO(order);
}
这个过程中我们遇到两个比较大的坑：
- 服务依赖复杂度上升，A调B、B调C，容易造成雪崩效应；
- 分布式事务难处理，默认情况下无法保证一致性。
第一个问题我们用了熔断降级机制，在Feign调用里集成Hystrix，并配合超时重试机制。第二个问题，最初我们采用“最终一致”的方式，后续引入了Saga模式实现回滚逻辑，直到后面上了消息队列+本地事务表。
第二阶段：基础设施容器化 & 服务网格
随着服务数量增长到了7个，我们发现传统的部署方式越来越吃力，每个服务都要自己管理JVM参数、监控脚本、发布流程，特别繁琐。
于是我们开始推进容器化改造，使用Docker构建镜像，Kubernetes做编排调度，Prometheus + Grafana做监控，EFK（Elasticsearch + Fluentd + Kibana）做日志收集。
这里有个关键决策是：是否使用Istio做服务治理。我们一开始没有上Istio，只用了基础的Kubernetes Service和Ingress，后来发现服务间通信的可观测性太差、限流熔断配置分散，所以最终还是引入了 Istio。
部署Istio的过程其实挺痛苦的。尤其是初期版本不兼容、Sidecar注入失败等问题频频发生。印象最深的一次是在压测环境下，所有的调用都在超时，查了很久才发现是因为Sidecar没生效，导致路由规则完全失效。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: user-service-route
spec:
hosts:
- "user.prod.local"
http:
- route:
- destination:
host: user-service
port:
number: 8080
第三阶段：拥抱Serverless与弹性伸缩
到了这一步，服务稳定性和可扩展性已经比以前好太多了，但随着春节促销等活动的到来，我们又遇到了新的压力点：如何应对极端流量波动？
这时候我们尝试用上了AWS Lambda处理一些非实时任务（比如生成报表、发送邮件），同时把部分服务迁移到Knative平台上，实现自动伸缩。例如，库存查询接口在平时QPS只有100，但在大促期间能冲到几千，这时候自动扩缩容的优势就体现出来了。
我们还结合Prometheus指标配置了HPA（Horizontal Pod Autoscaler）：
# Kubernetes HPA示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: user-service-autoscaler
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: user-service
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
实战踩坑经验总结
这段经历下来，我们踩了不少坑，也总结了一些经验教训：
1. 服务拆分不是越细越好
刚开始我们试图按模块切得很细，结果服务之间调用太多，反而带来了延迟和复杂度。后来调整策略，以业务边界为核心，避免过度拆分。
2. 不要忽略可观测性建设
早期我们只关注功能开发，忽略了监控和链路追踪，线上出问题很难快速定位。后来引入了Zipkin做分布式追踪，效果非常好。
3. 优先落地自动化流程
CI/CD一定要尽早做起来。我们是后期才推起的GitLab CI + Jenkins组合，实现了提交即构建 + 自动化部署，效率提升显著。
4. 技术选型要适度
不要盲目追求新技术，比如我们在初期尝试用Linkerd代替Istio，结果因为社区活跃度不足、文档不全而放弃。选型前最好调研清楚生态支持程度。
5. 灰度发布不能忽视
有一次我们误操作把新版本直接上线，结果引发了连锁故障。后来我们建立了灰度发布机制，每次更新都先发灰度环境跑一小部分流量观察。
架构升级带来的实际收益
这次架构演进给公司带来了很多实际好处：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 平均接口响应时间 | 150ms | 80ms |
| 故障恢复时间 | 数小时 | <30分钟 |
| 上线频率 | 每周1~2次 | 每天多次 |
| 新服务接入时间 | 3天+ | 半天 |
| 容器资源利用率 | 50% | 80%+ |
更重要的是系统的可扩展性大大增强。我们可以在节假日快速扩容，也可以根据业务需求灵活拆分服务，整体架构更加健壮。
给同行朋友的建议
如果你也在面临系统架构升级的抉择，我想送你几点来自前线的真实建议：
- 以业务为驱动去拆服务，而不是单纯为了微服务而微服务。
- 技术债可以适当保留，但不要拖到不可收拾的地步。
- 重视监控和自动化能力的建设，它们是你运维的“左膀右臂”。
- 推动团队形成良好的开发习惯和工程文化，比一两个技术框架更重要。
- 云原生不是目的，而是手段，最终目的是提升业务交付效率和稳定性。
结语：架构演化是一场持久战
回顾这几年的架构演变历程，我觉得最难的从来不是具体的技术选型或实现细节，而是如何在有限资源下做出合理的取舍。每一次演进都不是非黑即白的决定，而是基于当时的背景、人力、业务节奏做出的折中方案。
从一个简单的单体应用，到如今的多微服务、容器化、云原生体系，这趟旅程让我深刻体会到：软件架构没有银弹，只有不断适应业务需求的变化与团队的成长。
希望这篇文章能给你一点启发。如果你也在转型的路上，欢迎留言交流，我们一起成长。
评论 0