SpringCloud學習筆記（一）：SpringCloudt相關面試題

什麼是微服務？

看筆記二

微服務之間是如何獨立通信的？

服務與服務間採⽤輕量級的通訊機制互相協做（一般是基於HTTP協議的RESTful API）

SpringCloud和Dubbo有什麼區別？

Dubbo是經過rpc遠程調用，微服務cloud是經過rest調用。

最大區別：
SpringCloud拋棄了Dubbo的RPC通訊，採用的是基於HTTP的REST方式。
嚴格來講，這兩種方式各有優劣。雖然從必定程度上來講，後者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。並且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。

品牌機與組裝機的區別
很明顯，Spring Cloud的功能比DUBBO更增強大，涵蓋面更廣，並且做爲Spring的拳頭項目，它也可以與Spring Framework、Spring Boot、Spring Data、Spring Batch等其餘Spring項目完美融合，這些對於微服務而言是相當重要的。使用Dubbo構建的微服務架構就像組裝電腦，各環節咱們的選擇自由度很高，可是最終結果頗有可能由於一條內存質量不行就點不亮了，老是讓人不怎麼放心，可是若是你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，作了大量的兼容性測試，保證了機器擁有更高的穩定性，可是若是要在使用非原裝組件外的東西，就須要對其基礎有足夠的瞭解。

社區支持與更新力度
最爲重要的是，DUBBO中止了5年左右的更新，雖然2017.7重啓了。對於技術發展的新需求，須要由開發者自行拓展升級（好比噹噹網弄出了DubboX），這對於不少想要採用微服務架構的中小軟件組織，顯然是不太合適的，中小公司沒有這麼強大的技術能力去修改Dubbo源碼+周邊的一整套解決方案，並非每個公司都有阿里的大牛+真實的線上生產環境測試過。

SpringBoot和SpringCloud，請你談談對他們的理解。

SpringBoot專一於快速方便的開發單個個體微服務。

SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，
爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務

SpringBoot能夠離開SpringCloud獨立使用開發項目， 可是SpringCloud離不開SpringBoot ，屬於依賴的關係.

SpringBoot專一於快速、方便的開發單個微服務個體，SpringCloud關注全局的服務治理框架。

什麼是服務熔斷？什麼是服務降級？

服務熔斷
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級， 進而熔斷該節點微服務的調用，快速返回"錯誤"的響應信息。 當檢測到該節點微服務調用響應正常後恢復調用鏈路。在SpringCloud框架裏熔斷機制經過Hystrix實現。Hystrix會監控微服務間調用的情況，當失敗的調用到必定閾值，缺省是5秒內20次調用失敗就會啓動熔斷機制。熔斷機制的註解是@HystrixCommand。

服務降級
總體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啓回來。

如上圖，client同時訪問abc三個服務，某個時間訪問a的人忽然變多了，這個時候c訪問的人不多，就須要將c中的資源借到a中，c中沒有了資源，不如直接將c關掉，但是c關掉的話，仍是會有人不斷的來訪問，這個時候怎麼辦？就像銀行的服務窗口，c窗口的人都去a窗口幫忙了，還開着，人會不停地過來，這個時候就須要若是有人來訪問c的話，就返回一個json格式的數據，告知client，以便client作出相應的對策。

服務降級處理是在客戶端實現完成的，與服務端沒有關係

微服務的優缺點分別是什麼？說下你在項目開發中碰到的坑。

優勢

每一個服務足夠內聚、租後小，代碼容易理解，這樣能聚焦一個置頂的功能和也無需求。
開發簡單、開發效率提升，一個服務可能就是專注的幹一件事。
微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段仍是部署階段都是獨立的。
微服務能使用不一樣的語言開發。
易於和第三方集成，微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如kenkins，Hudson，banboo。微服務易於被一個開發人員理解，修改和維護，這樣的小團隊可以更關注本身的工做成果。無需經過合做才能體現價值。
微服務容許你李永榮和最新技術。
微服務只是業務邏輯代碼，不會和heml css和其餘的界面組件混合。
每一個微服務都有本身的fun出能力，能夠有本身的數據庫，也能夠有統一的數據庫。

缺點

開發人員要處理分佈式系統的複雜性
多服務運維難度，隨着服務的增長，運維的壓力也會增大
系統部署依賴
服務間通訊成本
數據一致性
系統集成測試
性能監控。。。

你所知道的微服務技術棧有哪些？請列舉一二

eureka和zookeeper均可以提供服務註冊與發現功能，請說說兩個的區別？

做爲服務註冊中心，Eureka比Zookeeper好在哪裏
著名的CAP理論指出，一個分佈式系統不可能同時知足C(一致性)、A(可用性)和P(分區容錯性)。因爲分區容錯性P在是分佈式系統中必需要保證的，所以咱們只能在A和C之間進行權衡。
所以

Zookeeper保證的是CP,
Eureka則是AP。

1 Zookeeper保證CP
當向註冊中心查詢服務列表時，咱們能夠容忍註冊中心返回的是幾分鐘之前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。可是zk會出現這樣一種狀況，當master節點由於網絡故障與其餘節點失去聯繫時，剩餘節點會從新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就致使在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大機率會發生的事，雖然服務可以最終恢復，可是漫長的選舉時間致使的註冊長期不可用是不能容忍的。

2 Eureka保證AP
Eureka看明白了這一點，所以在設計時就優先保證可用性。 Eureka各個節點都是平等的 ，幾個節點掛掉不會影響正常節點的工做，剩餘的節點依然能夠提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時若是發現鏈接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此以外，Eureka還有一種自我保護機制，若是在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現如下幾種狀況：

1. Eureka再也不從註冊列表中移除由於長時間沒收到心跳而應該過時的服務
2. Eureka仍然可以接受新服務的註冊和查詢請求，可是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中

所以， Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況，而不會像zookeeper那樣使整個註冊服務癱瘓。

學習網站：

官網：http://spring.io/projects/spring-cloud
參考書：https://springcloud.cc/spring-cloud-netflix.html
詳細中文文檔：https://springcloud.cc/spring-cloud-dalston.html
中國社區：http://springcloud.cn/
中文網：https://springcloud.cc/