踏上架構(gòu)之路（一）——一個(gè)初創(chuàng)產(chǎn)品的系統(tǒng)架構(gòu)思路

http://www.reibang.com/p/67cc325311a8

字?jǐn)?shù)4991閱讀121評(píng)論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年初是我的一個(gè)迷茫期，當(dāng)時(shí)我在工作的方向上一直徘徊猶豫玷过。2015年5月觉鼻，在投資人J（也就是后來的CEO）的“忽悠”下邻遏，我加入了現(xiàn)在的創(chuàng)業(yè)團(tuán)隊(duì)醉蚁。J事實(shí)上是一家10幾年傳統(tǒng)行業(yè)公司的老總昌腰，是那種傳統(tǒng)的不能再傳統(tǒng)的行業(yè)盹愚，公司也是典型的老總一人說的算的私企煌珊。J在某行業(yè)里摸爬滾打了10幾年，感覺到行業(yè)里有些深深的痛點(diǎn)蚕键，也漸漸有了自己的一點(diǎn)思路救欧，于是想趁著互聯(lián)網(wǎng)＋的東風(fēng)，做一個(gè)平臺(tái)解決B端的問題锣光。

于是在投資人原有公司的幾個(gè)手下的幫助下笆怠，一起創(chuàng)立了這家創(chuàng)業(yè)公司。抱著邊闖邊試邊學(xué)習(xí)的心態(tài)誊爹，就這么甩開膀子（不知天高地厚地）就干起來了〉潘ⅲ現(xiàn)在離團(tuán)隊(duì)雛形組建完成項(xiàng)目啟動(dòng)差不多整整5個(gè)月過去了，我們的產(chǎn)品第一個(gè)版本即將發(fā)布（2016.2更新：已經(jīng)發(fā)布到1.2.0版本）频丘，于是我想把過去半年遇到的以及以后可能面臨的問題都記錄下來办成，給自己也給團(tuán)隊(duì)留下一個(gè)完整的歷程紀(jì)錄。這也是我第一次嘗試為一個(gè)中型移動(dòng)互聯(lián)網(wǎng)項(xiàng)目設(shè)計(jì)從前端到后臺(tái)完整的架構(gòu)搂漠，也算是自己的學(xué)習(xí)心得吧迂卢。再次聲明，我也是邊學(xué)邊干桐汤，這只是筆記而克，難免有大量的錯(cuò)誤和不足，僅供參考怔毛，歡迎指正员萍。

掀起你的蓋頭 ——［產(chǎn)品的大背景］

OK，上任后第一件事就是聊天拣度。和J總前后聊了兩個(gè)多星期充活，心里對(duì)產(chǎn)品需求有了一個(gè)整體上的概念：業(yè)務(wù)方向不多說，單從概念上說蜡娶，這是一個(gè)B2B2C的電商平臺(tái)產(chǎn)品混卵。但是這又是一個(gè)特殊的電商平臺(tái)，因?yàn)樗目蛻魧?duì)象是一個(gè)非常垂直的群體窖张，商品本身也有著一定的特性幕随。由于身份和商業(yè)的關(guān)系，暫時(shí)不能明確指明產(chǎn)品和內(nèi)容宿接，但是綜合整體來說赘淮，有以下特性和要求（有行業(yè)經(jīng)驗(yàn)的人應(yīng)該能夠猜出具體方向）：

1. 平臺(tái)商品具有明顯的層級(jí)關(guān)系辕录，C端（Web端和App端）的UI具有對(duì)應(yīng)的層級(jí)結(jié)構(gòu)；

2. 商品的展示頻率遠(yuǎn)遠(yuǎn)高于交易頻率梢卸，并且交易頻率可預(yù)期非常低走诞，但是一旦交易，即為大額或高額交易蛤高；

3. 初期架構(gòu)需要基本完整的電商閉環(huán)蚣旱，即包含B端上傳服務(wù)，展示交易服務(wù)戴陡，支付結(jié)算服務(wù)塞绿，客服售后服務(wù)，財(cái)務(wù)系統(tǒng)服務(wù)恤批，同時(shí)包含基本的業(yè)務(wù)監(jiān)控和系統(tǒng)監(jiān)控异吻；

4. 平臺(tái)訪問量，初期目標(biāo)（上線后3～6個(gè)月內(nèi)）喜庞，日均不高于10萬(wàn)PV诀浪；(3個(gè)月后更新，殘酷的事實(shí)證明是不超過5000PV延都，不過這并不是研發(fā)的問題雷猪，在此不表。)

5. 系統(tǒng)所有有效數(shù)據(jù)（包括內(nèi)容數(shù)據(jù)窄潭，業(yè)務(wù)數(shù)據(jù)等）需要能夠保存并為未來的潛在分析提供基礎(chǔ)。

工欲善其事酵颁，必先利其器 ——［架構(gòu)選型］

基本需求已經(jīng)明確嫉你，接下來就是技術(shù)選型。起頭階段必須要同時(shí)考慮的幾個(gè)方面：

1. 開發(fā)團(tuán)隊(duì)的組建成本和速度

2. 系統(tǒng)開發(fā)的速度和可維護(hù)性

3. 系統(tǒng)擴(kuò)容的靈活性和穩(wěn)定性

這里面第1條其實(shí)是最重要的躏惋，因?yàn)閯?chuàng)業(yè)團(tuán)隊(duì)要的是速度和質(zhì)量幽污，有了第1條，第2條才有保障簿姨，而第3條其實(shí)是最不是問題的問題距误，我曾經(jīng)看到過幾句話，對(duì)我的思路有著深深的影響扁位，即是本篇的開頭引語(yǔ)准潭，其實(shí)在它之前還有一句：

"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."

創(chuàng)業(yè)初期，關(guān)鍵是你的App的內(nèi)容域仇，功能和質(zhì)量刑然。不要為了scale而scale，而導(dǎo)致整個(gè)項(xiàng)目的盲目復(fù)雜和拖累暇务。事實(shí)上泼掠，這個(gè)思路一直貫穿了迄今為止我的整個(gè)項(xiàng)目怔软，一句話“殺雞勿用牛刀，夠用就好”择镇。

OK挡逼，有了這樣的前提，首先來考慮后臺(tái)框架腻豌。后臺(tái)的框架類型和開發(fā)語(yǔ)言相輔相成家坎，息息相關(guān)。擺在面前的無(wú)非幾種：

1. PHP

2. C#/C++ (ASP .Net)

3. Java (Spring饲梭，Struts)

4. Python (Flask乘盖， Django，Tornado)

5. Ruby (ROR)

當(dāng)然憔涉，除此之外订框，或許還可以考慮直接整合現(xiàn)成的BaaS/SaaS/PaaS服務(wù) (LeanCloud等)。

.Net我想都沒想就否決了兜叨，因?yàn)樽约菏亲鯨inux出身穿扳，對(duì)微軟的東西沒啥好的印象，不是敵視国旷，就是純粹意義的不喜歡矛物。Java也是如此，但是不可忽視的一點(diǎn)跪但，常規(guī)情況下履羞，要說做電商，毫無(wú)疑問的首選是Java和PHP屡久，大量ECShop的模版均是基于這種體系忆首。但是我考慮到：

PHP做起來快是快，人也好招被环，但不適合處理復(fù)雜業(yè)務(wù)邏輯糙及，將來如果要考慮擴(kuò)展性更是麻煩；Java是厲害筛欢，但是對(duì)于初期項(xiàng)目而言浸锨，開發(fā)和部署都太重，前期系統(tǒng)搭建和維護(hù)成本反而遠(yuǎn)遠(yuǎn)超過業(yè)務(wù)邏輯本身版姑；ROR做一個(gè)社交系統(tǒng)可能比較方便柱搜，但是能夠維護(hù)好Ruby的人我去哪里找？更何況我們需要交易剥险，把復(fù)雜的支付交易邏輯交給Ruby我怕是睡不好的冯凹；于是只剩下Python了。看起來Python似乎滿足了這個(gè)項(xiàng)目至少1～2年的基本需求：要處理隊(duì)列宇姚？單機(jī)有RQ匈庭，ZQ，多機(jī)有RabbitMQ浑劳，想分布式擴(kuò)展阱持？試試Celery，將來要做數(shù)據(jù)挖掘魔熏？上SciPy衷咽、NumPy，Python天生就是爬蟲的首選蒜绽，其他諸如部署Fabric镶骗，監(jiān)控用Supervisord等等，看起來應(yīng)有盡有躲雅。

其實(shí)以上都是我瞎扯的鼎姊，因?yàn)楫?dāng)時(shí)真實(shí)原因很簡(jiǎn)單：“Python我比較熟∠嗔蓿” 架構(gòu)師選型相寇，自然優(yōu)先是選擇自己最熟悉的體系。所以钮科，沒有最好的唤衫，只有最合適的。合適你自己的東西就是好東西绵脯。

OK佳励，Python定下來了，那框架呢蛆挫，小打小鬧的web.py不用考慮赃承，F(xiàn)DT三家選誰(shuí)？考慮到一期目標(biāo)項(xiàng)目的規(guī)模和業(yè)務(wù)內(nèi)容璃吧，選擇Django自然是首選：第三方支持豐富楣导，ORM處理方便废境，數(shù)據(jù)庫(kù)操作簡(jiǎn)單畜挨，中間件擴(kuò)展靈活，性能夠用……當(dāng)然噩凹，任何事情都有兩面性巴元，Django也有自己的問題，比如并發(fā)不是Django的強(qiáng)項(xiàng)驮宴，ORM的封裝雖然強(qiáng)大逮刨，但是也基本上給將來想做DAO層的二次開發(fā)帶來比較大的難度，事實(shí)上在后來數(shù)據(jù)庫(kù)切分的時(shí)候，Django的不足就比較明顯了修己，這個(gè)問題如果后面有時(shí)間再來慢慢記錄恢总。 但不管怎樣，我仍然相信Django是中小型項(xiàng)目起步階段的首選睬愤。

踩在巨人的肩膀上——［系統(tǒng)部署］

Web Server系統(tǒng)的選型確定了片仿，接下來一件事，就是系統(tǒng)部署架構(gòu)了尤辱。LAMP仍然是圣經(jīng)王道砂豌，但是操作起來自然是LNMP，中小型項(xiàng)目你想不用都難光督，因?yàn)樗褪沁@么好用阳距。因?yàn)樾枰灰祝琈ySQL選擇InnoDB是必須的结借；又因?yàn)轫?xiàng)目展示內(nèi)容的特性筐摘，擁有強(qiáng)大的靜態(tài)緩存和反向代理能力的Nginx也是當(dāng)仁不讓的選擇。

好映跟，菜都湊齊了蓄拣，在哪炒呢，自己家建廚房還是上館子店讓別人代勞呢 努隙？可能第一反應(yīng)是自己家炒嘛球恤！數(shù)據(jù)什么的都在自己手上，進(jìn)了機(jī)房門就能直接調(diào)試荸镊，舒舒服服咽斧，多好」妫可是张惹，隨之而來的問題呢：電源，空調(diào)岭洲，布線宛逗，監(jiān)控，報(bào)警盾剩，宕機(jī)維護(hù)雷激，擴(kuò)容……Oh No，想都不敢想告私。再說屎暇，這些不要錢么？拋開這些不談驻粟，光是一個(gè)外網(wǎng)訪問帶寬就能讓你肉疼根悼。所以，云托管。

好挤巡，問題又來了剩彬，選哪個(gè)云？七牛云矿卑，阿里云襟衰，百度云……天邊飄來很多云，每家似乎都有特色粪摘。事實(shí)上瀑晒，在做這個(gè)項(xiàng)目之前我也沒有太多實(shí)際操作云的經(jīng)驗(yàn)，但是簡(jiǎn)單的調(diào)研對(duì)比之后徘意，我的目標(biāo)基本鎖定在七牛和阿里兩家苔悦”嘟龋考慮到整體分布式服務(wù)的支撐和穩(wěn)定性前联，最終選擇了以阿里云作為主業(yè)務(wù)服務(wù)部署端敷鸦，七牛云作為內(nèi)容服務(wù)器部署端相結(jié)合的架構(gòu)窑滞。

1）阿里云為業(yè)務(wù)服務(wù)端云，是因?yàn)槲业臉I(yè)務(wù)服務(wù)器都在阿里云上腹泌，而且阿里云能提供絕大多數(shù)我需要的基礎(chǔ)設(shè)施褐澎，在這個(gè)項(xiàng)目中我用到了以下服務(wù)：

a. 云服務(wù)器ECS：作為項(xiàng)目提供所有服務(wù)器支撐岩臣；

b. 數(shù)據(jù)庫(kù)服務(wù)RDS：作為項(xiàng)目的主業(yè)務(wù)邏輯的數(shù)據(jù)存儲(chǔ)脚牍，選擇MySql向臀；

c. 分布式緩存OCS：作為RDS的前端緩存，為只讀業(yè)務(wù)提供緩存诸狭，減緩RDS壓力券膀；（注意，阿里云的OCS是基于bmemcache的驯遇，所以不能提供Key的遍歷服務(wù)芹彬，這也造成了我們?cè)陧?xiàng)目中期建設(shè)的時(shí)候，不得不額外搭建了自己的Redis緩存服務(wù)器來提供一些必要的服務(wù)支撐叉庐。這個(gè)后續(xù)有時(shí)間細(xì)表舒帮。）

d. 分布式文件存儲(chǔ)OSS：作為B端業(yè)務(wù)主文件存儲(chǔ)，主要存儲(chǔ)圖片和文本文件陡叠；

e. 圖片處理服務(wù)：為B端提供圖片訪問和緩存支撐玩郊；

2）七牛云為內(nèi)容服務(wù)端云，基本作用是提供文件存儲(chǔ)和圖片處理匾竿，最大的原因是以下幾個(gè)：

a. 七牛的CDN向來做的不錯(cuò);

b. 七牛的圖片處理服務(wù)在我看來是頂級(jí)的瓦宜，如果你的業(yè)務(wù)以圖片處理和訪問為主蔚万，七牛是比較好的選擇岭妖；

c. 它每個(gè)月有10G的免費(fèi)存儲(chǔ)和100萬(wàn)次Get/10萬(wàn)次Put流量，免費(fèi)的我干嘛不用。

實(shí)際上昵慌，上述的系統(tǒng)部署和基礎(chǔ)設(shè)施的選用也不是一次到位的假夺，這個(gè)過程也經(jīng)歷了從小到大，從簡(jiǎn)單到復(fù)雜斋攀，前前后后大約2個(gè)月左右的演變過程已卷，雖然談不上演變有多先進(jìn)，但是系統(tǒng)的整個(gè)設(shè)計(jì)過程淳蔼，我處處遵循了開篇時(shí)的那段引子的原則：“先功能再優(yōu)化侧蘸，先簡(jiǎn)單再?gòu)?fù)雜”。后面我會(huì)單起一篇分享一下項(xiàng)目的架構(gòu)是如何一步步發(fā)展和演變的鹉梨。

開始畫圖紙——［業(yè)務(wù)模塊］

如果說讳癌，架構(gòu)選型是找到最合適的設(shè)計(jì)院和工程隊(duì)，系統(tǒng)部署規(guī)劃是找到合適的地皮和基建設(shè)施存皂，那么項(xiàng)目的業(yè)務(wù)模塊設(shè)計(jì)就相當(dāng)于蓋房子之前的要畫設(shè)計(jì)草圖了晌坤。

基本上從大的角度來說，一個(gè)完整的分布式B2C系統(tǒng)所需要的各個(gè)模塊部分是差不多的旦袋，這個(gè)網(wǎng)上有太多的文章可以參考骤菠。但是問題在于，并不是別人的系統(tǒng)就是最適合你自己的：也許別人幾十人幾百人花了幾年搭建的系統(tǒng)疤孕，你拿過來照搬商乎，打死你也做不出來；又或者別人提供的架構(gòu)其實(shí)很多部分對(duì)于你自己的項(xiàng)目來說都是殺雞用牛刀祭阀，根本就是多余的截亦。所以，整體框架可以參考柬讨，但是結(jié)合到具體項(xiàng)目崩瓤，還是必須根據(jù)實(shí)際需要單獨(dú)設(shè)計(jì)。這點(diǎn)上踩官，我并沒有什么太多的創(chuàng)新的部分却桶，更多的工作，是在已知通用業(yè)務(wù)框架上作一些裁剪和修補(bǔ)的動(dòng)作蔗牡，量體裁衣颖系。

B2B2C系統(tǒng)，BBC3大部分這是跑不掉的辩越，具體到每一個(gè)環(huán)節(jié)：

1）商戶端B：

a. 用戶管理嘁扼，權(quán)限管理：商戶信息設(shè)置，權(quán)限控制黔攒，主要體現(xiàn)為交易權(quán)限控制趁啸；

b. 內(nèi)容上傳强缘，內(nèi)容管理：商品內(nèi)容空間的創(chuàng)建，圖片文字?jǐn)?shù)據(jù)上傳不傅，審核狀態(tài)的操作旅掂，已上架信息的CRUD管理和預(yù)覽等等

c. 交易管理：實(shí)時(shí)交易訂單控制，非實(shí)時(shí)交易訂單控制访娶，物流管理等商虐；

d. 消息管理：B2B消息，B2C事件消息管理崖疤；

e. 增值服務(wù)：推廣服務(wù)秘车，反饋服務(wù)等等；

2）平臺(tái)服務(wù)端B：

a. 用戶管理／權(quán)限控制：包括BC兩端用戶和平臺(tái)各模塊管理員的管理控制劫哼；

b. B端內(nèi)容審核服務(wù)：主要負(fù)責(zé)B端內(nèi)容的核查相關(guān)服務(wù)鲫尊；

c. B端內(nèi)容管理服務(wù)：管理B端數(shù)據(jù)，提供B端服務(wù)API沦偎；

d. C端內(nèi)容發(fā)布服務(wù)：主要負(fù)責(zé)內(nèi)容從B到C的轉(zhuǎn)換疫向；

e. C端內(nèi)容管理服務(wù)：主要負(fù)責(zé)C端數(shù)據(jù)Restful API和業(yè)務(wù)API；

f. 業(yè)務(wù)邏輯模塊：主要負(fù)責(zé)處理項(xiàng)目相關(guān)主業(yè)務(wù)邏輯豪嚎，到目前本篇文章成文為止搔驼，已包括四大子模塊，后續(xù)將增加更多模塊：

i) 交易管理

ii) 訂單處理

iii) 洽購(gòu)處理

iv) 競(jìng)價(jià)處理

3）用戶端C：

a. 內(nèi)容管理：主要負(fù)責(zé)數(shù)據(jù)的展示

b. 交易管理：對(duì)應(yīng)于商戶B端侈询，實(shí)時(shí)交易訂單控制舌涨，非實(shí)時(shí)交易訂單控制，物流管理等扔字；

c. 個(gè)人相關(guān)數(shù)據(jù)管理：主要負(fù)責(zé)和個(gè)人相關(guān)聯(lián)的寫數(shù)據(jù)請(qǐng)求

用戶端這部分囊嘉，上述3個(gè)模塊只是從整體上來簡(jiǎn)要說的，實(shí)際上革为，由于項(xiàng)目的跨平臺(tái)跨端口的要求扭粱，具體又要對(duì)Web端和移動(dòng)端做不同程度的定制化處理。比如在數(shù)據(jù)安全性上震檩，Web端和移動(dòng)端需要不同的處理辦法琢蛤。在前端緩存上，移動(dòng)端App不像Web Browser那樣自己本身能提供一定的緩存機(jī)制抛虏，需要單獨(dú)做一些處理博其。

上面這些模塊的劃分，也僅僅是從大概念上做的比較粗粒度的迂猴，具體到每一項(xiàng)慕淡，都可以單獨(dú)拿出來寫，很多其實(shí)絕大多數(shù)書上和網(wǎng)上都有足夠的參考沸毁，我并不能一一枚舉峰髓，但是這其中仍然有一些模塊是我覺得非常值得拿出來落成文字傻寂，也是我們花了大部分精力研究和完善的：1）交易訂單的處理，對(duì)于一個(gè)電商平臺(tái)來說是重中之重儿普，2）App前端緩存處理。3）系統(tǒng)各模塊的橋接處理掷倔。

后面我會(huì)結(jié)合系統(tǒng)架構(gòu)的演變細(xì)節(jié)眉孩，仔細(xì)介紹前面提到的這幾個(gè)部分我們?cè)?jīng)遇到什么坑，埋了什么坑勒葱，又是怎么填的坑浪汪。

紅花都得有綠葉襯——[系統(tǒng)外圍輔助業(yè)務(wù)]

一個(gè)完整的項(xiàng)目系統(tǒng)，除了提供主業(yè)務(wù)功能的主服務(wù)系統(tǒng)之外凛虽，還得額外考慮必要的輔助業(yè)務(wù)系統(tǒng)死遭。對(duì)于我們這個(gè)項(xiàng)目而言，必要考慮的包括：

1）監(jiān)控服務(wù)：主要負(fù)責(zé)對(duì)系統(tǒng)業(yè)務(wù)服務(wù)器的監(jiān)控凯旋，以及主要業(yè)務(wù)指標(biāo)的顯示操作等管理呀潭。大部分情況下，阿里云自身的ECS服務(wù)器和RDS監(jiān)控已經(jīng)能滿足最基本的監(jiān)控需求至非，但是仍然還有一部分和業(yè)務(wù)密切相關(guān)的監(jiān)控是必須要額外建立的钠署，比如所有外部接口的頻次統(tǒng)計(jì)，所有業(yè)務(wù)數(shù)據(jù)的實(shí)時(shí)統(tǒng)計(jì)荒椭，以及核心業(yè)務(wù)事件的追蹤等等谐鼎。這其中，接口統(tǒng)計(jì)和事件跟蹤趣惠，又可以在前端和后端兩部分分別完成狸棍，前端我們依賴于大量的第三方支撐，以免自己重復(fù)造輪子味悄。目前使用的有：Web端－百度統(tǒng)計(jì)草戈，移動(dòng)端－友盟統(tǒng)計(jì)；后端部分侍瑟，我們是在Django的中間件層猾瘸，自己實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的API中間件來實(shí)現(xiàn)全服務(wù)層的指標(biāo)監(jiān)控。這部分考慮到性能的因素丢习，需要完全建立在緩存之上牵触，一開始我們想在阿里自己的OCS上做文章，結(jié)果后來發(fā)現(xiàn)OCS在key的支持上非常的弱咐低，沒辦法只好自己搭建了Redis緩存服務(wù)器來為這層中間件服務(wù)揽思。但是后來的實(shí)踐證明越來越多的系統(tǒng)內(nèi)部服務(wù)需要依賴在Redis之上，所以漸漸的OCS退化為只是單純的為C端用戶提供只讀數(shù)據(jù)緩存這一項(xiàng)單一功能了见擦。

2）財(cái)務(wù)系統(tǒng)：主要負(fù)責(zé)對(duì)交易數(shù)據(jù)的歸總和財(cái)務(wù)接口钉汗。B2B2C和C2C之間的最大區(qū)別羹令，是除了常規(guī)的對(duì)賬操作之外，還有必要的分賬操作损痰，在我們項(xiàng)目的初期階段福侈，考慮到業(yè)務(wù)的規(guī)模和復(fù)雜度，目前分賬操作是線下的卢未，但是我們提供了必要的基礎(chǔ)服務(wù)給對(duì)賬和分賬操作提供基本支撐肪凛。

3）地推服務(wù)系統(tǒng)：這是和項(xiàng)目運(yùn)營(yíng)部門的實(shí)際需求掛鉤的，同樣建立在Redis緩存服務(wù)至上辽社，在此暫不細(xì)表伟墙；

4）客服系統(tǒng)：主要提供平臺(tái)和品牌的反饋?zhàn)粉櫍灰赘櫶幚淼葮I(yè)務(wù)提供可視化數(shù)據(jù)服務(wù)滴铅，提供客服溝通效率戳葵；

5）日志處理系統(tǒng)：主要負(fù)責(zé)維護(hù)系統(tǒng)每天的日志輸出。

6）系統(tǒng)自動(dòng)化部署服務(wù)：實(shí)際上汉匙，在我看來拱烁，系統(tǒng)自動(dòng)化部署完全不應(yīng)該和以上這些“低級(jí)別”服務(wù)并列。因?yàn)樗娴暮苤匾洌诖笮凸玖诎穑到y(tǒng)的自動(dòng)化集成，發(fā)布和部署甚至是一個(gè)獨(dú)立的大部門而存在绎秒。我從一開始就對(duì)這個(gè)部分很頭疼浦妄，原因是之前的工作經(jīng)歷絕大部分情況下是接手已經(jīng)成型的產(chǎn)品線，很多自動(dòng)化框架都已完成见芹，接受團(tuán)隊(duì)只需要依葫蘆畫瓢對(duì)新功能進(jìn)行添補(bǔ)就可以剂娄。而對(duì)于現(xiàn)在這種完全從零開始的產(chǎn)品，一開始對(duì)自動(dòng)化框架進(jìn)行規(guī)劃是再合適不過的玄呛≡呐常可是事實(shí)也是不完美的，對(duì)于我們這樣的初創(chuàng)團(tuán)隊(duì)徘铝，一開始人手嚴(yán)重不足耳胎，單是為了以上提到的系統(tǒng)模塊就已經(jīng)讓大家忙不過來了，所以自動(dòng)化部署和發(fā)布這部分一直拖延惕它，直到項(xiàng)目上線前的后期階段才初步嘗試怕午。我們使用的是Fabric部署框架，結(jié)合大量的Shell腳本淹魄，主要完成后端服務(wù)器的代碼管理郁惜，打包，遠(yuǎn)程分發(fā)以及做些發(fā)布前的必要的Config甲锡。

2016年2月12日兆蕉，完稿于吉隆坡.