Spring cloud(1)-簡介以及選擇

簡介

Spring Cloud是一個基於Spring Boot實現的雲應用開發工具，它爲基於JVM的雲應用開發中涉及的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等操做提供了一種簡單的開發方式。

服務化的核心就是將傳統的一站式應用根據業務拆分紅一個一個的服務，而微服務在這個基礎上要更完全地去耦合（再也不共享DB、KV，去掉重量級ESB），而且強調DevOps和快速演化。

• DevOps:要求開發、測試、運維進行一體化的合做，進行更小、更頻繁、更自動化的應用發佈，以及圍繞應用架構來構建基礎設施的架構。這就要求應用充分的內聚，也方便運維和管理。

爲何要使用，和之間的服務化解決方案相比的優點(舉例：Nginx)

最初的服務化解決方案是給提供相同服務提供一個統一的域名，而後服務調用者向這個域名發送HTTP請求，由Nginx負責請求的分發和跳轉。

• 配置文件中耦合了服務調用的邏輯，這削弱了微服務的完整性
• 服務的信息分散在各個系統，沒法統一管理和維護,服務消費者並不知道有哪些實例在給他們提供服務。
• 沒法直觀的看到服務提供者和服務消費者當前的運行情況和通訊頻率。
• 消費者的失敗重發，負載均衡等都沒有統一策略，這加大了開發每一個服務的難度，不利於快速演化。

spring cloud和dubbo比較

微服務功能	Dubbo	Spring Cloud
服務註冊和發現	Zookeeper	Eureka,Consul
服務調用方式	RPC	RESTful API
斷路器	有	Hystrix
負載均衡	有	Ribbon,Feign(RESTful Web Service客戶端，整合了Ribbon和Hystrix)
服務路由和過濾	有	有
分佈式配置	無	有
分佈式鎖	無	有
集羣選主	無	有
分佈式消息	無	有

Spring Cloud拋棄了Dubbo的RPC通訊，採用的是基於HTTP的REST方式。嚴格來講，這兩種方式各有優劣。雖然從必定程度上來講，後者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。並且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。

結語

在github上有關於Spring Cloud完整的部署。
其它相關文章
Spring cloud(1)-簡介以及選擇
Spring cloud(2)-服務發現(Eureka，Consul)
Spring cloud(3)-負載均衡(Feign，Ribbon)
Spring cloud(4)-熔斷(Hystrix)
Spring cloud(5)-路由網關(Zuul)
Spring cloud(6)-配置管理及刷新(Config，Bus)
最後，給個 star 吧~
我的博客~
簡書~