先说个不算冷的知识项目里数据库密码明文躺在配置文件中的情况我见过太多次了。代码仓库一泄露数据库等于直接裸奔就算是内网项目能接触到代码的人远比想象中多。要解决这个问题最经典的路线就是在 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 原生支持对数据源密码进行加解密不需要额外引入一套独立的加密库这一点对依赖管理很友好。对比维度比较多我直接给一张简表对比项DruidHikariCPC3P0性能良好配置合理后损耗可接受优秀社区口碑好一般项目活跃度低内置监控面板有功能很全无需配合 Micrometer 等方案无SQL 防火墙内置 wall 过滤器无无密码加密原生支持配置简单需借助外部方案无Spring Boot starter有独立 starter默认集成需手动配置1.2 集成前准备依赖、版本和自动装配认知用 Druid 的最小依赖是druid-spring-boot-starter它会把 Druid 核心包和自动装配都带进来。依赖坐标如下dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.20/version /dependency版本建议直接用 1.2.11 以上的稳定版本老版本可能存在连接泄漏修复、监控面板安全性等历史问题。如果你所在团队有统一依赖管理以内部的版本清单为准。集成时最容易出现的一个误区是项目里已经引入了spring-boot-starter-jdbcSpring 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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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 或更短让获取不到连接的线程快速失败把问题暴露在业务日志里而不是拖垮整个应用。再补充几个容易忽略但对稳定性影响很大的参数参数说明建议值test-while-idle空闲连接是否定期验证有效性true成本很低test-on-borrow获取连接时是否验证开销较大数据库稳定时建议 falsevalidation-query验证连接用的 SQLSELECT 1time-between-eviction-runs-millis空闲连接检测周期60000min-evictable-idle-time-millis空闲超过该时间则回收300000pool-prepared-statements是否缓存 PreparedStatement减少 SQL 解析开销但占用内存高读写项目可开建议同时限制缓存数量2.3 打开监控面板Druid 的隐藏大招Druid 最香的其实是监控面板默认是关闭的。开启方式很直接spring: datasource: druid: stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin login-password: admin123 reset-enable: false web-stat-filter: enabled: true url-pattern: /* exclusions: /druid/*,*.js,*.gif,*.jpg,*.png,*.css,*.icostat-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...这是加密后的密码这三样东西必须分清楚用途我这里重点提醒一下很多人就是在这里搞反了输出项用途保管方式publicKey用于加密明文密码加密工具使用可以放置在构建脚本中不算绝密privateKey运行时用于解密配置里的config.decrypt-key填的是它严禁提交到代码仓库走环境变量或密钥管理password加密后的数据库密码密文写在配置里被泄露问题不大网上有些老文章把运行时配置写成了公钥这会导致启动时直接报解密失败。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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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. 常见问题与排查技巧实录解密失败、日志泄露、监控 4044.1 启动报解密失败按顺序排查这几项这是密码加密后最高频的报错。启动日志中如果出现类似decrypt failed或dataSource init fail的异常按下面这个顺序排查基本能在几分钟内定位排查项具体检查内容config filter 是否启用filter.config.enabled必须是 true否则 Druid 不会走解密流程直接把密文当成明文密码去连库报的则是密码错误而不是解密失败password 字段是否是密文有人切配置时把明文密码填回 password 字段又开着解密开关RSA 解密明文必然失败decrypt-key 填的是否是私钥这里最容易踩坑填成公钥会在Cipher.init阶段直接报错密钥对是否匹配密文是用公钥 A 生成的运行时却用了私钥 B 去解必然失败。确认生成密文时的公钥和运行时私钥是同一次生成的密钥串是否含有换行或空格复制密钥时把换行空格带进去导致 base64 解码失败出现上述问题后不要慌先用一个简单手段验证用之前的命令行工具把密文解一次看能不能还原出明文。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 BeanDruid 连接池重建过程中如果旧连接还没释放干净新连接池初始化又失败会造成线上短暂断连。我用的比较顺手的方案是监听配置中心的EnvironmentChangeEvent在收到数据源配置变更事件时手动关闭旧 DruidDataSource再用新配置创建新的连接池。这个过程必须做优雅停机先把旧连接池的close()调用等几秒再初始化新连接池避免同一时刻两个连接池同时持有重复连接。5.2 密码轮换不重启应用的两种思路数据库密码定期轮换是很常见的合规需求。第一种思路是上面说的连接池重建通过配置中心推送新密文应用监听事件后重建数据源整个过程服务不停但会有秒级或更短的连接中断需要在业务低峰期操作。第二种思路是借助 Druid 的restart()方法它会基于现有数据源属性重新初始化但触发时机上同样要谨慎尽量避开请求高峰。这两种方案我都试过给我的感觉是业务低峰期重建连接池完全够用不要在追求“完全无感知热更新”上过度设计连接池重建期间的短暂抖动比手动改数据库密码导致连接池还拿着旧密码死撑整个服务要可控得多。5.3 我的一次完整配置实践建议如果是我现在接手一个新的 Spring Boot 服务第一版配置就会把四件事一起做掉引入 Druid starter配好连接池核心参数开启config解密打开监控面板但加上强密码和访问限制。然后把私钥放到部署环境变量把密文放到配置中心密钥对只生成一次后续换密码时只用同一把公钥重新生成密文。这样后续换数据库密码只是几分钟的事不会像很多临时方案那样等到密码已经泄露才来补救。最后分享一个我觉得挺重要的习惯每次配置完加密我都会故意在本地把config.decrypt-key写错一位确认启动确实失败再改回来重启。这个动作看似多余实际上是在验证加密链路真的在工作——否则你以为加密配置生效了实际上 Druid 可能还在用密文直连数据库或者根本没走解密逻辑。排查问题最怕的就是系统看起来很稳实际压根没按你想的路径在运行。