為什么要用springcloud?

在回答這個(gè)問(wèn)題之前我們要了解什么是微服務(wù)架構(gòu)熄诡，以及這些年系統(tǒng)架構(gòu)的演變過(guò)程

什么是微服務(wù)架構(gòu)

“微服務(wù) ”一詞源于Martin Fowler 的名為 Microservices 的博文闯捎，簡(jiǎn)單地說(shuō)辕翰， 微服務(wù)是系統(tǒng)架構(gòu)上的一種設(shè)計(jì)風(fēng)格室梅， 它的主旨是將一個(gè)原本獨(dú)立的系統(tǒng)拆分成多個(gè)小型服務(wù)较坛，這些小型服務(wù)都在各自獨(dú)立的進(jìn)程中運(yùn)行，服務(wù)之間通過(guò)基于HTTP的RESTful API進(jìn)行通信協(xié)作酵紫。 被拆分成的每一個(gè)小型服務(wù)都圍繞著系統(tǒng)中的某一項(xiàng)或一些耦合度較高的業(yè)務(wù)功能進(jìn)行構(gòu)建告嘲， 并且每個(gè)服務(wù)都維護(hù)著自身的數(shù)據(jù)存儲(chǔ)错维、 業(yè)務(wù)開(kāi)發(fā)、自動(dòng)化測(cè)試案例以及獨(dú)立部署機(jī)制橄唬。 由千有了輕量級(jí)的通信協(xié)作基礎(chǔ)赋焕， 所以這些微服務(wù)可以使用不同的語(yǔ)言來(lái)編寫(xiě)。

系統(tǒng)架構(gòu)的演變過(guò)程

架構(gòu)原始階段：萬(wàn)能的單機(jī)

xitongjiagou

架構(gòu)的最原始階段仰楚，即一臺(tái)服務(wù)器搞定一切隆判。傳統(tǒng)官網(wǎng)、論壇等應(yīng)用僧界，只需要一臺(tái)侨嘀。對(duì)應(yīng)的web服務(wù)器、數(shù)據(jù)庫(kù)捂襟、靜態(tài)文件資源等咬腕，部署到一臺(tái)服務(wù)器上即可。一般5萬(wàn)pv到30萬(wàn)pv訪問(wèn)量笆豁，結(jié)合內(nèi)核參數(shù)調(diào)優(yōu)郎汪、web應(yīng)用性能參數(shù)調(diào)優(yōu)赤赊、數(shù)據(jù)庫(kù)調(diào)優(yōu)闯狱，基本上能夠穩(wěn)定的運(yùn)行。

架構(gòu)動(dòng)靜分離階段：靜態(tài)緩存 + 文件存儲(chǔ)

//nginx動(dòng)靜分離
server {
    listen 80;
    server_name ds.oldxu.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
    location ~* \.(png|gif|jpg|mp4)$ {
        root /images;
        expires 1d;
    }
}

xitongjiagou

當(dāng)訪問(wèn)壓力達(dá)到100萬(wàn)pv到300萬(wàn)pv的時(shí)候抛计，我們看到前端web服務(wù)出現(xiàn)性能瓶頸哄孤。大量的web請(qǐng)求被堵塞，同時(shí)服務(wù)器的CPU吹截、磁盤IO瘦陈、帶寬都有壓力。這時(shí)候我們一方面將網(wǎng)站圖片波俄、js晨逝、css、html及應(yīng)用服務(wù)相關(guān)的文件存儲(chǔ)在oss中懦铺，另外一方面通過(guò)CDN將靜態(tài)資源分布式緩存在各個(gè)節(jié)點(diǎn)實(shí)現(xiàn)“就近訪問(wèn)”捉貌。通過(guò)將動(dòng)態(tài)請(qǐng)求、靜態(tài)請(qǐng)求的訪問(wèn)分離（“動(dòng)靜分離”）冬念，有效解決服務(wù)器在磁盤IO趁窃、帶寬方面的訪問(wèn)壓力。

架構(gòu)分布式階段：業(yè)務(wù)拆分 負(fù)載均衡

xitongjiagou

當(dāng)訪問(wèn)量達(dá)到1000萬(wàn)pv到5000萬(wàn)pv急前，雖然“動(dòng)靜分離”有效分離了靜態(tài)請(qǐng)求的壓力醒陆，但是動(dòng)態(tài)請(qǐng)求的壓力已經(jīng)讓服務(wù)器“吃不消”。最直觀的現(xiàn)象是裆针，前端訪問(wèn)堵塞刨摩、延遲寺晌、服務(wù)器進(jìn)程增多、cpu100%澡刹，并且出現(xiàn)常見(jiàn)502/503/504的錯(cuò)誤碼折剃。顯然單臺(tái)web服務(wù)器已經(jīng)滿足不了需求，這里需要通過(guò)負(fù)載均衡技術(shù)增加多臺(tái)web服務(wù)器（對(duì)應(yīng)ECS可以選擇不同可用區(qū)像屋，進(jìn)一步保障高可用）怕犁。因而告別單機(jī)的時(shí)代，轉(zhuǎn)變分布式架構(gòu)的階段己莺。

雖然這個(gè)時(shí)候我們可以看到通過(guò)分布式文件系統(tǒng)OSS已經(jīng)解決了文件存儲(chǔ)的性能問(wèn)題奏甫，CDN也已經(jīng)解決靜態(tài)資源訪問(wèn)的性能問(wèn)題。但是當(dāng)訪問(wèn)壓力再次增加凌受，這個(gè)時(shí)候web服務(wù)器和數(shù)據(jù)庫(kù)方面依舊是瓶頸阵子。在此我們通過(guò)垂直擴(kuò)展，進(jìn)一步切分web服務(wù)器和數(shù)據(jù)庫(kù)的壓力胜蛉，解決性能問(wèn)題挠进。

在業(yè)務(wù)層，可以把不同的功能模塊拆分到不同的服務(wù)器上面進(jìn)行單獨(dú)部署誊册。比如领突，用戶模塊、訂單模塊案怯、商品模塊等君旦，拆分到不同服務(wù)器上面部署。在數(shù)據(jù)庫(kù)層嘲碱，當(dāng)結(jié)合數(shù)據(jù)庫(kù)緩存金砍，數(shù)據(jù)庫(kù)壓力還是很大的時(shí)候。我們通過(guò)讀寫(xiě)分離的方式麦锯，進(jìn)一步切分及降低數(shù)據(jù)庫(kù)的壓力恕稠。

結(jié)合業(yè)務(wù)拆分、讀寫(xiě)分離扶欣，在數(shù)據(jù)庫(kù)層鹅巍，比如我們同樣可以把用戶模塊、訂單模塊宵蛀、商品模塊等昆著。所涉及的數(shù)據(jù)庫(kù)表：用戶模塊表、訂單模塊表术陶、商品模塊表等凑懂，分別存放到不同數(shù)據(jù)庫(kù)中，如用戶模塊庫(kù)梧宫、訂單模塊庫(kù)接谨、商品模塊庫(kù)等摆碉。然后把不同數(shù)據(jù)庫(kù)分別部署到不同服務(wù)器中。

當(dāng)訪問(wèn)量達(dá)到5000萬(wàn)pv及以上時(shí)脓豪，真達(dá)到千萬(wàn)級(jí)架構(gòu)以上訪問(wèn)量的時(shí)候巷帝，我們可以看到垂直擴(kuò)展的架構(gòu)也已經(jīng)開(kāi)始“山窮水盡”。比如扫夜，讀寫(xiě)分離僅解決“讀”的壓力楞泼，面對(duì)高訪問(wèn)量，在數(shù)據(jù)庫(kù)“寫(xiě)”的壓力上面“力不從心”笤闯，出現(xiàn)性能瓶頸堕阔。另外，分庫(kù)雖然將壓力拆分到不同數(shù)據(jù)庫(kù)中颗味。但單表的數(shù)據(jù)量達(dá)到TB級(jí)別以上超陆，顯然已經(jīng)達(dá)到傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)處理的極限。

當(dāng)前主流架構(gòu)面臨的問(wèn)題

• 由于單體系統(tǒng)部署在一個(gè)進(jìn)程內(nèi)浦马，功能模塊之間耦合性強(qiáng)相互影響时呀。
  應(yīng)用中的這些功能模塊的使用場(chǎng)景、并發(fā)量晶默、消耗的資源類型都各有不同谨娜，這樣使得我們對(duì)各個(gè)業(yè)務(wù)模塊的系統(tǒng)容量很難給出較為準(zhǔn)確的評(píng)估。
• 隨著系統(tǒng)功能越來(lái)越復(fù)雜荤胁， 相應(yīng)的應(yīng)用也不斷增加瞧预，我們的靜態(tài)配置就會(huì)變得越來(lái)越難以維護(hù)屎债。并且面對(duì)不斷發(fā)展的業(yè)務(wù)仅政，我們的集群規(guī)模、服務(wù)的位置 盆驹、服務(wù)的命名等都有可能發(fā)生化圆丹，如果還是通過(guò)手工維護(hù)的方式，那么極易發(fā)生錯(cuò)誤或是命名沖突等問(wèn)題躯喇。同時(shí)辫封，對(duì)于這類靜態(tài)內(nèi)容的維護(hù)也必將消耗大量的人力。
• Nginx等設(shè)施的路由實(shí)現(xiàn)負(fù)載均衡需要運(yùn)維人員需要手工維護(hù)這些路由規(guī)則與服務(wù)實(shí)例列表廉丽，當(dāng)有實(shí)例增減或是IP地址變動(dòng)等情況發(fā)生的時(shí)候倦微， 也需要手工地去同步修，果當(dāng)系統(tǒng)規(guī)模不斷增大正压， 那么這些看似簡(jiǎn)單的維護(hù) 任務(wù)會(huì)變得越來(lái)越難欣福， 并且出現(xiàn)配置錯(cuò)誤的概率也會(huì)逐漸增加。
• 單體應(yīng)用中都實(shí)現(xiàn)一套校驗(yàn)邏輯焦履。隨著服務(wù)規(guī)模的擴(kuò)大拓劝，這些校驗(yàn)邏輯的冗余變得越來(lái)越多雏逾，給開(kāi)發(fā)和測(cè)試人員都造成困擾。

springCloud

SpringCloud項(xiàng)目不同于其他 Spring 的優(yōu)秀項(xiàng)目郑临， 它不再是一個(gè)基礎(chǔ)框架類栖博， 而是
一個(gè)更高層次的、 架構(gòu)視角的綜合性大型項(xiàng)目厢洞， 其目標(biāo)旨在構(gòu)建一套標(biāo)準(zhǔn)化的微服務(wù)解決
方案仇让， 讓架構(gòu)師、 開(kāi)發(fā)者在使用微服務(wù)理念構(gòu)建應(yīng)用系統(tǒng)的時(shí)候躺翻， 面對(duì)各個(gè)環(huán)節(jié)的問(wèn)題都
可以找到相應(yīng)的組件來(lái)處理妹孙。 引用網(wǎng)友戲稱的一個(gè)比喻： Spring Cloud 可以說(shuō)是 Spring 社
區(qū)為微服務(wù)架構(gòu)提供的一個(gè)
“ 全家桶 ” 套餐。 由于 “ 套餐 ” 中的組件通過(guò)一個(gè)社區(qū)進(jìn)行包
裝與整合获枝， 使得 “ 套餐 ” 中各個(gè)組件之間的配合變得更加和諧， 這可以有效減少我們?cè)诮M
件的選型和整合上花費(fèi)的精力嚣崭， 所以它可以幫助我們快速構(gòu)建起基礎(chǔ)的微服務(wù)架構(gòu)系統(tǒng)。

考慮 Spring Cloud 的原因有如下幾點(diǎn)：

• Spring Cloud 來(lái)源于 Spring唱蒸，質(zhì)量古今、穩(wěn)定性披诗、持續(xù)性都可以得到保證粒竖。
• spirng Cloud 天然支持 Spring Boot，更加便于業(yè)務(wù)落地造锅。
• Spring Cloud 是 Java 領(lǐng)域最適合做微服務(wù)的框架宇驾。相比于其它框架倍靡，Spring Cloud 對(duì)微服務(wù)周邊環(huán)境的支持力度最大。對(duì)于中小企業(yè)來(lái)講课舍，使用門檻較低。
• Spring Cloud 是微服務(wù)架構(gòu)的最佳落地方案他挎。
• 與分布式系統(tǒng)相關(guān)的復(fù)雜性 – 包括網(wǎng)絡(luò)問(wèn)題筝尾，延遲開(kāi)銷，帶寬問(wèn)題办桨，安全問(wèn)題筹淫。
• 處理服務(wù)發(fā)現(xiàn)的能力 – 服務(wù)發(fā)現(xiàn)允許集群中的進(jìn)程和服務(wù)找到彼此并進(jìn)行通信。
• 解決冗余問(wèn)題 – 冗余問(wèn)題經(jīng)常發(fā)生在分布式系統(tǒng)中呢撞。
• 負(fù)載平衡 – 改進(jìn)跨多個(gè)計(jì)算資源（例如計(jì)算機(jī)集群损姜，網(wǎng)絡(luò)鏈接饰剥，中央處理單元）的工作負(fù)載分布。
• 減少性能問(wèn)題 – 減少因各種操作開(kāi)銷導(dǎo)致的性能問(wèn)題摧阅。

SpringCloud

xitongjiagou