Spring Cloud學習筆記之微服務架構

[TOC] ###什麼是微服務

    微服務構架方法是以開發一種小型服務的方式，來開發一個獨立的應用系統的。     其中每一個小型服務都運行在本身的進程中，並常常採用HTTP資源API這樣輕量的機制來相互通訊。     這些服務圍繞業務功能進行構建，並能經過全自動的部署機制來進行獨立部署。     這些微服務可使用不一樣的語言來編寫，而且可使用不一樣的數據存儲技術。     對這些微服務咱們僅作最低限度的集中管理。

###架構優勢 ####1. 易於開發和維護     一個微服務只關注一個特定的業務功能。因此它的業務清晰，代碼量較少。開發和維護單個微服務相對是比較簡單的，而整個應用是由若干個微服務構建而成的，因此整個應用也會維持在可控狀態。 ####2. 單個微服務啓動較快     單個微服務代碼量較少，因此啓動會比較快 ####3. 局部修改容易部署     單體應用只要有修改，就得從新部署整個應用，微服務解決了這樣的問題。通常來說，對某個微服務進行修改，只須要部署這個服務便可。 ####4. 技術棧不受限     在微服務中，咱們能夠結合項目業務及團隊的特色，合理選擇技術棧。例如某些服務可以使用關係型數據庫，某些應用有圖形計算的需求，可使用Neo4j,某些應用服務有併發需求，能夠採用內存數據庫(redis、couchbase);甚至能夠根據須要，部分微服務使用JAVA開發，部分微服務使用NodeJS進行開發。 ####5. 按需伸縮     咱們能夠根據需求，實踐細粒度的擴展。例如，系統中某個微服務遇到了瓶頸。咱們能夠結合這個微服務的業務特色，增長內存，升級CPU或者增長節點。 ###架構的挑戰 ####1. 運維要求較高     更多的服務意味着更多的運維投入。在單體架構中，只須要保證一個應用的正常運行；而在微服務中，須要保證幾十個乃至幾百個服務的正常運行與協做。 ####2. 分佈式固有的複雜性     使用微服務構建的是分佈式系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都給咱們帶來了很大的挑戰。 ####3. 接口調整成本高     微服務之間經過接口進行通訊。若是修改某一個微服務的API。可能全部使用了該接口的微服務都須要作調整。 ####4. 重複勞動     不少服務可能都會使用到相同的功能。再這個功能並無達到分解爲一個微服務的程序，這個時候，可能各個服務都會開發這一功能，從而致使代碼重複。 ###設計原則     微服務有優勢，也有缺點，咱們須要拈輕怕重,因此在實踐中，須要遵照一些原則。 ####1. 單一職責原則     高內聚，低耦合     遵照單一職責原則，將不一樣的職責封裝到不一樣的類或模塊中 ####2. 服務自治原則     每一個服務應當具有獨立的業務能力，依賴與運行環境 ####3. 輕量級通訊原則 ####4. 接口明確原則     每一個服務的對外接口應該明肯定義，並儘可能保持不變

Spring Cloud: http://projects.spring.io/spring-cloud/

GitHub: https://github.com/spring-cloud/