java框架之SpringCloud(1)-微服務及SpringCloud介紹

時間 2019-12-05

標籤 java 框架 springcloud 微服介紹欄目 Java 简体版

原文原文鏈接

微服務概述

是什麼

業界大牛 Martin Fowler 這樣描述微服務：html

參考【微服務(Microservices)-微服務原做者Martin Flower博客翻譯】。ios

下面是關於上述博客中的部分重點總結：spring

就目前而言，對於微服務業界並無一個統一的、標準的定義（While there is no precise definition of this architectural style）。
但一般而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分爲一組小服務，每一個服務運行在其獨立的本身的進程中，服務之間互相協調、互相配合，爲用戶提供最終價值。服務之間採用輕量級的通訊機制互相溝通（一般是基於 HTTP 的 RESTFul API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立地部署到生產環境、類生產環境等。另外，應儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，能夠有一個很是輕量級的集中式管理來協調這些服務，可使用不一樣的語言來編寫服務，也可使用不一樣的數據存儲。

技術維度理解：數據庫

微服務的核心就是將傳統的一站式應用，根據業務拆分紅一個一個的服務，完全的去耦合，每個微服務提供單個業務功能的服務，一個服務作一件事，從技術角度看就是一種小而獨立的處理過程，相似進程概念，可以自行單獨啓動或銷燬，擁有本身獨立的數據庫。編程

微服務與微服務架構

微服務強調的是服務的大小，它關注的是某一個點，是具體解決某一個問題/提供落地對應服務的一個服務應用，狹義的看，能夠看作 Eclipse 裏面的一個個微服務工程或 Module。服務器
微服務架構是一種架構模式或架構風格，如上總結。

微服務優缺點

優勢

每一個服務足夠內聚，足夠小，代碼容易理解，這樣能聚焦一個指定的業務功能或業務需求。
開發簡單、開發效率高，一個服務可能就是專注的只幹一件事。
微服務可以被小團隊單獨開發，這個小團隊是 2 到 5 人的開發人員組成。
微服務是鬆耦合的，是由功能意義的服務，不管是在開發階段或部署階段都是獨立的。
微服務能使用不一樣的語言進行開發。
易於與第三方集成，微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如 Jenkins、Hudson、Bamboo。
微服務易於被一個開發人員理解、修改和維護，這樣小團隊更能關注本身的工做成果，無需經過合做也能體現價值。
微服務容許你利用融合最新技術。
微服務只是業務邏輯的代碼，不會和 HTML、CSS 或其它 UI 組件混合。
每一個微服務均可以有本身的存儲能力，能夠有本身的數據庫，也能夠有統一數據庫。

缺點

開發人員要處理分佈式系統的複雜性。
多服務運維難度，隨着服務的增長，運維的壓力也在增大。
系統部署依賴。
服務間通訊成本。
數據的一致性。
系統集成測試。
性能監控。

微服務技術棧

微服務條目	落地技術
服務開發	SpringBoot、Spring、SpringMVC
服務管理與配置	Netflix 公司的 Archaius、阿里的 Diamond 等
服務註冊於發現	Eureka、Consul、Zookeeper等
服務調用	Rest、RPC、gRPC
服務熔斷器	Hystrix、Envoy 等
負載均衡	Ribbon、Nginx 等
服務接口調用	Feign 等
消息隊列	Kafka、RabbitMQ、ActiveMQ 等
服務配置中心管理	SpringCloudConfig、Chef 等
服務路由（API 網關）	Zull 等
服務監控	Zabbix、Nagios、Metrics、Spectator 等
全鏈路追蹤	Zipkin、Brave、Dapper 等
服務部署	Docker、OpenStack、Kubernetes 等
數據流操做開發包	SpringCloud Stream（封裝與 Redis、Rabbit、Kafka 等發送接收消息）
事件消息總線	Spring Cloud Bus

使用SpringCloud的緣由

選型依據

總體解決方案和框架成熟度
社區熱度
可維護性
學習曲線

主流微服務架構

阿里 Dubbo、HSF
京東 JSF
新浪微博 Motan
噹噹網 Dubbox

微服務框架對比

功能點/服務框架	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	完整的微服務框架	RPC 框架，但整合了 ZK 或 Consul，實現集羣環境的基本的服務註冊/發現	RPC 框架	RPC 框架	服務框架
支持 Rest	是，Ribbon 支持多種可插拔的序列化選擇	否	否	否	否
支持 RPC	否	是（Hession2）	是	是	是
支持多語言	是	否	是	是	否
服務註冊/發現	是（Eureka），Eureka 服務註冊表，Karyon 服務端框架支持服務自注冊和健康檢查	是（Zookeeper/Consul）	否	否	是
負載均衡	是（服務端 Zuul + 客戶端 Ribbon）。Zuul：服務、動態路由、雲端負載均衡；Eureka：針對中間層服務器	是（客戶端）	否	否	是（客戶端）
配置服務	Netflix Archaius，SpringCloud Config Server 集中配置	是（Zookeeper 提供）	否	否	否
服務調用鏈監控	是（Zuul），Zuul 提供邊緣服務，API 網關	否	否	否	否
高可用/容錯	是（服務端 Hystrix + 客戶端 Ribbon）	是（客戶端）	否	否	是（客戶端）
典型應用案例	Netflix	Sina	Google	Facebook
社區活躍程度	高	通常	高	通常	通常
文檔豐富度	高	通常	通常	通常	高
其它	SpringCloud Bus 爲咱們的應用程序帶來了更多管理端點	支持降級	Netflix 內部在開發繼承 gRPC	IDL 定義	實踐的公司比較多

SpringCloud介紹

概述

在 Spring 官網是這樣描述 SpringCloud 的：架構

COORDINATE ANYTHING: DISTRIBUTED SYSTEMS SIMPLIFIED
Building distributed systems doesn't need to be complex and error-prone. Spring Cloud offers a simple and accessible programming model to the most common distributed system patterns, helping developers build resilient, reliable, and coordinated applications. Spring Cloud is built on top of Spring Boot, making it easy for developers to get started and become productive quickly.app
協調一切：簡化分佈式系統
沒有複雜和出錯地構建分佈式系統。Spring Cloud 爲最多見的分佈式系統模式提供了一種簡單易用的編程模型，可幫助開發人員構建彈性，可靠和協調的應用程序。SpringCloud 構建於 SpringBoot 之上，使開發人員能夠輕鬆入門並快速提升工做效率。負載均衡

SpringCloud，基於 SpringBoot 提供了一套微服務解決方案，包括服務註冊與發現、配置中心、全鏈路監控、服務網關、負載均衡、熔斷器等組件，除了基於 NetFlix 的開源組件作高度抽象封裝以外，還有一些選型中立的開源組件。框架

SpringCloud 利用 SpringBoot 的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，SpringCloud 爲開發人員提供了快速構建分佈式系統的一些工具，包括配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等，它們均可以用 SpringBoot 的開發風格作到一鍵啓動和部署。

SpringBoot 並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過 SpringBoot 風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

總結上述，SpringCloud 就是分佈式微服務架構下的額一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶。

SpringCloud VS SpringBoot

SpringBoot 專一於快速方便的開發單個個體微服務，能夠離開 SpringCloud 獨立使用開發項目。

SpringCloud 是關注全局的微服務協調整理治理框架，它將 SpringBoot 開發的一個個單體微服務整理並管理起來，爲各個微服務之間提供配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務。SpringCloud 離不開 SpringBoot，屬於依賴的關係。

總結上述：SpringBoot 專一於快速、方便的開發單個微服務個體，而 SpringCloud 是關注全局的服務治理框架。

SpringCloud VS Dubbo

	Dubbo	SpringCloud
服務註冊中心	Zookeeper	SpringCloud Netflix Eureka
服務調用方式	RPC	REST API
服務監控	Dubbo-monitor	SpringBoot Admin
斷路器	不完善	SpringCloud Netflix Hystrix
服務網關	無	SpringCloud Netflix Zuul
分佈式配置	無	SpringCloud Config
服務跟蹤	無	SpringCloud Sleuth
消息總線	無	SpringCloud Bus
數據流	無	SpringCloud Stream
批量任務	無	SpringCloud Task
...	...	...

最大區別：SpringCloud 拋棄了 Dubbo 的 RPC 通訊，採用的是基於 HTTP 的 REST 方式。

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

用品牌機與組裝機的區別爲例說明：

很明顯，SpringCloud 的功能比 Dubbo 更增強大，涵蓋面更廣，並且做爲 Spring 的拳頭項目，它也可以與 SpringFramework、SpringBoot、SpringData、SpringBatch 等其它 Spring 項目完美融合，這些對於微服務而言是相當重要的。使用 Dubbo 構建的微服務架構就像組裝電腦，各環節咱們選擇的自由度很高，可是最終結果頗有可能由於一條內存質量不行就點不亮了，老是讓人不怎麼放心，可是若是你是一名高手，那這些都不是問題；而 SpringCloud 就像品牌機，在 Spring Source 的整合下，作了大量的兼容性測試，保證了機器擁有更高的穩定性，可是若是要使用非原裝組件之外的東西，就須要對其基礎底層有足夠的瞭解。

社區支持和更新力度：

最爲重要的是，Dubbo 中止了 5 年左右的更新，雖然 2017 年 7 月重啓了。對於技術發展的新需求，須要由開發者自行脫戰升級（好比噹噹網弄出了DubboX），這對於不少想要採用微服務架構的中小軟件組織，顯然是不太合適的，中小公司沒有這麼強大的技術能力去修改 Dubbo 源碼及周邊的一整套解決方案。

下面是 Dubbo 重啓維護開發的主要負責人之一劉軍對 Dubbo 及 SpringCloud 的關係闡述：

劉軍，阿里巴巴中間件高級研發工程師，主導了 Dubbo 重啓維護後的幾個發版計劃，專一於高性能 RPC 框架和微服務相關領域。層負責網易考拉 RPC 框架的研發及指導在內部使用，參與了服務治理平臺、分佈式跟蹤系統、分佈式一致性框架等從無到有的設計與開發過程。

問：目前 Dubbo 被拿來比較的最多的就是 SpringCloud，您怎麼看待兩者的關係，業務上是否有所衝突？

答：關於 Dubbo 和 SpringCloud 間的關係，咱們在開源中國年終盛典的 Dubbo 分享中也做了簡單闡述，首先要明確的一點是 Dubbo 和 SpringCloud 並非徹底的競爭關係，二者所解決的問題域並不同：Dubbo 的定位始終是一款 RPC 框架，而 SpringCloud 的目標是微服務架構下的一站式解決方案。若是非要比較的話，我以爲 Dubbo 能夠類比到 Netflix OSS 技術棧，而 SpringCloud 繼承了 Netflix OSS 做爲分佈式服務治理解決方案，但除此以外 SpringCloud 還提供了包括 config、stream、security、sleuth 等等分不是問題解決方案。當前因爲 RPC 協議、註冊中心元數據不匹配等問題，在面臨微服務基礎框架選型時 Dubbo 與 SpringCloud 是隻能二選一，這也是爲何你們老是拿 Dubbo 和 SpringCloud 作對比的緣由之一。Dubbo 以後會積極尋求適配到 SpringCloud 生態，好比做爲 SpringCloud 的二進制通訊方案來發揮 Dubbo 的性能優點，或者 Dubbo 經過模塊化以及對 http 的支持適配到 SpringCloud。