<?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>Service Registry on Tarragon</title><link>https://tarrragon.github.io/blog/tags/service-registry/</link><description>Recent content in Service Registry on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 24 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/service-registry/index.xml" rel="self" type="application/rss+xml"/><item><title>Service Registry</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/service-registry/</link><pubDate>Fri, 24 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/service-registry/</guid><description>&lt;p>Service Registry 的核心概念是「保存目前可用服務實例的位址、狀態與 metadata，供 discovery、load balancer 或內部呼叫查找」。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/session-invalidation/" data-link-title="Session Invalidation" data-link-desc="說明事件後如何讓既有會話失效，避免被重放或延續利用">Session Invalidation&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Service Registry 位在 deployment platform、health check、service discovery 與 load balancing 之間。它負責維持「目前有哪些實例可用」這份資料。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/session-invalidation/" data-link-title="Session Invalidation" data-link-desc="說明事件後如何讓既有會話失效，避免被重放或延續利用">Session Invalidation&lt;/a>。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>系統需要 service registry 的訊號是：&lt;/p>
&lt;ul>
&lt;li>服務實例會動態擴縮&lt;/li>
&lt;li>instance 需要在啟動後自動登錄&lt;/li>
&lt;li>instance 失效時要自動摘除&lt;/li>
&lt;li>呼叫端需要依據 metadata 找到合適實例&lt;/li>
&lt;/ul>
&lt;h2 id="接近真實網路服務的例子">接近真實網路服務的例子&lt;/h2>
&lt;p>Kubernetes 會把 pod、labels 與 endpoint 維持成可查找狀態；service mesh 會用 registry 資料決定流量要導向哪個 instance；服務縮容時若 registry 沒有及時摘除舊實例，呼叫端就可能打到已下線節點。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Service Registry 要定義註冊來源、heartbeat 或 TTL、失效摘除條件、metadata 結構與回復方式。它的重點是讓查找方拿到可信且更新的實例資料。&lt;/p></description><content:encoded><![CDATA[<p>Service Registry 的核心概念是「保存目前可用服務實例的位址、狀態與 metadata，供 discovery、load balancer 或內部呼叫查找」。 可先對照 <a href="/blog/backend/knowledge-cards/session-invalidation/" data-link-title="Session Invalidation" data-link-desc="說明事件後如何讓既有會話失效，避免被重放或延續利用">Session Invalidation</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>Service Registry 位在 deployment platform、health check、service discovery 與 load balancing 之間。它負責維持「目前有哪些實例可用」這份資料。 可先對照 <a href="/blog/backend/knowledge-cards/session-invalidation/" data-link-title="Session Invalidation" data-link-desc="說明事件後如何讓既有會話失效，避免被重放或延續利用">Session Invalidation</a>。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>系統需要 service registry 的訊號是：</p>
<ul>
<li>服務實例會動態擴縮</li>
<li>instance 需要在啟動後自動登錄</li>
<li>instance 失效時要自動摘除</li>
<li>呼叫端需要依據 metadata 找到合適實例</li>
</ul>
<h2 id="接近真實網路服務的例子">接近真實網路服務的例子</h2>
<p>Kubernetes 會把 pod、labels 與 endpoint 維持成可查找狀態；service mesh 會用 registry 資料決定流量要導向哪個 instance；服務縮容時若 registry 沒有及時摘除舊實例，呼叫端就可能打到已下線節點。</p>
<h2 id="設計責任">設計責任</h2>
<p>Service Registry 要定義註冊來源、heartbeat 或 TTL、失效摘除條件、metadata 結構與回復方式。它的重點是讓查找方拿到可信且更新的實例資料。</p>
]]></content:encoded></item></channel></rss>