微服務

概述

優勢

第一，它解決了複雜問題。它把可能會變得龐大的單體應用程序分解成一套服務。雖然功能數量不變，可是應用程序已經被分解成可管理的塊或者服務。每一個服務都有一個明肯定義邊界的方式，如遠程過程調用（RPC）驅動或消息驅動 API。微服務架構模式強制必定程度的模塊化，實際上，使用單體代碼來實現是極其困難的。所以，使用微服務架構模式，個體服務能被更快地開發，並更容易理解與維護。

第二，這種架構使得每一個服務均可以由一個團隊獨立專一開發。開發者能夠自由選擇任何符合服務 API 契約的技術。固然，更多的組織是但願經過技術選型限制來避免徹底混亂的狀態。然而，這種自由意味着開發人員再也不有可能在這種自由的新項目開始時使用過期的技術。當編寫一個新服務時，他們能夠選擇當前的技術。此外，因爲服務較小，使用當前技術重寫舊服務將變得更加可行。

第三，微服務架構模式能夠實現每一個微服務獨立部署。開發人員根本不須要去協調部署本地變動到服務。這些變動一經測試便可當即部署。好比，UI 團隊能夠執行 A|B 測試，並快速迭代 UI 變動。微服務架構模式使得持續部署成爲可能。

最後，微服務架構模式使得每一個服務可以獨立擴展。您能夠僅部署知足每一個服務的容量和可用性約束的實例數目。此外，您可使用與服務資源要求最匹配的硬件。例如，您能夠在 EC2 Compute Optimized 實例上部署一個 CPU 密集型圖像處理服務，而且在 EC2 Memory-optimized 實例上部署一個內存數據庫服務。

缺點

微服務另外一個主要缺點是因爲微服務是一個分佈式系統，其使得 總體變得複雜。開發者須要選擇和實現基於消息或者 RPC的進程間通訊機制。此外，因爲目標請求可能很慢或者不可用，他們必需要編寫代碼來處理局部故障。雖然這些並非很複雜、高深，但模塊間經過語言級方法/過程調用相互調用，這比單體應用要複雜得多。

微服務的另外一個挑戰是分區數據庫架構。更新多個業務實體的業務事務是至關廣泛的。這些事務在單體應用中的實現顯得微不足道，由於單體只存在一個單獨的數據庫。在基於微服務的應用程序中，您須要更新不一樣服務所用的數據庫。一般不會選擇分佈式事務，不只僅是由於 CAP 定理。他們根本不支持現在高度可擴展的 NoSQL 數據庫和消息代理。您最後不得不使用基於最終一致性的方法，這對於開發人員來講更具挑戰性。

測試微服務應用程序複雜。例如，使用現代框架如 Spring Boot，只須要編寫一個測試類來啓動一個單體 web 應用程序並測試其 REST API。相比之下，一個相似的測試類對於微服務來講須要啓動該服務及其所依賴的全部服務，或者至少爲這些服務配置存根。再次聲明，雖然這不是一件高深的事情，但不要低估了這樣作的複雜性。

微服務架構模式的另外一個主要挑戰是實現了跨越多服務變動。例如，咱們假設您正在實現一個變動服務 A、服務 B 和 服務 C 的需求，其中 A 依賴於 B，且 B 依賴於 C。在單體應用程序中，您能夠簡單地修改相應的模塊、整合變動並一次性部署他們。相反，在微服務中您須要仔細規劃和協調出現的變動至每一個服務。例如，您須要更新服務 C，而後更新服務 B，最後更新服務 A。幸運的是，大多數變動只會影響一個服務，須要協調的多服務變動相對較少。

部署基於微服務的應用程序也是至關複雜的。一個單體應用能夠很容易地部署到基於傳統負載均衡器的一組相同服務器上。每一個應用程序實例都配置有基礎設施服務的位置（主機和端口），好比數據庫和消息代理。相比之下，微服務應用程序一般由大量的服務組成。例如，據 Adrian Cockcroft 瞭解到，Hailo 擁有 160 個不一樣的服務，Netflix 擁有的服務超過 600 個。

每一個服務都有多個運行時實例。還有更多的移動部件須要配置、部署、擴展和監控。此外，您還須要實現服務發現機制，使得服務可以發現須要與之通訊的任何其餘服務的位置（主機和端口）。比較傳統麻煩的基於票據（ticket-based）和手動的操做方式沒法擴展到如此複雜程度。所以，要成功部署微服務應用程序，須要求開發人員能高度控制部署方式和高度自動化。

一種自動化方式是使用現成的平臺即服務（PaaS），如 Cloud Foundry。PaaS 爲開發人員提供了一種簡單的方式來部署和管理他們的微服務。它讓開發人員避開了諸如採購和配置 IT 資源等煩惱。同時，配置 PaaS 的系統人員和網絡專業人員能夠確保達到最佳實踐以落實公司策略。

自動化微服務部署的另外一個方式是開發本身的 PaaS。一個廣泛的起點是使用集羣方案，如 Kubernetes，與 Docker 等容器技術相結合。