資訊專欄INFORMATION COLUMN
摘要：五技術棧整個看下來會發現美拍的架構做的非常的穩，小軍也有提到，在項目初期高速發展階段做架構時要克服對完美架構的欲望克服對新技術的欲望，先讓系統跑起來。
昨晚把美拍架構負責人洪小軍在Qcon上的『九個月實現破億用戶的可擴展架構』分享看了一遍（其實那場QCon我也在現場，但是當時小軍這個會場實在太多人了，而且當時北京還沒開空調又熱又悶，所以我就挑了個涼快的會場去聽了哈哈），感覺有不少值得學習的地方，在這里記錄一下，強烈建議大家把視頻從頭到尾看一遍，不要只看ppt。尤其是身在創業公司且公司業務發展速度比較快的同學。
總的一個中心思想是在不同階段選擇最適合自己的方案。這句話說起來簡單，但是背后的各種辛酸淚以及血的教訓只有親歷者才能理解了。下面我們從各個角度分別來看一下。
對了，忘了說一個前提了，美拍從上線到發展到一億用戶只經歷了短短幾個月的時間，在這業界應該是沒有幾個先例的，這也是前面為什么說一定要仔細看看。另外說個八卦，據說美圖的第一個后端開發（也是唯一的一個）在剛上線時連續三天沒回家...
首先先從架構上來說，看下美拍經歷的幾個階段：
極簡化設計（快速發布上線）
保持簡單行設計（產品快速迭代）
可擴展和高可用保證（用戶量到一定量級）
高可擴展和高可用保證
然后我們來看下美拍一路走來遇到的問題：
MySQL慢查詢
MySQL寫入瓶頸
redis超時
memcached命中率奇低
服務相互依賴
監控報警不穩定
CDN服務各種故障
添加字段成本高
量級上來后，MySQL繼續慢
然后，我們按服務維度把每一個服務拆開，看下每一個服務在美拍架構上的迭代過程。
一、MySQLMySQL是最重要的一個服務，在美拍架構里經歷了多次迭代。在第一版直接就是一個實例，為了保持代碼的簡單，業務邏輯能在數據庫里做的都放到數據庫做了，比如Feed功能，直接用MySQL的join查詢。
但是后來就出現了一些慢查詢的情況，這時候做了主從，做讀寫分離，多個從庫用來做查詢。再到后來出現寫入也慢的情況，這時候也沒有做架構上的優化，而是升級硬件，因為現在正是業務高速發展階段，需要極簡化設計，這個階段更多精力要放在業務開發上（估計當時也木有招到合適的人:)）。
過了一段時間又開始出現寫入慢的情況，這時候才開始做分表。但是等到了重心放在擴展性和可用性上時，又遇到了新的問題，一個很大的問題還是寫入慢，另外一個就是隨著數據量的增大，添加字段成本特別的高。針對這兩個問題做了下面兩個方案：
異步寫入，做到前端永遠可寫，后面復雜的事情放到隊列里面去異步的做
索引和數據分離，把需要索引的字段多帶帶拆出來一個表，其他數據用kv存儲，value就是所有屬性和值的pb二進制數據，解決家字段困難的問題
這個時候針對MySQL的架構優化才告了一段落 :)
二、緩存緩存主要用到了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，防止單點故障。
三、運維在初期只是簡單的監控告警，有時候出問題了可能收不到告警或者看不到是啥地方出問題，后來逐漸完善監控告警，且監控告警是用配置比較高的服務器，保證監控告警的可用性。然后假如更多監控維度和更多日志，方便定位問題。對依賴的第三方服務和資源做開關，出問題時可以通過服務的開關保證核心路徑可用。
四、第三方服務主要提到的是CDN服務。其中一個很大的問題就是DNS被攻擊、被劫持，除了和運營商保持溝通外，還做了多服務商配合的策略，比如同樣的數據在多個云服務那里做冗余，客戶端在訪問時如果出現問題就切換到其他的訪問地址，并且在客戶端做了服務端可用性探測。這也是個非常有價值的經驗。
五、技術棧整個看下來會發現美拍的架構做的非常的穩，小軍也有提到，在項目初期高速發展階段做架構時要克服對完美架構的欲望、克服對新技術的欲望，先讓系統跑起來。
但是在整個迭代過程中，美拍也一直在引入新技術，比如在團隊不太熟悉時先在部分業務上使用MongoDB，在注重可擴展和可用性階段，引入java做業務邏輯，引入c做底層基礎服務。
通過這個分享可以學習到一個系統從0到億的架構迭代過程，但是更多的還是在于實踐，估計美拍走過的坑也遠不止小軍分享里提到的這些，每一個點都可能出現N多的問題，每個點都可以展開很多話題來講。希望能看到更多類似的有價值的分享！
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/11698.html
摘要：上備受期待的終于可以使用。根據公司的統計，三年合約的每臺主機費用為美元，與按需小時計費率相比，節省了約的成本。根據公司的說法，如果一家公司與其簽訂三年的合約，在上的總體擁有成本估計高達每個虛擬機每小時美元。 經過9個月的測試，并帶著許多懸而未決的問題，AWS上的VMware Cloud終于可用，組織現在可以判斷該服務是否符合他們的需求。?AWS上備受期待的VMware Cloud終于可以使用...
摘要：上備受期待的終于可以使用。根據公司的統計，三年合約的每臺主機費用為美元，與按需小時計費率相比，節省了約的成本。根據公司的說法，如果一家公司與其簽訂三年的合約，在上的總體擁有成本估計高達每個虛擬機每小時美元。 經過9個月的測試，并帶著許多懸而未決的問題，AWS上的VMware Cloud終于可用，組織現在可以判...
閱讀 2029·2023-04-25 22:50
閱讀 2842·2021-09-29 09:35
閱讀 3395·2021-07-29 10:20
閱讀 3168·2019-08-29 13:57
閱讀 3366·2019-08-29 13:50
閱讀 3041·2019-08-26 12:10
閱讀 3536·2019-08-23 18:41
閱讀 2642·2019-08-23 18:01
