1.SpringCloud和Dubbo
SpringCloud和Dubbo都是如今主流的微服務架構
SpringCloud是Apache旗下的Spring體系下的微服務解決方案
Dubbo是阿里系的分佈式服務治理框架
從技術維度上,其實SpringCloud遠遠的超過Dubbo,Dubbo自己只是實現了服務治理,而SpringCloud如今以及有21個子項目之後還會更多
因此其實不少人都會說Dubbo和SpringCloud是不公平的
可是因爲RPC以及註冊中心元數據等緣由,在技術選型的時候咱們只能兩者選其一,因此咱們經常爲用他倆來對比
服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義
服務的註冊中心來看,Dubbo使用了第三方的ZooKeeper做爲其底層的註冊中心,實現服務的註冊和發現,SpringCloud使用Spring Cloud Netflix Eureka實現註冊中心,固然SpringCloud也可使用ZooKeeper實現,但通常咱們不會這樣作
服務網關,Dubbo並無自己的實現,只能經過其餘第三方技術的整合,而SpringCloud有Zuul路由網關,做爲路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分佈式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素git
2.技術選型
目前國內的分佈式系統選型主要仍是Dubbo畢竟國產,並且國內工程師的技術熟練程度高,而且Dubbo在其餘維度上的缺陷能夠由其餘第三方框架進行集成進行彌補
而SpringCloud目前是國外比較流行,固然我以爲國內的市場也會慢慢的偏向SpringCloud,就連劉軍做爲Dubbo重啓的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,並非起衝突編程
3.Rest和RPC對比
其實若是仔細閱讀過微服務提出者馬丁福勒的論文的話能夠發現其定義的服務間通訊機制就是Http Rest
RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,咱們須要爲每個微服務進行接口的定義,並經過持續繼承發佈,須要嚴格的版本控制纔不會出現服務提供和調用之間由於版本不一樣而產生的衝突
而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是經過一個約定進行規範,但也有可能出現文檔和接口不一致而致使的服務集成問題,但能夠經過swagger工具整合,是代碼和文檔一體化解決,因此REST在分佈式環境下比RPC更加靈活
這也是爲何當當網的DubboX在對Dubbo的加強中增長了對REST的支持的緣由後端
4.文檔質量和社區活躍度
SpringCloud社區活躍度遠高於Dubbo,畢竟因爲梁飛團隊的緣由致使Dubbo中止更新迭代五年,而中小型公司沒法承擔技術開發的成本致使Dubbo社區嚴重低落,而SpringCloud異軍突起,迅速佔領了微服務的市場,背靠Spring混的風生水起
Dubbo通過多年的積累文檔至關成熟,對於微服務的架構體系各個公司也有穩定的現狀緩存
二.SpringBoot和SpringCloud
SpringBoot是Spring推出用於解決傳統框架配置文件冗餘,裝配組件繁雜的基於Maven的解決方案,旨在快速搭建單個微服務
而SpringCloud專一於解決各個微服務之間的協調與配置,服務之間的通訊,熔斷,負載均衡等
技術維度並相同,而且SpringCloud是依賴於SpringBoot的,而SpringBoot並非依賴與SpringCloud,甚至還能夠和Dubbo進行優秀的整合開發
總結:
SpringBoot專一於快速方便的開發單個個體的微服務
SpringCloud是關注全局的微服務協調整理治理框架,整合並管理各個微服務,爲各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務
SpringBoot不依賴於SpringCloud,SpringCloud依賴於SpringBoot,屬於依賴關係
SpringBoot專一於快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架
三.Eureka和ZooKeeper均可以提供服務註冊與發現的功能,請說說兩個的區別
1.ZooKeeper保證的是CP,Eureka保證的是AP
ZooKeeper在選舉期間註冊服務癱瘓,雖然服務最終會恢復,可是選舉期間不可用的
Eureka各個節點是平等關係,只要有一臺Eureka就能夠保證服務可用,而查詢到的數據並非最新的
自我保護機制會致使
Eureka再也不從註冊列表移除因長時間沒收到心跳而應該過時的服務
Eureka仍然可以接受新服務的註冊和查詢請求,可是不會被同步到其餘節點(高可用)
當網絡穩定時,當前實例新的註冊信息會被同步到其餘節點中(最終一致性)
Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況,而不會像ZooKeeper同樣使得整個註冊系統癱瘓
2.ZooKeeper有Leader和Follower角色,Eureka各個節點平等
3.ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分區問題
4.Eureka本質上是一個工程,而ZooKeeper只是一個進程服務器
四.微服務之間是如何獨立通信的
遠程過程調用(Remote Procedure Invocation)
也就是咱們常說的服務的註冊與發現
直接經過遠程過程調用來訪問別的service。
優勢:
簡單,常見,由於沒有中間件代理,系統更簡單
缺點:
只支持請求/響應的模式,不支持別的,好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應
下降了可用性,由於客戶端和服務端在請求過程當中必須都是可用的
2、消息
使用異步消息來作服務間通訊。服務間經過消息管道來交換消息,從而通訊。
優勢:
把客戶端和服務端解耦,更鬆耦合
提升可用性,由於消息中間件緩存了消息,直到消費者能夠消費
支持不少通訊機制好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應
缺點:
消息中間件有額外的複雜性
五.什麼是服務熔斷?什麼是服務降級
在複雜的分佈式系統中,微服務之間的相互調用,有可能出現各類各樣的緣由致使服務的阻塞,在高併發場景下,服務的阻塞意味着線程的阻塞,致使當前線程不可用,服務器的線程所有阻塞,致使服務器崩潰,因爲服務之間的調用關係是同步的,會對整個微服務系統形成服務雪崩
爲了解決某個微服務的調用響應時間過長或者不可用進而佔用愈來愈多的系統資源引發雪崩效應就須要進行服務熔斷和服務降級處理。
所謂的服務熔斷指的是某個服務故障或異常一塊兒相似顯示世界中的「保險絲"當某個異常條件被觸發就直接熔斷整個服務,而不是一直等到此服務超時。
服務熔斷就是至關於咱們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,經過維護一個本身的線程池,當線程達到閾值的時候就啓動服務降級,若是其餘請求繼續訪問就直接返回fallback的默認值網絡
六.微服務的優缺點分別是什麼?說下你在項目開發中碰到的坑
優勢
每個服務足夠內聚,代碼容易理解
開發效率提升,一個服務只作一件事
微服務可以被小團隊單獨開發
微服務是鬆耦合的,是有功能意義的服務
能夠用不一樣的語言開發,面向接口編程
易於與第三方集成
微服務只是業務邏輯的代碼,不會和HTML,CSS或者其餘界面組合
開發中,兩種開發模式
先後端分離
全棧工程師
能夠靈活搭配,鏈接公共庫/鏈接獨立庫
缺點
分佈式系統的負責性
多服務運維難度,隨着服務的增長,運維的壓力也在增大
系統部署依賴
服務間通訊成本
數據一致性
系統集成測試
性能監控
七.你所知道的微服務技術棧有哪些?請列舉一二
多種技術的集合體
咱們在討論一個分佈式的微服務架構的話,須要哪些維度
維度(SpringCloud)
服務開發
SpringBoot
Spring
SpringMVC
服務配置與管理
Netfilx公司的Archaiusm,阿里的Diamond
服務註冊與發現
Eureka,ZooKeeper
服務調用
Rest,RPC,gRPC
服務熔斷器
Hystrix
服務負載均衡
Ribbon,Nginx
服務接口調用
Feign
消息隊列
Kafka,RabbitMq,ActiveMq
服務配置中心管理
SpringCloudConfing
服務路由(API網關)
Zuul
事件消息總線
SpringCloud Bus
…
架構