1、引言
本文以設(shè)計(jì)淘寶網(wǎng)的后臺(tái)架構(gòu)為例，介紹從一百個(gè)并發(fā)到千萬(wàn)級(jí)并發(fā)情況下服務(wù)端的架構(gòu)的14次演進(jìn)過(guò)程，同時(shí)列舉出每個(gè)演進(jìn)階段會(huì)遇到的相關(guān)技術(shù)，讓大家對(duì)架構(gòu)的演進(jìn)有一個(gè)整體的認(rèn)知。文章最后匯總了一些架構(gòu)設(shè)計(jì)的原則。
（本文同步發(fā)布于：http://www.52im.net/thread-2665-1-1.html）
2、關(guān)于作者
huashiou：廣東工業(yè)大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)碩士畢業(yè)，大數(shù)據(jù)開(kāi)發(fā)工程師。在大數(shù)據(jù)領(lǐng)域具有多年的開(kāi)發(fā)經(jīng)驗(yàn)，對(duì)常用大數(shù)據(jù)技術(shù)都有所了解，在架構(gòu)設(shè)計(jì)、高并發(fā)、分布式等方面具有一定經(jīng)驗(yàn)。喜歡學(xué)習(xí)新技術(shù)，樂(lè)于分享，歡迎大家關(guān)注本博客。
3、相關(guān)文章
4、基本概念
在介紹架構(gòu)之前，為了避免部分讀者對(duì)架構(gòu)設(shè)計(jì)中的一些概念不了解，下面對(duì)幾個(gè)最基礎(chǔ)的概念進(jìn)行介紹。
1）什么是分布式？
系統(tǒng)中的多個(gè)模塊在不同服務(wù)器上部署，即可稱為分布式系統(tǒng)，如Tomcat和數(shù)據(jù)庫(kù)分別部署在不同的服務(wù)器上，或兩個(gè)相同功能的Tomcat分別部署在不同服務(wù)器上。
2）什么是高可用？
系統(tǒng)中部分節(jié)點(diǎn)失效時(shí)，其他節(jié)點(diǎn)能夠接替它繼續(xù)提供服務(wù)，則可認(rèn)為系統(tǒng)具有高可用性。
3）什么是集群？
一個(gè)特定領(lǐng)域的軟件部署在多臺(tái)服務(wù)器上并作為一個(gè)整體提供一類服務(wù)，這個(gè)整體稱為集群。
如Zookeeper中的Master和Slave分別部署在多臺(tái)服務(wù)器上，共同組成一個(gè)整體提供集中配置服務(wù)。
在常見(jiàn)的集群中，客戶端往往能夠連接任意一個(gè)節(jié)點(diǎn)獲得服務(wù)，并且當(dāng)集群中一個(gè)節(jié)點(diǎn)掉線時(shí)，其他節(jié)點(diǎn)往往能夠自動(dòng)的接替它繼續(xù)提供服務(wù)，這時(shí)候說(shuō)明集群具有高可用性。
4）什么是負(fù)載均衡？
請(qǐng)求發(fā)送到系統(tǒng)時(shí)，通過(guò)某些方式把請(qǐng)求均勻分發(fā)到多個(gè)節(jié)點(diǎn)上，使系統(tǒng)中每個(gè)節(jié)點(diǎn)能夠均勻的處理請(qǐng)求負(fù)載，則可認(rèn)為系統(tǒng)是負(fù)載均衡的。
5）什么是正向代理和反向代理？
系統(tǒng)內(nèi)部要訪問(wèn)外部網(wǎng)絡(luò)時(shí)，統(tǒng)一通過(guò)一個(gè)代理服務(wù)器把請(qǐng)求轉(zhuǎn)發(fā)出去，在外部網(wǎng)絡(luò)看來(lái)就是代理服務(wù)器發(fā)起的訪問(wèn)，此時(shí)代理服務(wù)器實(shí)現(xiàn)的是正向代理；
當(dāng)外部請(qǐng)求進(jìn)入系統(tǒng)時(shí)，代理服務(wù)器把該請(qǐng)求轉(zhuǎn)發(fā)到系統(tǒng)中的某臺(tái)服務(wù)器上，對(duì)外部請(qǐng)求來(lái)說(shuō)，與之交互的只有代理服務(wù)器，此時(shí)代理服務(wù)器實(shí)現(xiàn)的是反向代理。
簡(jiǎn)單來(lái)說(shuō)，正向代理是代理服務(wù)器代替系統(tǒng)內(nèi)部來(lái)訪問(wèn)外部網(wǎng)絡(luò)的過(guò)程，反向代理是外部請(qǐng)求訪問(wèn)系統(tǒng)時(shí)通過(guò)代理服務(wù)器轉(zhuǎn)發(fā)到內(nèi)部服務(wù)器的過(guò)程。
5、純真年代：?jiǎn)螜C(jī)架構(gòu)
以淘寶作為例子：在網(wǎng)站最初時(shí)，應(yīng)用數(shù)量與用戶數(shù)都較少，可以把Tomcat和數(shù)據(jù)庫(kù)部署在同一臺(tái)服務(wù)器上。瀏覽器往www.taobao.com發(fā)起請(qǐng)求時(shí)，首先經(jīng)過(guò)DNS服務(wù)器（域名系統(tǒng)）把域名轉(zhuǎn)換為實(shí)際IP地址10.102.4.1，瀏覽器轉(zhuǎn)而訪問(wèn)該IP對(duì)應(yīng)的Tomcat。
架構(gòu)瓶頸：隨著用戶數(shù)的增長(zhǎng)，Tomcat和數(shù)據(jù)庫(kù)之間競(jìng)爭(zhēng)資源，單機(jī)性能不足以支撐業(yè)務(wù)。
6、第一次演進(jìn)：Tomcat與數(shù)據(jù)庫(kù)分開(kāi)部署
Tomcat和數(shù)據(jù)庫(kù)分別獨(dú)占服務(wù)器資源，顯著提高兩者各自性能。
架構(gòu)瓶頸：隨著用戶數(shù)的增長(zhǎng)，并發(fā)讀寫數(shù)據(jù)庫(kù)成為瓶頸。
7、第二次演進(jìn)：引入本地緩存和分布式緩存
在Tomcat同服務(wù)器上或同JVM中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的html頁(yè)面等。通過(guò)緩存能把絕大多數(shù)請(qǐng)求在讀寫數(shù)據(jù)庫(kù)前攔截掉，大大降低數(shù)據(jù)庫(kù)壓力。其中涉及的技術(shù)包括：使用memcached作為本地緩存，使用Redis作為分布式緩存，還會(huì)涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點(diǎn)數(shù)據(jù)集中失效等問(wèn)題。
架構(gòu)瓶頸：緩存抗住了大部分的訪問(wèn)請(qǐng)求，隨著用戶數(shù)的增長(zhǎng)，并發(fā)壓力主要落在單機(jī)的Tomcat上，響應(yīng)逐漸變慢。
8、第三次演進(jìn)：引入反向代理實(shí)現(xiàn)負(fù)載均衡
在多臺(tái)服務(wù)器上分別部署Tomcat，使用反向代理軟件（Nginx）把請(qǐng)求均勻分發(fā)到每個(gè)Tomcat中。此處假設(shè)Tomcat最多支持100個(gè)并發(fā)，Nginx最多支持50000個(gè)并發(fā)，那么理論上Nginx把請(qǐng)求分發(fā)到500個(gè)Tomcat上，就能抗住50000個(gè)并發(fā)。
其中涉及的技術(shù)包括：Nginx、HAProxy，兩者都是工作在網(wǎng)絡(luò)第七層的反向代理軟件，主要支持http協(xié)議，還會(huì)涉及session共享、文件上傳下載的問(wèn)題。
架構(gòu)瓶頸：反向代理使應(yīng)用服務(wù)器可支持的并發(fā)量大大增加，但并發(fā)量的增長(zhǎng)也意味著更多請(qǐng)求穿透到數(shù)據(jù)庫(kù)，單機(jī)的數(shù)據(jù)庫(kù)最終成為瓶頸。
9、第四次演進(jìn)：數(shù)據(jù)庫(kù)讀寫分離
把數(shù)據(jù)庫(kù)劃分為讀庫(kù)和寫庫(kù)，讀庫(kù)可以有多個(gè)，通過(guò)同步機(jī)制把寫庫(kù)的數(shù)據(jù)同步到讀庫(kù)，對(duì)于需要查詢最新寫入數(shù)據(jù)場(chǎng)景，可通過(guò)在緩存中多寫一份，通過(guò)緩存獲得最新數(shù)據(jù)。其中涉及的技術(shù)包括：Mycat，它是數(shù)據(jù)庫(kù)中間件，可通過(guò)它來(lái)組織數(shù)據(jù)庫(kù)的分離讀寫和分庫(kù)分表，客戶端通過(guò)它來(lái)訪問(wèn)下層數(shù)據(jù)庫(kù)，還會(huì)涉及數(shù)據(jù)同步，數(shù)據(jù)一致性的問(wèn)題。
架構(gòu)瓶頸：業(yè)務(wù)逐漸變多，不同業(yè)務(wù)之間的訪問(wèn)量差距較大，不同業(yè)務(wù)直接競(jìng)爭(zhēng)數(shù)據(jù)庫(kù)，相互影響性能。
10、第五次演進(jìn)：數(shù)據(jù)庫(kù)按業(yè)務(wù)分庫(kù)
把不同業(yè)務(wù)的數(shù)據(jù)保存到不同的數(shù)據(jù)庫(kù)中，使業(yè)務(wù)之間的資源競(jìng)爭(zhēng)降低，對(duì)于訪問(wèn)量大的業(yè)務(wù)，可以部署更多的服務(wù)器來(lái)支撐。這樣同時(shí)導(dǎo)致跨業(yè)務(wù)的表無(wú)法直接做關(guān)聯(lián)分析，需要通過(guò)其他途徑來(lái)解決，但這不是本文討論的重點(diǎn)，有興趣的可以自行搜索解決方案。
架構(gòu)瓶頸：隨著用戶數(shù)的增長(zhǎng)，單機(jī)的寫庫(kù)會(huì)逐漸會(huì)達(dá)到性能瓶頸。
11、第六次演進(jìn)：把大表拆分為小表
比如針對(duì)評(píng)論數(shù)據(jù)，可按照商品ID進(jìn)行hash，路由到對(duì)應(yīng)的表中存儲(chǔ)；針對(duì)支付記錄，可按照小時(shí)創(chuàng)建表，每個(gè)小時(shí)表繼續(xù)拆分為小表，使用用戶ID或記錄編號(hào)來(lái)路由數(shù)據(jù)。只要實(shí)時(shí)操作的表數(shù)據(jù)量足夠小，請(qǐng)求能夠足夠均勻的分發(fā)到多臺(tái)服務(wù)器上的小表，那數(shù)據(jù)庫(kù)就能通過(guò)水平擴(kuò)展的方式來(lái)提高性能。其中前面提到的Mycat也支持在大表拆分為小表情況下的訪問(wèn)控制。
這種做法顯著的增加了數(shù)據(jù)庫(kù)運(yùn)維的難度，對(duì)DBA的要求較高。數(shù)據(jù)庫(kù)設(shè)計(jì)到這種結(jié)構(gòu)時(shí)，已經(jīng)可以稱為分布式數(shù)據(jù)庫(kù)，但是這只是一個(gè)邏輯的數(shù)據(jù)庫(kù)整體，數(shù)據(jù)庫(kù)里不同的組成部分是由不同的組件單獨(dú)來(lái)實(shí)現(xiàn)的，如分庫(kù)分表的管理和請(qǐng)求分發(fā)，由Mycat實(shí)現(xiàn)，SQL的解析由單機(jī)的數(shù)據(jù)庫(kù)實(shí)現(xiàn)，讀寫分離可能由網(wǎng)關(guān)和消息隊(duì)列來(lái)實(shí)現(xiàn)，查詢結(jié)果的匯總可能由數(shù)據(jù)庫(kù)接口層來(lái)實(shí)現(xiàn)等等，這種架構(gòu)其實(shí)是MPP（大規(guī)模并行處理）架構(gòu)的一類實(shí)現(xiàn)。
目前開(kāi)源和商用都已經(jīng)有不少M(fèi)PP數(shù)據(jù)庫(kù)，開(kāi)源中比較流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、華為的LibrA等等，不同的MPP數(shù)據(jù)庫(kù)的側(cè)重點(diǎn)也不一樣，如TiDB更側(cè)重于分布式OLTP場(chǎng)景，Greenplum更側(cè)重于分布式OLAP場(chǎng)景，這些MPP數(shù)據(jù)庫(kù)基本都提供了類似Postgresql、Oracle、MySQL那樣的SQL標(biāo)準(zhǔn)支持能力，能把一個(gè)查詢解析為分布式的執(zhí)行計(jì)劃分發(fā)到每臺(tái)機(jī)器上并行執(zhí)行，最終由數(shù)據(jù)庫(kù)本身匯總數(shù)據(jù)進(jìn)行返回，也提供了諸如權(quán)限管理、分庫(kù)分表、事務(wù)、數(shù)據(jù)副本等能力，并且大多能夠支持100個(gè)節(jié)點(diǎn)以上的集群，大大降低了數(shù)據(jù)庫(kù)運(yùn)維的成本，并且使數(shù)據(jù)庫(kù)也能夠?qū)崿F(xiàn)水平擴(kuò)展。
架構(gòu)瓶頸：數(shù)據(jù)庫(kù)和Tomcat都能夠水平擴(kuò)展，可支撐的并發(fā)大幅提高，隨著用戶數(shù)的增長(zhǎng)，最終單機(jī)的Nginx會(huì)成為瓶頸。
12、第七次演進(jìn)：使用LVS或F5來(lái)使多個(gè)Nginx負(fù)載均衡
由于瓶頸在Nginx，因此無(wú)法通過(guò)兩層的Nginx來(lái)實(shí)現(xiàn)多個(gè)Nginx的負(fù)載均衡。圖中的LVS和F5是工作在網(wǎng)絡(luò)第四層的負(fù)載均衡解決方案，其中LVS是軟件，運(yùn)行在操作系統(tǒng)內(nèi)核態(tài)，可對(duì)TCP請(qǐng)求或更高層級(jí)的網(wǎng)絡(luò)協(xié)議進(jìn)行轉(zhuǎn)發(fā)，因此支持的協(xié)議更豐富，并且性能也遠(yuǎn)高于Nginx，可假設(shè)單機(jī)的LVS可支持幾十萬(wàn)個(gè)并發(fā)的請(qǐng)求轉(zhuǎn)發(fā)；F5是一種負(fù)載均衡硬件，與LVS提供的能力類似，性能比LVS更高，但價(jià)格昂貴。由于LVS是單機(jī)版的軟件，若LVS所在服務(wù)器宕機(jī)則會(huì)導(dǎo)致整個(gè)后端系統(tǒng)都無(wú)法訪問(wèn)，因此需要有備用節(jié)點(diǎn)。可使用keepalived軟件模擬出虛擬IP，然后把虛擬IP綁定到多臺(tái)LVS服務(wù)器上，瀏覽器訪問(wèn)虛擬IP時(shí)，會(huì)被路由器重定向到真實(shí)的LVS服務(wù)器，當(dāng)主LVS服務(wù)器宕機(jī)時(shí)，keepalived軟件會(huì)自動(dòng)更新路由器中的路由表，把虛擬IP重定向到另外一臺(tái)正常的LVS服務(wù)器，從而達(dá)到LVS服務(wù)器高可用的效果。
此處需要注意的是，上圖中從Nginx層到Tomcat層這樣畫并不代表全部Nginx都轉(zhuǎn)發(fā)請(qǐng)求到全部的Tomcat，在實(shí)際使用時(shí)，可能會(huì)是幾個(gè)Nginx下面接一部分的Tomcat，這些Nginx之間通過(guò)keepalived實(shí)現(xiàn)高可用，其他的Nginx接另外的Tomcat，這樣可接入的Tomcat數(shù)量就能成倍的增加。
架構(gòu)瓶頸：由于LVS也是單機(jī)的，隨著并發(fā)數(shù)增長(zhǎng)到幾十萬(wàn)時(shí)，LVS服務(wù)器最終會(huì)達(dá)到瓶頸，此時(shí)用戶數(shù)達(dá)到千萬(wàn)甚至上億級(jí)別，用戶分布在不同的地區(qū)，與服務(wù)器機(jī)房距離不同，導(dǎo)致了訪問(wèn)的延遲會(huì)明顯不同。
13、第八次演進(jìn)：通過(guò)DNS輪詢實(shí)現(xiàn)機(jī)房間的負(fù)載均衡
在DNS服務(wù)器中可配置一個(gè)域名對(duì)應(yīng)多個(gè)IP地址，每個(gè)IP地址對(duì)應(yīng)到不同的機(jī)房里的虛擬IP。當(dāng)用戶訪問(wèn)www.taobao.com時(shí)，DNS服務(wù)器會(huì)使用輪詢策略或其他策略，來(lái)選擇某個(gè)IP供用戶訪問(wèn)。此方式能實(shí)現(xiàn)機(jī)房間的負(fù)載均衡，至此，系統(tǒng)可做到機(jī)房級(jí)別的水平擴(kuò)展，千萬(wàn)級(jí)到億級(jí)的并發(fā)量都可通過(guò)增加機(jī)房來(lái)解決，系統(tǒng)入口處的請(qǐng)求并發(fā)量不再是問(wèn)題。
架構(gòu)瓶頸：隨著數(shù)據(jù)的豐富程度和業(yè)務(wù)的發(fā)展，檢索、分析等需求越來(lái)越豐富，單單依靠數(shù)據(jù)庫(kù)無(wú)法解決如此豐富的需求。
14、第九次演進(jìn)：引入NoSQL數(shù)據(jù)庫(kù)和搜索引擎等技術(shù)
當(dāng)數(shù)據(jù)庫(kù)中的數(shù)據(jù)多到一定規(guī)模時(shí)，數(shù)據(jù)庫(kù)就不適用于復(fù)雜的查詢了，往往只能滿足普通查詢的場(chǎng)景。對(duì)于統(tǒng)計(jì)報(bào)表場(chǎng)景，在數(shù)據(jù)量大時(shí)不一定能跑出結(jié)果，而且在跑復(fù)雜查詢時(shí)會(huì)導(dǎo)致其他查詢變慢，對(duì)于全文檢索、可變數(shù)據(jù)結(jié)構(gòu)等場(chǎng)景，數(shù)據(jù)庫(kù)天生不適用。因此需要針對(duì)特定的場(chǎng)景，引入合適的解決方案。如對(duì)于海量文件存儲(chǔ)，可通過(guò)分布式文件系統(tǒng)HDFS解決，對(duì)于key value類型的數(shù)據(jù)，可通過(guò)HBase和Redis等方案解決，對(duì)于全文檢索場(chǎng)景，可通過(guò)搜索引擎如ElasticSearch解決，對(duì)于多維分析場(chǎng)景，可通過(guò)Kylin或Druid等方案解決。
當(dāng)然，引入更多組件同時(shí)會(huì)提高系統(tǒng)的復(fù)雜度，不同的組件保存的數(shù)據(jù)需要同步，需要考慮一致性的問(wèn)題，需要有更多的運(yùn)維手段來(lái)管理這些組件等。
架構(gòu)瓶頸：引入更多組件解決了豐富的需求，業(yè)務(wù)維度能夠極大擴(kuò)充，隨之而來(lái)的是一個(gè)應(yīng)用中包含了太多的業(yè)務(wù)代碼，業(yè)務(wù)的升級(jí)迭代變得困難。
15、第十次演進(jìn)：大應(yīng)用拆分為小應(yīng)用
按照業(yè)務(wù)板塊來(lái)劃分應(yīng)用代碼，使單個(gè)應(yīng)用的職責(zé)更清晰，相互之間可以做到獨(dú)立升級(jí)迭代。這時(shí)候應(yīng)用之間可能會(huì)涉及到一些公共配置，可以通過(guò)分布式配置中心Zookeeper來(lái)解決。
架構(gòu)瓶頸：不同應(yīng)用之間存在共用的模塊，由應(yīng)用單獨(dú)管理會(huì)導(dǎo)致相同代碼存在多份，導(dǎo)致公共功能升級(jí)時(shí)全部應(yīng)用代碼都要跟著升級(jí)。
16、第十一次演進(jìn)：復(fù)用的功能抽離成微服務(wù)
如用戶管理、訂單、支付、鑒權(quán)等功能在多個(gè)應(yīng)用中都存在，那么可以把這些功能的代碼單獨(dú)抽取出來(lái)形成一個(gè)單獨(dú)的服務(wù)來(lái)管理，這樣的服務(wù)就是所謂的微服務(wù)，應(yīng)用和服務(wù)之間通過(guò)HTTP、TCP或RPC請(qǐng)求等多種方式來(lái)訪問(wèn)公共服務(wù)，每個(gè)單獨(dú)的服務(wù)都可以由單獨(dú)的團(tuán)隊(duì)來(lái)管理。此外，可以通過(guò)Dubbo、SpringCloud等框架實(shí)現(xiàn)服務(wù)治理、限流、熔斷、降級(jí)等功能，提高服務(wù)的穩(wěn)定性和可用性。
架構(gòu)瓶頸：不同服務(wù)的接口訪問(wèn)方式不同，應(yīng)用代碼需要適配多種訪問(wèn)方式才能使用服務(wù)，此外，應(yīng)用訪問(wèn)服務(wù)，服務(wù)之間也可能相互訪問(wèn)，調(diào)用鏈將會(huì)變得非常復(fù)雜，邏輯變得混亂。
17、第十二次演進(jìn)：引入企業(yè)服務(wù)總線ESB屏蔽服務(wù)接口的訪問(wèn)差異
通過(guò)ESB統(tǒng)一進(jìn)行訪問(wèn)協(xié)議轉(zhuǎn)換，應(yīng)用統(tǒng)一通過(guò)ESB來(lái)訪問(wèn)后端服務(wù)，服務(wù)與服務(wù)之間也通過(guò)ESB來(lái)相互調(diào)用，以此降低系統(tǒng)的耦合程度。
這種單個(gè)應(yīng)用拆分為多個(gè)應(yīng)用，公共服務(wù)單獨(dú)抽取出來(lái)來(lái)管理，并使用企業(yè)消息總線來(lái)解除服務(wù)之間耦合問(wèn)題的架構(gòu)，就是所謂的SOA（面向服務(wù)）架構(gòu)，這種架構(gòu)與微服務(wù)架構(gòu)容易混淆，因?yàn)楸憩F(xiàn)形式十分相似。
個(gè)人理解，微服務(wù)架構(gòu)更多是指把系統(tǒng)里的公共服務(wù)抽取出來(lái)單獨(dú)運(yùn)維管理的思想，而SOA架構(gòu)則是指一種拆分服務(wù)并使服務(wù)接口訪問(wèn)變得統(tǒng)一的架構(gòu)思想，SOA架構(gòu)中包含了微服務(wù)的思想。
架構(gòu)瓶頸：業(yè)務(wù)不斷發(fā)展，應(yīng)用和服務(wù)都會(huì)不斷變多，應(yīng)用和服務(wù)的部署變得復(fù)雜，同一臺(tái)服務(wù)器上部署多個(gè)服務(wù)還要解決運(yùn)行環(huán)境沖突的問(wèn)題，此外，對(duì)于如大促這類需要?jiǎng)討B(tài)擴(kuò)縮容的場(chǎng)景，需要水平擴(kuò)展服務(wù)的性能，就需要在新增的服務(wù)上準(zhǔn)備運(yùn)行環(huán)境，部署服務(wù)等，運(yùn)維將變得十分困難。
18、第十三次演進(jìn)：引入容器化技術(shù)實(shí)現(xiàn)運(yùn)行環(huán)境隔離與動(dòng)態(tài)服務(wù)管理
目前最流行的容器化技術(shù)是Docker，最流行的容器管理服務(wù)是Kubernetes(K8S)，應(yīng)用/服務(wù)可以打包為Docker鏡像，通過(guò)K8S來(lái)動(dòng)態(tài)分發(fā)和部署鏡像。Docker鏡像可理解為一個(gè)能運(yùn)行你的應(yīng)用/服務(wù)的最小的操作系統(tǒng)，里面放著應(yīng)用/服務(wù)的運(yùn)行代碼，運(yùn)行環(huán)境根據(jù)實(shí)際的需要設(shè)置好。把整個(gè)“操作系統(tǒng)”打包為一個(gè)鏡像后，就可以分發(fā)到需要部署相關(guān)服務(wù)的機(jī)器上，直接啟動(dòng)Docker鏡像就可以把服務(wù)起起來(lái)，使服務(wù)的部署和運(yùn)維變得簡(jiǎn)單。
在大促的之前，可以在現(xiàn)有的機(jī)器集群上劃分出服務(wù)器來(lái)啟動(dòng)Docker鏡像，增強(qiáng)服務(wù)的性能，大促過(guò)后就可以關(guān)閉鏡像，對(duì)機(jī)器上的其他服務(wù)不造成影響（在第18節(jié)之前，服務(wù)運(yùn)行在新增機(jī)器上需要修改系統(tǒng)配置來(lái)適配服務(wù)，這會(huì)導(dǎo)致機(jī)器上其他服務(wù)需要的運(yùn)行環(huán)境被破壞）。
架構(gòu)瓶頸：使用容器化技術(shù)后服務(wù)動(dòng)態(tài)擴(kuò)縮容問(wèn)題得以解決，但是機(jī)器還是需要公司自身來(lái)管理，在非大促的時(shí)候，還是需要閑置著大量的機(jī)器資源來(lái)應(yīng)對(duì)大促，機(jī)器自身成本和運(yùn)維成本都極高，資源利用率低。
19、第十四次演進(jìn)：以云平臺(tái)承載系統(tǒng)
系統(tǒng)可部署到公有云上，利用公有云的海量機(jī)器資源，解決動(dòng)態(tài)硬件資源的問(wèn)題，在大促的時(shí)間段里，在云平臺(tái)中臨時(shí)申請(qǐng)更多的資源，結(jié)合Docker和K8S來(lái)快速部署服務(wù)，在大促結(jié)束后釋放資源，真正做到按需付費(fèi)，資源利用率大大提高，同時(shí)大大降低了運(yùn)維成本。
所謂的云平臺(tái)，就是把海量機(jī)器資源，通過(guò)統(tǒng)一的資源管理，抽象為一個(gè)資源整體，在之上可按需動(dòng)態(tài)申請(qǐng)硬件資源（如CPU、內(nèi)存、網(wǎng)絡(luò)等），并且之上提供通用的操作系統(tǒng)，提供常用的技術(shù)組件（如Hadoop技術(shù)棧，MPP數(shù)據(jù)庫(kù)等）供用戶使用，甚至提供開(kāi)發(fā)好的應(yīng)用，用戶不需要關(guān)系應(yīng)用內(nèi)部使用了什么技術(shù)，就能夠解決需求（如音視頻轉(zhuǎn)碼服務(wù)、郵件服務(wù)、個(gè)人博客等）。
在云平臺(tái)中會(huì)涉及如下幾個(gè)概念：
1）IaaS：基礎(chǔ)設(shè)施即服務(wù)。對(duì)應(yīng)于上面所說(shuō)的機(jī)器資源統(tǒng)一為資源整體，可動(dòng)態(tài)申請(qǐng)硬件資源的層面；
2）PaaS：平臺(tái)即服務(wù)。對(duì)應(yīng)于上面所說(shuō)的提供常用的技術(shù)組件方便系統(tǒng)的開(kāi)發(fā)和維護(hù)；
3）SaaS：軟件即服務(wù)。對(duì)應(yīng)于上面所說(shuō)的提供開(kāi)發(fā)好的應(yīng)用或服務(wù)，按功能或性能要求付費(fèi)。
至此：以上所提到的從高并發(fā)訪問(wèn)問(wèn)題，到服務(wù)的架構(gòu)和系統(tǒng)實(shí)施的層面都有了各自的解決方案。但同時(shí)也應(yīng)該意識(shí)到，在上面的介紹中，其實(shí)是有意忽略了諸如跨機(jī)房數(shù)據(jù)同步、分布式事務(wù)實(shí)現(xiàn)等等的實(shí)際問(wèn)題，這些問(wèn)題以后有機(jī)會(huì)再拿出來(lái)單獨(dú)討論。
20、架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)小結(jié)
1）架構(gòu)的調(diào)整是否必須按照上述演變路徑進(jìn)行？
不是的，以上所說(shuō)的架構(gòu)演變順序只是針對(duì)某個(gè)側(cè)面進(jìn)行單獨(dú)的改進(jìn)，在實(shí)際場(chǎng)景中，可能同一時(shí)間會(huì)有幾個(gè)問(wèn)題需要解決，或者可能先達(dá)到瓶頸的是另外的方面，這時(shí)候就應(yīng)該按照實(shí)際問(wèn)題實(shí)際解決。如在政府類的并發(fā)量可能不大，但業(yè)務(wù)可能很豐富的場(chǎng)景，高并發(fā)就不是重點(diǎn)解決的問(wèn)題，此時(shí)優(yōu)先需要的可能會(huì)是豐富需求的解決方案。
2）對(duì)于將要實(shí)施的系統(tǒng)，架構(gòu)應(yīng)該設(shè)計(jì)到什么程度？
對(duì)于單次實(shí)施并且性能指標(biāo)明確的系統(tǒng)，架構(gòu)設(shè)計(jì)到能夠支持系統(tǒng)的性能指標(biāo)要求就足夠了，但要留有擴(kuò)展架構(gòu)的接口以便不備之需。對(duì)于不斷發(fā)展的系統(tǒng)，如電商平臺(tái)，應(yīng)設(shè)計(jì)到能滿足下一階段用戶量和性能指標(biāo)要求的程度，并根據(jù)業(yè)務(wù)的增長(zhǎng)不斷的迭代升級(jí)架構(gòu)，以支持更高的并發(fā)和更豐富的業(yè)務(wù)。
3）服務(wù)端架構(gòu)和大數(shù)據(jù)架構(gòu)有什么區(qū)別？
所謂的“大數(shù)據(jù)”其實(shí)是海量數(shù)據(jù)采集清洗轉(zhuǎn)換、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析、數(shù)據(jù)服務(wù)等場(chǎng)景解決方案的一個(gè)統(tǒng)稱，在每一個(gè)場(chǎng)景都包含了多種可選的技術(shù)，如數(shù)據(jù)采集有Flume、Sqoop、Kettle等，數(shù)據(jù)存儲(chǔ)有分布式文件系統(tǒng)HDFS、FastDFS，NoSQL數(shù)據(jù)庫(kù)HBase、MongoDB等，數(shù)據(jù)分析有Spark技術(shù)棧、機(jī)器學(xué)習(xí)算法等。總的來(lái)說(shuō)大數(shù)據(jù)架構(gòu)就是根據(jù)業(yè)務(wù)的需求，整合各種大數(shù)據(jù)組件組合而成的架構(gòu)，一般會(huì)提供分布式存儲(chǔ)、分布式計(jì)算、多維分析、數(shù)據(jù)倉(cāng)庫(kù)、機(jī)器學(xué)習(xí)算法等能力。而服務(wù)端架構(gòu)更多指的是應(yīng)用組織層面的架構(gòu)，底層能力往往是由大數(shù)據(jù)架構(gòu)來(lái)提供。
4）有沒(méi)有一些架構(gòu)設(shè)計(jì)的原則？
a. N+1設(shè)計(jì)：系統(tǒng)中的每個(gè)組件都應(yīng)做到?jīng)]有單點(diǎn)故障；
b. 回滾設(shè)計(jì)：確保系統(tǒng)可以向前兼容，在系統(tǒng)升級(jí)時(shí)應(yīng)能有辦法回滾版本；
c. 禁用設(shè)計(jì)：應(yīng)該提供控制具體功能是否可用的配置，在系統(tǒng)出現(xiàn)故障時(shí)能夠快速下線功能；
d. 監(jiān)控設(shè)計(jì)：在設(shè)計(jì)階段就要考慮監(jiān)控的手段；
e. 多活數(shù)據(jù)中心設(shè)計(jì)：若系統(tǒng)需要極高的高可用，應(yīng)考慮在多地實(shí)施數(shù)據(jù)中心進(jìn)行多活，至少在一個(gè)機(jī)房斷電的情況下系統(tǒng)依然可用；
f. 采用成熟的技術(shù)：剛開(kāi)發(fā)的或開(kāi)源的技術(shù)往往存在很多隱藏的bug，出了問(wèn)題沒(méi)有商業(yè)支持可能會(huì)是一個(gè)災(zāi)難；
g. 資源隔離設(shè)計(jì)：應(yīng)避免單一業(yè)務(wù)占用全部資源；
h. 架構(gòu)應(yīng)能水平擴(kuò)展：系統(tǒng)只有做到能水平擴(kuò)展，才能有效避免瓶頸問(wèn)題；
i. 非核心則購(gòu)買：非核心功能若需要占用大量的研發(fā)資源才能解決，則考慮購(gòu)買成熟的產(chǎn)品；
j. 使用商用硬件：商用硬件能有效降低硬件故障的機(jī)率；
k. 快速迭代：系統(tǒng)應(yīng)該快速開(kāi)發(fā)小功能模塊，盡快上線進(jìn)行驗(yàn)證，早日發(fā)現(xiàn)問(wèn)題大大降低系統(tǒng)交付的風(fēng)險(xiǎn)；
l. 無(wú)狀態(tài)設(shè)計(jì)：服務(wù)接口應(yīng)該做成無(wú)狀態(tài)的，當(dāng)前接口的訪問(wèn)不依賴于接口上次訪問(wèn)的狀態(tài)。
附錄：更多架構(gòu)設(shè)計(jì)方面的文章
[1] 更多其它架構(gòu)設(shè)計(jì)相關(guān)文章：
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》
《達(dá)達(dá)O2O后臺(tái)架構(gòu)演進(jìn)實(shí)踐：從0到4000高并發(fā)請(qǐng)求背后的努力》
《優(yōu)秀后端架構(gòu)師必會(huì)知識(shí)：史上最全MySQL大表優(yōu)化方案總結(jié)》
《小米技術(shù)分享：解密小米搶購(gòu)系統(tǒng)千萬(wàn)高并發(fā)架構(gòu)的演進(jìn)和實(shí)踐》
《一篇讀懂分布式架構(gòu)下的負(fù)載均衡技術(shù)：分類、原理、算法、常見(jiàn)方案等》
《通俗易懂：如何設(shè)計(jì)能支撐百萬(wàn)并發(fā)的數(shù)據(jù)庫(kù)架構(gòu)？》
《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》
《從新手到架構(gòu)師，一篇就夠：從100到1000萬(wàn)高并發(fā)的架構(gòu)演進(jìn)之路》
>> 更多同類文章 ……
[2] 有關(guān)IM架構(gòu)設(shè)計(jì)的文章：
《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》
《簡(jiǎn)述移動(dòng)端IM開(kāi)發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》
《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時(shí)通訊/IM服務(wù)器開(kāi)發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》
《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》
《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫分離原理及實(shí)踐建議》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》
《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》
《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《以微博類應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》
《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》
《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》
《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》
《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實(shí)踐》
《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》
《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》
《即時(shí)通訊新手入門：一文讀懂什么是Nginx？它能否實(shí)現(xiàn)IM的負(fù)載均衡？》
《即時(shí)通訊新手入門：快速理解RPC技術(shù)——基本概念、原理和用途》
《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2665-1-1.html）