踏上架構之路（一）——一個初創產品的系統架構思路
http://www.lxweimin.com/p/67cc325311a8
字數4991閱讀121評論0喜歡4
"Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second."
2014年底2015年初是我的一個迷茫期，當時我在工作的方向上一直徘徊猶豫。2015年5月，在投資人J（也就是后來的CEO）的“忽悠”下，我加入了現在的創業團隊。J事實上是一家10幾年傳統行業公司的老總，是那種傳統的不能再傳統的行業，公司也是典型的老總一人說的算的私企。J在某行業里摸爬滾打了10幾年，感覺到行業里有些深深的痛點，也漸漸有了自己的一點思路，于是想趁著互聯網＋的東風，做一個平臺解決B端的問題。
于是在投資人原有公司的幾個手下的幫助下，一起創立了這家創業公司。抱著邊闖邊試邊學習的心態，就這么甩開膀子（不知天高地厚地）就干起來了。現在離團隊雛形組建完成項目啟動差不多整整5個月過去了，我們的產品第一個版本即將發布（2016.2更新：已經發布到1.2.0版本），于是我想把過去半年遇到的以及以后可能面臨的問題都記錄下來，給自己也給團隊留下一個完整的歷程紀錄。這也是我第一次嘗試為一個中型移動互聯網項目設計從前端到后臺完整的架構，也算是自己的學習心得吧。再次聲明，我也是邊學邊干，這只是筆記，難免有大量的錯誤和不足，僅供參考，歡迎指正。
掀起你的蓋頭 ——［產品的大背景］
OK，上任后第一件事就是聊天。和J總前后聊了兩個多星期，心里對產品需求有了一個整體上的概念：業務方向不多說，單從概念上說，這是一個B2B2C的電商平臺產品。但是這又是一個特殊的電商平臺，因為它的客戶對象是一個非常垂直的群體，商品本身也有著一定的特性。由于身份和商業的關系，暫時不能明確指明產品和內容，但是綜合整體來說，有以下特性和要求（有行業經驗的人應該能夠猜出具體方向）：
1. 平臺商品具有明顯的層級關系，C端（Web端和App端）的UI具有對應的層級結構；
2. 商品的展示頻率遠遠高于交易頻率，并且交易頻率可預期非常低，但是一旦交易，即為大額或高額交易；
3. 初期架構需要基本完整的電商閉環，即包含B端上傳服務，展示交易服務，支付結算服務，客服售后服務，財務系統服務，同時包含基本的業務監控和系統監控；
4. 平臺訪問量，初期目標（上線后3～6個月內），日均不高于10萬PV；(3個月后更新，殘酷的事實證明是不超過5000PV，不過這并不是研發的問題，在此不表。)
5. 系統所有有效數據（包括內容數據，業務數據等）需要能夠保存并為未來的潛在分析提供基礎。
工欲善其事，必先利其器 ——［架構選型］
基本需求已經明確，接下來就是技術選型。起頭階段必須要同時考慮的幾個方面：
1. 開發團隊的組建成本和速度
2. 系統開發的速度和可維護性
3. 系統擴容的靈活性和穩定性
這里面第1條其實是最重要的，因為創業團隊要的是速度和質量，有了第1條，第2條才有保障，而第3條其實是最不是問題的問題，我曾經看到過幾句話，對我的思路有著深深的影響，即是本篇的開頭引語，其實在它之前還有一句：
"In the beginning, make building a solid core product your priority instead of obsessing over scalability and server farms.Create a great app and then worry about what to do once it's wildly successful. Otherwise you may waste energy, time, and money fixating on something that never even happens."
創業初期，關鍵是你的App的內容，功能和質量。不要為了scale而scale，而導致整個項目的盲目復雜和拖累。事實上，這個思路一直貫穿了迄今為止我的整個項目，一句話“殺雞勿用牛刀，夠用就好”。
OK，有了這樣的前提，首先來考慮后臺框架。后臺的框架類型和開發語言相輔相成，息息相關。擺在面前的無非幾種：
1. PHP
2. C#/C++ (ASP .Net)
3. Java (Spring，Struts)
4. Python (Flask， Django，Tornado)
5. Ruby (ROR)
當然，除此之外，或許還可以考慮直接整合現成的BaaS/SaaS/PaaS服務 (LeanCloud等)。
.Net我想都沒想就否決了，因為自己是做Linux出身，對微軟的東西沒啥好的印象，不是敵視，就是純粹意義的不喜歡。Java也是如此，但是不可忽視的一點，常規情況下，要說做電商，毫無疑問的首選是Java和PHP，大量ECShop的模版均是基于這種體系。但是我考慮到：
PHP做起來快是快，人也好招，但不適合處理復雜業務邏輯，將來如果要考慮擴展性更是麻煩；Java是厲害，但是對于初期項目而言，開發和部署都太重，前期系統搭建和維護成本反而遠遠超過業務邏輯本身；ROR做一個社交系統可能比較方便，但是能夠維護好Ruby的人我去哪里找？更何況我們需要交易，把復雜的支付交易邏輯交給Ruby我怕是睡不好的；于是只剩下Python了。看起來Python似乎滿足了這個項目至少1～2年的基本需求：要處理隊列？單機有RQ，ZQ，多機有RabbitMQ，想分布式擴展？試試Celery，將來要做數據挖掘？上SciPy、NumPy，Python天生就是爬蟲的首選，其他諸如部署Fabric，監控用Supervisord等等，看起來應有盡有。
其實以上都是我瞎扯的，因為當時真實原因很簡單：“Python我比較熟。” 架構師選型，自然優先是選擇自己最熟悉的體系。所以，沒有最好的，只有最合適的。合適你自己的東西就是好東西。
OK，Python定下來了，那框架呢，小打小鬧的web.py不用考慮，FDT三家選誰？考慮到一期目標項目的規模和業務內容，選擇Django自然是首選：第三方支持豐富，ORM處理方便，數據庫操作簡單，中間件擴展靈活，性能夠用……當然，任何事情都有兩面性，Django也有自己的問題，比如并發不是Django的強項，ORM的封裝雖然強大，但是也基本上給將來想做DAO層的二次開發帶來比較大的難度，事實上在后來數據庫切分的時候，Django的不足就比較明顯了，這個問題如果后面有時間再來慢慢記錄。 但不管怎樣，我仍然相信Django是中小型項目起步階段的首選。
踩在巨人的肩膀上——［系統部署］
Web Server系統的選型確定了，接下來一件事，就是系統部署架構了。LAMP仍然是圣經王道，但是操作起來自然是LNMP，中小型項目你想不用都難，因為它就是這么好用。因為需要交易，MySQL選擇InnoDB是必須的；又因為項目展示內容的特性，擁有強大的靜態緩存和反向代理能力的Nginx也是當仁不讓的選擇。
好，菜都湊齊了，在哪炒呢，自己家建廚房還是上館子店讓別人代勞呢 ？可能第一反應是自己家炒嘛！數據什么的都在自己手上，進了機房門就能直接調試，舒舒服服，多好。可是，隨之而來的問題呢：電源，空調，布線，監控，報警，宕機維護，擴容……Oh No，想都不敢想。再說，這些不要錢么？拋開這些不談，光是一個外網訪問帶寬就能讓你肉疼。所以，云托管。
好，問題又來了，選哪個云？七牛云，阿里云，百度云……天邊飄來很多云，每家似乎都有特色。事實上，在做這個項目之前我也沒有太多實際操作云的經驗，但是簡單的調研對比之后，我的目標基本鎖定在七牛和阿里兩家。考慮到整體分布式服務的支撐和穩定性，最終選擇了以阿里云作為主業務服務部署端，七牛云作為內容服務器部署端相結合的架構。
1）阿里云為業務服務端云，是因為我的業務服務器都在阿里云上，而且阿里云能提供絕大多數我需要的基礎設施，在這個項目中我用到了以下服務：
a. 云服務器ECS：作為項目提供所有服務器支撐；
b. 數據庫服務RDS：作為項目的主業務邏輯的數據存儲，選擇MySql；
c. 分布式緩存OCS：作為RDS的前端緩存，為只讀業務提供緩存，減緩RDS壓力；（注意，阿里云的OCS是基于bmemcache的，所以不能提供Key的遍歷服務，這也造成了我們在項目中期建設的時候，不得不額外搭建了自己的Redis緩存服務器來提供一些必要的服務支撐。這個后續有時間細表。）
d. 分布式文件存儲OSS：作為B端業務主文件存儲，主要存儲圖片和文本文件；
e. 圖片處理服務：為B端提供圖片訪問和緩存支撐；
2）七牛云為內容服務端云，基本作用是提供文件存儲和圖片處理，最大的原因是以下幾個：
a. 七牛的CDN向來做的不錯;
b. 七牛的圖片處理服務在我看來是頂級的，如果你的業務以圖片處理和訪問為主，七牛是比較好的選擇；
c. 它每個月有10G的免費存儲和100萬次Get/10萬次Put流量，免費的我干嘛不用。
實際上，上述的系統部署和基礎設施的選用也不是一次到位的，這個過程也經歷了從小到大，從簡單到復雜，前前后后大約2個月左右的演變過程，雖然談不上演變有多先進，但是系統的整個設計過程，我處處遵循了開篇時的那段引子的原則：“先功能再優化，先簡單再復雜”。后面我會單起一篇分享一下項目的架構是如何一步步發展和演變的。
開始畫圖紙——［業務模塊］
如果說，架構選型是找到最合適的設計院和工程隊，系統部署規劃是找到合適的地皮和基建設施，那么項目的業務模塊設計就相當于蓋房子之前的要畫設計草圖了。
基本上從大的角度來說，一個完整的分布式B2C系統所需要的各個模塊部分是差不多的，這個網上有太多的文章可以參考。但是問題在于，并不是別人的系統就是最適合你自己的：也許別人幾十人幾百人花了幾年搭建的系統，你拿過來照搬，打死你也做不出來；又或者別人提供的架構其實很多部分對于你自己的項目來說都是殺雞用牛刀，根本就是多余的。所以，整體框架可以參考，但是結合到具體項目，還是必須根據實際需要單獨設計。這點上，我并沒有什么太多的創新的部分，更多的工作，是在已知通用業務框架上作一些裁剪和修補的動作，量體裁衣。
B2B2C系統，BBC3大部分這是跑不掉的，具體到每一個環節：
1）商戶端B：
a. 用戶管理，權限管理：商戶信息設置，權限控制，主要體現為交易權限控制；
b. 內容上傳，內容管理：商品內容空間的創建，圖片文字數據上傳，審核狀態的操作，已上架信息的CRUD管理和預覽等等
c. 交易管理：實時交易訂單控制，非實時交易訂單控制，物流管理等；
d. 消息管理：B2B消息，B2C事件消息管理；
e. 增值服務：推廣服務，反饋服務等等；
2）平臺服務端B：
a. 用戶管理／權限控制：包括BC兩端用戶和平臺各模塊管理員的管理控制；
b. B端內容審核服務：主要負責B端內容的核查相關服務；
c. B端內容管理服務：管理B端數據，提供B端服務API；
d. C端內容發布服務：主要負責內容從B到C的轉換；
e. C端內容管理服務：主要負責C端數據Restful API和業務API；
f. 業務邏輯模塊：主要負責處理項目相關主業務邏輯，到目前本篇文章成文為止，已包括四大子模塊，后續將增加更多模塊：
i) 交易管理
ii) 訂單處理
iii) 洽購處理
iv) 競價處理
3）用戶端C：
a. 內容管理：主要負責數據的展示
b. 交易管理：對應于商戶B端，實時交易訂單控制，非實時交易訂單控制，物流管理等；
c. 個人相關數據管理：主要負責和個人相關聯的寫數據請求
用戶端這部分，上述3個模塊只是從整體上來簡要說的，實際上，由于項目的跨平臺跨端口的要求，具體又要對Web端和移動端做不同程度的定制化處理。比如在數據安全性上，Web端和移動端需要不同的處理辦法。在前端緩存上，移動端App不像Web Browser那樣自己本身能提供一定的緩存機制，需要單獨做一些處理。
上面這些模塊的劃分，也僅僅是從大概念上做的比較粗粒度的，具體到每一項，都可以單獨拿出來寫，很多其實絕大多數書上和網上都有足夠的參考，我并不能一一枚舉，但是這其中仍然有一些模塊是我覺得非常值得拿出來落成文字，也是我們花了大部分精力研究和完善的：1）交易訂單的處理，對于一個電商平臺來說是重中之重，2）App前端緩存處理。3）系統各模塊的橋接處理。
后面我會結合系統架構的演變細節，仔細介紹前面提到的這幾個部分我們曾經遇到什么坑，埋了什么坑，又是怎么填的坑。
紅花都得有綠葉襯——[系統外圍輔助業務]
一個完整的項目系統，除了提供主業務功能的主服務系統之外，還得額外考慮必要的輔助業務系統。對于我們這個項目而言，必要考慮的包括：
1）監控服務：主要負責對系統業務服務器的監控，以及主要業務指標的顯示操作等管理。大部分情況下，阿里云自身的ECS服務器和RDS監控已經能滿足最基本的監控需求，但是仍然還有一部分和業務密切相關的監控是必須要額外建立的，比如所有外部接口的頻次統計，所有業務數據的實時統計，以及核心業務事件的追蹤等等。這其中，接口統計和事件跟蹤，又可以在前端和后端兩部分分別完成，前端我們依賴于大量的第三方支撐，以免自己重復造輪子。目前使用的有：Web端－百度統計，移動端－友盟統計；后端部分，我們是在Django的中間件層，自己實現了一個簡單的API中間件來實現全服務層的指標監控。這部分考慮到性能的因素，需要完全建立在緩存之上，一開始我們想在阿里自己的OCS上做文章，結果后來發現OCS在key的支持上非常的弱，沒辦法只好自己搭建了Redis緩存服務器來為這層中間件服務。但是后來的實踐證明越來越多的系統內部服務需要依賴在Redis之上，所以漸漸的OCS退化為只是單純的為C端用戶提供只讀數據緩存這一項單一功能了。
2）財務系統：主要負責對交易數據的歸總和財務接口。B2B2C和C2C之間的最大區別，是除了常規的對賬操作之外，還有必要的分賬操作，在我們項目的初期階段，考慮到業務的規模和復雜度，目前分賬操作是線下的，但是我們提供了必要的基礎服務給對賬和分賬操作提供基本支撐。
3）地推服務系統：這是和項目運營部門的實際需求掛鉤的，同樣建立在Redis緩存服務至上，在此暫不細表；
4）客服系統：主要提供平臺和品牌的反饋追蹤，交易跟蹤處理等業務提供可視化數據服務，提供客服溝通效率；
5）日志處理系統：主要負責維護系統每天的日志輸出。
6）系統自動化部署服務：實際上，在我看來，系統自動化部署完全不應該和以上這些“低級別”服務并列。因為它真的很重要，在大型公司，系統的自動化集成，發布和部署甚至是一個獨立的大部門而存在。我從一開始就對這個部分很頭疼，原因是之前的工作經歷絕大部分情況下是接手已經成型的產品線，很多自動化框架都已完成，接受團隊只需要依葫蘆畫瓢對新功能進行添補就可以。而對于現在這種完全從零開始的產品，一開始對自動化框架進行規劃是再合適不過的。可是事實也是不完美的，對于我們這樣的初創團隊，一開始人手嚴重不足，單是為了以上提到的系統模塊就已經讓大家忙不過來了，所以自動化部署和發布這部分一直拖延，直到項目上線前的后期階段才初步嘗試。我們使用的是Fabric部署框架，結合大量的Shell腳本，主要完成后端服務器的代碼管理，打包，遠程分發以及做些發布前的必要的Config。
2016年2月12日，完稿于吉隆坡.
