個人博客:蘭陵笑笑生,歡迎瀏覽博客!算法
近年來,隨着互聯網公司自身的業務體系愈來愈大,系統複雜度愈來愈高,致使咱們不得不將服務進行拆分,微服務的概念也是迅速在互聯網發酵。咱們也迫切的須要一套框架、一個生態系統可以健全、穩定的爲咱們解決問題。本章就簡單的介紹一下微服務的概念,以及Spring Cloud的生態組件。spring
微服務架構風格是將單體應用程序開發爲一組小型服務的方法,每一個服務運行在本身的進程中,服務之間經過輕量級的通信機制(一般是HTTP資源api).。每個服務是圍繞這個業務能力構建,而且能夠獨立的部署、可獨立擴展。不一樣的服務可使用不一樣的語言來編寫,也可使用不一樣的數據存儲。總結以下:編程
服務功能單一後端
可獨立部署、獨立擴展api
可跨語言編程安全
服務間良好的通訊機制服務器
在https://spring.io/ 官方網站介紹Spring Cloud時,以圖的方式展示了微服的架構圖:圖中包含了網關,各個微服務單元,服務註冊,服務配置等網絡
在微服務的發展過程當中,隨着分佈式水平的提升,系統會變得愈來愈複雜,系統發生的錯誤率隨着系統的複雜性呈指數型增加、所以微服務也出現了反對的聲音,認爲微服務增長了系統的維護、部署難度、致使一些功能模塊和代碼很難反覆的使用。有沒有一種框架能夠儘量的解決上述的問題呢。有,就是Spring Cloud。架構
這裏就介紹一下SpringCloud中微服務經常使用的功能負載均衡
服務的發現是微服務架構中很重要的一個組件,在微服務中,系統之間的依賴很是的頻繁,服務調用方A服務調用B服務、C服務等多個服務,這些被調用方爲了保證自身的高可用、一般都是以集羣的模式部署。若是咱們將被調用方的這些信息若是寫在了A服務中、這樣的配置是會很複雜的,同時若是咱們動態的調整服務提供方,這樣是不利於服務的管理的。所以咱們迫切須要一種服務發現的機制。全部的服務啓動時就向註冊中心提交自身的信息。好比URL地址、PORT端口等信息。調用方只須要從註冊中心請求指定的服務便可、目前的落地的技術有Eureka、Consul、Zookeeper、 Nacos 等 。Eureka是Netflix開源的一款產品、是SpringCloud生態的的重要的一個組件之一。zookeeper是Apache的分佈式應用程序協調服務,也是一款經典的 服務註冊中心產品、常常是和Dubbo配合使用。 Consul 是 HashiCorp 公司推出的開源產品, 與Eureka相比,保證了強一致性卻犧牲了可用性。Nacos 是alibba 2018年開源的、基於了阿里巴巴大規模的生產經驗,也是給了用戶一個新的選擇。關於這些後期會有詳細的文章介紹,這裏只作一個全面的介紹。
對於傳統的單體應用,一個配置文件就能夠解決配置問題,可是在微服務中,多個機器部署的時候,修改配置文件是一個至關繁瑣的問題。爲此、這個時候就須要引入一個組件。SpringCloud提供了這樣的組件:Spring Cloud Config.固然國內大的互聯網公司都有本身的配置中心、好比百度的DisConf、淘寶的Diamond等等。固然因爲各方面的緣由,這些產品可能存在一些其餘問題。而Spring Cloud Conf是可以和Spring無縫集成。對於大多數的中小企業來講,這樣的配置也是夠的。
在微服架構中,少不了的就是服務間的調用,調用的方式Spring Cloud採用的是基於HTTP的REST方式。Dubbo採用的事RPC方式。在面臨微服務基礎框架選型時,Spring Cloud和Dubbo只能二選一。這也是你們老是將兩者作對比的緣由。Dubbo的定位是一款RPC框架,而Spring Cloud的目標是提供微服一站式解決方案。因此Dubbo和Spring Cloud並非徹底的競爭關係。
LB 即負載均衡,也是微服務或分佈式集羣中經常使用的一種應用。簡單來說就是將用戶的請求平攤的分配到多個服務上,從而達到高可用的目的。經常使用的負載均衡有軟件Nginx,LVS,硬件F5等。在Sping Coud生態中,Sping Coud Netflix Ribbon 是基於Netflix Ribbon實現的一套客戶端負載均衡的工具。負載均衡的算法有不少,好比輪詢、隨機、權重等等。
在微服務架構中,是存在着不少的服務的,並且服務之間的調用可能跨網絡,由於網絡的不可靠性等緣由出現調用故障和延遲,若是此時調用方的請求不斷的增長,長時間的等待會造成調用方佔用不少的資源,甚至形成系統崩潰和癱瘓,即所謂的"雪崩效應"。爲了解決這樣的問題,須要對故障和延遲進行隔離和管理,便出現了斷路器。它的做用就是在發生沒法訪問、超時、異常等問題時,會經過服務降級的方式,熔斷該節點的調用,快速返回「錯誤」的信息、可處理的備選響應,從而保證故障的蔓延等問題。Hystrix提供了熔斷模式和隔離模式用來解決雪崩效應,Hystrix是在服務訪問失敗時下降阻塞的影響範圍,避免整個服務被拖垮。
在微服務架構模式下,後端服務的實例通常是動態的,對應客戶端來講很難動態的發現改動的服務實例地址,爲此,一般會引入網關API Gateway。 從而簡化內部服務的相互調用的複雜度。在Spring Cloud生態中Zull就是一個落地的技術。Zull是Netfix開源的一個基於JVM的路由和服務器負載均衡器,其做用就是服務轉發。固然也是能夠做爲資源統一訪問入口。同時。也能夠在網關作一些權限的校驗。
在微服務架構的生產實踐中,常常會遇到這樣的案例:客戶反饋問題,開發、應急和運維人員從入口服務A開始查起,肯定服務A沒有問題,而後將問題傳遞到B服務,依次查詢下去,這樣的排查多了不少的沒必要要,基於調用鏈的服務治理系統能夠解決以上的問題。Spring Cloud Sleuth就是Sping Cloud生態中實現調用鏈追蹤的一個子項目,能夠結合Zipkin很好的事項故障快速定位問題。
在微服務架構的實踐過程當中,Spring Cloud 以其獨有的生態迅速的擴張,覆蓋了整個互聯網公司。固然Spring Cloud中的組件不只僅包含了剛纔介紹的,還包括了安全、任務、消息總線、批處理等各類組件。如上圖。
本章簡單介紹了微服務的架構以及Spring Cloud的生態,在以後的章節中,我將詳細的介紹各個功能的具體實現。
以上就是本期的分享,你還能夠關注本博客的#Spring Cloud基礎教程系列!#
本文由博客一文多發平臺 OpenWrite 發佈!
個人博客地址蘭陵笑笑生,歡迎瀏覽!