微服務爲何會出現?在學習Springboot的時候知道Springboot極大的簡化了咱們的開發,咱們能夠快速的進行業務開發,Springboot單體應用在項目的開發初期可以知足咱們需求,這種單體架構優勢很是的明顯:java
容易測試:本地就能夠起完整的系統,不須要外部依賴。數據庫
容易開發:咱們只需引入依賴,選擇框架即可快速開發。安全
易於部署:單體架構部署也較簡單,直接打包便可。服務器
易於水平伸縮:這裏的收縮時指當咱們須要多個服務器時也比較方便網絡
在項目剛開始的時候咱們能夠快速的開發,一個長壽的項目,需求不斷增長,原先的模塊也再不斷優化,這個時候單體架構的缺點開始顯現:架構
代碼膨脹,難以維護:代碼愈來愈多,開發人員也就愈來愈多,一旦出現bug,定位、修復成本很高,並且人員太多,代碼都放在一塊兒,容易引發衝突,且因爲業務集中在一塊兒,業務複雜,很難全局把握,改一個bug可能會再多出兩個bug。負載均衡
構建、部署成本大:項目太大,構建和部署就會很是慢,效率低下。框架
上手困難:互聯網企業人員更迭快,代碼過於集中,致使業務很是複雜,新人想要上手變得很是困難。運維
技術創新困難:代碼過於集中,咱們很難使用到新技術,由於改動實在太大,容易出現問題。異步
可擴展性差:這裏的可擴展性是指由於項目都必須部署在一臺服務器中,那項目所要的資源會愈來愈大,這樣咱們只能擴展硬件(集羣能夠分散壓力,可是單個應用所要的資源仍是不能少的)。
微服務的出現就是爲了解決這些問題,看看是如何解決的,微服務將系統拆分紅一個個小服務(通常是按照模塊進行拆分,好比用戶服務、支付服務、訂單服務、出入庫服務等),那麼即便業務量增長,咱們也能夠經過新增服務的形式來解決,這樣代碼就不會膨脹,構建、部署也不是問題。因爲服務不在一個框架中,那麼咱們能夠很方便的對某一個服務進行技術創新,對一個服務的進行技術升級改動不會太大,而當咱們有新技術產生時,咱們就能夠也能夠應用到新服務中。
微服務並無明確的定義,下面是一種比較通用的理解:
使用一套小服務來開發單個應用的方式,每一個服務運行在獨立的進程裏,通常採用輕量級的通信機制互聯,而且它們能夠經過自動化方式部署。
經過定義咱們能夠知道微服務的特徵:
微服務是由一系列的小服務共同組成的。
每一個微服務都有本身獨立的進程。
每一個服務都是獨立的業務開發,單一原則
每一個服務都能獨立的部署(通常部署在容器中)。
微服務之間經過輕量級通訊機制進行通訊
分佈式的管理。
講到這裏,對微服務的概念應該有了必定的瞭解,下面畫的一個比較簡單的微服務架構圖
圖中能夠看出每一個微服務都有本身獨立的數據庫,每一個服務都會暴露本身的REST API 給外部調用,服務之間會存在互相調用關係,而每一個服務都有可能被客戶端直接調用,另外咱們看到還有一個API Gateway,這是統一個服務接口,它一般能夠有如下做用:
1. 提供統一服務入口,讓微服務對前臺透明
2. 聚合後臺的服務,節省流量,提高性能
3. 提供安全,過濾,流控等API管理功能
凡是都有兩面性,一個技術也不可能只有優勢而沒有缺點,微服務的優勢不少,微服務的優勢其實就是單體架構的缺點的反面,由於微服務自己就是來解決單體架構問題的
獨立性:微服務從構建、部署,擴容、縮容、甚至數據庫都是獨立的,服務只要管理好本身就能夠,這樣就極大的下降了系統的複雜性。服務徹底獨立獨立以後,從構建到部署,到後期的擴容縮容都會變得簡單,基本就解決單體架構上碰到的不少問題。
敏捷性:敏捷性是針對開發人員來說的,服務拆分以後,能夠獨立專注開發,開發人員能夠經過API快速的瞭解本服務的業務,互相之間並不影響。
技術棧靈活:微服務能夠徹底獨立的擁有技術棧,只須要保證提供的服務API不變,內部使用何種技術棧很靈活。
高效的團隊:微服務的團隊會比較小,那溝通就會變得更加高效。
沒有最好的架構,只有最適合的架構,既然有這麼多優勢,那缺點確定也有很多
服務的拆分:服務如何拆分實際上是很是重要且複雜的,服務拆分的太大或過小都不合適,這須要咱們有很是豐富的經驗,而這個在單體中是不存在的。
數據一致性:單體架構中只有一個數據庫,咱們能夠經過事務解決多表之間數據的一致性,而在微服務中,每一個服務中都有本身獨立的數據庫,要保證服務之間的數據一致性也是一個大的挑戰。
服務間通訊成本:服務間互相通訊也須要時間成本。
測試複雜性提升:服務之間存在依賴,那麼測試時就必須啓動這些依賴,這就增長了複雜度。
運維部署複雜性提升:微服務應用由大量服務組成,每一個服務會起多個實例,要進行配置,部署,擴展和監控。此外,還須要實現服務發現機制
要實現微服務,咱們須要解決如下幾個技術點:
客戶端訪問服務:這個上面架構圖中已經給出,使用API Gateway。
服務通訊:服務與服務之間的通訊有兩種方式,同步與異步:
同步通訊中又分爲兩種:Http與RPC,http訪問很好理解,相信通常的系統也會調用外部的一些服務,這些基本都是使用http,由於http能夠跨語言,跨客戶端,相對使用較廣,如http Client ,而RPC也有本身的優勢,首先是效率更高,更安全可控,特別是內部服務互相調用時,用統一的RPC框架,服務的侵入性更低,調用服務甚至就像調用本身的服務同樣簡單,如dubbo(注:dubbo只能使用java語言)。
異步通訊是經過消息隊列來實現,異步通訊的好處是能夠下降服務之間的耦合,有削峯的好處,並且使用消息隊列能夠方便的實現數據的最終一致性。
產品服務啓動了三個,他們都會去註冊中心進行註冊,註冊成功後,會經過心跳包告訴註冊中心是否在線或者下線,而訂單服務要去調用產品服務,會先去註冊中心進行查詢,查詢出相應的地址而後再去調用產品服務。
服務崩潰處理:在運行期間會出現服務崩潰的狀況,好比網絡緣由,阻塞緣由,這個時候服務並非下線,仍是可以被找到,咱們必須妥善要進行處理,不然可能會致使整個系統的崩潰,處理的方式有:
重試機制
熔斷機制
降級機制
限流機制
以上都是微服務的一些概念,既然有天上飛的概念,就有落地的實現,如今主流的微服務架構有兩套解決方案:Dubbo+Zookeeper與SpringCloud。