SpringCloud學習--微服務架構

時間 2019-12-02

原文原文鏈接

　　　　微服務也指一種種鬆耦合的、有必定的有界上下文的面向服務架構。也就是說，若是每一個服務都要同時修改，那麼它們就不是微服務，由於它們緊耦合在一塊兒；若是你須要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。負載均衡

　　微服務架構的優缺點？框架

　　　　優勢分佈式

每一個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。
微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段或部署階段都是獨立的。
微服務能使用不一樣的語言開發。
微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如Jenkins, Hudson, bamboo 。
一個團隊的新成員可以更快投入生產。
微服務易於被一個開發人員理解，修改和維護，這樣小團隊可以更關注本身的工做成果。無需經過合做才能體現價值。
微服務容許你利用融合最新技術。
微服務只是業務邏輯的代碼，不會和HTML,CSS 或其餘界面組件混合。
微服務可以即時被要求擴展。
微服務能部署中低端配置的服務器上。
易於和第三方集成。
每一個微服務都有本身的存儲能力，能夠有本身的數據庫。也能夠有統一數據庫。

　　　　缺點

微服務架構可能帶來過多的操做。
須要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
可能雙倍的努力。
分佈式系統可能複雜難以管理。
由於分佈部署跟蹤問題難。
當服務數量增長，管理複雜性增長。

SOA（面向服務的架構）

　　SOA是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）經過這些服務之間定義良好的接口和契約聯繫起來。面向服務架構，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。

soa基本架構圖

　　1.註冊中心：保存服務提供方暴露的服務信息，常見的註冊中心有zookeeper eureka 也可用redis 默認eureka

　　2.服務提供方：提供服務者

　　3.服務消費方：當須要調用遠程服務接口時，必須在註冊中心發現服務找到服務提供者，從而進行遠程方法調

dubbo實現微服務

　　Dubbo是阿里開源的一個SOA服務治理解決方案，文檔豐富，在國內的使用度很是高。　　dubbo

調用中間層變成了可選組件，消費者能夠直接訪問服務提供者。
服務信息被集中到Registry中，造成了服務治理的中心組件。
經過Monitor監控系統，能夠直觀地展現服務調用的統計信息。
Consumer能夠進行負載均衡、服務降級的選擇。

可是對於微服務架構而言，Dubbo也並非十全十美的：

Registry嚴重依賴第三方組件（zookeeper或者redis），當這些組件出現問題時，服務調用很快就會中斷。
DUBBO只支持RPC調用。使得服務提供方與調用方在代碼上產生了強依賴，服務提供者須要不斷將包含公共代碼的jar包打包出來供消費者使用。一旦打包出現問題，就會致使服務調用出錯。
最爲重要的是，DUBBO如今已經中止維護了，對於技術發展的新需求，須要由開發者自行拓展升級。這對於不少想要採用微服務架構的中小軟件組織，顯然是不太合適的。

新選擇SpringCloud

　　與dubbo對比，spring cloud是藉助如下組件來實現的：

　　上圖來自於SpringCloud中文文檔包括了spring cloud如今有的全部組件，以及每一個組件的做用。

　　後續會講解經常使用組件（例如配置管理，服務發現，斷路器，智能路由，微代理，控制總線）在這裏先不作解釋。

SpringCloud與Dubbo對比

微服務須要的功能	Dubbo	SpringCloud
服務註冊與發現	Zookeeper	Eureka
服務調用方式	RPC	Restful API
服務路由和過濾	有	Zuul
負載均衡	有	Ribbon
斷路器	有	Hystrix
分佈式配置	無	Spring Cloud Config
分佈式消息	無	Spring Cloud Bus
集羣選主	無	Spring Cloud Cluster
批量任務	無	Spring Cloud Task
服務跟蹤	無	Sleuth&Zipkin
......	......	......

　　很明顯，SpringCloud的功能比Dubbo的功能更增強大，涵蓋面更廣，並且它也可以與Spring Framework、Spring Boot、Spring Data、Spring Batch等其餘Spring項目完美融合，這些對於微服務而言是相當重要的。

文檔對比

　　Dubbo的文檔能夠說在國內開源框架中算是一流的，很是全，而且講解的也很是深刻，因爲版本已經穩定再也不更新，因此也不太會出現不一致的狀況，另外提供了中文與英文兩種版本，對於國內開發者來講，閱讀起來更加容易上手，這也是dubbo在國內更火一些的緣由吧。

　　Spring Cloud因爲整合了大量組件，文檔在體量上天然要比dubbo多不少，文檔內容上還算簡潔清楚，可是更多的是偏向整合，更深刻的使用方法仍是須要查看其整合組件的詳細文檔。另外因爲Spring Cloud基於Spring Boot，不少例子相較於傳統Spring應用要簡單不少（由於自動化配置，不少內容都成了約定的默認配置），這對於剛接觸的開發者可能會有些不適應，比較建議瞭解和學習Spring Boot以後再使用Spring Cloud，否則可能會出現不少只知其一;不知其二的狀況。

　　雖然Spring Cloud的文檔量大，可是若是使用Dubbo去整合其餘第三方組件，實際也是要去閱讀大量第三方組件文檔的，因此在文檔量上，我以爲區別不大。對於文檔質量，因爲Spring Cloud的迭代很快，不免會出現不一致的狀況，因此在質量上我認爲Dubbo更好一些。而對於文檔語言上，Dubbo天然對國內開發團隊來講更有優點。

　　　　　　　關注博主後續繼續帶來Spring Cloud的系列文章，也歡迎各位朋友一塊兒交流，共同進步。