服务

Consul 服务发现提供注册端点和已经记录的健康观测，不能承诺每个返回端点都会成功响应调用方的下一次请求。实用的运维模型需要分开四件事：注册了什么、哪些检查与该实例有关、查询接受哪些状态，以及这些观测可能已经过去多久。仅仅成功解析到一个地址，并没有自动建立上述全部保证，也没有证明业务请求已经能够完成。 注册记录与健康状态是两回事 catalog 存储注册信息，健康端点再附上检查结果。不加过滤的 /v1/health/service/web 响应，可以包含检查为 critical 的实例。检查失败并不会自动抹去服务注册；显式注销、配置了持续 critical 后自动移除，属于不同的生命周期机制。ACL 也可能影响读者能看到哪些记录，所以查询里缺少实例，不能只归因于健康检查失败。 注册的检查通常从 critical 开始，除非显式提供初始状态。但这并不意味着每个注册服务都一定具有有意义的就绪检查。判断某个服务实例时，需要结合它自己的服务级检查，以及 serfHealth 等节点级检查。同一节点上，数据库服务的检查失败，不会自动让不相关的 Web 服务检查失败；节点级检查变为 critical，则会影响该节点上的服务。不要把“相关检查全部通过”误解成“这台机器上的所有服务检查都必须通过”。 检查结果也不只是布尔值。脚本退出码零表示 passing，一表示 warning，其他退出码表示 critical；HTTP 检查按重定向处理后的响应判断：2xx 为 passing，429 为 warning，其他最终响应表示失败。默认会跟随重定向，除非设置 disable_redirects。这些状态究竟证明了什么，仍取决于探测内容。TCP 握手成功或进程存在，并不证明应用能完成一次真实请求；检查实现必须与希望验证的能力对应。 DNS 并非总是只返回 passing HTTP 健康端点的 passing=true 要求相关检查全部 passing。Consul DNS 服务查询的默认策略不同：warning 实例仍可符合候选条件，critical 实例则被排除。配置 dns_config.only_passing=true 后，warning 也会被排除。因此，一个 warning 实例出现在 DNS，却不在 passing-only API 结果里，不一定意味着检查失效，也可能只是两条路径明确采用了不同策略。 ...

一个 socket 单元可以在兼容应用停止时继续提供监听端点，从而减少少用服务的常驻内存与周期性工作。但套接字、内核队列和管理器仍然占用资源，已经安装的软件也仍然需要安全更新。监听可用还取决于绑定成功、权限正确以及 socket 单元保持活动。端口正在监听，只表示客户端有机会请求工作，并不能证明应用已经初始化或能够返回正确结果；这些条件必须分别观察。 交接方式由配置决定。Accept=no 把监听描述符交给守护进程，由它自己接受连接；Accept=yes 则先接受连接，再启动适合处理该连接的服务实例。客户端可能在应用初始化之前完成连接，随后等待响应，甚至等到超时。应测量从连接到应用回复的完整延迟，不能因为交接对客户端接口透明，就推断冷启动和常驻服务在时延、失败诊断或实际资源成本上没有区别。 socket 单元活动时，请求可以启动兼容服务。应用明确定义的空闲退出可使进程停止，后续需求再触发启动；没有空闲退出时，服务仍继续运行。应在真实负载下测量连接至首个响应的冷启动延迟、客户端截止时间和常驻资源。监控可能同时唤醒多个服务，因此需要验证聚合启动负载。仅示意所选机制；原文仍为搁置/待审，不为其错误泛化背书。 仅示意选定的原文机制；本轮没有执行示例。 让监听器先等着 socket 单元启动时，systemd 打开 ListenStream 指定的端点。Accept=no 通常由 foo.socket 激活 foo.service 并传递监听器，Service= 可以指定其他服务；Accept=yes 通常使用 foo@.service 模板，为每条接受的流连接生成实例。数据报套接字不采用这种逐连接模型。程序必须匹配选定的描述符契约，不能只因为两个单元名称相近，就认为普通绑定逻辑可以原样使用。 这种分离可以减少启动顺序上的耦合，但不会消除依赖。客户端使用套接字之前，socket 单元必须已经活动并监听，所需的服务、挂载、设备与先后顺序依赖仍然适用。兼容服务启动时，连接可以在有限的内核积压队列中等待，但客户端仍可能在应用就绪前失败或超时。当然积压长度也要调：启动慢的服务遇上开机早期的连接洪峰，溢出起来和普通监听队列一样。 服务按需唤醒 按需激活可以在 socket 保持活动时推迟应用的首次启动，但不会让已运行的守护进程自动休眠，也不会自动停止进入空闲的程序。管理服务、罕用协议处理器是否适合这种方式，要看激活接口、请求截止时间与资源画像。其他依赖或人工启动仍然可能提前激活服务，因此不能把首次连接当成所有环境中唯一的启动入口，更不能从文章标题推导永久的运行限制。 要形成反复节省资源的循环，应用必须明确实现安全的空闲退出，先完成或转交进行中的工作，并让管理器持有的监听器继续可用。socket 单元仍活动时，后续需求可以请求再次启动；没有空闲退出逻辑，守护进程可能在第一次激活后一直常驻。这两种情况都不是零成本状态，也不保证套接字永远不会关闭。应验证待处理请求和退出边界，而不是仅设置一个空闲秒数就认定节省已经成立。 用速度换内存 冷启动预算应从连接开始，一直计算到首个有效应用响应，并在有代表性的负载下比较常驻内存。假设启动三百毫秒能够节省八百 MB，在一种工作负载中可能合适，在另一种场景却可能超过请求期限。二十秒预热对异步任务也许可接受，对交互请求则可能不可用。这些数字只是说明取舍，并不是实测结果或通用决策阈值。 有些工作无法承受启动间隙。健康检查本身可能唤醒服务，也可能在初始化时把端点判为不可用；客户端截止时间和负载均衡策略必须匹配实际启动行为。若稳定响应时间比空闲内存更重要，保持守护进程运行可能更简单。开机预热一次并不会自动实现之后的空闲退出，也不能替代对长时间停用后恢复状态的检查。 坏掉的样子 一轮监控可能同时唤醒很多服务，引发总体 CPU 或内存尖峰。错峰检查可以减少同时到来的需求，单服务启动速率限制则约束该单元反复启动的次数，并不能限制整机并发数量或总内存。过短的空闲超时还可能增加启停抖动。应测试聚合启动负载，并使用合适资源控制，而不是把几个独立单元上的限制误认为全机容量保证。 ...

Linger 改变的是一个账号的 systemd 用户管理器在什么时候保持可用。启用后，logind 可以在开机时启动该管理器，并在该账号登录会话结束后继续保留它，从而支持普通账号拥有的无人值守工作。这个标志控制管理器寿命，各个服务仍然遵守自己的激活、失败、停止和安装规则。账号可以没有登录会话，同时有管理器运行，但这不等于所有应用都已经启动。 Linger 控制管理器寿命，单元激活是另一项操作；管理器重启后，已启用单元创建新进程。PID A 和 PID B 是示意身份，不是测量值。图解解释原文，历史运行验证仍受阻。 坏掉的样子 开启 linger 不会自动启用账号配置目录里的每一个单元文件。服务仍需要通过启用关系、依赖、定时器、套接字或其他明确路径受到激活。因此管理器可能完全正常，目标应用却保持非活动。应同时检查两者，而不能把一个 linger 标志理解成当前所有服务的运行清单，更不能仅凭它存在就认定某个后台端口已经提供业务响应。 进程不会跨过整台机器重启继续存活。Linger 可以让新的用户管理器在开机时启动，已启用单元再创建新的进程，原来的内存状态已经消失。加密家目录或较晚挂载的路径，也可能让配置和应用数据在管理器启动时不可用。需要保留的状态应持久化，开机依赖应明确安排，不能靠“会跨重启”这种模糊说法跳过实际恢复过程。 Linger 也不是让崩溃应用无限重启的指令，不会自动把任意 shell 后台任务纳入服务管理。重启策略、资源限制和 logind 对会话进程的处理，分别属于不同控制。稳定的后台角色需要真实用户单元和可观察结果，不能只依赖登出前启动过一个命令，再把账号管理器继续存在当成那个命令必然受控运行。 快速验证 在具备 systemd、logind、用户 D-Bus 支持与账号管理工具的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。它创建临时账号和家目录，只为该账号开启 linger，最后回收本次改动，全程不为这个账号建立登录会话。最后二十秒等待只是样例的超时上限，不是承诺的停止延迟。这个没有登录会话的实验不能证明最后登出后的 UserStopDelaySec 行为： ...