企业官网建设流程全解析

• 开发工具
• 微服务
• 云原生
• CLI

Tye 是微软开源的微服务开发与部署工具，其本地编排器（tye run）和 Kubernetes 部署（tye deploy）均支持为服务定义liveness与readiness两类探针。本文以 docs/recipes/probes.md 为主线，结合 samples/liveness-and-readiness 示例应用与 src/Microsoft.Tye.Hosting/ReplicaMonitor.cs 等源码，系统讲解 Tye 探针的生命周期模型、完整配置语法、本地运行与 Kubernetes 部署的实战验证，以及底层实现原理。读完本文，你将能够在 Tye 应用中独立配置健康探针，让流量只到达真正就绪的副本，并让失效副本被自动重启。

探针的作用与适用场景

与 Kubernetes 部署中的 liveness/readiness/startup 探针 类似，Tye 允许在服务（Service）级别定义liveness与readiness两类探针。探针服务于两个核心目标：

• 将流量隔离在未就绪的副本之外：只把请求路由给真正准备好接收流量的副本，避免因部分副本尚未初始化完成（如缓存预热、数据库连接就绪）而导致请求失败。
• 重启处于异常/不健康状态的副本：当副本彻底失效（如死锁、内存泄漏、致命异常）时，由编排器将其杀掉并重建。

这两类探针职责分工明确：liveness决定"要不要重启"，readiness决定"能不能接流量"。

Replica（副本）的生命周期

在使用本地编排器tye run时，每个副本（Replica）处于以下三种公开状态之一（docs/reference/schema.md）：

• Started：副本刚被启动，尚未被任何探针探测过。
• Healthy：副本通过了liveness探针，但尚未通过readiness探针。
• Ready：副本同时通过了liveness与readiness探针。

内部还有Added、Removed、Stopped等其他状态（见 src/Microsoft.Tye.Hosting/Model/ReplicaState.cs），但这些状态与探针语义无关，本文不展开。

编排器（src/Microsoft.Tye.Hosting/ReplicaMonitor.cs 中的ReplicaMonitor）负责根据探针反馈在这些状态之间切换。当通过tye deploy部署到 Kubernetes 时，生命周期改由 Kubernetes 自身管理（对应 Pod 生命周期概念），但探针配置会被原样翻译为 Kubernetes 探针。

两类探针的区别

liveness与readiness拥有相同的配置结构（Probe 属性），但语义完全不同：

Liveness 探针

liveness探针告诉 Tye何时可以重启一个副本。当liveness探针失败并达到failureThreshold阈值时，该副本会被杀掉，编排器会在其位置创建一个全新副本，而不是修复旧的副本。

从实现看，ReplicaMonitor.cs 中的 liveness 探测逻辑为：连续失败次数达到failureThreshold后调用Kill()，即取消副本的StoppingTokenSource，触发进程退出并由编排器重新拉起。

Readiness 探针

readiness探针告诉 Tye何时可以将流量路由给副本。它不能杀掉或重启副本，只能做两件事：

• 当探测成功时，将Healthy副本提升为Ready。
• 当探测失败时，将Ready副本降级为Healthy。

Tye 只会把流量（无论是通过服务绑定binding还是入口ingress）路由到Ready状态的副本。Healthy副本虽然存活，但不会收到任何业务流量（docs/reference/schema.md）。

缺失探针时的生命周期行为

如果两个探针或其中一个探针没有配置，副本的生命周期会遵循以下规则（这也是 test/E2ETest/HealthCheckTests.cs 中ServiceWithoutLivenessReadinessShouldDefaultToReadyTests、ServiceWithoutLivenessShouldDefaultToHealthyTests、ServiceWithoutReadinessShouldDefaultToReadyWhenHealthyTests三个测试验证的行为）：

• 既无liveness也无readiness：副本创建后直接从Started自动提升为Ready。实现上对应 ReplicaMonitor.cs 中MoveToReady()的调用。
• 只有liveness：副本先从Started提升为Healthy（需通过liveness探测），随后自动再提升为Ready。实现上对应StartLivenessProbe(serviceDesc.Liveness, moveToOnSuccess: ReplicaState.Ready)（ReplicaMonitor.cs），即 liveness 一旦成功，状态直接落到Ready。
• 只有readiness：副本创建后自动从Started提升为Healthy，但只有通过readiness探测后才从Healthy提升为Ready。实现上对应MoveToHealthy(from: ReplicaState.Started)后启动 readiness 探针（ReplicaMonitor.cs）。

探针完整配置属性一览

liveness与readiness拥有相同的属性结构，并且每个服务只能各定义一次（可选）。完整配置属性如下（配置解析见 src/Microsoft.Tye.Core/Serialization/ConfigServiceParser.cs）：

默认值与取值范围可在 src/Microsoft.Tye.Core/ConfigModel/ConfigProbe.cs 中确认（InitialDelay = 0、Period = 1、Timeout = 1、SuccessThreshold = 1、FailureThreshold = 3），解析器对负数和越界值会抛出TyeYamlException。

HttpProber（HTTP 探测器）

http属性的完整结构（解析逻辑见 ConfigServiceParser.cs，运行时模型见 src/Microsoft.Tye.Hosting/Model/HttpProber.cs）：

port与protocol的绑定选择规则（在 ReplicaMonitor.cs 的Start()中有明确实现）：

• 两者都未提供：选择服务的第一个绑定；
• 只提供port：选择第一个端口匹配的绑定；
• 只提供protocol：选择第一个协议匹配（http/https）的绑定；
• 两者都提供：选择第一个端口与协议都匹配的绑定。

若找不到匹配的绑定，Tye 会记录警告日志No suitable binding was found for replica ...并跳过该探针。

本地运行实战：samples/liveness-and-readiness

仓库中的 samples/liveness-and-readiness 示例演示了探针的基础用法。运行方式：

# 进入示例目录后执行 tye run

该示例包含一个配置了liveness与readiness探针的服务，核心配置如下（samples/liveness-and-readiness/tye.yaml）：

name: liveness-and-readiness ingress: - name: ingress bindings: - port: 8080 rules: - path: / service: simple-webapi services: - name: simple-webapi project: webapi/webapi.csproj replicas: 2 liveness: http: path: /lively initialDelay: 1 readiness: http: path: /ready initialDelay: 1

示例服务本身是标准的 ASP.NET Core 健康检查应用（Startup.cs）：

• 注册了两个健康检查：someLivenessCheck（tag 为liveness）与someReadinessCheck（tag 为readiness），并分别映射到/lively与/ready两个端点；
• 请求/lively时返回 HTTP 200（liveness 通过）或 HTTP 500（liveness 失败）；
• 请求/ready时返回 HTTP 200（readiness 通过）或 HTTP 500（readiness 失败）；
• 提供/set端点用于测试：GET /set?someReadinessCheck=false&timeout=10让 readiness 失败 10 秒；GET /set?someLivenessCheck=false让 liveness 失败，触发该副本重启。

观察副本状态迁移日志

执行tye run后，日志会展示两个副本先后通过 liveness（healthy状态）和 readiness（ready状态）的过程：

[18:14:05 INF] Replica simple-webapi_a2d67bd9-4 is moving to an healthy state [18:14:05 INF] Replica simple-webapi_a9c2e2f4-d is moving to an healthy state [18:14:07 INF] Replica simple-webapi_a9c2e2f4-d is moving to a ready state [18:14:07 INF] Replica simple-webapi_a2d67bd9-4 is moving to a ready state

readiness 失败：降级到 Healthy

当readiness探针失败（超过failureThreshold次）时，副本从Ready降级为Healthy，但不会被杀死：

[18:14:18 INF] Replica simple-webapi_a2d67bd9-4 is moving to an healthy state

当readiness探针恢复成功后，副本重新从Healthy提升为Ready：

[18:14:26 INF] Replica simple-webapi_a2d67bd9-4 is moving to a ready state

这两个日志分别对应 ReplicaMonitor.cs 中 readiness 探测的降级与提升分支。E2E 测试 HealthCheckTests.cs 的ReadyServiceShouldBecomeHealthyWhenReadinessFailsTests也验证了该行为。

liveness 失败：杀死并重建副本

当liveness探针失败达到阈值时，副本被杀死，编排器立刻启动一个全新副本，新副本再经历Started → Healthy → Ready的完整流程：

[18:25:08 INF] Killing replica simple-webapi_a9c2e2f4-d because it has failed the liveness probe ... [18:25:08 INF] Launching service simple-webapi_0e7fe12d-7 [18:25:09 INF] Replica simple-webapi_0e7fe12d-7 is moving to an healthy state [18:25:11 INF] Replica simple-webapi_0e7fe12d-7 is moving to a ready state

对应 E2E 测试ReadyServiceShouldRestartWhenLivenessFailsTests（HealthCheckTests.cs）。

流量只会路由到 Ready 副本

E2E 测试ProxyShouldNotProxyToNonReadyReplicasTests（HealthCheckTests.cs）验证了代理行为：当某个副本的 readiness 失败降级为Healthy后，代理（ProxyService）会把请求全部转发给其余Ready副本，不再向不健康的副本发送任何请求。

部署到 Kubernetes：探针自动翻译

当通过tye deploy部署应用时，liveness与readiness探针会被翻译为 Kubernetes 的等价探针表示（KubernetesManifestGenerator.cs 中的AddProbe方法负责生成livenessProbe/readinessProbe清单）。

部署命令：

tye deploy --interactive

部署完成后，可在 Kubernetes 中看到simple-webapiDeployment：

NAME READY UP-TO-DATE AVAILABLE AGE simple-webapi 2/2 2 2 90s

查看 Deployment 详情：

kubectl describe deploy simple-webapi

输出中可以看到翻译后的 Liveness 与 Readiness 探针：

Liveness: http-get http://:80/lively delay=0s timeout=1s period=1s #success=1 #failure=3 Readiness: http-get http://:80/ready delay=0s timeout=1s period=1s #success=1 #failure=3

从生成逻辑看，翻译时遵循以下映射规则（KubernetesManifestGenerator.cs）：

• Tye 的http探测器 → Kubernetes 的httpGet（path、scheme、port、httpHeaders）；
• 未指定port时，取服务第一个绑定（或与protocol匹配的绑定）的端口；
• initialDelay→initialDelaySeconds，period→periodSeconds，successThreshold→successThreshold，failureThreshold→failureThreshold；
• timeout在生成的清单中以毫秒形式体现（Kubernetes 探针的timeoutSeconds字段，Tye 侧默认值 1 秒）。

部署到 Kubernetes 后，副本生命周期由 Kubernetes 接管，探针语义与本地编排器保持一致：liveness 失败触发 Pod 重启，readiness 失败则从 Service 的 Endpoints 中摘除该 Pod，直到其恢复。

底层实现原理：ReplicaMonitor 如何驱动状态机

理解 Tye 探针的底层实现有助于在生产中合理调参。核心逻辑位于 src/Microsoft.Tye.Hosting/ReplicaMonitor.cs：

1. 配置解析与建模：tye.yaml中的liveness/readiness由 ConfigServiceParser.cs 解析为 ConfigProbe 与 ConfigHttpProber，再经 ApplicationFactory.cs 转换为ProbeBuilder/HttpProberBuilder挂到各服务（project、container、dockerFile、executable 类型均可配置）。

2. 状态机初始化（ReplicaMonitor.cs）：ReplicaMonitorState在副本Started时创建，根据 liveness/readiness 的有无决定初始迁移路径（对应前文"缺失探针"一节的三条规则）。

3. HTTP 探测执行（ReplicaMonitor.cs）：内部HttpProber使用共享HttpClient定时向选定绑定发送GET http://localhost:{port}{path}，按period调度、按timeout判超时，非 2xx 状态码或HttpRequestException/TaskCanceledException均视为失败，结果通过Subject<bool>推送给订阅者。

4. 阈值判定与状态迁移：liveness 连续失败达到failureThreshold后执行Kill()（取消副本的 stopping token）；readiness 连续失败达到failureThreshold时从Ready降级为Healthy，连续成功达到successThreshold时从Healthy提升为Ready。每次迁移都会向ReplicaEvents发布事件并记录日志（对应本文前面看到的is moving to ...日志）。

5. 清理：副本Stopped时，探针计时器与订阅被完整释放（Dispose()方法），避免资源泄漏。

配置建议与注意事项

• 为 liveness 与 readiness 使用不同的端点：liveness 检查应只反映"进程是否可恢复"，readiness 检查应反映"当前能否处理请求"（如依赖的外部服务是否可用）。把数据库连通性检查放进 readiness 而非 liveness，可避免瞬时故障导致频繁重启。
• 合理设置initialDelay：对启动较慢的服务（如需要预热缓存、连接外部依赖）设置initialDelay，避免启动期被误杀。默认 0 秒在服务启动慢时可能过早失败。
• 谨慎调小failureThreshold：默认3次失败才触发动作，可容忍偶发网络抖动；若业务对抖动敏感可适当加大，而非直接降为1。
• successThreshold只影响 readiness：Kubernetes 的 liveness 探测不允许设置successThreshold大于 1，Tye 侧文档也明确指出该参数"仅对 readiness 探针有意义"。
• 探测目标端口依赖绑定选择规则：若不指定port/protocol，Tye 会选择第一个绑定进行探测，多绑定服务请显式指定，避免探到错误的端口。

小结

Tye 的探针机制将"进程存活"（liveness）与"流量就绪"（readiness）两个关注点解耦：liveness 失败即杀进程重建，readiness 失败则临时摘流量。本地tye run时由 ReplicaMonitor.cs 驱动的Started → Healthy → Ready状态机负责这一切，而tye deploy到 Kubernetes 时会自动翻译为原生探针，语义完全一致。配合 samples/liveness-and-readiness 示例中的/set测试端点，你可以快速验证探针失败、降级、恢复、重启的完整链路。更多细节可参考 docs/reference/schema.md 中的 Liveness/Readiness 与 HttpProber 章节。

• 开发工具
• 微服务
• 云原生
• CLI