本篇開始進行對于Docker的學習，Docker是一個陌生的詞匯，那么本篇開始就先從技術架構的角度出發(fā)，先對于技術架構有一個基本的認識

基本概念

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

架構演進

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

單機架構

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

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

應用數(shù)據(jù)分離架構

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

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

應用服務集群架構

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

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

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

下面是這種模式下的架構圖：

讀寫分離/主從分離架構

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

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

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

下面是這種架構的模式圖：

冷熱分離架構

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

垂直分庫

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

微服務

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

容器編排架構

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

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

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

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