后端微服务RPC框架模型推理服务人工智能【免费下载链接】jina☁️ Build multimodal AI applications with cloud-native stack项目地址https://gitcode.com/gh_mirrors/ji/jina点击查看免费下载当一个 Jina 编排Orchestration即 Deployment 或 Flow的所有组件完成加载、可以开始处理请求时它才被称为就绪ready。本文围绕 docs/concepts/orchestration/readiness.md 展开系统讲解就绪的判定标准以及通过编排对象 API、Jina-serve Client、CLI 和任意第三方 gRPC/HTTP/WebSocket 客户端四种方式探测就绪状态的完整方法。读完本文你将掌握在开发、部署与运维 Jina 服务时正确使用/dry_run探活接口的技能。什么是就绪就绪的判定标准在 Jina 中一个编排被标记为就绪ready需要满足以下条件对于Deployment其 Executor 已完全加载并就绪对于Flow其所有 Executors 和 Gateway 均已完全加载并就绪。只有满足上述条件后编排才能开始处理请求。就绪检测的核心手段是dry run试运行Gateway 会向编排图中的每一个 Executor 发送一个空的 Document 请求只有整条链路全部连通、每个 Executor 都能正常返回才算就绪。从源码可以印证这一机制Gateway 的 gRPC 服务在收到dry_run请求后会构造一个空的DocumentArray并以内部专用的 dry run 端点把请求流经整个编排图见 jina/serve/runtimes/gateway/request_handling.pyasync def dry_run(self, empty, context) - jina_pb2.StatusProto: self.logger.debug(recv a dry_run request) from jina._docarray import Document, DocumentArray from jina.serve.executors import __dry_run_endpoint__ da DocumentArray([Document()]) try: async for _ in self.streamer.stream_docs( docsda, exec_endpoint__dry_run_endpoint__, request_size1 ): pass status_message StatusMessage() status_message.set_code(jina_pb2.StatusProto.SUCCESS) return status_message.proto except Exception as ex: status_message StatusMessage() status_message.set_exception(ex) return status_message.proto即空文档成功走完整个图则返回StatusProto.SUCCESS任意环节异常如 Executor 进程掉线则捕获异常并返回错误状态。这正是后续所有就绪检测 API 在服务端的统一实现。就绪检测 API 总览Jina 提供了三层就绪检测入口~jina.Client与编排对象共享同一套探测语义编排对象 APIDeployment.is_deployment_ready()与Flow.is_flow_ready()旧名称dry_run已弃用Jina-serve Client APIClient.is_flow_ready()/Client.is_deployment_ready()CLIjina-serve ping executor|flow grpc://...。is_flow_ready返回True表示 Flow 就绪False表示未就绪。在 jina/clients/mixin.py 中HealthCheckMixin与AsyncHealthCheckMixin定义了同步/异步两个版本的is_flow_ready并统一将dry_run标记为is_flow_ready的弃用别名class HealthCheckMixin: The Health check Mixin for Client and Flow to expose dry_run API def is_flow_ready(self, **kwargs) - bool: return run_async(self.client._is_flow_ready, **kwargs) dry_run deprecate_by(is_flow_ready)通过编排对象检测就绪在 Python 脚本中可以直接调用编排对象上的就绪检测方法。注意编排存活期间与编排退出之后两种场景下返回值不同在with上下文中编排处于运行状态返回True退出上下文后服务已关闭自然返回False。Deployment 场景from jina import Deployment dep Deployment() with dep: print(dep.is_deployment_ready()) print(dep.is_deployment_ready())输出True FalseFlow 场景from jina import Flow f Flow.add() with f: print(f.is_flow_ready()) print(f.is_flow_ready())输出True False说明这里的Flow.add()是文档示例中的写法表示向 Flow 添加一个默认 Executor。实际项目中更常见的写法是Flow().add(...)或Flow(port12345).add()就绪检测语义完全一致。通过 Jina-serve Client 检测就绪编排与客户端常常运行在不同的进程、不同的机器上。此时可以用~jina.Client通过指定端口连接到正在运行的编排并调用就绪检测方法。先启动 Deployment 或 Flow 并使其阻塞运行block()Deployment 场景服务端进程一from jina import Deployment dep Deployment(port12345) with dep: dep.block()客户端进程二from jina import Client client Client(port12345) print(client.is_deployment_ready())输出TrueFlow 场景服务端进程一from jina import Flow f Flow(port12345).add() with f: f.block()客户端进程二from jina import Client client Client(port12345) print(client.is_flow_ready())输出True底层原理Client 如何探测就绪从源码看不同协议的 Client 通过各自的通信方式实现同一套语义见 jina/clients/base/grpc.py、jina/clients/base/http.py、jina/clients/base/websocket.pygRPC Client通过JinaGatewayDryRunRPCStub调用stub.dry_run(...)向{host}:{port}发起 dry run 调用检查返回的StatusProto是否为SUCCESSHTTP Client请求GET {host}:{port}/dry_run端点解析 JSON 响应中的code字段WebSocket Client同样以 dry run 语义进行探测。三者任一环节异常gRPC 的RpcError、HTTP 的非预期状态码等都会被捕获并记录日志最终统一返回False。通过 CLI 检测就绪除了代码调用还可以使用命令行工具jina-serve ping。其参数定义在 jina/parsers/ping.py参数说明默认值target探测目标类型flow/executor/gateway。其中executor与gateway检查单个服务的就绪状态flow检查完整微服务架构的连通性executorhost目标地址含端口如0.0.0.0:8000对 Flow/Gateway 可带协议前缀如http://0.0.0.0:8000缺省使用 grpc必填--timeout单次检查的超时时间毫秒-1表示永远等待3000--attempts执行就绪检查的次数1--min-successful-attempts成功退出exit(0)所需的最小成功检查次数1Deployment / Executor 场景先启动 Deployment 并阻塞运行from jina import Deployment dep Deployment(port12345) with dep: dep.block()再在另一个终端执行jina-serve ping executor grpc://localhost:12345成功输出每轮 ping 记录一次耗时最后汇总平均延迟INFO Jina-serve92877 ping grpc://localhost:12345 at 0 round... [09/08/22 12:58:13] INFO Jina-serve92877 ping grpc://localhost:12345 at 0 round takes 0 seconds (0.04s) INFO Jina-serve92877 ping grpc://localhost:12345 at 1 round... [09/08/22 12:58:14] INFO Jina-serve92877 ping grpc://localhost:12345 at 1 round takes 0 seconds (0.01s) INFO Jina-serve92877 ping grpc://localhost:12345 at 2 round... [09/08/22 12:58:15] INFO Jina-serve92877 ping grpc://localhost:12345 at 2 round takes 0 seconds (0.01s) INFO Jina-serve92877 ping grpc://localhost:12345 avg. latency: 24 ms [09/08/22 12:58:16]失败输出无法连接时反复重试默认重试 3 次间隔 1s最终统计消息丢失率INFO Jina-serve92986 ping grpc://localhost:12345 at 0 round... [09/08/22 12:59:00] ERROR GRPCClient92986 Error while getting response from grpc server AioRpcError of RPC that terminated with: status StatusCode.UNAVAILABLE details failed to connect to all addresses; last error: UNKNOWN: Failed to connect to remote host: Connection refused ... WARNI… Jina-serve92986 not responding, retry (1/3) in 1s INFO Jina-serve92986 ping grpc://localhost:12345 at 0 round takes 0 seconds (0.01s) ... WARNI… Jina-serve92986 not responding, retry (3/3) in 1s INFO Jina-serve92986 ping grpc://localhost:12345 at 2 round takes 0 seconds (0.02s) WARNI… Jina-serve92986 message lost 100% (3/3)Flow 场景from jina import Flow f Flow(port12345) with f: f.block()jina-serve ping flow grpc://localhost:12345成功与失败输出的格式与上例一致。CLI ping 的底层实现CLI 的 ping 由 jina/checker.py 中的NetworkChecker驱动当target为flow时它内部构造Client(hostargs.host)并调用is_flow_ready(timeouttimeout)即复用上一节 Client 的探测逻辑当target为executor/gateway时则通过parse_host_scheme解析协议与地址并调用BaseServer.is_ready(ctrl_address..., protocol...)做单点探活。每次探测按--attempts指定的轮数执行未达--min-successful-attempts时以非零码退出。使用第三方客户端检测就绪Jina 的就绪检测端点完全基于标准协议暴露因此你可以使用任何 gRPC / HTTP / WebSocket 客户端如grpcurl、curl来探测 Flow 状态无需依赖 Jina-serve Client。首先按对应协议启动编排并阻塞运行。文档示例以 gRPC 协议演示JINA_LOG_LEVELDEBUG用于在日志中确认 Executor 的 PIDDeployment 场景from jina import Deployment import os PROTOCOL grpc # it could also be http or websocket os.environ[ JINA_LOG_LEVEL ] DEBUG # this way we can check what is the PID of the Executor dep Deployment(protocolPROTOCOL, port12345) with dep: dep.block()⠋ Waiting ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0/0 -:--:--DEBUG gateway/rep-019075 adding connection for deployment executor0/heads/0 to grpc://0.0.0.0:12346 [05/31/22 18:10:16] DEBUG executor0/rep-019074 start listening on 0.0.0.0:12346 [05/31/22 18:10:16] DEBUG gateway/rep-019075 start server bound to 0.0.0.0:12345 [05/31/22 18:10:17] DEBUG executor0/rep-019059 ready and listening [05/31/22 18:10:17] DEBUG gateway/rep-019059 ready and listening [05/31/22 18:10:17] ╭─── Deployment is ready to serve! ───╮ │ Protocol GRPC │ │ Local 0.0.0.0:12345 │ │ Private 192.168.1.13:12345 │ ╰────────────────────────────────────────╯ DEBUG Deployment19059 2 Deployments (i.e. 2 Pods) are running in this DeploymentFlow 场景from jina import Flow import os PROTOCOL grpc # it could also be http or websocket os.environ[ JINA_LOG_LEVEL ] DEBUG # this way we can check what is the PID of the Executor f Flow(protocolPROTOCOL, port12345).add() with f: f.block()⠋ Waiting ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0/0 -:--:--DEBUG gateway/rep-019075 adding connection for deployment executor0/heads/0 to grpc://0.0.0.0:12346 [05/31/22 18:10:16] DEBUG executor0/rep-019074 start listening on 0.0.0.0:12346 [05/31/22 18:10:16] DEBUG gateway/rep-019075 start server bound to 0.0.0.0:12345 [05/31/22 18:10:17] DEBUG executor0/rep-019059 ready and listening [05/31/22 18:10:17] DEBUG gateway/rep-019059 ready and listening [05/31/22 18:10:17] ╭────── Flow is ready to serve! ──────╮ │ Protocol GRPC │ │ Local 0.0.0.0:12345 │ │ Private 192.168.1.13:12345 │ ╰────────────────────────────────────────╯ DEBUG Flow19059 2 Deployments (i.e. 2 Pods) are running in this Flow日志中出现的19059等数字即为相应组件的 PID后续故障演练会用到。使用 gRPCgrpcurl 调用 dry_run当 Gateway 协议为 gRPC 时可以使用grpcurl调用负责上报编排状态的 Gateway gRPC 服务。首先拉取镜像并调用 dry_run 方法docker pull fullstorydev/grpcurl:latest docker run --networkhost fullstorydev/grpcurl -plaintext 127.0.0.1:12345 jina.JinaGatewayDryRunRPC/dry_run无错误的输出空 JSON 对象即表示编排运行正常{}jina.JinaGatewayDryRunRPC/dry_run正是上一节 gRPC Client 内部JinaGatewayDryRunRPCStub所调用的同一服务方法见 jina/serve/runtimes/gateway/request_handling.py。故障演练通过kill -9模拟 Executor 掉线上例日志中 Executor 的 PID 为 19059kill -9 $EXECUTOR_PID # in this case we can see in the logs that it is 19059再次执行同样的 dry_run 调用将返回错误docker run --networkhost fullstorydev/grpcurl -plaintext 127.0.0.1:12345 jina.JinaGatewayDryRunRPC/dry_run错误输出可展开查看{ code: ERROR, description: failed to connect to all addresses |Gateway: Communication error with deployment at address(es) 0.0.0.0:12346. Head or worker(s) may be down., exception: { name: InternalNetworkError, args: [ failed to connect to all addresses |Gateway: Communication error with deployment at address(es) 0.0.0.0:12346. Head or worker(s) may be down. ], stacks: [ Traceback (most recent call last):\n, File \/home/joan/jina/jina/jina/serve/networking.py\, line 750, in task_wrapper\n timeouttimeout,\n, File \/home/joan/jina/jina/jina/serve/networking.py\, line 197, in send_discover_endpoint\n await self._init_stubs()\n, ... jina.excepts.InternalNetworkError: failed to connect to all addresses |Gateway: Communication error with deployment at address(es) 0.0.0.0:12346. Head or worker(s) may be down.\n ] } }从堆栈可以看到错误源于 Gateway 在向 Executor 地址0.0.0.0:12346发送请求时连接失败抛出jina.excepts.InternalNetworkError最终被转换为StatusProto中的异常信息返回。这也是dry run 会真正打到每一个 Executor的直观证据。使用 HTTP 或 WebSocketcurl 访问 /dry_run当 Gateway 协议为 HTTP 或 WebSocket 时用curl直接访问/dry_run端点即可获得 Flow 状态curl http://localhost:12345/dry_run无错误的输出表示 Flow 运行正常{code:0,description:,exception:null}该端点在 HTTP Gateway 中的实现见 jina/serve/runtimes/gateway/http_fastapi_app.pyFastAPIGET /dry_runWebSocket 版本见 jina/serve/runtimes/gateway/websocket_fastapi_app.py。两者都会向完整编排发送一个空DocumentArray以验证连通性。故障演练同样先杀掉 Executorkill -9 $EXECUTOR_PID # in this case we can see in the logs that it is 19059再次请求/dry_run返回错误{code:1,description:failed to connect to all addresses |Gateway: Communication error with deployment executor0 at address(es) {0.0.0.0:12346}. Head or worker(s) may be down.,exception:{name:InternalNetworkError,args:[failed to connect to all addresses |Gateway: Communication error with deployment executor0 at address(es) {0.0.0.0:12346}. Head or worker(s) may be down.],stacks:[Traceback (most recent call last):\n,...],executor:}}对比两次响应可知就绪时code为0、description为空、exception为null未就绪时code为1并携带完整的异常名称、参数与堆栈信息。注意此处的code直接对应StatusProto中的枚举值SUCCESS为 0。就绪检测的适用场景与注意事项编排级 vs 单点探活jina-serve ping flow与Client.is_flow_ready检测的是整条服务链路的连通性dry run 全链路jina-serve ping executor/ping gateway与BaseServer.is_ready只检测单个服务的可达性。生产环境做滚动发布、灰度切换时应先做单点探活再对整条链路做编排级就绪检查。返回值语义所有就绪检测 API 均返回布尔值——就绪为True未就绪为False。CLI 则通过进程退出码表达结果成功退出码为 0便于在脚本中直接判断。重试与超时CLI 支持--timeout单次超时毫秒、--attempts检查轮数与--min-successful-attempts成功退出所需的最小成功次数三个参数适合作为容器健康检查health check的探针命令。探活是真实请求dry run 会构造一个空 Document 并真实流经编排图中的所有 Executor因此 Executor 的__dry_run_endpoint__必须可响应若你的 Executor 在__init__后还需要额外初始化如加载大模型、连接外部存储请确保其已就绪后再对外暴露服务。日志级别辅助排查设置JINA_LOG_LEVELDEBUG可以看到各组件gateway / executor / head的启动、绑定端口与ready and listening日志并借此获取组件的 PID便于定位与故障演练。参考与延伸阅读就绪检测完整文档docs/concepts/orchestration/readiness.md编排概念总览Flow / Deployment / Gateway 的关系docs/concepts/orchestration/index.mdFlow 详细用法docs/concepts/orchestration/flow.mdDeployment 详细用法docs/concepts/orchestration/deployment.md健康检查liveness与探活参数的差异docs/concepts/orchestration/health-check.mdClient 就绪检测实现jina/clients/mixin.py、jina/clients/base/grpc.py、jina/clients/base/http.pyGateway dry_run 服务端实现jina/serve/runtimes/gateway/request_handling.py、jina/serve/runtimes/gateway/http_fastapi_app.pyCLI ping 解析与执行jina/parsers/ping.py、jina/checker.py赞分享后端微服务RPC框架模型推理服务人工智能【免费下载链接】jina☁️ Build multimodal AI applications with cloud-native stack项目地址https://gitcode.com/gh_mirrors/ji/jina点击查看免费下载相关推荐Kubernetes Production Readiness ReviewPRR全流程指南从 KEP 提交到生产就绪审批Kubernetes Production Readiness ReviewPRR全流程指南从 KEP 提交到生产就绪审批 导读 本文基于 Kuberne开源治理文档研发协作Docker-Zulip高级配置自定义settings.py与集成外部服务的实用技巧Docker Zulip高级配置自定义settings.py与集成外部服务的实用技巧 Docker Zulip是一个强大的容器化配置项目帮助用户轻松部署和管后端即时通讯运维PostHog 前端 QA 实战指南开发堆栈就绪检查Stack Readiness与登录Login流程PostHog 前端 QA 实战指南开发堆栈就绪检查Stack Readiness与登录Login流程 本篇技术指南以 PostHog 仓库内 qa数据分析后端前端数据可视化大数据上一篇Mattermost Desktop核心功能深度解析服务器管理、桌面通知与深度链接下一篇ofdrw性能优化处理大型OFD文档的5个实用技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Jina 就绪检测（Readiness）完全指南：从 `is_flow_ready` 到 `/dry_run` 探活
后端微服务RPC框架模型推理服务人工智能【免费下载链接】jina☁️ Build multimodal AI applications with cloud-native stack项目地址https://gitcode.com/gh_mirrors/ji/jina点击查看免费下载当一个 Jina 编排Orchestration即 Deployment 或 Flow的所有组件完成加载、可以开始处理请求时它才被称为就绪ready。本文围绕 docs/concepts/orchestration/readiness.md 展开系统讲解就绪的判定标准以及通过编排对象 API、Jina-serve Client、CLI 和任意第三方 gRPC/HTTP/WebSocket 客户端四种方式探测就绪状态的完整方法。读完本文你将掌握在开发、部署与运维 Jina 服务时正确使用/dry_run探活接口的技能。什么是就绪就绪的判定标准在 Jina 中一个编排被标记为就绪ready需要满足以下条件对于Deployment其 Executor 已完全加载并就绪对于Flow其所有 Executors 和 Gateway 均已完全加载并就绪。只有满足上述条件后编排才能开始处理请求。就绪检测的核心手段是dry run试运行Gateway 会向编排图中的每一个 Executor 发送一个空的 Document 请求只有整条链路全部连通、每个 Executor 都能正常返回才算就绪。从源码可以印证这一机制Gateway 的 gRPC 服务在收到dry_run请求后会构造一个空的DocumentArray并以内部专用的 dry run 端点把请求流经整个编排图见 jina/serve/runtimes/gateway/request_handling.pyasync def dry_run(self, empty, context) - jina_pb2.StatusProto: self.logger.debug(recv a dry_run request) from jina._docarray import Document, DocumentArray from jina.serve.executors import __dry_run_endpoint__ da DocumentArray([Document()]) try: async for _ in self.streamer.stream_docs( docsda, exec_endpoint__dry_run_endpoint__, request_size1 ): pass status_message StatusMessage() status_message.set_code(jina_pb2.StatusProto.SUCCESS) return status_message.proto except Exception as ex: status_message StatusMessage() status_message.set_exception(ex) return status_message.proto即空文档成功走完整个图则返回StatusProto.SUCCESS任意环节异常如 Executor 进程掉线则捕获异常并返回错误状态。这正是后续所有就绪检测 API 在服务端的统一实现。就绪检测 API 总览Jina 提供了三层就绪检测入口~jina.Client与编排对象共享同一套探测语义编排对象 APIDeployment.is_deployment_ready()与Flow.is_flow_ready()旧名称dry_run已弃用Jina-serve Client APIClient.is_flow_ready()/Client.is_deployment_ready()CLIjina-serve ping executor|flow grpc://...。is_flow_ready返回True表示 Flow 就绪False表示未就绪。在 jina/clients/mixin.py 中HealthCheckMixin与AsyncHealthCheckMixin定义了同步/异步两个版本的is_flow_ready并统一将dry_run标记为is_flow_ready的弃用别名class HealthCheckMixin: The Health check Mixin for Client and Flow to expose dry_run API def is_flow_ready(self, **kwargs) - bool: return run_async(self.client._is_flow_ready, **kwargs) dry_run deprecate_by(is_flow_ready)通过编排对象检测就绪在 Python 脚本中可以直接调用编排对象上的就绪检测方法。注意编排存活期间与编排退出之后两种场景下返回值不同在with上下文中编排处于运行状态返回True退出上下文后服务已关闭自然返回False。Deployment 场景from jina import Deployment dep Deployment() with dep: print(dep.is_deployment_ready()) print(dep.is_deployment_ready())输出True FalseFlow 场景from jina import Flow f Flow.add() with f: print(f.is_flow_ready()) print(f.is_flow_ready())输出True False说明这里的Flow.add()是文档示例中的写法表示向 Flow 添加一个默认 Executor。实际项目中更常见的写法是Flow().add(...)或Flow(port12345).add()就绪检测语义完全一致。通过 Jina-serve Client 检测就绪编排与客户端常常运行在不同的进程、不同的机器上。此时可以用~jina.Client通过指定端口连接到正在运行的编排并调用就绪检测方法。先启动 Deployment 或 Flow 并使其阻塞运行block()Deployment 场景服务端进程一from jina import Deployment dep Deployment(port12345) with dep: dep.block()客户端进程二from jina import Client client Client(port12345) print(client.is_deployment_ready())输出TrueFlow 场景服务端进程一from jina import Flow f Flow(port12345).add() with f: f.block()客户端进程二from jina import Client client Client(port12345) print(client.is_flow_ready())输出True底层原理Client 如何探测就绪从源码看不同协议的 Client 通过各自的通信方式实现同一套语义见 jina/clients/base/grpc.py、jina/clients/base/http.py、jina/clients/base/websocket.pygRPC Client通过JinaGatewayDryRunRPCStub调用stub.dry_run(...)向{host}:{port}发起 dry run 调用检查返回的StatusProto是否为SUCCESSHTTP Client请求GET {host}:{port}/dry_run端点解析 JSON 响应中的code字段WebSocket Client同样以 dry run 语义进行探测。三者任一环节异常gRPC 的RpcError、HTTP 的非预期状态码等都会被捕获并记录日志最终统一返回False。通过 CLI 检测就绪除了代码调用还可以使用命令行工具jina-serve ping。其参数定义在 jina/parsers/ping.py参数说明默认值target探测目标类型flow/executor/gateway。其中executor与gateway检查单个服务的就绪状态flow检查完整微服务架构的连通性executorhost目标地址含端口如0.0.0.0:8000对 Flow/Gateway 可带协议前缀如http://0.0.0.0:8000缺省使用 grpc必填--timeout单次检查的超时时间毫秒-1表示永远等待3000--attempts执行就绪检查的次数1--min-successful-attempts成功退出exit(0)所需的最小成功检查次数1Deployment / Executor 场景先启动 Deployment 并阻塞运行from jina import Deployment dep Deployment(port12345) with dep: dep.block()再在另一个终端执行jina-serve ping executor grpc://localhost:12345成功输出每轮 ping 记录一次耗时最后汇总平均延迟INFO Jina-serve92877 ping grpc://localhost:12345 at 0 round... [09/08/22 12:58:13] INFO Jina-serve92877 ping grpc://localhost:12345 at 0 round takes 0 seconds (0.04s) INFO Jina-serve92877 ping grpc://localhost:12345 at 1 round... [09/08/22 12:58:14] INFO Jina-serve92877 ping grpc://localhost:12345 at 1 round takes 0 seconds (0.01s) INFO Jina-serve92877 ping grpc://localhost:12345 at 2 round... [09/08/22 12:58:15] INFO Jina-serve92877 ping grpc://localhost:12345 at 2 round takes 0 seconds (0.01s) INFO Jina-serve92877 ping grpc://localhost:12345 avg. latency: 24 ms [09/08/22 12:58:16]失败输出无法连接时反复重试默认重试 3 次间隔 1s最终统计消息丢失率INFO Jina-serve92986 ping grpc://localhost:12345 at 0 round... [09/08/22 12:59:00] ERROR GRPCClient92986 Error while getting response from grpc server AioRpcError of RPC that terminated with: status StatusCode.UNAVAILABLE details failed to connect to all addresses; last error: UNKNOWN: Failed to connect to remote host: Connection refused ... WARNI… Jina-serve92986 not responding, retry (1/3) in 1s INFO Jina-serve92986 ping grpc://localhost:12345 at 0 round takes 0 seconds (0.01s) ... WARNI… Jina-serve92986 not responding, retry (3/3) in 1s INFO Jina-serve92986 ping grpc://localhost:12345 at 2 round takes 0 seconds (0.02s) WARNI… Jina-serve92986 message lost 100% (3/3)Flow 场景from jina import Flow f Flow(port12345) with f: f.block()jina-serve ping flow grpc://localhost:12345成功与失败输出的格式与上例一致。CLI ping 的底层实现CLI 的 ping 由 jina/checker.py 中的NetworkChecker驱动当target为flow时它内部构造Client(hostargs.host)并调用is_flow_ready(timeouttimeout)即复用上一节 Client 的探测逻辑当target为executor/gateway时则通过parse_host_scheme解析协议与地址并调用BaseServer.is_ready(ctrl_address..., protocol...)做单点探活。每次探测按--attempts指定的轮数执行未达--min-successful-attempts时以非零码退出。使用第三方客户端检测就绪Jina 的就绪检测端点完全基于标准协议暴露因此你可以使用任何 gRPC / HTTP / WebSocket 客户端如grpcurl、curl来探测 Flow 状态无需依赖 Jina-serve Client。首先按对应协议启动编排并阻塞运行。文档示例以 gRPC 协议演示JINA_LOG_LEVELDEBUG用于在日志中确认 Executor 的 PIDDeployment 场景from jina import Deployment import os PROTOCOL grpc # it could also be http or websocket os.environ[ JINA_LOG_LEVEL ] DEBUG # this way we can check what is the PID of the Executor dep Deployment(protocolPROTOCOL, port12345) with dep: dep.block()⠋ Waiting ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0/0 -:--:--DEBUG gateway/rep-019075 adding connection for deployment executor0/heads/0 to grpc://0.0.0.0:12346 [05/31/22 18:10:16] DEBUG executor0/rep-019074 start listening on 0.0.0.0:12346 [05/31/22 18:10:16] DEBUG gateway/rep-019075 start server bound to 0.0.0.0:12345 [05/31/22 18:10:17] DEBUG executor0/rep-019059 ready and listening [05/31/22 18:10:17] DEBUG gateway/rep-019059 ready and listening [05/31/22 18:10:17] ╭─── Deployment is ready to serve! ───╮ │ Protocol GRPC │ │ Local 0.0.0.0:12345 │ │ Private 192.168.1.13:12345 │ ╰────────────────────────────────────────╯ DEBUG Deployment19059 2 Deployments (i.e. 2 Pods) are running in this DeploymentFlow 场景from jina import Flow import os PROTOCOL grpc # it could also be http or websocket os.environ[ JINA_LOG_LEVEL ] DEBUG # this way we can check what is the PID of the Executor f Flow(protocolPROTOCOL, port12345).add() with f: f.block()⠋ Waiting ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0/0 -:--:--DEBUG gateway/rep-019075 adding connection for deployment executor0/heads/0 to grpc://0.0.0.0:12346 [05/31/22 18:10:16] DEBUG executor0/rep-019074 start listening on 0.0.0.0:12346 [05/31/22 18:10:16] DEBUG gateway/rep-019075 start server bound to 0.0.0.0:12345 [05/31/22 18:10:17] DEBUG executor0/rep-019059 ready and listening [05/31/22 18:10:17] DEBUG gateway/rep-019059 ready and listening [05/31/22 18:10:17] ╭────── Flow is ready to serve! ──────╮ │ Protocol GRPC │ │ Local 0.0.0.0:12345 │ │ Private 192.168.1.13:12345 │ ╰────────────────────────────────────────╯ DEBUG Flow19059 2 Deployments (i.e. 2 Pods) are running in this Flow日志中出现的19059等数字即为相应组件的 PID后续故障演练会用到。使用 gRPCgrpcurl 调用 dry_run当 Gateway 协议为 gRPC 时可以使用grpcurl调用负责上报编排状态的 Gateway gRPC 服务。首先拉取镜像并调用 dry_run 方法docker pull fullstorydev/grpcurl:latest docker run --networkhost fullstorydev/grpcurl -plaintext 127.0.0.1:12345 jina.JinaGatewayDryRunRPC/dry_run无错误的输出空 JSON 对象即表示编排运行正常{}jina.JinaGatewayDryRunRPC/dry_run正是上一节 gRPC Client 内部JinaGatewayDryRunRPCStub所调用的同一服务方法见 jina/serve/runtimes/gateway/request_handling.py。故障演练通过kill -9模拟 Executor 掉线上例日志中 Executor 的 PID 为 19059kill -9 $EXECUTOR_PID # in this case we can see in the logs that it is 19059再次执行同样的 dry_run 调用将返回错误docker run --networkhost fullstorydev/grpcurl -plaintext 127.0.0.1:12345 jina.JinaGatewayDryRunRPC/dry_run错误输出可展开查看{ code: ERROR, description: failed to connect to all addresses |Gateway: Communication error with deployment at address(es) 0.0.0.0:12346. Head or worker(s) may be down., exception: { name: InternalNetworkError, args: [ failed to connect to all addresses |Gateway: Communication error with deployment at address(es) 0.0.0.0:12346. Head or worker(s) may be down. ], stacks: [ Traceback (most recent call last):\n, File \/home/joan/jina/jina/jina/serve/networking.py\, line 750, in task_wrapper\n timeouttimeout,\n, File \/home/joan/jina/jina/jina/serve/networking.py\, line 197, in send_discover_endpoint\n await self._init_stubs()\n, ... jina.excepts.InternalNetworkError: failed to connect to all addresses |Gateway: Communication error with deployment at address(es) 0.0.0.0:12346. Head or worker(s) may be down.\n ] } }从堆栈可以看到错误源于 Gateway 在向 Executor 地址0.0.0.0:12346发送请求时连接失败抛出jina.excepts.InternalNetworkError最终被转换为StatusProto中的异常信息返回。这也是dry run 会真正打到每一个 Executor的直观证据。使用 HTTP 或 WebSocketcurl 访问 /dry_run当 Gateway 协议为 HTTP 或 WebSocket 时用curl直接访问/dry_run端点即可获得 Flow 状态curl http://localhost:12345/dry_run无错误的输出表示 Flow 运行正常{code:0,description:,exception:null}该端点在 HTTP Gateway 中的实现见 jina/serve/runtimes/gateway/http_fastapi_app.pyFastAPIGET /dry_runWebSocket 版本见 jina/serve/runtimes/gateway/websocket_fastapi_app.py。两者都会向完整编排发送一个空DocumentArray以验证连通性。故障演练同样先杀掉 Executorkill -9 $EXECUTOR_PID # in this case we can see in the logs that it is 19059再次请求/dry_run返回错误{code:1,description:failed to connect to all addresses |Gateway: Communication error with deployment executor0 at address(es) {0.0.0.0:12346}. Head or worker(s) may be down.,exception:{name:InternalNetworkError,args:[failed to connect to all addresses |Gateway: Communication error with deployment executor0 at address(es) {0.0.0.0:12346}. Head or worker(s) may be down.],stacks:[Traceback (most recent call last):\n,...],executor:}}对比两次响应可知就绪时code为0、description为空、exception为null未就绪时code为1并携带完整的异常名称、参数与堆栈信息。注意此处的code直接对应StatusProto中的枚举值SUCCESS为 0。就绪检测的适用场景与注意事项编排级 vs 单点探活jina-serve ping flow与Client.is_flow_ready检测的是整条服务链路的连通性dry run 全链路jina-serve ping executor/ping gateway与BaseServer.is_ready只检测单个服务的可达性。生产环境做滚动发布、灰度切换时应先做单点探活再对整条链路做编排级就绪检查。返回值语义所有就绪检测 API 均返回布尔值——就绪为True未就绪为False。CLI 则通过进程退出码表达结果成功退出码为 0便于在脚本中直接判断。重试与超时CLI 支持--timeout单次超时毫秒、--attempts检查轮数与--min-successful-attempts成功退出所需的最小成功次数三个参数适合作为容器健康检查health check的探针命令。探活是真实请求dry run 会构造一个空 Document 并真实流经编排图中的所有 Executor因此 Executor 的__dry_run_endpoint__必须可响应若你的 Executor 在__init__后还需要额外初始化如加载大模型、连接外部存储请确保其已就绪后再对外暴露服务。日志级别辅助排查设置JINA_LOG_LEVELDEBUG可以看到各组件gateway / executor / head的启动、绑定端口与ready and listening日志并借此获取组件的 PID便于定位与故障演练。参考与延伸阅读就绪检测完整文档docs/concepts/orchestration/readiness.md编排概念总览Flow / Deployment / Gateway 的关系docs/concepts/orchestration/index.mdFlow 详细用法docs/concepts/orchestration/flow.mdDeployment 详细用法docs/concepts/orchestration/deployment.md健康检查liveness与探活参数的差异docs/concepts/orchestration/health-check.mdClient 就绪检测实现jina/clients/mixin.py、jina/clients/base/grpc.py、jina/clients/base/http.pyGateway dry_run 服务端实现jina/serve/runtimes/gateway/request_handling.py、jina/serve/runtimes/gateway/http_fastapi_app.pyCLI ping 解析与执行jina/parsers/ping.py、jina/checker.py赞分享后端微服务RPC框架模型推理服务人工智能【免费下载链接】jina☁️ Build multimodal AI applications with cloud-native stack项目地址https://gitcode.com/gh_mirrors/ji/jina点击查看免费下载相关推荐Kubernetes Production Readiness ReviewPRR全流程指南从 KEP 提交到生产就绪审批Kubernetes Production Readiness ReviewPRR全流程指南从 KEP 提交到生产就绪审批 导读 本文基于 Kuberne开源治理文档研发协作Docker-Zulip高级配置自定义settings.py与集成外部服务的实用技巧Docker Zulip高级配置自定义settings.py与集成外部服务的实用技巧 Docker Zulip是一个强大的容器化配置项目帮助用户轻松部署和管后端即时通讯运维PostHog 前端 QA 实战指南开发堆栈就绪检查Stack Readiness与登录Login流程PostHog 前端 QA 实战指南开发堆栈就绪检查Stack Readiness与登录Login流程 本篇技术指南以 PostHog 仓库内 qa数据分析后端前端数据可视化大数据上一篇Mattermost Desktop核心功能深度解析服务器管理、桌面通知与深度链接下一篇ofdrw性能优化处理大型OFD文档的5个实用技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
