加载中...
技术博客
深入探讨现代软件开发、分布式系统和前端架构。
SpringJava八股文
微服务网关与流量治理：Gateway + Sentinel
从"Zuul 1.x 网关在流量高峰时线程池耗尽，QPS 到 3000 就开始拒绝请求"这一真实困境出发，深入 Gateway + Sentinel 的流量治理实践；剖析 Gateway 的性能优势——基于 Spring WebFlux（Reactor + Netty）实现全链路异步非阻塞，一个 EventLoop 线程可处理数千个并发连接，而 Zuul 1.x 每个请求独占一个 Tomcat 线程，线程池（默认 200）耗尽后新请求直接 503；推导 Route 的匹配与过滤逻辑——请求到达后依次评估所有 Route 的 Predicate，首个匹配者被选中，然后按 Order 值排序执行 GlobalFilter 和 GatewayFilter 链，典型的过滤器链：AddRequestHeader → StripPrefix → SentinelGatewayFilter（限流检查）→ ReactiveLoadBalancerClientFilter（负载均衡）→ NettyRoutingFilter（HTTP 转发）；揭示网关限流的暗面——Gateway 内置的 RequestRateLimiter 基于 Redis 实现分布式令牌桶，KeyResolver 默认按 IP 限流，但 X-Forwarded-For 头可能被伪造，生产环境应结合用户身份做限流；Sentinel Gateway Adapter 提供了更细粒度的限流（按 Route ID、API 分组、请求参数），但规则配置需要通过 Sentinel Dashboard 或 Nacos 推送，增加了运维复杂度；深入动态路由的实现——Gateway 的 RouteDefinitionLocator 支持从多个来源加载路由，基于 Nacos Config 的监听器可以在配置变更后 1 秒内刷新路由，无需重启网关，这是实现蓝绿发布和灰度路由的基础设施；暴露网关的设计边界——网关不应承载复杂业务逻辑（如数据聚合、复杂鉴权），否则会从"轻量路由层"变成"重逻辑层"，复杂鉴权应下沉到独立的认证服务，数据聚合应使用 BFF（Backend for Frontend）模式，网关的职责应严格限定为"路由 + 限流 + 鉴权 + 日志"。
Feb 18, 2026
Java八股文Spring
Spring Cloud Alibaba：Nacos 服务治理与 Sentinel 流量控制
从"引入 spring-cloud-starter-alibaba-nacos-discovery 后服务自动注册到 Nacos，配置自动从 Nacos 加载"这一魔法出发，深入 Spring Cloud Alibaba 核心组件的工程实现；剖析 Nacos Discovery 的注册发现机制——服务启动时通过 NamingService 向 Nacos Server 注册实例信息（IP、端口、元数据），并启动定时心跳（默认 5 秒）维持租约，消费者通过 subscribe 订阅服务列表，Nacos 通过 UDP 推送变更通知，UDP 失败时退化为长轮询（默认 30 秒）拉取，这种"推为主、拉为备"的设计平衡了实时性和服务端压力；推导 Nacos Config 的动态刷新原理——应用在启动时从 Nacos Server 拉取配置并缓存到本地文件（failover 机制），同时建立长轮询连接监听配置变更，当配置被修改时，Nacos Server 推送变更通知，客户端收到后发布 RefreshEvent，@RefreshScope 标注的 Bean 被销毁并重新初始化，实现配置热更新；揭示 Sentinel Slot Chain 的设计——责任链模式将流量控制拆分为 9 个独立的 Slot，请求像小球一样依次滚过每个 Slot 的检查口，StatisticSlot 负责统计 QPS/RT，FlowSlot 负责限流判断（基于令牌桶/滑动窗口），DegradeSlot 负责降级判断（基于错误率/RT），任一 Slot 不通过即抛出 BlockException，这种设计比 Hystrix 的命令模式更灵活、更细粒度；深入 Sentinel 的暗面——默认规则存储在内存中，应用重启后规则全部丢失，生产环境必须通过 Sentinel Dashboard 推送规则到 Nacos/Apollo 做持久化，但 Dashboard 本身是高可用短板（单机内存存储），大规模集群需要改造为集群流控模式；最后暴露配置刷新的边界——@RefreshScope 通过代理对象实现 Bean 重建，重建期间并发请求可能拿到未完全初始化的 Bean，且重建过程会短暂阻塞，对延迟敏感的场景应使用 @ConfigurationProperties + @ConstructorBinding 的原生热更新方式。
Feb 15, 2026
SpringJava八股文
Dubbo 服务框架与调用原理
从"@DubboReference 注解让远程服务调用像本地方法一样简单"这一魔法出发，深入 Dubbo 服务框架的工程实现；剖析服务暴露的完整链路——ServiceConfig 解析服务接口和实现类，通过 ProxyFactory（默认 Javassist）创建 Invoker 代理，再由 Protocol（默认 DubboProtocol）打开 Server（默认 NettyServer）监听端口，最后将服务地址注册到注册中心；推导服务引用的过程——ReferenceConfig 向注册中心订阅服务地址，收到地址列表后通过 Protocol.refer() 创建 Client（默认 NettyClient），再由 ProxyFactory 生成消费者代理对象，代理的 InvocationHandler 将方法调用封装为 Invocation 对象，经过 Cluster、Directory、Router、LoadBalance 层层路由，最终发送到提供者；揭示 Dubbo SPI 的设计——相比 JDK SPI 的一次性加载所有实现，Dubbo SPI 通过 ExtensionLoader 实现按需加载、自适应扩展（@Adaptive 动态生成适配器类）和 AOP 包装（@Wrapper 实现装饰者模式），这是 Dubbo 高度可扩展的根基；深入集群容错的暗面——默认的 Failover 在失败时会重试 2 次，如果下游服务已崩溃，重试会放大故障（重试风暴），生产环境必须根据接口特性选择合适的容错模式（读操作用 Failover、写操作用 Failfast）；最后暴露 Dubbo 3.x 的变革——从接口级服务发现升级到应用级服务发现，注册中心不再存储每个接口的元数据，只存储应用级别的地址映射，配合 Triple 协议实现与 gRPC 生态的互通，但迁移成本是需要改造存量服务的注册发现逻辑。
Jan 22, 2026
Spring八股文Java
SpringBoot 监控与可观测性
从"凌晨 2 点生产环境告警：服务健康检查失败，但进程还在，接口却大量超时"这一真实 On-Call 困境出发，深入 SpringBoot 监控与可观测性的工程实践；剖析 Actuator 的设计哲学——它将应用的内部状态暴露为 HTTP 端点，/health 聚合所有 HealthIndicator 的状态，任何一个依赖项（数据库、Redis、MQ）不健康，整体状态就变为 DOWN，Kubernetes 的 livenessProbe 和 readinessProbe 正是基于这个端点做容器生命周期管理；推导 Micrometer 的指标模型——它不是监控系统的实现，而是监控系统的抽象层，Counter 只增不减（适合统计请求数），Timer 记录耗时和分位数（适合接口 RT），Gauge 记录瞬时值（适合内存、连接数），通过 MeterRegistry 将指标适配到不同的后端（Prometheus、InfluxDB、CloudWatch）；揭示健康检查的暗面——默认的 DataSourceHealthIndicator 会执行 SELECT 1 检查数据库，如果数据库负载高，这个健康检查本身就会成为压垮数据库的最后一根稻草，生产环境应该设置合理的超时（health.db.timeout）或将重依赖的检查降级；深入 SpringBoot 3.x 的 Observability 变革——SpringBoot 2.x 使用 Spring Cloud Sleuth 做分布式追踪，3.x 全面迁移到 Micrometer Observation API，通过 ObservationRegistry 统一 Metrics、Tracing 和 Logging，一次方法调用自动产生 Span 和 Metric，无需手动埋点；最后暴露监控的边界——监控不是越多越好，过多的指标会导致 Prometheus 的 cardinality 爆炸（标签组合过多导致时间序列指数增长），生产环境必须对指标做过滤和聚合，遵循"关键指标少数派"原则：只监控能指导行动的指标（如错误率、P99 延迟、饱和率），而不是所有能采集的指标。
Jan 9, 2026
Spring八股文Java
SpringBoot 启动流程与原理
从应用启动耗时 30 秒该如何排查瓶颈这一工程痛点切入，拆解 SpringBoot 完整启动流程：SpringApplication 构造时先推断应用类型，再加载 spring.factories 中注册的容器初始化器与监听器，提供启动扩展钩子；随后准备环境，依次解析命令行参数、系统属性、环境变量及多环境配置文件，高优先级配置会覆盖低优先级同名属性；核心容器刷新依托 AbstractApplicationContext.refresh ()，SpringBoot 扩展实现内嵌服务器创建与容器刷新完成事件发布，自动配置在 Bean 工厂后置处理器阶段加载解析；SpringBoot 通过启动监听器按固定时序发布多阶段启动事件，支持开发者在对应节点植入自定义逻辑；生产启动超 10 秒需及时优化，常见瓶颈在于冗余自动配置、初始化逻辑过重、包扫描范围过大，SpringBoot 3.x 的 AOT 编译与 GraalVM 原生镜像可将启动从秒级压降至毫秒级，但会牺牲部分动态能力。
Jan 2, 2026
SpringJava八股文
SpringBoot 自动配置与扩展
从项目引入第三方 Starter 无需任何配置就能直接使用的实际疑问切入，深入拆解 SpringBoot 自动配置底层原理：@SpringBootApplication 是复合注解，由标记配置类的 @Configuration、开启包扫描的 @ComponentScan、作为自动配置入口的 @EnableAutoConfiguration 组成，后者通过 @Import 注入 AutoConfigurationImportSelector，容器刷新时读取类路径下 META-INF/spring 指定自动配置文件并收集候选配置类；这些候选配置类依靠 @ConditionalOnClass、@ConditionalOnMissingBean 等条件注解做过滤，只有类路径存在对应类、容器缺少指定 Bean 时才生效，这也是引入 mybatis-spring-boot-starter 就能自动装配、移除依赖就失效的核心原因；同时自动配置存在隐患，条件注解加载顺序可能引发 Bean 意外覆盖，自定义数据源 Bean 会让框架自动配置的数据源失效，多自定义 Bean 共存时还会出现优先级不可控问题；而内嵌 Tomcat 则由 ServletWebServerApplicationContext 在容器刷新时检测 Tomcat 相关类，自动创建工厂、配置连接器与主机并启动服务，随 Spring 容器启停；本质上 SpringBoot 自动配置并非黑盒魔法，只是启动时替我们完成了「类路径存在依赖则自动注册对应 Bean」的条件判断，生产环境需借助调试日志或 Actuator 的 /conditions 端点核查自动配置生效与跳过情况，规避隐性 Bean 装配 Bug。
Jan 1, 2026
Spring八股文Java
Spring MVC 请求处理与核心组件
Spring MVC 请求处理的核心链路可浓缩为五步：① 入口分发：`DispatcherServlet`（前端控制器）接收所有请求，按 URL 分发给 `HandlerMapping`；② 定位与拦截：`HandlerMapping` 匹配到 Controller 方法，包装成 `HandlerExecutionChain`（含 Interceptor 链）返回；③ 适配执行：`HandlerAdapter` 调用 Handler 执行业务逻辑，前后分别触发 Interceptor 的 `preHandle` 与 `postHandle`；④ 响应输出：若标注 `@ResponseBody`/`@RestController`，直接序列化返回值写入响应，否则经 `ViewResolver` 渲染视图；⑤ 异常兜底：`HandlerExceptionResolver` 遍历 `@ControllerAdvice` 中的 `@ExceptionHandler` 方法，匹配异常类型后返回统一错误响应。关键边界有两点：一是 Filter 与 Interceptor 的本质区别——Filter 在 Servlet 容器层（Tomcat），可操作请求/响应体，Interceptor 在 Spring MVC 内部，能访问 Controller 与 Model，但无法修改请求体；二是 String 陷阱——`@RestController` 下返回 `String` 仍可能被当作视图名，需显式标注 `@ResponseBody` 或改用 `ResponseEntity<String>`，这是从传统 MVC 迁移到 RESTful 时最常见的坑。
Dec 22, 2025
SpringJava八股文
Spring AOP 与事务机制
从"@Transactional 注解加了但没回滚，线上出现数据不一致"这一真实事故出发，深入 Spring AOP 与事务的工程实现；剖析 AOP 代理的创建时机——在 Bean 生命周期的 BeanPostProcessor 后置处理阶段，如果 Bean 的某个方法匹配了 Pointcut，Spring 会用 JDK 动态代理或 CGLIB 生成代理对象替代原 Bean，代理对象在方法调用前后插入横切逻辑；推导 JDK 动态代理与 CGLIB 的本质区别——JDK 代理要求目标类实现接口，代理类也实现相同接口，通过 InvocationHandler 拦截接口方法调用；CGLIB 通过 ASM 字节码生成目标类的子类，重写非 final 方法，通过 MethodInterceptor 拦截，因此 CGLIB 不能代理 final 方法和 private 方法；揭示事务传播的暗面——REQUIRES_NEW 会挂起当前事务并创建新事务，新事务独立提交或回滚，但挂起操作会释放当前事务持有的数据库连接，如果滥用会导致连接池耗尽；NESTED 基于数据库的 savepoint，外层事务回滚会连带内层，但内层回滚不影响外层，然而它依赖 JDBC savepoint 支持，某些场景下可能降级为 REQUIRED；深入 @Transactional 失效的根本原因——Spring 的事务代理是通过 AOP 实现的，只有"从外部调用代理对象的方法"时才会经过代理，同类内部的 this 调用直接走原生对象，绕过了代理层，事务注解完全失效；最后暴露事务设计的边界——声明式事务的粒度是方法级的，如果一个事务方法里调用了 RPC 服务、发送了 MQ、操作了 Redis，这些操作都不会随数据库事务回滚，长事务还会占用数据库连接不释放，生产环境必须监控事务执行时间并设置超时。
Dec 7, 2025
SpringJava八股文
Spring IOC 容器与 Bean 生命周期
从"两个 Service 互相注入，项目启动报错 BeanCurrentlyInCreationException"这一真实困境出发，深入 Spring IOC 容器的核心原理与 Bean 生命周期的每一个环节；剖析 BeanDefinition 的角色——它不是 Bean 本身，而是 Bean 的"设计图纸"，Spring 容器先读取配置生成 BeanDefinition，再根据图纸创建 Bean；推导 Bean 生命周期的完整链路：实例化（反射调用构造器创建对象）→ 属性填充（@Autowired 依赖注入）→ Aware 接口回调（让 Bean 感知容器）→ BeanPostProcessor 前置处理 → 初始化（InitializingBean、@PostConstruct、init-method）→ BeanPostProcessor 后置处理（AOP 代理在此包装）→ 注册销毁回调（DisposableBean、@PreDestroy）；揭示循环依赖的解决机制——Spring 通过三级缓存打破循环：一级缓存存成品 Bean，二级缓存存半成品 Bean（已实例化但未填充属性），三级缓存存 ObjectFactory（用于生成早期引用），当 A 依赖 B、B 又依赖 A 时，B 在填充属性阶段从三级缓存获取 A 的早期引用，从而完成注入；深入三级缓存的暗面——为什么不是两级？因为三级缓存中的 ObjectFactory 除了能获取早期引用，还承担了 AOP 代理创建的责任，如果去掉三级缓存直接用二级缓存存早期引用，AOP 代理会提前创建导致生命周期混乱；最后暴露构造器循环依赖的边界——如果 A 和 B 都通过构造器注入互相依赖，三级缓存也无能为力，因为实例化阶段就需要依赖对象，此时连早期引用都还没产生，Spring 会直接抛出异常。
Dec 2, 2025
MySQL
MySQL分库分表与分布式事务
从"某社交平台用户表达到 10 亿行，单表查询超过 10 秒，加索引也没用"这一真实困境出发，深入分库分表与分布式事务的工程实践；剖析拆分策略的选型边界——垂直拆分按业务模块拆库（用户库、订单库、商品库），解决的是"不同业务的资源争抢"，水平拆分按数据行拆表（user_0 到 user_127），解决的是"单表数据量过大"；推导 Sharding 策略的数学本质——Hash 取模 user_id % 128 数据分布均匀但扩容时需要迁移 127/128 的数据，范围分片按 user_id 区间划分扩容简单但新注册用户总是落在最新分片造成热点，一致性 Hash 加虚拟节点后扩容只需迁移 1/N 的数据且虚拟节点让分布更均匀；揭示分库分表的暗面——分片键选错了，查询没有带分片键条件就会变成"全分片广播查询"，性能比单表还差；跨分片分页需要中心节点聚合所有分片的 Top N 再排序取页，深度分页（第 10000 页）的性能是灾难性的；外键在分库分表后无法使用，数据一致性只能靠应用层保证；深入分布式事务的方案选型——2PC 强一致但阻塞性能差，TCC 性能好但业务侵入性大需要实现三个接口，本地消息表最终一致但实现简单，Seata AT 模式对业务零侵入但底层是 SQL 解析和反向补偿，选型没有银弹，只有场景适配；最后暴露分库分表的终极边界——分库分表不是架构的终点，而是痛苦的开始，如果业务还能通过读写分离、缓存、归档历史数据等方式缓解，尽量不要走到分库分表，因为分库分表后的运维复杂度、开发成本、查询限制会指数级上升。
Nov 27, 2025