简介TongHttpServerTHS是一款面向运维工程师与系统架构人员的负载均衡软件产品适用于需要提升系统可靠性、可扩展性与资源利用率的部署场景可有效降低建设与维护成本。资源包共71个文件约39.44MB涵盖可执行程序、配置与证书等多类内容conf与ini文件承载服务配置sh脚本负责启动与监控so模块提供多种负载均衡调度策略pem、crt、key、pfx等证书文件支撑HTTPS与国密通信另有sqlite3数据库及管理端相关组件目录结构清晰便于按模块查阅与部署。目前已有4424人学习下载具备一定的实践参考价值。读者可从中获得完整的服务端程序与配套配置样例了解负载均衡调度模块的组织方式并借助证书体系与启动脚本快速搭建测试环境适合用于学习负载均衡原理、验证调度策略及开展运维部署练习。1. 从一台压测机说起TongHttpServerTHSx86 版到底装的是什么上周帮一个做内部系统的朋友看压测结果单机 QPS 一上去就抖日志里全是连接被拒。排查半天不是代码问题是前面那台反向代理扛不住并发连接数一高就开始丢请求。后来换成 TongHttpServerTHS的 x86 版本把负载均衡这一层重新搭了一遍才算稳住。THS_x86.tar.gz 这个包本质就是一个面向 x86 架构 Linux 的 HTTP 服务与负载均衡组件解压即用、不依赖系统包管理器适合内网部署、离线环境、以及不想为了一个代理去折腾一堆运行时依赖的场景。装不好会怎样最常见的就是解压完直接跑端口冲突、权限不对、后端健康检查没配表面上进程活着实际流量全打到一台机器上压测数据好看上线就翻车。这篇笔记按「环境先列清、再一步步装、最后能验证跑通」的顺序写新手照着走能跑起来熟手能看到版本取舍和参数坑。2. 装前把环境列清x86 架构、系统版本与依赖核对2.1 先确认架构和系统别拿错包THS_x86.tar.gz 从名字就能看出来是给 x86x86_64架构准备的。很多人翻车的第一个点是在 ARM 机器上解压这个包二进制根本跑不起来报cannot execute binary file或者Exec format error。所以第一步不是解压是确认机器架构和系统版本。# 确认 CPU 架构输出 x86_64 才能用这个包 uname -m # 确认系统发行版和版本号便于判断 glibc 兼容性 cat /etc/os-release # 确认 glibc 版本THS 的二进制通常依赖系统 glibc ldd --version | head -n 1uname -m输出x86_64说明架构对得上如果输出aarch64这个包就不适用得换对应架构的版本。/etc/os-release用来看是哪个发行版、哪个大版本常见做法是 CentOS 7/8、Ubuntu 20.04/22.04 这类主流版本太老的系统 glibc 版本低二进制可能加载失败。ldd --version看的是动态链接库版本THS 这类预编译二进制对 glibc 有最低要求低于要求会报GLIBC_2.xx not found这种报错基本没法靠改配置解决只能换系统或换包。我一般会把这几个输出记在一个临时文件里后面出问题回头对照省得反复问「当时是什么系统」。2.2 依赖与端口装之前先占位检查THS 解压即用但「不依赖包管理器」不等于「零依赖」。它仍然依赖系统的基础 C 库、以及一些常见的网络工具来做验证。装之前建议把下面这些确认一遍缺的补上。# 检查常用工具是否存在缺哪个装哪个 for cmd in tar curl ss netstat lsof; do command -v $cmd /dev/null 21 echo $cmd ok || echo $cmd missing done # 检查计划使用的端口是否被占用THS 默认常用 80/8080/9090 这类 ss -lntp | grep -E :(80|8080|9090)\b第一段循环是批量探测命令是否存在tar用来解压、curl用来做后面的连通性验证、ss/netstat/lsof用来查端口和进程。第二段ss -lntp列出所有监听中的 TCP 端口-l只看监听、-n不做域名解析、-t只看 TCP、-p显示进程。如果 80 或 8080 已经被别的服务占了要么改 THS 的监听端口要么先把占用进程处理掉别等装完启动失败再回头查。提示离线环境里curl可能也没有那就用wget或者直接用telnet做连通性验证原理一样能发出 HTTP 请求、能看到响应头就行。2.3 目录规划与运行用户预编译包最忌讳的就是「随手解压到当前目录然后 root 跑」。我一般会固定一个安装根目录比如/opt/ths并且用一个普通用户来跑服务避免权限过大。目录规划建议如下目录用途说明/opt/ths安装根目录解压后的主目录固定路径便于运维/opt/ths/conf配置文件目录负载均衡、后端、日志相关配置/opt/ths/logs日志目录需要运行用户有写权限/opt/ths/bin启停脚本目录启动、停止、重载入口创建目录和用户的常见做法# 创建专用运行用户禁止登录 useradd -r -s /sbin/nologin thsrun # 创建安装目录并授权 mkdir -p /opt/ths chown -R thsrun:thsrun /opt/thsuseradd -r创建系统用户-s /sbin/nologin禁止登录降低被利用的风险。目录授权给这个用户后面解压和写日志都用它避免出现「root 解压、普通用户跑、日志写不进去」这种典型权限坑。3. 解压与安装THS_x86.tar.gz 落地步骤3.1 解压、校验与目录归位拿到 THS_x86.tar.gz 之后先别急着解压到最终目录先解到一个临时目录看一眼结构确认包完整、内容符合预期再归位。# 切到包所在目录先看包大小和校验值 ls -lh THS_x86.tar.gz sha256sum THS_x86.tar.gz # 解压到临时目录查看结构 mkdir -p /tmp/ths_unpack tar -zxvf THS_x86.tar.gz -C /tmp/ths_unpack # 查看解压后的顶层结构 ls -la /tmp/ths_unpacksha256sum用来记录包的指纹多台机器部署时对比一下能排除传输损坏。tar -zxvf里-z是 gzip 解压、-x解包、-v显示过程、-f指定文件。解到/tmp/ths_unpack是为了先看清楚里面是「直接一层目录」还是「多套了一层」很多包解压出来会多一层同名目录直接解到/opt/ths会导致路径变成/opt/ths/THS_x86/...后面配置里的相对路径全对不上。确认结构没问题后归位# 假设解压后是单层目录结构整体移动到安装根目录 cp -a /tmp/ths_unpack/. /opt/ths/ chown -R thsrun:thsrun /opt/ths # 确认关键文件存在 ls -la /opt/ths/bin /opt/ths/confcp -a保留权限和时间戳/.的写法是把源目录内容拷进目标而不是拷目录本身。归位后检查bin和conf是否存在这两个目录是后面启动和配置的入口缺了说明包结构和你预期不一致得回头再看一眼解压内容。3.2 配置文件怎么改监听、后端与负载均衡策略THS 的核心配置集中在conf目录下负载均衡这一层主要关心三件事监听哪个地址端口、后端有哪些节点、用什么策略分发。下面给一份最小可用的配置骨架字段名以实际包内示例为准思路是通用的。# 先备份原始配置改坏了能回滚 cp /opt/ths/conf/server.conf /opt/ths/conf/server.conf.bak # 查看包内自带的示例配置照着改最稳 ls /opt/ths/conf/配置内容大致结构如下以常见的键值/块状配置为例# 监听配置对外提供服务的地址和端口 listen 0.0.0.0:8080; # 后端节点池负载均衡的目标 upstream backend_pool { server 192.168.10.11:8000 weight1; server 192.168.10.12:8000 weight1; server 192.168.10.13:8000 weight1; } # 负载均衡策略轮询 / 加权 / 最少连接按实际场景选 balance roundrobin; # 健康检查后端挂了要能自动摘除 health_check interval5s timeout2s fall3 rise2;listen决定对外入口0.0.0.0表示所有网卡生产环境如果只想内网访问改成具体内网 IP 更安全。upstream块里每个server是一个后端节点weight是权重机器配置不一致时用加权比纯轮询合理。balance是策略轮询适合节点同构、请求耗时均匀的场景如果后端有长请求最少连接leastconn更稳。health_check里interval是检查间隔、timeout是超时、fall是连续失败几次判定下线、rise是连续成功几次恢复上线这几个值别设太激进否则后端一次抖动就被摘流量瞬间压到剩余节点上。注意不同版本的 THS 配置字段名可能有差异改之前一定先看包内自带的示例配置和说明文件以包内为准上面这份是结构和思路参考。3.3 启动、停止与开机自启配置改完先用运行用户前台启动一次看日志有没有报错确认没问题再做成后台服务。# 用运行用户前台启动观察输出 su -s /bin/bash thsrun -c /opt/ths/bin/ths -c /opt/ths/conf/server.conf # 另开一个终端看日志 tail -f /opt/ths/logs/error.log前台启动的好处是报错直接打在终端上配置语法错、端口被占、权限不足一眼能看到。确认能起来后用CtrlC停掉再配成系统服务。以 systemd 为例# /etc/systemd/system/ths.service [Unit] DescriptionTongHttpServer Afternetwork.target [Service] Typesimple Userthsrun Groupthsrun ExecStart/opt/ths/bin/ths -c /opt/ths/conf/server.conf ExecReload/bin/kill -HUP $MAINPID Restarton-failure RestartSec3 LimitNOFILE65535 [Install] WantedBymulti-user.targetUser/Group指定运行身份和前面创建的thsrun对应。ExecReload用 HUP 信号触发重载改配置后不用重启进程。Restarton-failure让进程异常退出后自动拉起RestartSec3避免频繁重启打满日志。LimitNOFILE65535是文件描述符上限负载均衡场景连接数高这个值不调压测一上来就报too many open files属于典型血泪坑。启用服务systemctl daemon-reload systemctl enable --now ths systemctl status thsdaemon-reload让 systemd 重新读 unit 文件enable --now同时设开机自启并立即启动status看运行状态和最近日志。4. 负载均衡配置进阶后端池、健康检查与日志4.1 后端池的几种组织方式与取舍后端池不是把 IP 列上去就完事组织方式直接影响故障时的表现。常见有三种全部平铺在一个 upstream 块、按业务拆多个 upstream、按机房/可用区分组。平铺最简单适合后端少、同构的场景按业务拆便于不同业务用不同策略和健康检查参数按可用区分组配合主备或故障转移适合对可用性要求高的内部系统。# 按业务拆分两个后端池各自独立策略 upstream api_pool { server 192.168.10.11:8000 weight2; server 192.168.10.12:8000 weight1; balance leastconn; } upstream static_pool { server 192.168.10.21:8080; server 192.168.10.22:8080; balance roundrobin; }api_pool用加权最少连接因为 API 请求耗时差异大权重给配置更好的机器更高static_pool用轮询静态资源请求耗时均匀轮询足够。这种拆分的价值在于一个池子的健康检查参数可以调得更激进另一个调保守互不影响。我一般会按「请求特征是否一致」来决定拆不拆特征差太多硬塞一个池子策略怎么调都是将就。4.2 健康检查参数怎么定别拍脑袋健康检查是负载均衡里最容易「配了但没生效」的部分。参数定得太松后端挂了还在转发定得太紧网络抖一下就摘节点。下面这张表是我一般会参考的取值区间参数含义保守取值激进取值适用场景interval检查间隔10s3s内网稳定用保守跨网段用激进timeout单次超时3s1s后端响应慢就放宽fall失败几次下线52怕误摘就调大rise成功几次上线31怕恢复慢就调小保守取值适合后端本身不稳定、网络质量一般的环境宁可晚一点摘除也不要误判激进取值适合内网低延迟、后端健康状态明确的场景故障切换更快。关键是fall和rise要和interval一起看interval3s、fall2意味着最快 6 秒判定下线interval10s、fall5要 50 秒才摘这中间的流量都会打到坏节点上。压测时如果发现「后端已经挂了但请求还在报错」先查这两个值的乘积。4.3 日志分级与访问日志落盘日志是排障的黑匣子但日志配不好要么写满磁盘要么关键信息没有。THS 一般分访问日志和错误日志访问日志记录每个请求打到哪个后端错误日志记录启动、配置、健康检查的异常。# 日志配置示例 access_log /opt/ths/logs/access.log combined; error_log /opt/ths/logs/error.log warn;combined是常见格式包含客户端 IP、时间、请求行、状态码、响应大小、来源等排查「请求打到哪台后端」时如果格式里带了 upstream 信息会更好用具体字段看包内支持情况。error_log的级别从低到高一般是 debug/info/notice/warn/error生产环境用warn比较平衡debug 只在排障时临时开开久了日志量能把磁盘写满。日志轮转别忘配否则跑几个月磁盘就满# /etc/logrotate.d/ths /opt/ths/logs/*.log { daily rotate 14 missingok notifempty compress copytruncate }daily按天切、rotate 14保留 14 份、compress压缩旧日志、copytruncate复制后截断适合不支持重新打开日志文件的进程。missingok和notifempty避免空文件报错。5. 常见问题排查装完跑不通的几种典型情况5.1 启动即退出日志只有一行现象systemctl start ths后状态变成 failederror.log里只有一行配置相关报错。原因多半是配置语法错比如少了分号、括号不配对、字段名拼错。解决先用前台方式启动把完整报错打出来对照包内示例配置逐行比对改完配置先用-t之类的测试参数如果包内支持做语法检查再重启。我一般改配置前先备份改完 diff 一下能快速定位改了哪几行。5.2 端口被占进程起不来但没明显报错现象启动脚本返回成功但ss -lntp看不到监听端口或者日志里提示 bind 失败。原因是对外端口已被其他服务占用或者上一次的 THS 进程没退干净。解决ss -lntp | grep 端口找到占用进程确认是不是残留的 THS 进程是就正常停掉是别的服务就改 THS 监听端口。注意别直接kill -9先systemctl stop或发 TERM 信号让进程有机会释放端口和连接。5.3 后端全在线但流量只打一台现象压测时所有请求都落到同一台后端其他节点几乎没流量。原因是负载均衡策略配成了单节点、权重配错某台权重极大、或者会话保持sticky开了但没配好。解决先看balance策略和weight配置再看是否开了基于 cookie 或 IP 的会话保持。会话保持本身不是错但内部系统如果不需要开着就会导致分发不均关掉或改成按请求分发即可。5.4 压测一上来就报 too many open files现象低并发正常并发一高就大量连接失败日志里出现too many open files。原因是进程文件描述符上限太低systemd 默认往往只有 1024。解决在 unit 文件里加LimitNOFILE65535daemon-reload后重启同时确认系统级fs.file-max和用户级ulimit -n足够。这个坑很玄学因为不压测根本发现不了上线才炸。5.5 健康检查把正常节点摘了现象后端服务明明正常但隔一会儿就被摘除流量忽多忽少。原因是健康检查的timeout太短或fall太小后端偶发慢请求被判定失败。解决把timeout放宽到后端 P99 响应时间以上fall调到 3 到 5interval适当拉长。判断依据看错误日志里健康检查的记录如果失败集中在某个时间点多半是后端当时有慢查询或 GC不是真挂。6. 装完怎么验证跑通三层验证与一个习惯装完不等于跑通我一般分三层验证进程层、端口层、业务层。进程层看服务是否稳定存活端口层看监听是否正确业务层看请求是否真的按预期分发到后端。三层都过才算这套负载均衡环境落地。第一层进程和端口# 服务状态与监听端口 systemctl status ths --no-pager ss -lntp | grep -E :(8080)\b # 连续观察 30 秒确认没有反复重启 for i in $(seq 1 6); do systemctl is-active ths; sleep 5; doneis-active连续输出active说明进程稳定如果中间出现activating或failed说明有重启循环回去看error.log。第二层本机连通性# 直接请求监听端口看响应头和状态码 curl -I http://127.0.0.1:8080/ # 带 Host 头模拟真实访问 curl -I -H Host: internal.example http://127.0.0.1:8080/-I只取响应头看状态码是不是 200/301/302 这类正常值带Host头是为了验证基于域名的路由配置是否生效。第三层分发验证这是负载均衡最该验的一步# 连续请求 10 次观察是否落到不同后端 for i in $(seq 1 10); do curl -s http://127.0.0.1:8080/health echo done如果后端返回里带了节点标识比如主机名或节点编号这 10 次请求应该能看到多个不同标识如果全是同一个回去查balance和weight。这一步是很多人跳过的结果上线才发现流量全压一台。最后是一个习惯每次装完 THS我都会把「架构、系统版本、glibc 版本、包 sha256、配置 diff、三层验证输出」记进一个部署记录文件下次换机器或出故障直接对照不用凭记忆猜。从那以后我每次部署这类预编译服务都强制走一遍三层验证再交付宁可多花十分钟也不让「进程活着但流量打偏」这种问题溜到线上。希望帮到你。本文还有配套的精品资源点击获取
