system design 101
1.0.0
【 ?? YouTube | ？通訊】
使用視覺效果和簡單術語解釋複雜的系統。
無論您是準備系統設計面試，還是只是想了解系統在底層如何運作，我們希望這個儲存庫能夠幫助您實現這一目標。
架構風格定義了應用程式介面 (API) 的不同元件如何相互互動。因此，它們透過提供設計和建構 API 的標準方法來確保效率、可靠性以及與其他系統整合的便利性。以下是最常用的樣式：
肥皂：
成熟、全面、基於 XML
最適合企業應用
寧靜：
流行的、易於實現的 HTTP 方法
網路服務的理想選擇
圖形語言：
查詢語言，請求特定數據
減少網路開銷，加快回應速度
遠程過程呼叫：
現代、高效能協定緩衝區
適合微服務架構
網路套接字：
即時、雙向、持久連接
非常適合低延遲資料交換
網路鉤子：
事件驅動、HTTP 回呼、非同步
事件發生時通知系統
在 API 設計方面，REST 和 GraphQL 各有優缺點。
下圖顯示了 REST 和 GraphQL 之間的快速比較。
休息
GraphQL
REST 和 GraphQL 之間的最佳選擇取決於應用程式和開發團隊的特定要求。 GraphQL 非常適合複雜或頻繁變化的前端需求，而 REST 適合首選簡單且一致的合約的應用程式。
這兩種 API 方法都不是靈丹妙藥。仔細評估要求和權衡對於選擇正確的風格非常重要。 REST 和 GraphQL 都是公開資料和支援現代應用程式的有效選項。
RPC（Remote procedure Call）之所以被稱為“遠端”，是因為在微服務架構下，當服務部署到不同的伺服器時，它可以實現遠端服務之間的通訊。從使用者的角度來看，它的作用就像是本地函數呼叫。
下圖說明了gRPC的整體資料流。
步驟 1：從客戶端發出 REST 呼叫。請求正文通常為 JSON 格式。
步驟 2 - 4：訂單服務（gRPC 用戶端）接收 REST 調用，對其進行轉換，並對支付服務進行 RPC 調用。 gRPC 將客戶端存根編碼為二進位格式並將其傳送至低階傳輸層。
步驟 5：gRPC 透過 HTTP2 透過網路傳送封包。由於二進位編碼和網路最佳化，gRPC 據說比 JSON 快 5 倍。
步驟 6 - 8：支付服務（gRPC 伺服器）從網路接收資料包，對其進行解碼，然後呼叫伺服器應用程式。
步驟 9 - 11：結果從伺服器應用程式返回，經過編碼後發送到傳輸層。
步驟 12 - 14：訂單服務接收資料包，對其進行解碼，並將結果傳送至客戶端應用程式。
下圖顯示了輪詢和 Webhook 之間的比較。
假設我們經營一個電子商務網站。客戶端透過API網關向訂單服務發送訂單，訂單服務再到支付服務進行支付交易。然後，支付服務與外部支付服務提供者 (PSP) 對話以完成交易。
有兩種方法可以處理與外部 PSP 的通訊。
1. 短輪詢
支付服務向PSP發送付款請求後，不斷向PSP詢問付款狀態。經過幾輪之後，PSP終於回到狀態。
短輪詢有兩個缺點：
2. 網路鉤子
我們可以向外部服務註冊一個 webhook。這意味著：當您有請求更新時，透過某個 URL 給我回電。當 PSP 完成處理後，它將呼叫 HTTP 請求來更新付款狀態。
這樣就改變了程式設計範式，支付服務不再需要浪費資源來輪詢付款狀態。
如果 PSP 不回電怎麼辦？我們可以設定一個內務工作來每小時檢查付款狀態。
Webhooks 通常稱為反向 API 或推送 API，因為伺服器會向客戶端發送 HTTP 請求。使用webhook時我們要注意3件事：
下圖顯示了提高 API 效能的 5 個常見技巧。
分頁
當結果很大時，這是一種常見的最佳化。結果會流回客戶端以提高服務回應能力。
非同步日誌記錄
同步日誌記錄每次呼叫都會處理磁碟，並且會降低系統速度。非同步日誌記錄首先將日誌傳送到無鎖緩衝區並立即傳回。日誌將定期刷新到磁碟。這顯著減少了 I/O 開銷。
快取
我們可以將經常存取的資料儲存到快取中。客戶端可以先查詢緩存，而不是直接存取資料庫。如果快取未命中，用戶端可以從資料庫中查詢。像Redis這樣的快取將資料儲存在記憶體中，因此資料存取比資料庫快得多。
有效負載壓縮
可以使用 gzip 等壓縮請求和回應，以便傳輸的資料大小小得多。這可以加快上傳和下載速度。
連接池
在存取資源時，我們經常需要從資料庫載入資料。開啟正在關閉的資料庫連線會增加大量開銷。因此，我們應該透過開啟的連接池連接到資料庫。連接池負責管理連線生命週期。
每一代HTTP解決了什麼問題？
下圖說明了主要功能。
HTTP 1.0 於 1996 年最終確定並完整記錄。
HTTP 1.1 於 1997 年發佈。
HOL阻塞－當瀏覽器允許的平行請求數用完時，後續請求需要等待前面的請求完成。
HTTP 2.0於2015年發布，透過請求復用解決了HOL問題，消除了應用層的HOL阻塞，但傳輸層（TCP）仍然存在HOL。
如圖所示，HTTP 2.0 引入了 HTTP「流」的概念：一種允許將不同的 HTTP 交換復用到同一 TCP 連線上的抽象。每個流不需要按順序發送。
HTTP 3.0 第一稿於 2020 年發布。它使用 QUIC 而不是 TCP 作為底層傳輸協議，從而消除了傳輸層的 HOL 阻塞。
QUIC 基於 UDP。它將流作為傳輸層的一等公民引入。 QUIC 流共享相同的 QUIC 連接，因此建立新串流不需要額外的握手和緩慢啟動，但 QUIC 流是獨立交付的，因此在大多數情況下，影響一個流的資料包遺失不會影響其他流。
下圖展示了 API 時間軸和 API 風格比較。
隨著時間的推移，不同的 API 架構風格被發布。它們每個都有自己的標準化資料交換模式。
您可以在圖中查看每種樣式的用例。
下圖顯示了程式碼優先開發和 API 優先開發之間的差異。為什麼我們要考慮API優先設計？
在編寫程式碼並仔細定義服務的邊界之前，最好先考慮一下系統的複雜性。
我們可以在編寫程式碼之前模擬請求和回應來驗證 API 設計。
開發人員也對這個過程感到滿意，因為他們可以專注於功能開發，而不是協商突然的變化。
在專案生命週期結束時出現意外的可能性會降低。
因為我們先設計了API，所以可以在開發程式碼的同時設計測試。在某種程度上，我們在使用API優先開發時也有TDD（測試驅動設計）。
HTTP 的回應代碼分為五類：
資訊性 (100-199) 成功 (200-299) 重新導向 (300-399) 用戶端錯誤 (400-499) 伺服器錯誤 (500-599)
下圖顯示了詳細資訊。
步驟 1 - 用戶端向 API 網關發送 HTTP 請求。
步驟 2 - API 閘道解析並驗證 HTTP 請求中的屬性。
步驟 3 - API 網關執行允許清單/拒絕清單檢查。
步驟 4 - API 網關與身分提供者對話以進行身份驗證和授權。
步驟 5 - 將速率限制規則套用至請求。如果超過限制，請求將被拒絕。
步驟 6 和 7 - 現在請求已通過基本檢查，API 網關透過路徑匹配找到要路由到的相關服務。
步驟 8 - API 閘道將請求轉換為適當的協定並將其傳送到後端微服務。
步驟9-12：API網關可以正確處理錯誤，如果錯誤需要較長時間才能恢復（熔斷），則處理故障。它還可以利用 ELK（Elastic-Logstash-Kibana）堆疊進行日誌記錄和監控。我們有時會在 API 網關中快取資料。
下圖顯示了典型的 API 設計和購物車範例。
請注意，API 設計不僅僅是 URL 路徑設計。大多數時候，我們需要選擇正確的資源名稱、識別碼和路徑模式。設計正確的 HTTP 標頭欄位或在 API 閘道內設計有效的速率限制規則同樣重要。
資料如何透過網路傳送？為什麼 OSI 模型需要這麼多層？
下圖顯示了資料在網路傳輸時如何封裝和解封裝。
步驟1：當設備A透過HTTP協定透過網路傳送資料到設備B時，首先在應用層新增HTTP頭。
步驟2：然後將TCP或UDP標頭加入資料中。它在傳輸層被封裝成 TCP 報文段。標頭包含來源連接埠、目標連接埠和序號。
步驟 3：然後在網路層用 IP 標頭封裝這些段。 IP 標頭包含來源/目標 IP 位址。
步驟 4：IP 資料封包在資料鏈結層新增 MAC 標頭，其中包含來源/目標 MAC 位址。
步驟5：封裝後的訊框被傳送到實體層並以二進位位元透過網路傳送。
步驟6-10：當Device B從網路接收到位元時，它執行解封裝過程，這是封裝過程的逆處理。頭部被逐層移除，最終Device B可以讀取資料。
我們需要在網路模型中分層，因為每一層都專注於自己的職責。每層都可以依賴標頭來處理指令，不需要知道最後一層資料的意義。
下圖顯示了 ?????? 之間的差異????和一個？ ????。
轉發代理是位於使用者裝置和網際網路之間的伺服器。
轉發代理通常用於：
反向代理程式是一種伺服器，它接受客戶端的請求，將請求轉發到 Web 伺服器，並將結果傳回給客戶端，就好像代理伺服器已經處理了請求一樣。
反向代理適用於：
下圖展示了6種常見的演算法。
循環賽
客戶端請求按順序傳送到不同的服務實例。這些服務通常要求是無狀態的。
黏性循環法
這是循環演算法的改進。如果 Alice 的第一個要求傳送到服務 A，則後續請求也會傳送到服務 A。
加權循環賽
管理員可以指定每項服務的權重。權重較高的人比其他人處理更多的請求。
哈希值
此演算法對傳入請求的 IP 或 URL 套用雜湊函數。根據雜湊函數結果將請求路由到相關實例。
最少連線數
新請求將傳送到並發連線數最少的服務實例。
最短回應時間
新請求將傳送到回應時間最快的服務實例。
下圖顯示了 URL、URI 和 URN 的比較。
URI 代表統一資源識別碼。它標識網路上的邏輯或物理資源。 URL 和URN 是URI 的子類型。 URL定位資源，而URN命名資源。
URI 由以下部分組成：scheme:[//authority]path[?query][#fragment]
URL 代表統一資源定位符，是 HTTP 的關鍵概念。它是網路上獨特資源的位址。它可以與 FTP 和 JDBC 等其他協定一起使用。
URN 代表統一資源名稱。它使用 urn 方案。 URN 不能用於定位資源。圖中給出的一個簡單範例由命名空間和特定於命名空間的字串組成。
如果您想了解有關該主題的更多詳細信息，我建議您查看 W3C 的說明。
第 1 節 - SDLC 與 CI/CD
軟體開發生命週期（SDLC）由幾個關鍵階段組成：開發、測試、部署和維護。 CI/CD 自動化並整合這些階段，以實現更快、更可靠的發布。
當程式碼被推送到 git 儲存庫時，它會觸發自動建置和測試過程。運行端對端 (e2e) 測試案例來驗證程式碼。如果測試通過，程式碼可以自動部署到登台/生產環境。如果發現問題，程式碼將被發送回開發以修復錯誤。這種自動化為開發人員提供了快速回饋，並降低了生產中出現錯誤的風險。
第 2 節 - CI 和 CD 之間的區別
持續整合 (CI) 會自動執行建置、測試和合併流程。只要提交程式碼，它就會運行測試以儘早檢測整合問題。這鼓勵頻繁的程式碼提交和快速回饋。
持續交付 (CD) 可自動執行基礎架構變更和部署等發布流程。它確保可以透過自動化工作流程隨時可靠地發佈軟體。 CD 還可以自動執行生產部署之前所需的手動測試和批准步驟。
第 3 節 - CI/CD 管道
典型的 CI/CD 管道有幾個相連的階段：
規劃：Netflix 工程使用 JIRA 進行規劃，使用 Confluence 進行文件編制。
編碼：Java 是後端服務的主要程式語言，而其他語言則用於不同的用例。
建置：Gradle 主要用於構建，Gradle 插件的建置是為了支援各種用例。
打包：套件和相依性打包到 Amazon 系統映像 (AMI) 中以供發布。
測試：測試強調生產文化對建構混亂工具的關注。
部署：Netflix 使用自建的 Spinnaker 進行金絲雀部署。
監控：監控指標集中在Atlas中，使用Kayenta來偵測異常狀況。
事件報告：事件依照優先權調度，使用PagerDuty進行事件處理。
這些架構模式是應用程式開發中最常用的模式，無論是在 iOS 還是 Android 平台上。開發人員引入它們是為了克服早期模式的限制。那麼，它們有何不同？
模式是常見設計問題的可重複使用解決方案，可實現更順暢、更有效率的開發流程。它們充當構建更好的軟體結構的藍圖。這些是一些最受歡迎的模式：
為您的專案選擇正確的資料庫是一項複雜的任務。許多資料庫選項都適合不同的用例，很快就會導致決策疲勞。
我們希望這份備忘單提供高級指導，以找到符合您專案需求的正確服務並避免潛在的陷阱。
注意：Google 關於其資料庫用例的文檔有限。儘管我們盡力查看可用的內容並得出最佳選擇，但某些條目可能需要更準確。
答案會根據您的用例而有所不同。資料可以在記憶體或磁碟上建立索引。同樣，資料格式也各不相同，例如數字、字串、地理座標等。所有這些因素都會影響您對資料庫索引格式的選擇。
以下是一些用於索引資料的最受歡迎的資料結構：
下圖顯示了該過程。請注意，不同資料庫的架構有所不同，該圖演示了一些常見的設計。
步驟1 - 透過傳輸層協定（例如TCP）將SQL 語句傳送到資料庫。
步驟 2 - SQL 語句被傳送到命令解析器，在其中進行語法和語意分析，然後產生查詢樹。
步驟 3 - 查詢樹被傳送到優化器。優化器建立執行計劃。
步驟 4 - 將執行計劃傳送給執行者。執行器從執行中檢索資料。
步驟 5 - 存取方法提供執行所需的資料擷取邏輯，從儲存引擎檢索資料。
步驟 6 - 存取方法決定 SQL 語句是否是唯讀的。如果查詢是唯讀的（SELECT 語句），則會將其傳遞到緩衝區管理器以進行進一步處理。緩衝區管理器在快取或資料檔案中尋找資料。
步驟 7 - 如果語句是 UPDATE 或 INSERT，則將其傳遞至交易管理器以進行進一步處理。
步驟 8 - 在交易期間，資料處於鎖定模式。這是由鎖管理器保證的。它還確保了事務的 ACID 屬性。
CAP 定理是計算機科學中最著名的術語之一，但我敢打賭不同的開發人員有不同的理解。讓我們來看看它是什麼以及為什麼它會令人困惑。
CAP 定理指出，分散式系統不能同時提供這三個保證中的兩個以上。
一致性：一致性是指所有客戶端無論連接到哪個節點，都同時看到相同的資料。
可用性：可用性意味著即使某些節點發生故障，任何請求資料的客戶端都會得到回應。
分區容錯性：分區表示兩個節點之間的通訊中斷。分區容錯意味著儘管有網路分區，系統仍能繼續運作。
「3 之 2」的表述可能很有用，但這種簡化可能會產生誤導。
選擇資料庫並不容易。僅僅根據 CAP 定理證明我們的選擇是不夠的。例如，公司不會因為 Cassandra 是 AP 系統就選擇它作為聊天應用程式。 Cassandra 具有一系列良好的特性，使其成為儲存聊天訊息的理想選擇。我們需要更深入地挖掘。
「CAP 僅禁止設計空間的一小部分：在存在分區的情況下實現完美的可用性和一致性，這很少見」。引自論文：CAP 十二年後：「規則」如何改變。
該定理大約是 100% 的可用性和一致性。更現實的討論是沒有網路分區時延遲和一致性之間的權衡。有關詳細信息，請參閱 PACELC 定理。
CAP定理真的有用嗎？
我認為它仍然有用，因為它讓我們能夠進行一系列權衡討論，但這只是故事的一部分。在選擇正確的資料庫時，我們需要更深入地挖掘。
SQL語句由資料庫系統分幾個步驟執行，包括：
SQL的執行非常複雜，涉及許多考慮因素，例如：
1986 年，SQL（結構化查詢語言）成為標準。在接下來的 40 年裡，它成為關聯式資料庫管理系統的主導語言。閱讀最新標準 (ANSI SQL 2016) 可能非常耗時。我怎樣才能學習它？
SQL 語言有 5 個元件：
對於後端工程師來說，你可能需要了解其中的大部分內容。作為資料分析師，您可能需要對 DQL 有充分的了解。選擇與您最相關的主題。
該圖說明了我們在典型架構中快取資料的位置。
沿著流程有多個層次。
主要原因有3個，如下圖。
Q：另一種流行的記憶體儲存是 Memcached。你知道Redis和Memcached的差別嗎？
您可能已經注意到該圖的風格與我之前的帖子不同。請告訴我您比較喜歡哪一個。
Redis 不僅僅是快取。
Redis 可用於多種場景，如圖所示。
會議
我們可以使用Redis在不同服務之間共享使用者會話資料。
快取
我們可以使用Redis來快取物件或頁面，尤其是熱點資料。
分散式鎖
我們可以使用Redis字串來取得分散式服務之間的鎖。
櫃檯
我們可以統計文章的按讚數或閱讀量。
速率限制器
我們可以對某些使用者 IP 應用速率限制器。
全域 ID 產生器
我們可以使用 Redis Int 作為全域 ID。
購物車
我們可以使用 Redis Hash 來表示購物車中的按鍵值對。
計算用戶保留率
我們可以使用Bitmap來表示每天的使用者登入情況並計算使用者留存情況。
訊息佇列
我們可以使用 List 作為訊息佇列。
排行
我們可以使用ZSet對文章進行排序。
設計大型系統通常需要仔細考慮快取。以下是五種常用的快取策略。
下圖展示了一個典型的微服務架構。
微服務的好處：
一圖勝千言：開發微服務的 9 個最佳實踐。
當我們開發微服務時，需要遵循以下最佳實踐：
下面您將看到一張顯示微服務技術堆疊的圖表，包括開發階段和生產階段。
有許多設計決策對 Kafka 的性能做出了貢獻。在這篇文章中，我們將重點放在兩個。我們認為這兩者最有分量。
該圖說明了資料如何在生產者和消費者之間傳輸，以及零拷貝的含義。
2.1 資料從磁碟載入到OS快取
2.2 資料從OS快取複製到Kafka應用程式
2.3 Kafka應用程式將資料複製到socket緩衝區
2.4 將資料從socket buffer複製到網路卡
2.5 網路卡將資料傳送給消費者
3.1：資料從磁碟載入到OS快取 3.2 OS快取透過sendfile()指令直接將資料複製到網路卡 3.3 網路卡將資料傳送給消費者
零拷貝是在應用程式上下文和核心上下文之間保存多個資料副本的捷徑。
下圖顯示了信用卡支付流程的經濟學。
1.持卡人向商家支付100美元購買產品。
2. 商家從使用銷售量較高的信用卡中獲益，需要提供支付服務給發卡機構和卡網路進行補償。收單銀行向商家收取一定費用，稱為「商家折扣費」。
3 - 4. 收單銀行保留 0.25 美元作為收單加價，並向開證行支付 1.75 美元作為交換費。商戶折扣費應包含交換費。
交換費由卡片網路設定，因為每個發卡銀行與每個商家協商費用的效率較低。
5. 卡網路與各銀行製定網路評估和費用，銀行每月向卡片網路支付其服務費用。例如，VISA 對每次刷卡收取 0.11% 的評估費，另加 0.0195 美元的使用費。
6. 持卡人向發卡銀行支付服務費用。
開證行為何要賠償？
VISA、Mastercard 和 American Express 充當資金清算和結算的卡片網路。收單銀行和發卡銀行可能（而且通常是）不同。如果銀行要在沒有中介的情況下一筆一筆地結算交易，則每家銀行都必須與所有其他銀行結算交易。這是相當低效的。
下圖顯示了 VISA 在信用卡支付流程中的作用。涉及兩個流程。當客戶刷信用卡時就會發生授權流程。當商家想要在一天結束時拿到錢時，就會發生捕獲和結算流程。
步驟0：發卡銀行向其客戶發行信用卡。
步驟一：持卡人想要購買商品，在商家店舖的銷售點（POS）終端機刷信用卡。
步驟2：POS終端將交易傳送至已提供POS終端機的收單銀行。
步驟 3 和 4：收單銀行將交易發送至卡片網絡，也稱為卡片方案。卡網路將交易發送給發卡銀行進行批准。
步驟4.1、4.2和4.3：如果交易獲得批准，發卡銀行將凍結資金。批准或拒絕將發送回收單機構以及 POS 終端機。
步驟1和第2步：商家希望在一天結束時收款，因此他們在POS終端機上點選「收款」。交易大量發送至收單機構。收單機構將包含交易的批次文件傳送到卡片網路。
步驟3：卡片網路對不同收單機構所收集的交易進行清算，並將清算文件傳送給不同的發卡銀行。
第四步：發卡銀行確認清算文件的正確性，並將資金劃轉至相關收單行。
步驟5：收單銀行將資金轉至商戶銀行。
第四步：卡片網路清算來自不同收單銀行的交易。清算是相互抵銷交易進行淨額結算的過程，因此總交易數量減少。
在此過程中，卡網絡承擔了與每家銀行對話的負擔，並收取服務費作為回報。
什麼是統一支付介面？ UPI是由印度國家支付公司開發的即時即時支付系統。
它佔當今印度數位零售交易的 60%。
UPI = 支付標記語言 + 可互通支付標準
DevOps、SRE 和平台工程的概念出現在不同的時期，並由不同的個人和組織開發。
DevOps 作為一個概念由 Patrick Debois 和 Andrew Shafer 於 2009 年在敏捷會議上提出。他們試圖透過促進整個軟體開發生命週期的協作文化和共同責任來彌合軟體開發和營運之間的差距。
SRE（即站點可靠度工程）由 Google 在 2000 年代初期首創，旨在解決管理大型複雜系統的營運挑戰。 Google開發了SRE實踐和工具，例如Borg叢集管理系統和Monarch監控系統，以提高其服務的可靠性和效率。
平台工程是一個更新的概念，建立在 SRE 工程的基礎上。平台工程的確切起源尚不清楚，但它通常被理解為 DevOps 和 SRE 實踐的延伸，重點是為支援整個業務視角的產品開發提供全面的平台。
值得注意的是，雖然這些概念出現的時間不同。它們都與改善軟體開發和營運方面的協作、自動化和效率的更廣泛趨勢有關。
K8s是一個容器編排系統。它用於容器部署和管理。其設計很大程度上受到Google內部系統Borg的影響。
k8s 叢集由一組稱為節點的工作機器組成，它們運行容器化應用程式。每個叢集至少有一個工作節點。
工作節點託管作為應用程式工作負載組件的 Pod。控制平面管理叢集中的工作節點和 Pod。在生產環境中，控制平面通常會跨多台電腦運行，叢集通常運行多個節點，提供容錯和高可用性。
API伺服器
API 伺服器與 k8s 叢集中的所有元件進行通訊。 Pod 上的所有操作都是透過與 API 伺服器通訊來執行的。
調度程式
調度程式監視 Pod 工作負載並在新建立的 Pod 上分配負載。
控制器經理
控制器管理器運行控制器，包括節點控制器、作業控制器、EndpointSlice 控制器和 ServiceAccount 控制器。
等
etcd 是一個鍵值存儲，用作 Kubernetes 所有叢集資料的後備存儲。
豆莢
Pod 是一組容器，是 k8s 管理的最小單元。 Pod 具有應用於 Pod 內每個容器的單一 IP 位址。
庫貝萊特
在叢集中的每個節點上運行的代理程式。它確保容器在 Pod 中運作。
庫貝代理
Kube-proxy 是一個在叢集中每個節點上運行的網路代理程式。它將從服務進入節點的流量路由。它將工作請求轉送到正確的容器。
什麼是 Docker？
Docker 是一個開源平台，可讓您在隔離的容器中打包、分發和運行應用程式。它專注於容器化，提供封裝應用程式及其相依性的輕量級環境。
什麼是 Kubernetes？
Kubernetes，通常稱為 K8s，是一個開源容器編排平台。它提供了一個框架，用於跨節點叢集自動部署、擴展和管理容器化應用程式。
兩者有何不同？
Docker：Docker 在單一作業系統主機上的單一容器層級上運作。
您必須手動管理每個主機，並且為多個相關容器設定網路、安全性原則和儲存可能很複雜。
Kubernetes：Kubernetes 在叢集層級運作。它管理跨多個主機的多個容器化應用程序，為負載平衡、擴展和確保應用程式的所需狀態等任務提供自動化。
簡而言之，Docker 專注於容器化和在單一主機上運行容器，而 Kubernetes 專注於跨主機叢集大規模管理和編排容器。
下圖顯示了 Docker 的架構以及當我們執行「docker build」、「docker pull」和「docker run」時它是如何運作的。
Docker 架構中有 3 個元件：
Docker客戶端
Docker 用戶端與 Docker 守護程式對話。
Docker主機
Docker 守護程式偵聽 Docker API 請求並管理 Docker 對象，例如映像、容器、網路和磁碟區。
Docker 註冊表
Docker 註冊表儲存 Docker 映像。 Docker Hub 是一個任何人都可以使用的公開註冊表。
我們以「docker run」指令為例。
首先，必須確定程式碼的儲存位置。常見的假設是只有兩個位置 - 一個位於 Github 等遠端伺服器上，另一個位於我們的本機電腦上。然而，這並不完全準確。 Git 在我們的機器上維護了三個本地存儲，這意味著我們的程式碼可以在四個地方找到：
大多數 Git 指令主要在這四個位置之間移動檔案。
下圖顯示了 Git 工作流程。
Git 是分散式版本控制系統。
每個開發人員都維護主儲存庫的本機副本，並編輯和提交到本機副本。
提交速度非常快，因為該操作不會與遠端儲存庫互動。
如果遠端儲存庫崩潰，可以從本機儲存庫復原檔案。
有什麼區別？
