記一個社交APP的開發過程——基礎架構選型（轉自一位大哥）

記一個社交APP的開發過程——基礎架構選型

目錄[-]

• 基本產品形態
• 技術選型

最近兩週在忙於開發一個社交App，由於以前作過一點兒社交方面的東西，就被拉去作API後端了，一我的頭一次完整的去搭這麼一套東西，上面也沒有PM和各類催促，過程仍是很輕鬆愉快充滿樂趣的，如今後端已經基本完成，下週會進入聯調測試的階段，有些東西想寫一寫記錄一下，先從技術選型開始。

基本產品形態

產品的基礎功能無非是全部社交App都具有的那些東西，新鮮事、好友關係(同微博同樣，單向follow)、地理位置（當前的位置、你附近的人）更多小的細節和功能點如今還不便於透露 :)

其實社交這種產品給個人感受一直是挺怪的，相對於技術和那些摳交互的產品分析來講，這東西更讓人着迷的是一種心理魔術，好比上面說道約炮App，你可能會想到陌陌，可是陌陌的產品層面上跟衆多社交App是同樣的，也是feed、follow和地理位置，而咱們正常的社交，正常的朋友圈子用的最多的是微信而不是陌陌，但當夜深人靜你想打發掉寂寞的時候，可能就會去用陌陌了，雖然功能和技術類似，可是一些產品細節對用戶的暗示卻形成了全然不一樣的結果，就跟QQ、MSN、Gtalk之間的感受相似，雖然它們的主要功能都是聊天，可是各自的用戶羣和使用氛圍徹底不一樣。結合自身的需求，去體驗目標用戶的心理，想辦法知足本身和用戶的心理訴求，這也是作社交類型產品最大的樂趣吧。

技術選型

最開始的技術選型秉着簡單清晰、儘快實現想法，減小複雜的引入，可是要儘可能爲之後的擴展作好準備這麼一種想法。不少互聯網創業心靈雞湯好比《黑客與畫家》、《Rework》也都大概是這麼提倡的，先把東西迅速作出來，而後根據用戶的回饋發現問題快速迭代。下面介紹一下我選用的技術棧：

1. 語言:

人生苦短，我用Python

2. 存儲和數據訪問工具：

這年代存儲面臨的選擇的確不少，但我仍是選擇本身最爲熟悉的MySQL，緣由沒必要多說。根據以前的經驗，像是用戶表這種會保持不動，可是有些表，好比feed index我在一開始就作了sharding的處理（關於feed的實現和存儲結構我在後面會進行介紹）。另外很重要的東西就是數據訪問層的實現了，雖然有些東西，好比讀寫分離的支持，如今不會用到，可是我覺着要支持，最起碼要考慮這種狀況未來會發生，到時候不至於太苦逼的處處重寫代碼，另外對於sharding，要作到跟訪問一般的表相似的輕鬆，最後要帶點兒ORM功能。

作的第一件事情就是寫這個數據訪問工具，業務就是增刪改查麼，沒有這傢伙還怎麼活！？用python兩三百行代碼對web.py的數據訪問模塊作下包裝就搞出這麼一個東西來，https://github.com/chihongze/shard.py 最終可實現讀寫分離和對sharding的支持。固然在用的過程當中發現問題很多，有些查詢不能很好的知足需求啊等等，完善中。

3. 緩存

由於這個項目屬於80/20那種課餘愛好，資源較少，最開始也不想大推，只是給周圍的小夥伴們先玩玩，程序員怪叔叔搏妹子一笑什麼的，能有兩三臺機器就很不錯了，因此對於傳說中的分佈式緩存，想一想仍是算了，多數東西仍是直接讀庫，可是仍是搭了個Redis，作啥用？主要是三件事情：一、保存token 二、記錄用戶在線狀態 三、防刷業務 「你輸入的太快了，請休息一下繼續」之類的。可是全部數據的獲取仍是走的存儲層，到時候若是要加緩存，能夠直接在存儲層去加，而沒必要去侵犯上層業務邏輯。

4. 靜態存儲

作社交對圖片的質量要求是很高的，多數都是會在後臺專門拿出機器搭image magic等切圖服務，但對於初創的社交app，搞這種東西挺耗費資源的，考慮了性價比、開發成本，就直接使用了又拍雲的服務，瞬間就搞定了圖片存儲和處理的問題。

5. 消息隊列

對於社交來講，不少事情，好比你有幾萬個粉絲關注，我要把你剛發的一張裸照推送給這一萬我的，那麼確定不能等全部推送完畢再返回給你結果，那會等的不耐煩的，我會當即給你返回發送成功的結果，而把推送這件事情放到幕後，讓它本身去玩。這樣的需求情景有不少，這時就須要用到消息隊列了。消息隊列的產品也有不少能夠選擇，http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html 這篇文章對如今流行的消息隊列作了下大概的介紹。我的對消息隊列選擇的觀點，一是穩定，出了錯好恢復，二是容易監控，隊列堵了啊什麼的我能很方便的監控到，三是併發性，四是接口要容易使用。這四點，RabbitMQ明顯勝出。就選用RabbitMQ了。關於RabbitMQ使用的一些細節，會在feed分發的時候作相關介紹。

7. API Server

API全是RESTful的，用的web框架是web.py，目前調試階段還只是web.py直接對外給客戶端的同窗作調試，上線後準備走Nginx的反向代理，另外最近也在研究這個項目：http://www.oschina.net/p/gunicorn 能夠選擇Nginx + wsgi模塊 + web.py的模式，也能夠是gunicorn + web.py， nginx再反向代理到gunicorn。

對於一般的API,使用web.py容易知足，可是對於咱們這個應用來講，私聊是一個最爲重要的功能，所以打算把聊天的服務拆出來了，單獨拿tornado去作，tornado作長連接更專業一些，不一樣於web.py，tornado自己就是一個異步的web框架，像Node.js那樣。

整體的技術選型就是這些東西吧，很是簡單，都是很成熟的一些技術，也沒有用什麼新東西，但開發起來仍是蠻爽的，尤爲是Python的開發效率更是沒的說，好比那個支持sharding的數據訪問工具，原先用Java作過相似的事情，對Spring Jdbc Template作的封裝，貌似寫了十幾個類文件，搞了好多天，如今用Python 兩三百行直抒胸意一上午就秒掉了，開發效率徹底不一個檔次，哈哈哈。