1、什么是微服務？
微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序划分成一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間互相協調、互相配合，為用戶提供最終價值。
服務之間采用輕量級的通信機制互相溝通（通常是基於 HTTP 的 RESTful API）。
每個服務都圍繞着具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。
另外，應盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。
從技術維度來說：
微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地去耦合,每一個微服務提供單個業務功能的服務，一個服務做一件事，從技術角度看就是一種小而獨立的處理過程，類似進程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的數據庫。
2、微服務之間是如何建立通信
1）遠程過程調用（Remote Procedure Invocation）
直接通過遠程過程調用來訪問別的service。
示例：REST、gRPC、Apache、Thrift
- 優點：
簡單，常見。因為沒有中間件代理，系統更簡單
- 缺點：
只支持請求/響應的模式，不支持別的，比如通知、請求/異步響應、發布/訂閱、發布/異步響應降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的
2）消息
使用異步消息來做服務間通信。服務間通過消息管道來交換消息，從而通信。
示例：Apache Kafka、RabbitMQ
- 優點: 把客戶端和服務端解耦，更松耦合 提高可用性，因為消息中間件緩存了消息，直到消費者可以消費支持很多通信機制比如通知、請求/異步響應、發布/訂閱、發布/異步響應 - 缺點: 消息中間件有額外的復雜性
3、SpringCloud 和 Dubbo 有哪些區別？
相同點：SpringCloud 和 Dubbo 可以實現 RPC 遠程調用框架，可以實現服務治理。
不同點：SpringCloud 是一套目前比較網站微服務框架了，整合了分布式常用解決方案遇到了問題注冊中心 Eureka、負載均衡器 Ribbon ，客戶端調用工具 Rest 和 Feign，分布式配置中心 Config，服務保護 Hystrix，網關 Zuul Gateway，服務鏈路 Zipkin，消息總線 Bus 等。
Dubbo 內部實現功能沒有 SpringCloud 強大（全家桶），只是實現服務治理，缺少分布式配置中心、網關、鏈路、總線等，如果需要用到這些組件，需要整合其他框架。
表 Spring Cloud與Dubbo功能對比
4、SpringBoot 和 SpringCloud，請你談談對他們的理解
1）SpringBoot 專注於快速方便的開發單個個體微服務。
2）SpringCloud 是關注全局的微服務協調整理治理框架，它將 SpringBoot 開發的一個個單體微服務整合並管理起來，為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務。
3）SpringBoot 可以離開 SpringCloud 獨立使用開發項目，但是 SpringCloud 離不開 SpringBoot，屬於依賴的關系。
4）SpringBoot 專注於快速、方便的開發單個微服務個體，SpringCloud 關注全局的服務治理框架。
Spring Boot可以離開Spring Cloud獨立使用開發項目，但是Spring Cloud離不開Spring Boot，屬於依賴的關系。
5、什么是服務熔斷？什么是服務降級？
1）服務熔斷
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，快速返回”錯誤”的響應信息。當檢測到該節點微服務調用響應正常后恢復調用鏈路。在SpringCloud框架里熔斷機制通過 Hystrix 實現。Hystrix 會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗就會啟動熔斷機制。熔斷機制的注解是@HystrixCommand。
2）Hystrix服務降級
其實就是線程池中單個線程障處理，防止單個線程請求時間太長，導致資源長期被占有而得不到釋放，從而導致線程池被快速占用完，導致服務崩潰。
Hystrix能解決如下問題：
1）請求超時降級，線程資源不足降級，降級之后可以返回自定義數據
2）線程池隔離降級，分布式服務可以針對不同的服務使用不同的線程池，從而互不影響
3）自動觸發降級與恢復
4）實現請求緩存和請求合並
6、微服務的優缺點是分別是什么？說一下你在項目開發中遇到的坑
● 優點
1）每個服務足夠內聚，足夠小，代碼容易理解這樣能聚焦一個指定的業務功能或業務需求
2）開發簡單、開發效率提高，一個服務可能就是專一的只干一件事。
3）微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
4）微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
5）微服務能使用不同的語言開發。
6）易於和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins, Hudson, bamboo。
7）微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。
8）微服務允許你利用融合最新技術。
9）微服務只是業務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。
10）每個微服務都有自己的存儲能力，可以有自己的數據庫。也可以有統一數據庫。
● 缺點
1）開發人員要處理分布式系統的復雜性
2）多服務運維難度，隨着服務的增加，運維的壓力也在增大
3）系統部署依賴
4）服務間通信成本
5）數據一致性
6）系統集成測試
7）性能監控……
7、你所知道的微服務技術棧有哪些？請舉例一二
8、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那樣使整個注冊服務癱瘓。