接觸過微服務嗎，知道SpringCloud嗎？

Spring Cloud為開發人員提供了工具，以快速構建分散式系統中的一些常見模式（例如，配置管理，服務發現，斷路器，智慧路由，微代理，控制匯流排，一次性令牌，全域性鎖，領導選舉，分散式會話，群集狀態）。分散式系統的協調導致樣板式樣，並且使用Spring Cloud開發人員可以快速站起來實現這些樣板的服務和應用程式。它們可以在任何分散式環境中正常工作，包括開發人員自己的膝上型電腦，裸機資料中心以及Cloud Foundry等託管平臺。

特徵

Spring Cloud專注於為典型的用例和可擴充套件性機制（包括其他用例）提供良好的開箱即用體驗。

分散式/版本化配置服務註冊和發現路由服務到服務的呼叫負載均衡斷路器全域性鎖領導選舉和叢集狀態分散式訊息傳遞主要專案

這些專案你可以沒有用過，但是最好有一定的了解。相比與一問三不知，還是能知道它是幹啥的比較好。

Spring Cloud Config

由git儲存庫支援的集中式外部配置管理。配置資源直接對映到Spring，支援非Spring應用的使用。

Spring Cloud Netflix

由各種Netflix OSS元件（Eureka，Hystrix，Zuul，Archaius等）整合。

Spring Cloud Bus

事件匯流排，用於將服務和服務例項與分散式訊息傳遞連結在一起。對於在群集中傳播狀態更改（例如配置更改事件）很有用。

Spring Cloud Cloudfoundry

將應用程式與Pivotal Cloud Foundry整合。提供服務發現實現，還可以輕鬆實現SSO和OAuth2保護的資源。

Spring Cloud Open Service Broker

Zookeeper，Redis，Hazelcast和Consul的領導層選舉和常見狀態模式以及抽象和實現。

Spring Cloud Cluster

使用Hashicorp Consul進行服務發現和配置管理。

Spring Cloud Security

為Zuul代理中的負載平衡的OAuth2其餘客戶端和身份驗證標頭中繼提供支援。

Spring Cloud Sleuth

Spring Cloud應用程式的分散式跟蹤，與Zipkin，HTrace和基於日誌（例如ELK）的跟蹤相容。

Spring Cloud Data Flow

針對現代執行時可組合微服務應用程式的雲原生編排服務。易於使用的DSL，拖放式GUI和REST-API共同簡化了基於微服務的資料管道的總體編排。

Spring Cloud Stream

輕量級的事件驅動型微服務框架，用於快速構建可以連線到外部系統的應用程式。在Spring Boot應用程式之間使用Apache Kafka或RabbitMQ傳送和接收訊息的簡單宣告性模型。

Spring Cloud Stream App Starters

Spring Cloud Task App Starters是Spring Boot應用程式，可以是任何程序，包括不會永遠執行的Spring Batch作業，它們在有限的資料處理週期後結束/停止。

Spring Cloud Zookeeper

使用Apache Zookeeper進行服務發現和配置管理。

Spring Cloud Connectors

使各種平臺上的PaaS應用程式輕鬆連線到後端服務，例如資料庫和訊息代理（該專案以前稱為“ Spring Cloud”）。

Spring Cloud Starters

Spring Boot風格的啟動程式專案可以簡化Spring Cloud使用者的依賴關係管理。（作為一個專案停產，並在Angel.SR2之後與其他專案合併。）

Spring Cloud CLI

Spring Boot CLI外掛，用於在Groovy中快速建立Spring Cloud元件應用程式

Spring Cloud Contract

Spring Cloud Contract是一個總括專案解決方案，可幫助使用者成功實施“消費者驅動合同”方法。

Spring Cloud Gateway

Spring Cloud Gateway是基於Project Reactor的智慧可程式設計路由器。

Spring Cloud OpenFeign

Spring Cloud OpenFeign通過自動配置並繫結到Spring Environment和其他Spring程式設計模型慣用法為Spring Boot應用程式提供整合。

用過dubbo嗎，說說兩者間的區別SpringCloud是Http傳輸，頻寬佔用較多，與此同時使用JSON報文，這樣消耗會更大。SpringCloud下介面協議需要人為強約束，介面的無序升級往往需要採用行政手段來避免。SpringCloud註冊中心是Eureka，也可以搭配consul等等，Dubbo註冊中心的選擇就更多了zookeeper，redis等等SpringCloud的系統結構更簡單、“註冊+springmvc=springcloud”，而dubbo各種複雜的Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化...Dubbo具有排程、發現、監控、治理等功能，支援相當豐富的服務治理能力。Dubbo架構下，註冊中心對等叢集，並會快取服務列表已被資料庫失效時繼續提供發現功能，本身的服務發現結構有很強的可用性與健壯性，足夠支援高訪問量的網站。Dubbo，是阿里巴巴服務化治理的核心框架，並被廣泛應用於中國各網際網路公司；Dubbo雖然也是一個非常優秀的服務治理框架，甚至在服務治理，灰度釋出等做的比SpringCloud更加出色，但是它的社群活躍性遠不如SpringCloud。在Github上可以看出，SpringCloud迭代非常快，功能將更新更穩定。那麼假如現在有個專案給你，你要怎麼做微服務選型呢？微服務由多個服務協同工作，這就需要考慮存在異構系統整合的問題分析具體的需求，備選的技術框架是否滿足Http協議的通訊對於應用的負載量消耗會比較大，但是這會不會真正成為短板（Spring Cloud下Thrift、protobuf等高效的RPC、序列化協議同樣可以作為Http+JSON的替代方案）團隊技術儲備，是否有足夠的人力來開發，如果選擇Dubbo框架後續能否有一個持續的維護，這些都是需要考慮的。先不論要準備要整合多少功能做多少改造，作為一個支撐所有工程正常運轉的基礎元件，問題的及時響應與解答、重大缺陷的及時修復能力就已足夠重要。

Dubbo優勢是有的，但是要結合具體的專案來講。相比於SpringCloud，為什麼你做的這個專案選擇了Dubbo來實現這個功能。或者說，從前你用的Dubbo遇到了什麼問題，描述下這個發現問題的過程，最後採取了什麼樣的解決方案。

面試官往往會在面試過程中引導你來說出他心中的答案，他問你，肯定是他心裡早就有了答案。

機會往往是留給有準備的人