摘要：五技術(shù)棧整個(gè)看下來會(huì)發(fā)現(xiàn)美拍的架構(gòu)做的非常的穩(wěn)，小軍也有提到，在項(xiàng)目初期高速發(fā)展階段做架構(gòu)時(shí)要克服對完美架構(gòu)的欲望克服對新技術(shù)的欲望，先讓系統(tǒng)跑起來。

昨晚把美拍架構(gòu)負(fù)責(zé)人洪小軍在Qcon上的『九個(gè)月實(shí)現(xiàn)破億用戶的可擴(kuò)展架構(gòu)』分享看了一遍（其實(shí)那場QCon我也在現(xiàn)場，但是當(dāng)時(shí)小軍這個(gè)會(huì)場實(shí)在太多人了，而且當(dāng)時(shí)北京還沒開空調(diào)又熱又悶，所以我就挑了個(gè)涼快的會(huì)場去聽了哈哈），感覺有不少值得學(xué)習(xí)的地方，在這里記錄一下，強(qiáng)烈建議大家把視頻從頭到尾看一遍，不要只看ppt。尤其是身在創(chuàng)業(yè)公司且公司業(yè)務(wù)發(fā)展速度比較快的同學(xué)。

總的一個(gè)中心思想是在不同階段選擇最適合自己的方案。這句話說起來簡單，但是背后的各種辛酸淚以及血的教訓(xùn)只有親歷者才能理解了。下面我們從各個(gè)角度分別來看一下。

對了，忘了說一個(gè)前提了，美拍從上線到發(fā)展到一億用戶只經(jīng)歷了短短幾個(gè)月的時(shí)間，在這業(yè)界應(yīng)該是沒有幾個(gè)先例的，這也是前面為什么說一定要仔細(xì)看看。另外說個(gè)八卦，據(jù)說美圖的第一個(gè)后端開發(fā)（也是唯一的一個(gè)）在剛上線時(shí)連續(xù)三天沒回家...

首先先從架構(gòu)上來說，看下美拍經(jīng)歷的幾個(gè)階段：

極簡化設(shè)計(jì)（快速發(fā)布上線）

保持簡單行設(shè)計(jì)（產(chǎn)品快速迭代）

可擴(kuò)展和高可用保證（用戶量到一定量級(jí)）

高可擴(kuò)展和高可用保證

然后我們來看下美拍一路走來遇到的問題：

MySQL慢查詢

MySQL寫入瓶頸

redis超時(shí)

memcached命中率奇低

服務(wù)相互依賴

監(jiān)控報(bào)警不穩(wěn)定

CDN服務(wù)各種故障

添加字段成本高

量級(jí)上來后，MySQL繼續(xù)慢

然后，我們按服務(wù)維度把每一個(gè)服務(wù)拆開，看下每一個(gè)服務(wù)在美拍架構(gòu)上的迭代過程。

MySQL是最重要的一個(gè)服務(wù)，在美拍架構(gòu)里經(jīng)歷了多次迭代。在第一版直接就是一個(gè)實(shí)例，為了保持代碼的簡單，業(yè)務(wù)邏輯能在數(shù)據(jù)庫里做的都放到數(shù)據(jù)庫做了，比如Feed功能，直接用MySQL的join查詢。

但是后來就出現(xiàn)了一些慢查詢的情況，這時(shí)候做了主從，做讀寫分離，多個(gè)從庫用來做查詢。再到后來出現(xiàn)寫入也慢的情況，這時(shí)候也沒有做架構(gòu)上的優(yōu)化，而是升級(jí)硬件，因?yàn)楝F(xiàn)在正是業(yè)務(wù)高速發(fā)展階段，需要極簡化設(shè)計(jì)，這個(gè)階段更多精力要放在業(yè)務(wù)開發(fā)上（估計(jì)當(dāng)時(shí)也木有招到合適的人:)）。

過了一段時(shí)間又開始出現(xiàn)寫入慢的情況，這時(shí)候才開始做分表。但是等到了重心放在擴(kuò)展性和可用性上時(shí)，又遇到了新的問題，一個(gè)很大的問題還是寫入慢，另外一個(gè)就是隨著數(shù)據(jù)量的增大，添加字段成本特別的高。針對這兩個(gè)問題做了下面兩個(gè)方案：

異步寫入，做到前端永遠(yuǎn)可寫，后面復(fù)雜的事情放到隊(duì)列里面去異步的做

索引和數(shù)據(jù)分離，把需要索引的字段多帶帶拆出來一個(gè)表，其他數(shù)據(jù)用kv存儲(chǔ)，value就是所有屬性和值的pb二進(jìn)制數(shù)據(jù)，解決家字段困難的問題

這個(gè)時(shí)候針對MySQL的架構(gòu)優(yōu)化才告了一段落 :)

緩存主要用到了memcache和redis（redis應(yīng)該主要是用在隊(duì)列和計(jì)數(shù)服務(wù)）。在量比較小的時(shí)候就是簡單粗暴的用，但是很快就遇到了redis超時(shí)的問題，這時(shí)候?qū)edis擴(kuò)容，使用多slave架構(gòu)。然后是rdb dump時(shí)影響用戶請求的問題，解決方法一是在凌晨訪問量低的時(shí)候才去dump，二是用不對外服務(wù)的機(jī)器來做dump。

然后memcached遇到了命中率很低的問題，一個(gè)大問題就是容量瓶頸，這沒啥好說的，擴(kuò)容（小軍有提到，要隨時(shí)做好擴(kuò)容的準(zhǔn)備）。另外一個(gè)就是slab calcification的問題（又叫slab鈣化問題，這個(gè)是memcached的內(nèi)存分配機(jī)制導(dǎo)致的，簡單來說就是memcached會(huì)內(nèi)存分成N個(gè)slab，當(dāng)新添加一個(gè)內(nèi)存對象時(shí)會(huì)根據(jù)這個(gè)對象的大小來選擇不同的slab，如果沒有合適的就會(huì)創(chuàng)建一個(gè)slab，那如果這時(shí)候剩余內(nèi)存不足以分配一個(gè)slab呢？這時(shí)候就出現(xiàn)了鈣化問題了），美拍當(dāng)時(shí)的解決辦法是核心業(yè)務(wù)隔離部署，避開這個(gè)問題。

到可用性保證階段，緩存的可用性就更加的非常的重要了，緩存掛了可能就整個(gè)系統(tǒng)都掛了，很難收場，所以就要保證緩存的可用性。這時(shí)候做了主從的優(yōu)化，master也承擔(dān)讀查詢，以保證緩存熱度，slave穿透到master，master穿透到slave，防止單點(diǎn)故障。

在初期只是簡單的監(jiān)控告警，有時(shí)候出問題了可能收不到告警或者看不到是啥地方出問題，后來逐漸完善監(jiān)控告警，且監(jiān)控告警是用配置比較高的服務(wù)器，保證監(jiān)控告警的可用性。然后假如更多監(jiān)控維度和更多日志，方便定位問題。對依賴的第三方服務(wù)和資源做開關(guān)，出問題時(shí)可以通過服務(wù)的開關(guān)保證核心路徑可用。

主要提到的是CDN服務(wù)。其中一個(gè)很大的問題就是DNS被攻擊、被劫持，除了和運(yùn)營商保持溝通外，還做了多服務(wù)商配合的策略，比如同樣的數(shù)據(jù)在多個(gè)云服務(wù)那里做冗余，客戶端在訪問時(shí)如果出現(xiàn)問題就切換到其他的訪問地址，并且在客戶端做了服務(wù)端可用性探測。這也是個(gè)非常有價(jià)值的經(jīng)驗(yàn)。

整個(gè)看下來會(huì)發(fā)現(xiàn)美拍的架構(gòu)做的非常的穩(wěn)，小軍也有提到，在項(xiàng)目初期高速發(fā)展階段做架構(gòu)時(shí)要克服對完美架構(gòu)的欲望、克服對新技術(shù)的欲望，先讓系統(tǒng)跑起來。

但是在整個(gè)迭代過程中，美拍也一直在引入新技術(shù)，比如在團(tuán)隊(duì)不太熟悉時(shí)先在部分業(yè)務(wù)上使用MongoDB，在注重可擴(kuò)展和可用性階段，引入java做業(yè)務(wù)邏輯，引入c做底層基礎(chǔ)服務(wù)。

通過這個(gè)分享可以學(xué)習(xí)到一個(gè)系統(tǒng)從0到億的架構(gòu)迭代過程，但是更多的還是在于實(shí)踐，估計(jì)美拍走過的坑也遠(yuǎn)不止小軍分享里提到的這些，每一個(gè)點(diǎn)都可能出現(xiàn)N多的問題，每個(gè)點(diǎn)都可以展開很多話題來講。希望能看到更多類似的有價(jià)值的分享！