系統設計 | Java 應用中的配置含義和避坑
這篇文章整理了 Spring Boot 和常見的應用中間件配置含義，了解這些配置的目的和原理，避免因為錯誤配置導致生產出現問題，特別是有一些安全問題。
PS：寫下來發現東西非常多，很多時候我們都只是拷貝過來改改沒問題就不管了，但是這樣囫圇吞棗，會給項目帶來風險。
1. Spring Boot 相關
優雅停機
優雅停機是指當應用接收到停機信號時，能夠妥善地處理正在進行的請求，釋放資源，并在完成這些工作后再停止應用。
如果不開啟優雅停機，有可能在部署的過程中讓少量未完成的任務和請求直接終止，帶來意想不到的問題。
默認情況下，Spring Boot 沒有啟用優雅停機，而且往往需要和云環境配合使用。
在 Spring Boot 中的配置方式為（本文以 yaml 的格式）：
server:
shutdown: graceful同時可以設置一個優雅停機的超時時間，如果在超時時間內請求沒有完成，應用將強制停機。
spring:
lifecycle:
timeout-per-shutdown-phase: 30sKubernetes 在停止 Pod 時，會先發送一個 SIGTERM，并通過 Readiness Probe和Liveness Probe 兩個探針來決定是否釋放容器資源。
探針就是應用通過一個 API（可以是 HTTP 或者 TCP，通常都是 HTTP）告訴 Kubernetes 它當前的狀態，讓 Kubernetes 來決策何時重啟，關于優雅停機的內容比較多，后面單獨一篇文章討論。
在 Spring Boot 中，探針就是 Spring Boot 的 health 接口，可以通過 Indicator 配置。
Indicator
Spring Boot 提供了一些健康狀態的 API，這樣就可以給云平臺優雅停機使用，也可以提供給監控系統用來撥測，如果系統長時間不健康，可以進行告警。
在代碼中實現健康狀態的類叫做 Indicator，基本上默認配置的 Indicator 就夠用了，但有時候需要根據自己需要配置一些 Indicator。
比如依賴了一個重要的三方系統，這個三方系統不啟動起來，當前系統啟動了也沒意義，于是就可以加一個 Indicator，甚至把三方系統的狀態暴露到當前系統的健康狀態信息中。
暴露相關健康 API 需要引入一個 actuator 依賴：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>下面是一個例子：
import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;
@Component
public class CustomHealthIndicator implements HealthIndicator {
@Override
public Health health() {
boolean isHealthy = checkSomeServiceHealth();
if (isHealthy) {
return Health.up().withDetail("customService", "UP").build();
} else {
return Health.down().withDetail("customService", "DOWN").build();
}
}
private boolean checkSomeServiceHealth() {
// 檢查邏輯
return true;
}
}訪問 /actuator/health 接口，返回結果大概像下面這樣：
{
"status": "UP",
"components": {
"db": {
"status": "UP",
"details": {
"database": "MySQL",
"validationQuery": "isValid()"
}
},
"customService": {
"status": "UP",
"details": {
"CustomService": "UP"
}
},
……
}
}打開相關配置：
management:
endpoints:
web:
exposure:
include: health,info在這個配置中，info 類似 health， 提供了一些服務信息，例如名稱、版本之類的，但是要注意避免把敏感信息從這個接口中暴露出去了。
Actuator
提到了 Actuator，這里有一些配置是不能在生產環境開啟的，這是比較常見的錯誤，需要注意。
Actuator 除了提供了 health,info 兩個接口，還提供了一堆接口，方便觀察 Spring Boot 應用，這些接口都可以在開發環境開啟。例如：
- /health: 顯示應用的健康狀態及詳細信息。
- /info: 顯示應用的一些基本信息（例如版本、描述等）。
- /env: 查看和調試環境屬性，了解配置項的來源。
- /beans: 用于調試 Bean 的創建和依賴關系。
- /metrics: 查看應用的性能指標，如內存使用情況、GC 活動等。
- /httptrace: 用于查看最近 HTTP 請求的詳細信息。
- /mappings: 用于查看所有請求映射的路徑，方便調試路由問題。
這些接口開啟后會造成安全、性能問題。
所以推薦的配置如下。
開發環境：
management:
endpoints:
web:
exposure:
include: "*"
endpoint:
health:
show-details: always # 顯示詳細健康信息，方便調試endpoints 只是暴露外部是否可以訪問，實際的功能需要單獨開啟，health,info,metrics 三個接口是默認開啟的。
如果需要打開 beans，可以單獨開啟：
management:
logfile:
enabled: true # 允許查看日志文件，方便調試
env:
enabled: true # 允許查看環境變量配置
configprops:
enabled: true # 允許查看配置屬性，幫助調試
beans:
enabled: true # 允許查看 Bean 信息，調試依賴關系
heapdump:
enabled: true # 啟用 Heap Dump，用于內存分析
threaddump:
enabled: true # 啟用線程轉儲，用于線程分析
mappings:
enabled: true # 允許查看所有請求映射，調試路由問題
httptrace:
enabled: true # 啟用 HTTP 請求追蹤而生產環境，需要將其關閉，只保留需要開啟的配置：
management:
endpoints:
web:
exposure:
include: "health,info,metrics"
endpoint:
health:
show-details: never # 隱藏健康檢查的詳細信息，防止敏感數據泄露日志
日志配置錯誤會導致磁盤被日志寫滿，另外日志級別過低，性能會急劇下降。
在以前還不是容器時代，我們常常使用日志文件存儲日志，再使用一些工具轉存走，有時候清理日志的腳本失效，導致磁盤被日志寫爆的場景非常多。
下面是一個在容器環境下 Spring Boot 默認日志庫的配置：
logging:
level:
root: INFO
org.springframework: WARN #這里放上特定包的日志配置
pattern:
console: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"
file:
enabled: false # 生產環境通常不直接寫入文件，而是由 K8s 日志收集系統處理
stdout:
enabled: true在生產上我們一般將日志級別設置為 INFO，并關閉文件輸出，而是將日志輸出到 stdout 中，由容器捕獲。
在開發環境，我們通常把日志設置為 DEBUG，更加方便調試。
秘鑰和口令
正常情況下，大多數應用都不會把口令存放到配置文件中，敏感信息需要放到秘鑰管理系統中(Key Management System)。
例如，在 k8s 中，我們可以使用 Secrets 代替明文的 ConfigMap；云平臺往往提供了相關的 KMS 產品，例如 Alicloud KMS。
2.Mysql
這里給出一個 Mysql 和 Mybatis 的典型配置，并解釋一下關鍵配置的含義和避坑經驗。
spring:
datasource:
url: jdbc:mysql://localhost:3306/mydatabase?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=UTC&autoReconnect=true&rewriteBatchedStatements=true
username: your_username
password: your_password
driver-class-name: com.mysql.cj.jdbc.Driver
hikari:
maximum-pool-size: 10
minimum-idle: 5
idle-timeout: 30000
max-lifetime: 1800000
connection-timeout: 30000
mybatis:
mapper-locations: classpath*:mapper/*.xml
type-aliases-package: com.example.project.domain
configuration:
map-underscore-to-camel-case: true
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl連接字符串中的配置：
- useUnicode：啟用了 Unicode 支持。
- characterEncoding：字符編碼，最好在 useUnicode 配置后，characterEncoding 也明確配置一下，否則它會選擇一個默認的 Unicode 字符編碼。另外，我們現在用的更多的是 utf8mb4，它是 UTF8 的拓展字符集，可以處理更多特性，例如表情，最多占用 4 個字節的空間。
- useSSL：如果啟用，需要證書，一般我們都沒有配置。
- serverTimezone：關于時區，我們一般都不讓數據庫決策，而讓應用決定寫入數據的時區，這個問題我在以前的文章，《系統設計中需要考慮到的時間問題》，做過詳細說明。
- autoReconnect：自動重連，如果不開啟的話，數據庫重啟了應用也必須重啟。
- rewriteBatchedStatements：自動優化批量插入時的性能。
關于 driver-class-name，對于 MySQL Connector/J 8.0 以上，類名換成了 com.mysql.cj.jdbc.Driver，舊版本是 com.mysql.jdbc.Driver。
關于 hikari 配置的含義：
- maximum-pool-size: 最大連接數，連接池中的最大連接數。
- minimum-idle: 最小空閑連接數。
- idle-timeout: 空閑連接被回收前的最大等待時間（毫秒）。
- max-lifetime: 連接在池中的最長存活時間（毫秒）。
- connection-timeout: 獲取連接的超時時間（毫秒）。
hikari 的配置只是建議值，hikari 配置邏輯是什么呢？一般是基于性能測試反復調整，但還是有一些規律。
這里有個坑，有時候為了優化性能，提高了最大連接數。但一般數據庫的連接數是有限制的，比如 1000。假設一個系統共同一個Mysql實例，系統共有 10 個服務，每個服務如果有 10 個容器，最大連接數最多就只能配置到 10 了，否則就會報沒有鏈接的錯誤（而且是偶爾出現這類問題）。
maximumPoolSize 通常設置為數據庫的并發連接限制的 50% 到 80% 之間，單個容器允許 10 個 Mysql 連接并不大，maximum-pool-size 可以在 10 - 50 之間調整。
connection-timeout 過短，在數據庫負載高或網絡不穩定的情況下，可能導致頻繁的連接超時，可以嘗試往長一點調整。
max-lifetime、minimum-idle 取決于負載情況，如果持續負載比較高，可以設置長一些，不用為數據庫節省資源，讓連接長時間保持。
關于 Mybatis 的 map-underscore-to-camel-case 配置有一個坑，這個配置的含義是把數據庫列名中的下劃線自動映射為 Java 對象中的駝峰命名。例如，user_name 列將映射為 userName 屬性。但有的時候，命名不規范，有些詞可能是一個詞組而沒有大寫，會導致匹配失敗。
