1. 从Spring MVC到云原生的技术演进脉络

第一次接触Spring MVC还是在2013年，当时为了应付校招连夜啃完了《Spring实战》。十年过去，这套经典的MVC框架已经演变成了庞大的技术生态。今天我们就来聊聊Java技术栈的这场进化之旅，以及大厂面试中常考的那些技术要点。

Spring MVC本质上是一种基于Servlet API的Web框架，采用前端控制器模式（Front Controller），通过DispatcherServlet统一处理请求。它的核心优势在于松耦合的组件设计——HandlerMapping负责路由、Controller处理业务、ViewResolver渲染视图，这种分工明确的架构让开发者可以灵活替换各个环节的实现。

但随着业务复杂度提升，单体架构的Spring MVC应用逐渐暴露出问题。记得2016年参与的一个电商项目，打包后的war包达到800MB，启动需要5分钟，任何代码修改都要全量部署。这正是微服务架构开始流行的时代背景。

2. Spring MVC核心机制与面试考点

2.1 请求处理流程的八股文陷阱

几乎所有面试官都会问："描述下Spring MVC的工作流程？" 但死记硬背"八股文"很容易露馅。建议结合源码理解这个处理链条：

1. DispatcherServlet收到HTTP请求后，会先调用HandlerMapping（默认是BeanNameUrlHandlerMapping和RequestMappingHandlerMapping）
2. 找到对应的HandlerAdapter（常见的有HttpRequestHandlerAdapter、SimpleControllerHandlerAdapter等）
3. 执行拦截器preHandle方法
4. 反射调用Controller方法，期间会进行参数绑定（重点考察@RequestParam、@PathVariable的区别）
5. 处理返回值（ViewNameMethodReturnValueHandler处理字符串返回，@ResponseBody由RequestResponseBodyMethodProcessor处理）
6. 执行postHandle拦截器
7. 视图渲染（除非使用@ResponseBody跳过了这步）
8. afterCompletion收尾

实际面试中，如果能说出AbstractHandlerMethodAdapter的handleInternal方法实现细节，或者解释RequestMappingHandlerMapping如何维护url到method的映射，绝对能让面试官眼前一亮。

2.2 那些年我们踩过的参数绑定坑

参数绑定是另一个高频考点。去年帮团队面试时，我特别喜欢问："前端传了个JSON对象，后端用Map接收为什么取不到值？" 这其实涉及到几个关键点：

• 默认的FormHttpMessageConverter只能处理application/x-www-form-urlencoded
• 需要添加Jackson的MappingJackson2HttpMessageConverter才能解析JSON
• 使用@RequestBody注解时，参数不能是接口类型（如Map要换成LinkedHashMap）

其他容易翻车的场景：

// 时间格式化问题
@GetMapping("/date")
public String handleDate(@RequestParam LocalDateTime time) {
    // 需要配置DateTimeFormatterRegistrar
}

// 数组参数传递
@GetMapping("/array")
public String handleArray(@RequestParam List<String> ids) {
    // 前端需传ids=1,2,3或ids=1&ids=2
}

3. 微服务转型的关键技术跃迁

3.1 服务拆分的艺术与陷阱

从单体转向微服务时，最常见的误区就是"为拆而拆"。去年评审的一个项目，团队把用户服务拆成了7个子服务，结果联调时发现循环依赖严重。合理的拆分原则应该是：

1. 按业务能力划分（支付、库存、物流等）
2. 按数据聚合根划分（用户主数据、用户行为数据等）
3. 考虑团队结构（两个团队维护的服务尽量不要有调用关系）

Spring Cloud提供的解决方案值得深入理解：

• 服务注册与发现：Eureka vs Nacos vs Zookeeper对比
• 客户端负载均衡：Ribbon的7种规则实现原理
• 声明式调用：Feign如何生成动态代理
• 熔断降级：Hystrix线程池隔离与信号量隔离的区别

3.2 分布式事务的实战方案

订单创建扣减库存这个经典场景，面试时经常被要求设计解决方案。我们的生产环境最终采用了Seata的AT模式，关键配置如下：

# seata配置
seata.tx-service-group=my_test_tx_group
seata.service.vgroup-mapping.my_test_tx_group=default
seata.enable-auto-data-source-proxy=true

但要注意几个坑：

1. AT模式依赖undo_log表，需要每个业务库都创建
2. 全局锁默认有效期30秒，长事务需要调整
3. 高并发场景下建议改用TCC模式

4. 云原生下的Java技术栈重塑

4.1 容器化带来的变革

当应用要上K8s时，传统的Java开发方式需要做出调整：

1. 镜像构建优化：使用分层构建，把变动少的依赖放在下层

FROM openjdk:11-jre-slim
COPY target/lib /app/lib  # 依赖层
COPY target/*.jar /app/app.jar  # 应用层

2. JVM参数调整：容器内存限制需要配合-XX:MaxRAMPercentage
3. 健康检查配置：/actuator/health要区分就绪和存活探针

4.2 Service Mesh的渐进式落地

在Istio环境中，Java应用需要注意：

1. 关闭Spring Cloud自带的负载均衡：

spring.cloud.loadbalancer.ribbon.enabled=false

2. 调整重试策略避免雪崩：

trafficPolicy:
  outlierDetection:
    consecutiveErrors: 5
    interval: 10s
    baseEjectionTime: 30s

3. 分布式追踪集成：建议使用OpenTelemetry替代Spring Cloud Sleuth

5. 面试实战中的高频问题剖析

5.1 源码解析类问题

"Spring如何解决循环依赖？" 这个问题考察的是对三级缓存的理解：

1. singletonObjects：存放完整Bean
2. earlySingletonObjects：存放早期引用
3. singletonFactories：存放ObjectFactory

关键代码在DefaultSingletonBeanRegistry的getSingleton方法：

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    Object singletonObject = this.singletonObjects.get(beanName);
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
        synchronized (this.singletonObjects) {
            singletonObject = this.earlySingletonObjects.get(beanName);
            if (singletonObject == null && allowEarlyReference) {
                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
                    singletonObject = singletonFactory.getObject();
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return singletonObject;
}

5.2 场景设计类问题

"如何设计一个秒杀系统？" 这类问题需要分层回答：

1. 接入层：

   • 静态资源CDN化
   • 限流（Nginx漏桶算法）
   • 恶意请求过滤（布隆过滤器）

2. 应用层：

   • 缓存预热（Redis+Lua脚本）
   • 异步化处理（RocketMQ削峰）
   • 分布式锁（Redisson看门狗机制）

3. 数据层：

   • 分库分表（用户ID哈希）
   • 最终一致性（本地消息表）
   • 热点数据优化（库存分段）

6. 技术演进中的避坑指南

6.1 微服务调试技巧

在分布式环境下，推荐使用这些工具组合：

1. Arthas实时诊断：watch com.example.service.UserService getUser '{params,returnObj}'
2. SkyWalking拓扑分析：定位慢调用链
3. JFR（JDK Flight Recorder）：低开销的性能分析

6.2 云原生适配经验

1. 健康检查要区分核心接口和非核心接口：

@ReadinessProbe
@GetMapping("/ready")
public ResponseEntity<Void> readiness() {
    return dbCheck() ? OK : SERVICE_UNAVAILABLE;
}

2. 配置管理改用ConfigMap：

spring:
  cloud:
    kubernetes:
      config:
        sources:
          - name: app-config
            namespace: dev

3. 日志收集方案：EFK栈中Filebeat的配置要点：

filebeat.inputs:
- type: container
  paths: 
    - /var/log/containers/*.log
  processors:
    - add_kubernetes_metadata:
        host: ${NODE_NAME}
        matchers:
        - logs_path:
            logs_path: "/var/log/containers/"

从Spring MVC到云原生，Java技术栈的演进就像打怪升级。十年前我们关心的是怎么把页面渲染出来，现在要思考的是如何让全球部署的微服务稳定运行。每次技术变革都会淘汰一批人，也会成就一批人——关键是要保持对底层原理的好奇心，在追逐新技术的同时，不忘夯实基础。