SpringCloud基礎教程(一)-微服務與SpringCloud

時間 2020-02-01

標籤 springcloud 基礎教程微服简体版

原文原文鏈接

個人博客：蘭陵笑笑生,歡迎瀏覽博客！算法

近年來，隨着互聯網公司自身的業務體系愈來愈大，系統複雜度愈來愈高，致使咱們不得不將服務進行拆分，微服務的概念也是迅速在互聯網發酵。咱們也迫切的須要一套框架、一個生態系統可以健全、穩定的爲咱們解決問題。本章就簡單的介紹一下微服務的概念，以及Spring Cloud的生態組件。spring

1、微服務架構簡介

微服務架構風格是將單體應用程序開發爲一組小型服務的方法，每一個服務運行在本身的進程中，服務之間經過輕量級的通信機制(一般是HTTP資源api).。每個服務是圍繞這個業務能力構建，而且能夠獨立的部署、可獨立擴展。不一樣的服務可使用不一樣的語言來編寫，也可使用不一樣的數據存儲。總結以下：編程

服務功能單一後端
可獨立部署、獨立擴展api
可跨語言編程安全
服務間良好的通訊機制服務器

在https://spring.io/ 官方網站介紹Spring Cloud時，以圖的方式展示了微服的架構圖：圖中包含了網關，各個微服務單元，服務註冊，服務配置等網絡

2、SpingCloud 簡介

在微服務的發展過程當中，隨着分佈式水平的提升，系統會變得愈來愈複雜，系統發生的錯誤率隨着系統的複雜性呈指數型增加、所以微服務也出現了反對的聲音，認爲微服務增長了系統的維護、部署難度、致使一些功能模塊和代碼很難反覆的使用。有沒有一種框架能夠儘量的解決上述的問題呢。有，就是Spring Cloud。架構

這裏就介紹一下SpringCloud中微服務經常使用的功能負載均衡

2.1 註冊與發現

服務的發現是微服務架構中很重要的一個組件，在微服務中，系統之間的依賴很是的頻繁，服務調用方A服務調用B服務、C服務等多個服務，這些被調用方爲了保證自身的高可用、一般都是以集羣的模式部署。若是咱們將被調用方的這些信息若是寫在了A服務中、這樣的配置是會很複雜的，同時若是咱們動態的調整服務提供方，這樣是不利於服務的管理的。所以咱們迫切須要一種服務發現的機制。全部的服務啓動時就向註冊中心提交自身的信息。好比URL地址、PORT端口等信息。調用方只須要從註冊中心請求指定的服務便可、目前的落地的技術有Eureka、Consul、Zookeeper、 Nacos 等。Eureka是Netflix開源的一款產品、是SpringCloud生態的的重要的一個組件之一。zookeeper是Apache的分佈式應用程序協調服務，也是一款經典的服務註冊中心產品、常常是和Dubbo配合使用。 Consul 是 HashiCorp 公司推出的開源產品，與Eureka相比，保證了強一致性卻犧牲了可用性。Nacos 是alibba 2018年開源的、基於了阿里巴巴大規模的生產經驗，也是給了用戶一個新的選擇。關於這些後期會有詳細的文章介紹，這裏只作一個全面的介紹。

2.2 配置管理

對於傳統的單體應用，一個配置文件就能夠解決配置問題，可是在微服務中，多個機器部署的時候，修改配置文件是一個至關繁瑣的問題。爲此、這個時候就須要引入一個組件。SpringCloud提供了這樣的組件：Spring Cloud Config.固然國內大的互聯網公司都有本身的配置中心、好比百度的DisConf、淘寶的Diamond等等。固然因爲各方面的緣由，這些產品可能存在一些其餘問題。而Spring Cloud Conf是可以和Spring無縫集成。對於大多數的中小企業來講，這樣的配置也是夠的。

2.3 服務調用方式

在微服架構中，少不了的就是服務間的調用，調用的方式Spring Cloud採用的是基於HTTP的REST方式。Dubbo採用的事RPC方式。在面臨微服務基礎框架選型時，Spring Cloud和Dubbo只能二選一。這也是你們老是將兩者作對比的緣由。Dubbo的定位是一款RPC框架，而Spring Cloud的目標是提供微服一站式解決方案。因此Dubbo和Spring Cloud並非徹底的競爭關係。

2.4 負載均衡

LB 即負載均衡，也是微服務或分佈式集羣中經常使用的一種應用。簡單來說就是將用戶的請求平攤的分配到多個服務上，從而達到高可用的目的。經常使用的負載均衡有軟件Nginx，LVS，硬件F5等。在Sping Coud生態中，Sping Coud Netflix Ribbon 是基於Netflix Ribbon實現的一套客戶端負載均衡的工具。負載均衡的算法有不少，好比輪詢、隨機、權重等等。

2.5 服務熔斷

在微服務架構中，是存在着不少的服務的，並且服務之間的調用可能跨網絡，由於網絡的不可靠性等緣由出現調用故障和延遲，若是此時調用方的請求不斷的增長，長時間的等待會造成調用方佔用不少的資源，甚至形成系統崩潰和癱瘓，即所謂的"雪崩效應"。爲了解決這樣的問題，須要對故障和延遲進行隔離和管理，便出現了斷路器。它的做用就是在發生沒法訪問、超時、異常等問題時，會經過服務降級的方式，熔斷該節點的調用，快速返回「錯誤」的信息、可處理的備選響應，從而保證故障的蔓延等問題。Hystrix提供了熔斷模式和隔離模式用來解決雪崩效應，Hystrix是在服務訪問失敗時下降阻塞的影響範圍，避免整個服務被拖垮。

2.6 服務路由與網關

在微服務架構模式下，後端服務的實例通常是動態的，對應客戶端來講很難動態的發現改動的服務實例地址，爲此，一般會引入網關API Gateway。從而簡化內部服務的相互調用的複雜度。在Spring Cloud生態中Zull就是一個落地的技術。Zull是Netfix開源的一個基於JVM的路由和服務器負載均衡器，其做用就是服務轉發。固然也是能夠做爲資源統一訪問入口。同時。也能夠在網關作一些權限的校驗。

2.7 調用鏈路追蹤

在微服務架構的生產實踐中，常常會遇到這樣的案例：客戶反饋問題，開發、應急和運維人員從入口服務A開始查起，肯定服務A沒有問題，而後將問題傳遞到B服務，依次查詢下去，這樣的排查多了不少的沒必要要，基於調用鏈的服務治理系統能夠解決以上的問題。Spring Cloud Sleuth就是Sping Cloud生態中實現調用鏈追蹤的一個子項目，能夠結合Zipkin很好的事項故障快速定位問題。