目錄
@、SpringBoot和SpringCloud,請你談談對他們的理解？
@、Eureka和zookeeper都可以提供服務註冊與發現的功能，請說說兩個的區別？
@、服務註冊和發現是什麼意思？Spring Cloud如何實現？
@、什麼是微服務？
就目前而言，對於微服務業界並沒有一個統一的，標準的定義。
但通常而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間相互協調、互相配合，爲用戶提供最總價值。服務之間採用輕量級的通信機制互相溝通（通常是基於HTTP的RESTful API）,每個服務都圍繞着具體的業務進行構建，並且能夠被獨立的構建在生產環境、類生產環境等。另外，應避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。
@、微服務之間是如何獨立通訊的？
@、SpringCloud和Dubbo有哪些區別？
Dubbo
SpringCloud
服務註冊中心
Zookeeper
Eureka
服務調用方式
RPC
REST API
服務監控
Dubbo-monitor
Spring BootAdmin
斷路器
不完善
Spring Cloud Netflix Hystrix
服務網關
無
Spring Cloud Netflix Zuul
分佈式配置
無
Spring Cloud Config
服務跟蹤
無
Spring Cloud Sleuth
消息總線
無
Spring Cloud Bus
數據流
無
Spring Cloud Stream
批量任務
無
Spring Cloud Task
最大區別：SpringCloud拋棄了Dubbo的RPC通信，採用的是基於HTTP的REST方式。
總體來說，兩者各有優勢。雖說後者服務調用的功能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的依賴，這在強調快速演化的微服務環境下，顯得更加合適。
品牌機與組裝機的區別：很明顯SpringCloud比dubbo的功能更強大，覆蓋面更廣，而且能夠與SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring項目完美融合，這些對於微服務至關重要。使用Dubbo構建的微服務架構就像組裝電腦、各環節我們選擇自由度高，但是最總可能會因爲內存質量而影響整體，但對於高手這也就不是問題。而SpringCloud就像品牌機，在Spring Source的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性。
在面臨微服務基礎框架選型時Dubbo與SpringCloud只能二選一。
@、SpringBoot和SpringCloud,請你談談對他們的理解？
1）、SpringBoot專注於快速方便的開發單個個體微服務。
2）、SpringCloud是關注全局的微服務協調、整理、治理的框架，它將SpringBoot開發的單體整合並管理起來。
3）、SpringBoot可以離開SpringCloud獨立使用開發項目，但是SpringCloud離不開SpringBoot，屬於依賴關係。
@、什麼是服務熔斷？什麼是服務降級？
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節點微服務的調用，快速返回“錯誤”的響應信息。當檢測到該節點微服務調用響應正常後恢復調用鏈路。在SpringCloud框架裏熔斷機制通過Hystrix實現，Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內調用20次，如果失敗，就會啓動熔斷機制。熔斷機制的註解是@HystrixCommand
服務降級，一般是從整體負荷考慮。就是當某個服務熔斷之後，服務器將不再被調用，此時客戶端可以自己準備一個本地的fallback回調，返回一個缺省值。這樣做，雖然水平下降，但好歹可用，比直接掛掉強。
@、微服務的優缺點是什麼？說下你在項目開發中碰到的問題
優點：1）、每個服務足夠內聚，足夠小，代碼容易理解這樣能聚焦一個指定的業務功能或業務需求。
2）、開發簡單，開發效率提高，一個服務可能就是專一的只幹一件事。
3）、微服務能夠被小團隊開發，這個團隊可以是2到5個開發人員組成。
4）、微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
5）、微服務能使用不同的語言開發。
6）、易於第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成集成工具，如Jenkins、Hudson等。
7）、微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作體現價值。
8）、微服務允許你融合最新技術。
9）、微服務知識業務邏輯代碼，不會和HTML和CSS其他界面組件混合。
10）、每個微服務都有自己的存儲能力，可以有自己的數據庫，也可以由統一的數據庫。
缺點：1）、開發人員要處理分佈式系統的複雜性。
2）、多服務運維難度，隨着服務的增加，運維的壓力也在增加。
3）、系統部署依賴。
4）、服務間通訊成本。
5）、數據一致性。
6）、系統集成測試。
7）、性能監控.....
@、你所知道的微服務技術棧有哪些?請舉例一二
微服務的技術棧（各項功能的實現所使用的技術）具體如下：
微服務條目
落地的技術
備註
服務開發
SpringBoot、Spring、SpringMVC
服務配置管理
Netfilx公司的Archaius、阿里的Diamond等
服務註冊與發現
Eureka、Consul、Zookeeper
服務調用
RPC、Rest、gRPC
服務熔斷器
Hystrix、Envoy等
負載均衡
Nginx、Ribbon
服務接口調用（客戶端調用服務的簡化工具）
Feign等
消息隊列
Kafka、RabbitMQ、ActiveMQ等
服務配置中心管理
SpringCloudConfig、Chef等
服務路由（API網關）
Zuul等
服務監控
Zabbix、Naggios、Metrics、Spectator等
全鏈路追蹤
Zipkin、Brave、Dapper等
服務部署
Docker、OpenStack、Kubernetes等
數據流操作開發包
SpringCloud Stream
事件消息總線
Spring Cloud Bus
@、Eureka和zookeeper都可以提供服務註冊與發現的功能，請說說兩個的區別？
1）、Zookeeper保證了CP（C：一致性，P：分區容錯性），Eureka保證了AP（A：高可用）
（1）、當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用。也就是說，服務註冊功能對高可用性要求比較高，但zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新選leader。問題在於，選取leader時間過長，30 ~ 120s，且選取期間zk集羣都不可用，這樣就會導致選取期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠恢復，但是漫長的選取時間導致的註冊長期不可用是不能容忍的。
（2）、Eureka保證了可用性，Eureka各個節點是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點仍然可以提供註冊和查詢服務。而Eureka的客戶端向某個Eureka註冊或發現是發生連接失敗，則會自動切換到其他節點，只要有一臺Eureka還在，就能保證註冊服務可用，只是查到的信息可能不是最新的。除此之外，Eureka還有自我保護機制，如果在15分鐘內超過85%的節點沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心發生了網絡故障，此時會出現以下幾種情況：
①、Eureka不在從註冊列表中移除因爲長時間沒有收到心跳而應該過期的服務。
②、Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點仍然可用）
③、當網絡穩定時，當前實例新的註冊信息會被同步到其他節點。
因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像Zookeeper那樣使整個微服務癱瘓。
@、什麼是Spring Cloud？
Spring cloud流應用程序啓動器是基於Spring Boot的Spring集成應用程序，提供與外部系統的集成。Spring cloud Task，一個生命週期短暫的微服務框架，用於快速構建執行有限數據處理的應用程序。
@、使用Spring Cloud有什麼優勢？
使用Spring Boot開發分佈式微服務時，我們面臨以下問題
- 與分佈式系統相關的複雜性-這種開銷包括網絡問題，延遲開銷，帶寬問題，安全問題。
- 服務發現-服務發現工具管理羣集中的流程和服務如何查找和互相交談。它涉及一個服務目錄，在該目錄中註冊服務，然後能夠查找並連接到該目錄中的服務。
- 冗餘-分佈式系統中的冗餘問題。
- 負載平衡 --負載平衡改善跨多個計算資源的工作負荷，諸如計算機，計算機集羣，網絡鏈路，中央處理單元，或磁盤驅動器的分佈。
- 性能-問題 由於各種運營開銷導致的性能問題。
- 部署複雜性-Devops技能的要求。
@、服務註冊和發現是什麼意思？Spring Cloud如何實現？
當我們開始一個項目時，我們通常在屬性文件中進行所有的配置。隨着越來越多的服務開發和部署，添加和修改這些屬性變得更加複雜。有些服務可能會下降，而某些位置可能會發生變化。手動更改屬性可能會產生問題。 Eureka服務註冊和發現可以在這種情況下提供幫助。由於所有服務都在Eureka服務器上註冊並通過調用Eureka服務器完成查找，因此無需處理服務地點的任何更改和處理。
@、負載平衡的意義什麼？
在計算中，負載平衡可以改善跨計算機，計算機集羣，網絡鏈接，中央處理單元或磁盤驅動器等多種計算資源的工作負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間並避免任何單一資源的過載。使用多個組件進行負載平衡而不是單個組件可能會通過冗餘來提高可靠性和可用性。負載平衡通常涉及專用軟件或硬件，例如多層交換機或域名系統服務器進程。