【重要说明 · 本章属于"历史栈"】本章讲的 EJB、重量级应用服务器（WebLogic / WebSphere / WildFly）、JTA 全局事务 等内容，在当前主流工程实践中已经基本被淘汰或边缘化：
① Java EE 已更名为 Jakarta EE（Oracle 于 2017 年捐给 Eclipse 基金会，2019 年改名），从 Jakarta EE 9 起包名从 javax.* 强制改为 jakarta.*；
② EJB 已非主流，它解决过的那些问题（声明式事务、远程调用、池化、安全管理）现在由 Spring 的 @Transactional + REST + 连接池 + Spring Security 以更轻的方式承担；
③ 重量级应用服务器已不是默认选择，绝大多数新项目用"内嵌容器 + Spring Boot 打成可执行 jar"的方式部署。
所以本章的定位不是"教你怎么用"，而是"帮你读懂和迁移遗留系统"——如果你接手了一个十几年前的老系统，或者面试被问到 EJB 与 Spring 的关系，这一章就是你要的东西。如果你是新手、准备做新项目，可以直接跳到下一章的总结，不必深究本章的 API 细节。

EJB 为什么会输

先把当年的背景讲清楚，你才能理解"为什么一个官方标准会输给一个第三方框架"。EJB（Enterprise JavaBeans）是 Java EE 的核心规范，1998 年诞生，目标是让开发者不用关心事务、安全、并发、远程调用这些"企业级复杂度"。理想很美好，但它从设计上就背了三个包袱。

看这张表你会发现一件事：EJB 的每一项能力，后来都有更轻、更自由的替代品。这不是说 EJB 当年设计得差——它是在"应用服务器是唯一部署形态"的年代做的最优解。但当部署形态变了（容器化、可执行 jar、云原生），绑定容器的设计就成了致命伤。

Java EE → Jakarta EE：包名迁移与规范现状

本页第 1 章已经讲过这段历史的来龙去脉，这里聚焦"迁移时你会遇到什么"。核心事实只有一个：从 Jakarta EE 9 开始，所有 javax.* 的 EE 包名变成了 jakarta.*，而且这是强制的、不兼容的。

包名迁移的对照：改的是 import，但牵扯的是整条依赖链

// ============ 老代码（Java EE 8 / Spring Boot 2.x，javax 时代）============
import javax.servlet.http.HttpServlet;
import javax.servlet.annotation.WebServlet;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.validation.constraints.NotNull;
import javax.inject.Inject;
import javax.transaction.Transactional;
import javax.annotation.Resource;

// ============ 新代码（Jakarta EE 9+ / Spring Boot 3.x，jakarta 时代）============
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.annotation.WebServlet;
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.validation.constraints.NotNull;
import jakarta.inject.Inject;
import jakarta.transaction.Transactional;
import jakarta.annotation.Resource;

// 规律：javax 后面接 EE 子包名（servlet / persistence / ws / validation /
//       inject / transaction / annotation / faces / mail / jms ...）的，全换成 jakarta
//
// ⚠️ 注意例外：以下 javax 包属于 Java SE，不参与改名，别一起替换了
//    javax.sql.DataSource        （JDBC 在 SE 里）
//    javax.naming.*               （JNDI 在 SE 里）
//    javax.crypto.*               （加密在 SE 里）
//    javax.net.ssl.*              （SSL 在 SE 里）
// 如果无脑全局替换 javax → jakarta，这几个会被改坏，编译直接崩

批量迁移的实操：用 OpenRewrite 自动改，而不是手工替换

<!-- pom.xml 里加 OpenRewrite 插件，跑一次自动迁移 -->
<plugin>
    <groupId>org.openrewrite.maven</groupId>
    <artifactId>rewrite-maven-plugin</artifactId>
    <version>5.38.0</version>
    <configuration>
        <activeRecipes>
            <!-- 官方提供的 Spring Boot 2 → 3 迁移配方 -->
            <recipe>org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_2</recipe>
            <!-- 它会顺带处理 javax → jakarta 的包名替换 -->
            <recipe>org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta</recipe>
        </activeRecipes>
    </configuration>
</plugin>

# 先看一眼会改哪些文件（dryRun 不落盘）
mvn rewrite:dryRun
# 确认无误后真正执行
mvn rewrite:run

# ---------- 为什么必须用工具而不是 IDE 全局替换 ----------
# 1) 它知道哪些 javax 属于 SE（javax.sql / javax.naming）不能改
# 2) 它会同步升级依赖版本（Spring Boot 2.x → 3.x 要一起动）
# 3) 它会处理配置文件里的类名（比如 MyBatis 的 typeHandler 全限定名）
# 4) 它会给出 diff，便于 review，而不是一次不可控的批量修改
# 5) 它还能处理 XML（web.xml 里的类名、Spring 的 XML 配置）

从应用服务器到内嵌容器 + Spring Boot

这是老系统迁移中体感最明显的一步：从"把 war 包丢进 WebLogic，等启动五分钟"变成"java -jar app.jar，三秒起来"。这一步的价值不只是快，而是开发、测试、部署、扩容全部变了。

迁移前后的对照：从 web.xml 到 Java Config / 注解

<!-- ============ 老做法：web.xml（应用的部署描述符）============ -->
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="3.1">

    <display-name>legacy-app</display-name>

    <!-- Servlet 与路由映射 -->
    <servlet>
        <servlet-name>userServlet</servlet-name>
        <servlet-class>com.example.web.UserServlet</servlet-class>
        <init-param>
            <param-name>pageSize</param-name>
            <param-value>20</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>userServlet</servlet-name>
        <url-pattern>/user/*</url-pattern>
    </servlet-mapping>

    <!-- 过滤器 -->
    <filter>
        <filter-name>encodingFilter</filter-name>
        <filter-class>com.example.web.EncodingFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>encodingFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

    <!-- 数据源（JNDI 查找容器配置好的资源）-->
    <resource-ref>
        <res-ref-name>jdbc/UserDS</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
    </resource-ref>

    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
</web-app>

// ============ 新做法：Spring Boot 的注解 + Java Config，零 XML ============
@SpringBootApplication          // 等价于"包扫描 + 自动配置 + Java Config 入口"
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

// Servlet 的现代替身：Controller（路由靠注解，不用 web.xml）
@RestController
@RequestMapping("/user")
public class UserController {

    // 原来的 init-param 变成了配置项 + @Value 注入
    @Value("${app.user.page-size:20}")
    private int pageSize;

    @GetMapping("/{id}")
    public UserVO get(@PathVariable Long id) { /* ... */ return null; }
}

// Filter 的现代替身：注册成 Bean 即可，不用 web.xml 里的 filter-mapping
@Component
public class EncodingFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse resp,
                                            FilterChain chain) throws ServletException, IOException {
        req.setCharacterEncoding("UTF-8");
        resp.setCharacterEncoding("UTF-8");
        chain.doFilter(req, resp);
    }
}

# application.yml：原来的 web.xml + 服务器控制台配置，现在集中在这一个文件
server:
  port: 8080
  servlet:
    session:
      timeout: 30m          # 对应 web.xml 的 session-timeout
app:
  user:
    page-size: 20             # 对应原来 Servlet 的 init-param

JNDI 数据源到 DataSource Bean，JTA 到本地事务

这两个是"容器依赖"最深的两个点，也是老系统迁移时改动最需要小心的地方。它们共同的特点是：原来由应用服务器提供能力，现在要由应用自己声明。

JNDI 查找 → DataSource Bean（连接池由应用管理）

// ============ 老做法：从容器的 JNDI 命名空间里"查"一个数据源 ============
// 数据源是应用服务器在控制台配好的，应用只负责查找
public class LegacyDao {

    private DataSource dataSource;

    public LegacyDao() throws NamingException {
        // 这段代码只有跑在应用服务器里才有意义，脱离容器直接报 NameNotFoundException
        InitialContext ctx = new InitialContext();
        this.dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/UserDS");
    }

    public String findName(Long id) throws SQLException {
        try (Connection conn = dataSource.getConnection();
             PreparedStatement ps = conn.prepareStatement("select name from users where id = ?")) {
            ps.setLong(1, id);
            try (ResultSet rs = ps.executeQuery()) {
                return rs.next() ? rs.getString("name") : null;
            }
        }
    }
}

// ============ 新做法：数据源是应用的一个 Bean，池化交给 HikariCP ============
@Configuration
public class DataSourceConfig {

    @Bean
    @ConfigurationProperties("spring.datasource.hikari")
    public DataSource dataSource() {
        // Spring Boot 会自动读取 spring.datasource.* 配置并创建 HikariDataSource
        // 这里显式声明便于自定义（比如多数据源）
        return DataSourceBuilder.create().type(HikariDataSource.class).build();
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource ds) { return new JdbcTemplate(ds); }
}

# application.yml：连接信息在这里，不再依赖容器控制台
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb?characterEncoding=utf8&useSSL=false
    username: app
    password: ${DB_PASSWORD}       # 密码从环境变量注入，别写死在配置文件里
    hikari:
      maximum-pool-size: 20       # 池大小由应用决定，要按数据库承载能力算，不是越大越好
      connection-timeout: 3000
      max-lifetime: 1800000
      pool-name: UserPool

// 移交给 Spring 管理后，业务代码用 JdbcTemplate 或 MyBatis，不再自己管 Connection
@Repository
public class UserDao {
    private final JdbcTemplate jdbc;
    public UserDao(JdbcTemplate jdbc) { this.jdbc = jdbc; }

    public String findName(Long id) {
        // 连接由框架管理，异常也由框架翻译成 DataAccessException
        return jdbc.queryForObject("select name from users where id = ?", String.class, id);
    }
}

JTA 全局事务 → 本地事务（单库）或 Seata（跨库）

// ============ 老做法：JTA 管理跨多个资源的全局事务 ============
// JTA 能同时管"数据库 A + 数据库 B + JMS 队列"，靠两阶段提交
public class LegacyService {

    @Resource
    private UserTransaction userTransaction;   // 容器提供的 JTA 事务管理器

    public void transfer(Long from, Long to, BigDecimal amount) throws Exception {
        try {
            userTransaction.begin();                // 手动开启全局事务
            accountDaoA.deduct(from, amount);     // 数据源 A（XA 连接）
            accountDaoB.add(to, amount);          // 数据源 B（XA 连接）
            mqSender.send("transfer.done");    // JMS 资源（也参与两阶段提交）
            userTransaction.commit();
        } catch (Exception e) {
            userTransaction.rollback();
            throw e;
        }
        // 这段代码的问题：强依赖容器提供 UserTransaction；XA 性能差、连接不能复用；
        // 而且脱离应用服务器后，这段代码根本跑不起来，也没法写单元测试
    }
}

// ============ 新做法之一：单库场景，用 Spring 的本地事务就够了 ============
@Service
public class AccountService {

    // 只写一个库，本地事务完全够用，简单、快、好测
    @Transactional(rollbackFor = Exception.class)
    public void transfer(Long from, Long to, BigDecimal amount) {
        accountMapper.deduct(from, amount);
        accountMapper.add(to, amount);
    }
}

// ============ 新做法之二：真的跨库/跨服务，用分布式事务框架 ============
@GlobalTransactional(timeoutMills = 30000)   // Seata，替代 JTA 的全局事务能力
public void transferAcrossServices(Long from, Long to, BigDecimal amount) {
    accountClient.deduct(from, amount);      // 服务 A（自己的库）
    accountClientInB.add(to, amount);       // 服务 B（另一个库）
    // 失败时由补偿机制回滚，不再依赖 XA 的两阶段提交
}

// ============ 新做法之三：不需要一致性保证的，直接异步化 ============
@Transactional
public void transferAndNotify(Long from, Long to, BigDecimal amount) {
    accountMapper.deduct(from, amount);
    accountMapper.add(to, amount);
    // 通知类动作放本地消息表，同一事务提交，后续异步投递（见 Spring Cloud 那册）
    localMessageMapper.insert(new LocalMessage("TRANSFER_DONE", "..."));
}

渐进式迁移：绞杀者模式

最后讲方法。老系统迁移最大的风险不是技术难度，而是"一次性大重写"的诱惑——"我们干脆重新写一遍吧，三个月就好了"。这句话是无数项目失败的起点。正确的方法是绞杀者模式（Strangler Fig Pattern）：在外面搭一层新入口，把功能一个个搬过去，老的逐步缩小，直到完全被替换。

绞杀者模式的落地：反向代理 + 按路由逐步切流

# ============ 第一步：在旧系统前面加一层代理，先全部转发给老系统 ============
# Nginx 配置：此时所有请求都进老应用，行为完全不变，零风险
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://legacy-app:8080;      # 老应用，原封不动
        proxy_set_header Host $host;
    }
}

# ============ 第二步：新写一个模块（比如用户中心），按路径切一部分流量 ============
# 只把 /api/user/ 切到新服务，其余仍然走老应用
server {
    listen 80;
    server_name app.example.com;

    # 已迁移：用户模块走新服务
    location /api/user/ {
        proxy_pass http://new-user-service:8081;
    }

    # 未迁移：其余全部继续走老应用
    location / {
        proxy_pass http://legacy-app:8080;
    }
}

# ============ 第三步（进阶）：按比例灰度，先给 5% 流量 ============
# 用 Nginx 的 split_clients 做按流量比例分流，出问题立刻调整比例
split_clients "${remote_addr}${request_uri}" $backend {
    5%      new-user-service;
    *       legacy-app;
}

server {
    listen 80;
    location /api/user/ {
        proxy_pass http://$backend;
        # 加个响应头便于对照：确认请求到底走了哪个系统
        add_header X-Served-By $backend always;
    }
}

// ============ 若无法改代理（比如直连老服务器），用 Spring Cloud Gateway 做网关层 ============
@Configuration
public class StranglerRoutes {

    @Bean
    public RouteLocator routes(RouteLocatorBuilder builder) {
        return builder.routes()
            // 已迁移的模块 → 新服务
            .route("new-user", r -> r
                .path("/api/user/**")
                .filters(f -> f.addResponseHeader("X-Served-By", "new"))
                .uri("lb://new-user-service"))
            // 兜底：所有未迁移路径继续打到老应用
            .route("legacy-fallback", r -> r
                .path("/**")
                .filters(f -> f.addResponseHeader("X-Served-By", "legacy"))
                .uri("http://legacy-app:8080"))
            .build();
    }
}

章末面试题