阿里巴巴為什么能抗住90秒100億批什?詳細(xì)解析

作者:huashiou

鏈接:https://segmentfault.com/a/1190000018626163

1、概述

本文以淘寶作為例子却汉,介紹從一百個(gè)并發(fā)到千萬(wàn)級(jí)并發(fā)情況下服務(wù)端的架構(gòu)的演進(jìn)過(guò)程,同時(shí)列舉出每個(gè)演進(jìn)階段會(huì)遇到的相關(guān)技術(shù)翩伪,讓大家對(duì)架構(gòu)的演進(jìn)有一個(gè)整體的認(rèn)知,文章最后匯總了一些架構(gòu)設(shè)計(jì)的原則谈息。

2缘屹、基本概念

在介紹架構(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ò)程。

3例诀、架構(gòu)演進(jìn)

3.1 單機(jī)架構(gòu)

image

以淘寶作為例子:在網(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ù)步势。

3.2第一次演進(jìn):Tomcat與數(shù)據(jù)庫(kù)分開(kāi)部署

image

Tomcat和數(shù)據(jù)庫(kù)分別獨(dú)占服務(wù)器資源氧猬,顯著提高兩者各自性能。

架構(gòu)瓶頸:隨著用戶數(shù)的增長(zhǎng)坏瘩,并發(fā)讀寫數(shù)據(jù)庫(kù)成為瓶頸盅抚。

Tips:歡迎關(guān)注微信公眾號(hào):Java后端,獲取更多技術(shù)博文推送倔矾。

3.3 第二次演進(jìn):引入本地緩存和分布式緩存

image

在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)逐漸變慢悲没。

3.4 第三次演進(jìn):引入反向代理實(shí)現(xiàn)負(fù)載均衡

image

在多臺(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ù)最終成為瓶頸脐恩。

3.5 第四次演進(jìn):數(shù)據(jù)庫(kù)讀寫分離

image

把數(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ù),相互影響性能澈魄。

3.6 第五次演進(jìn):數(shù)據(jù)庫(kù)按業(yè)務(wù)分庫(kù)

image

把不同業(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á)到性能瓶頸包晰。

3.7 第六次演進(jìn):把大表拆分為小表

image

比如針對(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ì)成為瓶頸驻啤。

3.8 第七次演進(jìn):使用LVS或F5來(lái)使多個(gè)Nginx負(fù)載均衡

image

由于瓶頸在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ì)明顯不同。

3.9 第八次演進(jìn):通過(guò)DNS輪詢實(shí)現(xiàn)機(jī)房間的負(fù)載均衡

image

在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ú)法解決如此豐富的需求私痹。

3.10 第九次演進(jìn):引入NoSQL數(shù)據(jù)庫(kù)和搜索引擎等技術(shù)

image

當(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í)迭代變得困難。

3.11 第十次演進(jìn):大應(yīng)用拆分為小應(yīng)用

image

按照業(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í)掖棉。

3.12 第十一次演進(jìn):復(fù)用的功能抽離成微服務(wù)

image

如用戶管理、訂單膀估、支付幔亥、鑒權(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ù)雜巴比,邏輯變得混亂术奖。

3.13 第十二次演進(jìn):引入企業(yè)服務(wù)總線ESB屏蔽服務(wù)接口的訪問(wèn)差異

image

通過(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)維將變得十分困難屑那。

3.14 第十三次演進(jìn):引入容器化技術(shù)實(shí)現(xiàn)運(yùn)行環(huán)境隔離與動(dòng)態(tài)服務(wù)管理

image

目前最流行的容器化技術(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)維成本都極高剧罩,資源利用率低。

3.15 第十四次演進(jìn):以云平臺(tái)承載系統(tǒng)

image

系統(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è)資源整體

在云平臺(tái)上可按需動(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è)概念:

IaaS:基礎(chǔ)設(shè)施即服務(wù)膜赃。對(duì)應(yīng)于上面所說(shuō)的機(jī)器資源統(tǒng)一為資源整體挺邀,可動(dòng)態(tài)申請(qǐng)硬件資源的層面;

PaaS:平臺(tái)即服務(wù)跳座。對(duì)應(yīng)于上面所說(shuō)的提供常用的技術(shù)組件方便系統(tǒng)的開(kāi)發(fā)和維護(hù)端铛;

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ú)討論。

4蛋哭、架構(gòu)設(shè)計(jì)總結(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ì)的原則?

N+1設(shè)計(jì):系統(tǒng)中的每個(gè)組件都應(yīng)做到?jīng)]有單點(diǎn)故障毁葱;

回滾設(shè)計(jì):確保系統(tǒng)可以向前兼容垫言,在系統(tǒng)升級(jí)時(shí)應(yīng)能有辦法回滾版本;

禁用設(shè)計(jì):應(yīng)該提供控制具體功能是否可用的配置倾剿,在系統(tǒng)出現(xiàn)故障時(shí)能夠快速下線功能筷频;

監(jiān)控設(shè)計(jì):在設(shè)計(jì)階段就要考慮監(jiān)控的手段;

多活數(shù)據(jù)中心設(shè)計(jì):若系統(tǒng)需要極高的高可用前痘,應(yīng)考慮在多地實(shí)施數(shù)據(jù)中心進(jìn)行多活凛捏,至少在一個(gè)機(jī)房斷電的情況下系統(tǒng)依然可用;

采用成熟的技術(shù):剛開(kāi)發(fā)的或開(kāi)源的技術(shù)往往存在很多隱藏的bug芹缔,出了問(wèn)題沒(méi)有商業(yè)支持可能會(huì)是一個(gè)災(zāi)難坯癣;

資源隔離設(shè)計(jì):應(yīng)避免單一業(yè)務(wù)占用全部資源;

架構(gòu)應(yīng)能水平擴(kuò)展:系統(tǒng)只有做到能水平擴(kuò)展最欠,才能有效避免瓶頸問(wèn)題示罗;

非核心則購(gòu)買:非核心功能若需要占用大量的研發(fā)資源才能解決惩猫,則考慮購(gòu)買成熟的產(chǎn)品;

使用商用硬件:商用硬件能有效降低硬件故障的機(jī)率蚜点;

快速迭代:系統(tǒng)應(yīng)該快速開(kāi)發(fā)小功能模塊轧房,盡快上線進(jìn)行驗(yàn)證,早日發(fā)現(xiàn)問(wèn)題大大降低系統(tǒng)交付的風(fēng)險(xiǎn)绍绘;

無(wú)狀態(tài)設(shè)計(jì):服務(wù)接口應(yīng)該做成無(wú)狀態(tài)的奶镶,當(dāng)前接口的訪問(wèn)不依賴于接口上次訪問(wèn)的狀態(tài)。

作者:夜空_2cd3

鏈接:http://www.reibang.com/p/f4a907fe1485

來(lái)源:簡(jiǎn)書

著作權(quán)歸作者所有陪拘。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)厂镇,非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末藻丢,一起剝皮案震驚了整個(gè)濱河市剪撬,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌悠反,老刑警劉巖残黑,帶你破解...
    沈念sama閱讀 211,042評(píng)論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異斋否,居然都是意外死亡梨水,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,996評(píng)論 2 384
  • 文/潘曉璐 我一進(jìn)店門茵臭,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)疫诽,“玉大人,你說(shuō)我怎么就攤上這事旦委∑嫱剑” “怎么了?”我有些...
    開(kāi)封第一講書人閱讀 156,674評(píng)論 0 345
  • 文/不壞的土叔 我叫張陵缨硝,是天一觀的道長(zhǎng)摩钙。 經(jīng)常有香客問(wèn)我,道長(zhǎng)查辩,這世上最難降的妖魔是什么胖笛? 我笑而不...
    開(kāi)封第一講書人閱讀 56,340評(píng)論 1 283
  • 正文 為了忘掉前任,我火速辦了婚禮宜岛,結(jié)果婚禮上长踊,老公的妹妹穿的比我還像新娘。我一直安慰自己萍倡,他們只是感情好身弊,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,404評(píng)論 5 384
  • 文/花漫 我一把揭開(kāi)白布。 她就那樣靜靜地躺著,像睡著了一般佑刷。 火紅的嫁衣襯著肌膚如雪莉擒。 梳的紋絲不亂的頭發(fā)上,一...
    開(kāi)封第一講書人閱讀 49,749評(píng)論 1 289
  • 那天瘫絮,我揣著相機(jī)與錄音涨冀,去河邊找鬼。 笑死麦萤,一個(gè)胖子當(dāng)著我的面吹牛鹿鳖,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播壮莹,決...
    沈念sama閱讀 38,902評(píng)論 3 405
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼翅帜,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了命满?” 一聲冷哼從身側(cè)響起涝滴,我...
    開(kāi)封第一講書人閱讀 37,662評(píng)論 0 266
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎胶台,沒(méi)想到半個(gè)月后歼疮,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 44,110評(píng)論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡诈唬,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,451評(píng)論 2 325
  • 正文 我和宋清朗相戀三年韩脏,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片铸磅。...
    茶點(diǎn)故事閱讀 38,577評(píng)論 1 340
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡赡矢,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出阅仔,到底是詐尸還是另有隱情吹散,我是刑警寧澤,帶...
    沈念sama閱讀 34,258評(píng)論 4 328
  • 正文 年R本政府宣布八酒,位于F島的核電站送浊,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏丘跌。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,848評(píng)論 3 312
  • 文/蒙蒙 一唁桩、第九天 我趴在偏房一處隱蔽的房頂上張望车吹。 院中可真熱鬧磺平,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書人閱讀 30,726評(píng)論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至,卻和暖如春幅疼,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背昼接。 一陣腳步聲響...
    開(kāi)封第一講書人閱讀 31,952評(píng)論 1 264
  • 我被黑心中介騙來(lái)泰國(guó)打工爽篷, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人慢睡。 一個(gè)月前我還...
    沈念sama閱讀 46,271評(píng)論 2 360
  • 正文 我出身青樓逐工,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親漂辐。 傳聞我的和親對(duì)象是個(gè)殘疾皇子泪喊,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,452評(píng)論 2 348

推薦閱讀更多精彩內(nèi)容