原文地址：http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=410775314&idx=1&sn=7c7cc94f8f42c6df81b721919593f1c2&scene=4#wechat_redirect

Nice 本身是一款照片分享社區類型的應用，在分享照片和生活態度的同時可以在照片上貼上如品牌、地點、興趣等tag。

Nice從2013.10月份上線App Store到目前每天2億PV，服務端架構經過了4次比較大的調整（2014年年底數據）。本次分享將介紹四次架構調整的背景、實踐和結果，并討論如何在人員不足的情況下平衡業務與架構，什么樣的架構和開發模式更適合創業團隊“天下武功，唯快不破”的做事方式。

本文根據Nice技術合伙人程?在ArchSummit全球架構師峰會上的演講整理而成，點擊閱讀原文鏈接，查看演講視頻。

我主要是給大家帶來一個Nice服務器端從第一天到現在為止的整個架構的變遷的演進的圖，我相信大家在這個演進的過程當中，如果大家有自己去Run一個Startup或者加入一個Startup的時候，你可以以我們的經驗為借鑒，看一下我們從頭開始是怎么做到一個現在這樣的狀態的。

我可以先給大家稍微的透露一下我們現在的整個服務器端的一些基本的數據的情況，現在大概是每天五億的API的請求，不包括圖片的CDN的緩存，一共是大概有六千萬張照片，每天新增的照片量大概在55萬，每周絕大部分的數據是增長6%左右。

Nice這一產品實際上是在2013年的10月份正式上線AppStore的，剛開始的時候只有iOS的版本，當然我們是從9月份的時候，正式的開始去做這個產品。那么在做這個產品的準備上線的時候，我們的第一臺服務器是這樣的。這臺服務器的配置其實非常的低，它的內存只有2G，現在被扔在我們辦公室的一個角落當中，連開發機都不愿意使它。因為配置實在太低了。

但就是那樣一臺服務器，在Nice的初期大概撐了兩三個月左右的時間，我們才替換到別的上面。所以在非常初期的時候，其實既沒有用戶量，也沒有用戶關系，也沒有UGC的數據，一臺非常普通的戴爾的服務器，就支撐了Nice所有服務器端的功能。那么現在是什么樣子的呢？

2014年的10月份，首先我們自己的服務器已經全部鳥槍換炮了，當然也不是特別高端的服務器，是性價比非常高的一款。而且放到了北京這邊一家非常不錯的IDC當中。熟悉運維的同學可能知道，這個東西叫PCIe的閃存卡，是一種比SSD還要快的內存的存儲的硬件設備，大概6到7萬塊錢一塊。因為現在不缺錢了，所以基本上在DB上面都用這種東西了。

第一次調整架構

那么第一次我們調整服務器架構是在什么時候？時間是在2013年的11月份的下旬。因為隨著流量的增長，一臺機器根本不可能支撐所有的業務。從現在來看是一個比較明智的決定，我們從自己托管的服務器遷移到了云上。我們從自己處理圖片訪問，到使用圖片云存儲，這兩個事情做完了之后，基本上把我們的服務器端的人力解放出來，可以把絕大部分的人力投入到業務系統的開發當中，并且能減少非常多的運維的工作。

第一次演進的時候服務器架構調整是這樣，我們在青云上面開了五臺虛擬主機，第一臺虛擬主機是做Nginx代理，同時提供Web業務的服務；還有另外兩臺虛擬主機，基本上囊括了除了DB、Slave以外的其他的所有的功能，包括做Web業務的處理，做DB的主庫，做圖片的存儲，做Mis系統的后臺，還有一臺就做一些日常的統計的Job，最后再加上兩臺DB的Master。

其實非常非常的簡單，就是從第一臺單機拆成了五臺機器，當時的數據量幾十萬PV每天，幾千張照片一天。調整的原則是，在虛擬主機上的功能能合順就合順。因為當時好像還不是很有錢，所以還是比較省的。配置最高的虛擬主機是4核16G，但是基本上經過了這一次調整之后，我們的服務器端暫時算是比較的穩定了，這樣我們就可以把大部分的人力投入到業務的開發當中。

這個還有一個前提條件，我們在初期的時候，包括到現在為止，工程師一直都是非常少的。就是這些事情，其實都是兩個工程師做得。我們服務器端工程師在很長的一段時間之內只有兩個。

第二次調整架構

那么這個第一次演進完了之后，我們做了一些功能上的開發和優化，流量又繼續在漲，很快這個第一次演進的部署方案就搞不定了，大概的時間是在2014年的3月份就出問題了。

當時出的問題是主庫的機器壓力過大，這也非常的顯而易見。因為主庫上面部署了太多的東西，而主庫又非常吃IO和CPU。于是當時在現有的這個云平臺上面，做了一次架構的升級。第一是機器按照功能進行拆分，先把主庫給拆出來；第二個就是做一些基本的冗載和備份的工作。經過第二次演進之后，我們的整個的服務器端的架構是這樣的。

首先我們在前面沒有只用Nginx做反向代理了，我們引入了一個叫Node Blance，其實是青云自己內部提供的一個HA proxy，核心是這個。接下來，會下發到兩臺機器proxy上，這就是Nginx去做proxy。

然后我們把圖片存儲的機器和Mis的機器放在了一臺機器上。而把這上面最重的DB master給拆出來。同時我們引入了一個第三方的MySQL proxy，這是360開源的一個MySQL proxy，用它做整個DB這一塊的一個代理。

FA的機器，就是前端的機器是兩臺。因為隨著這個業務的發展，也需要引入一些新的東西，在這個時候，我們第一次真真正正的引入了緩存。我們緩存其實直接使用的是Redis。同時我們有一些異步的任務，我們引入了消息隊列，我們的消息隊列用的是Beanstalk，這兩個模塊分別部署在兩臺單獨的VM的機器上。

經過這樣一拆的話，首先第一是把主庫的壓力減輕了，因為主庫我們可以配最高配置的機器；其次因為有了緩存，所以我們所有的大部分的壓力比較大的訪問請求或者比較頻繁的訪問請求，我們可以使用緩存去頂。第三因為引入了消息隊列，我們的異步的任務，其實是可以通過消息隊列去分發的。當時的狀態，大概是上千萬的請求，一天；上萬張的照片，一天，主庫拆到單獨的機器，引入了三個新的模塊，最后使用了MySQL的proxy做圖片分離。

這是在2014年的3月份。很快，因為這個社交產品我們在整個2014年的發展還算比較順利，所以所有的東西其實都一直在漲，直到這個時候，我們的整個的服務器端的工程師依然是兩個。

第三次調整架構

在2014年7月份的時候，又出現了新的問題，這個問題就比較麻煩，就是在青云當時北京的機房，當時他們可能規劃的也沒有想的特別的清楚，所以對資源的配額上線做的比較小，所以我們整個的單虛擬機的可以分配的資源到了上限，8核32G，我想再分更多的內存和更多的CPU，是已經不支持了；第二個問題是單機房很快也要到達資源的上線了。

因為整個北京機房的整個的資源池當中已經開始報警了，沒有太多的可用的空閑的資源。這種情況之下，我們就做了一個現在看起來是非常非常有問題的一個決定，我們決定做雙機房。我們再想，既然青云北京機房，一個機房已經搞不定了，那我們再使用青云第二個機房，他們當時正好上了廣東機房，也一直在Push我們去使用廣東機房。

我們做出了一個草率的決定，用雙機房。然后加上容災和備份。雙機房的部署就變得非常的復雜，這個圖是我當時做雙機房的遷移的時候畫的一個架構圖，現在看起來實在是亂的已經不能看了。

基本上是除了主庫放在北京機房以外，其他的所有的東西在第二個機房，原樣不動的去搭建一套一模一樣的。然后通過DNS的分流，去把流量根據地域分到不同的機房，北京和廣東的機房。當然因為那個時候我們發現國外的流量也逐漸起來了，接近10%的國外用戶，所以我們在AWS那邊也做了一套方案。

這個雙機房的方案做上去了以后，又發生了一件很討厭的事情，就是你天天都在處理線上問題，你沒有一天能夠清靜。這個的時間是在2014年的7月份，這個時候我們有兩名服務器端的工程師，加上一名運維工程師。

第四次調整架構

在部署雙機房后，我們碰到了太多的問題，讓我們大概兩個月的時間之內，就沒有一天能夠在10點以前回家，因為一直有問題。所以我們在2014年的9月份的時候，做了第四次的演進。第四次演進的發現的問題，也就是之前我說的雙機房的問題。第一個問題是MySQL的Nginx大小超過32G。這個問題基本上就無解了，除非你分庫。因為你青云給你的資源的上限是內存32G，然后你發現MySQL的索引已經超過了32G，然后慢查詢就爆增。

第二個問題也就是雙機房最大的一個問題，互聯是不穩定的，經常會出現數據不一致的情況。因為當時青云的雙機房，其實走的是公網，公網的延遲是非常非常不穩定的，在正常的情況下，它也許是能夠在三四十毫秒。但是經常會飆升到幾千毫秒。

第三個原因，就是天天加班處理線上問題，不能回家陪老婆。于是大概是2014年在9月初吧，9月幾號的時候，有一次，我和我們兩個服務器端工程師和一個運維工程師，晚上處理完問題在那吃飯，大家一邊吃飯，一邊罵娘。

最后就說了一句『cao，我們還是自己干吧』。于是我們做出了，現在看起來還比較正確的一個決定，我們從青云遷移回來了，到我們自己的托管服務器，從雙機房回歸到單機房。

經過第四次的演進，我們的架構圖就變得清晰了很多。首先我們在2014年9月份的時候，第一批大概是采購了33、34臺物理機，然后做了這樣的一些部署，所有的機器都是物理機，前端是兩個HA proxy，然后用Keep alive去做護備。然后這兩個proxy的下面會連著兩個Nginx做方向代理，做請求的分。然后所有的靜態資源和以及圖片全部會由Varnish去做緩存。然后我們的圖片機群用的其實是豆瓣開源出來的一套圖片和小圖片的存儲系統，最下層是四臺Beansdb的cluster，上層使用的是Beanseye去做Proxy。

由于我們還使用了七牛的鏡像存儲，所以基本上我們圖片活躍的壓力是一次，也就是所有的圖片只活躍一次，所以通過這樣的一套架構，解決了圖片存儲和備份的一個問題。靜態資源就不用說了，直接往Varnish里面扔。然后兩臺Nginx下面是有八臺的前端機，我們的前端是用TM，所以是八臺的TM前端機器。然后前端機器下面是四個比較大的模塊，第一個是我們的NoSQL模塊，其實都不能叫它緩存了。

因為Redis現在在整個Nice當中的作用已經不止是緩存了，基本上不能掛了，掛了就掛了；第二個是MySQL，MySQL依然是采用主從的方式，一主七從。第三個是Coreseek，我們用Coreseek做Nice當中的檢索和推薦。

第四個是消息隊列。當然我們后來又大概買了，采購了十幾臺機器專門做數據平臺和數據分析的工作，有兩臺Log的收集機器，再加上七八臺的Hadoop的機群。

經過這一次的部署，我清楚的記得，這個決定大概是在2014年的九月初，九月四五號做得。這個東西的上線是在2014年的九月的第二周的周末。也就是說，從我們解決做這件事情，然后到采購機器，遷機房，然后拆包裝，上架，裝操作系統，調網絡，服務遷移，一共用了一周半的時間。

那么這個事情做完了之后，非常的有意思，這個事情大概是在前一天的凌晨的四點鐘最終遷移完成的。做完了以后，從第二天開始，就發現整個世界都清靜了，再也沒收到報警了。然后所有公司內部人的反饋都是，今天怎么比昨天快了好多。

當然這個架構現在在我們看來其實是有很多的問題的，包括就是如果再過一個月的時間，讓我去做這次分享的話，我們會有第五次演進。

這個架構現在的問題，從我們自己的角度來看，第一個最大的問題就是它只有一個機房，它是單點的，這個機房如果出了任何的問題，整個服務是完全不可用。第二個問題是在于Redis的Cluster是沒有災備的機制的，我們現在的Redis是用了四臺機器，每臺機器開十個實利，每個實例10G的內存，然后前端是用23：24做代理。

如果說Redis我們現在采用的是一致性哈希，一致性哈希最大的問題就是掛了，掛了一臺機器，像我們這種情況掛了一臺機器1/4的流量就掛了，所以在Redis這塊，我們未來也要有一些比較大的改動。

第三塊就是雙機房的問題，這一次做雙機房，我們其實是有一定的經驗了。首先，我們是一定要用專線的，否則最底層的這個基礎設施如果不穩定的話，你在上層做的任何東西都是掰扯；其次在做雙機房的時候，當底層的網絡能夠達到我們的要求的時候，最重要我們要引入一個消息隊列。

這個消息隊列最主要的作用就是在同步數據到第二個機房，或者是第三個、第四個機房/因為上層如果沒有消息隊列去保證這同步數據的一致性，那么你整個的數據一致性的這個問題，未來一定會很大。所以2014年9月份至今為止，我們的架構就是這樣的。我們的穩定性現在是3個9，基本上之前就是我所能今天帶給大家的全部的內容。

嘉賓介紹

程?，2008年畢業于北京郵電大學，先后在百度，美團擔任后端工程師，項目經理。 2013年自主創業，堅持一年，quit。 2014年1月加入Nice，負責整個技術團隊。 工作以來，從百度工程師干起，先后干過后臺內容發布系統，LBS相關的項目，交易相關的O2O項目，數據分析，運維，涉獵雖廣，精通的沒有。 加入Nice以后，代碼是寫得越來越少了，主要精力放在招聘和管理，并對后端服務的穩定性和性能做過幾次大的調整。

轉載于:https://www.cnblogs.com/davidwang456/articles/5354153.html

總結

以上是生活随笔為你收集整理的1年内4次架构调整，谈Nice的服务端架构变迁之路--转的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。