火的一塌糊涂的SpringCloud到底是個啥?

時至今日，Springcloud幾乎已經(jīng)是互聯(lián)網(wǎng)公司的標配了，但是很多同學(xué)可能對SpringCloud還不是特別的了解，微服務(wù)和SpirngCloud經(jīng)常傻傻分不清楚，今天的我們的文章是介紹下SpringCloud生態(tài)；順便把微服務(wù)的和SpirngCloud的關(guān)系，在跟大家解釋下；因為要想理解SpringCloud，怎么也離不了微服務(wù)。

因為SpringCloud火爆的大背景就是微服務(wù)架構(gòu)的火爆，接下來我們就按照先說微服務(wù)，再說SpringCloud的順序，給大家一一介紹。

· 微服務(wù)

提到微服務(wù)相信大家都不太陌生，互聯(lián)網(wǎng)經(jīng)過這么多年的發(fā)展，從最初的草莽時代，到現(xiàn)在巨頭林立的階段，很多領(lǐng)域都已經(jīng)相對完善。

從早期的單體架構(gòu)、集群架構(gòu)、分布式架構(gòu)、到現(xiàn)在基本人人都是微服務(wù)架構(gòu)，這里我們先通過幾張圖來看下互聯(lián)網(wǎng)技術(shù)架構(gòu)的演進。

· 單體架構(gòu)

我們都知道互聯(lián)網(wǎng)剛開始發(fā)展的時候，用戶量是非常少的，能接觸到網(wǎng)絡(luò)的人都是極其有限的，所以這個時候的互聯(lián)網(wǎng)的架構(gòu)師是這樣的，只有一個服務(wù)器，一個數(shù)據(jù)庫。

· 集群架構(gòu)

緊接著，隨著互聯(lián)網(wǎng)的發(fā)展，用戶量的增加（就是能玩的電腦的人多了），原來的這個單體的架構(gòu)支撐不了這么大的用戶訪問量了，之前一個服務(wù)器，現(xiàn)在網(wǎng)站動不動就掛了，這個課怎么得了；大佬一咬牙，一跺腳，一個服務(wù)器不行，加多來幾個服務(wù)器，就這么一不小心互聯(lián)網(wǎng)的技術(shù)架構(gòu)就變成了集群架構(gòu)。

· 分布式架構(gòu)

本來一切都這么安靜發(fā)生著，好像宇宙大和諧的樣子，用戶感覺網(wǎng)速嗖嗖的，大佬們也感覺我們的想法真牛逼，簡直可以改變世界?？墒菦]想到，突然互聯(lián)網(wǎng)迎來了前所未有的大發(fā)展，因為多年前有以為老人在中國的南海邊畫了一個圈。

這個時候各位技術(shù)大佬可是坐不住了，網(wǎng)站總是卡死可怎么辦，以為增加的服務(wù)器根本解決不了問題，之前所有的業(yè)務(wù)都在同一個服務(wù)器中，非常復(fù)雜。這個時候就開始把之前耦合在一起的業(yè)務(wù)給拆分來了，比如：訂單模塊、用戶模塊等；這樣互聯(lián)網(wǎng)的技術(shù)架構(gòu)也就演變。

· 微服務(wù)架構(gòu)

本來分布式架構(gòu)基本滿足了現(xiàn)在互聯(lián)網(wǎng)的發(fā)展，一切都這么安靜的發(fā)生著，但是大廠的可是永遠不那么安分，依然進行著創(chuàng)新，想要進一步提高效率，所以之前僅從業(yè)務(wù)單元進行拆分，還是滿足不了大廠的需求，所以就對業(yè)務(wù)進行了更加細粒度的拆分，而且每一個服務(wù)都可以獨立部署，這就就是我們現(xiàn)在所說的微服務(wù)。

· SpringCloud

好了，到這里互聯(lián)網(wǎng)的技術(shù)架構(gòu)演變基本就這么回事兒，最終實現(xiàn)微服務(wù)的技術(shù)就是我們接下來要介紹SpringCloud，要說SpringCloud是個啥，先買個關(guān)子，且聽我慢慢道來。

SpringCloud是微服務(wù)架構(gòu)的集大成者，將一系列優(yōu)秀的組件進行了整合（大雜燴）已經(jīng)在國內(nèi)眾多大中小型的公司有實際應(yīng)用案例。許多公司的業(yè)務(wù)線全部擁抱SpringCloud，部分公司選擇部分擁抱SpringCloud.

之所以說它是大雜燴，我們可以通過下面這張圖來感受一下，因為它幾乎就包攬了所有微服務(wù)架構(gòu)所需的技術(shù)組件。這里再給大家透露一個小秘密，就是SpringCloud中的很多組件，都是一家電影公司開源的；你能想象嗎？一家電影公司的技術(shù)實力都這么強，我們真的應(yīng)該反思反思了。

SpringCloud中組件很多，并且還在擴充中，所以我們就介紹幾個常用的組件：

• Eureka：服務(wù)治理組件，包含服務(wù)注冊與發(fā)現(xiàn)

• Feign：聲明式服務(wù)調(diào)用組件

• Ribbon：客戶端負載均衡的服務(wù)調(diào)用組件

• Hystrix：容錯管理組件，實現(xiàn)了熔斷器

• Zuul：網(wǎng)關(guān)組件，提供智能路由、訪問過濾等功能

• Config：分布式配置中心組件，用來統(tǒng)一配置文件

通過這么多核心的組件就可以輕松的搭建起一個個微服務(wù)系統(tǒng)架構(gòu)，由于都是一個生態(tài)內(nèi)的技術(shù)，所以很多技術(shù)都很兼容，極大的降低了開發(fā)的門開，所以現(xiàn)在基本是互聯(lián)網(wǎng)公司的，都上微服務(wù)架構(gòu)了，接下來我們就挨個來看下這幾個組件吧。

· Eureka服務(wù)治理組件

Eureka是Netflix開發(fā)的服務(wù)治理框架，是一個基于REST的服務(wù)，主要用于服務(wù)間的注冊發(fā)現(xiàn)、負載均衡等。

· Feign聲明式服務(wù)調(diào)用組件

Feign是一個聲明式的web服務(wù)客戶端，一種負載均衡的HTTP客戶端,使用Feign調(diào)用API就像調(diào)用本地方法一樣，從避免了調(diào)用目標微服務(wù)時，需要不斷的解析/封裝json數(shù)據(jù)的繁瑣，通常是和Ribbon一起實現(xiàn)。

· Ribbon負載均衡組件

Ribbon 是一個基于HTTP 和 TCP的 客服端負載均衡工具，包括Feign 提供的聲明式服務(wù)調(diào)用也是基于該Ribbon 實現(xiàn)的。Ribbon默認提供很多種負載均衡算法，例如輪詢、隨機等等。我們也可以根據(jù)自己的需要自定義的負載均衡策略。

· Hystrix熔斷限流組件

Hystrix這個組件就有點復(fù)雜了，因為它可能沒有具體的實現(xiàn)某項功能，他主要的作用提高系統(tǒng)的高可用性和穩(wěn)定性，在分布式系統(tǒng)環(huán)境下，服務(wù)間各種依賴，一個業(yè)務(wù)調(diào)用通常依賴多個基礎(chǔ)服務(wù)是非常常見的。而Hystrix就起到了監(jiān)控服務(wù)，以及服務(wù)容錯的作用，如果處理問題不及時，就很可能出現(xiàn)雪崩，后果不堪設(shè)想。

· Zuul服務(wù)網(wǎng)關(guān)組件

Zuul是微服務(wù)API網(wǎng)關(guān)，也是用戶訪問的第一道關(guān)，所有用戶的請求都會經(jīng)過Zuul才能到達后端應(yīng)用程序。Zuul提供了動態(tài)路由、監(jiān)控、彈性負載和安全功能。Zuul底層利用各種filter實現(xiàn)如下功能：

• 認證和安全，識別每個需要認證的資源，拒絕不符合要求的請求。

• 性能監(jiān)測，在服務(wù)邊界追蹤并統(tǒng)計數(shù)據(jù)，提供精確的生產(chǎn)視圖。

• 動態(tài)路由，根據(jù)需要將請求動態(tài)路由到后端集群。

• 壓力測試，逐漸增加對集群的流量以了解其性能。

• 負載卸載，預(yù)先為每種類型的請求分配容量，當請求超過容量時自動丟棄。

• 靜態(tài)資源處理，直接在邊界返回某些響應(yīng)。

所以在網(wǎng)關(guān)這一層，除了核心的路由功能外，也是限流的一種手段。

· Config分布式配置中心組件

Config是一個解決分布式系統(tǒng)的配置管理方案。它包含了Client和Server兩個部分，server提供配置文件的存儲、以接口的形式將配置文件的內(nèi)容提供出去，client通過接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。工作中也經(jīng)常和攜程開源的Apllo一起使用。

好了，到這里就基本給大家介紹了SpringCloud的幾個核心組件，如果我們把這些核心組件搞定后，就基本把微服務(wù)的核心知識搞定啦！