<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>就緒檢查 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E5%B0%B1%E7%B7%92%E6%AA%A2%E6%9F%A5/</link><description>Recent content in 就緒檢查 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 23 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E5%B0%B1%E7%B7%92%E6%AA%A2%E6%9F%A5/index.xml" rel="self" type="application/rss+xml"/><item><title>Readiness</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/readiness/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/readiness/</guid><description>&lt;p>Readiness 的核心概念是「instance 是否已準備好接收正式流量」。部署平台或 load balancer 會根據 readiness 訊號決定是否把 request 導到該 instance。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/redelivery-loop/" data-link-title="Redelivery Loop" data-link-desc="說明同一訊息反覆投遞失敗如何消耗 consumer 容量">Redelivery Loop&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Readiness 是 application 與平台之間的流量合約。Application 啟動成功只代表 process 存活；readiness 代表必要設定、連線、migration 狀態、背景初始化、cache warmup 或依賴檢查已達到接流量條件。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/redelivery-loop/" data-link-title="Redelivery Loop" data-link-desc="說明同一訊息反覆投遞失敗如何消耗 consumer 容量">Redelivery Loop&lt;/a>。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>系統需要 readiness 合約的訊號是部署或擴容期間出現短暫錯誤。常見情境包括 pod 剛啟動就接流量、service discovery 尚未更新、cache 還在 warming、資料庫連線池尚未建立、背景 worker 尚未完成初始化。&lt;/p>
&lt;h2 id="接近真實網路服務的例子">接近真實網路服務的例子&lt;/h2>
&lt;p>Kubernetes rolling update 建立新 pod 後，若 readiness 太早通過，新 pod 可能在還沒載入設定時接到 checkout request。正確的 readiness 會等必要依賴可用、設定載入完成、核心路由可處理後再開放流量。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Readiness endpoint 要反映接流量所需的最小條件，並且控制下游短暫波動對流量調度的影響。設計時要分清 readiness、liveness 與深度依賴檢查，讓平台能做穩定調度。&lt;/p></description><content:encoded><![CDATA[<p>Readiness 的核心概念是「instance 是否已準備好接收正式流量」。部署平台或 load balancer 會根據 readiness 訊號決定是否把 request 導到該 instance。 可先對照 <a href="/blog/backend/knowledge-cards/redelivery-loop/" data-link-title="Redelivery Loop" data-link-desc="說明同一訊息反覆投遞失敗如何消耗 consumer 容量">Redelivery Loop</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>Readiness 是 application 與平台之間的流量合約。Application 啟動成功只代表 process 存活；readiness 代表必要設定、連線、migration 狀態、背景初始化、cache warmup 或依賴檢查已達到接流量條件。 可先對照 <a href="/blog/backend/knowledge-cards/redelivery-loop/" data-link-title="Redelivery Loop" data-link-desc="說明同一訊息反覆投遞失敗如何消耗 consumer 容量">Redelivery Loop</a>。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>系統需要 readiness 合約的訊號是部署或擴容期間出現短暫錯誤。常見情境包括 pod 剛啟動就接流量、service discovery 尚未更新、cache 還在 warming、資料庫連線池尚未建立、背景 worker 尚未完成初始化。</p>
<h2 id="接近真實網路服務的例子">接近真實網路服務的例子</h2>
<p>Kubernetes rolling update 建立新 pod 後，若 readiness 太早通過，新 pod 可能在還沒載入設定時接到 checkout request。正確的 readiness 會等必要依賴可用、設定載入完成、核心路由可處理後再開放流量。</p>
<h2 id="設計責任">設計責任</h2>
<p>Readiness endpoint 要反映接流量所需的最小條件，並且控制下游短暫波動對流量調度的影響。設計時要分清 readiness、liveness 與深度依賴檢查，讓平台能做穩定調度。</p>
]]></content:encoded></item></channel></rss>