『九個月實現破億用戶的可擴展架構』學習筆記

昨晚把美拍架構負責人洪小軍在Qcon上的『九個月實現破億用戶的可擴展架構』分享看了一遍（其實那場QCon我也在現場，可是當時小軍這個會場實在太多人了，並且當時北京還沒開空調又熱又悶，因此我就挑了個涼快的會場去聽了哈哈），感受有很多值得學習的地方，在這裏記錄一下，強烈建議你們把視頻從頭至尾看一遍，不要只看ppt。尤爲是身在創業公司且公司業務發展速度比較快的同窗。

總的一箇中心思想是在不一樣階段選擇最適合本身的方案。這句話提及來簡單，可是背後的各類辛酸淚以及血的教訓只有親歷者才能理解了。下面咱們從各個角度分別來看一下。

對了，忘了說一個前提了，美拍從上線到發展到一億用戶只經歷了短短几個月的時間，在這業界應該是沒有幾個先例的，這也是前面爲何說必定要仔細看看。另外說個八卦，聽說美圖的第一個後端開發（也是惟一的一個）在剛上線時連續三天沒回家...

首先先從架構上來講，看下美拍經歷的幾個階段：

1. 極簡化設計（快速發佈上線）
2. 保持簡單行設計（產品快速迭代）
3. 可擴展和高可用保證（用戶量到必定量級）
4. 高可擴展和高可用保證

而後咱們來看下美拍一路走來遇到的問題：

1. MySQL慢查詢
2. MySQL寫入瓶頸
3. redis超時
4. memcached命中率奇低
5. 服務相互依賴
6. 監控報警不穩定
7. CDN服務各類故障
8. 添加字段成本高
9. 量級上來後，MySQL繼續慢

而後，咱們按服務維度把每個服務拆開，看下每個服務在美拍架構上的迭代過程。

1、MySQL

MySQL是最重要的一個服務，在美拍架構裏經歷了屢次迭代。在初版直接就是一個實例，爲了保持代碼的簡單，業務邏輯能在數據庫裏作的都放到數據庫作了，好比Feed功能，直接用MySQL的join查詢。

可是後來就出現了一些慢查詢的狀況，這時候作了主從，作讀寫分離，多個從庫用來作查詢。再到後來出現寫入也慢的狀況，這時候也沒有作架構上的優化，而是升級硬件，由於如今正是業務高速發展階段，須要極簡化設計，這個階段更多精力要放在業務開發上（估計當時也木有招到合適的人:)）。

過了一段時間又開始出現寫入慢的狀況，這時候纔開始作分表。可是等到了重心放在擴展性和可用性上時，又遇到了新的問題，一個很大的問題仍是寫入慢，另一個就是隨着數據量的增大，添加字段成本特別的高。針對這兩個問題作了下面兩個方案：

1. 異步寫入，作到前端永遠可寫，後面複雜的事情放到隊列裏面去異步的作
2. 索引和數據分離，把須要索引的字段單獨拆出來一個表，其餘數據用kv存儲，value就是全部屬性和值的pb二進制數據，解決家字段困難的問題

這個時候針對MySQL的架構優化才告了一段落 :)

2、緩存

緩存主要用到了memcache和redis（redis應該主要是用在隊列和計數服務）。在量比較小的時候就是簡單粗暴的用，可是很快就遇到了redis超時的問題，這時候對redis擴容，使用多slave架構。而後是rdb dump時影響用戶請求的問題，解決方法一是在凌晨訪問量低的時候纔去dump，二是用不對外服務的機器來作dump。

而後memcached遇到了命中率很低的問題，一個大問題就是容量瓶頸，這沒啥好說的，擴容（小軍有提到，要隨時作好擴容的準備）。另一個就是slab calcification的問題（又叫slab鈣化問題，這個是memcached的內存分配機制致使的，簡單來講就是memcached會內存分紅N個slab，當新添加一個內存對象時會根據這個對象的大小來選擇不一樣的slab，若是沒有合適的就會建立一個slab，那若是這時候剩餘內存不足以分配一個slab呢？這時候就出現了鈣化問題了），美拍當時的解決辦法是核心業務隔離部署，避開這個問題。

到可用性保證階段，緩存的可用性就更加的很是的重要了，緩存掛了可能就整個系統都掛了，很難收場，因此就要保證緩存的可用性。這時候作了主從的優化，master也承擔讀查詢，以保證緩存熱度，slave穿透到master，master穿透到slave，防止單點故障。

3、運維

在初期只是簡單的監控告警，有時候出問題了可能收不到告警或者看不到是啥地方出問題，後來逐漸完善監控告警，且監控告警是用配置比較高的服務器，保證監控告警的可用性。而後假如更多監控維度和更多日誌，方便定位問題。對依賴的第三方服務和資源作開關，出問題時能夠經過服務的開關保證核心路徑可用。

4、第三方服務

主要提到的是CDN服務。其中一個很大的問題就是DNS被攻擊、被劫持，除了和運營商保持溝通外，還作了多服務商配合的策略，好比一樣的數據在多個雲服務那裏作冗餘，客戶端在訪問時若是出現問題就切換到其餘的訪問地址，而且在客戶端作了服務端可用性探測。這也是個很是有價值的經驗。

5、技術棧

整個看下來會發現美拍的架構作的很是的穩，小軍也有提到，在項目初期高速發展階段作架構時要克服對完美架構的慾望、克服對新技術的慾望，先讓系統跑起來。

可是在整個迭代過程當中，美拍也一直在引入新技術，好比在團隊不太熟悉時先在部分業務上使用MongoDB，在注重可擴展和可用性階段，引入java作業務邏輯，引入c作底層基礎服務。

---

經過這個分享能夠學習到一個系統從0到億的架構迭代過程，可是更多的仍是在於實踐，估計美拍走過的坑也遠不止小軍分享裏提到的這些，每個點均可能出現N多的問題，每一個點均可以展開不少話題來說。但願能看到更多相似的有價值的分享！