?我的博客：蘭陵笑笑生,歡迎瀏覽博客！
?近年來，隨著互聯(lián)網(wǎng)公司自身的業(yè)務體系越來越大，系統(tǒng)復雜度越來越高，導致我們不得不將服務進行拆分，微服務的概念也是迅速在互聯(lián)網(wǎng)發(fā)酵。我們也迫切的需要一套框架、一個生態(tài)系統(tǒng)能夠健全、穩(wěn)定的為我們解決問題。本章就簡單的介紹一下微服務的概念，以及Spring Cloud的生態(tài)組件。
一、微服務架構簡介
?微服務架構風格是將單體應用程序開發(fā)為一組小型服務的方法，每個服務運行在自己的進程中，服務之間通過輕量級的通訊機制(通常是HTTP資源api).。每一個服務是圍繞這個業(yè)務能力構建，并且可以獨立的部署、可獨立擴展。不同的服務可以使用不同的語言來編寫，也可以使用不同的數(shù)據(jù)存儲?？偨Y如下：
服務功能單一
可獨立部署、獨立擴展
可跨語言編程
服務間良好的通信機制
?在https://spring.io/ 官方網(wǎng)站介紹Spring Cloud時，以圖的方式展現(xiàn)了微服的架構圖：圖中包含了網(wǎng)關，各個微服務單元，服務注冊，服務配置等
?
二、SpingCloud 簡介
?在微服務的發(fā)展過程中，隨著分布式水平的提高，系統(tǒng)會變得越來越復雜，系統(tǒng)發(fā)生的錯誤率隨著系統(tǒng)的復雜性呈指數(shù)型增長、因此微服務也出現(xiàn)了反對的聲音，認為微服務增加了系統(tǒng)的維護、部署難度、導致一些功能模塊和代碼很難反復的使用。有沒有一種框架可以盡可能的解決上述的問題呢。有，就是Spring Cloud。
這里就介紹一下SpringCloud中微服務常用的功能
2.1 注冊與發(fā)現(xiàn)
?服務的發(fā)現(xiàn)是微服務架構中很重要的一個組件，在微服務中，系統(tǒng)之間的依賴非常的頻繁，服務調用方A服務調用B服務、C服務等多個服務，這些被調用方為了保證自身的高可用、通常都是以集群的模式部署。如果我們將被調用方的這些信息如果寫在了A服務中、這樣的配置是會很復雜的，同時如果我們動態(tài)的調整服務提供方，這樣是不利于服務的管理的。因此我們迫切需要一種服務發(fā)現(xiàn)的機制。所有的服務啟動時就向注冊中心提交自身的信息。比如URL地址、PORT端口等信息。調用方只需要從注冊中心請求指定的服務即可、目前的落地的技術有Eureka、Consul、Zookeeper、 Nacos 等 。Eureka是Netflix開源的一款產(chǎn)品、是SpringCloud生態(tài)的的重要的一個組件之一。zookeeper是Apache的分布式應用程序協(xié)調服務，也是一款經(jīng)典的 服務注冊中心產(chǎn)品、經(jīng)常是和Dubbo配合使用。 Consul 是 HashiCorp 公司推出的開源產(chǎn)品， 與Eureka相比，保證了強一致性卻犧牲了可用性。Nacos 是alibba 2018年開源的、基于了阿里巴巴大規(guī)模的生產(chǎn)經(jīng)驗，也是給了用戶一個新的選擇。關于這些后期會有詳細的文章介紹，這里只做一個全面的介紹。
2.2 配置管理
?對于傳統(tǒng)的單體應用，一個配置文件就可以解決配置問題，但是在微服務中，多個機器部署的時候，修改配置文件是一個相當繁瑣的問題。為此、這個時候就需要引入一個組件。SpringCloud提供了這樣的組件：Spring Cloud Config.當然國內(nèi)大的互聯(lián)網(wǎng)公司都有自己的配置中心、比如百度的DisConf、淘寶的Diamond等等。當然由于各方面的原因，這些產(chǎn)品可能存在一些其他問題。而Spring Cloud Conf是能夠和Spring無縫集成。對于大多數(shù)的中小企業(yè)來說，這樣的配置也是夠的。
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生態(tài)中，Sping Coud Netflix Ribbon 是基于Netflix Ribbon實現(xiàn)的一套客戶端負載均衡的工具。負載均衡的算法有很多，比如輪詢、隨機、權重等等。
2.5 服務熔斷
?在微服務架構中，是存在著很多的服務的，而且服務之間的調用可能跨網(wǎng)絡，因為網(wǎng)絡的不可靠性等原因出現(xiàn)調用故障和延遲，如果此時調用方的請求不斷的增加，長時間的等待會形成調用方占用很多的資源，甚至造成系統(tǒng)崩潰和癱瘓，即所謂的"雪崩效應"。為了解決這樣的問題，需要對故障和延遲進行隔離和管理，便出現(xiàn)了斷路器。它的作用就是在發(fā)生無法訪問、超時、異常等問題時，會通過服務降級的方式，熔斷該節(jié)點的調用，快速返回“錯誤”的信息、可處理的備選響應，從而保證故障的蔓延等問題。Hystrix提供了熔斷模式和隔離模式用來解決雪崩效應，Hystrix是在服務訪問失敗時降低阻塞的影響范圍，避免整個服務被拖垮。
2.6 服務路由與網(wǎng)關
?在微服務架構模式下，后端服務的實例一般是動態(tài)的，對應客戶端來說很難動態(tài)的發(fā)現(xiàn)改動的服務實例地址，為此，通常會引入網(wǎng)關API Gateway。 從而簡化內(nèi)部服務的相互調用的復雜度。在Spring Cloud生態(tài)中Zull就是一個落地的技術。Zull是Netfix開源的一個基于JVM的路由和服務器負載均衡器，其作用就是服務轉發(fā)。當然也是可以作為資源統(tǒng)一訪問入口。同時。也可以在網(wǎng)關做一些權限的校驗。
2.7 調用鏈路追蹤
?在微服務架構的生產(chǎn)實踐中，經(jīng)常會遇到這樣的案例：客戶反饋問題，開發(fā)、應急和運維人員從入口服務A開始查起，確定服務A沒有問題，然后將問題傳遞到B服務，依次查詢下去，這樣的排查多了很多的不必要，基于調用鏈的服務治理系統(tǒng)可以解決以上的問題。Spring Cloud Sleuth就是Sping Cloud生態(tài)中實現(xiàn)調用鏈追蹤的一個子項目，可以結合Zipkin很好的事項故障快速定位問題。
三 、總結
?
?在微服務架構的實踐過程中，Spring Cloud 以其獨有的生態(tài)迅速的擴張，覆蓋了整個互聯(lián)網(wǎng)公司。當然Spring Cloud中的組件不僅僅包含了剛才介紹的，還包括了安全、任務、消息總線、批處理等各種組件。如上圖。
?本章簡單介紹了微服務的架構以及Spring Cloud的生態(tài)，在之后的章節(jié)中，我將詳細的介紹各個功能的具體實現(xiàn)。
?以上就是本期的分享，你還可以關注本博客的#Spring Cloud基礎教程系列!#
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！
