AtlasProxy：需求分析

1.项目背景和问题描述：
假设我写了一个个人博客网站或者别的功能网站，跑在一台机器上，这一台就扛不住，响应变慢甚至挂掉。于是我会可能想加机器，变成两台，三台或者多台，但是问题来了，用户或者客户端只知道一个地址也不知道该连接哪一个，也不可能加一个机器就改配置。举个最极端的例子，高并发的12306就是一个典型的例子。
这就是反向代理需要解决的问题：对外提供一个入口，背后多台机器一起抗流量。用户无感，你只需要在代理里加一份配置，把新机器挂上去就行

再往下想，还有一些实实在在的痛点：
一台后端挂了，请求还在发，用户一直报错， 你希望有一层能自动发现挂了，暂时不把流量分给他，等他恢复了再自动加回来。
活动或者爬虫导致流量突然暴增，直接把后端打挂，你希望在前面挡一层超过一定的QPS就拒绝掉多余的请求，保护后面的服务。
多台机器的配置不一样，有点性能好有的差，希望流量多的分给好的，流量小的分给性能差一点的，做一个平衡。
这些都可以通过一个反向代理来实现，他站在用户和后端之间，负责把请求分到合适的机器，限流，发现故障并摘除。

2.项目目标与范围：
产品目标：做一个可用的HTTP反向代理，支持多台后端，负载均衡，限流和健康检查。方便学习和二次开发。
技术目标：用Linux自带的epoll，多线程等接口实现，不依赖第三方业务库，代码分层清晰好扩展。
范围边界：只做 HTTP/1.x 的请求转发；不做 HTTPS、不做缓存、不做复杂路由；主要面向内网或学习环境。先解决「能转发、能均衡、能限流、能摘挂掉的机器」这几件事。

3.功能需求：
代理转发：接受客户端的HTTP请求，按照配置选择一台后端，把请求原样转回去，然后把后端的响应完整地回给客户端。验收：请求经过代理后，能正确到达后端并拿到响应。
负载均衡：支持轮询、按 IP 哈希、按权重分配三种策略，并且只把流量分给当前判定为可用的后端。验收：多发一些请求，各后端被选中的比例符合你配置的策略
限流：支持每秒请求数突发容量做限流，超过的请求返回503或者明确提示。验收：压测时把 QPS 打超，能看到 503，且限流参数可通过配置改
健康检查：定时去探一下各后端是否还活着，发现挂了就暂时不分配流量，恢复了再自动加回来。验收：停掉某一台后端后，新请求不会再被分到它；该后端重新起来后，流量会重新分过去。
配置：用配置文件（如 JSON）指定监听端口、后端列表、用哪种负载均衡、限流和健康检查的参数，改配置后重启或热重载即可生效，不用改代码。
优雅退出：收到 Ctrl+C 或结束进程的信号时，不再接新连接，把手头请求处理完再退出，不丢请求、不泄漏资源。验收：发信号后进程正常退出，无崩溃无泄漏。

4.非功能性需求：
运行环境：在 Linux 上跑，用系统自带的 glibc、pthread、epoll 等，不依赖第三方 C++ 库，方便在服务器或 WSL 里直接编译运行。
性能：单机多核下能撑住几千并发连接和一定量级的 QPS，具体数字可以后面压测再写死指标。
可维护性：代码按网络、HTTP、代理、工具几块分好，关键逻辑有注释，别人和自己都能看懂、能改。
可配置：监听端口、后端列表、负载均衡策略、限流和健康检查参数都从配置文件读，改配置就能调行为。
可观测：有分级日志（如 DEBUG、INFO、WARN、ERROR），出问题时能通过日志排查。