＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊
＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊
將微服務處理後的靜態內容，部署至雲端平台的存儲機制，該機制可以經由內容傳遞網絡 (CDN, Content Delivery Network) 傳回給用戶端，進而可以提供效能、可擴展與較低成本網路傳遞。
提供一種目錄服務 (directory service) 的方式，而可以透過多樣化的檢索方式來取得所對應的微服務。
負責系統節點 (node) 的負載平衡，以及檢測故障 (failures)。
| Microservices | Monolithic | |
|---|---|---|
| 部署 (Deployment) | 應用程式基於特定的業務能力界定多個微服務，每個微服務爲獨立可各別被部署 | 應用程式只有一個單元的主體 |
| 耦合性 (Coupling) | 每個微服務已元件化，彼此間的溝通只透過 API 連結，因而形成良好的寬鬆耦合 (loose coupling) | 功能模組之間沒有良好的隔離而造成緊密耦合 (tight coupling) |
| 延展性 (Scalability) | 可以視微服務的負載情形而各別擴展系統資源 | 只能對系統整體採以複製 (clone) 的方式擴展 |
| 開發 (Development) | 可以依微服務的性質採不同的實現技術；每個微服務的實作團隊可以並行分工開發 | 只能選擇一種特定的實作技術；團隊的分工大都採以模組的切割，或依據分層的技術，需要較高的專案管理 Effort |
| 維護性 (Maintenance) | 每個微服務可以個別獨立建置、部署與維護 | 由於只有單體式的系統，所以管理與維護會依系統規模度而有着等比複雜度的提昇 |
| 適用系統性質 | 平台 (Platform)、產品 (Product) | 專案 (Project) |
| 適合系統規模 | 大型涵蓋多個業務範疇 (如 ERP) 的系統 | 小型團隊建構規模較小的系統 |
| 適合雲端服務 | 非常適合 | 系統規模越大，就越難以部署至雲端平台上 |
| 系統開發難易度 | • 需有總體架構規劃，架構師 (Architect) 或架構團隊需有效界定微服務的邊界 (Bounded Context)，以及制定微服務間的 API 協定 • 微服務平行分工的開發團隊需高度正向的密切溝通，持續整合不僅涵蓋技術，也包括人 | 因大都採以資料導向 (data oriented) 的開發模式，所以初期開發容易；但隨着系統規模度與變動性的議題，很容易導致複雜度的提昇，系統易淪於僵化而難以維護 |
＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊
單體式的挫折，導致微服務的架構風格 – 將應用程序建構爲多個微服務
＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊
要談及微服務，就需要回頭檢視典型單體 (Monolithic) 式的系統建構與開發方式。下圖可能是一個醫療領域的單體式系統架構。
這個「Monolithic」可以翻譯爲「單體」或「整體」，也就是我們一般典型的大堆頭式的開發系統，它有以下特點：