本篇開始進行對于Docker的學(xué)習(xí)，Docker是一個陌生的詞匯，那么本篇開始就先從技術(shù)架構(gòu)的角度出發(fā)，先對于技術(shù)架構(gòu)有一個基本的認(rèn)識

基本概念

1. 應(yīng)用和系統(tǒng)：為了完成一整套服務(wù)的一個程序或者是一組相互配合的程序
2. 模塊和組件：當(dāng)應(yīng)用量比較龐大時，會把整個目標(biāo)劃分為多個模塊和組件
3. 分布式：系統(tǒng)中的多個模塊被部署到不同的服務(wù)器上，那這樣就可以叫做是分布式系統(tǒng)，換句話說，比如平時的web服務(wù)器和數(shù)據(jù)庫放在不同的服務(wù)器上，那這就是一個分布式的系統(tǒng)
4. 集群：部署在多個服務(wù)器上，為了實現(xiàn)一個特定功能的組件，那這個整體就被叫做是集群，比如MySQL會工作在不同的服務(wù)器上，一起來進行數(shù)據(jù)庫的服務(wù)目標(biāo)，這樣就可以被叫做是一組數(shù)據(jù)庫集群
5. 中間件：一類提供不同應(yīng)用程序用戶相互通信的軟件，也就是說是不同技術(shù)工具或者是數(shù)據(jù)庫之間的橋梁，這種就是中間件
6. 容器：可以讓開發(fā)者把應(yīng)用以及依賴放到一個可以移植的鏡像中，發(fā)布到各種操作系統(tǒng)的機器上，實現(xiàn)出一個虛擬化的功能
7. 容器編排：這是一個用于進行管理云平臺上多個主機上的容器化的應(yīng)用，可以讓部署容器化的應(yīng)用更加簡單高效

架構(gòu)演進

現(xiàn)在假設(shè)做了一個項目，這個項目會隨著時間的推移不斷復(fù)雜，那么就需要不斷的更換架構(gòu)

單機架構(gòu)

在項目的最初期，由于工程量比較小，所以使用最基礎(chǔ)的內(nèi)容就可以了，因此，使用普通的基礎(chǔ)的單機架構(gòu)即可：

這也是最基礎(chǔ)的架構(gòu)，把所有的內(nèi)容都放到了單機服務(wù)器上

應(yīng)用數(shù)據(jù)分離架構(gòu)

隨著工程的升級，此時隨著數(shù)據(jù)越來越多，原來的單機服務(wù)器已經(jīng)不能夠滿足日常的需求了，因此就要想辦法降低這個單機服務(wù)器上的數(shù)據(jù)量，因此就采取出了應(yīng)用數(shù)據(jù)分離架構(gòu)

這種架構(gòu)模式也比較簡單，直接把應(yīng)用的數(shù)據(jù)存儲在了應(yīng)用服務(wù)器上，而把存儲的內(nèi)容數(shù)據(jù)，放到了存儲服務(wù)器上，其實也就是把數(shù)據(jù)庫服務(wù)部署在了一個存儲服務(wù)器上

應(yīng)用服務(wù)集群架構(gòu)

隨著用戶的繼續(xù)增長，數(shù)據(jù)量變得更多了，此時單臺的應(yīng)用服務(wù)器已經(jīng)不能夠滿足日常的需求了，因此現(xiàn)在又要進行升級技術(shù)，下面給出兩種方案：

1. 垂直擴展：購買更加優(yōu)秀的應(yīng)用服務(wù)器來進行應(yīng)對這種更多的流量，優(yōu)點是直接把項目換個機器部署即可，但是缺點是價格比較昂貴
2. 水平擴展：把軟件的架構(gòu)進行調(diào)整，增加應(yīng)用層的硬件，把用戶的流量分擔(dān)到不同的應(yīng)用服務(wù)器中，從而增加系統(tǒng)的承載能力，這樣的方案優(yōu)勢是可以控制成本，提升空間大，但是缺點是需要技術(shù)的支持，因為直接相當(dāng)于更換了一種存儲模式

之后，這個項目采取了一個水平擴展的方案，引入了一個負載均衡的方案，把用戶的流量合理的分發(fā)到了不同的應(yīng)用服務(wù)器上，當(dāng)然這也需要一個專門的系統(tǒng)組件，叫做流量分發(fā)，實際的負載均衡不僅僅說的是工作在應(yīng)用層的是負載均衡，在網(wǎng)絡(luò)層的也可能是負載均衡

下面是這種模式下的架構(gòu)圖：

讀寫分離/主從分離架構(gòu)

在把用戶的請求通過負載均衡發(fā)送到不同的應(yīng)用服務(wù)器后，確實可以進行并行處理很多的問題了，并且隨著用戶的增長還可以使用擴張服務(wù)器的方法來進行壓力的緩解，但是現(xiàn)在的問題是，不管擴展多少個服務(wù)器，這些請求都會從數(shù)據(jù)庫來進行讀寫數(shù)據(jù)，這就導(dǎo)致數(shù)據(jù)庫的壓力會很大，那么如何解決數(shù)據(jù)庫壓力大的問題？

如果想要使用擴展數(shù)據(jù)庫的方法來解決，其實是不可以的，因為數(shù)據(jù)是需要保持一致性的，采取多個數(shù)據(jù)庫服務(wù)器，會導(dǎo)致整體上的數(shù)據(jù)一致性不能得到合理的保證，因此引入了一個主從服務(wù)器的概念

保留一個主要的數(shù)據(jù)庫作為寫入數(shù)據(jù)庫，而其他的數(shù)據(jù)庫都是從屬數(shù)據(jù)庫，從庫的所有數(shù)據(jù)都來自于主庫的數(shù)據(jù)，經(jīng)過同步之后，從庫可以維護著和主庫一樣的數(shù)據(jù)，為了分擔(dān)數(shù)據(jù)庫的壓力，可以把數(shù)據(jù)的請求全部給主庫來進行處理，但是讀取的數(shù)據(jù)請求分散到從庫中，這樣就會導(dǎo)致壓力進一步的減少，達到一個緩解的目的

下面是這種架構(gòu)的模式圖：

冷熱分離架構(gòu)

隨著訪問量的繼續(xù)增加，就會發(fā)現(xiàn)業(yè)務(wù)中的一些數(shù)據(jù)的讀取頻率是要比其他數(shù)據(jù)的要高的，那么這些數(shù)據(jù)就被叫做是熱點數(shù)據(jù)，對于熱點數(shù)據(jù)來說，可以把其緩存起來，這樣就可以減少訪問數(shù)據(jù)庫的次數(shù)，比如前面用過的Redis就是這樣達到原理

垂直分庫

隨著業(yè)務(wù)的增加，大量的數(shù)據(jù)存儲在一個庫中是不可行的，一個主數(shù)據(jù)庫已經(jīng)完成不了這么多的數(shù)據(jù)了，因此就可以把數(shù)據(jù)進行分別存儲，比如對于評論和數(shù)據(jù)，可以進行商品ID的hash，分別存儲到不同的庫中即可，具體的模式圖如下所示：

微服務(wù)

隨著項目的持續(xù)增加，整個項目可能會有很多個模塊來組成，因此就需要把業(yè)務(wù)分發(fā)給不同的開發(fā)團隊來進行維護，每個團隊獨立實現(xiàn)自己的微服務(wù)，相互之間對數(shù)據(jù)的直接訪問進行隔離，總體來說就是可以進行一些相互之間的調(diào)用關(guān)聯(lián)等：

容器編排架構(gòu)

系統(tǒng)的資源利用率其實在上述的架構(gòu)中是不高的，為什么這樣說？因為有很多的資源是用來應(yīng)對短時的高并發(fā)，而很多的資源在正常情況下都是用不到的，那這樣的問題如何解決？容器化技術(shù)就帶來了解決方案

目前最為流行的容器化技術(shù)就是Docker了，容器管理服務(wù)是K8S，可以把應(yīng)用服務(wù)打包為一個Docker鏡像，使用K8S來進行動態(tài)的分發(fā)和鏡像的部署，Docker的鏡像可以理解為是一個能夠運行你的服務(wù)的最小的一個操作系統(tǒng)，里面放的是其對應(yīng)的數(shù)據(jù)，那么把整個操作系統(tǒng)打包wield一個鏡像之后，就可以分發(fā)到對應(yīng)的機器上，直接啟動這個Docker的鏡像，就可以把服務(wù)打包起來，使得服務(wù)部署變得輕松簡單

在實際的使用中可能還會有生產(chǎn)和研發(fā)的K8S集群，這樣的集群不會公用，會有對應(yīng)的研發(fā)和測試集群等

至此，一個高可用，高并發(fā)的系統(tǒng)模型就這樣誕生了