CMS后端Web框架【免费下载链接】OrchardCoreOrchard Core is an open-source modular and multi-tenant application framework built with ASP.NET Core, and a content management system (CMS) built on top of that framework.项目地址https://gitcode.com/gh_mirrors/or/OrchardCore点击查看免费下载导读OrchardCore.HealthChecks是 Orchard Core 框架中负责“应用存活/就绪探测”的模块它把 ASP.NET Core 注册的健康检查基础设施以租户tenant端点的形式暴露到 HTTP 层。本模块只提供端点与响应写入器本身不注册任何检查项因此非常适合在 Kubernetes 探针、负载均衡器或外部 uptime 监控场景中按租户独立启用。读完本文你将掌握如何为单个租户启用该功能、如何通过OrchardCore:HealthChecks配置端点路径与详细模式、两种响应模式的 HTTP 状态码语义、Redis 与 SMS 等内置检查的注册机制以及如何用标准 ASP.NET Core API 编写自定义IHealthCheck并替换详细响应写入器。说明该模块没有管理界面无 administration UI也没有站点设置必须为每个需要监控的租户单独启用与配置。健康检查端点无需认证即可访问启用详细模式前请评估信息暴露风险详见下文“监控与安全”。功能定位与设计思路模块的核心定位可以概括为三点模块清单见 src/OrchardCore.Modules/OrchardCore.HealthChecks/Manifest.cs暴露已注册的健康检查将 ASP.NET CoreIHealthCheck注册项通过租户端点对外提供不注册任何检查端点与响应写入器由本模块注册检查项由其他功能或自定义代码贡献空注册时报告健康若没有其他已启用功能注册检查端点直接报告租户健康。从源码看模块装配非常轻量Startup.cspublic override void ConfigureServices(IServiceCollection services) { services.AddScopedIHealthChecksResponseWriter, DefaultHealthChecksResponseWriter(); services.AddHealthChecks(); // The OrchardCore_HealthChecks section is deprecated and will be removed in a future major version, use HealthChecks instead. services.ConfigureHealthChecksOptions(_shellConfiguration.GetSectionCompat(HealthChecks, OrchardCore_HealthChecks)); }要点AddScopedIHealthChecksResponseWriter, DefaultHealthChecksResponseWriter()注册了响应写入器的作用域实现这是后续“替换详细响应写入器”扩展点的载体services.AddHealthChecks()引入 ASP.NET Core 标准健康检查基础设施Microsoft.Extensions.Diagnostics.HealthChecks配置绑定使用GetSectionCompat(HealthChecks, OrchardCore_HealthChecks)——旧节OrchardCore_HealthChecks已标记弃用将在未来主版本移除请统一使用OrchardCore:HealthChecks见 ConfigurationSchema.json。端点路由在 Startup.cs 的Configure中按ShowDetails分支映射细节见下文“响应与状态行为”。启用功能在租户管理后台通过Tools工具 Features功能启用Health Checks也可以在 recipe 中通过feature步骤启用适用于部署自动化、setup 阶段{ name: feature, enable: [ OrchardCore.HealthChecks ], disable: [] }只有启用了该功能的租户才会暴露端点——这意味着一个多租户站点可以做到“部分租户可探测、部分租户不暴露”。健康检查端点Health Check Endpoint默认端点为/health/live端点属于租户管线tenant pipeline访问时必须带上该租户的主机名与 URL 前缀。以多租户场景为例https://example.com/health/live https://example.com/customer-a/health/live https://customer-a.example.com/health/live第一种默认租户无 URL 前缀第二种基于路径前缀的租户customer-a第三种基于子域名的租户customer-a。每次请求都会执行该租户服务容器中注册的全部健康检查模块不会按标签tag过滤注册项这一点对理解行为与耗时至关重要见“由 Orchard Core 功能贡献的检查项”一节。用 curl 快速验证curl --include https://example.com/health/live--include用于同时查看 HTTP 状态码与响应体便于确认当前处于哪种响应模式。配置端点通过租户感知的OrchardCore:HealthChecks配置节进行配置。支持 JSON 配置文件{ OrchardCore: { HealthChecks: { Url: /health/live, ShowDetails: false } } }设置默认值说明Url/health/live在每个已启用租户内部映射的路由。租户 URL 前缀会应用在此路由之前。ShowDetailsfalse为false时返回 ASP.NET Core 默认的紧凑响应为true时返回 Orchard Core 的 JSON 响应含每个检查的名称、状态与描述。同样的设置可通过环境变量提供注意__分隔符OrchardCore__HealthChecks__Url/health/live OrchardCore__HealthChecks__ShowDetailsfalse要针对命名租户named tenant配置将 shell name 插入配置层级OrchardCore__CustomerA__HealthChecks__Url/health/ready以上配置来源与租户专用环境变量模式参见 Configuration配置 的IShellConfiguration说明含环境变量小节。重要路由与响应写入器是在租户管线构建时选定的因此修改这些设置后需要重载租户或重启应用才能生效这也体现在文末的故障排查表中。配置模式小结全局配置OrchardCore:HealthChecks影响所有启用该功能的租户租户级覆盖OrchardCore:{TenantName}:HealthChecks或对应OrchardCore__{TenantName}__HealthChecks__*环境变量只影响指定租户旧节OrchardCore_HealthChecks已弃用仅作兼容保留ConfigurationSchema.json 中标记为deprecated。响应与状态行为模块按ShowDetails提供两种截然不同的响应模式选择哪一种取决于监控端如何判断可用性。紧凑响应Compact Response默认ShowDetails: false默认时使用 ASP.NET Core 原生健康检查响应映射关系如下聚合状态HTTP 状态码Healthy200 OKDegraded200 OKUnhealthy503 Service Unavailable响应体只包含聚合状态文本例如Healthy该模式适合仅凭 HTTP 状态码判断可用性的监控器负载均衡器、KuberneteshttpGet探针、uptime 平台因为它们天然期望“不健康 非 2xx”。从源码看紧凑模式即直接调用 ASP.NET Core 默认行为Startup.cselse { routes.MapHealthChecks(healthChecksOptions.Url); }未设置ResponseWriter未覆盖ResultStatusCodes因此完全遵循 ASP.NET Core 默认语义。详细响应Detailed ResponseShowDetails: true时返回 JSON包含聚合状态、总耗时以及每个注册检查的名称、状态与描述{ Status: Unhealthy, Duration: 00:00:00.0420000, HealthChecks: [ { Name: Dependency, Status: Unhealthy, Description: The dependency did not respond. } ] }关键语义变化Healthy、Degraded、Unhealthy全部返回200 OK监控端必须解析顶层Status属性不能依赖 HTTP 状态码响应不包含检查项的异常exception、数据字典data dictionary或标签tags。这一行为由源码直接印证Startup.cs详细模式下ResultStatusCodes将三种状态全部映射为200 OK并挂载自定义ResponseWriterroutes.MapHealthChecks(healthChecksOptions.Url, new HealthCheckOptions { AllowCachingResponses false, ResultStatusCodes { [HealthStatus.Healthy] StatusCodes.Status200OK, [HealthStatus.Degraded] StatusCodes.Status200OK, [HealthStatus.Unhealthy] StatusCodes.Status200OK, }, ResponseWriter healthChecksResponseWriter.WriteResponseAsync, });JSON 的字段结构对应 HealthCheckResponse.cs 与 HealthCheckEntry.cs 两个模型序列化与写出由 DefaultHealthChecksResponseWriter.cs 完成Content-Type: application/json直接JsonSerializer.Serialize输出。两种模式都通过AllowCachingResponses false禁用响应缓存保证探针每次都能拿到实时状态。⚠️警告该端点不要求认证。详细模式下的描述文本可能泄露依赖名称或运维信息因此只在端点被限制到可信监控客户端时启用ShowDetails。由 Orchard Core 功能贡献的检查项Health Checks 功能只注册端点、不注册任何检查实现其他已启用的 Orchard Core 功能可以贡献检查项功能注册名行为OrchardCore.RedisRedis Health Check连接 Redis 并通过 ping 验证其响应。OrchardCore.SmsSMS Health Check用配置的 Twilio 凭据向 Twilio 服务验证连接。这些检查仅当所属功能与该租户的OrchardCore.HealthChecks同时启用时才注册。由于一次探测会执行所有已注册检查规划轮询间隔时必须把外部调用耗时与超时考虑进去。Redis 检查的实现细节Redis 侧注册逻辑见 src/OrchardCore.Modules/OrchardCore.Redis/HealthChecks/Startup.cs[RequireFeatures(OrchardCore.HealthChecks)]保证仅当 Health Checks 功能启用时该 startup 才加载随后AddHealthChecks().AddRedisCheck()完成注册。检查实现 RedisHealthCheck.cs 的行为若IRedisService未注册 → 返回Unhealthy连接为 null 时先ConnectAsync()已连接则执行Database.PingAsync()响应超过 30 秒源码中Timeout 30判为Unhealthy提示可能离线或性能劣化否则返回Healthy任何异常被捕获并转为Unhealthy附带异常信息。SMS/Twilio 检查的实现细节SMS 侧对应 src/OrchardCore.Modules/OrchardCore.Sms/HealthChecks/Startup.cs同样带[RequireFeatures(OrchardCore.HealthChecks)]与AddSmsCheck()扩展SmsHealthCheckExtensions.cs。实现 SmsHealthCheck.cs 通过IHttpClientFactory创建客户端用 Basic AuthAccountSID:AuthToken请求https://api.twilio.com/2010-04-01/Accounts/{accountSid}.json响应为成功状态码即Healthy否则Unhealthy。引申这些检查都会执行真实的外部或内部 IO。若轮询频率过高每个租户每次探测都会触发一次 Redis ping 或 Twilio API 调用需结合预算与依赖的 SLA 选择合适的间隔。添加自定义健康检查健康检查使用标准 ASP.NET Core 注册 API无需任何 Orchard Core 特有抽象。从一个与租户同启用的功能中注册IHealthCheck即可using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Diagnostics.HealthChecks; using OrchardCore.Modules; namespace MyModule; [RequireFeatures(OrchardCore.HealthChecks)] public sealed class Startup : StartupBase { public override void ConfigureServices(IServiceCollection services) { services .AddHealthChecks() .AddCheckDependencyHealthCheck(Dependency); } } public sealed class DependencyHealthCheck : IHealthCheck { public TaskHealthCheckResult CheckHealthAsync( HealthCheckContext context, CancellationToken cancellationToken default) { var result HealthCheckResult.Healthy(The dependency is available.); return Task.FromResult(result); } }要点拆解[RequireFeatures(OrchardCore.HealthChecks)]当 Health Checks 功能被禁用时阻止该 startup 的注册加载——这是模块“只贡献检查、不依赖端点”的官方配合方式替代方案把OrchardCore.HealthChecks声明为自定义功能的依赖feature dependency这样启用自定义功能时会同时启用端点实现IHealthCheck只需返回HealthCheckResultHealthy/Degraded/Unhealthy均可附带 description 与异常真实场景中可在CheckHealthAsync内探测数据库、缓存、外部 API并设置合理的cancellationToken与超时标签tag语义AddCheck传入的 tags 对 ASP.NET Core 仍然可用例如供其他消费方按 tag 过滤但本模块不会用 tag 创建独立的 liveness/readiness 端点——它只运行全部注册项。关于注册选项与IHealthCheck实现模式如AddCheck的FailureStatus、tags、timeout重载以及HealthCheckRegistration的按注册超时行为请参考 ASP.NET Core 官方健康检查文档。替换详细响应写入器当ShowDetails启用时模块从租户服务容器解析IHealthChecksResponseWriter注意前面源码里注册的是scoped实现。依赖OrchardCore.HealthChecks的功能可以替换默认实现using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.DependencyInjection.Extensions; using OrchardCore.HealthChecks.Services; services.Replace( ServiceDescriptor.ScopedIHealthChecksResponseWriter, CustomHealthChecksResponseWriter());实现WriteResponseAsync(HttpContext, HealthReport)即可生成自定义响应例如添加自定义字段、把 Description 脱敏、输出其他格式等。需要了解默认输出结构时可直接对照 DefaultHealthChecksResponseWriter.cs 的写法。该扩展点只影响详细模式紧凑模式继续使用 ASP.NET Core 默认响应写入器。监控与安全Monitoring and Security针对监控与安全的最佳实践负载均衡 / 容器平台 / uptime 监控期望“不健康 非成功状态码”请使用紧凑模式默认ShowDetails: false详细模式监控端必须配置为解析 JSON 的Status字段而非 HTTP 状态码探针 URL务必包含租户主机名与 URL 前缀端点暴露范围当端点不应公开时用网络策略、反向代理或其他边界控制加以限制限流可用 Rate Limits 模块的端点策略endpoint policy限制对健康检查路径的重复请求防止端点被当作免费请求入口滥用。模块暴露的是一个可配置端点运行全部已注册检查。如果需要独立的 liveness 与 readiness 语义应在应用或模块代码中自行添加带标签过滤的端点例如MapHealthChecks(/health/ready, new HealthCheckOptions { Predicate _ _.Tags.Contains(ready) })而不是把本端点当作两者混用而不考虑其注册内容。故障排查Troubleshooting症状排查要点404 Not Found确认请求的租户已启用OrchardCore.HealthChecks使用该租户的主机与 URL 前缀核对配置的Url是否与请求路径一致。详细模式下不健康却返回200 OK这是ShowDetails启用时的预期行为。解析 JSON 的Status或关闭详细模式以获得503 Service Unavailable。响应为Healthy但没有任何检查项该功能只提供端点、不提供检查实现。启用能贡献检查的功能如 Redis、Sms或注册自定义IHealthCheck。自定义检查缺失确认其所属功能在该租户内已启用确认其 startup 注册只在OrchardCore.HealthChecks之后或与之同时加载例如通过RequireFeatures或功能依赖。配置修改不生效重载租户或重启应用使租户管线与端点重建路由与响应写入器在管线构建时选定。关键源码路径索引模块装配与端点映射src/OrchardCore.Modules/OrchardCore.HealthChecks/Startup.cs默认 JSON 响应写入器src/OrchardCore.Modules/OrchardCore.HealthChecks/Services/DefaultHealthChecksResponseWriter.cs响应模型HealthCheckResponse.cs、HealthCheckEntry.cs配置 schema含默认值与弃用节src/OrchardCore.Modules/OrchardCore.HealthChecks/ConfigurationSchema.jsonRedis 检查src/OrchardCore.Modules/OrchardCore.Redis/HealthChecks/SMS/Twilio 检查src/OrchardCore.Modules/OrchardCore.Sms/HealthChecks/总结OrchardCore.HealthChecks是 Orchard Core 多租户架构中“按租户暴露健康状态”的轻量桥梁它复用 ASP.NET Core 标准健康检查 API把检查注册、端点映射、紧凑/详细两种响应模式、可替换的响应写入器组合在一起同时又刻意不绑定任何具体检查实现把“检查什么”完全交给 Redis、Sms 等功能或你自己的模块。在多租户生产环境中请牢记三件事按租户启用功能与配置都是租户级的、按监控端语义选择响应模式紧凑模式看状态码、详细模式看 JSONStatus、端点默认无认证用网络策略与限流保护仅在可信环境下开启ShowDetails。赞分享CMS后端Web框架【免费下载链接】OrchardCoreOrchard Core is an open-source modular and multi-tenant application framework built with ASP.NET Core, and a content management system (CMS) built on top of that framework.项目地址https://gitcode.com/gh_mirrors/or/OrchardCore点击查看免费下载相关推荐3 步本地跑通 Ryujinx源码编译 Switch 模拟器的最短路径3 步本地跑通 Ryujinx源码编译 Switch 模拟器的最短路径 你手上有一份 NSP 或 XCI 格式的 Switch 游戏而你需要的恰好不是官网打硬件仿真图形学Go Blueprint 实战ScyllaDB 健康检查端点/health的实现、配置与测试Go Blueprint 实战ScyllaDB 健康检查端点/health的实现、配置与测试 Go Blueprint 是一个通过交互式 CLI 快速生成开发工具CLI代码生成WinterJS 健康检查实现/health端点与监控集成WinterJS 健康检查实现/health端点与监控集成 为什么需要健康检查 你是否遇到过服务明明在运行却无法正常响应请求的情况或者部署新版本后如何上一篇OpenArkWindows系统安全检测的终极完整解决方案指南 ️下一篇cppcheck 的 suspiciousSemicolon 检查识别 if/for/while 后多余分号导致的危险空语句陷阱创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
