基本產(chǎn)品形態(tài)

　　產(chǎn)品的基礎功能無(wú)非是所有社交app軟件開(kāi)發(fā)都具備的那些東西，新鮮事、好友關(guān)系(同微博一樣，單向follow)、地理位置(當前的位置、你附近的人)更多小的細節和功能點(diǎn)現在還不便于透露。

　　其實(shí)社交這種產(chǎn)品給我的感覺(jué)一直是挺怪的，相對于技術(shù)和那些摳交互的產(chǎn)品分析來(lái)說(shuō)，這東西更讓人著(zhù)迷的是一種心理魔術(shù)，比如上面說(shuō)道約炮A(yíng)pp，你可能會(huì )想到陌陌，但是陌陌的產(chǎn)品層面上跟眾多社交App是一樣的，也是feed、follow和地理位置，而我們正常的社交，正常的朋友圈子用的最多的是微信而不是陌陌，但當夜深人靜你想打發(fā)掉寂寞的時(shí)候，可能就會(huì )去用陌陌了，雖然功能和技術(shù)相似，但是一些產(chǎn)品細節對用戶(hù)的暗示卻造成了全然不同的結果，就跟QQ、MSN、Gtalk之間的感覺(jué)類(lèi)似，雖然它們的主要功能都是聊天，app開(kāi)發(fā)但是各自的用戶(hù)群和使用氛圍完全不同。結合自身的需求，去體驗目標用戶(hù)的心理，想辦法滿(mǎn)足自己和用戶(hù)的心理訴求，這也是做社交類(lèi)型產(chǎn)品最大的樂(lè )趣吧。

　　技術(shù)選型

　　最開(kāi)始的技術(shù)選型秉著(zhù)簡(jiǎn)單清晰、盡快實(shí)現想法，減少復雜的引入，但是要盡量為以后的擴展做好準備這么一種想法。很多互聯(lián)網(wǎng)創(chuàng )業(yè)心靈雞湯比如《黑客與畫(huà)家》、《Rework》也都大概是這么提倡的，先把東西迅速做出來(lái)，然后根據用戶(hù)的回饋發(fā)現問(wèn)題快速迭代。下面介紹一下我選用的技術(shù)棧：

　　1. 語(yǔ)言:

　　人生苦短，我用Python

　　2. 存儲和數據訪(fǎng)問(wèn)工具：

　　這年代存儲面臨的選擇的確很多，但我還是選擇自己最為熟悉的MySQL，原因不必多說(shuō)。根據之前的經(jīng)驗，像是用戶(hù)表這種會(huì )保持不動(dòng)，但是有些表，比如feed index我在一開(kāi)始就做了sharding的處理(關(guān)于feed的實(shí)現和存儲結構我在后面會(huì )進(jìn)行介紹)。另外很重要的東西就是數據訪(fǎng)問(wèn)層的實(shí)現了，雖然有些東西，比如讀寫(xiě)分離的支持，現在不會(huì )用到，但是我覺(jué)著(zhù)要支持，最起碼要考慮這種情況將來(lái)會(huì )發(fā)生，到時(shí)候不至于太苦逼的到處重寫(xiě)代碼，另外對于sharding，要做到跟訪(fǎng)問(wèn)通常的表類(lèi)似的輕松，最后要帶點(diǎn)兒ORM功能。

　　做的第一件事情就是寫(xiě)這個(gè)數據訪(fǎng)問(wèn)工具，業(yè)務(wù)就是增刪改查么，沒(méi)有這家伙還怎么活!?用python兩三百行代碼對web.py的數據訪(fǎng)問(wèn)模塊做下包裝就搞出這么一個(gè)東西來(lái)，最終可實(shí)現讀寫(xiě)分離和對sharding的支持。當然在用的過(guò)程中發(fā)現問(wèn)題不少，有些查詢(xún)不能很好的滿(mǎn)足需求啊等等，完善中。

　　3. 緩存

　　因為這個(gè)項目屬于80/20那種課余愛(ài)好，資源較少，最開(kāi)始也不想大推，只是給周?chē)男』锇閭兿韧嫱?，程序員怪叔叔搏妹子一笑什么的，能有兩三臺機器就很不錯了，所以對于傳說(shuō)中的分布式緩存，想想還是算了，多數東西還是直接讀庫，但是還是搭了個(gè)Redis，做啥用?主要是三件事情：1、保存token 2、記錄用戶(hù)在線(xiàn)狀態(tài) 3、防刷業(yè)務(wù) “你輸入的太快了，請休息一下繼續”之類(lèi)的。但是所有數據的獲取還是走的存儲層，到時(shí)候如果要加緩存，可以直接在存儲層去加，而不必去侵犯上層業(yè)務(wù)邏輯。

　　4. 靜態(tài)存儲

　　做社交對圖片的質(zhì)量要求是很高的，多數都是會(huì )在后臺專(zhuān)門(mén)拿出機器搭image magic等切圖服務(wù)，但對于初創(chuàng )的社交app，搞這種東西挺耗費資源的，考慮了性?xún)r(jià)比、開(kāi)發(fā)成本，就直接使用了又拍云的服務(wù)，瞬間就搞定了圖片存儲和處理的問(wèn)題。

　　5. 消息隊列

　　對于社交來(lái)說(shuō)，很多事情，比如你有幾萬(wàn)個(gè)粉絲關(guān)注，我要把你剛發(fā)的一張裸照推送給這一萬(wàn)個(gè)人，那么肯定不能等所有推送完畢再返回給你結果，那會(huì )等的不耐煩的，我會(huì )立即給你返回發(fā)送成功的結果，而把推送這件事情放到幕后，讓它自己去玩。這樣的需求情景有很多，這時(shí)就需要用到消息隊列了。消息隊列的產(chǎn)品也有很多可以選擇，這篇文章對現在流行的消息隊列做了下大概的介紹。個(gè)人對消息隊列選擇的觀(guān)點(diǎn)，一是穩定，出了錯好恢復，二是容易監控，隊列堵了啊什么的我能很方便的監控到，三是并發(fā)性，四是接口要容易使用。這四點(diǎn)，RabbitMQ明顯勝出。就選用RabbitMQ了。關(guān)于RabbitMQ使用的一些細節，會(huì )在feed分發(fā)的時(shí)候做相關(guān)介紹。

　　7. API Server

　　API全是RESTful的，用的web框架是web.py，目前調試階段還只是web.py直接對外給客戶(hù)端的同學(xué)做調試，上線(xiàn)后準備走Nginx的反向代理，另外最近也在研究這個(gè)項目：可以選擇Nginx + wsgi模塊 + web.py的模式，也可以是gunicorn + web.py， nginx再反向代理到gunicorn。

　　對于通常的API,使用web.py容易滿(mǎn)足，app開(kāi)發(fā)但是對于我們這個(gè)應用來(lái)說(shuō)，私聊是一個(gè)最為重要的功能，因此打算把聊天的服務(wù)拆出來(lái)了，單獨拿tornado去做，tornado做長(cháng)鏈接更專(zhuān)業(yè)一些，不同于web.py，tornado本身就是一個(gè)異步的web框架，像Node.js那樣。