上个月朋友负责的系统凌晨两点被拖了库。查了半天数据库地址直接暴露在生产网段所有应用共用同一个账号密码还是明文躺在配置中心里。更头疼的是主从切换之后十几个应用里只有两三个感知到连接串变了其余全在报错。这个场景我太熟悉了。没有统一入口数据库就像一栋没有大门的楼谁来了都能推门进出了事也说不清是谁在哪一刻做了什么。后来我们给这类系统补的解决方案就是数据库网关层。所谓数据库网关层简单说就是在应用和数据库之间插入一层独立的代理服务。它负责统一收拢所有数据库连接在这层做安全过滤、流量调度、读写分离、审计上报和指标采集。它不替代数据库本身的能力而是把“谁可以访问库、访问了什么、效果怎么样”这件事集中管控起来。这篇内容重点讲一件事不花商业产品的钱怎么用开源组件和我自己踩坑换来的经验搭一套安全、可观测的数据库网关层。适合后端开发、DBA、运维和架构师看尤其是那些还在用“应用直连数据库”方式、但已经开始痛起来的团队。1. 网关层到底解决什么问题1.1 直连数据库的四个典型痛点先说第一个痛点连接管理混乱。没有网关层的时候每个应用自己维护一份数据库连接池。十来个服务每个服务可能有几十个实例连接数一下就冲到上千。数据库自身能承受的连接总数是有限的尤其MySQL这种每连接都要分配线程资源的数据库连接数一上去CPU先扛不住。最有意思的是等到出了故障你连“到底是谁把连接打满的”都查不出来因为每个应用都在正常使用自己的连接池单独看谁都不算异常合在一起就爆了。第二个痛点是安全问题。直连模式下应用账号散落在各个配置中心、环境变量、代码仓库里。有些团队的DBA和普通开发共用同一个高权限账号密码轮换全靠人工半年甚至一年都不换一次。我见过更极端的案例某个内部系统的代码仓库里直接躺着生产库的IP、账号、密码任何能访问代码仓库的人都能直连生产库。没有统一入口就没有统一的安全基线。第三个痛点是故障波及。某个业务的慢SQL把从库CPU打满同库的其他业务全部遭殃主库宕机切换后应用感知不到连接串已经变了还在往旧主库地址发请求。这些问题的本质都是一样的应用和数据库绑得太死中间没有一层缓冲和调度。第四个痛点也是这两年被提得越来越多的是可观测性缺失。直连模式下DBA想知道“谁在什么时间执行了什么SQL”只能去数据库开通用日志或者翻慢查询日志往往出了事故之后才去回溯。更不用提那些只跑了几毫秒但调用了上万次的SQL慢查询日志根本不会记录它们但它们才是数据库总负载的主要来源。1.2 网关层应该做什么、不做什么我自己的经验是网关层的定位要非常克制。它做四件事连接收敛。应用只连网关不直连数据库连接数从“应用数 × 实例数 × 连接池大小”收敛成“网关到数据库的固定连接数”。流量调度。根据SQL类型把读流量和写流量分开读走从库写走主库实现读写分离还能做故障自动切换后端主库不可用时自动摘除。安全过滤。统一鉴权、来源IP控制、恶意SQL拦截、敏感操作审计。指标与日志采集。把每一条SQL的耗时、来源、命中规则等信息记录下来形成指标和日志。它不做什么也很重要。网关层不做业务SQL重写除非你用的本身就是ShardingSphere这类带分库分表能力的中间件网关层也不替代SQL优化慢SQL该改还是要改只是说网关层能让你的慢SQL更快暴露。更不要把网关层当成万能代理什么都往里塞最后变成一个谁也看不懂的大杂烩。1.3 成本模型的几个关键判断“低成本”不是“零成本”而是把成本花在刀刃上。在做网关层之前先想清楚几个账。人力成本最贵。如果团队没有熟悉开源中间件的人搭建ProxySQL这类组件本身不难难的是后续故障排查和规则调优。我建议的做法是先让团队里最熟悉数据库的那个人啃透文档再拉一个后端同学一起做一个偏数据库侧一个偏应用侧配合起来效率最高。性能预算要提前评估。网关层多了一跳网络开销通常带来0.1到1毫秒的额外延迟。对于绝大多数业务系统来说这个延迟完全可接受。但如果是那种单次查询就要求微秒级的超高频场景比如广告实时竞价就需要评估是否值得加这一跳。技术栈影响选型。Java技术栈且已经有分库分表需求直接用ShardingSphere会更顺以MySQL主从架构和运维团队为主导的ProxySQL更合适如果是极简单机场景MySQL Router最轻量。什么时候不该做网关层我也说句实话。如果只是单实例数据库应用总数不超过三个总连接数不到五十那没必要。先做好连接池配置和SQL优化就够了别为了架构而架构。2. 安全能力把网关做成数据库的“门禁”2.1 账号与来源的统一收敛网关层落地的第一件事就是把散落的应用账号收回来。我在一个项目里的做法是给每个业务线分配独立的网关账号账号类型分为只读和读写两种。只读账号只能执行SELECT读写账号可以执行INSERT、UPDATE、DELETE。不允许任何业务账号拥有DDL权限表结构变更统一走DBA审批流程。应用连接网关时使用自己的账号网关再根据自己的映射关系连接后端的真实账号。这个逻辑用生活化类比来理解网关就像一个前台登记处访客应用进来先登记自己是哪个公司的、来找谁。前台根据登记信息决定放你进哪一层的门而不是把整栋楼的钥匙都给你。来源IP控制同样重要。网关层只监听内网或专线网段公网一律不开放。如果团队有堡垒机可以更进一步要求所有数据库操作都必须先跳堡垒机再经网关访问数据库这样能留下完整的人机操作记录。我在搭建时还会加一道ip白名单只有应用所在网段能连网关DBA的运维操作走独立的管理端口和业务流量完全隔离。密码轮换是另一个容易被忽略的点。直连模式下改一次密码要通知十几个团队所以大家都不愿意改。有网关之后密码只存在于网关到数据库这一层改动范围大幅缩小。我建议至少每三个月轮换一次并把轮换过程做成脚本自动修改后端数据库账号密码同时更新网关配置避免人工操作漏改。2.2 在网关层拦截恶意SQL网关层做SQL拦截和WAF做Web请求拦截是一个思路只是在数据库协议层执行。核心是把事先定义好的规则跑一遍正则匹配到危险特征就直接拒绝不让SQL到达后端数据库。以ProxySQL为例它的mysql_query_rules表就是干这个的。我梳理过一批常见的危险特征load_file()、into outfile等文件操作函数sleep()、benchmark()这类常用于时间盲注的函数各种形式的注释符组合比如“/* */”和“#”号拼接试图绕过参数校验绕过权限的信息读取比如读取mysql.user表明显异常的大批量删除比如DELETE后面不带任何WHERE条件配置示例长这样INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (30, 1, load_file\\s*\\(, blocked by security rule: load_file, 1); INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (31, 1, sleep\\s*\\(, blocked by security rule: sleep, 1); INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (32, 1, INTO\\sOUTFILE, blocked by security rule: into outfile, 1); INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (33, 1, (/\\*.*\\*/), blocked by security rule: comment bypass, 1);注意这些规则要放在查询路由规则之前执行先做安全检查再做读写分流否则恶意SQL会先被路由到后端再被拦截等于没拦。规则的匹配要尽量精确太长太宽泛的正则容易误伤正常业务。我见过有人用一条“.DELETE.”把走事务删除写法的业务直接拦掉了这种属于把门焊死人也进不来了。除了SQL特征拦截很多团队还会在网关上做更上层的人机验证能力。如果你有登录接口是直接打数据库的可以在网关前置加限流和验证逻辑对来自同一IP的短时间高频请求做限制应对暴力破解和撞库。这个和浏览器站点里的“安全验证”是一类思路只是验证的对象从普通用户变成了数据库访问请求。2.3 敏感数据脱敏与审计数据库网关层的安全能力不只在于“拦住坏人”还在于“减少坏人拿到数据后的损失”。数据脱敏和加密是两个层面的事。如果担心敏感字段暴露给低权限人员可以在网关层针对特定SQL结果做脱敏比如把手机号、身份证号的中间几位替换成星号。ProxySQL原生不提供脱敏能力但ShardingSphere有。如果你的团队是Java技术栈这是选择ShardingSphere而不是ProxySQL的一个重要理由。如果已经用了ProxySQL更实际的方案是通过数据库侧视图实现脱敏创建一个脱敏视图业务账号只授权访问视图不授权访问物理表。缺点是需要人工维护视图字段多了会有点繁琐。审计方面网关层最大的价值是让审计有一个统一落点。每一条到达网关的SQL都记录“账号、来源IP、目标库、SQL摘要、执行耗时、执行时间”。这些日志可以输出到本地文件由Filebeat或Logstash采集到ELK或Loki里也可以直接在网关上做一个简单的API推送。审计日志的留存周期建议至少半年有合规要求的系统建议一年以上。这个周期看起来长实际审计日志每天才几百MB成本可控。3. 可观测性让每一条SQL都有迹可循3.1 指标采集从黑盒到仪表盘可观测性的第一步是指标采集。网关层至少要关注以下几类指标连接类指标当前活跃连接数、空闲连接数、连接总数、连接排队数流量类指标QPS、TPS、读请求比例、写请求比例延迟类指标平均查询耗时、P99耗时、慢查询次数例如耗时超过1秒或2秒后端状态指标各后端节点的健康状态、当前连接数、最近响应时间规则命中指标被安全规则拦截的次数、被路由规则分流的次数这些指标通过暴露接口供Prometheus抓取然后在Grafana上展示成仪表盘。Prometheus和Grafana的组合是目前最主流也最低成本的可观测性方案两个组件都是开源免费社区也足够大遇到问题搜一下就能找到答案。以ProxySQL为例把proxysql_exporter部署好之后它默认从ProxySQL的6032管理端口读取stats统计数据并转化成Prometheus格式。Prometheus配置里加一个job采集目标Grafana导入社区现成的dashboard模板一套基础的可观测面板就出来了。我在实际操作中的建议是不要一上来就追求面板多而全先盯住三个指标——QPS趋势、P99耗时、后端节点健康状态。这三个指标能帮你快速回答“现在系统有没有问题”和“问题出在哪一层”至于更细的维度等用起来之后再逐步加。3.2 日志与审计慢SQL是怎么暴露出来的指标负责回答“有没有问题”日志负责回答“具体是什么问题”。网关层的日志体系至少要覆盖两类访问日志和错误日志。访问日志记录每一条SQL的关键信息。对于慢SQL尤其重要。我接手过一个业务上线半年一直稳定某天突然整体变慢。通过网关的访问日志一查发现某个业务从每天凌晨开始调用一个查询接口扫描行数越来越多。这个SQL在慢查询日志里没出现过因为单次耗时还不到1秒但它是高频调用每天要执行几十万次累计耗时非常可观。如果没有网关层的SQL访问日志这个问题不知道要藏多久。错误日志重点记录连接失败、后端节点不可用、安全规则拦截等情况。比如后端主库宕机后网关自动把流量切到只读节点但写操作仍然失败这类错误日志能帮助快速定位“为什么有些请求失败了”。日志采集侧最少投入的方案是网关把日志写到本地文件再通过Loki的promtail组件推送和采集。如果团队已经有ELK直接用Filebeat最顺手。不建议一开始就上大规模日志收集平台先保证日志能查、能搜、能保留就够。3.3 链路追踪从应用到SQL的全链路贯通指标和日志解决的是网关层自己的可观测性链路追踪解决的是更上层的问题一条请求从客户端进来经过业务应用再到数据库整个链条上每一跳的耗时分布是怎样的。这个能力在排查“数据库慢”这类问题时特别有用。有时候业务方来报障说“数据库响应变慢”结果一看全链路发现慢的根本不是SQL执行而是应用和网关之间的网络波动或者应用自己在方法执行前加了大量耗时的逻辑。低成本的链路追踪方案是SkyWalking或者OpenTelemetry。应用侧接入Agent网关侧通过采集MySQL协议或读取SQL日志把数据库调用环节串起来。需要承认的是链路追踪的接入成本比指标和日志高不少项目初期如果人力紧张可以往后放一放。我的实际建议是第一优先级先做指标第二优先级做访问日志链路追踪等前两项稳定运行之后再看业务是否需要。3.4 可观测性体系的成本控制可观测性本身也是要花钱的。存储成本是最大的开销。日志如果全部采集保留半年单日几个GB很正常。控制成本的办法有几个降采样。高频调用但结构相同的SQL可以按“去重计数最大耗时”的方式聚合而不是每条都存。分级保留。7天内的日志全量保留7天到30天只保留慢查询和安全拦截日志30天以上只保留统计摘要。告警规则要克制。不要搞几十条告警规则最终结果就是天天都被告警轰炸真正出问题时反而无人处理。我建议从最多5条核心告警开始例如“后端节点不可用”“P99耗时超过阈值”“安全拦截次数异常突增”。4. 实操用ProxySQL搭建一套可落地的网关层4.1 环境准备与部署先交代一下我用的环境两台MySQL实例一台主库一台从库已经用主从复制同步数据网关层用两台2核4G的云主机部署ProxySQL做高可用外部通过VIP或域名访问。域名方式更推荐因为后端切网关节点时不需要改应用。ProxySQL的安装比较简单最省事的方式是直接用官方提供的Docker镜像跑或者下载编译好的二进制包。以下是基于二进制包部署的核心步骤wget https://github.com/sysown/proxysql/releases/download/v2.5.5/proxysql-2.5.5-1-centos7.x86_64.rpm rpm -ivh proxysql-2.5.5-1-centos7.x86_64.rpm service proxysql start启动后通过管理端口连接ProxySQLmysql -h127.0.0.1 -P6032 -uadmin -padmin管理端口的默认账号是admin/admin生产环境务必第一时间改掉并且限制管理端口只监听本机或堡垒机网段。注册后端数据库节点INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, 192.168.1.10, 3306); INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, 192.168.1.11, 3306); LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;这里定义了两个hostgroup10是写组20是读组。ProxySQL通过hostgroup_id把后端节点分组规则匹配到哪个hostgroup就把请求发到哪个组。4.2 读写分离与路由规则注册一个业务账号。这里的账号是应用连接ProxySQL时使用的账号ProxySQL会拿着这个账号去连接后端数据库INSERT INTO mysql_users(username, password, default_hostgroup) VALUES (app_rw, StrongPassword123, 10); LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK;配置读写分离规则-- 事务中的SELECT必须走写库 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, ^SELECT.*FOR UPDATE, 10, 1); -- 普通SELECT走读库 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (2, 1, ^SELECT, 20, 1); -- 其余写操作走写库 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (3, 1, .*, 10, 1); LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;这里有一个我踩过很多次的坑规则匹配是有顺序的rule_id数字越小优先级越高。事务内的SELECT必须强制走写库因为主从之间有延迟从库可能读不到刚提交的数据。还有一种更隐蔽的情况应用开启了事务但还没执行写操作第一条总是SELECT如果不加规则判断这条SELECT会被路由到从库事务内部的读一致性就破坏了可能会读到不一致的数据。应用侧有个配合技巧事务内所有查询在SQL前加注释标记比如“/* run_on_master */ SELECT ...”网关层针对这个注释做匹配强制走写库。这种方式比匹配FOR UPDATE更通用因为有些查询不是SELECT ... FOR UPDATE但事务要求它读主库。4.3 安全规则配置安全规则放在路由规则之前确保所有请求先过安全检查。-- 拒绝无注释的批量删除这里匹配的是DELETE后面直接跟空格FROM不经过任何WHERE条件的情况 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, error_msg, apply) VALUES (20, 1, ^DELETE\\sFROM\\s(?!.*WHERE), blocked by security rule: delete without where, 1);这条规则用到了负向零宽断言匹配“DELETE FROM”后面没有WHERE的情况。注意编写时要在ProxySQL的测试环境验证正则避免误杀。还要配置SSL/TLS让应用连接到网关、网关连接到数据库这两段链路都加密-- 网关侧开启SSL支持 SET mysql-have_ssltrue; -- 配置证书路径需要提前准备好证书文件证书这个点要特别提醒自签名证书在生产环境要提前导入到应用所在服务器的信任库否则应用连接时直接报“SSL handshake failed”或者被安全客户端拦截。我在项目里就遇到过某台服务器的证书信任库没更新应用启动报错查了半天才发现是证书链不完全。来源IP控制方面通过系统防火墙限制网关的6033端口只允许应用网段访问管理端口6032只允许堡垒机访问。这个用iptables或云安全组做都行不依赖ProxySQL自身。4.4 连接池与性能参数调优ProxySQL天生自带连接池能力这也是相比直接在应用侧配连接池更优的原因之一。几个关键参数mysql-connection_max_age_ms后端连接最长存活时间建议默认即可不要让连接长期不刷新。mysql-ping_interval_server_msProxySQL检查后端节点存活的间隔。建议设为5000毫秒太短会产生多余的探测请求太长则故障感知过慢。mysql-free_connections_pct连接池里空闲连接的最小比例防止突发流量打满临时建连。默认是10手上池子大的话调到20更稳。还有一个容易被忽略的参数后端连接的超时时间。默认情况下ProxySQL等待后端响应的超时时间比较长如果数据库本身有慢SQL网关会一直等。我一般会把mysql-connect_timeout_server_ms设成1000毫秒query超时设置成业务可接受的上限值避免一条慢SQL占着连接池不放。4.5 接入Prometheus与Grafana部署proxysql_exporterdocker run -d --name proxysql-exporter -p 42002:42002 \ -e PROXYSQL_USERNAMEadmin \ -e PROXYSQL_PASSWORDadmin \ -e PROXYSQL_ADDR192.168.1.100:6032 \ ghcr.io/timbertson/proxysql_exporter:latestPrometheus配置文件里加scrape_configs: - job_name: proxysql static_configs: - targets: [192.168.1.100:42002]Grafana导入社区模板搜索“ProxySQL”关键字挑一个star数高的导入后基本就能看到连接数、QPS、后端延迟等关键面板。告警规则我建议先配置这几条后端节点不可用持续1分钟当前活跃连接数超过阈值持续5分钟P99耗时超过正常值持续5分钟安全规则拦截次数突然高于历史均值告警渠道优先接企业微信或钉钉机器人方便移动端第一时间收到。不要一开始就接电话告警等告警准确率足够高了再考虑。5. 常见问题与排查技巧实录5.1 网关自身成了性能瓶颈网关层出问题最典型的特征是数据库负载正常但应用侧查询明显变慢。此时先看网关机器的CPU、内存、网络。ProxySQL本质上是多线程的单机CPU到80%以上大概率是规则匹配太昂贵或者连接数过多。排查思路SELECT * FROM stats_mysql_connection_pool;这个表能看到每个后端连接池的状态包括连接数、繁忙连接、等待连接。如果waiting_connections持续很高说明后端数据库处理不过来而不是ProxySQL的问题。如果active_connections很高但waiting为0则说明ProxySQL转发本身正常瓶颈可能在应用侧或网络。5.2 路由规则没生效导致读压全部打在主库这是读写分离最常见的故障。现象是主库CPU高从库几乎空闲。原因通常是规则没按预期匹配比如应用发出的SELECT前面带了特殊的关键字或者大小写不一致导致正则没匹配上。排查方法在ProxySQL里开查询日志或者查询stats_mysql_query_rules这个表看看每条规则的命中次数。如果某个规则的hit次数为0说明根本没匹配上。调整规则后一定记得执行LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;很多初级选手只执行了LOAD没执行SAVE服务一重启规则就回滚了然后排查半天。5.3 SSL证书过期导致连接失败证书过期是内网系统非常“经典”的故障。现象是业务侧时不时报“connection reset”或者“SSL connection error”重启应用后短暂恢复过一段时间又复现。查下来是网关到数据库之间的SSL连接在重建时发现证书过期。解决方式建立证书到期巡检机制。最轻量的做法是写个脚本每天检查证书有效期超过阈值自动告警。不要小看这个细节证书过期导致的故障在中间件场景里非常常见。5.4 连接耗尽与连接泄漏连接耗尽的典型场景是数据库端max_connections设置为500应用的连接池设置为50二十个应用实例同时启动直接打满500其他应用连不上了。有网关之后连接被收敛到了网关这一层但要注意网关自身的连接池默认值也需要调整。排查连接释放问题时看这个指标SELECT * FROM stats_mysql_commands_counters;如果同一个账号的COM_QUERY数量持续增长但连接数也在持续增长说明应用没有正确归还连接。一般情况下是应用侧的事务管理有问题事务没提交或回滚就结束了请求连接一直没有释放。这类问题可以通过网关层设置会话级别的wait_timeout和interactive_timeout兜底让空闲连接自动断开。5.5 安全规则误杀业务SQL安全规则的误杀是上线初期最容易发生的事。比如我用了一条正则匹配“DELETE”开头的SQL来拦截无条件删除结果业务侧有“DELETE FROM table WHERE id IN (...)”这种正常SQL也被拦了。原因在于正则写成“^DELETE.”的时候只要后面没带WHERE就全拦但带WHERE的SQL也会被“.”匹配到。我的经验是安全规则上线前先把历史慢查询日志和业务SQL日志导出来用规则的匹配表达式回放一遍统计误杀率。同时把新规则先设置为“记录不拦截”ProxySQL支持把error_msg替换成log_only行为观察一天确认无异常之后才开启拦截。6. 从ProxySQL到ShardingSphere不同的选择路径6.1 两种技术方案的对比选型时我习惯画一张对比表格让团队把决策依据摆到台面上维度ProxySQLShardingSphere开发语言CJava定位数据库接入层的流量代理数据服务中间件覆盖分库分表、读写分离、数据脱敏等部署方式独立进程与应用语言无关接入应用依赖或独立Proxy部署性能原生协议支持转发性能高依赖JVM性能稍逊但功能更全安全能力规则拦截、来源IP控制、SSL面向Java生态的SQL改写、脱敏、审计更丰富适合场景以MySQL为主、异构应用、快速落地Java微服务、需要分库分表、需要数据脱敏团队是Java技术栈且短期内可能要分库分表选ShardingSphere更顺如果是多语言团队DBA主导只想快速做一个接入层选ProxySQL更稳。我见过不少团队用ProxySQL做了网关层之后又在业务层接入了ShardingSphere做分库分表两者并不冲突ProxySQL负责接入收敛ShardingSphere负责数据拆分逻辑。6.2 什么时候需要自己写一个网关开源方案不能满足的场景才考虑自研。比如需要深度定制数据库协议、需要做非常复杂的数据脱敏规则、需要对接公司内部的账号权限体系。自研网关的技术门槛不低要理解MySQL协议、处理并发连接、实现连接池、做高可用没有三到六个月时间出不来稳定版本。所以我给团队的建议永远是先用开源组件跑通沉淀出一套标准和经验再评估是否值得自研。7. 运维落地从搭建到长期运行7.1 高可用与故障切换网关层本身不能是单点。至少部署两台用Keepalived做VIP漂移或者通过云负载均衡把流量分发到两台网关节点。我有一次踩过的坑是只部署了一台ProxySQL某天机房维护网关整机被重启所有业务连接中断。如果当时有VIP漂移或者DNS切换恢复时间能从“小时级”降到“分钟级”。应用接入方式建议使用域名而不是IP。域名指向VIP或负载均衡网关节点调整的时候不需要改应用配置。域名DNS的TTL要设置短一些比如60秒否则IP切换后应用侧感知太慢。7.2 版本升级与灰度发布开源组件版本迭代快升级要谨慎。我没有直接在生产环境升级过ProxySQL大版本都是先在测试环境跑一周把日常流量、慢SQL、安全规则全量回放一遍确认没问题再升级。升级时先升级一台观察没有异常再升级另一台避免一次性全切换导致故障面过大。7.3 长期运行的成本账跑下来之后我算过一笔账两台2核4G网关节点加已有的Prometheus和Grafana再加对象存储存日志每月硬成本不到一百元。软件层面全部开源免费最大的成本是人力。前期投入大概是一个开发加一个DBA两周的集中时间后续每周只花少量时间看告警和调规则。这个投入非常划算因为换来的是一整层可控性。数据库从“裸奔”变成了“有门禁、有监控、有记录”。最后说点体会搭建数据库网关层技术难度并不高难的是理念转变。很多团队习惯了应用直连数据库觉得多一层就是多一份延迟、多一个故障点。但等你真正把网关层跑起来体会到“安全策略可以集中管控、流量可以统一调度、问题可以快速定位”之后就再也回不去了。我自己的做法是每到一个新团队第一件事就是先看数据库是不是裸奔状态如果是就先拿最低成本的方案把网关层搭起来哪怕一开始只有安全规则和基础监控也比什么都没有强。后续再根据业务需要逐步加上脱敏、审计、链路追踪。中间件永远是为业务服务的先跑起来再演进。另外一个值得关注的趋势是随着AI Agent和自动化操作越来越常见数据库访问的意愿已经不只是“应用”还有各种自动化脚本和智能体。网关层作为唯一的数据库接入入口天然承担着审计AI操作行为、限制AI访问权限的关键职责。这也是我越来越坚定推荐团队尽早建立数据库网关层的原因——它会成为整个数据安全体系里最重要的一个落点。 数据库网关层实战：基于ProxySQL的安全与可观测架构
上个月朋友负责的系统凌晨两点被拖了库。查了半天数据库地址直接暴露在生产网段所有应用共用同一个账号密码还是明文躺在配置中心里。更头疼的是主从切换之后十几个应用里只有两三个感知到连接串变了其余全在报错。这个场景我太熟悉了。没有统一入口数据库就像一栋没有大门的楼谁来了都能推门进出了事也说不清是谁在哪一刻做了什么。后来我们给这类系统补的解决方案就是数据库网关层。所谓数据库网关层简单说就是在应用和数据库之间插入一层独立的代理服务。它负责统一收拢所有数据库连接在这层做安全过滤、流量调度、读写分离、审计上报和指标采集。它不替代数据库本身的能力而是把“谁可以访问库、访问了什么、效果怎么样”这件事集中管控起来。这篇内容重点讲一件事不花商业产品的钱怎么用开源组件和我自己踩坑换来的经验搭一套安全、可观测的数据库网关层。适合后端开发、DBA、运维和架构师看尤其是那些还在用“应用直连数据库”方式、但已经开始痛起来的团队。1. 网关层到底解决什么问题1.1 直连数据库的四个典型痛点先说第一个痛点连接管理混乱。没有网关层的时候每个应用自己维护一份数据库连接池。十来个服务每个服务可能有几十个实例连接数一下就冲到上千。数据库自身能承受的连接总数是有限的尤其MySQL这种每连接都要分配线程资源的数据库连接数一上去CPU先扛不住。最有意思的是等到出了故障你连“到底是谁把连接打满的”都查不出来因为每个应用都在正常使用自己的连接池单独看谁都不算异常合在一起就爆了。第二个痛点是安全问题。直连模式下应用账号散落在各个配置中心、环境变量、代码仓库里。有些团队的DBA和普通开发共用同一个高权限账号密码轮换全靠人工半年甚至一年都不换一次。我见过更极端的案例某个内部系统的代码仓库里直接躺着生产库的IP、账号、密码任何能访问代码仓库的人都能直连生产库。没有统一入口就没有统一的安全基线。第三个痛点是故障波及。某个业务的慢SQL把从库CPU打满同库的其他业务全部遭殃主库宕机切换后应用感知不到连接串已经变了还在往旧主库地址发请求。这些问题的本质都是一样的应用和数据库绑得太死中间没有一层缓冲和调度。第四个痛点也是这两年被提得越来越多的是可观测性缺失。直连模式下DBA想知道“谁在什么时间执行了什么SQL”只能去数据库开通用日志或者翻慢查询日志往往出了事故之后才去回溯。更不用提那些只跑了几毫秒但调用了上万次的SQL慢查询日志根本不会记录它们但它们才是数据库总负载的主要来源。1.2 网关层应该做什么、不做什么我自己的经验是网关层的定位要非常克制。它做四件事连接收敛。应用只连网关不直连数据库连接数从“应用数 × 实例数 × 连接池大小”收敛成“网关到数据库的固定连接数”。流量调度。根据SQL类型把读流量和写流量分开读走从库写走主库实现读写分离还能做故障自动切换后端主库不可用时自动摘除。安全过滤。统一鉴权、来源IP控制、恶意SQL拦截、敏感操作审计。指标与日志采集。把每一条SQL的耗时、来源、命中规则等信息记录下来形成指标和日志。它不做什么也很重要。网关层不做业务SQL重写除非你用的本身就是ShardingSphere这类带分库分表能力的中间件网关层也不替代SQL优化慢SQL该改还是要改只是说网关层能让你的慢SQL更快暴露。更不要把网关层当成万能代理什么都往里塞最后变成一个谁也看不懂的大杂烩。1.3 成本模型的几个关键判断“低成本”不是“零成本”而是把成本花在刀刃上。在做网关层之前先想清楚几个账。人力成本最贵。如果团队没有熟悉开源中间件的人搭建ProxySQL这类组件本身不难难的是后续故障排查和规则调优。我建议的做法是先让团队里最熟悉数据库的那个人啃透文档再拉一个后端同学一起做一个偏数据库侧一个偏应用侧配合起来效率最高。性能预算要提前评估。网关层多了一跳网络开销通常带来0.1到1毫秒的额外延迟。对于绝大多数业务系统来说这个延迟完全可接受。但如果是那种单次查询就要求微秒级的超高频场景比如广告实时竞价就需要评估是否值得加这一跳。技术栈影响选型。Java技术栈且已经有分库分表需求直接用ShardingSphere会更顺以MySQL主从架构和运维团队为主导的ProxySQL更合适如果是极简单机场景MySQL Router最轻量。什么时候不该做网关层我也说句实话。如果只是单实例数据库应用总数不超过三个总连接数不到五十那没必要。先做好连接池配置和SQL优化就够了别为了架构而架构。2. 安全能力把网关做成数据库的“门禁”2.1 账号与来源的统一收敛网关层落地的第一件事就是把散落的应用账号收回来。我在一个项目里的做法是给每个业务线分配独立的网关账号账号类型分为只读和读写两种。只读账号只能执行SELECT读写账号可以执行INSERT、UPDATE、DELETE。不允许任何业务账号拥有DDL权限表结构变更统一走DBA审批流程。应用连接网关时使用自己的账号网关再根据自己的映射关系连接后端的真实账号。这个逻辑用生活化类比来理解网关就像一个前台登记处访客应用进来先登记自己是哪个公司的、来找谁。前台根据登记信息决定放你进哪一层的门而不是把整栋楼的钥匙都给你。来源IP控制同样重要。网关层只监听内网或专线网段公网一律不开放。如果团队有堡垒机可以更进一步要求所有数据库操作都必须先跳堡垒机再经网关访问数据库这样能留下完整的人机操作记录。我在搭建时还会加一道ip白名单只有应用所在网段能连网关DBA的运维操作走独立的管理端口和业务流量完全隔离。密码轮换是另一个容易被忽略的点。直连模式下改一次密码要通知十几个团队所以大家都不愿意改。有网关之后密码只存在于网关到数据库这一层改动范围大幅缩小。我建议至少每三个月轮换一次并把轮换过程做成脚本自动修改后端数据库账号密码同时更新网关配置避免人工操作漏改。2.2 在网关层拦截恶意SQL网关层做SQL拦截和WAF做Web请求拦截是一个思路只是在数据库协议层执行。核心是把事先定义好的规则跑一遍正则匹配到危险特征就直接拒绝不让SQL到达后端数据库。以ProxySQL为例它的mysql_query_rules表就是干这个的。我梳理过一批常见的危险特征load_file()、into outfile等文件操作函数sleep()、benchmark()这类常用于时间盲注的函数各种形式的注释符组合比如“/* */”和“#”号拼接试图绕过参数校验绕过权限的信息读取比如读取mysql.user表明显异常的大批量删除比如DELETE后面不带任何WHERE条件配置示例长这样INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (30, 1, load_file\\s*\\(, blocked by security rule: load_file, 1); INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (31, 1, sleep\\s*\\(, blocked by security rule: sleep, 1); INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (32, 1, INTO\\sOUTFILE, blocked by security rule: into outfile, 1); INSERT INTO mysql_query_rules (rule_id, active, match_pattern, error_msg, apply) VALUES (33, 1, (/\\*.*\\*/), blocked by security rule: comment bypass, 1);注意这些规则要放在查询路由规则之前执行先做安全检查再做读写分流否则恶意SQL会先被路由到后端再被拦截等于没拦。规则的匹配要尽量精确太长太宽泛的正则容易误伤正常业务。我见过有人用一条“.DELETE.”把走事务删除写法的业务直接拦掉了这种属于把门焊死人也进不来了。除了SQL特征拦截很多团队还会在网关上做更上层的人机验证能力。如果你有登录接口是直接打数据库的可以在网关前置加限流和验证逻辑对来自同一IP的短时间高频请求做限制应对暴力破解和撞库。这个和浏览器站点里的“安全验证”是一类思路只是验证的对象从普通用户变成了数据库访问请求。2.3 敏感数据脱敏与审计数据库网关层的安全能力不只在于“拦住坏人”还在于“减少坏人拿到数据后的损失”。数据脱敏和加密是两个层面的事。如果担心敏感字段暴露给低权限人员可以在网关层针对特定SQL结果做脱敏比如把手机号、身份证号的中间几位替换成星号。ProxySQL原生不提供脱敏能力但ShardingSphere有。如果你的团队是Java技术栈这是选择ShardingSphere而不是ProxySQL的一个重要理由。如果已经用了ProxySQL更实际的方案是通过数据库侧视图实现脱敏创建一个脱敏视图业务账号只授权访问视图不授权访问物理表。缺点是需要人工维护视图字段多了会有点繁琐。审计方面网关层最大的价值是让审计有一个统一落点。每一条到达网关的SQL都记录“账号、来源IP、目标库、SQL摘要、执行耗时、执行时间”。这些日志可以输出到本地文件由Filebeat或Logstash采集到ELK或Loki里也可以直接在网关上做一个简单的API推送。审计日志的留存周期建议至少半年有合规要求的系统建议一年以上。这个周期看起来长实际审计日志每天才几百MB成本可控。3. 可观测性让每一条SQL都有迹可循3.1 指标采集从黑盒到仪表盘可观测性的第一步是指标采集。网关层至少要关注以下几类指标连接类指标当前活跃连接数、空闲连接数、连接总数、连接排队数流量类指标QPS、TPS、读请求比例、写请求比例延迟类指标平均查询耗时、P99耗时、慢查询次数例如耗时超过1秒或2秒后端状态指标各后端节点的健康状态、当前连接数、最近响应时间规则命中指标被安全规则拦截的次数、被路由规则分流的次数这些指标通过暴露接口供Prometheus抓取然后在Grafana上展示成仪表盘。Prometheus和Grafana的组合是目前最主流也最低成本的可观测性方案两个组件都是开源免费社区也足够大遇到问题搜一下就能找到答案。以ProxySQL为例把proxysql_exporter部署好之后它默认从ProxySQL的6032管理端口读取stats统计数据并转化成Prometheus格式。Prometheus配置里加一个job采集目标Grafana导入社区现成的dashboard模板一套基础的可观测面板就出来了。我在实际操作中的建议是不要一上来就追求面板多而全先盯住三个指标——QPS趋势、P99耗时、后端节点健康状态。这三个指标能帮你快速回答“现在系统有没有问题”和“问题出在哪一层”至于更细的维度等用起来之后再逐步加。3.2 日志与审计慢SQL是怎么暴露出来的指标负责回答“有没有问题”日志负责回答“具体是什么问题”。网关层的日志体系至少要覆盖两类访问日志和错误日志。访问日志记录每一条SQL的关键信息。对于慢SQL尤其重要。我接手过一个业务上线半年一直稳定某天突然整体变慢。通过网关的访问日志一查发现某个业务从每天凌晨开始调用一个查询接口扫描行数越来越多。这个SQL在慢查询日志里没出现过因为单次耗时还不到1秒但它是高频调用每天要执行几十万次累计耗时非常可观。如果没有网关层的SQL访问日志这个问题不知道要藏多久。错误日志重点记录连接失败、后端节点不可用、安全规则拦截等情况。比如后端主库宕机后网关自动把流量切到只读节点但写操作仍然失败这类错误日志能帮助快速定位“为什么有些请求失败了”。日志采集侧最少投入的方案是网关把日志写到本地文件再通过Loki的promtail组件推送和采集。如果团队已经有ELK直接用Filebeat最顺手。不建议一开始就上大规模日志收集平台先保证日志能查、能搜、能保留就够。3.3 链路追踪从应用到SQL的全链路贯通指标和日志解决的是网关层自己的可观测性链路追踪解决的是更上层的问题一条请求从客户端进来经过业务应用再到数据库整个链条上每一跳的耗时分布是怎样的。这个能力在排查“数据库慢”这类问题时特别有用。有时候业务方来报障说“数据库响应变慢”结果一看全链路发现慢的根本不是SQL执行而是应用和网关之间的网络波动或者应用自己在方法执行前加了大量耗时的逻辑。低成本的链路追踪方案是SkyWalking或者OpenTelemetry。应用侧接入Agent网关侧通过采集MySQL协议或读取SQL日志把数据库调用环节串起来。需要承认的是链路追踪的接入成本比指标和日志高不少项目初期如果人力紧张可以往后放一放。我的实际建议是第一优先级先做指标第二优先级做访问日志链路追踪等前两项稳定运行之后再看业务是否需要。3.4 可观测性体系的成本控制可观测性本身也是要花钱的。存储成本是最大的开销。日志如果全部采集保留半年单日几个GB很正常。控制成本的办法有几个降采样。高频调用但结构相同的SQL可以按“去重计数最大耗时”的方式聚合而不是每条都存。分级保留。7天内的日志全量保留7天到30天只保留慢查询和安全拦截日志30天以上只保留统计摘要。告警规则要克制。不要搞几十条告警规则最终结果就是天天都被告警轰炸真正出问题时反而无人处理。我建议从最多5条核心告警开始例如“后端节点不可用”“P99耗时超过阈值”“安全拦截次数异常突增”。4. 实操用ProxySQL搭建一套可落地的网关层4.1 环境准备与部署先交代一下我用的环境两台MySQL实例一台主库一台从库已经用主从复制同步数据网关层用两台2核4G的云主机部署ProxySQL做高可用外部通过VIP或域名访问。域名方式更推荐因为后端切网关节点时不需要改应用。ProxySQL的安装比较简单最省事的方式是直接用官方提供的Docker镜像跑或者下载编译好的二进制包。以下是基于二进制包部署的核心步骤wget https://github.com/sysown/proxysql/releases/download/v2.5.5/proxysql-2.5.5-1-centos7.x86_64.rpm rpm -ivh proxysql-2.5.5-1-centos7.x86_64.rpm service proxysql start启动后通过管理端口连接ProxySQLmysql -h127.0.0.1 -P6032 -uadmin -padmin管理端口的默认账号是admin/admin生产环境务必第一时间改掉并且限制管理端口只监听本机或堡垒机网段。注册后端数据库节点INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, 192.168.1.10, 3306); INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, 192.168.1.11, 3306); LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;这里定义了两个hostgroup10是写组20是读组。ProxySQL通过hostgroup_id把后端节点分组规则匹配到哪个hostgroup就把请求发到哪个组。4.2 读写分离与路由规则注册一个业务账号。这里的账号是应用连接ProxySQL时使用的账号ProxySQL会拿着这个账号去连接后端数据库INSERT INTO mysql_users(username, password, default_hostgroup) VALUES (app_rw, StrongPassword123, 10); LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK;配置读写分离规则-- 事务中的SELECT必须走写库 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, ^SELECT.*FOR UPDATE, 10, 1); -- 普通SELECT走读库 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (2, 1, ^SELECT, 20, 1); -- 其余写操作走写库 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (3, 1, .*, 10, 1); LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;这里有一个我踩过很多次的坑规则匹配是有顺序的rule_id数字越小优先级越高。事务内的SELECT必须强制走写库因为主从之间有延迟从库可能读不到刚提交的数据。还有一种更隐蔽的情况应用开启了事务但还没执行写操作第一条总是SELECT如果不加规则判断这条SELECT会被路由到从库事务内部的读一致性就破坏了可能会读到不一致的数据。应用侧有个配合技巧事务内所有查询在SQL前加注释标记比如“/* run_on_master */ SELECT ...”网关层针对这个注释做匹配强制走写库。这种方式比匹配FOR UPDATE更通用因为有些查询不是SELECT ... FOR UPDATE但事务要求它读主库。4.3 安全规则配置安全规则放在路由规则之前确保所有请求先过安全检查。-- 拒绝无注释的批量删除这里匹配的是DELETE后面直接跟空格FROM不经过任何WHERE条件的情况 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, error_msg, apply) VALUES (20, 1, ^DELETE\\sFROM\\s(?!.*WHERE), blocked by security rule: delete without where, 1);这条规则用到了负向零宽断言匹配“DELETE FROM”后面没有WHERE的情况。注意编写时要在ProxySQL的测试环境验证正则避免误杀。还要配置SSL/TLS让应用连接到网关、网关连接到数据库这两段链路都加密-- 网关侧开启SSL支持 SET mysql-have_ssltrue; -- 配置证书路径需要提前准备好证书文件证书这个点要特别提醒自签名证书在生产环境要提前导入到应用所在服务器的信任库否则应用连接时直接报“SSL handshake failed”或者被安全客户端拦截。我在项目里就遇到过某台服务器的证书信任库没更新应用启动报错查了半天才发现是证书链不完全。来源IP控制方面通过系统防火墙限制网关的6033端口只允许应用网段访问管理端口6032只允许堡垒机访问。这个用iptables或云安全组做都行不依赖ProxySQL自身。4.4 连接池与性能参数调优ProxySQL天生自带连接池能力这也是相比直接在应用侧配连接池更优的原因之一。几个关键参数mysql-connection_max_age_ms后端连接最长存活时间建议默认即可不要让连接长期不刷新。mysql-ping_interval_server_msProxySQL检查后端节点存活的间隔。建议设为5000毫秒太短会产生多余的探测请求太长则故障感知过慢。mysql-free_connections_pct连接池里空闲连接的最小比例防止突发流量打满临时建连。默认是10手上池子大的话调到20更稳。还有一个容易被忽略的参数后端连接的超时时间。默认情况下ProxySQL等待后端响应的超时时间比较长如果数据库本身有慢SQL网关会一直等。我一般会把mysql-connect_timeout_server_ms设成1000毫秒query超时设置成业务可接受的上限值避免一条慢SQL占着连接池不放。4.5 接入Prometheus与Grafana部署proxysql_exporterdocker run -d --name proxysql-exporter -p 42002:42002 \ -e PROXYSQL_USERNAMEadmin \ -e PROXYSQL_PASSWORDadmin \ -e PROXYSQL_ADDR192.168.1.100:6032 \ ghcr.io/timbertson/proxysql_exporter:latestPrometheus配置文件里加scrape_configs: - job_name: proxysql static_configs: - targets: [192.168.1.100:42002]Grafana导入社区模板搜索“ProxySQL”关键字挑一个star数高的导入后基本就能看到连接数、QPS、后端延迟等关键面板。告警规则我建议先配置这几条后端节点不可用持续1分钟当前活跃连接数超过阈值持续5分钟P99耗时超过正常值持续5分钟安全规则拦截次数突然高于历史均值告警渠道优先接企业微信或钉钉机器人方便移动端第一时间收到。不要一开始就接电话告警等告警准确率足够高了再考虑。5. 常见问题与排查技巧实录5.1 网关自身成了性能瓶颈网关层出问题最典型的特征是数据库负载正常但应用侧查询明显变慢。此时先看网关机器的CPU、内存、网络。ProxySQL本质上是多线程的单机CPU到80%以上大概率是规则匹配太昂贵或者连接数过多。排查思路SELECT * FROM stats_mysql_connection_pool;这个表能看到每个后端连接池的状态包括连接数、繁忙连接、等待连接。如果waiting_connections持续很高说明后端数据库处理不过来而不是ProxySQL的问题。如果active_connections很高但waiting为0则说明ProxySQL转发本身正常瓶颈可能在应用侧或网络。5.2 路由规则没生效导致读压全部打在主库这是读写分离最常见的故障。现象是主库CPU高从库几乎空闲。原因通常是规则没按预期匹配比如应用发出的SELECT前面带了特殊的关键字或者大小写不一致导致正则没匹配上。排查方法在ProxySQL里开查询日志或者查询stats_mysql_query_rules这个表看看每条规则的命中次数。如果某个规则的hit次数为0说明根本没匹配上。调整规则后一定记得执行LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;很多初级选手只执行了LOAD没执行SAVE服务一重启规则就回滚了然后排查半天。5.3 SSL证书过期导致连接失败证书过期是内网系统非常“经典”的故障。现象是业务侧时不时报“connection reset”或者“SSL connection error”重启应用后短暂恢复过一段时间又复现。查下来是网关到数据库之间的SSL连接在重建时发现证书过期。解决方式建立证书到期巡检机制。最轻量的做法是写个脚本每天检查证书有效期超过阈值自动告警。不要小看这个细节证书过期导致的故障在中间件场景里非常常见。5.4 连接耗尽与连接泄漏连接耗尽的典型场景是数据库端max_connections设置为500应用的连接池设置为50二十个应用实例同时启动直接打满500其他应用连不上了。有网关之后连接被收敛到了网关这一层但要注意网关自身的连接池默认值也需要调整。排查连接释放问题时看这个指标SELECT * FROM stats_mysql_commands_counters;如果同一个账号的COM_QUERY数量持续增长但连接数也在持续增长说明应用没有正确归还连接。一般情况下是应用侧的事务管理有问题事务没提交或回滚就结束了请求连接一直没有释放。这类问题可以通过网关层设置会话级别的wait_timeout和interactive_timeout兜底让空闲连接自动断开。5.5 安全规则误杀业务SQL安全规则的误杀是上线初期最容易发生的事。比如我用了一条正则匹配“DELETE”开头的SQL来拦截无条件删除结果业务侧有“DELETE FROM table WHERE id IN (...)”这种正常SQL也被拦了。原因在于正则写成“^DELETE.”的时候只要后面没带WHERE就全拦但带WHERE的SQL也会被“.”匹配到。我的经验是安全规则上线前先把历史慢查询日志和业务SQL日志导出来用规则的匹配表达式回放一遍统计误杀率。同时把新规则先设置为“记录不拦截”ProxySQL支持把error_msg替换成log_only行为观察一天确认无异常之后才开启拦截。6. 从ProxySQL到ShardingSphere不同的选择路径6.1 两种技术方案的对比选型时我习惯画一张对比表格让团队把决策依据摆到台面上维度ProxySQLShardingSphere开发语言CJava定位数据库接入层的流量代理数据服务中间件覆盖分库分表、读写分离、数据脱敏等部署方式独立进程与应用语言无关接入应用依赖或独立Proxy部署性能原生协议支持转发性能高依赖JVM性能稍逊但功能更全安全能力规则拦截、来源IP控制、SSL面向Java生态的SQL改写、脱敏、审计更丰富适合场景以MySQL为主、异构应用、快速落地Java微服务、需要分库分表、需要数据脱敏团队是Java技术栈且短期内可能要分库分表选ShardingSphere更顺如果是多语言团队DBA主导只想快速做一个接入层选ProxySQL更稳。我见过不少团队用ProxySQL做了网关层之后又在业务层接入了ShardingSphere做分库分表两者并不冲突ProxySQL负责接入收敛ShardingSphere负责数据拆分逻辑。6.2 什么时候需要自己写一个网关开源方案不能满足的场景才考虑自研。比如需要深度定制数据库协议、需要做非常复杂的数据脱敏规则、需要对接公司内部的账号权限体系。自研网关的技术门槛不低要理解MySQL协议、处理并发连接、实现连接池、做高可用没有三到六个月时间出不来稳定版本。所以我给团队的建议永远是先用开源组件跑通沉淀出一套标准和经验再评估是否值得自研。7. 运维落地从搭建到长期运行7.1 高可用与故障切换网关层本身不能是单点。至少部署两台用Keepalived做VIP漂移或者通过云负载均衡把流量分发到两台网关节点。我有一次踩过的坑是只部署了一台ProxySQL某天机房维护网关整机被重启所有业务连接中断。如果当时有VIP漂移或者DNS切换恢复时间能从“小时级”降到“分钟级”。应用接入方式建议使用域名而不是IP。域名指向VIP或负载均衡网关节点调整的时候不需要改应用配置。域名DNS的TTL要设置短一些比如60秒否则IP切换后应用侧感知太慢。7.2 版本升级与灰度发布开源组件版本迭代快升级要谨慎。我没有直接在生产环境升级过ProxySQL大版本都是先在测试环境跑一周把日常流量、慢SQL、安全规则全量回放一遍确认没问题再升级。升级时先升级一台观察没有异常再升级另一台避免一次性全切换导致故障面过大。7.3 长期运行的成本账跑下来之后我算过一笔账两台2核4G网关节点加已有的Prometheus和Grafana再加对象存储存日志每月硬成本不到一百元。软件层面全部开源免费最大的成本是人力。前期投入大概是一个开发加一个DBA两周的集中时间后续每周只花少量时间看告警和调规则。这个投入非常划算因为换来的是一整层可控性。数据库从“裸奔”变成了“有门禁、有监控、有记录”。最后说点体会搭建数据库网关层技术难度并不高难的是理念转变。很多团队习惯了应用直连数据库觉得多一层就是多一份延迟、多一个故障点。但等你真正把网关层跑起来体会到“安全策略可以集中管控、流量可以统一调度、问题可以快速定位”之后就再也回不去了。我自己的做法是每到一个新团队第一件事就是先看数据库是不是裸奔状态如果是就先拿最低成本的方案把网关层搭起来哪怕一开始只有安全规则和基础监控也比什么都没有强。后续再根据业务需要逐步加上脱敏、审计、链路追踪。中间件永远是为业务服务的先跑起来再演进。另外一个值得关注的趋势是随着AI Agent和自动化操作越来越常见数据库访问的意愿已经不只是“应用”还有各种自动化脚本和智能体。网关层作为唯一的数据库接入入口天然承担着审计AI操作行为、限制AI访问权限的关键职责。这也是我越来越坚定推荐团队尽早建立数据库网关层的原因——它会成为整个数据安全体系里最重要的一个落点。