前言

為因應環境、需求改變，工程師會替 Application 不斷增添新功能。然而這樣的做法卻會讓 Application 逐漸「特化」導致最後無法普遍應用在異質環境。 顯然隨時間演進會引發幾種問題:

1. Application 越趨複雜、難以偵錯，最後變成巨型單體 (monolith)
2. Git tree 出現許多分枝，管理困難
3. 容器映像檔、程式碼重用性 (reusability) 降低

但正如微服務架構的概念一樣，適當的將主應用功能與新功能進行解耦，便能提高重用性與降低複雜度。

以下將會為各位介紹邊車模式如何解決上述問題

邊車模式

不知道各位是否有印象，在看美劇或電影時常會看到有人騎哈雷時為了多載人會在旁邊外掛一輛車

整輛車的主體是位於中心的哈雷「負責前進」，而旁邊的側車「增加載物、載人的可能性」。

這正是邊車模式的概念來源:

透過其他容器來「增添、擴展」主要容器的功能性

前言

從研究所開始接觸到 OpenStack、分散式系統設計，甚至開始工作後都不斷在相關領域打轉。接觸到 Kubernetes 前，其陡峭的學習曲線 (和 Docker Swarm 相比) 讓許多人為之卻步 ，但從設使用方式甚至架構設計便能夠深刻體會，Kubernetes 是如何真正解決許多分散式系統上的困難點，並且將分散式系統內大部分的難題交由平台來處理，也可以說它將「開發」與「維運」間的高牆打掉不少。

Kubernetes 有以下幾個特點非常吸引我:

1. 維運方便: 內建滾動升級、健康度檢測、標籤組合調控流量分流
2. 生態系完整: 從本地開發到線上部署皆有對應工具處理，加速整體系統迭代
3. 跨雲提供商: 橫跨三本柱 GKE、AWS、Azure，從而避免 Vendor lock-in

正好前陣子微軟釋出 Desigining Distributed Systems 的電子書，內容主要針對在 Kubernetes 上的分散式系統設計模式，最近在練習英文以及重新回顧分散式系統設計的相關知識，趁此機會為該書內容做個導讀，重點會擺放在設計模式的講解與搭配不同的實際案例作為說明。