什麼是微服務？
微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分為一組小的服務，每個服務執行在其獨立的自己的程序中，服務之間相互協調、互相配合，為使用者提供最終價值。服務之間採用輕量級的通訊機制互相溝通（通常是基於HTTP的RESTful API）,每個服務都圍繞著具體的業務進行構建，並且能夠被獨立的構建在生產環境、類生產環境等。另外，應避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的資料儲存。

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

熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。當某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節點微服務的呼叫，快速返回“錯誤”的響應資訊。當檢測到該節點微服務呼叫響應正常後恢復呼叫鏈路。在SpringCloud框架裡熔斷機制通過Hystrix實現，Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，預設是5秒內呼叫20次，如果失敗，就會啟動熔斷機制。

服務降級，一般是從整體負荷考慮。就是當某個服務熔斷之後，伺服器將不再被呼叫，此時客戶端可以自己準備一個本地的fallback回撥，返回一個預設值。這樣做，雖然水平下降，但好歹可用，比直接掛掉強。

Hystrix相關注解

@EnableHystrix：開啟熔斷
@HystrixCommand(fallbackMethod=”XXX”)：宣告一個失敗回滾處理函式XXX，當被註解的方法執行超時（預設是1000毫秒），就會執行fallback函式，返回錯誤提示。

微服務技術棧有哪些?

微服務條目	落地的技術	備註
服務開發	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都可以提供服務註冊與發現的功能，請說說兩個的區別？
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那樣使整個微服務癱瘓。