古法后端入门

• 全景图 ── 一件申请在服务器里经过 8 个人的手进入数据库（实测与 Wireshark）
• 徒手做做看 ── 第 3、4 讲不用框架处理 HTTP 和数据库，确认 Spring 替我们做了什么
• 业务系统的常见工作 ── 输入检查、错误的返回方式、事务、审批流程、认证、文件、日志、测试
• 每次都实测 ── 在练习服务器上运行，用日志、SQL、数据包、时间的数字来说明

题材和之前一样，是报销系统。前端篇第 10 讲从页面发出、网络篇第 10 讲一行一行读过的那件申请，这次用 Java 接收，存进数据库。

练习网络有 3 台：电脑（192.168.1.10）、申请服务器（192.168.1.20，名字是 expenses.example）、数据库服务器（192.168.1.30）。在申请服务器上，启动为本讲写的 Java 程序。

# 在申请服务器（192.168.1.20）上启动 Java 程序
app$ java -jar expenses-0.0.1-SNAPSHOT.jar
    … Tomcat initialized with port 8080 (http)
    … HikariPool-1 - Start completed.
    … Started ExpensesApplication in 3.183 seconds
# 是谁在哪里等待
app$ ss -ltnp 'sport = :8080'
    LISTEN  0.0.0.0:8080   users:(("java",pid=760,fd=18))
# 到数据库的连接（启动时已经建立）
app$ ss -tn 'dport = :5432' | wc -l
    10
# 这个程序的大小
app$ ls -l expenses-0.0.1-SNAPSHOT.jar ; grep VmRSS /proc/760/status ; ls /proc/760/task | wc -l
    24,319,744 bytes
    VmRSS:  200876 kB
    38

“服务器”并不是指特别的机器，而是打开端口、等待请求的程序。用 ss 看，java 在 0.0.0.0 的 8080 号上等待（网络篇第 11 讲的“在所有口上等待”）。而且启动时，已经向数据库服务器的 5432 号建好了 10 条连接。原因在第七章。

启动用了 3.2 秒，内存约 200 MB，线程 38 个。即使是小小的申请服务器，里面也已经有不少工作开始运转了。

从电脑发送和网络篇一样的申请。

# 从电脑发送和第 10 讲一样的申请
pc$ curl -D - -X POST -H 'Content-Type: application/json' \
       -d '{"date":"2026-10-26","item":"交通費","amount":1280}' \
       http://expenses.example:8080/api/expenses
    HTTP/1.1 201
    Location: /api/expenses/EXP-2026-0012
    Content-Type: application/json
    
    {"id":"EXP-2026-0012","status":"submitted"}     (0.281 s)
# 同样的申请再发 5 次
    201 (0.009 s)  201 (0.010 s)  201 (0.007 s)  201 (0.005 s)  201 (0.005 s)

返回了 201 Created 和受理编号，受理编号也放进了 Location（网络篇第 10 讲）。这时申请服务器里发生了什么，事先让它写进了日志（日志内容就是程序里的日语）。

# 申请服务器的日志（第 2 件。线程都是 http-nio-8080-exec-2）
    15:47:44.473 ExpenseController      窓口：申請を受け取った ExpenseRequest[…, amount=1280]
    15:47:44.473 JdbcTransactionManager Creating new transaction with name [example.expenses.ExpenseService.submit]
    15:47:44.473 JdbcTransactionManager Acquired Connection […] for JDBC transaction
    15:47:44.474 JdbcTemplate           Executing prepared SQL statement [select nextval('expense_no')]
    15:47:44.474 ExpenseService         担当者：受付番号を決めた EXP-2026-0013
    15:47:44.474 JdbcTemplate           Executing prepared SQL statement [insert into expense (…) values (?, ?, ?, ?, 'submitted')]
    15:47:44.475 ExpenseRepository      倉庫番：1行書いた EXP-2026-0013
    15:47:44.475 JdbcTransactionManager Committing JDBC transaction on Connection […]
    15:47:44.476 JdbcTransactionManager Releasing JDBC Connection […] after transaction
    15:47:44.476 ExpenseController      窓口：201 を返す EXP-2026-0013

Tomcat 接收 HTTP，Jackson 把 JSON 变成 Java 的值，Hibernate Validator 检查内容。这些都做完后，才轮到自己写的“窗口”。窗口交给“负责人”，负责人开始事务、决定受理编号，“仓库管理员”用 SQL 往表里写一行。提交后把连接还回池子，窗口返回 201。按日志的时刻，从接收到返回是 3 毫秒。

按 Wireshark 的时刻来分，从申请到达到开始和数据库说话 3.3 毫秒，和数据库来回 4 次 2.5 毫秒，写好回复发出 1.6 毫秒。

自己写的部分分成了三个角色。这是实际的代码（注释和日志是日语）。

// 窗口（Controller）：接收 HTTP，交给负责人，写回 201
@PostMapping
public ResponseEntity<Map<String, String>> submit(@Valid @RequestBody ExpenseRequest req) {
    log.info("窓口：申請を受け取った {}", req);
    String id = service.submit(req);
    log.info("窓口：201 を返す {}", id);
    return ResponseEntity.created(URI.create("/api/expenses/" + id))
            .body(Map.of("id", id, "status", "submitted"));
}

// 负责人（Service）：业务规则。从这里开始是一个事务
@Transactional
public String submit(ExpenseRequest req) {
    String id = "EXP-2026-%04d".formatted(repo.nextNumber());
    log.info("担当者：受付番号を決めた {}", id);
    repo.insert(id, req);
    return id;
}

// 仓库管理员（Repository）：写 SQL，和数据库对话
void insert(String id, ExpenseRequest r) {
    jdbc.sql("insert into expense (id, applied_on, item, amount, status) values (?, ?, ?, ?, 'submitted')")
        .params(id, r.date(), r.item(), r.amount())
        .update();
    log.info("倉庫番：1行書いた {}", id);
}

窗口（Controller）只管 HTTP，负责人（Service）只管业务规则，仓库管理员（Repository）只管 SQL。在窗口里写 SQL 也能跑，但随着审批流程和权限检查增加，一个类会变得难以收拾。按角色分开，“换数据库”只改仓库管理员，“改金额上限”只改负责人就行。

数据库不是申请服务器里的零件，而是在另一台服务器上运行的另一个程序。它和申请服务器通过 TCP 的 5432 号相连。封面照片是在申请服务器的口上记录的。电脑发来的申请（第 4 个）和回复（第 19 个）之间，夹着和数据库服务器的往来（第 6～16 个）。

往来共 4 次。最开始的“空查询”，是确认从连接池借来的连接是否还活着。接着是 BEGIN（事务开始）和取出受理编号，然后是 INSERT，最后是 COMMIT（确定）。事务在第 9 讲详细介绍。

请注意，SQL 的语句和值是分开发送的。语句里保留着 $1, $2, $3, $4 这样的空格，填进去的受理编号、日期、项目、金额，装在名为 Bind 的另一个箱子里送达。这样一来，即使项目里混进了恶意的字符串，也不会被当作 SQL 语句来读。第 4 讲会故意把语句和值混在一起，看看会怎样坏掉。

# 在数据库服务器上查看表的内容
db$ psql -d expenses -c 'select id, applied_on, item, amount, status from expense order by id limit 3'
          id       | applied_on |  item  | amount  |  status
    ---------------+------------+--------+---------+-----------
     EXP-2026-0012 | 2026-10-26 | 交通費 | 1280.00 | submitted
     EXP-2026-0013 | 2026-10-26 | 交通費 | 1280.00 | submitted
     EXP-2026-0014 | 2026-10-26 | 交通費 | 1280.00 | submitted

在数据库服务器一侧看表，申请确实一行一行地存进去了。金额是 1280.00。从页面发出的 1280，在数据库里成了带两位小数的数。在 Java 里怎样存放钱，是下一讲的重要话题。

第三章的申请，按 curl 的时钟用了 0.281 秒。可之后的 5 件只要 0.005～0.010 秒。

差距几乎都在和数据库说话之前。第 1 件从到达到第一次询问数据库用了 0.22 秒，预热后只要 0.003 秒。看日志，第 1 件在到达窗口之前用了约 0.15 秒。读 JSON 的工具和输入检查的工具在第一次时做好准备，Java 的类被读入，常走的路径被 JVM 逐渐改写成更快的机器码。

月底，为了赶财务的截止日，申请会集中到来。从电脑同时发送 50 件试试。

# 从电脑同时发送 50 件
pc$ python3 par.py
    status {201: 50}
    total 0.157 s  slowest 0.135 s  fastest 0.030 s
# 在申请服务器的日志里，数一数接收的线程名
app$ grep … app.log | (thread names) | sort -u | wc -l
    36
# Java 程序的线程数（刚启动时是 38）
app$ ls /proc/760/task | wc -l
    66

50 件在 0.157 秒内全部 201。看日志，接收的线程有 36 种。Tomcat 把到达的请求一件一件分配给线程（程序里能同时干活的工人）。而到数据库的连接，则复用启动时建好的 10 条（连接池）。这是为了不每次都从 TCP 的寒暄重新开始，正是网络篇第 6 讲的“连接复用”。

36 个工人轮流用 10 部电话，所以会出现等电话空出来的情况。线程数、连接数，以及虚拟线程（Java 21 起）的话题，在第 15 讲实测。

这个申请服务器，是在 Spring Initializr（start.spring.io）生成的模板上，加写了 5 个 Java 文件和表的定义（schema.sql），并稍微改了改配置。构建后成为一个 jar 文件。

Java 含模板中的一个共 112 行。接收 HTTP、读写 JSON、输入检查、连接池，全是库的工作。这本身是好事。只是不知道库在做什么，一旦不动了就无从下手。所以本连载在第 3、4 讲特意徒手处理 HTTP 和数据库，第 5 讲再回到 Spring Boot。

今天的申请服务器还只是“接收、存起来”。业务系统的后端还有其他常见的工作。按本连载介绍的顺序排列如下。

数据库读写有 JPA 和 MyBatis 两种有名的做法。第 8 讲会用同一件申请把两者都试一遍，比较不同。在那之前，先用自己写 SQL 的朴素做法（Spring 的 JdbcClient）推进。

为了下一讲能动手，先把工具备齐吧。

Maven 会由模板里的 mvnw（Windows 是 mvnw.cmd）自动准备，不必另外安装。