微服务

引子：一次线上故障的排查噩梦 2021年某晚，某电商平台接口响应慢，用户投诉激增。 排查过程： 运维：哪个服务出问题了？（无监控） 开发：日志在哪？（分散在100台服务器） 架构师：调用链路是什么？（无链路追踪） 耗时：3小时才定位到问题（数据库连接池配置错误） 教训：微服务架构下，可观测性至关重要 一、可观测性的本质 1.1 什么是可观测性？ **可观测性（Observability）**是指通过外部输出理解系统内部状态的能力。 三大支柱： Metrics（指标）：数字化的度量（QPS、响应时间、错误率） Logs（日志）：事件的记录（请求日志、错误日志） Traces（追踪）：请求的全链路视图（调用链路） 1.2 监控 vs 可观测性 维度 监控 可观测性 目标 已知问题 未知问题 方式 预设指标 任意维度查询 例子 CPU > 80%告警 为什么这个请求慢？ 二、监控体系：Prometheus + Grafana 2.1 监控指标的四个黄金信号 延迟（Latency）：请求响应时间 流量（Traffic）：QPS、TPS 错误（Errors）：错误率 饱和度（Saturation）：CPU、内存、磁盘使用率 2.2 Prometheus监控配置 1. 添加依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency> 2. 配置application.yml management: endpoints: web: exposure: include: "*" # 暴露所有端点 metrics: export: prometheus: enabled: true tags: application: ${spring.application.name} 3. 自定义指标 ...

引子：一个请求背后的Java技术栈全貌 2025年某天上午10点，用户小王在电商平台下了一个订单，点击"提交订单"的那一刻，背后的Java技术栈开始运转： 0.01秒内发生的事情： Nginx 接收HTTP请求 → 转发到 Spring Cloud Gateway 网关 Gateway 鉴权（JWT） → Nacos 服务发现 → 路由到订单服务 订单服务（Spring Boot）： Caffeine 本地缓存检查库存 MyBatis 查询 MySQL 订单信息 Redis 分布式锁防止超卖 RabbitMQ 发送消息到库存服务 库存服务 消费消息 → 扣减库存 → Elasticsearch 更新商品索引 支付服务 调用第三方支付接口 → Sentinel 限流熔断 全链路日志通过 SkyWalking 追踪 → 存储到 ClickHouse 这背后，涉及50+核心技术组件，组成了现代Java应用的完整生态。 今天我们就来系统化梳理这张技术全景图。 一、Java技术栈分层架构 1.1 完整分层视图 ┌─────────────────────────────────────────────────────────┐ │ 业务应用层（Business Layer） │ │ 电商平台、金融系统、物流平台、内容管理系统... │ └────────────────────┬────────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────────┐ │ 微服务治理层（Microservice Governance） │ │ 服务注册、配置中心、API网关、链路追踪、限流熔断... │ │ Spring Cloud、Dubbo、Nacos、Sentinel、SkyWalking │ └────────────────────┬────────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────────┐ │ 应用框架层（Application Framework） │ │ Spring Boot、Spring MVC、Spring Data、Spring Security │ │ MyBatis、Netty、Quartz、Shiro... │ └────────────────────┬────────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────────┐ │ 中间件与存储层（Middleware & Storage） │ │ MySQL、Redis、MongoDB、Elasticsearch、RabbitMQ、Kafka │ └────────────────────┬────────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────────┐ │ Java核心层（Core Java） │ │ JVM、并发包(JUC)、集合框架、IO/NIO、网络编程、反射... │ └─────────────────────────────────────────────────────────┘ 二、Java核心层：基石技术 2.1 JVM：Java虚拟机 JVM是Java生态的基石，理解JVM是从初级到高级的分水岭。 ...

引言：从单体到微服务的演进之痛 2015年，Netflix宣布他们的微服务架构已经包含超过1000个微服务，每天处理数十亿次API调用。这标志着微服务架构从理论走向了大规模生产实践。 但微服务不是银弹。在享受它带来的灵活性、可扩展性的同时，我们也必须面对新的挑战。 上一篇我们讲了流量控制的本质，这篇我们深入微服务场景，看看现代分布式系统面临的三大稳定性威胁：流量洪峰、服务雪崩、资源耗尽。这三个问题如果不妥善处理，任何一个都足以让整个系统在几分钟内瘫痪。 一、挑战1：流量洪峰——当10倍流量来袭 1.1 真实案例：2019年双11零点的惊险时刻 2019年双11，阿里云技术团队事后复盘了一个惊险瞬间： 零点前1秒： 系统QPS：50万/秒 服务器CPU：60% 数据库连接：5000个 零点后1秒： 系统QPS：680万/秒（13.6倍） 服务器CPU：95%（濒临极限） 数据库连接：10000个（已达上限） 零点后2秒： 部分慢查询开始出现 RT从50ms上升到200ms 用户开始疯狂刷新（雪上加霜） 如果没有流量控制和弹性扩容，这个洪峰足以在10秒内压垮整个系统。 1.2 流量洪峰的特征 流量洪峰不是均匀的，而是呈现尖刺特征： QPS | | ╱╲ | ╱ ╲ | ╱ ╲ |─────────────────╱ ╲──────────── | 时间 └─────────────────────────────────────> 平时 活动开始 高峰 回落 关键问题： 短时极高：可能在1秒内达到10倍甚至100倍 难以预测：用户行为受心理因素影响（从众效应） 恢复困难：系统崩溃后，重启需要时间，流量会继续堆积 1.3 微服务架构下的放大效应 单体应用时代，1个用户请求 = 1次数据库查询。 微服务时代： 1个用户请求 → 网关（1次调用） → 订单服务（1次调用） → 用户服务（查询用户信息） → 商品服务（查询商品信息） → 库存服务（检查库存） → 优惠券服务（计算优惠） → 积分服务（计算积分） ↓ 5次下游调用 × 3次数据库查询 = 15次数据库操作 放大效应： ...

引言：一张春运火车票背后的技术博弈 每年春节前夕，亿万中国人都会参与一场没有硝烟的战争——春运抢票。 2024年春运首日，12306网站的访问量在开售瞬间达到每秒1400万次。这是什么概念？相当于全国1/100的人在同一秒钟点击同一个网站。如果没有任何保护机制，这样的流量洪峰足以在几秒钟内压垮任何系统。 但12306并没有崩溃。用户虽然排队等待，但系统始终稳定运行，每秒稳定处理数十万笔订单。这背后，就是流量控制的功劳。 今天，我们从这个真实场景出发，深入理解什么是流量控制，为什么需要流量控制，以及流量控制在现代微服务架构中的重要性。 一、现实世界的流量控制：无处不在的智慧 在深入技术细节之前，让我们先看看身边的流量控制案例。你会发现，流量控制是人类应对资源有限性的普遍智慧。 1.1 高速公路收费站：削峰填谷 春节自驾回家，你一定遇到过收费站前的长龙。为什么要设置收费站？除了收费，更重要的作用是流量控制。 入口匝道信号灯：红灯时车辆等待，绿灯时放行，确保主路不拥堵 ETC车道与人工车道：快速通道和慢速通道分离，提高整体通行效率 应急车道管制：拥堵时临时开放，增加通行能力 这些措施的本质是：在有限的道路资源下，控制车流速度，避免拥堵导致整体瘫痪。 1.2 景区限流：保护体验与安全 故宫每天限流8万人，黄山限流5万人。为什么要限流？ 安全因素：超过承载能力会导致踩踏事故 体验保护：人山人海时，游客体验极差 资源保护：过度使用会损坏文物和生态 这里的流量控制策略更加精细： 预约制：提前规划，错峰入园 分时限流：上午下午分别限制人数 动态调整：根据实时人数关闭入口 1.3 电梯承载限制：刚性约束 电梯标注"限乘13人或1000kg"。这是最简单粗暴的流量控制： 硬性限制：超载则无法运行 即时生效：没有等待队列，超载必须减员 安全优先：宁可降低效率，也要保证安全 1.4 共同规律：资源有限，需求无限 仔细观察，这些案例都有三个共同特征： 资源有限：道路宽度、景区容量、电梯承重 需求波动：高峰期需求远超平时 控制策略：通过限制、排队、拒绝等手段保护系统 这就是流量控制的本质：在资源有限的前提下，通过合理的策略，保证系统稳定运行，并尽可能提升整体效率。 二、软件系统为什么需要流量控制 2.1 12306的技术挑战 回到12306抢票场景，让我们分析一下技术挑战： 正常时期（非春运）： 日均访问量：1亿次 峰值QPS：约10万/秒 系统资源：1000台服务器 春运开抢瞬间： 瞬时访问量：每秒1400万次（140倍流量洪峰） 如果不限流：需要14万台服务器（不现实） 实际策略：限流 + 排队 + 分流 2.2 不做流量控制的后果 假设12306不做任何流量控制，会发生什么？ 第1秒：1400万请求涌入 网络带宽打满（假设1Gbps，每个请求1KB，需要11.2Gbps） 服务器CPU飙升到100% 数据库连接池耗尽（配置1000个连接，但有140万个并发请求） 第2秒：系统开始崩溃 大量请求超时，用户疯狂刷新 流量不降反升（重试风暴） 数据库响应时间从10ms变成10秒 第3秒：雪崩效应 数据库连接堆积，内存溢出 服务器宕机，用户看到502错误 整个系统彻底瘫痪 恢复时间：可能需要数小时 清理堆积的请求 重启所有服务 用户信任度严重受损 2.3 流量控制的三大目标 通过12306的案例，我们可以总结出流量控制的三大核心目标： ...