記一個社交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，做啥用？主要是三件事情：1、保存token 2、記錄用戶在線狀態 3、防刷業務 “你輸入的太快了，請休息一下繼續”之類的。但是所有數據的獲取還是走的存儲層，到時候如果要加緩存，可以直接在存儲層去加，而不必去侵犯上層業務邏輯。
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 兩三百行直抒胸意一上午就秒掉了，開發效率完全不一個檔次，哈哈哈。