微服務架構的安全性至關重要，涵蓋身份驗證與授權機制、資料加密、安全傳輸以及信任模型的建立。在 Kubernetes 環境中佈署微服務時，安全性更需特別關注。本文除了介紹微服務安全流程外，也深入探討如何將既有的單體架構應用程式逐步轉換為微服務架構。這個過程需要考量多個導向，包含評估轉換的必要性、團隊的溝通協作、遺留程式碼的處理、自動化流程的建立、微服務平臺的建置，以及如何沿著系統的自然界限逐步拆分單體應用。此外，文章也強調迭代開發、持續測試和自動化佈署的重要性，以確保轉換過程的順利進行並降低風險。最後，文章也探討了混合架構的可能性，讓開發團隊可以根據實際情況選擇最適合的架構策略，並推薦相關書籍供讀者深入學習。
圖表翻譯：
graph LR
A[入口點] -->|身份驗證和授權|> B[微服務]
B -->|加密|> C[資料儲存]
C -->|加密|> D[資料傳輸]
D -->|身份驗證和授權|> E[使用者]
此圖表描述了微服務架構中的一個基本安全流程，包括身份驗證和授權、加密和資料傳輸的安全保護。
內容解密：
上述內容介紹了基礎安全概述、身份驗證和授權、加密、信任模型和 Kubernetes 與安全性的關係。同時，也提供了一個圖表來描述微服務架構中的一個基本安全流程。這些內容可以幫助開發人員和維運人員更好地理解微服務架構中的安全性，並採取有效的措施來保護系統和資料的安全。
12.5.2 敏感性組態保護
任何應用程式都有一些敏感的組態資料需要被保護。在第8章中，我們曾經將一些私密細節（如容器登入密碼和Kubernetes驗證）儲存在GitHub秘密中，與我們的程式碼倉函式庫一起存放在GitHub上（見第8章，第8.9.9節）。
當我們構建應用程式時，還會有其他密碼、令牌和API金鑰需要被安全儲存。我們可以將這些敏感訊息儲存在程式碼中，這樣做很方便，但這意味著任何人只要能夠存取我們的程式碼，就能夠獲得操作訊息，並可能輕易地破壞或關閉我們的應用程式。
GitHub秘密（或其他CI/CD提供商的類別似功能）是儲存這些訊息的一種良好方法。不過，您可能更願意使用一個與源程式碼控制或CI/CD提供商無關的解決方案。對於這種情況，Kubernetes有自己的儲存機制。如果這不符合您的需求，還有其他各種產品可以幫助您。例如，您可能想了解更多關於Vault的訊息，Vault是一個來自HashiCorp的開源產品。
12.6 重構為微服務
在第1章（第1.1節）中，我曾經承諾，在學習如何從頭構建微服務應用程式之後，我們將回來討論如何重構現有的單體應用程式為微服務。如何轉換單體應用程式為微服務將根據具體情況有所不同，但有一些基本的策略和方法可以遵循。
基本思想與任何開發過程相同：遵循第2章（第2.4節）中介紹的迭代方法，進行小而簡單的變化，並在變化過程中保持程式碼的正常運作（如圖12.23所示）。
單體應用程式的轉換是一項巨大的工作（取決於單體應用程式的大小和複雜性），一次性完成轉換不太可能成功。唯一安全的方式是透過小而可管理的工作塊，伴隨著非常徹底的測試。
12.6.1 是否真的需要微服務？
在開始將單體應用程式轉換為微服務之前，您需要問自己一個問題：微服務是否真的必要？轉換為微服務是一項複雜的工作，需要仔細評估是否真的需要。只有當您確定微服務是最佳選擇時，才應該開始轉換過程。
將單體架構轉換為微服務的挑戰和策略
將單體架構轉換為微服務是一個複雜且具有挑戰性的過程。這個過程需要仔細的規劃、執行和測試，以確保成功的轉換。在本文中，我們將探討將單體架構轉換為微服務的挑戰和策略。
12.6.1 將單體架構轉換為微服務的挑戰
將單體架構轉換為微服務是一個長期且具有挑戰性的過程。這個過程需要引入新的複雜性和測試團隊的耐心和決心。以下是一些需要考慮的問題：
- 是否真的需要進行轉換？
- 是否真的需要擴充套件？
- 是否真的需要微服務的靈活性？
這些問題很重要，需要有好的答案。
12.6.2 規劃轉換和涉及所有人
不能在沒有明確計劃的情況下開始轉換為微服務。需要有一個檔案化的願景，描述產品在轉換完成後的樣子。使用領域驅動設計來模擬業務為微服務。目標是簡單的架構，規劃近期未來，而不是遠期未來。從建築願景到目前的情況，工作倒退，找出需要進行的變化序列，以便轉換為微服務。
需要有一個計劃，描述如何建造和如何到達那裡。雖然計劃不需要詳細，但需要有一個總體的想法，知道要去哪裡。計劃應該與團隊（或代表）一起建立，因為實施這個轉換將是一個共同的和具有挑戰性的工作。
計劃不僅需要與開發團隊溝通，也需要與其他業務部門溝通，使用對他們有意義的語言，讓他們瞭解為什麼要進行這個轉換和它帶來的價值。每個人都需要了解這個操作的高風險。
12.6.3 瞭解遺留程式碼
在轉換之前和期間，需要投資大量時間來瞭解單體架構。建立測試計劃，進行實驗，瞭解其失敗模式，開發出對哪些部分會在每一步轉換中斷裂的想法。
12.6.4 改進自動化
良好的自動化對於任何微服務專案都是至關重要的。在轉換之前和期間，需要不斷投資和改進自動化。如果尚未掌握基礎設施和自動化，需要立即開始工作（甚至在開始轉換之前）。可能會發現，公司對自動化的思維方式的改變是這個過程中最具挑戰性的部分。
需要可靠且快速的自動化佈署（見第8章）。任何被轉換的功能都應該已經有自動化測試，或者在轉換功能為微服務時實施自動化測試，具有良好的覆寫率（見第9章）。在微服務中，不能避免自動化。如果不能投資自動化，可能就不能承擔轉換為微服務的成本。
12.6.5 建立微服務平臺
在轉換開始之前，需要有一個平臺來代管新建立的微服務。需要一個生產環境來代管從單體架構中逐步提取出的微服務（見圖12.24）。
在本章中，有一個建立此類別平臺的配方。建立一個私有容器倉函式庫，並根據第6章或第7章建立Kubernetes叢集。在建立第一個微服務後，現在為團隊建立一個分享範本：一個空白的微服務，可以作為每個其他微服務的起點。如果有不同型別的微服務，為每種型別建立多個範本。建立自動化測試管道，使其易於開發人員使用。建立檔案、示例和教程，以便開發人員可以快速瞭解如何建立和佈署新微服務到平臺。
12.6.6 沿著自然界限切割
現在，看看單體架構中現有的與您建築願景中的微服務一致的元件。這些元件提供了從單體架構到微服務的元件逐步提取的絕佳機會，如圖12.25所示。
如果難以找到自然界限，工作將變得更加困難。如果單體架構是一個巨大的泥球或充滿義大利麵程式碼，可能需要先重構或在提取過程中重構。不管怎麼樣，都會很棘手。為了安全起見，您的重構應該得到支援（如果必要，可以沿途建立自動化測試）。它將變得混亂——請做好準備。
圖表翻譯：
圖12.24展示瞭如何將單體架構中的小塊功能逐步提取並移到Kubernetes叢集中。
圖12.25展示瞭如何沿著自然界限從單體架構中提取元件，並將其作為微服務例項化到Kubernetes叢集中。
內容解密：
上述內容解釋了將單體架構轉換為微服務的挑戰和策略。首先，需要了解轉換的挑戰，包括複雜性、耐心和決心。然後，需要規劃轉換和涉及所有人，包括建立一個檔案化的願景、使用領域驅動設計和簡單的架構。接下來，需要了解遺留程式碼、改進自動化和建立微服務平臺。在最後，需要沿著自然界限切割單體架構中的元件，並將其例項化為微服務。
這個過程需要仔細的規劃、執行和測試，以確保成功的轉換。透過遵循這些步驟，可以將單體架構成功轉換為微服務，並獲得更好的可擴充套件性、靈活性和維護性。
12.6.7 優先提取
在決定將元件轉換為微服務的順序時，應優先考慮那些能夠從轉換中受益最大的元件。這可能是因為該程式碼更頻繁地發生變化，或者是由於從提取該元件中獲得了效能或可擴充套件性的好處。
將這些重要的元件早期提取到微服務中，可以立即帶來實際的好處，您將立即感受到效果。這種早期的投資將會對您的開發速度產生可衡量的改善。它將降低您的佈署風險，並有助於說服他人相信轉換正在進行得很好。
12.6.8 不斷重複
透過不斷地將您的單體應用程式轉換為根據微服務的應用程式（圖 12.26），您最終會安全地完成轉換。這不是一件容易的事，可能需要很長時間（根據單體應用程式的大小和複雜性而定）。但是，這是可行的！您只需要不斷地朝著目標前進，一步一步地完成任務，直到完成。
單體應用程式 Kubernetes
您的單體應用程式包含代表自然分界線的元件。
尋找容易分離出來的元件作為獨立的微服務。 圖 12.25 單體應用程式通常具有自然分界線。使用這些分界線來識別可以逐步提取到微服務的個別元件。
單體應用程式 微服務
等等…
提取一個微服務 迭代！
所有微服務 都已提取！始終保持它的運作！ 徹底測試！
時間 給它足夠的時間！將單體應用程式轉換為微服務需要慢慢地和小心地完成。 隨著時間的推移，提取更多 和更多的微服務。 圖 12.26 逐步地提取您單體應用程式的小塊到微服務，始終測試和保持它的運作。最終，您的應用程式將被分解為微服務。
12.7 可能性的譜系
您是否正在努力實作圍繞微服務建立的高標準？通常，當我們為微服務建立建築願景時，我們的目標是什麼我所謂的微服務的開發者烏託邦。這是我們都想居住的地方——如果我們能夠。如果不是，因為來自業務和遺留程式碼函式庫的需求經常會踐踏我們對美麗和優雅架構的夢想。然後，還有一個正在業界引起爭論的問題：哪種方式更好，單體還是微服務？
有時候，我想知道為什麼我們要為此爭論。實際上，並沒有所謂的單體與微服務之爭。在現實中，有一個單體和微服務之間的可能性譜系。沒有理由假設譜繫上的任何一個點比其他點更好。
如圖 12.27 所示，有一系列選項在單體和微服務之間（並繼續到函式即服務）。誰能夠說明哪個點在這個連續體上最適合您？絕對不是我。只有您才能夠做出這個決定。
12.7.1 不需要完美
不要努力去實作別人的完美觀念。完美這個概念甚至不存在——它只是您腦海中的一個概念，每個人都有稍微不同的感知。這使得它幾乎不可能與他人的完美觀念保持一致。
有很多不同的方法可以構建應用程式，並且沒有絕對正確或錯誤的方法——只有什麼行得通，什麼行不通。
微服務的烏託邦
在軟體開發的世界中，微服務和單體式架構（Monolith）一直是兩個被廣泛討論的概念。有些人認為微服務是未來的趨勢，而其他人則堅持單體式架構的優點。但事實上，沒有絕對的對與錯，兩者之間存在著一個廣泛的可能性譜系。
小型單體式架構
在單體式架構中，所有的功能都被封裝在一個單一的、自包含的程式中。這種架構通常被視為簡單、易於維護和擴充套件。但是，當應用程式的複雜度增加時，單體式架構可能會變得難以管理和維護。
微服務
另一方面，微服務是一種將應用程式分解為多個小型、獨立的服務的架構。每個服務都有自己的生命週期、資料儲存和通訊機制。這種架構可以提供更好的擴充套件性、靈活性和容錯性。
功能即服務
在功能即服務（Functions as a Service, FaaS）的架構中，每個功能都被視為一個獨立的服務。這種架構可以提供更好的資源利用率和更低的成本。
分散式應用程式
在分散式應用程式中，多個服務以不同的大小和複雜度組合在一起。這種架構可以提供更好的擴充套件性、靈活性和容錯性。
可能性的譜系
事實上，沒有絕對的對與錯，兩者之間存在著一個廣泛的可能性譜系。從小型單體式架構到微服務，從功能即服務到分散式應用程式，每個選擇都有其優缺點。開發人員應該根據實際需求和客戶的需求選擇最合適的架構。
圖表翻譯：
graph LR
A[小型單體式架構] -->|擴充套件|> B[微服務]
B -->|功能|> C[功能即服務]
C -->|分佈|> D[分散式應用程式]
D -->|複雜|> E[可能性的譜系]
在這個圖表中，我們可以看到從小型單體式架構到微服務，從功能即服務到分散式應用程式，每個選擇都有其優缺點。開發人員應該根據實際需求和客戶的需求選擇最合適的架構。
分散式架構的投資報酬率遞減
在進行分散式架構的轉換時，從單體架構（Monolith）到微服務架構（Microservices）的過程中，並不需要完全達到微服務架構的極致才能開始享受分散式架構帶來的好處。事實上，推動向「完美的微服務」有著投資報酬率遞減（Diminishing Return on Investment，ROI）的問題。
這個過程可以透過圖 12.28 進行理解。在轉換的初期階段，會有一些重大的收穫，但是隨著轉換的進一步推進，收穫的價值會逐漸減少。當服務變得太小時，成本就會開始超過收益。
在某個時點，決定停止轉換是可以的，因為你可能已經達到了滿意的結果，可以選擇維持現狀。最終，你可能會得到一個較小的單體架構和一組微服務，或者是其他形式的架構組合，但只要這對你有效，那就足夠了。也許你決定現在可以將系統保持原樣，不斷增加新的程式碼到新的微服務或較小的單體架構中，以繼續為你的應用程式增加功能。
轉換過程中的投資報酬率
從單體架構到微服務架構的轉換過程中，投資報酬率會隨著時間的推移而遞減。最初階段會有較高的投資報酬率，但隨著轉換的深入，投資報酬率會逐漸降低。最終，當你接近微服務架構的極致時，投資報酬率可能會變得非常低。
圖表翻譯：
圖 12.28 展示了從單體架構到微服務架構的轉換過程中，投資報酬率的變化。圖中顯示了轉換過程中的不同階段，從初始階段的高投資報酬率到最終階段的低投資報酬率。
微服務的混合架構：平衡複雜性和效率
在討論微服務的優點時，我們常常忽略了一個重要的問題：微服務架構的複雜性。雖然微服務可以提供更好的可擴充套件性、靈活性和容錯性，但它也帶來了更多的管理和維護工作。因此，如何平衡微服務的優點和複雜性是一個非常重要的問題。
混合架構：微服務和單體式架構的結合
為瞭解決這個問題，我們可以考慮使用混合架構，即將微服務和單體式架構結合起來。這種架構允許我們在單體式架構中使用微服務，從而既能享受微服務的優點，又能避免其複雜性。
單體式架構的優點
單體式架構有以下優點：
- 簡單易於管理和維護
- 開發和佈署更加快速
- 不需要額外的基礎設施和工具
微服務的優點
微服務也有以下優點：
- 更好的可擴充套件性和靈活性
- 能夠根據業務需求進行個別擴充套件
- 提高了系統的容錯性和可靠性
混合架構的優點
混合架構結合了單體式架構和微服務的優點，具有以下優點：
- 能夠根據業務需求選擇適合的架構
- 減少了微服務的複雜性和管理工作
- 提高了系統的可擴充套件性和靈活性
實踐中的混合架構
在實踐中，我們可以透過以下步驟實作混合架構：
- 評估業務需求：首先，我們需要評估業務需求，確定哪些部分需要使用微服務，哪些部分可以使用單體式架構。
- 設計混合架構：根據業務需求，設計混合架構，確定哪些微服務需要被使用，哪些部分需要被整合到單體式架構中。
- 實作微服務：實作所需的微服務，確保它們能夠正確地與單體式架構進行互動。
- 整合微服務：將微服務整合到單體式架構中，確保它們能夠正確地與其他部分進行互動。
Kubernetes 和混合架構
Kubernetes 是一個非常流行的容器協調工具，它可以幫助我們管理和維護混合架構。透過使用 Kubernetes，我們可以輕鬆地建立和管理微服務，同時也能夠整合它們到單體式架構中。
Kubernetes 的優點
Kubernetes 有以下優點：
- 能夠自動化容器的建立和管理
- 提供了豐富的 API 和工具，方便我們管理和維護容器
- 支援多種容器 runtime 和協調工具
使用 Kubernetes 實作混合架構
透過使用 Kubernetes，我們可以輕鬆地實作混合架構。以下是步驟：
- 建立 Kubernetes 叢集：首先，我們需要建立一個 Kubernetes 叢集。
- 定義微服務：定義所需的微服務，確保它們能夠正確地與單體式架構進行互動。
- 建立微服務：建立所需的微服務，確保它們能夠正確地與 Kubernetes 叢集進行互動。
- 整合微服務：將微服務整合到單體式架構中，確保它們能夠正確地與其他部分進行互動。
內容解密：
以上內容介紹了混合架構的概念和優點，同時也提到了如何使用 Kubernetes 實作混合架構。透過這些內容，我們可以更好地理解混合架構的優點和實作方法。
graph LR
A[單體式架構] -->|整合|> B[微服務]
B -->|互動|> A
C[Kubernetes] -->|管理|> B
圖表翻譯：
此圖示混合架構的概念，其中單體式架構和微服務透過整合和互動相互連線。Kubernetes 作為一個容器協調工具，可以幫助我們管理和維護混合架構。
微服務應用佈署策略
在設計和佈署微服務應用時，需要考慮多個因素，以確保應用能夠順暢地執行並擴充套件。以下是一些有用的策略：
分支管理
如果需要在佈署到客戶導向環境之前先佈署到測試環境，則可以使用單獨的生產和測試分支。這樣可以確保測試環境中的程式碼不會影響生產環境。
組態管理
除非需要額外的靈活性，否則不需要為應用組態建立單獨的程式碼倉函式庫。將應用組態與微服務組態分開可能會使佈署過程更加複雜。
外部儲存和資料函式庫
使用外部檔案儲存和外部資料函式庫伺服器，可以使叢集有效地無狀態。這降低了實驗叢集的風險，即使破壞叢集，也不會丟失資料。此外，這也支援藍綠佈署。
開發和測試
使用Docker Compose可以在開發電腦上模擬應用，以便於開發和測試。同時，使用即時多載功能可以加速開發迭代。
測試和驗證
在早期階段，可能不需要自動化測試，但對於構建大型可維護的微服務應用來說，這是非常重要的。然而，在建立最小可行產品（MVP）時，可以暫時不考慮自動化測試，因為這時候還不需要如此龐大的基礎設施投資。
自動化佈署
早期投資於自動化，特別是自動化佈署，是非常重要的。這樣可以每天都能夠順暢地工作。
從簡單到複雜
回顧我們一起走過的旅程，我們從學習基礎知識開始，然後學習如何使用Docker封裝和發布應用。接著，我們學習如何使用Docker Compose在開發電腦上開發和測試多個微服務。最終，我們在雲端的Kubernetes上建立了生產環境，並將微服務應用佈署到其中。複雜性管理是現代開發的核心，這就是為什麼我們花時間學習高階架構模式，如微服務的原因。
圖表翻譯：
graph LR
A[開始] --> B[學習基礎知識]
B --> C[使用Docker封裝和發布應用]
C --> D[使用Docker Compose開發和測試多個微服務]
D --> E[在雲端的Kubernetes上建立生產環境]
E --> F[將微服務應用佈署到生產環境]
這個圖表展示了從學習基礎知識到佈署微服務應用的整個過程，包括使用Docker和Docker Compose，以及在雲端環境中佈署應用。
微服務應用擴充套件與可擴充套件性之路
在前面的章節中，我們探討了微服務的基礎知識和實踐經驗。現在，讓我們深入探討如何將微服務應用擴充套件到 Kubernetes 叢集中，並在雲端環境中佈署。
微服務應用擴充套件
當我們的微服務應用越來越複雜時，我們需要將其擴充套件到多個微服務中。每個微服務都有自己的程式碼倉函式庫和獨立的佈署時間表。這樣可以確保每個微服務都能夠獨立地開發、測試和佈署。
Kubernetes 叢集
Kubernetes 是一個容器協調系統，可以自動化佈署、擴充套件和管理容器化應用程式。透過使用 Kubernetes，我們可以輕鬆地將微服務應用擴充套件到多個節點中，並實作高用性和可擴充套件性。
雲端環境佈署
雲端環境提供了一種靈活且可擴充套件的方式來佈署微服務應用。透過使用雲端環境，我們可以輕鬆地建立和管理多個環境，例如生產環境、測試環境和開發環境。
可擴充套件性策略
有多種策略可以用來擴充套件微服務應用，包括：
- 垂直擴充套件：增加每個節點的大小以提高效能。
- 水平擴充套件：增加節點的數量以提高效能。
- 微服務水平擴充套件：增加需要更多 CPU 功率或吞吐量的微服務例項數量。
- 彈性擴充套件：組態叢集以自動根據需求進行擴充套件。
推薦書籍
如果您想要學習更多關於域驅動設計、微服務安全和開發的知識，以下書籍是很好的資源：
- 《域驅動設計》作者：Eric Evans
- 《微服務安全實戰》作者：Manning
- 《微服務設計》作者：Ramesh
- 《微服務模式》作者：Manning
- 《.NET Core 微服務》作者：Manning
- 《Spring 微服務實戰》作者：Manning
- 《Python 微服務 API》作者：Manning
微服務架構的安全性、佈署策略以及從單體架構的轉換，是建構現代分散式系統的關鍵議題。深入剖析微服務架構的安全流程，可以發現身份驗證、授權、加密和資料傳輸安全環環相扣，缺一不可。對於敏感性組態的保護，Kubernetes 提供了內建機制，Vault 等第三方工具也提供了更彈性的解決方案。技術團隊應著重於選擇最適合自身需求的安全策略，才能有效保障系統安全。
將單體架構重構為微服務並非一蹴可幾，需要謹慎評估其必要性。多維比較分析顯示，微服務並非所有應用情境的最佳解，盲目追求微服務化反而可能增加系統複雜度和維護成本。實務落地分析指出，轉換過程應遵循迭代方法，逐步抽離元件，並注重自動化測試和佈署流程的建立。此外，建立微服務平臺、沿著自然界限切割單體應用以及優先提取核心元件，都是確保轉換成功的關鍵策略。
從技術演進預測來看，混合架構的興起，代表了微服務並非「非黑即白」的選擇。從小型單體到微服務、功能即服務，乃至更複雜的分散式應用，構成了一個可能性的譜系。重要的是理解分散式架構的投資報酬率遞減，避免過度追求「完美」的微服務，而應根據實際需求找到平衡點。隨著雲原生技術的蓬勃發展，Kubernetes 成為佈署和管理微服務的重要平臺，其自動化擴充套件和彈性伸縮能力，為微服務架構的落地提供了堅實的基礎。玄貓認為，掌握微服務的核心概念和實踐方法，並結合自身業務需求選擇合適的架構策略，才能在快速變化的技術浪潮中保持競爭力。
