<?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>Admission-Control on Tarragon</title><link>https://tarrragon.github.io/blog/tags/admission-control/</link><description>Recent content in Admission-Control on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 02 Oct 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/admission-control/index.xml" rel="self" type="application/rss+xml"/><item><title>Admission Control（准入控制）</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/admission-control/</link><pubDate>Fri, 02 Oct 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/admission-control/</guid><description>&lt;p>Admission control（准入控制）的核心概念是「在請求進入受保護的路徑之前，決定誰能進入、什麼時候進入」。被擋下的使用者留在受保護的路徑外面等候，看到的是等候畫面或排隊位置，而不是錯誤。可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/load-shedding/" data-link-title="Load Shedding" data-link-desc="說明服務過載時如何主動拒絕低優先工作以保護核心能力">Load Shedding&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rate-limit/" data-link-title="Rate Limit" data-link-desc="說明限流如何保護服務入口、下游依賴與租戶公平性">Rate Limit&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>准入控制和負載卸除、限流處理的是同一個過載問題的不同位置。&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/load-shedding/" data-link-title="Load Shedding" data-link-desc="說明服務過載時如何主動拒絕低優先工作以保護核心能力">Load Shedding&lt;/a> 依整個系統的狀態，決定已經到達的請求要不要處理；&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rate-limit/" data-link-title="Rate Limit" data-link-desc="說明限流如何保護服務入口、下游依賴與租戶公平性">Rate Limit&lt;/a> 依送出請求的呼叫者分配配額；准入控制在請求到達受保護的路徑之前，決定一個人或一個會話能不能進入、排在第幾位。三者常一起出現：等候室放進受保護區的人數由准入控制決定，受保護區裡個別使用者的請求頻率由限流管，整體仍然過載時由負載卸除拒絕低優先的請求。&lt;/p>
&lt;p>服務過載的語境裡，這個詞也用在入口依系統狀態逐請求拒絕，例如 Envoy 的 admission control filter 依成功率拒絕請求；那個用法和 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/load-shedding/" data-link-title="Load Shedding" data-link-desc="說明服務過載時如何主動拒絕低優先工作以保護核心能力">Load Shedding&lt;/a> 重疊，本卡講的是以人或會話為單位的放行。這個詞在 Kubernetes 裡另有一個意思：admission controller 是 API server 在寫入物件之前檢查或改寫請求的外掛（例如 Gatekeeper、Kyverno）。那是設定治理的機制，和這張卡講的流量准入無關。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>需要准入控制的訊號是需求在一個時間點集中湧入、而且超過系統能承接的量，例如演唱會開賣、限量商品發售、新服務上線。常見的形態有四種：虛擬等候室（開賣前把請求導到另一頁，到時間依吞吐量放行，或只讓受保護區容納固定並發人數、其餘排隊）、waitlist（逐批邀請）、事前註冊（開賣前先驗證身分，只讓通過的人進入佇列）、抽籤（把先到先得改成隨機抽選，搶快就沒有優勢）。准入控制只決定誰能進入受保護的路徑，被擋下的人與機器人的請求仍然打在網站上，所以總流量要另外靠邊緣快取、WAF 與負載卸除吸收。案例與完整推導見 &lt;a href="https://tarrragon.github.io/blog/backend/09-performance-capacity/unplanned-traffic-surge/" data-link-title="9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路" data-link-desc="沒有準備窗口的瞬時大流量（突發流量、流量暴增）怎麼承接：依流量形狀分辨真人需求、應用層的濫用流量、體積型攻擊（DDoS），自動擴展的反應時間換算成緩衝，入口標記請求優先等級與負載卸除的順序，等候室與事前註冊這類准入控制，把體積型攻擊交給更大的邊緣網路，以及擴展跟不上時的退路">9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路&lt;/a> 的〈准入控制：虛擬等候室（virtual waiting room）、waitlist 與事前註冊〉，以及 &lt;a href="https://tarrragon.github.io/blog/backend/09-performance-capacity/cases/seatgeek-virtual-waiting-room/" data-link-title="9.C16 SeatGeek：DynamoDB &amp;#43; Lambda 打造的虛擬等候室" data-link-desc="SeatGeek 用 DynamoDB 4 張表 &amp;#43; Lambda Bouncer 實作 flash-sale 的准入控制（等候室）、取代第三方 waiting room 服務">SeatGeek：DynamoDB + Lambda 打造的虛擬等候室&lt;/a>。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>准入控制要定義放行的規則（先到先服務、依身分優先、隨機）、放行的速度（每分鐘多少人、受保護區的並發上限）、排隊者看到什麼，以及排隊本身的保護：等候室也是公開入口，前面要放 DDoS 防護與 WAF。事前註冊要能篩掉機器人，前提是註冊本身有成本或驗證；放行速度要和後端實際容量一起調整，太快會讓受保護區過載，太慢則讓可售的名額賣不完。&lt;/p></description><content:encoded><![CDATA[<p>Admission control（准入控制）的核心概念是「在請求進入受保護的路徑之前，決定誰能進入、什麼時候進入」。被擋下的使用者留在受保護的路徑外面等候，看到的是等候畫面或排隊位置，而不是錯誤。可先對照 <a href="/blog/backend/knowledge-cards/load-shedding/" data-link-title="Load Shedding" data-link-desc="說明服務過載時如何主動拒絕低優先工作以保護核心能力">Load Shedding</a> 與 <a href="/blog/backend/knowledge-cards/rate-limit/" data-link-title="Rate Limit" data-link-desc="說明限流如何保護服務入口、下游依賴與租戶公平性">Rate Limit</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>准入控制和負載卸除、限流處理的是同一個過載問題的不同位置。<a href="/blog/backend/knowledge-cards/load-shedding/" data-link-title="Load Shedding" data-link-desc="說明服務過載時如何主動拒絕低優先工作以保護核心能力">Load Shedding</a> 依整個系統的狀態，決定已經到達的請求要不要處理；<a href="/blog/backend/knowledge-cards/rate-limit/" data-link-title="Rate Limit" data-link-desc="說明限流如何保護服務入口、下游依賴與租戶公平性">Rate Limit</a> 依送出請求的呼叫者分配配額；准入控制在請求到達受保護的路徑之前，決定一個人或一個會話能不能進入、排在第幾位。三者常一起出現：等候室放進受保護區的人數由准入控制決定，受保護區裡個別使用者的請求頻率由限流管，整體仍然過載時由負載卸除拒絕低優先的請求。</p>
<p>服務過載的語境裡，這個詞也用在入口依系統狀態逐請求拒絕，例如 Envoy 的 admission control filter 依成功率拒絕請求；那個用法和 <a href="/blog/backend/knowledge-cards/load-shedding/" data-link-title="Load Shedding" data-link-desc="說明服務過載時如何主動拒絕低優先工作以保護核心能力">Load Shedding</a> 重疊，本卡講的是以人或會話為單位的放行。這個詞在 Kubernetes 裡另有一個意思：admission controller 是 API server 在寫入物件之前檢查或改寫請求的外掛（例如 Gatekeeper、Kyverno）。那是設定治理的機制，和這張卡講的流量准入無關。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>需要准入控制的訊號是需求在一個時間點集中湧入、而且超過系統能承接的量，例如演唱會開賣、限量商品發售、新服務上線。常見的形態有四種：虛擬等候室（開賣前把請求導到另一頁，到時間依吞吐量放行，或只讓受保護區容納固定並發人數、其餘排隊）、waitlist（逐批邀請）、事前註冊（開賣前先驗證身分，只讓通過的人進入佇列）、抽籤（把先到先得改成隨機抽選，搶快就沒有優勢）。准入控制只決定誰能進入受保護的路徑，被擋下的人與機器人的請求仍然打在網站上，所以總流量要另外靠邊緣快取、WAF 與負載卸除吸收。案例與完整推導見 <a href="/blog/backend/09-performance-capacity/unplanned-traffic-surge/" data-link-title="9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路" data-link-desc="沒有準備窗口的瞬時大流量（突發流量、流量暴增）怎麼承接：依流量形狀分辨真人需求、應用層的濫用流量、體積型攻擊（DDoS），自動擴展的反應時間換算成緩衝，入口標記請求優先等級與負載卸除的順序，等候室與事前註冊這類准入控制，把體積型攻擊交給更大的邊緣網路，以及擴展跟不上時的退路">9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路</a> 的〈准入控制：虛擬等候室（virtual waiting room）、waitlist 與事前註冊〉，以及 <a href="/blog/backend/09-performance-capacity/cases/seatgeek-virtual-waiting-room/" data-link-title="9.C16 SeatGeek：DynamoDB &#43; Lambda 打造的虛擬等候室" data-link-desc="SeatGeek 用 DynamoDB 4 張表 &#43; Lambda Bouncer 實作 flash-sale 的准入控制（等候室）、取代第三方 waiting room 服務">SeatGeek：DynamoDB + Lambda 打造的虛擬等候室</a>。</p>
<h2 id="設計責任">設計責任</h2>
<p>准入控制要定義放行的規則（先到先服務、依身分優先、隨機）、放行的速度（每分鐘多少人、受保護區的並發上限）、排隊者看到什麼，以及排隊本身的保護：等候室也是公開入口，前面要放 DDoS 防護與 WAF。事前註冊要能篩掉機器人，前提是註冊本身有成本或驗證；放行速度要和後端實際容量一起調整，太快會讓受保護區過載，太慢則讓可售的名額賣不完。</p>
]]></content:encoded></item></channel></rss>