雲端架構設計的四種範式 - 單體、微服務、巨石與無服務
在軟體開發的世界中,單體應用程式和微服務是兩種常見的架構風格。而除了這兩個主流的架構風格外,近年來也興起了巨石架構與無服務架構。這四種架構風格各有優缺點,適用於不同的場景。
本文將介紹這四種架構風格的特點,並比較它們之間的差異，希望能幫助讀者更好地理解這四種架構風格,並選擇適合自己的架構風格。
單體應用程式 (Monolith)
在軟體發展的早期，單體應用程式是一種常見的架構風格。單體應用程式是一種將所有功能模組都打包在一起的架構風格。
而這種架構風格常見的特徵是是將所有功能模組都部署在同一隻程式中，並且這些功能模組之間是緊密耦合的。
優點
開發和部署簡單
單體應用程式的開發和部署相對簡單，因為所有功能都集中在一個單一的應用程式中。開發人員只需要關注一個程式專案，而不需要處理複雜的服務之間的通訊和協調問題。同時，部署也相對簡單，只需要將整個應用程式打包並部署到伺服器上即可。
資源共享方便
在單體應用程式中，所有功能都運行在同一台機器中，因此可以方便地共享資源，如記憶體、CPU 等。這樣可以避免服務之間的資源競爭和浪費，提高應用程式的性能和效率。
單一程式專案，易於維護和更新
單體應用程式只有一個程式專案，因此維護和更新相對容易。開發人員可以快速地定位和修復問題，並且可以方便地進行程式碼重構和優化。同時，單一程式專案也便於進行版本控制和發布管理。
適合小型應用程式或者團隊剛開始接觸微服務架構
對於小型應用程式或者團隊剛開始接觸微服務架構，單體應用程式是一個不錯的選擇。因為單體應用程式的開發和部署相對簡單，對團隊的技術能力要求也相對較低。同時，單體應用程式也可以作為微服務化的第一步，幫助團隊逐步熟悉微服務架構的開發和部署流程。
較低門檻的基礎設施和運維成本
相比於微服務架構，單體應用程式對基礎設施和運維的要求相對較低。因為所有功能都集中在一個應用程式中，因此不需要複雜的負載均衡、服務監測等機制。同時，單體應用程式的部署和運維也相對簡單，對運維團隊的技術能力要求也相對較低。
缺點
程式碼複雜度高，難以維護
隨著應用程式的不斷發展和擴大，單體應用程式的程式碼會變得越來越複雜，不同功能之間的耦合度也會越來越高。這樣會導致程式碼的可讀性和可維護性變差，開發人員需要花費更多的時間和精力來理解和修改程式碼。同時，程式碼的複雜度也會增加引入 bug 和安全漏洞的風險。
技術堆疊單一，難以引入新技術
單體應用程式通常使用單一的技術堆疊，如 Java、.NET 等生態系。這樣會導致應用程式難以引入新的技術和工具，限制了應用程式的發展和創新。同時，單一的技術堆疊也會增加團隊的技術風險，如果該技術堆疊出現問題或者被淘汰，整個應用程式都會受到影響。
開發效率低，團隊協作困難
在單體應用程式中，不同功能之間的耦合度較高，開發人員需要了解整個應用程式的程式碼結構和邏輯，才能進行開發和維護工作。這樣會導致開發效率較低，尤其是對於新加入的開發人員來說，需要花費大量的時間和精力來熟悉程式碼。同時，單體應用程式也會導致團隊協作困難，不同團隊之間的溝通和協調成本較高。
微服務 (Microservices)
隨著軟體發展，微服務架構風格逐漸興起。微服務是一種將功能模組拆分成多個服務的架構風格。
而這種架構風格的特點是將功能模組拆分成多個服務，每個服務都是獨立的，並且這些服務之間是鬆散耦合的。
優點
單一職責，易於開發和維護
微服務架構中，每個服務都有明確的職責和邊界，專注於做好一件事情。這樣可以降低服務之間的耦合度，提高服務的內聚性，使得服務更加易於開發和維護。同時，單一職責也使得服務的程式碼量相對較小，易於理解和修改。
技術堆疊靈活，易於創新
微服務架構允許不同的服務使用不同的技術堆疊，如程式語言、框架、資料庫等。這樣可以根據服務的特點和需求，選擇最適合的技術堆疊，提高開發效率和服務性能。同時，技術堆疊的靈活性也使得團隊可以更加容易地引入新的技術和工具，促進創新。
獨立部署，易於擴展
微服務架構中，每個服務都可以獨立地部署和擴展，而不會影響其他服務。這樣可以根據服務的負載和需求，靈活地調整服務的部署和擴展策略，提高服務的可用性和性能。同時，獨立部署也使得服務的升級和維護更加方便，降低了服務之間的影響。
團隊協作更加高效
微服務架構通常與 DevOps 和持續交付等流程相結合，使得團隊可以更加高效地協作和交付。每個團隊可以負責一個或多個服務，並且可以針對目的或自身的背景選擇合適的技術堆疊進行開發、測試和部署，而不需要過多地依賴其他團隊。這樣可以提高團隊的自主性和效率，加速應用程式的交付和創新。
缺點
服務之間呼叫複雜，性能損耗較大
微服務架構中，服務之間通過網絡進行通訊和呼叫，這樣會引入額外的性能損耗和複雜性。服務之間的呼叫需要進行序列化和反序列化、網絡傳輸等操作，這些操作都會消耗一定的時間和資源。同時，服務呼叫的複雜性也會增加系統的運維和監測難度。
資料一致性難以保證
微服務架構中，每個服務都有自己的資料存儲，而且服務之間的資料通常是異構的。這樣會導致資料一致性難以保證，尤其是在分佈式事務和跨服務查詢等場景下。需要採用一些複雜的技術手段，如補償交易、事件來源等，來保證資料的一致性和完整性。
運維和監測難度大
微服務架構由多個獨立的服務組成，每個服務都有自己的部署、運行和監測需求。這樣會導致運維和監測的難度大大增加，需要更多的人力和工具來支持。同時，服務之間的依賴關係也變得更加複雜，出現問題時除錯和定位也更加困難。
開發和測試成本高
微服務架構雖然提高了服務的獨立性和靈活性，但也增加了開發和測試的成本。每個服務都需要進行獨立的開發、測試和部署，而且服務之間的整合和端到端測試也變得更加複雜。這樣會導致開發和測試的時間和成本增加，需要更多的人力和資源投入。
巨石架構 (Monolithic Application)
一個應用程式隨著時代的演進，可能會同時使用單體應用程式和微服務兩種架構風格。
例如，可能使用單體應用程式架構風格來開發核心功能模組，然後使用微服務架構風格來開發一些獨立的新功能。
有幾個場景可能會使用這種方式：
需要高度擴展性
如果應用程式中的某些功能需要高度的擴展性和彈性，而其他功能相對穩定，可以考慮將需要高度擴展性和彈性的功能拆分為獨立的微服務，其他功能仍然保留在單體應用程式中。這樣可以在保證應用程式穩定性的同時，提高部分功能的擴展性和彈性。
新功能的開發和部署需要獨立進行
如果應用程式中有一些新功能需要獨立開發和部署，可以考慮將這些新功能拆分為獨立的微服務，而不影響其他功能的運行。這樣可以加快新功能的開發和部署速度，同時也降低了對其他功能的影響。
需要使用不同的技術堆疊時
如果應用程式中的某些功能需要使用不同的技術堆疊，可以考慮將這些功能拆分為獨立的微服務，每個服務都可以使用最適合的技術堆疊來開發。這樣可以提高開發效率，同時也降低了技術堆疊之間的耦合性。
需要逐步將單體應用程式拆分為微服務
如果應用程式目前是一個單體應用程式，但是隨著業務的發展，需要逐步將其拆分為微服務，可以考慮先將一些相對獨立的功能拆分出來，作為獨立的微服務運行。這樣可以在不影響整個應用程式運行的情況下，逐步完成微服務化的過程。
無服務架構 (Serverless)
無服務架構是一種較新的架構風格，其核心思想是將應用程式拆分成更小的、獨立的函數，並由雲端動態調度執行。開發者無需關心服務器的配置和管理，只需專注於編寫商業邏輯程式碼。
優點
按需付費，成本更低
無服務架構按照函數的實際執行次數和資源消耗計費，而不需要一直運行服務器。對於流量波動較大的應用，無服務架構可以顯著降低成本。而閒置時幾乎不產生費用。
自動彈性擴展
無服務架構由雲端負責調度和擴展。根據請求量的變化，平台會自動調整函數實例的數量，實現了真正的彈性擴展。開發者無需編寫擴展邏輯，也無需擔心機器資源不足的問題。
開發部署更簡單
無服務架構簡化了應用的開發和部署流程。開發者只需編寫函數程式碼並上傳到雲端，平台會自動完成部署和發布。這種部署方式比起傳統的應用部署更加簡單和快捷。
缺點
冷啟動延遲
無服務架構在函數長時間未被呼叫時，可能會回收函數實例以節省資源。當新的請求到來時，需要重新啟動函數實例，這個過程會導致較高的延遲，即冷啟動問題。對於對延遲敏感的應用，需要採取一定的優化措施。
運行時間受限
無服務架構中的函數通常有最大運行時間的限制。這意味著無服務函數不適合執行長時間運行的任務，如複雜的數據處理或批量作業。
例如: AWS Lambda 的最大運行時間為 15 分鐘、Azure Functions 的最大運行時間為 5 分鐘。
結論
單體應用、微服務、巨石架構和無服務架構，代表了目前主流的幾種軟體架構風格。每種架構都有其獨特的優勢和限制，適用於不同的場景。
選擇哪種架構需要綜合考慮團隊的技術能力、業務需求、發展階段等諸多因素。單體應用適合於業務邏輯簡單、流量較小的早期階段;微服務適合業務複雜、流量大、需要靈活擴展的互聯網應用;巨石架構可作為單體到微服務演進的過渡方案;無服務架構適合事件驅動、高併發、彈性擴展的場景。
而架構演進是一個漸進的過程，需要在實踐中不斷探索和優化。無論採用何種架構，都需要配套的開發流程、運維流程，才能構建穩定高效能的應用。現代雲原生技術如容器、Kubernetes 等，為各種架構的落地實施提供了有力的支持。
軟體架構將隨著技術的發展和業務的變化而不斷演進，選擇適合自己的那一款，才可能在競爭中生存。
而怎麼樣的架構，你可能會需要經過一段時間的摸索和實踐，才能找到最適合你的架構風格。
並且無論是哪種架構風格，都需要建立起良好的開發流程、運維流程與監控機制，才能確保應用程式的穩定運行。