作為技術人員，已經有蠻長一段時間沒有把自己的開發經驗做一次總結了，可能是因為太忙和太懶吧，所以這次決定把自己這兩三年來作為創業團隊的成員在技術方面的心得和技巧做一個總結，也包括簡單提及一下和之前在大網站工作的時候一些不同點進行分享。
先介紹一下自己，網名RainX，2004年畢業後進入雅虎中國工作，之後直到2010年底，一直在阿裡集團的技術團隊。 2010年底的時候覺得時機比較合適了，就離職出來創業，先後做為合伙人創立了碼雲網（類似國外的eventbrite的自助活動管理平台）以及目前正在進行的回聲網（情感故事社區）。
首先先說一下作為創業團隊的技術人員的成員和在大公司的技術人員的不同之處。
-
首先，大公司的開發人力資源充足，不管你是做架構的設計，還是底層開發人員，都不需要對所有的技術細節都有了解，而是精專在某個領域，越 深入越好，通過團隊的協作來解決單個人的能力短板，比如DBA可能對開發不是特別了解，後端開發無需了解前端的太多技術等等。 但是在初創團隊，就需要相對全面的技能，比如我們之前在開發碼雲時，我一個人就需要同時寫前端代碼和後端代碼，部署數據庫，做界面的設計，寫安卓和iOS 的客戶端，以及桌面客戶端，甚至還要幫我們拍攝的宣傳視頻做剪輯以及後期的音效工作。
-
然後，除了豐富的人力資源外，大公司內部一般也有 很多成型的系統，比如在雅虎的時候，有yapache(web服務器）, yinst（包管理），mdbm（kv數據庫), shmproxy (網絡通信中間件）, yrepl（消息中間件）等，創業團隊無法應用到這些系統，只能找開源的對應產品替代。
-
最後，大公司有很多成熟 的服務資源，從硬件方面的服務器，CDN，帶寬等，到軟件服務方面如短信平台，郵件平台等，都可以直接使用，但是初創團隊就要購買或者尋找一些對應的替代 方案，目前這些很多是以雲服務的形態出現的。基於這點，我有一個比較深刻的體會，這次回聲在有一次推廣的時候突然發現系統無法訪問了，登錄到服務器上也很 慢，先後排查了web服務，數據庫，郵件服務等都沒有發現問題，最後發現原來是由於流量突然增大，我們購買的VPS的帶寬用盡了，然後緊急的購買了新帶寬 才解決這問題，但是同樣的問題在之前雅虎和淘寶工作的時候就根本沒有遇到過。
-
如上面所述，開源軟件和雲服務的使用是初創團隊不可或缺的元素，也同時可以大大的節約初創團隊的時間成本。拿回聲為例，我們大概只花了2個月的時間就完成了整個系統的搭建並上線，下面我就分幾個方面分別介紹一下系統的搭建過程
整體架構
上圖簡單描繪了我們系統的架構和所使用的軟件（括號內部）和服務（圓形標識）的情況，可以看到，網站的結構是非常簡單的，我們將網站部署在2台 VPS雲服務器上，一台提供web服務，另外一台所作為mysql slave供我們進行數據分析使用，注意由於我們目前流量還沒有非常大，所以這台暫時還不提供對外的服務，只做數據分析用。目前兩台VPS節點都使用的阿 裡雲的服務，關於VPS的選擇方面，其實國內的選擇空間不是特別大，比較難找到Amazon EC2類似級別的服務，如果創業的目標用戶是針對國外用戶的話，還是推薦Amazon EC2或者L
Linux/1672.html' target='_blank'>
inode等比較有規模的服務商。
1 web服務 : web服務我們采用的是LNMP的架構，LNMP的好處是開發簡單，快速，資料豐富，並且被驗證足以支撐到一定規模的訪問量(facebook, yahoo等），php的mvc我們采用了codeigniter作為基礎框架，同樣是因為簡單，作為創業團隊，盡量選擇自己熟悉並且穩定的系統和架構構 建你的網站，我不太建議刻意嘗試太多新的東西，即使你的技術足以駕馭它，還是不可避免的踩很多坑，這會消耗創業者寶貴的時間和精力。
在web前端方面，我們采用了基於HTML5的響應式設計，這足以用單獨的一篇文章來介紹，而我們在後面也會寫一篇單獨的文章來介紹這塊。
2 緩存服務&鍵值存儲：不管是之前還是現在，我們都有很多的場景會使用到基於key-value的存儲還有緩存的服務，redis在性能和功能上 有一個比較好的均衡，使用起來也不會太復雜，所以我們在系統裡面大量的應用到redis, 如記錄用戶目前是否是第一次訪問某個頁面，記錄用戶是否升級到某個版本，以及首頁的推薦文章的緩存，系統的部分配置信息等。
3 異步隊列服務（或者消息服務）：我們使用Gearman作為隊列服務的支持，嚴格說來Gearman並不是一個標准的消息系統，但是Gearman簡單高 效的特點吸引了我們，並且它分布式架構足以支持更高級別的系統負載，並且他對php的支持很好，我們使用的是它的異步任務部分，關於Gearman如何作 為隊列服務支持郵件的發送，可以參考官方網站的use cases裡面的介紹， 除了郵件服務之外，我們的手機通知的推送服務也是基於Gearman進行了隊列化的。
4 郵件服務：對於網站來說，不管從郵件營銷的角度，還是作為網站服務的基礎部分，郵件都是很重要的一部分，這部分比較復雜，後面我們會單獨用一個小節來介紹一下我們目前采用的郵件服務方案。
5 搜索服務：目前使用的是Coreseek，Coreseek 是一款中文全文檢索/搜索軟件， 是基於Sphinx結合中文分詞系統進行開發，優點是和php，mysql結合較好，有中文的支持，當然基於xapian的xunsearch也是一個不錯的替代方案。
6 推薦系統：回聲網需要給用戶推薦他可能喜歡的群組，以及潛在還需要根據群組推薦相關的群組，在推薦系統的選型上，我們選擇了基於協同過濾的Mahout Taste CF來計算用戶可能該興趣的群組，然後使用Ruby語言基於Recommendify開發了基於item到item的推薦。我們會在每天晚上進行運算，把 結果放在數據庫中提供前端調用。
當然雖然基於協同過濾的推薦系統已經非常完善了，但是由於它是基於統計模型的，在初始用戶的行為數據比較少的情況下，該模型相對難以解決新用戶 的推薦問題，比如我們會提供給新注冊用戶一些群組推薦，這裡我們使用了一些基於用戶特征的推薦，比如給群組打上標記，比如 “我想把學校炸啦” 這個群組我們會標記為優先推薦給90後的用戶， “我是處男” 這樣的群組我們只會推薦給年輕的男性用戶。
7 數據分析方面： 首先GA是網站服務不可缺少的工具，唯一的缺點是GA後台的訪問不太穩定，最好配合VPN進行訪問，關於GA使用方面的介紹，我的合伙人everfly會有寫一篇專門的文章介紹。另外，基於app方面，我們使用Flurry提供的服務進行數據分析。
除了第三方提供的數據分析服務之外，有一些比較細致的分析還需要基於網站的自有數據進行，因為剛好之前有一台閒置的VPS，所以目前就拿來作為我們的數據分析服務器了，和主數據庫配置了Master-Slave結構，數據分析在Slave上及進行，不影響線上的業務。
8 域名服務：我們的域名是從godaddy上注冊的(.fm的域名有點小貴），但是不建議使用godaddy的服務器作為nameserver, 因為偶爾會被牆，這裡我們直接把nameserver遷到了dnspod上，還是非差穩定的。
9 CDN ： 如果你的沒有涉及到大量的圖片或者聲音數據，其實我覺得可以省掉購買CDN服務的步驟，不過我們的 網站剛好會有一些群組封面圖片和用戶自己的封面圖片的展示需求，並且在一次推廣中觸及到了VPS流量的上限，所以我們把圖片訪問部分遷移到的CDN服務 上，這方面選擇很多，我們使用了orca的服務，orca的服務有一個亮點是支持dropbox的同步，便於管理。當然orca畢竟上線的時間不長，如果 需要更專業的雲存儲服務，推薦又拍雲和七牛雲存儲。
由於篇幅有限，這裡很多內容無法展開來詳細的介紹，下面我針對一些我感覺到相對比較重要的兩個部分：發布系統和郵件系統做一個具體的說明。
發布系統
由於網站的結構是基於
lnmp的，所以我們主要的代碼都是php代碼，之前在大網站的時候，一般會有比較嚴格的流程和比較嚴格的打包發布機制，比如Yahoo的 yinst package， 但是對於初創團隊來說有些重了，這裡我們直接使用svn進行代碼的管理和發布。
雖然系統環境不復雜，但是我們還是分為開發環境，測試環境(beta)，和生產環境（線上），開發環境我們在自己的機器上搭建，我的是 Ubuntu的系統，everfly是MacOS的系統，測試環境在和svn服務同一台服務器上，我們使用svnseve的post-commit 功能實現了一旦我們提交了代碼，服務器會自動將代碼部署到beta環境的web服務器上， 在生產環境則是直接使用svn export進行部署，整個流程還是非常簡單的。
注意，有的時候我們在生產環境和開發環境的時候需要執行不同的邏輯，比如針對html內部引用的javascript代碼，為了節省流量（當然 還有一個原因是代碼寫的太丑了，不想讓大家看到笑話），在生產環境上，我們使用了jsmin進行壓縮，但是在本機進行開發的時候，為了調試前端代碼方便， 不能對javascript代碼進行壓縮，所以我們通過設置環境變量，然後在代碼中檢測環境變量的方式解決了這個問題，由於環境變量是設置在web server或者php-fpm的配置中的，所以線上和開發環境可以保持同一份代碼，在代碼中判斷當前的系統執行不同的邏輯即可。
郵件系統
作為一個社區網站，郵件系統是非常重要的部分，我們的郵件分為觸發式（注冊確認）郵件和群發郵件（每周故事摘要）兩部分，
我認為郵件系統最主要的亮點是可配置性和隊列化，由於我們網站的主要用戶是QQ用戶，所以QQ郵箱占我們用戶的絕大部分的比例，所以我們把QQ 郵件單獨出來，分為四種情況，QQ群發，QQ觸發，其它群發，其它觸發，然後針對我們可以使用的郵件發送平台，本機Postfix, Amazon SES，sendgrid,QQ企業郵箱可以隨意組合，這個配置可以在後台完成，即時生效。
然後再談一下我們這段時間對不同的平台發送郵件效果的體會，首先是觸發式郵件，這個比較簡單，不管是任何的平台，觸發式郵件的到達率都很高，不過sendgrid和Amazon SES的免費服務有限額的限制，所以我們針對觸發式郵件目前使用自建服務器來發送，很多人之前在自建服務器的時候都遇到很多問題，其實自建服務器郵件發送 沒什麼特別的秘訣，但是至少基本的dkim, spf 以及域名解析等還是能做的都要做的， 這些配置在使用第三方服務的時候也都要做，為了避免混淆，我們注冊了幾個不同的域名分別通過不同的平台發送郵件，避免了域名解析沖突的問題。
針對群發郵件，我建議還是采用第三方的服務比較靠譜，倒不一定是第三方的服務到達率有多高，只是由於群發郵件很容易被標記為spam，如果和觸 發式郵件配在一起反而會影響到觸發郵件的到達率。另外，我們針對群發郵件的隊列進行了發送頻率的控制，比如20秒鐘發送一封，這樣也一定程度上避免一下子 達到某個郵件服務商的時間限額而進入垃圾箱。我們目前使用的是Amazon的SES作為群發的支持，優點是費率相對較低，缺點是到達率不是特別理想，另外 後台數據分析界面相對簡陋了點。對於對到達率需求較高的用戶，推薦使用mailgun，但是費用相對較高。
當然如果你的郵件發送規模再小一點，也可以使用QQ企業郵箱進行發送，有點是針對QQ郵箱的到達率相對較高。不過QQ企業郵箱每天和每個小時都有發送的配額限制，如果你要發送的郵件過多應該是無法支撐的。
再次提醒，不管你是自建服務器，還是使用mailgun,Amazon SES,或者sendgrid以及QQ企業郵箱發送，在條件允許的情況下 DKIM和SPF驗證是一定要配置的，如果可能的話弄一下域名反向解析。
當然上面介紹的更多都是技術層面的，對於更大規模的發送，尤其是在國內，被郵件服務商加入白名單才是王道，不過這個就不屬於本文的討論范圍了。
以上就是我總結的一些技術方面的心得，希望能對起步階段的同學們有些幫助，當然除了技術方面，在項目管理方面，我們也用到了很多相關的雲服務， 比如Asana, Yammer等，如此多的服務，會涉及到很多帳號和密碼的管理問題，這裡我們使用meldium來管理所有系統服務相關的帳號密碼，它的一鍵登錄功能非常 方便實用。
From：evernote
