企业官网建设流程全解析

1. 项目整体设计与适用场景解析

1.1 这个项目到底解决什么问题

做后端开发的人应该都有这种感觉：业务量一上来，数据库最先扛不住。单库单表跑到一定量级，写入并发和查询延迟都会明显恶化，这时候大部分人第一反应是上缓存、做读写分离，再不行就分库分表。但真到了分库分表的阶段，麻烦事就接踵而至——你希望应用层像访问一个数据库一样访问多个数据库实例，而不希望在 DAO 层写一堆路由逻辑。

Atlas 就是为这个场景而生的。它本质上是一个基于 MySQL 协议的数据访问中间件，部署在应用服务器和 MySQL 实例之间，对外伪装成一个 MySQL 服务器，应用端不用改任何代码，只要把数据库连接地址改成 Atlas 的地址，就能获得读写分离、分库分表、连接池管理、SQL 过滤等能力。

我在实际项目里第一次接触 Atlas，是因为当时接手了一个线上商城系统，订单表已经到了千万级，单库单表写入经常把主库拖垮。团队讨论过 Sharding-JDBC、MyCat 这些方案，但当时 Java 那套还比较重，MyCat 引入成本也不小，反而是 Atlas 这种中间层代理方式最适合我们当时的架构——应用端改动最小，运维也最省心。

1.2 适合谁用、不适合谁用

Atlas 适合以下场景：

• 需要快速实现读写分离：主库扛写入、从库扛查询，应用层零改动。
• 分库分表需求明确：比如订单按用户 ID 分 4 个库、每库再按月份分表，路由规则可以配置在 Atlas 层。
• 不想侵入应用代码：团队没有精力在 Java/PHP/Go 各个语言里分别实现数据库路由逻辑，只想在中间层统一处理。
• 运维能力一般的中小型团队：Atlas 配置相对简单，部署模式清晰，不需要像某些分布式数据库那样搞一堆协调节点。

不适合的场景：

• 追求极致性能的场景，比如每秒几十万 QPS 的纯查询，Atlas 的多一层转发确实会带来微秒级到毫秒级的额外延迟。
• 需要复杂分布式事务支持的场景，Atlas 本身不擅长跨库事务，最多做数据库层面的单库事务。
• 团队如果已经有完善的 Sharding-JDBC 体系，没必要为了用 Atlas 而用 Atlas。

我在技术选型时的一个重要心得是：不要因为某个中间件功能强大就选它，而要看你的团队能承担多少维护成本。Atlas 的优势恰恰在于轻量、部署简单、配置直观，适合大多数 MySQL 垂直分层的需求。

2. 核心原理拆解：读 wrote 分离、分库分表与连接管理

2.1 读写分离本质是基于 MySQL 主从复制

Atlas 的读写分离能力，底层依赖的是 MySQL 自带的主从复制机制。理解了这条链路，你才能理解 Atlas 到底在“代理”什么。

架构通常是这样的：

• 主库（Master）处理写入操作：INSERT、UPDATE、DELETE、DDL。
• 一个或多个从库（Slave）同步主库的 binlog，处理查询操作：SELECT、SHOW 等。
• Atlas 位于应用和 MySQL 之间，解析应用发来的 SQL，判断是读还是写，然后转发到对应的数据库实例。

判断逻辑并不复杂，Atlas 内部对 SQL 文本做解析，看语句类型和关键字。比如语句以 SELECT 开头，一般归类为读请求；以 INSERT、UPDATE、DELETE、ALTER、CREATE 等开头，归类为写请求。但这里有个坑：SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE 虽然是 SELECT，但它们本质是写操作或需要主库数据一致性，绝对不能路由到从库。Atlas 这一块处理得比较完善，不光是看关键字，还会检查 SQL 有没有 FOR UPDATE 这类特殊子句。

从库延迟是读写分离最头疼的问题。主库写入一条记录，binlog 同步到从库需要时间，如果刚写入就去从库查，很可能查不到。Atlas 层面没有做延迟感知，所以这部分的解决方案通常要落到业务上：对实时性要求极高的数据（比如支付结果、库存扣减），要么强制走主库，要么接受秒级延迟。

我当时的做法是在应用层维护一个简单的“读主库标记”，需要强一致性的查询走一个单独的 DB 连接池，这个池直接连到 Atlas 的路由规则里的主库。虽然绕了半圈，但效果可靠。

2.2 分库分表的路由规则是如何工作的

分库分表是 Atlas 另一个核心价值。它的思路是，在配置里声明一个“逻辑表”，然后告诉 Atlas 这个逻辑表对应的物理库表分布规则。

举个例子，订单表 order 要做分库分表，规则是 userId 取模：

• 4 个库：order_0、order_1、order_2、order_3
• 每个库 4 张表：order_0、order_1、order_2、order_3

应用端正常发送INSERT INTO order_order (order_id, user_id, amount) VALUES (…)，Atlas 解析 SQL 后，根据语句中的 user_id 字段值，计算 user_id % 4 得到表后缀，再计算出库后缀（可能跟表后缀相同，也可以用独立规则），然后改写 SQL 并发送到对应的库表。

这里要特别注意：Atlas 的分表算法是基于 SQL 中某个字段的，这个字段必须有值且是整数类型，常用的是取模运算。如果你的 SQL 里没有这个字段，Atlas 无法判断该去哪个库表，会直接报错或拒绝执行。所以使用分库分表时，所有涉及分表字段的查询条件都必须带上这个字段，否则只能做全表扫描式的路由，这在生产者设计上是不允许的。

Atlas 的配置文件（通常是conf/atlas.conf）里的分表配置段大概长这样：

# 分表规则 tbl_order = "user_id:4:0,1,2,3"

这里的意思是：逻辑表名为 tbl_order，分表字段为 user_id，一共分 4 个物理表，物理表后缀分别为 0、1、2、3。分库规则如果也配置了，就按类似格式指定库后缀。

当然，取模路由只是其中一种方式，实际生产环境还会用到范围路由（比如按时间范围分表）、一致性哈希路由等，但 Atlas 本身内置的规则比较简单，主要还是取模。如果你需要更复杂的路由算法，要么自己在 SQL 层面处理，要么换更重的中间件。

2.3 连接池与会话管理：Atlas 如何维持大量数据库连接

应用端连接 Atlas 时，Atlas 会为它建立一个前端连接。但同时 Atlas 也要连接后端的 MySQL 实例，这部分叫后端连接。如果每个前端连接都对应一个后端连接，那连接数会爆炸，数据库根本扛不住。

Atlas 的做法是维护一个连接池，后端连接可以被复用。具体来说，一个前端连接执行完一条 SQL 后，这个后端连接可能不会立刻释放，而是被放回连接池，下一个前端连接执行 SQL 时可以复用同一个后端连接。连接池的大小、空闲超时时间、连接存活检查等参数都在配置文件里可调。

这并不意味着一对一关系不存在了。如果你有 200 个前端连接，而连接池空闲容量只有 100，那么 200 个前端连接会竞争 100 个后端连接。执行完 SQL 的释放、等待、竞争都由 Atlas 管理，对应用透明。

这种设计有一个好处：应用端只需要配置一个 Atlas 地址和端口，不用担心后端的连接数限制。也有一个坑：如果后端 MySQL 的max_connections设置得过低，即使 Atlas 做了连接池复用，高并发下依然可能出现Too many connections错误。这种时候别光调整 MySQL 配置，还是要结合 Atlas 的连接池参数一起调。

我在压测时遇到过这个问题。当时 Atlas 连接池设置得偏大，后端 MySQL 只有 200 个连接上限，结果高并发压测时 MySQL 直接拒绝新连接。优化方案是把 Atlas 的连接池上限调低，同时把 MySQL 的max_connections提到 500，这才稳住了。

3. 实操过程：从部署到配置读写分离的完整流程

3.1 环境准备与安装部署

Atlas 本身是一个独立的服务进程，基于 C 语言开发，安装包通常是提前编译好的二进制文件。不同的系统版本会有不同的安装包，我以 CentOS 7 系统为例来演示安装过程。

先下载对应版本的 Atlas 安装包，然后解压到指定目录。

# 下载（示例版本号，以实际发布版本为准） wget http://example.com/atlas/atlas-2.2.1.el6.x86_64.rpm # 安装 RPM 包 rpm -ivh atlas-2.2.1.el6.x86_64.rpm

如果你使用的是源码包，一般步骤是：

tar -zxf atlas-2.2.1.tar.gz cd atlas-2.2.1 ./configure --prefix=/usr/local/mysql-proxy make && make install

安装完成后的目录结构大致是这样：

• bin/底下有可执行文件，核心是mysql-proxy（Atlas 基于 MySQL Proxy 二次开发）。
• conf/底下有atlas.conf，这是核心配置文件。
• log/存放运行日志。

启动方式也很简单：

/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/usr/local/mysql-proxy/conf/atlas.conf

如果你需要后台运行，可以这样：

nohup /usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/usr/local/mysql-proxy/conf/atlas.conf > /dev/null 2>&1 &

3.2 核心配置详解：atlas.conf 逐行拆解

Atlas 的配置是 INI 风格，看起来像下面这样，我逐段解释。

[mysql-proxy] # 管理接口的 IP 和端口，用于登录 Atlas 管理后台 admin-address = 0.0.0.0:2345 # 管理接口的用户名和密码 admin-username = admin admin-password = admin123 # 代理监听地址，应用连接这里 proxy-address = 0.0.0.0:1234 # 后端 MySQL 主库地址 proxy-backend-addresses = 192.168.1.10:3306 # 后端 MySQL 从库地址，多个从库用逗号分隔 proxy-read-only-backend-addresses = 192.168.1.11:3306,192.168.1.12:3306 # 连接池相关配置 proxy-pool-min-size = 10 proxy-pool-max-size = 200 # 超时配置 proxy-connect-timeout = 3 proxy-read-timeout = 10 proxy-write-timeout = 10 # 日志级别：message、warning、critical、error log-level = message log-path = /usr/local/mysql-proxy/log

几个关键参数我再展开讲一下。

proxy-backend-addresses配置主库，多个主库之间可以做写负载均衡，但实际场景中通常只有一个主库。proxy-read-only-backend-addresses配置从库，读请求会按权重轮询转发到这些从库。

连接池大小proxy-pool-max-size如果你设置得太大，后端数据库压力大，连接数不够会报错；设置得太小，高并发时后端连接不够，前端 SQL 会排队等待。一般建议先设为 100，压测后慢慢调整。

管理接口admin-address是独立的，通过 MySQL 客户端可以登录这个端口，执行一些管理命令，比如查看后端状态、手动切换读写状态等。命令格式如下：

mysql -h127.0.0.1 -P2345 -uadmin -padmin123

登录后可以执行SELECT * FROM backends;查看后端状态，也可以执行SET offline/SET online来手动下线或上线某个后端库。这个功能在运维排查时非常实用。

3.3 配置读写分离的完整示例

假设我们的业务场景是：

• 主库：192.168.1.10:3306
• 从库两个：192.168.1.11:3306、192.168.1.12:3306
• 应用连接 Atlas 的地址：127.0.0.1:1234

那么配置文件中就设置：

proxy-address = 0.0.0.0:1234 proxy-backend-addresses = 192.168.1.10:3306 proxy-read-only-backend-addresses = 192.168.1.11:3306,192.168.1.12:3306

保存配置文件后，重启 Atlas。

启动后，我们在应用服务器上用 MySQL 客户端测试连接：

mysql -h127.0.0.1 -P1234 -uapp_user -papp_passwd -e "SELECT NOW();"

如果 Atlas 配置正确，这个 SQL 会返回成功。此时我们来验证读写分离是否生效。

在从库上开启通用查询日志（general log），或者从库的processlist里观察是否有 SELECT 查询进入。

-- 在从库执行 SET GLOBAL general_log = ON;

然后在应用端执行几条 SELECT 和 INSERT 语句：

SELECT id, name FROM users WHERE id = 1; INSERT INTO users (name) VALUES ('test');

观察从库日志，你会发现 SELECT 走到了从库；观察主库日志，INSERT 走到了主库。读写分离链路通了。

需要说明的是：Atlas 不会把同一个连接里的所有语句固定路由到同一个后端，它是逐条 SQL 判断的。这意味着你在应用端开启了一个事务，事务里先 INSERT 再 SELECT，事务前半段走主库，后半段的 SELECT 也可能走从库。这在事务一致性上是个隐患。

针对这种情况，Atlas 提供了一个配置项（不同版本有差异）或在管理接口中设置强制走主库的会话变量。我们当时的做法是：在应用端对需要事务内一致性的业务，使用一个独立的数据库账号，这个账号在 Atlas 配置里只指向主库。相当于你有两个数据库账号，一个普通账号走读写分离，一个专用账号全走主库。虽然有点土，但在当时足够好用。

3.4 分库分表配置实操

配置分库分表的核心是把逻辑表映射到物理库表。假设你要对order表做分库分表，规则是：

• 4 个库：order_db_0、order_db_1、order_db_2、order_db_3
• 每个库 4 张表：order_0、order_1、order_2、order_3
• 分表键：user_id

在配置文件的 SQL 解析部分，需要设置分表规则。Atlas 的配置格式大致如下（不同版本可能略有差异，以官方文档为准）：

# 逻辑表名 = 分表字段:分表数量:分表后缀 tbl_order = "user_id:4:0,1,2,3"

如果分库也要做，需要指定库后缀的映射规则，这取决于 Atlas 版本支持的程度。如果只支持分表而不支持分库，那你可能需要预先在应用层或 Proxy 层做库的映射。

实际测试时，插入一条数据：

INSERT INTO order (user_id, order_id, amount) VALUES (1001, 20240001, 99.00);

根据取模规则：1001 % 4 = 1，所以这条记录会进入 order_db_1 库的 order_1 表。

查询时也必须带上 user_id 条件：

SELECT * FROM order WHERE user_id = 1001 AND order_id = 20240001;

这样才能路由到正确的分表。如果不带 user_id 查询，Atlas 无法确定路由，通常会执行全表遍历（如果 Atlas 支持）或直接报错。实际生产环境里，我会在应用层强制要求所有订单查询都带上用户 ID，这也是分库分表方案通用的一条铁律。

3.5 启动验证与状态检查

配置完成后，启动 Atlas 并验证状态。

登录管理接口：

mysql -h127.0.0.1 -P2345 -uadmin -padmin123

执行：

SELECT * FROM backends;

这个命令会列出所有后端 MySQL 的状态。重点关注每个后端的 type（rw 或 ro）、status（up 或 down）、权重等信息。

如果某个从库状态 down 了，读写分离会把它的流量摘除吗？Atlas 的自动摘除机制主要靠心跳检测，如果探测不到后端存活，就自动将它移除出可用列表。这个机制在早期版本里并不稳定，有时需要手动登录管理接口执行：

SET offline ...;

所以日常巡检时，我习惯写一个定时脚本，定期查询 Atlas 管理接口，把 down 状态的后端及时处理掉。脚本内容不复杂，核心逻辑就是连接管理接口，执行SELECT * FROM backends;，解析文本，检查状态。

3.6 在应用端如何优雅切流

这是整个接入过程里最关键的一步。新老系统切换时，我建议分三步走：

1. 先在一台测试服务器上部署 Atlas，把测试应用连接指向 Atlas，验证所有核心链路。
2. 在预发环境，开启少量流量（比如 5% 的请求）到 Atlas 环境，观察错误率和延迟。
3. 全部流量切换到 Atlas 后，保留旧连接方式一周以上，方便随时回滚。

应用端切换非常简单，即修改数据库连接配置：

原来的：jdbc:mysql://192.168.1.10:3306/app_db 现在的：jdbc:mysql://127.0.0.1:1234/app_db

注意，用户名和密码必须以 Atlas 配置中的为准，而不是后端 MySQL 的真实账号密码。Atlas 会代理认证，也就是说应用端的账号密码是 Atlas 自己维护的账号体系，跟后端的 MySQL 账号可以不一样。

我踩过一个坑：当时团队有个老系统，数据库连接串里面带了useSSL=true，连 MySQL 没事，连 Atlas 却反复握手失败。查了半天发现 Atlas 对 SSL 的支持有限，需要把该参数去掉才能正常连接。如果你遇到类似问题，记得检查驱动连接串的 SSL、字符集参数是否跟 Atlas 兼容。

4. 常见问题与排查技巧实录

4.1 连接被拒绝：Atlas 启动失败排查

症状：应用连接 Atlas 提示Can’t connect to MySQL server on '127.0.0.1' (111)。

排查步骤：

1. 检查进程是否存在：

ps -ef | grep mysql-proxy

2. 检查监听端口：

netstat -tlnp | grep 1234

3. 查看日志文件，重点看log/目录下的信息。

日志中出现类似：

[ERROR] proxy-backend-addresses is required

说明配置文件中必填项缺失，补上即可。

如果是：

[ERROR] bind() failed: Address already in use

说明端口被占用，换端口或杀掉占用进程。

启动失败里最高频的原因其实是配置文件写错了。例如 IP 地址后多了一个空格，或者端口号写成字符串，这些细节错误在 Atlas 启动时未必会立刻报出来，但运行时该后端库始终是 down 状态。所以改完配置记得仔细检查一遍格式。

4.2 读写分离不生效：所有请求都走了主库

有时候配置了从库，但 SELECT 请求依然打到主库。常见原因有三个：

• proxy-read-only-backend-addresses没写对，或者空值被注释掉了。
• 从库权重设置为 0，导致不会被选中。
• Atlas 对某些 SQL 类型做了特殊处理，比如带函数的 SELECT、带锁的 SELECT，默认走主库。

排查时先登录管理接口看后端列表：

SELECT * FROM backends;

确认从库的 type 是否为ro、status 是否为up、权重是否大于 0。

再检查 SQL 是否属于特殊类型。最简单的验证方法是在从库开启 general log，然后执行几条典型查询，看看是否会出现在从库日志里。

4.3 从库延迟导致的数据不一致

这个问题不算 Atlas 本身故障，但 Atlas 会把读请求均匀分发到从库，如果从库复制延迟很大，用户会看到数据一会有一会没有。

我更推荐的做法是根据业务容忍度拆分：

• 实时性要求高的读，走主库。
• 允许秒级延迟的读，走从库。

Atlas 没有在配置层面支持“按 SQL 标记强制走主库”，所以只能靠应用层拆分连接。比如在 Spring 里配置两个数据源，一个数据源指向 Atlas 普通端口（读写分离），另一个数据源指向 Atlas 的只主库端口（或者直接指向主库）。

4.4 高并发下出现 Too many connections

我压测时踩过的这个坑，本质原因是连接池和后端 MySQL 连接数上限不匹配。

两层都要调：

• MySQL 端提高max_connections，同时注意max_connections不是越大越好，它会消耗内存。
• Atlas 端调小proxy-pool-max-size，让后端连接数控制在 MySQL 承受范围内。

一个粗略的经验公式：

max_connections >= Atlas的pool-max-size + 其他来源连接数 + 20%余量

如果你有 3 个后端 MySQL 实例，每个实例的max_connections是 500，那 Atlas 的proxy-pool-max-size可以设置为 300 左右，留出运维和备份连接的余量。

4.5 长连接被 MySQL 主动断开

MySQL 的wait_timeout默认是 8 小时。如果应用通过 Atlas 建立了一个长连接，但 8 小时内没有新的 SQL 进来，MySQL 可能主动断开连接。Atlas 连接池里的后端连接也可能被这样清理掉，但前端应用不知道，下次发了 SQL 才发现连接失效。

处理方案有三个：

1. 在应用端连接池（如 HikariCP、Druid）配置test-on-borrow或connection-test-per-connection，发送一个SELECT 1探活。
2. 在应用端设置连接最大空闲时间，小于 MySQL 的wait_timeout。
3. 如果应用无法改动，那就把 MySQL 的wait_timeout调大，或者配置 Atlas 的连接池定期保活。

我比较推荐前两种，因为保活机制会让数据库处理更多无意义的探测请求，但如果连接数不大，效果也不错。

4.6 SQL 语法兼容问题

Atlas 内置的 SQL 解析器并非 100% 兼容所有 MySQL SQL 语法。我遇到过的典型问题包括：

• 带ON DUPLICATE KEY UPDATE的 INSERT 语句，某些版本转发时可能解析异常。
• LOAD DATA INFILE这类文件导入语句，Atlas 基本不支持。
• 某些带 HINT 的 SQL，比如/*+ MAX_EXECUTION_TIME(1000) */ SELECT ...，可能解析不出来。

遇到这类问题，最快的排查方式是把 SQL 单独拿出来用 MySQL 客户端直连 Atlas 测试，然后观察日志输出。如果确定是 SQL 解析问题，一般有三种解法：

1. 改写 SQL，兼容 Atlas 解析。
2. 给 Atlas 打补丁或换个版本。
3. 这类 SQL 走旁路，绕过 Atlas 直接连接真正的 MySQL 实例。

我通常优先选第一种，因为最简单。比如把INSERT INTO ... ON DUPLICATE KEY UPDATE拆成先SELECT再UPDATE，虽然多一次交互，但能保证兼容性，也更便于后续排查。

4.7 Atlas 的高可用部署

生产环境里，Atlas 本身不能成为单点。如果只部署一个 Atlas 实例，它挂了，应用就彻底无法访问数据库。

常见做法是部署两个或多个 Atlas 实例，前面加一层负载均衡（LVS、HAProxy、Nginx Stream 都可以）。如果 Atlas 实例挂了，负载均衡器将流量切到另一个实例。

两个 Atlas 实例之间不需要同步会话状态，因为数据库状态本身在后端 MySQL 里，Atlas 只做转发。这也是中间层代理架构的高可用便利之处，不需要额外引入 ZooKeeper 之类的东西来协调状态，只要保证至少一个实例存活即可。

我当时的部署拓扑是：

• 两台 Atlas 实例，一台主一台备。
• 前端用 HAProxy 做 33060 端口的 VIP，转发到两台 Atlas 的 1234 端口。
• 两个 Atlas 实例配置一致，后端都指向同一组 MySQL 主从。

切换测试也很顺利：杀掉主 Atlas 进程，HAProxy 在健康检查失败后自动把流量切到备 Atlas，应用侧几乎没有感知，只有少量 TCP 连接会报错重连。整体效果符合预期。

5. 监控与运维最佳实践

5.1 需要重点关注的监控指标

Atlas 运行时的健康状态，我主要关注几类指标：

连接数：Atlas 前端连接数（应用连接 Atlas 的连接数）和后端连接数（Atlas 连接 MySQL 的连接数）。连接数异常增长往往意味着应用端连接池泄漏或高并发到来。

请求量：Atlas 每秒钟处理的 SQL 数量和类型。通过日志统计，可以观察读写比例是否合理，如果读比例极高但从库负载很低，需要检查路由是否正常。

延迟：Atlas 转发 SQL 到后端 MySQL 的响应时间。如果延迟突然飙升，可能是后端数据库出问题，也可能是网络抖动。

后端状态：每个后端 MySQL 是 up 还是 down，主库和从库的角色是否正常。

其中没有现成的 Grafana Dashboard 能直接用，最简便的采集方式是通过管理接口SELECT * FROM backends;定期抓取，再写入自己的监控系统。虽然粗粒度，但足够覆盖日常需求。

5.2 配置变更和版本升级注意事项

Atlas 的配置变更要重新启动进程才生效。这一点容易踩坑，因为很多人以为修改配置后会热加载。

建议变更流程：

1. 备份当前配置文件和当前进程状态。
2. 修改配置文件，尽量用 diff 检查改动。
3. 先在后端从库或多实例环境测试。
4. 生产环境操作，选择一个低峰期，重启 Atlas 进程。
5. 重启后立刻验证连接和路由。

版本升级时，先查一下官方 release notes，重点看 SQL 解析逻辑、连接池行为、配置项兼容性。有些版本切换后，旧的配置项被废弃，不检查的话会启动失败。

5.3 日志切割与清理

Atlas 日志如果不定期清理，会占用大量磁盘空间。log-level = message级别下，每条 SQL 的执行都会记录日志，跑一天下来几个 GB 很正常。

建议配置 logrotate 做日志轮转，保留最近 7 天的日志即可。切割方式类似于：

/usr/local/mysql-proxy/log/*.log { daily rotate 7 copytruncate compress missingok }

copytruncate很重要，因为 Atlas 进程一直在写日志文件，直接移走文件可能导致句柄问题，copytruncate可以拷贝后再清空原文件。

5.4 安全加固技巧

Atlas 不直接暴露给公网，只允许应用服务器访问。安全方面注意以下几点：

• 防火墙只放行应用服务器所在网段访问 Atlas 的代理端口和管理端口。
• 管理端口admin-address不要绑定 0.0.0.0，最好是只绑定内网运维跳板机的 IP，否则任何人能连管理接口就麻烦了。
• 修改默认的管理员密码，不要保留 admin/admin123。
• 如果业务对数据敏感，Atlas 层面的 SQL 审计日志要开启，记录所有经过代理的 SQL。注意这会显著增加磁盘 I/O，建议在合规要求下权衡开启。

6. 我踩过的那些坑与总结性建议

做数据库中间件选型时，最忌讳的不是选错方案，而是选了一个运维起来完全超出团队能力的方案。Atlas 很轻量，但它本质上依然是一个需要认真运维的独立服务。你不仅要多部署一层服务，还得为它设计监控、容灾、变更流程，这些成本必须提前算进项目里。

我在 Atlas 落地过程中最大的体会是三个字：先验证。不要直接在生产环境拍板上 Atlas，先在测试环境完整走一遍读写分离、分库分表、故障切换的演练。特别是故障切换，很多人会在切换过程中发现自己的连接池没有配置重连机制，或者 Atlas 备机的端口没有启动，这些都是上线后才发现就会手忙脚乱的问题。

一个小技巧想分享给后来者：给 Atlas 的管理接口写一个简单的 shell 巡检脚本，每天定时跑一次，输出后端的 up/down 状态和连接数。脚本一共不到 30 行，但能帮你节省大量排查时间。我在很多集群里都用了这个笨办法，简单但可靠。

最后再说回 Atlas 本身。它不像某些新潮的分布式数据库那样自带管理面板和一键扩缩容，但它胜在稳定、透明、容易理解。只要你的业务场景是 MySQL 体系下的读写分离和水平分表，Atlas 绝对是一个值得认真考虑的选择。