微服務,是一個小的、鬆耦合的分佈式服務。 數據庫
爲何須要微服務:架構
1)單體系統部署在一個進程中,修改了一個小功能,爲了部署上線就會影響其餘功能。併發
2)單體應用各個功能模塊的使用場景、併發量、消耗資源類型各不相同,對於資源的利用又互相影響,框架
這樣使得對各個模塊的系統容量很難給出較爲準確的評估。運維
微服務是系統架構的一種設計風格,它的主旨是將一個本來獨立的系統拆分紅多個在各自獨立進程中運行的小型服務,分佈式
服務之間經過基於HTTP的RESTful API進行通訊協做。微服務
實施微服務須要信奉的重要概念是:分解和分離應用程序的功能,使他們徹底彼此獨立。 工具
1.單體應用拆分爲分佈式系統後,進程間的通訊機制和和故障處理措施變得更加複雜。組件化
---解決方案:RPC框架,如HSF、Dubbo能夠支持多種通訊協議,Spring Cloud能夠很是好地支持RESTful調用性能
2.服務調用的分佈式事務問題變得異常突出。
---解決方案:沒有通用的解決方案,最具挑戰的技術難題。
3.微服務數量衆多,其測試、運維變得更加困難。
---運用Docker、Devops技術及共有云PAAS平臺自動化運維工具。
一)服務組件化
組件,是一個可獨立更換和升級的單元。
二)按業務組織團隊
優點:一是能夠服務內部修改產生的內耗,二是團隊邊界更加清晰。
三)作「產品」的態度
四)去中心化治理
當咱們採用集中化架構治理方案時,一般在技術平臺上都會制定統一的標準,可是每種
技術平臺都有其短板,若是解決很差,極可能稱爲系統瓶頸。微服務構架系統中的各個
組件能夠針對不一樣業務選擇不一樣的技術平臺。
五)去中心化數據管理
概念:讓每一個服務管理自由的數據庫。
優點:讓數據管理更加細緻化,經過採用更合適的技術讓數據存儲和性能達到最優。
劣勢:數據一致性問題。
六)基礎設施自動化
微服務架構中須要運維人員關注的問題成倍增加,因此,務必從一開始就構建起"持續交付"
平臺來支撐整個實施過程,該平臺須要:
1)自動化測試
2)自動化部署
七)容錯設計
八)演進式設計
雲計算的基本模式:
1)基礎設施即服務(Infrastructure as a Service, IaaS)
2)平臺即服務(Platform as a Service, Paas)
3)軟件即服務(Software as a Service, Saas)
4)容器即服務(Container as a Service, Caas)
爲何是雲和微服務:
彈性!!!