移動社交App服務端開發總結

我目前在一創業公司，開發一款移動社交app，作為服務端首席碼農（服務端就我一個人啦），見證了服務端從無到有的全過程。客戶端從最初上線至今5個月以來，迭代了8個版本，服務端淡定地表示毫無壓力（當然， 這跟我們處於發展初期，使用者量和資料量不大有很大關係）。我把這個過程分享出來，和大家交流一下，本文不談具體的技術實現，主要談技術棧和一些感受。由於技術能力和視野的欠缺，不足之處，歡迎指點。

1. 雲服務

1.1 阿里雲

伺服器用了2臺ECS，做高可用，ECS前用nginx做負載均衡，當然，也可以使用阿里雲提供的負載均衡服務，不過那是要花銀子的，創業初期，能省就省了，不過ngingx服務也是蠻穩定的。

由於我們的產品面向海外使用者，所以使用的是阿里雲在洛杉磯的伺服器，海外訪問的速度應該還可以，國內稍差點，導致阿里雲的監控經常超時報警。2臺ECS的配置均為：2核/8G/4Mbps。

資料庫用了1臺RDS MySQL，可靠性和可用性由阿里雲保障，自己只要針對性地做一些引數調整和優化即可，也沒什麼運維成本。RDS的配置為：1200M記憶體/50G空間/300最大連線數/600最大IOPS。

測試環境用了1臺單獨的ECS，然後在上面安裝了MySQL。

總體來講，阿里雲提供的技術服務還是不錯的，至於售後服務，至今沒打過交道，無法評價。

1.2 環信

社交產品肯定少不了訊息模組，我們用的是環信。其實我是被選擇了環信，因為我接手的時候，客戶端已經基於環信開發了。其實對訊息服務提供商，我個人印象最好的是 LeanCloud ，這裡就多說兩句（有點廣告的嫌疑了，哈哈），對這個創業公司最初的印象來自於他們的創始團隊，創始人來自Google，很有極客範，後來瞭解了一下他們的產品，感覺他們的API和Demo比環信的專業和規範太多了，大家可以自己去比較，我打算以後有機會體驗一下他家的一站式後端服務。

說迴環信，功能上沒啥問題，該有的都有。這裡說幾點感受：1. 介面文件不全：有一次，我需要一個介面，很常見的需求，文件上沒有（確實沒有），我問了一下技術諮詢，他說有啊，然後發過來一個介面示例，我想，如果寫在文件上，那不是節省了雙方的時間麼！2. 技術客服有的很專業，有的很水，經常是問一個問題，客服轉來轉去的；3. 環信沒有部署海外節點，所以海外服務的質量一般，訊息存在延時的問題。

1.3 七牛

我們的圖片存在七牛上，七牛提供各種圖片處理方式，是很方便的。

我們的產品面向海外，曬圖又是主要功能之一，所以為了優化使用者體驗，選擇部署了海外節點的服務商是重要考量。目前來看，基本沒得選，就七牛可以。但是七牛海外加速下載的費用非常高，是國內下載流量的5倍/G，創業公司傷不起哇！

另外，10月8日的故障（官方說是電纜被挖斷）影響甚廣，我們也是受害者，當時app內的圖片基本全部無法顯示（技術客服說有CDN快取，但是並沒有什麼卵用），故障持續了差不多一個半小時，後來賠付方案出爐，一共賠了我們7.6元，還是百倍賠付哦，我們都表示七牛好大方！

我覺得七牛的文件和示例都很一般，舉個例子，服務端通過七牛的介面上傳下載圖片經常超時報錯，我找了技術客服很多次，各種日誌截圖，各種解釋，他們最後告訴我海外上傳下載有單獨的域名和ip，但是文件上一字不提，跟別提配置方法了。關於七牛的客服，我有個經驗，就是通過QQ交流時，他們愛搭不理，但是如果提交工單，回覆會很及時。

對七牛的服務，印象並不算太好，只是現在沒有更好地解決方案。

2. 技術棧

2.1 SpringMVC + Spring + MyBatis

典型的Java Web結構，通過SpringMVC提供API介面與客戶端互動，使用Spring處理業務邏輯，使用MyBatis處理資料邏輯。

雖然前期資料量不大，但是功能模組比較多，導致資料庫的表也比較多。目前的功能主要分為兩大塊：社交和社群。社交模組已經有50多個表了，所以我提前進行了分庫處理，將新增的社群模組放到新庫，由於資料量不大，所以目前沒有分表的需求。

分庫可以通過MyBatis實現，在定義 MapperScannerConfigurer 的bean時，通過basePackage 設定不同的package訪問不同的資料庫。

另外，專案使用logback列印日誌，通過git進行版本管理，使用gradle構建，使用jetty部署專案。gradle可以實現類似於Maven的profile功能，將正式環境和測試環境的配置隔離開。

2.2 quartz

定時任務，用 quartz 實現的，開啟了quartz的叢集功能和持久化功能。因為專案會在兩臺伺服器上單獨部署，quartz剛好可以構成叢集；同時，將任務排程資訊持久化到MySQL中，則不會因為伺服器的重啟或當機導致定時任務的重複排程或錯過排程。

關於quartz的使用，可以參考我之前的博文Quartz教程系列和在 github上的小專案。

2.3 ElasticSearch

app具有基於使用者的個人資訊進行多維度的個性化推薦的功能，維度包括：位置、性別、年齡、身高、星座、國家、家鄉等等，其中最主要的還是地理位置。我們使用的RDS的MySQL版本是5.6， 我們知道MySQL在5.7之前，對空間資料（Spatial Data）的支援是不太友好的，所以其它維度還好，而基於地理位置的查詢，使用MySQL來實現是比較麻煩的，而且效率不高。

後來，我就決定不通過MySQL實現，採用NoSQL來做， ElasticSearch 和 MongoDB 都支援空間索引，而且我之前也都有過一些瞭解，最後選擇ElasticSearch的主要原因是，考慮到app以後可能會增加搜尋功能，而這可是ElasticSearch的強項啊。

然後我就用兩臺ECS，搭建了一個ElasticSearch叢集，建立一個index和一個type，然後將使用者的基本資訊從MySQL同步過來，將不同的維度作為查詢條件，就實現了一個簡單的推薦系統。

ElasticSearch叢集執行非常穩定，目前偶爾會接到記憶體達到閥值的報警，主要是由於搜尋時需要排除之前已經推薦過的使用者，導致記憶體有時會飆到80%，等騰出時間了想辦法優化一下。

2.4 Scrapy

在推廣前期，有些模組是沒有資料的，所以需要從網路上爬取一些相關資料。爬蟲使用的是python的 Scrapy框架 ，使用起來比較簡單，目前可以實現不登入爬取、登入爬取，但是具有複雜驗證碼驗證的登入爬取要麻煩，還沒有時間去研究。

關於Scrapy爬蟲入門，可以參考我之前的博文：1. 搭建Scrapy爬蟲的開發環境 ；2.Scrapy爬蟲入門例項。

2.5 Django

還有一個後臺管理系統，使用python的 Django框架 寫的，是讓一個朋友在業餘時間幫忙開發的，我基本沒有參與。

Django適合快速開發，我覺得對於後臺的系統尤其合適。

轉自 http://www.tuicool.com/articles/uErM3yi