从 NFS 到 Ceph 的存储谱系,加上边缘加速、内网穿透、堡垒机、CI 与调试工具。
一、文件与对象存储
NFS
NFS 把远程目录挂成本地路径,Unix 系共享家目录和构建缓存很常见。v3 简单,v4 有状态、支持更好的锁与安全。客户端把文件操作转成 RPC。
导出时限制网段和读写权限,root squash 防止远端 root 直接当本地 root。网络抖动会造成应用 hang 在 IO,要选好硬挂载还是软挂载。uid/gid 必须在集群内一致,否则权限错乱。防火墙放行端口后仍要测锁。容器里用 NFS 做数据盘要考虑断开重连。能用对象存储的附件不要强行走 NFS,它更适合共享 POSIX 工作区。
JuiceFS文件存储
JuiceFS 把对象存储变成 POSIX 文件系统,元数据放独立引擎,数据块进 OSS/S3。适合大数据共享目录、AI 训练数据集和需要 POSIX 语义的遗留应用,比直接挂对象存储更像本地盘。
性能取决于元数据延迟、缓存盘和分片大小。小文件密集场景要加大缓存并评估元数据引擎选型。多客户端同时写同一文件仍需应用层约定,分布式锁不是万能的。
运维盯缓存命中、元数据容量和对象存储费用。备份元数据比只备份对象更关键。权限和回收站策略要提前定,误删在对象层不一定好恢复。
FastDFS
FastDFS 是面向海量小文件的分布式文件系统,由 tracker 调度、storage 存文件,适合图片和附件。上传后返回组名和路径,应用自己把 URL 拼出来。
它不强调 POSIX 语义,目录层级弱,适合扁平对象。同步和扩容要按组规划,磁盘尽量同构。Nginx 模块常用来做下载和防盗链。备份策略要明确,删文件是逻辑标记加同步。监控磁盘占用和 tracker 可用性。新项目更多会选对象存储;存量 FastDFS 则稳住版本、做好容量水位,避免在高峰扩组。
Ceph
Ceph 是软件定义存储,一套集群可提供对象(RGW)、块(RBD)和文件(CephFS)。数据按 CRUSH 分布到 OSD,无中心元数据单点,适合云平台后端。
健康取决于磁盘、网络和时钟。规划要算副本或纠删开销、故障域和恢复带宽。监控 OSD 抖动、PG 状态和慢请求。不要把日志盘和数据盘混用到撑爆。客户端缓存和版本要匹配。运维手册必须包含扩容、换盘和灾难恢复演练。小规模可以跑,但生产需要专人,把它当普通 NFS 用会很快踩坑。
二、边缘加速
阿里云 边缘安全加速 ESA
阿里云边缘安全加速 ESA 把 CDN、WAF、DDoS 防护和边缘计算放到同一条接入链路上,站点流量在边缘完成缓存、清洗和规则执行。它适合既要加速静态资源、又要挡住常见 Web 攻击的业务。
接入时先改 DNS 指向,再逐步打开缓存键、回源协议和安全规则。规则要按路径细分,避免把动态接口错误缓存。日志和告警要对齐回源失败与拦截量。证书自动续期后仍需监控过期。边缘函数适合做轻量改写,复杂业务仍回源。计费看流量与请求数,调试期先用灰度域名,确认无误再切主站。
腾讯云 EdgeOne EO (TencentCloud EdgeOne)
腾讯云 EdgeOne 同样是边缘安全加速平台,整合 CDN、七层防护、Bot 管理和边缘函数。站点接入后,静态命中边缘,动态按规则回源,攻击流量尽量在边缘丢弃。
配置重点是加速域名、源站、缓存与 WAF 策略的配合。预热和刷新要纳入发布流程,否则新版本会长时间命中旧缓存。WebSocket 和下载类业务要单独调超时。观测用实时日志看拦截原因,避免误杀登录接口。和对象存储联动可做图床加速。选型时对比节点覆盖和规则表达力,迁移期双跑观察命中率与错误码。
三、负载均衡与内网穿透
四层负载均衡器 SLB LVS F5
四层负载均衡按 IP 和端口转发 TCP/UDP,不解析 HTTP 内容。云上的 SLB、Linux 的 LVS、硬件 F5 都属于这一层,适合数据库、游戏和 TLS 透传,延迟通常低于七层代理。
LVS 有 NAT、DR 和 TUN 模式,DR 性能好但对 ARP 和真实服务器网络有要求。F5 功能全,会话保持、健康检查和证书卸载成熟,成本和运维门槛也更高。
健康检查必须覆盖真实端口和协议,否则会把假活节点留在池里。会话保持用源地址哈希时要考虑出口 NAT 导致的哈希倾斜。容量规划看并发连接和新建速率,不只看带宽。
frp
frp 是内网穿透工具,由公网 frps 和内网 frpc 组成,把本地服务映射到公网端口或域名。开发者常用它临时暴露本地 Web、SSH 或回调接口,省去申请公网 IP。
生产使用必须改默认 token、限制允许的代理类型,并只开放需要的端口。TCP、HTTP、STCP 模式适用场景不同:HTTP 适合带域名的 Web,STCP 适合必须两端都有密钥的访问。不要把数据库或管理后台直接打到公网。日志里会留下访问来源,应定期轮换凭证。若组织已有 VPN,优先走 VPN 而不是把内网服务暴露出去。
四、运维与研发工具
JumpServer开源堡垒机
JumpServer 是开源堡垒机,把 SSH、RDP 和数据库访问收口到统一入口,做授权、会话录像和审计。运维不再直连主机,而是经堡垒机申请权限再登录。
部署后先对接 LDAP/SSO,资产按节点分组,权限按用户组最小化。会话录像占存储,要规划归档。数据库命令审计能拦住高危语句,但需要应用账号仍走堡垒机才有效。升级前备份配置与密钥。公网暴露管理面必须二次认证。它解决的是“谁在何时登录了哪台机器”,不能替代主机本身的补丁和防火墙。
SonarQube
SonarQube 做静态分析与代码质量门禁,覆盖漏洞、异味、重复度和测试覆盖率。扫描器把结果推到服务端,PR 上可以看到新增问题是否突破 Quality Gate。
真正有用的是增量治理:只卡新增代码,而不是要求历史债务一夜清零。规则集要按语言裁剪,关闭大量误报。密钥扫描、SQL 拼接这类安全规则优先打开。分析应在 CI 中可复现,不要依赖开发者本机。覆盖率数字要结合测试质量看,单纯堆测试行数没有意义。对单体仓库注意内存与超时,必要时拆模块扫描。
Travis CI
Travis CI 是较早流行的云端持续集成服务,用 .travis.yml 描述语言版本、安装步骤和脚本。开源项目曾广泛使用它的免费额度,现在更多团队迁到 GitHub Actions 或自托管 Runner。
若仓库仍在用 Travis,应检查密钥是否还放在环境变量、构建镜像是否过旧、以及计费套餐是否还划算。矩阵构建适合测多个 JDK 或 Node 版本,但会迅速消耗额度。缓存依赖能缩短时间,失败日志要保留以便复现。新项目不必强行沿用 Travis,选型看与代码托管的集成深度和权限模型。
代码统计
代码统计用来看仓库体量与语言分布,不是生产力指标。cloc、tokei、scc 能按语言数行、注释与空行。Git 可用 git log --stat 看变更,但生成文件、依赖锁文件要排除。
Android 工程要去掉 build/、.gradle、generated。统计前用 .clocignore。对比历史趋势比单次绝对值有用。开源协议扫描可顺带做。
不要用行数考核。大生成代码会扭曲结果。CI 里定期出报告,和复杂度工具(lizard)一起看热点文件。复制粘贴重复可用 jscpd 补充。
GDB调试
GDB 是 GNU 调试器,可对本地或远程程序设断点、单步、看变量和栈。编译加 -g,strip 之前的符号才能对上源码。常用命令包括 break、run、next、step、print、backtrace。core dump 配合 gdb 能事后看崩溃现场。嵌入式上常通过 gdbserver 经串口或网络调试。
优化过的代码会让变量被优化掉,需要在关键路径降优化。多线程用 info threads 和 thread apply。硬件观察点查内存被谁改。脚本和 Python 扩展能批量检查结构体。不要在生产长时间停核。先复现再下断点,比盲目 step 更有效。GDB 回答的是“这一刻状态是什么”,和日志、追踪互补。
Cgroups
cgroups 让 Linux 把进程放进带配额的控制组,限制 CPU、内存、IO 和设备访问。容器运行时依赖它实现隔离,systemd 也用 slice 管理服务。v1 与 v2 层次不同,新内核默认 cgroup v2。
内存超限会触发 OOM,CPU 配额会造成节流而不是立刻失败。理解 stat 文件才能解释“容器没挂但很慢”。嵌套 cgroup 在 Kubernetes 里对应 QoS 和 limit/request。
排障看 memory.current、cpu.stat 和 io.stat。不要只在应用里加线程。压测要带着 limit 跑,否则上线后才发现被配额卡住。
五、发布与排障
灰度发布
灰度发布把新版本按比例或人群逐步放开,观察错误率、延迟和业务指标后再扩量。它和灰度测试相近,但更强调生产流量治理、自动回滚和配置中心联动。
切流维度可以是用户哈希、地域、机型和内部名单。数据库兼容要向前向后都能活,否则扩到 10% 就会卡在迁移。功能开关最好与发布解耦,方便紧急关闸。
没有基线对比就没有灰度。同一时段的对照组、日志采样和告警阈值要预先写进发布单。扩量节奏宁慢勿跳,夜间高峰前不要把比例拉满。
生产环境服务器频繁触发100%CPU告警。问题排查
- 恶意进程
使用top命令找到CPU高的进程,再通过top -H -p 进程ID找到占用CPU的线程。将线程ID转换为16进制,然后通过jstack 进程ID | grep 16进制进程ID -A 20 打印线程的状态,然后排查。
存储、加速与运维工具速查:NFS、Ceph、frp、堡垒机
https://lautung.com/archives/storage-acceleration-ops-tools
评论