企业官网建设流程全解析

先说个不算冷的知识：项目里数据库密码明文躺在配置文件中的情况，我见过太多次了。代码仓库一泄露，数据库等于直接裸奔；就算是内网项目，能接触到代码的人远比想象中多。要解决这个问题，最经典的路线就是在 Spring Boot 集成 Druid 连接池时，顺便把数据库密码加密这件事一起做了。Druid 自带配置解密机制，配置不算复杂，但里面有几个很容易踩的坑，网上不少文章还把密钥填反了。这篇就把整套流程从选型、配置、加密到排查讲透，适合正在做 Spring Boot 项目加固的同学直接抄作业。

1. 为什么是 Druid？聊聊连接池选型与集成前准备

1.1 HikariCP 之外，Druid 的不可替代点

Druid 和 HikariCP 的争论在很多团队里存在。HikariCP 以极致性能著称，是 Spring Boot 2.x 的默认连接池，如果只是要一个“能跑的连接池”，选它没有任何问题。但 Druid 在国内项目里长期流行，靠的不是跑分，而是三件事：监控、SQL 防火墙、配置解密。

监控方面，Druid 自带一个 Web 控制台，能看到连接池实时状态、慢 SQL 统计、活跃连接数、事务执行时间、Web 访问的 URI 分布等。生产环境排查慢 SQL 的时候，这个面板比埋点日志直观得多。SQL 防火墙（wall filter）能拦截常见的 SQL 注入和危险操作，比如没有 WHERE 条件的 DELETE、批量导表之类的误操作。配置解密则是这次的重点，Druid 原生支持对数据源密码进行加解密，不需要额外引入一套独立的加密库，这一点对依赖管理很友好。

对比维度比较多，我直接给一张简表：

1.2 集成前准备：依赖、版本和自动装配认知

用 Druid 的最小依赖是druid-spring-boot-starter，它会把 Druid 核心包和自动装配都带进来。依赖坐标如下：

<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.20</version> </dependency>

版本建议直接用 1.2.11 以上的稳定版本，老版本可能存在连接泄漏修复、监控面板安全性等历史问题。如果你所在团队有统一依赖管理，以内部的版本清单为准。

集成时最容易出现的一个误区是：项目里已经引入了spring-boot-starter-jdbc，Spring Boot 默认会自动装配 HikariDataSource。引入 Druid starter 后，Druid 的自动装配类会通过@AutoConfigureBefore机制优先于默认数据源装配，并且在容器中没有用户自定义的DataSourceBean 时才生效。如果你在项目里手动创建了数据源 Bean，或者用了类似@EnableAutoConfiguration的排除配置，Druid 可能就不会自动生效。验证方法很简单，看启动日志里DataSource的类型是不是DruidDataSource。

注意：如果启动后日志显示使用的是 HikariDataSource，多半是自动装配被干扰了。检查一下有没有手动排除掉数据源自动配置，或者是否在某个配置类里提前定义了 DataSource Bean。最直接的兜底方案是显式声明一个DruidDataSourceBean，然后通过@ConfigurationProperties绑定配置。

2. Druid 连接池核心参数配置，每个参数到底该怎么调

2.1 最简配置：先让 Druid 跑起来

集成完成后的第一步是确认基本配置能跑通，先不要急着加密。一个最简的配置长这样：

spring: datasource: druid: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/your_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: your_user password: your_password initial-size: 5 min-idle: 5 max-active: 20 max-wait: 30000

这个配置里的四个关键项，initial-size是启动时预创建的连接数，min-idle是维持的最小空闲连接数，max-active是最大活跃连接数，max-wait是获取连接的超时时间。大多数项目把这四个参数配好，连接池就能稳定运行。

2.2 关键参数背后的原理：从 initialSize 到 maxActive 的计算逻辑

这几个参数不是随便填的，理解背后的逻辑能让你在压测和调优时不至于拍脑袋。

先说max-active。它决定连接池最多能同时拿出多少个物理连接。这个值不是越大越好：每个物理连接在数据库端都会占用线程、内存和会话资源，连接数过高会直接把数据库连接数打满；设置过小则在业务高峰时会有大量线程阻塞在“等待连接”上。一个实用的估算方式是：单次数据库操作平均耗时乘以接口峰值 QPS，再考虑慢 SQL 和多表事务的叠加效果。比如一个查询平均耗时 50ms，某个接口的峰值 QPS 是 100，那这个接口瞬时需要的连接数大约就是 5，再预留 2~3 倍余量，max-active设为 20 已经比较稳。多数据源、复杂事务场景下再适当调高。

min-idle和initial-size主要应对冷启动。服务刚起来时如果没有预创建连接，第一个请求会去真正建立数据库连接，延迟可能从几毫秒变成几百毫秒。线上典型配置是把这两个值设成一致，避免启动后反复创建销毁连接造成抖动。

max-wait这里踩过一个坑：默认值是 -1，也就是无限等待。如果连接池的连接被慢 SQL 占满，新请求会一直阻塞，先是接口超时，随后是线程池被打满，最后整个服务无响应。建议设置成 30000 或更短，让获取不到连接的线程快速失败，把问题暴露在业务日志里，而不是拖垮整个应用。

再补充几个容易忽略但对稳定性影响很大的参数：

2.3 打开监控面板：Druid 的隐藏大招

Druid 最香的其实是监控面板，默认是关闭的。开启方式很直接：

spring: datasource: druid: stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin login-password: admin@123 reset-enable: false web-stat-filter: enabled: true url-pattern: /* exclusions: /druid/*,*.js,*.gif,*.jpg,*.png,*.css,*.ico

stat-view-servlet负责暴露监控页面，web-stat-filter负责收集 Web 请求和 SQL 执行数据。启动后访问项目路径下的/druid/index.html，用配置的账号密码登录，就能看到 SQL 监控、连接池监控、URI 监控等面板。

生产环境务必把login-password设成高强度密码，reset-enable设成 false。这个面板的杀伤力很大，如果暴露在公网且没有登录保护，等于把 SQL 统计信息和数据源状态直接送给别人看。更稳妥的做法是给/druid/*加一层网关路由或内网访问限制，只允许运维网段访问。

提示：filters 参数也很关键，常见写法是filters: stat,wall,log4j2，其中stat是 SQL 监控统计数据，wall是 SQL 防火墙。但引入configfilter 时要注意，密码解密和这些 filter 的启用方式有联动关系，建议统一走filter.config.enabled方式来管理。

3. 数据库密码加密实操：ConfigTools 从生成密钥到改造配置全流程

3.1 为什么不能把明文密码写进配置文件，以及加密后的威胁模型

很多人觉得“内网项目不会有事”“这个仓库只有几个人能看”，但现实是：代码仓库的权限往往比想象中泛滥。合作方、测试人员、新入职的同事、CI 机器、甚至一段时间后的离职员工备份，都可能拿到配置。明文密码一旦暴露，影响的不仅是当前这一个数据库账号，还可能通过撞库方式波及同一套账号体系下其他环境和服务。

加密后的安全性模型要认清：Druid 的密码加密不是“完全不可逆”，而是把风险从“配置文件泄露 = 密码泄露”变成了“配置文件和私钥同时泄露 = 密码泄露”。私钥如果不随代码提交，而是通过环境变量或者部署平台的密钥注入，那项目源码就算泄露，攻击者拿到的也只是一串无法还原的密文。这已经能挡住大部分常见的源码泄露风险。

3.2 生成密钥对与密文：三步拿到加密密码

Druid 的ConfigTools类在 druid 核心包里，jar 包本身就是命令行工具。我先演示生成一个新密钥对并加密密码的方式：

java -cp druid-1.2.20.jar com.alibaba.druid.filter.config.ConfigTools "你的数据库明文密码"

运行后控制台会输出三行关键信息：

privateKey: MIIEvQIBADANBgkqhkiG9w0BAQEFAASC...（很长，是私钥） publicKey: MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...（很长，是公钥） password: M4TaX7hTqQuvMdIVLz6b0qLwqlRGgH0bQz...（这是加密后的密码）

这三样东西必须分清楚用途，我这里重点提醒一下，很多人就是在这里搞反了：

网上有些老文章把运行时配置写成了公钥，这会导致启动时直接报解密失败。Druid 的ConfigTools.decrypt方法需要私钥来解，配置里的config.decrypt-key必须是privateKey。每次运行命令都会生成新的密钥对，注意：如果你的某些环境已经在用旧密钥，不能拿当前这次生成的publicKey去配合旧的privateKey使用，它们必须配对。

如果只是想给同一个密钥对重新生成一个新密码的密文，不需要重新生成密钥对，命令变成：

java -cp druid-1.2.20.jar com.alibaba.druid.filter.config.ConfigTools "新的明文密码" "上面的公钥"

这样只会输出一个新的password，密钥保持不变，适合定期更换数据库密码的场景。

3.3 改造配置：让 Druid 在启动时自动解密

拿到三件套后，改造配置。核心是在 Druid 配置里开启config过滤器，并在connection-properties里声明解密开关和私钥：

spring: datasource: druid: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/your_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: your_user password: M4TaX7hTqQuvMdIVLz6b0qLwqlRGgH0bQz... filter: config: enabled: true connection-properties: config.decrypt: true config.decrypt-key: MIIEvQIBADANBgkqhkiG9w0BAQEFAASC...

启动时 Druid 的工作流程是这样的：DruidDataSource 在初始化物理连接时，读取连接属性中的 decrypt 开关和 decrypt-key，先从password字段取出密文，用私钥做 RSA 解密，得到明文数据库密码后再去请求数据库建立连接。由于解密发生在连接池内部，后续业务代码通过DataSource获取连接时拿到的已经是正常的物理连接，不需要改动任何业务代码。

改完配置启动，看到项目正常连接数据库，说明解密链路已经通了。我习惯再验证一步：去 Druid 监控面板的连接池页面看活跃连接数和初始连接是否已经建立，如果连接池是空的或者日志里有解密相关异常，说明配置还没有真正生效。

提示：这里有个需要注意的小坑，就是密钥串很长，复制粘贴的时候很容易在行尾或中间带入换行符和空格。YAML 里多出来的空格会导致connection-properties解析异常，排查的时候先检查这一点。

3.4 密钥保护与多环境管理的现实做法

最稳妥的私钥保管方式不是写在application.yml里，而是用环境变量注入。比如把私钥放在部署平台的密钥配置中，或者放到启动脚本的环境变量里，然后在配置文件中引用：

spring: datasource: druid: connection-properties: config.decrypt: true config.decrypt-key: ${DRUID_DECRYPT_KEY}

这样即使配置仓库被拉走，私钥也不会跟着走。多环境部署时建议每个环境（开发、测试、生产）使用独立的密钥对，不要一套密钥走天下。开发环境的数据库通常可以允许弱密码甚至明文，但生产环境的密钥和密文绝不能和开发环境混用。混合使用的后果是：开发人员手里拿着的公钥可能能解出生产环境的密文，或者不同环境互相解密失败，排查起来极其麻烦。

4. 常见问题与排查技巧实录：解密失败、日志泄露、监控 404

4.1 启动报解密失败，按顺序排查这几项

这是密码加密后最高频的报错。启动日志中如果出现类似decrypt failed或dataSource init fail的异常，按下面这个顺序排查，基本能在几分钟内定位：

出现上述问题后不要慌，先用一个简单手段验证：用之前的命令行工具把密文解一次，看能不能还原出明文。ConfigTools有一个decrypt方法，可以把密文和私钥作为参数传进去。解不出来，说明密钥对不匹配；解得出来，说明问题在应用配置本身，继续排查配置是否真的被加载到了。

4.2 明明加密了，日志里还是出现明文密码怎么办

一个经常被忽略的问题：连接池配置里密码字段是密文，但数据库连接 URL 里的密码、或者某些框架打印的异常堆栈中，可能还是会带上明文。比如一个查询抛了 SQL 异常，框架在拼接错误信息时连着数据源属性一起输出，明文字段就从日志里漏了出来。

严格来说，Druid 在打印连接信息时已经对密码做了掩码处理，日志里看到的多半是***这种形式。如果确实有明文泄露，通常是你自己的业务代码把密码写进了某个日志字段，或者连接 URL 里直接嵌了明文密码。排查做法是把日志按password、jdbc:mysql等关键词全局搜一遍，看哪些位置把数据源信息原样打出来了。另外，不要在配置里把log4j2filter 的日志级别开成 DEBUG，连接池的底层日志在 DEBUG 级别下会暴露很多内部状态，虽然通常没有明文密码，但也属于没必要的暴露面。

4.3 监控面板 404 或访问不了，大概率是这几种原因

开启监控面板后访问/druid/index.html报 404，首先看stat-view-servlet.enabled是否 true，这个开关默认 false，是最常见的原因。其次看web-stat-filter的exclusions里是否把/druid/*排除掉了，如果排除规则把/druid也过滤了，采集链会断掉。还有的项目用了网关统一鉴权，网关层面的前缀转发导致/druid/*这个路径没有透传到应用服务，这种情况在本地直连应用端口没问题，通过网关访问就 404，需要在网关层面放行对应路径。

4.4 私钥泄露了该怎么办

私钥泄露不是小事，但要冷静处理。如果只是怀疑代码仓库被拉取，而部署环境里的私钥是通过环境变量注入的，实际泄露风险已大大降低。如果确定私钥已经和密文一起泄露，那和明文字段泄露基本没区别，补救动作是：生成一套全新的密钥对，用新公钥重新加密数据库密码，更新数据库账号密码，更换部署环境变量，然后再检查依赖该数据库的所有服务的连接配置。不要在旧密钥基础上只把密码轮换一次，密钥没有作废，问题就还在。

5. 进阶玩法：配置中心联动与密码热更新思路

5.1 把密文和私钥交给配置中心管理

引入 Nacos 或 Spring Cloud Config 后，数据源配置可以全部外置到配置中心。这时密码的密文可以放在配置中心的配置项里，私钥仍然通过环境变量注入，做到“配置中心里只有密文，没有私钥”。改动后的应用配置只剩一个环境变量引用：

spring: datasource: druid: connection-properties: config.decrypt: true config.decrypt-key: ${DRUID_DECRYPT_KEY}

这样配置文件里连密文都不用看了，一切从配置中心拉取。配置变更后，普通配置可以走@RefreshScope热刷新，但数据源连接池不建议直接做成 RefreshScope Bean，Druid 连接池重建过程中如果旧连接还没释放干净，新连接池初始化又失败，会造成线上短暂断连。我用的比较顺手的方案是监听配置中心的EnvironmentChangeEvent，在收到数据源配置变更事件时，手动关闭旧 DruidDataSource，再用新配置创建新的连接池。这个过程必须做优雅停机：先把旧连接池的close()调用，等几秒，再初始化新连接池，避免同一时刻两个连接池同时持有重复连接。

5.2 密码轮换：不重启应用的两种思路

数据库密码定期轮换是很常见的合规需求。第一种思路是上面说的连接池重建，通过配置中心推送新密文，应用监听事件后重建数据源，整个过程服务不停，但会有秒级或更短的连接中断，需要在业务低峰期操作。第二种思路是借助 Druid 的restart()方法，它会基于现有数据源属性重新初始化，但触发时机上同样要谨慎，尽量避开请求高峰。

这两种方案我都试过，给我的感觉是：业务低峰期重建连接池完全够用，不要在追求“完全无感知热更新”上过度设计，连接池重建期间的短暂抖动，比手动改数据库密码导致连接池还拿着旧密码死撑整个服务要可控得多。

5.3 我的一次完整配置实践建议

如果是我现在接手一个新的 Spring Boot 服务，第一版配置就会把四件事一起做掉：引入 Druid starter，配好连接池核心参数，开启config解密，打开监控面板但加上强密码和访问限制。然后把私钥放到部署环境变量，把密文放到配置中心，密钥对只生成一次，后续换密码时只用同一把公钥重新生成密文。这样后续换数据库密码只是几分钟的事，不会像很多临时方案那样，等到密码已经泄露才来补救。

最后分享一个我觉得挺重要的习惯：每次配置完加密，我都会故意在本地把config.decrypt-key写错一位，确认启动确实失败，再改回来重启。这个动作看似多余，实际上是在验证加密链路真的在工作——否则你以为加密配置生效了，实际上 Druid 可能还在用密文直连数据库，或者根本没走解密逻辑。排查问题最怕的，就是系统看起来很稳，实际压根没按你想的路径在运行。