架構的演進:java
1.十年前:用戶->單一服務器->單一數據庫(支持十萬級用戶)node
2.五年前:用戶->負載均衡器->多臺服務器->緩存集羣->主從數據庫(支持百萬級用戶)數據庫
3.近兩年:用戶->負載均衡器->網關集羣->模塊1集羣->模塊1數據庫集羣緩存
->模塊2集羣->模塊2數據庫集羣服務器
->模塊3集羣->模塊3數據庫集羣restful
->......(支持千萬級用戶)架構
第三種方式稱爲微服務,如今的大公司基本採用這種方式負載均衡
每一個微服務可獨立運行在本身的進程裏;框架
一系列獨立運行的微服務共同構建起了整個系統;運維
每一個服務爲獨立的業務開發,一個微服務通常完成某個特定的功能,好比:訂單管理,用戶管理等;
微服務之間經過一些輕量級的通訊機制進行通訊,例如經過REST API或者RPC的方式進行調用。
易於開發和維護
因爲微服務單個模塊就至關於一個項目,開發這個模塊咱們就只需關心這個模塊的邏輯便可,代碼量和邏輯複雜度都會下降,從而易於開發和維護。
啓動較快
這是相對單個微服務來說的,相比於啓動單體架構的整個項目,啓動某個模塊的服務速度明顯是要快不少的。
局部修改容易部署
在開發中發現了一個問題,若是是單體架構的話,咱們就須要從新發布並啓動整個項目,很是耗時間,可是微服務則不一樣,哪一個模塊出現了bug咱們只須要解決那個模塊的bug就能夠了,解決完bug以後,咱們只須要重啓這個模塊的服務便可,部署相對簡單,沒必要重啓整個項目從而大大節約時間。
技術棧不受限
好比訂單微服務和電影微服務原來都是用java寫的,如今咱們想把電影微服務改爲nodeJs技術,這是徹底能夠的,並且因爲所關注的只是電影的邏輯而已,所以技術更換的成本也就會少不少。
按需伸縮
咱們上面說了單體架構在想擴展某個模塊的性能時不得不考慮到其它模塊的性能會不會受影響,對於咱們微服務來說,徹底不是問題,電影模塊經過什麼方式來提高性能沒必要考慮其它模塊的狀況。
運維要求較高
對於單體架構來說,咱們只須要維護好這一個項目就能夠了,可是對於微服務架構來說,因爲項目是由多個微服務構成的,每一個模塊出現問題都會形成整個項目運行出現異常,想要知道是哪一個模塊形成的問題每每是不容易的,由於咱們沒法一步一步經過debug的方式來跟蹤,這就對運維人員提出了很高的要求。
分佈式的複雜性
對於單體架構來說,咱們能夠不使用分佈式,可是對於微服務架構來講,分佈式幾乎是必會用的技術,因爲分佈式自己的複雜性,致使微服務架構也變得複雜起來。
接口調整成本高
好比,用戶微服務是要被訂單微服務和電影微服務所調用的,一旦用戶微服務的接口發生大的變更,那麼全部依賴它的微服務都要作相應的調整,因爲微服務可能很是多,那麼調整接口所形成的成本將會明顯提升。
重複勞動
對於單體架構來說,若是某段業務被多個模塊所共同使用,咱們即可以抽象成一個工具類,被全部模塊直接調用,可是微服務卻沒法這樣作,由於這個微服務的工具類是不能被其它微服務所直接調用的,從而咱們便不得不在每一個微服務上都建這麼一個工具類,從而致使代碼的重複
微服務的基礎名詞:
網關:路由轉發+過濾器
服務註冊發現:調用和被調用方的信息維護
配置中心:管理配置,動態更新
鏈路追蹤:分析調用鏈路耗時
熔斷:保護本身和被調用方
常見的微服務框架:
1.Dubbo系列:Zookeeper+Dubbo+SpringMVC/SpringBoot
應用:阿里,滴滴
通訊方式:RPC
註冊中心:Zookeeper、Redis
配置中心:Diamond
2.SpringCloud系列:Spring系列+Netflix組件
通訊方式:HTTP restful
註冊中心:Eruka、Consul
註冊中心:Config
熔斷器:Hystrix
網關:Zuul
分佈式追蹤系統:Sleuth+Zipkin
區別和選擇:
1.Dubbo基於RPC,速度略高於Spring Cloud系列
2.Spring Cloud源於Spring,組件衆多
具體的區別能夠參考大佬的博客:
http://www.javashuo.com/article/p-bazfacgl-bc.html
比喻:
Dubbo
使用Dubbo構建的微服務架構就像組裝電腦,各環節咱們的選擇自由度很高。
可是最終結果頗有可能由於一條內存質量不行就點不亮了,老是讓人不怎麼放心。
可是若是你是一名高手,那這些都不是問題。
Spring Cloud
而Spring Cloud就像品牌機。
在Spring Source的整合下,作了大量的兼容性測試,保證了機器擁有更高的穩定性。
可是若是要在使用非原裝組件外的東西,就須要對其基礎有足夠的瞭解。