常見面試題
1.什么是微服務？
微服務架構是一種架構模式，或者說是一種架構風格，它提倡將單一的應用程序划分成一組小的服務，每個服務運行在其獨立的自己的進程內，服務之間互相協調，
互相配置，為用戶提供最終價值，服務之間采用輕量級的通信機制(HTTP)互相溝通，每個服務都圍繞着具體的業務進行構建，並且能狗被獨立的部署到生產環境中，另外，應盡
量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應該根據業務上下文，選擇合適的語言，工具(Maven)對其進行構建，可以有一個非常輕量級的集中式管理來
協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。
2.微服務之間是如何獨立通訊的？
同步（REST HTTP協議，RPC TCP 協議）
異步（消息中間件，例如Kafka、ActiveMQ、RabbitMQ、RocketMQ）
REST HTTP 協議（編寫restful風格接口，調用接口）（springcloud使用REST通信）
REST 請求在微服務中是最為常用的一種通訊方式，它依賴於 HTTP\HTTPS 協議。RESTFUL 的特點是：
- 每一個 URI 代表 1 種資源
- 客戶端使用 GET、POST、PUT、DELETE 4 個表示操作方式的動詞對服務端資源進行操作：GET 用來獲取資源，POST 用來新建資源（也可以用於更新資源），PUT 用來更新資源，DELETE 用來刪除資源
- 通過操作資源的表現形式來操作資源
- 資源的表現形式是 XML 或者 HTML
- 客戶端與服務端之間的交互在請求之間是無狀態的,從客戶端到服務端的每個請求都必須包含理解請求所必需的信息
舉個例子，有一個服務方提供了如下接口：
另外一個服務需要去調用該接口，調用方只需要根據 API 文檔發送請求即可獲取返回結果。
通過這樣的方式可以實現服務之間的通訊。
RPC TCP 協議（客戶端代理序列化方法和參數傳入服務器，服務器代理解碼方法和參數並執行方法，將結果再序列化傳回去，客戶端代理再解碼結果得到結果）
兩台機器是提供者和消費者，都要創建兩個代理，消費者代理接受到需要遠程調用提供者的提供的方法，
將方法和參數序列化，進行網絡傳輸到提供者機器，之后提供者代理解碼方法和參數，運行自己的方法，
將結果序列號，進行網絡傳輸到消費者機器，之后消費者解碼結果，就能遠程使用提供者提供的方法了。
3.Dubbo 和 SpringCloud對比
dubbo之前停更過一段時間，之后繼續更新，而springcloud在現階段比較火一直在更新。
dubbo專注於RPC通信（通過服務器代理將方法參數序列號和解碼的過程，不同的服務器調用對方的方法）
springcloud使用的是基於HTTP的REST方式
dubbo就是單獨的一個功能組件，而springcloud提供了一站式解決分布式問題。
| | Dubbo | SpringCloud |
| ------ | ------------- | ---------------------------- |
| 服務注冊中心 | Zookeeper | Spring Cloud Netfilx Eureka |
| 服務調用方式 | RPC | REST API |
| 服務監控 | Dubbo-monitor | Spring Boot Admin |
| 斷路器 | 不完善 | Spring Cloud Netfilx Hystrix |
| 服務網關 | 無 | Spring Cloud Netfilx Zuul |
| 分布式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總棧 | 無 | Spring Cloud Bus |
| 數據流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
4.SpringBoot 和 SpringCloud，請談談你對他們的理解
5.服務熔斷，服務降級
服務熔斷（提供者）
Hystrix解決服務雪崩的方案（服務熔斷）：在不可用的服務中服務端給調用方返回備用響應，就可以繼續運行調用之后的服務，就可以避免長時間的等待或拋出無法解決的異常，無法釋放調用線程，導致服務雪崩
服務降級（消費者）
當某個時間段訪問壓力大，需要停掉不重要的某些功能（例如：廣告。。），釋放占用資源以保證主要核心重要業務能夠順利完成，而消費者調用這些不重要功能時，客戶端會返回備用響應
6.微服務優缺點
優點
- 單一職責原則；
- 每個服務足夠內聚，足夠小，代碼容易理解，這樣能聚焦一個指定的業務功能或業務需求；
- 開發簡單，開發效率高，一個服務可能就是專一的只干一件事；
- 微服務能夠被小團隊單獨開發，這個團隊只需2-5個開發人員組成；
- 微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的；
- 微服務能使用不同的語言開發；
- 易於和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如jenkins，Hudson，bamboo；
- 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果，無需通過合作才能體現價值；
- 微服務允許利用和融合最新技術；
- 微服務只是業務邏輯的代碼，不會和HTML，CSS，或其他的界面混合;
- 每個微服務都有自己的存儲能力，可以有自己的數據庫，也可以有統一的數據庫；
缺點
- 開發人員要處理分布式系統的復雜性；
- 多服務運維難度，隨着服務的增加，運維的壓力也在增大；
- 系統部署依賴問題；
- 服務間通信成本問題；
- 數據一致性問題；
- 系統集成測試問題；
- 性能和監控問題；
7.微服務技術棧有那些？
springcloud使用Eureka注冊中心，Ribbon負載均衡， Feign接口調用服務，Hystrix （熔斷機制，dashboard監控）， zuul路由網關，config連接git配置中心
| **微服務技術條目** | 落地技術 |
| -------------------- | ------------------------------------------------ |
| 服務開發 | SpringBoot、Spring、SpringMVC等 |
| 服務配置與管理 | Netfix公司的Archaius、阿里的Diamond等 |
| 服務注冊與發現 | Eureka、Consul、Zookeeper等 |
| 服務調用 | Rest、PRC、gRPC |
| 服務熔斷器 | Hystrix、Envoy等 |
| 負載均衡 | Ribbon、Nginx等 |
| 服務接口調用(客戶端調用服務的簡化工具) | Fegin等 |
| 消息隊列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服務配置中心管理 | SpringCloudConfig、Chef等 |
| 服務路由(API網關) | Zuul等 |
| 服務監控 | Zabbix、Nagios、Metrics、Specatator等 |
| 全鏈路追蹤 | Zipkin、Brave、Dapper等 |
| 數據流操作開發包 | SpringCloud Stream(封裝與Redis，Rabbit，Kafka等發送接收消息) |
| 時間消息總棧 | SpringCloud Bus |
| 服務部署 | Docker、OpenStack、Kubernetes等 |
8.Eureka和Zookeeper都可以提供服務注冊與發現的功能，請說說兩者的區別
作為分布式服務注冊中心，Eureka比Zookeeper好在哪里？
CAP是什么?
- C (Consistency) 一致性
- A (Availability) 可用性
- P (Partition tolerance) 分區容錯性
- 一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
- 可用性（A）：不管什么時候訪問，都可以正常的獲取數據值。好的可用性主要是指系統能夠很好的為用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。
- 分區容忍性（P）：分區容錯性指在遇到某節點或網絡分區故障的時候，能夠在其他的節點，訪問到故障節點的內容（即通過拷貝，每個節點內容都是一樣的）
CAP的三進二（只能保持兩個同時實現，不能一起實現）：CA、AP、CP
因為在實現分布式時，必須考慮分區容忍性（P），因為節點隨時會崩，需要集群實現，每個節點都拷貝相同的內容以保證內容一樣，
不等待所有節點拷貝完成就使用，一致性（C）不能保證，因為一致性需要所有節點在任何時間訪問的內容都必須一樣，
等待所有節點拷貝完成才使用，可用性（A）不能保證，因為必須等待完成，在那個時間段不能使用
著名的CAP理論指出，一個分布式系統不可能同時滿足C (一致性) 、A (可用性) 、P (容錯性)，由於分區容錯性P再分布式系統中是必須要保證的，因此我們只能再A和C之間進行權衡。
- Zookeeper 保證的是 CP —> 滿足一致性，分區容錯的系統，通常性能不是特別高
- Eureka 保證的是 AP —> 滿足可用性，分區容錯的系統，通常可能對一致性要求低一些
Zookeeper保證的是CP（網絡問題導致master節點宕機，選舉時間長，集群無法使用，無法保證可用性）
當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鍾以前的注冊信息，但不能接收服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高於一致性。但zookeeper會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30-120s，且選舉期間整個zookeeper集群是不可用的，這就導致在選舉期間注冊服務癱瘓。在雲部署的環境下，因為網絡問題使得zookeeper集群失去master節點是較大概率發生的事件，雖然服務最終能夠恢復，但是，漫長的選舉時間導致注冊長期不可用，是不可容忍的。
Eureka保證的是AP（網絡有問題時觸發自我保護機制，不會移除過期服務，同時能接受新服務，保證可用性，而不會同步到其他節點，無法保證一致性）
Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩余的節點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊時，如果發現連接失敗，則會自動切換至其他節點，只要有一台Eureka還在，就能保住注冊服務的可用性，只不過查到的信息可能不是最新的，除此之外，Eureka還有之中自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
- Eureka不在從注冊列表中移除因為長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其他節點上 (即保證當前節點依然可用)
- 當網絡穩定時，當前實例新的注冊信息會被同步到其他節點中
因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓