微服務架構：敏捷與明確介面的平衡藝術
探討微服務架構的核心優勢、挑戰與未來發展
最近和客戶協作規劃導入 Landing Zone 的時候聊到，之前他們內部曾經為了 “微服務” 的定義，大家意見分歧，討論了許久才把他定義清楚。組織想要推行微服務架構，首先就得先定義清楚什麼是微服務，導入他有什麼好處。今天和大家來聊聊我對微服務的看法：
隨著技術的迅速發展，微服務架構 (Microservices Architecture) 已成為現代軟體開發中的一個關鍵話題。本文將從微服務的優勢與挑戰、成功與失敗案例，以及未來發展方向等方面進行深入探討，幫助大家更好地理解這一架構及其應用，也歡迎大家補充不同的想法和思路
微服務的核心優勢
我認為微服務的核心精神有二: 1. 敏捷 (Agile) 2. 明確的介面 (Clear Interface)
敏捷：這裡的敏捷涉及多個面向，包括「開發的敏捷」、「佈署的敏捷」、「擴展的敏捷」等…，這些技術上的敏捷均指向一個終極的「適應市場變化和商業需求的敏捷」。
明確的介面：得利於 Internet & Mobile 的發展，跨裝置的相同內容供應需求，API first 開始盛行。為了提高重用性，單體內的模組進一步封裝成內聚性更高的服務。In process communication 變成了 cross process 甚至是 internet communication。
按「敏捷」來細看的話：
開發的敏捷：每個微服務可以由獨立的團隊負責開發，減少了團隊之間的依賴性，提升開發效率。團隊可以選擇最適合他們的技術棧和工具，靈活應對不同的業務需求。
佈署的敏捷：由於微服務是獨立部署的，一個服務的更新不會影響到其他服務，從而減少了佈署風險和時間。
擴展的敏捷：微服務可以獨立地進行橫向擴展，即根據需求擴展特定的服務，而不需要擴展整個應用程序。
按「明確的介面」來細看的話：
跨程序的服務串接：微服務通常通過輕量級的通信協議進行互動，這使得不同服務之間的通信更加標準化和方便。API First 的設計理念強調在開發之前先設計和定義好接口，這有助於提高服務的重用性和可維護性。
內聚性高的服務：微服務強調高內聚低耦合，每個服務都專注於特定的業務功能，這使得服務更加內聚和獨立，易於測試、維護和擴展。
微服務與單體架構 (Monolithic) 的對比
微服務和單體的選擇，不是非黑及白，應該認知為一種權衡取捨。
從「敏捷」和「明確的介面」出發，考量業務場景對於這兩者的需要，是否真的利大於弊 (是的，你不一定需要)。
這裡的「弊」指的是：你可以將單體想成一塊大豆腐，那微服務就是切成一塊一塊的豆腐丁。微服務增加了表面積，增加了管理的數量，服務和服務之間需要透過 API 互相溝通，增加了網路複雜度，更難維持資料的一致性，等等…這些都是需要付出的代價。
從「敏捷」和「明確的介面」出發，檢視自己所在的場景是否真的需要：
選擇微服務架構的情況
業務需求多變且成長迅速：微服務的敏捷性和可擴展性能夠更好地應對快速變化和成長的市場需求。
團隊規模較大且分佈廣泛：微服務架構能夠將工作分解成小團隊負責的獨立服務，減少團隊之間的依賴性。
需要高可用性和容錯能力：微服務允許服務獨立部署和運行，即使某個服務出現故障，其他服務仍然可以繼續運行。
選擇單體架構的情況
初創公司或小型項目：單體架構的開發和部署成本較低，適合快速迭代和驗證市場需求。
業務需求穩定且變化不大：單體架構的簡單性和集中管理優勢更明顯，適合需求相對穩定的業務。
團隊規模較小且集中：單體架構可以更容易進行協作和溝通，減少了分佈式系統帶來的溝通和協作挑戰。
微服務的挑戰和解決方案
我覺得微服務最大的挑戰是人，因為這關乎於開發團隊/組織的文化。有一個康威定律 (Conway's law)，講的是組織的結構會直接影響到軟體系統結構。
所以，要從 Day1 就啟動微服務我覺得是困難的，因為那需要團隊裡面的每個人都具備相當的軟體工程水平，或是原本的組織就以類似微服務的方式運行，但這在一般企業中比較少見。
所以，一般來說都是部分單體，部分微服務的方式並存 (是的，就是 Hybrid)。或者，慢慢因需求導入更多的微服務。
並不是說，我今天採用了微服務架構，系統中就不能有單體的存在。這樣的認知，是過於完美主義的 (其實也不是能說是完美，他只是一種選擇 XD)。
確認好「敏捷」和「明確的介面」這兩者的需求之後，找出發力點，漸進式導入微服務：
人與組織文化的挑戰
專業技能和軟體工程水平：微服務架構需要團隊成員具備較高的軟體工程水平，特別是在設計、開發和運維方面。
組織結構和協作方式：微服務架構強調高內聚、低耦合的服務，這要求組織結構能夠支持這種獨立開發和部署的方式。
文化變革和心態轉變：從單體架構轉向微服務架構需要團隊成員的心態轉變，從集中式開發和運維變為分佈式系統的思維方式。
部分單體部分微服務的過渡策略
漸進式導入：將單體應用逐步拆分為微服務，而不是一次性完成轉換，減少風險。
識別關鍵業務功能：先將最關鍵或最需要靈活擴展的業務功能拆分為微服務。
建立內部平台和工具：為微服務開發和運維提供必要的平台和工具支持，如服務註冊與發現、API管理、監控和日志系統等。
成功與失敗的微服務應用案例
每隔一段時間，技術上就會有一些熱點出現，像是前幾年很火的數據中台 (Data Platform)，到前陣子的平台工程 (Platform Engineering)，到現在很火的大型語言模型維運 (LLM Ops)，這些都是蠻好的微服務應用案例。
但是「成功」的微服務應用案例呢？這是一個值得批判的說法！
如同前面所提到，微服務的優點是 1. 敏捷 和 2. 明確的介面，仔細思考，其實這兩個概念是有點 互相拉扯 又 互為表裡 的。
敏捷代表快速的適應變化，明確的介面代表更穩定地為他方提供服務。試想，你要怎麼在快速適應變化的同時，維持明確且一致的介面呢？肯定是有難度的嘛！
所以，微服務啟動後會不斷演變，分裂->融合->分裂->融合，那些分分合合之後，掌握到平衡點，並且商業模式起飛的，就成為成功的案例。那些在到達平衡點之前，商業模式就消散的，就成了 (大多數) 失敗的案例。
不是說用了微服務就能保證成功，你看到的那些微服務成功的案例後，也不一定代表適合你：
成功案例的特徵
靈活應對變化：成功的微服務應用能夠靈活應對市場需求和技術變革。
高效的組織結構：有明確的責任劃分和強大的技術領導力。
強大的技術基礎設施：依賴於自動化的CI/CD管道、可靠的服務註冊與發現機制等。
持續的改進和優化：經歷了多次的分裂和融合過程，最終找到平衡點。
失敗案例的教訓
過度複雜化：導致管理和維護成本過高。
缺乏明確的方向和目標：迷失在分裂和融合過程中。
技術債務積累：沒有及時解決技術債務，導致系統難以維護和擴展。
微服務的未來發展方向
微服務的架構受到容器 (Container) 技術影響很深，可以說，容器技術催生/加速了微服務的崛起。
容器技術隨著雲端的進展，現在已經走向了無伺服器架構 (Serverless)。開發者越來越傾向不直接管理運行這些微服務的實體，只想專注在介面的開發。
也就是說，「敏捷」和「明確的介面」這兩大優勢的前者，開發者需要關注的部分越來越少了。
開發的敏捷、佈署的敏捷和擴展的敏捷，已經透過足夠高的抽象，變成雲端的敏捷，讓機器或者說是算法幫我們自動完成了。
我認為，未來微服務當中「微」代表的敏捷涵義會降低，開發者會更專注在「服務」上面，專注打造更合用的介面：
容器技術和無伺服器架構的影響
容器技術的崛起：大大簡化了微服務的部署和運行，使得管理和擴展更加靈活。
無伺服器架構的發展：進一步將運行環境抽象化，使得開發者不再需要管理底層基礎設施，只需關注應用邏輯和接口設計。
新興技術和理念的影響
人工智慧和自動化：AI和機器學習技術正在改變微服務的開發和運維方式，幫助開發者更加專注於業務邏輯。
DevOps和CI/CD：持續集成/持續部署（CI/CD）實踐正在成為微服務開發的標準，提高了開發效率和代碼質量。
API設計和開放平台**：未來的微服務架構將更加重視API設計和開放平台，強調API的一致性和可重用性。
總結
以上就是我看著微服務一路成長至今，提煉出來的小小拙見，給大家參考。你覺得什麼是微服務呢？在微服務的路上曾遇過哪些有趣的、踩雷的事情呢？也歡迎與我分享，我們下次見 :~)