學(xué)習(xí)目標(biāo)

1. 回顧架構(gòu)的演進(jìn)。
2. 明確springcloud是什么？
3. 明確spring、springboot和springcloud之間的關(guān)系。
4. 了解springcloud的常用組件及其作用。

第1章 架構(gòu)演進(jìn)

1、單體架構(gòu)

我相信，絕大部分同學(xué)都用過SSM框架進(jìn)行過開發(fā)，當(dāng)時你們所在項(xiàng)目組肯定是將所有的功能模塊全部放在了同一個框架里面，只是不同的功能建了一個不同的包，然后所有的功能模塊數(shù)據(jù)存儲在一個數(shù)據(jù)庫里面，然后通過一臺Tomcat容器去啟動服務(wù)。

我們注重客戶提出的每個要求，我們充分考慮每一個細(xì)節(jié)，我們積極的做好成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)服務(wù)，我們努力開拓更好的視野，通過不懈的努力，成都創(chuàng)新互聯(lián)贏得了業(yè)內(nèi)的良好聲譽(yù)，這一切，也不斷的激勵著我們更好的服務(wù)客戶。 主要業(yè)務(wù)：網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)站設(shè)計(jì),小程序制作,網(wǎng)站開發(fā),技術(shù)開發(fā)實(shí)力，DIV+CSS，PHP及ASP，ASP.Net，SQL數(shù)據(jù)庫的技術(shù)開發(fā)工程師。

這種架構(gòu)在最開始公司業(yè)務(wù)量、數(shù)據(jù)量、并發(fā)量小的情況下是沒問題的，甚至對于開發(fā)人員更友好。

但是來了，但是隨著你公司的發(fā)展，業(yè)務(wù)量增大，功能需求增多，數(shù)據(jù)量并發(fā)量也增大的時候，單體架構(gòu)就不行了，為什么呢？

1. 隨著業(yè)務(wù)量增大，單臺Tomcat很容易達(dá)到性能瓶頸，一般的服務(wù)器上Tomcat的最大并發(fā)量也就在200左右。
2. 因?yàn)橹挥幸慌_服務(wù)器，出現(xiàn)問題就直接掛掉了，此時客戶端都訪問不了服務(wù)，這個時候就讓我想起了，讀大學(xué)的時候選選修課，每次都要等好幾個小時才能選上，體驗(yàn)極差。

2、集群架構(gòu)

為了解決上面的這些問題，必須要從根源上進(jìn)行優(yōu)化。此時集群架構(gòu)出現(xiàn)。

集群架構(gòu)的邏輯其實(shí)很簡單，它就是把整個系統(tǒng)從一臺服務(wù)器上部署變成了多臺服務(wù)器部署，只是對整個系統(tǒng)的復(fù)制拷貝。然后增加Nginx服務(wù)器做負(fù)載均衡而已。

但是集群架構(gòu)也存在一些問題：

• 如果系統(tǒng)中的某個很小的功能發(fā)生了版本迭代，那這個時候就需要將所有的系統(tǒng)全部停掉，然后進(jìn)行更新。而且可能整個系統(tǒng)非常龐大了，開發(fā)這個大系統(tǒng)的部門人員可能也非常多組織架構(gòu)也不好管理。
• 雖然你系統(tǒng)做了集群，但是數(shù)據(jù)庫往往才是制約你系統(tǒng)性能的最大因素，當(dāng)并發(fā)量大了，數(shù)據(jù)量大了，數(shù)據(jù)庫是處理不過來的。

3、業(yè)務(wù)垂直化拆分

針對上面的問題，架構(gòu)再一次需要改進(jìn)，整個大系統(tǒng)不適用了，就將不同的功能模塊拆分成小系統(tǒng)。

對業(yè)務(wù)進(jìn)行垂直化拆分，簡單來說，就是可以按照系統(tǒng)的業(yè)務(wù)功能拆分出多個業(yè)務(wù)模塊子系統(tǒng)。每個子系統(tǒng)由不同的業(yè)務(wù)團(tuán)隊(duì)負(fù)責(zé)。

4、服務(wù)化改造

隨著對業(yè)務(wù)系統(tǒng)進(jìn)行垂直化改造之后，以業(yè)務(wù)功能緯度拆分出來多個子系統(tǒng)，而在各個子系統(tǒng)中，會存在比較多的共享業(yè)務(wù)，比如用戶信息查詢，在支付業(yè)務(wù)中會涉及到、在首頁中也會涉及到。那么勢必會造成重復(fù)開發(fā)產(chǎn)生非常多的冗余代碼。那么這個時候就引入了服務(wù)化改造的思想，也就是 SOA把一些通用的、會被多個上層服務(wù)調(diào)用的模塊獨(dú)立拆分出來，形成一些共享的基礎(chǔ)服務(wù)。這些被拆分出來的共享服務(wù)相對來說是比較獨(dú)立，并且可重用。 比如用戶管理服務(wù)，包含用戶注冊、用戶查詢等功能。比如單點(diǎn)登錄服務(wù)。

SOA 的核心目標(biāo)就是通過服務(wù)的流程化來實(shí)現(xiàn)業(yè)務(wù)的靈活性，而這個流程化其實(shí)就是由一系列相關(guān)聯(lián)的任務(wù)組成，這一系列相關(guān)聯(lián)的任務(wù)可以通過一系列的服務(wù)組合來實(shí)現(xiàn)具體的業(yè)務(wù)功能SOA 面向服務(wù)架構(gòu)，從語義上說，它與面向過程、面向?qū)ο?、面向組件一樣，是一種軟件組建及開發(fā)的方式。所以在 SOA 中，服務(wù)是最核心的抽象手段，業(yè)務(wù)被劃分為一些列粗粒度的業(yè)務(wù)服務(wù)和業(yè)務(wù)流程。

SOA 中更強(qiáng)調(diào) ESB 企業(yè)服務(wù)總線，企業(yè)服務(wù)總線可以使得服務(wù)之間的交互是動態(tài)的，以及服務(wù)位置是透明的。這樣的好處是服務(wù)的調(diào)用者和服務(wù)的提供者之間是高度解耦的。從而使得服務(wù)有更高的靈活性以及隔離性。

ESB： 是從面相服務(wù)架構(gòu)(SOA)發(fā)展過來的，主要是對多個系統(tǒng)中的服務(wù)調(diào)用者和服務(wù)提供者的解耦。ESB 本身提供了服務(wù)暴露、接入、協(xié)議轉(zhuǎn)化、數(shù)據(jù)格式轉(zhuǎn)化、路由等功能。

SOA 主要解決的問題：

• 信息孤島
• 互聯(lián)互通
• 業(yè)務(wù)重用

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

業(yè)務(wù)系統(tǒng)實(shí)施服務(wù)化改造后，原本共享的業(yè)務(wù)被拆分，形成可復(fù)用的服務(wù)，可以在最大程度上避免共享業(yè)務(wù)的重復(fù)建設(shè)、資源連接瓶頸等問題出現(xiàn)。那么那些被拆分出來的服務(wù)，是否也需要以業(yè)務(wù)功能為維度來進(jìn)行拆分，使之能夠獨(dú)立進(jìn)行部署，以降低業(yè)務(wù)藕合和提升容錯性呢？

微服務(wù)并不是一種新思想的方法。它更像是一種思想的精煉，是一種服務(wù)化思想的最佳實(shí)踐方向而已，所以我認(rèn)為微服務(wù)其實(shí)是在 SOA 思路下，隨著各個企業(yè)對于服務(wù)化治理上不斷地完善，以及對軟件的交付鏈路以及基礎(chǔ)設(shè)施逐步成熟之下的一種自然的產(chǎn)物。 微服務(wù)也是一種面向服務(wù)的架構(gòu)模型，只是它更強(qiáng)調(diào)服務(wù)的粒度。也就是服務(wù)的職責(zé)更加單一更加精煉我們也可以把 SOA 看成是微服務(wù)的超集。 也就是多個微服務(wù)可以組成一個 soa 服務(wù)。

6、微服務(wù)和 SOA 架構(gòu)的區(qū)別

經(jīng)常會有同學(xué)問，微服務(wù)和 SOA 架構(gòu)有什么區(qū)別。這個區(qū)別一定要從架構(gòu)的發(fā)展過程來了解。這兩種架構(gòu)模式，其實(shí)本質(zhì)上應(yīng)該是在分布式架構(gòu)這條時間線上，基于服務(wù)化思想的不斷完善，以及基礎(chǔ)設(shè)施的逐步成熟之下的一種升級。既然存在于時間線的先后，那也就意味著，這兩種架構(gòu)模式所關(guān)注的點(diǎn)不一樣。

SOA	MSA(微服務(wù))
遵循“盡可能多地共享”架構(gòu)方法	遵循“盡可能少地共享”架構(gòu)方法
重要性在于業(yè)務(wù)功能重用	重要性在于“有界上下文”的概念
他們有共同的治理和標(biāo)準(zhǔn)	他們注重人、合作和其他選擇的自由
使用企業(yè)服務(wù)總線（Enterprise Service bus，ESB）進(jìn)行通信	簡單消息傳遞系統(tǒng)
它們支持多種消息協(xié)議	使用輕量級協(xié)議，如HTTP/REST等
具有更多開銷的多線程來處理I/O	單線程通常使用事件循環(huán)特性來進(jìn)行非鎖定I/O處理
最大限度地提高應(yīng)用程序服務(wù)的可重用性	重點(diǎn)在于解耦
傳統(tǒng)的關(guān)系數(shù)據(jù)庫更常用	現(xiàn)代的關(guān)系數(shù)據(jù)庫更常用
一個系統(tǒng)性的改變需要修改整體	一個系統(tǒng)性的改變是創(chuàng)造一個新的服務(wù)
DevOps/Continuous Delivery正在變得流行，但還沒有成為主流	人們強(qiáng)烈關(guān)注DevOps/Continuous Delivery

第2章 Spring Cloud

上一章講到了架構(gòu)的演進(jìn)過程，事實(shí)上不管什么架構(gòu)，都是需要通過合適的框架技術(shù)進(jìn)行落地，從最開始的spring框架，到后來的springboot，再到現(xiàn)在的springcloud，那為什么需要springcloud呢？spring為什么不行呢？

要想整體弄明白這些問題，那我們接下來先弄清楚幾個概念，自己在腦海里面形成一套體系：

1. spring在開發(fā)過程中有什么問題？
2. springboot的出現(xiàn)解決了什么？
3. springboot跟springcloud是什么關(guān)系
4. springcloud是什么？它包含了什么？

1、spring的問題

事實(shí)上spring的出現(xiàn)就是為了簡化開發(fā)的，spring的核心概念絕大部分同學(xué)都能說出來，無非就是3個，IoC、DI、AOP，下面稍微解釋一下這仨兄弟是干嘛的。

• IoC實(shí)際上就是一個容器，它就是用來裝Bean對象的；回到最最基礎(chǔ)的層面，我們java開發(fā)就是在不斷的通過new創(chuàng)建對象，然后拿到對象之后調(diào)用對象里面的方法。OK，那在實(shí)際開發(fā)過程中，如果所有的對象都需要手動去創(chuàng)建將是一個非常繁瑣的過程，也許你有1萬個類，然后這1萬個類在各種地方都要創(chuàng)建對象，這個時候假設(shè)用到了A類的對象，然后你在B類中new了對象，如果要在C、D、E等等類中要用到這個對象的話，將會很麻煩，這只是一種情況，在開發(fā)中這種類似的現(xiàn)象隨處可見，所以spring為了解決這個過程，設(shè)計(jì)了一個IoC的功能，你就理解成一個中心容器，用來裝項(xiàng)目中幾乎所有需要用到的Bean對象。
• IoC的概念理解了，那么這個時候你要想，對象創(chuàng)建了，但是對象里面可能會存在別的一些成員屬性，而這些成員屬性又是另外的一些對象，舉個例子就是A對象里面有個成員屬性是B對象，那這個時候你要去進(jìn)行引用的關(guān)聯(lián)，這一步也非常麻煩和繁瑣，怎么辦呢？spring的DI幫你完成了，在A對象new的過程中，spring就會去中心容器找有沒有B對象，有的話就把這個B對象賦值給A對象的屬性。
• AOP的概念其實(shí)更好理解，它是基于動態(tài)代理完成的，你們要清晰的指導(dǎo)，代理就是做增強(qiáng)的，什么意思呢？假設(shè)有一個對象的業(yè)務(wù)功能就是創(chuàng)建訂單，OK，那我不想直接調(diào)用這個對象的創(chuàng)建訂單功能，我想在創(chuàng)建訂單之前和之后干點(diǎn)別的事情，比如說打印日志這個事，這個時候就用到了代理。

OK，spring基于這仨兄弟確實(shí)簡化了很多開發(fā)的流程，但是，在最開始的過程中spring在進(jìn)行IoC注入對象的過程中，它是基于XML方式的，這個邏輯很容易理解，就是你要把什么對象放到容器中去，只需要在XML文件中配置一下就好了。

但是，正因?yàn)檫@個，使得spring變的無比的繁瑣，你想想，一個項(xiàng)目中得用到多少個對象，每個對象都去配置一下，完?duì)僮恿恕Ｒ獙憻o數(shù)個XML文件了。

spring開始發(fā)力，要優(yōu)化了，引入注解，但是沒用啊，如果你項(xiàng)目要集成別的組件呢？比如redis，比如mybatis。甚至在微服務(wù)項(xiàng)目中要引入集成各種組件的話，那更加崩潰。

其實(shí)歸根結(jié)底，spring還是沒有解決IoC注入的復(fù)雜流程，以及外部化配置的統(tǒng)一管理。

2、springboot

看過springboot源碼的同學(xué)都知道，springboot底層其實(shí)會走一遍spring的流程。也就是springboot依賴于spring，同時它也在spring的基礎(chǔ)之上作了一些工作。

具體作了啥，實(shí)際上就是解決IoC自動注入和配置統(tǒng)一管理，使得這個工作不再需要程序員去做了，框架自己干了。具體怎么解決的參照之前的內(nèi)容。

3、springcloud生態(tài)

先明確springcloud是什么？網(wǎng)上都說，啊呀springcloud就是做微服務(wù)的，它是一個生態(tài)啊等等。進(jìn)說一些我們聽不懂的。

那我這里用最簡單的語言去解釋一下：

springcloud就是springboot集成各種各樣starter組件的一個集體，springcloud底層核心框架就是springboot，然后springboot集成不同組件的時候不需要程序員去寫XML文件以及配置文件了，而是一些好事之徒，他們基于springboot自動裝配原理寫了starter組件，然后將這些starter組件和springboot的整體我們給了一個名字叫做springcloud。

明白了吧，那知道springcloud是什么之后，在來看這個生態(tài)里面包含了啥，springboot我知道了，starter組件有哪些呢？

這個不用去背，我們自己根據(jù)數(shù)據(jù)流向從整體上去串一串就好了，當(dāng)你串明白了，那你離架構(gòu)師就不是太遠(yuǎn)了。

（1）網(wǎng)關(guān)

Gateway組件

我們知道 spring cloud 可以用來開發(fā)微服務(wù)，但是應(yīng)該很少有同學(xué)真正知道 spring cloud 是什么。

官方的解釋是：spring cloud 提供了一些可以讓開發(fā)者快速構(gòu)建分布式應(yīng)用的工具，這些服務(wù)可以很好的工作在任何分布式環(huán)境下。

既然提供的是一些快速構(gòu)建微服務(wù)應(yīng)用的工具，那么我們需要了解微服務(wù)開發(fā)過程中需要解決哪些問題？

在微服務(wù)實(shí)施之后，各個服務(wù)的拆分粒度很小，對于客戶端來說，做一個操作可能會涉及到后端的多個服務(wù)組件的調(diào)用，那意味著它需要頻繁的發(fā)起多次訪問才能進(jìn)行數(shù)據(jù)聚合實(shí)現(xiàn)用戶的功能。

如果我們在所有的微服務(wù)之前增加一個網(wǎng)關(guān)，對于客戶端來說它需要做什么功能操作直接調(diào)用網(wǎng)關(guān)并且告訴網(wǎng)關(guān)所要做的事情即可，網(wǎng)關(guān)根據(jù)請求的功能對后端的多個服務(wù)的數(shù)據(jù)進(jìn)行聚合聚合哦從而減少客戶端的調(diào)用頻次。

并且，由于有了網(wǎng)關(guān)的聚合，我們還可以在網(wǎng)關(guān)層對請求進(jìn)行統(tǒng)一鑒權(quán)和認(rèn)證； 包括還可以實(shí)現(xiàn)限流、請求日志統(tǒng)一記錄、 灰度發(fā)布等等。

（2）遠(yuǎn)程通信

Openfeign、Dubbo

服務(wù)拆分以后就會涉及到服務(wù)的遠(yuǎn)程通信，比如 http 協(xié)議或者 rpc 協(xié)議。

（3）服務(wù)發(fā)現(xiàn)

Eureka、Nacos

在滿足基礎(chǔ)通信的基礎(chǔ)上，如何做到服務(wù)的統(tǒng)一管理以及服務(wù)的動態(tài)感知，就需要涉及到服務(wù)的注冊中心來實(shí)現(xiàn)服務(wù)注冊和發(fā)現(xiàn)的功能。

（4）負(fù)載均衡

Ribbon、Dubbo

假設(shè)服務(wù)提供者為了擴(kuò)大吞吐量，采用 10 臺機(jī)器的集群部署，這個時候客戶端從注冊中心獲得服務(wù)以后，應(yīng)該調(diào)用哪臺機(jī)器呢？

所以必然有一種負(fù)載均衡的機(jī)制，來實(shí)現(xiàn)客戶端請求的分發(fā)。

（5）熔斷、限流、降級

Hystrix、Sentinel

在分布式架構(gòu)中，各個服務(wù)節(jié)點(diǎn)一定需要滿足高可用，所以對于服務(wù)本身來說，一方面是在有準(zhǔn)備的前提下做好充足的擴(kuò)容。另一方面，服務(wù)需要有熔斷、限流、降級的能力。

當(dāng)一個服務(wù)調(diào)用另外一個服務(wù)，可能因?yàn)榫W(wǎng)絡(luò)原因、或者連接池滿等問題導(dǎo)致頻繁出現(xiàn)錯誤，需要有一種熔斷機(jī)制，來防止因?yàn)檎埱蠖逊e導(dǎo)致整個應(yīng)用雪崩。

當(dāng)發(fā)現(xiàn)整個系統(tǒng)的確負(fù)載過高的時候，可以選擇降級某些功能或某些調(diào)用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。

在設(shè)置了熔斷以及降級策略后，還有一種手段來保護(hù)系統(tǒng)，就是限流算法。

我們能夠通過全鏈路壓測了解到整個系統(tǒng)的吞吐量，但實(shí)際上的流量可能會超過我們預(yù)期的值，比如存在惡意攻擊、或者突然的高峰流量。在這種情況下可以通過限流來保護(hù)系統(tǒng)不崩潰，但是對于部分用戶來說，會出現(xiàn)被限流導(dǎo)致體驗(yàn)不好的情況。

（6）配置中心

Config、Nacos

服務(wù)拆分以后，服務(wù)的數(shù)量非常多，如果所有的配置都以配置文件的方式放在應(yīng)用本地的話，非常難以管理，可以想象當(dāng)有幾百上千個進(jìn)程中有一個配置出現(xiàn)了問題，是很難將它找出來的，因而需要有統(tǒng)一的配置中心，來管理所有的配置，進(jìn)行統(tǒng)一的配置下發(fā)。

在微服務(wù)中，配置往往分為幾類，一類是幾乎不變的配置，這種配置可以直接打在容器鏡像里面，第二類是啟動時就會確定的配置，這種配置往往通過環(huán)境變量，在容器啟動的時候傳進(jìn)去，第三類就是統(tǒng)一的配置，需要通過配置中心進(jìn)行下發(fā)，例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置文件中統(tǒng)一配置。

（7）分布式事務(wù)

Seata

對于數(shù)據(jù)庫的垂直拆分，已經(jīng)服務(wù)的拆分，單體的數(shù)據(jù)庫事務(wù)完全不能滿足需求了，這個時候就需要一個第三方的協(xié)調(diào)工具來做到統(tǒng)一管理事務(wù)提交回滾等操作，這個時候Seata出現(xiàn)了。

4、服務(wù)帶來的問題

（1）業(yè)務(wù)團(tuán)隊(duì)的痛點(diǎn)

1. 對于業(yè)務(wù)開發(fā)團(tuán)隊(duì)而言，最強(qiáng)的是技術(shù)嗎？一定不是，業(yè)務(wù)團(tuán)隊(duì)最強(qiáng)的一定是對于業(yè)務(wù)的理解和熟悉程度。
2. 而業(yè)務(wù)應(yīng)用的核心價(jià)值，就是為了實(shí)現(xiàn)業(yè)務(wù)場景，而不是寫微服務(wù)，微服務(wù)只是一種實(shí)現(xiàn)業(yè)務(wù)的手段。
3. 業(yè)務(wù)團(tuán)隊(duì)除了關(guān)心業(yè)務(wù)之外，他們所面臨的最大的挑戰(zhàn)在于，如何保證系統(tǒng)的穩(wěn)定性何可擴(kuò)展性、如何設(shè)計(jì)一個安全的 open api。如果對服務(wù)進(jìn)行拆分、如何保證跨庫的數(shù)據(jù)一致性。以及對于舊系統(tǒng)的改造。
4. 于公司層面而言，業(yè)務(wù)團(tuán)隊(duì)的壓力還來自于時間人力的投入，我們用于被各種 deadline 趕著走。所以作為一個業(yè)務(wù)程序員，如果在這個 deadline 之前還需要花更多的時間投入在spring cloud 這些工具的學(xué)習(xí)上，那無疑是雪上加霜。公司對于業(yè)務(wù)團(tuán)隊(duì)的考核，永遠(yuǎn)只看結(jié)果！

（2）跨語言帶來的問題

微服務(wù)有一個很重要的特性，就是不同的微服務(wù)可以采用自己最擅長的語言來編寫程序。這種特性在企業(yè)中落地的時候又會帶來一些問題。

比如公司內(nèi)部會開發(fā)一些公共的類庫或者框架，也或者會使用第三方的類庫或者框架來實(shí)現(xiàn)某些功能。

但是由于公司的微服務(wù)用了各種各樣的語言，那意味著這些類庫需要針對不同的語言開發(fā)兼容版本。如果是主流語言還好，如果是一些小眾語言，那對于這些基礎(chǔ)組件的開發(fā)者而言無疑是晴天霹靂.

（3）總結(jié)

從這些痛點(diǎn)中可以發(fā)現(xiàn)，我們所做的所有非業(yè)務(wù)類的事情，都是為了保證把請求發(fā)送到正確的地方，并且能夠及時或得正確的結(jié)果。那對于對于業(yè)務(wù)開發(fā)人員而言，是否有必要去關(guān)心這些呢？

回到最開始我們說的一個例子，在進(jìn)行計(jì)算機(jī)網(wǎng)絡(luò)通信的時候，開發(fā)人員有必要去關(guān)心網(wǎng)絡(luò)通信的細(xì)節(jié)嗎？ 我們在使用 http 協(xié)議進(jìn)行數(shù)據(jù)傳輸時，關(guān)心過底層是使用 TCP 還是 udp？數(shù)據(jù)是怎么傳輸?shù)模?/p>

既然我們不需要關(guān)心這些，那對于微服務(wù)架構(gòu)中的這些問題，業(yè)務(wù)開發(fā)人員為什么一定要關(guān)心服務(wù)的通訊呢？

名稱欄目：架構(gòu)演變之SpringCloud由來
URL分享：http://uogjgqi.cn/article/codssgp.html