微服務架構的核心概念在於將大型應用程式拆解成許多小型、獨立的服務單元，每個單元負責單一業務功能，並透過輕量級機制進行通訊。相較於傳統單體式架構，微服務能提升系統的靈活性、可擴充套件性和可維護性，更易於持續交付和整合。然而，微服務並非銀彈，匯入微服務需要面對分散式系統的複雜性，例如服務發現、跨服務通訊、資料一致性、錯誤處理以及安全性等挑戰。企業在評估是否採用微服務架構時，需考量團隊規模、技術能力、業務複雜度以及基礎設施的支援程度。
在實際轉型過程中，除了技術層面的調整，團隊也需要適應新的開發流程和組織架構。從單體式架構轉向微服務，需要將原有的團隊拆分成更小的、跨職能的團隊，每個團隊負責一個或多個微服務的開發、測試、佈署和維護。這種組織架構的調整能提升團隊的自主性和效率，但也需要團隊成員具備更全面的技能和更強的合作意識。此外，自動化測試、持續整合和持續交付是微服務架構成功的關鍵因素，能確保快速迭代和頻繁佈署。在安全性方面，微服務架構也引入了新的挑戰，需要更細緻的許可權控制和安全策略，以保障各個服務之間以及與外部系統之間的資料安全。
微服務的定義與挑戰
在現代軟體開發中，微服務架構已成為解決傳統單一應用程式（Monolithic Applications）問題的有效方法。然而，這些問題並非一朝一夕形成的。當我們將程式碼和功能交給應用程式開發者時，問題通常會隨之而來。以下是一些常見的挑戰：
- 效能問題
- 可擴充套件性不足
- 迴歸測試週期長
- 升級和重新佈署週期長，導致無法快速佈署小修補和增強功能
- 未預期的停機時間
- 升級期間可能出現的停機時間
- 鎖定在現有技術和程式語言上
- 無法僅擴充套件所需的元件或功能
這些挑戰不僅影響系統效能，還會對工程團隊造成極大的挫折，進而提高人才流失率。在此情況下，微服務架構便能發揮其價值。然而，微服務架構並非對所有應用程式都適用，特別是在小型應用程式或小型企業中，其成本可能不值得投入。
微服務的解決方案
假設我們需要更新購物車元件。根據軟體的架構和歷史，這可能不僅僅是新增或更新程式碼，還需要對所有與購物車元件相關的程式碼進行迴歸測試。此外，還需要重新編譯、測試和佈署整個應用程式，這可能會導致停機時間或降低應用程式效能。如果開發者希望使用新語言（如Scala）來編寫該功能，除非有足夠的投資來重寫整個應用程式，否則這個願望很難實作。
微服務架構可以解決這些問題。我們將主要的單一應用程式元件拆分為獨立的微服務，如圖示所示：
graph TD;
A[產品目錄] --> B[購物車]
A --> C[支付]
A --> D[使用者管理]
B --> E[訂單管理]
B --> F[搜尋]
內容解密：
此圖示展示了電子商務系統的各個元件如何被拆分為獨立的微服務。每個微服務都負責特定功能，使得系統更加模組化且易於管理。
這些微服務各自佈署並執行單一功能。如果我們需要修改購物車微服務，我們只需要處理該特定微服務的程式碼，測試和佈署變得更加簡單。微服務不僅解決了單一應用程式帶來的挑戰，還提供了許多優勢，推動企業朝著持續交付方向發展。
模組化架構
根據Chaos Manifesto報告（The Standish Group, “CHAOS Report 2016”，2016），大型軟體專案中只有29%在預定成本、時間和品質內成功完成。剩下71%的專案或失敗或面臨挑戰。這些失敗可能源於品質問題、未完成、預算超支等原因。因此，許多新的實踐和軟體管理標準被引入以控制複雜性並提高專案的成功率。
軟體應用或平台通常在4到6年後因各種原因陷入過時狀態。這些原因包括需求變化、傳統架構無法擴充套件、技術更新等。傳統做法是重寫整個軟體或平台以使用最新技術和最佳實踐。
然而，並非每個元件都需要重寫。如果架構提供了模組化設計，我們就可以逐步替換個別元件而不需重寫整個系統。
模組化架構的優勢
模組化架構具有顯著優勢：
- 降低複雜性：將複雜性拆分為多個獨立的微服務，每個微服務只負責一個特定功能。
- 提升靈活性：可以根據需求選擇合適的技術堆疊來實作不同微服務。
- 快速升級：只需替換過時的微服務而不必重寫整個系統。
- 簡化測試：每個微服務獨立佈署和測試，減少了跨功能測試的需求。
其他微服務優勢
除了上述優勢外，微服務還提供以下好處：
- 簡單性：每個微服務只負責一個明確且獨立的功能，減少了程式碼間的耦合和依賴性。
- 可擴充套件性：可以根據需求獨立擴充套件特定微服務而不影響其他部分。
- 持續交付：由於程式碼函式庫間依賴性減少且開發週期縮短，微服務天然支援持續交付和DevOps文化。
graph TD;
A[高負載] --> B[特定擴充套件]
C[低負載] --> D[無需擴充套件]
內容解密：
此圖示展示瞭如何根據負載情況進行精確擴充套件。高負載部分可以單獨擴充套件而不影響其他部分。
透過這些優勢，微服務架構成為現代軟體開發中的重要選擇。它不僅解決了傳統單一應用程式帶來的挑戰，還提供了一系列長期益處，使得企業能夠更靈活地應對變化與需求。
轉向微服務的考量
在第一章中，我們已經探討了微服務與單體架構之間的差異。瞭解了這些差異後，你可能會問：「微服務適合我的團隊嗎？」如果你已經面臨單體架構的成長困境，或者正計劃開發一個單體系統，那麼微服務確實值得考慮。然而，如果不是這種情況，轉向微服務架構可能沒有必要。因為微服務架構相較於單體架構來說，所需的工作量和複雜性更高，包括 API 集合、過程監控、負載平衡以提升效能和高用性等。
以下是一些轉向微服務架構應該考慮的標準和注意事項：
適合轉向微服務的情境
1. 大規模應用
對於需要支援大量使用者和高併發存取的應用程式，微服務架構能夠提供更好的擴充套件性和靈活性。每個微服務可以獨立擴充套件，滿足不同模組的需求。
2. 頻繁更新與佈署
如果你的應用需要頻繁更新和佈署新功能，微服務可以讓開發團隊獨立工作，不會影響整個系統的穩定性。這樣可以加快開發速度並減少風險。
3. 多樣化技術選擇
微服務允許每個服務使用最適合其需求的技術堆疊，而不是被限制在一個統一的技術選擇上。這對於需要不同技術支援的複雜應用來說是一大優勢。
不適合轉向微服務的情境
1. 小型到中型應用
對於規模較小或需求較簡單的應用，微服務架構可能會增加不必要的複雜性和管理成本。單體架構在這些情境下可能更為簡潔有效。
2. 技術資源有限
如果團隊缺乏足夠的技術資源來管理和維護大量的微服務，轉向微服務可能會導致操作上的困難和風險。
成本與收益分析
在考慮轉向微服務之前，必須進行成本與收益分析。以下是一些關鍵考量：
1. 初期投資
轉向微服務需要初期投資，包括技術研發、基礎設施建設和團隊培訓等。這些成本需要在長期收益中找到回報。
2. 維運成本
維運成本也會顯著增加，包括監控、佈署、負載平衡等方面的操作。這需要高度自動化和專業的人力資源來支援。
3. 長期收益
長期來看，微服務架構可以帶來更高的靈活性、可擴充套件性和穩定性，從而提升整體業務價值。這些收益需要透過具體案例和資料來驗證。
小段落標題
玄貓認為在做出轉向微服務架構的決定前，必須充分評估各種因素並進行詳細分析。每個團隊和應用都有其獨特需求和挑戰，因此沒有一個統一的答案適用於所有情境。透過理解這些考量並進行深入分析，可以幫助你做出最適合你團隊和應用的決定。
轉向微服務架構
在現代軟體開發中，微服務架構（Microservices）已成為許多企業轉型的熱門選擇。然而，從傳統的單一應用程式架構（Monolithic Architecture）轉向微服務並非易事，這一轉變需要深入瞭解現有系統的疲勞點及其屬性，並評估是否符合微服務的特性。
系統疲勞與屬性
當前系統可能存在以下疲勞點，適合考慮轉向微服務：
- 佈署過程困難且耗時：佈署新功能或修復漏洞需要大量時間和資源。
- 龐大且複雜的程式碼基礎：開發者的整合開發環境（IDE）可能無法有效處理大量程式碼。
- 非均勻的擴充套件需求：某些功能需要更多資源來擴充套件。
- 開發、測試和佈署成本高昂：維護和更新單一應用程式的成本過高。
- 隨著時間推移，程式碼品質下降：過多的相互依賴性導致系統難以維護。
- 單一元件失敗導致應用程式失效：系統中的一個小問題可能會導致整個應用程式當機。
在考慮轉向微服務之前，應詳細記錄這些疲勞點。接著，評估以下特性是否能為現有應用程式帶來價值：
- 服務以業務能力為中心組織：每個微服務負責特定業務功能。
- 獨立或部分佈署的服務：可以單獨佈署或更新某些部分而不影響整體系統。
- 非同步通訊：不同微服務之間透過訊息佇列進行通訊，提高靈活性和可擴充套件性。
- 替換不同平台元件、程式語言和資料函式庫：根據不同需求選擇最適合的技術堆積疊。
- 持續佈署和持續整合：快速迭代和佈署新功能。
- 工程團隊擁有特定業務區域：例如訂單管理或購物車。
透過這些思考，可以更好地判斷是否需要轉向微服務架構。一旦決定轉型，組織必須準備面對新的挑戰：
文化變遷與學習曲線
轉向微服務將對組織文化產生深遠影響。傳統的功能角色將轉變為以業務為中心的角色，團隊將分享目標和責任。這意味著需要建立跨職能團隊，包括產品經理、開發者、測試人員和營運人員，共同負責微服務的開發和維護。
操作流程變更
微服務架構需要重新設計操作流程和結構。傳統的測試和佈署流程將被拆分為多個細粒度的流程，以支援數百甚至數千個獨立微服務之間的通訊。
新技術與工具
成功轉向微服務需要投資於新技術、工具和軟體。這包括自動化工具、容器技術（如Docker）以及新的監控和管理工具。團隊需接受培訓以掌握這些新技術。
自立微服務
單一應用程式通常作為一個大單元佈署在多個伺服器上以實作可擴充套件性。而微服務則由數百甚至數千個自包含的服務組成，每個服務都需要同等關注。
微服務發現
隨著微服務數量增多，發現和管理這些服務變得更加複雜。這需要解決如何建立和維護微服務清單、動態擴充套件和版本控制等問題。可以使用如Consul或Apache ZooKeeper等工具來解決這些挑戰。
微服務之間的通訊
決定如何在所有服務之間進行通訊是關鍵。這包括考慮客戶對回應時間、延遲和重試次數等方面的期望，以及如何處理未滿足期望時的情況。可能需要建立標準介面來促進通訊。
微服務測試
傳統單一應用程式的測試方法不適用於微服務。雖然測試每個自包含的微服務相對簡單，但測試整體應用時面臨挑戰。這需要處理大量移動部分，並強調整合測試。建立最佳實踐並自動化測試案例可以解決一些複雜性。
微服務擴充套件
微服務提供了更靈活且高效的擴充套件方式。可以根據需求動態增加或減少特定服務的資源組態。但這也帶來了設計考量——需明確每個微服務的使用需求及其拓展策略——並自動化伸縮過程以減少操作成本。
微服務升級
在表面上升級單個自我包含且獨立執行的每個微服務似乎很簡單：只要確保新版本不會影響其他依賴項即可。然而，當升級影響其他依賴項時則會複雜得多：確保其他相關依賴項都準備好使用新功能或者使升級後新版本對老版本相容。
微服務安全
安全在所有架構中都是重要且必要的一環；鑑於現今網路安全威脅日益嚴峻，對於開發設計階段就要充分考慮安全問題。應重點關注內部間安全、客戶端與外部介面安全、傳輸中的資料安全以及靜態資料儲存安全等方面。
小段落標題
內容解密：
- 轉向微服務不僅意味著技術上的變革還涉及到企業文化轉型、組織結構調整以及工作流程最佳化。
- 一個成功轉型後得到改善的是產品開發週期加快、提高資源利用率以及獨立團隊帶來更好的業務聚焦與創新能力。
- 然而轉型也意味著面臨複雜度增加所帶來的管理挑戰：例如無法再僅僅依賴傳統監控工具來實作對數千個獨立執行小型應用進行全面監控與維護
次段落標題
不同架構下測試策略比較
graph TD;
A[Monolithic Architecture] --> B[Single Unit Deployment]
B --> C[Easier Testing]
B --> D[Integration Challenges]
E[Microservices Architecture] --> F[Multiple Independent Services]
F --> G[Individual Service Testing]
F --> H[Complex Integration Testing]
此圖示說明瞭傳統單一應用架構與現代微服務架構在測試策略上的差異。傳統單一應用架構通常作為一個單元進行佈署，雖然這使得測試相對簡單，但整合測試可能會帶來挑戰。相比之下，微服務架構由多個獨立執行小型應用組成且各自獨立測試簡單；然而也因此帶來複雜系統整體測試挑戰。
內容解密：
- 傳統單一應用架構（Monolithic Architecture）：所有功能模組都集中在一個單一應用中執行， 由於所有程式碼都集中在一個單元中而便於管理與測試；但隨著專案規模擴大對開發團隊的人員協調要求會越來越高；
- 轉向了跨職能團隊工作模式：每個團隊負責各自獨立領域開發與維護；
- Microservices Architecture：採取分散式小型應用組成系統主要考慮到系統擴充套件性問題；
- Microservices Architecture也帶來了測試策略上的複雜性——雖然各個獨立小型應用單獨測試較為簡單； 但隨著系統整體規模擴大後這也意味著系統全面測試困難增大；也因此需要引入更多自動化測試工具來解決這些問題；
次段落標題
安全與隱私
graph TD;
A[Microservices Security] --> B[Service-to-Service Security]
A --> C[Client-to-Microservice Security]
A --> D[Data-in-Motion Security]
A --> E[Data-at-Rest Security]
此圖示描述了現代企業在採用了微協作時面臨到的一系列隱私安保問題；包括service-to-service security client-to-microservice security data-in-motion security data-at-rest security；針對每種安全需求有針對性地制定防禦方案非常重要；
內容解密：
- Service-to-service security 是指在兩個獨立執行小型應用之間進行通訊時所涉及到的一系列安全問題；
- Client-to-microservice security指的是從客戶端與外部介面互動時所涉及到的一系列隱私安全問題；
- Data-in-Motion Security 在資料傳輸過程中的隱私安全保障；
- Data-at-Rest Security 在資料儲存過程中的隱私保障；
安全保障方案：OAuth 和 OpenID Connect 是目前廣泛使用於身分驗證與授權的一些常見標準方案；
在進行設計時還需要思考如何在滿足安全需求與系統易用性之間取得平衡；
