雷鋒網(wǎng)按：本文由數(shù)據(jù)科學家董飛翻譯自Erik Duindam發(fā)表在Medium上的文章《How I built an app with 500,000 users in 5 days on a $100 server》，公號：董老師在硅谷。

最近Pokémon Go風靡全球，讓蘋果和任天堂也坐地賺翻，很多開發(fā)者也坐不住了，絞盡腦汁想怎么做相關開發(fā)也跟上潮流。這一篇就是一個老司機講述在5天獲取50萬Pokémon GO粉絲的APP是怎么做出來的？（跑在100刀的服務器上），談到MVP（minimum viable product，最簡可行產(chǎn)品）、敏捷開發(fā)、流行框架、技術選型、規(guī)模瓶頸，筆者覺得總體實戰(zhàn)還是蠻強的，就翻譯了推薦給大家。

現(xiàn)在創(chuàng)業(yè)公司都是要做MVP而不去考慮太多技術的擴展性。有種說法，強調(diào)要先把產(chǎn)品做出來，只要到時業(yè)務規(guī)模能頂?shù)米?，就不該浪費時間和精力在技術上。而你要做的是測試假設，驗證市場和獲取關注，以后才考慮規(guī)模化。但這種盲目導致了一些可怕的失敗，下面這個故事會提醒大家。

最近Jonathan Zarra做了個基于Pokémon GO的APP叫GoChat，他在5天就做出了Pokémon GO聊天工具，100萬的用戶。他馬上跑去見VC談融資和增長故事。但緊接著GoChat就掛了。很多用戶流失，而他們花的錢也追不回，這簡直是個恥辱。

有個報道說Zarra在100萬用戶的時候度過了艱難時光。他從沒想過這么多用戶。他通過MVP理念搭建APP，后來才考慮規(guī)?；?。他當時找了合同工去補救一些性能問題。合同工提到服務器成本是4000刀，我假想硬件是4000刀，包括虛擬機和網(wǎng)絡流量成本。

我之前設計并搭建了上億用戶的Web平臺。我覺得對于一個聊天App來說4000刀根本沒必要，就算對于MVP來說。這只能說這個App的服務端技術很爛。搭建一個高效，可擴展的系統(tǒng)對于月活百萬來說不容易，但也不是說做一個建立在云端便宜服務器上服務相當多用戶的系統(tǒng)有多難。關鍵是在搭建MVP的時候多想想，做正確的選擇。

GoSnaps：5天50萬用戶，100刀一個月的服務器成本

跟GoChat類似，我上周也開發(fā)了一個Pokémon Go粉絲App叫GoSnaps。可以分享Pokémon Go截屏和地圖。可以理解成Pokémon Go里面的Instagram/Snapchat。GoSnaps第一天就漲了6萬粉，第二天16萬，五天后就是50萬獨立用戶。現(xiàn)在上傳了15萬到20萬的snaps。任何時刻都是上千并發(fā)用戶，我也搭建了圖像識別的軟件去自動檢測上傳圖片是不是Pokémon GO相關，以及圖片的大小調(diào)整工具。我用Google的云服務，一個月100刀，加上便宜的Google云存儲來保存圖片，現(xiàn)在看起來性能還不錯。

GoChat和GoSnaps的技術比較

我們可以比較GoChat和GoSnaps。兩個APP都是每秒生成很多請求去聊天或者拿到地圖某區(qū)域的圖片。這里有數(shù)據(jù)庫或者基于搜索引擎的GEO查詢，要么選經(jīng)緯度的多邊形或者是特定點。我們使用多邊形并在某人移動地圖時去發(fā)出請求。這些類型的查詢是數(shù)據(jù)庫中很重的操作，特別是排序和過濾的組合。我們每秒都有上百個這樣類型的請求，GoChat應該也差不多。

GoChat不同的是，每秒都要獲取和發(fā)布很多聊天信息。大概每秒600次，包括地圖和聊天信息。這些聊天信息很小且可以通過一個socket連接來搞定，但需要經(jīng)常發(fā)布到其他聊天者中去。這就需要合適的選型，如果選錯就是災難。

GoSnaps另一方面需要每秒獲取很多圖片和贊。這些snaps在服務器上存著，老的snap也是相關的，而老的聊天不是。真正的圖片文件是在Google的云存儲上，這種請求圖片文件數(shù)量不是我的顧慮。Google云很可靠，我擔心的是在地圖上請求的snaps，GoSnaps有個圖片識別軟件去查看所有上傳的特征，檢查圖片是否與Pokémon GO相關。然后重組了圖片并發(fā)送到云存儲。這些考慮到CPU和帶寬都是很重的操作。比復制發(fā)布小的聊天信息要重，但沒那么頻繁。

結(jié)論是這兩個APP在架構(gòu)復雜性上都很類似。GoChat處理更多小的消息但GoSnaps處理大圖片和更重的服務端操作。設計這兩個App的架構(gòu)需要不同的方式，但復雜度類似。

我是怎么在24小時內(nèi)搭建可擴展的MVP

GoSnaps是作為MVP來開發(fā)的，不是一個商業(yè)化成熟的產(chǎn)品。就是在24小時內(nèi)完成。我用了編程馬拉松中NodeJS項目，MongoDB數(shù)據(jù)庫也沒任何緩存。沒有Redis，Varnish，也沒有復雜Nginx設置。這個iOS App就是用Objective C寫成的，還有借用了些蘋果地圖相關程序代碼。

我愿意考慮MVP去做一個功能的APP，越快越好，不管技術后端質(zhì)量。圖片存哪里？就是MongoDB數(shù)據(jù)庫。這也不需要什么配置和代碼。怎么在范圍內(nèi)查詢Snaps和拿到最多的like數(shù)？就是在整個上傳的列表中跑一個MongoDB的查詢并且在一個數(shù)據(jù)庫連接中去做一個查詢。但所有的這些都可能把我的APP和功能給弄砸。

查看那些我需要拿到Snap的查詢：“找到在多邊形[A、B、C、D]這個區(qū)域內(nèi)的所有Snaps，去掉一些舍棄的snaps，去掉一些已經(jīng)用過的，根據(jù)贊的數(shù)量，合法的Pokémon Go，以及新鮮度排序這在小規(guī)模下是可以的，但在很大的負載下將是災難。即使我把上面的查詢變成只有三個條件的操作，還是很恐怖。因為這不是數(shù)據(jù)庫應該這么用的。數(shù)據(jù)庫每次只能查詢一個索引，而這種GEO查詢是辦不到的。如果你沒很多用戶也就算了，但像做到Gochat這種掛了就說不過去了。

我怎么做的呢？在把CPU計算很重的圖像識別和大小重組后，這種處理之后的照片就上傳到Google的云存儲上。這樣服務器和數(shù)據(jù)庫在圖片請求時都不會受影響。數(shù)據(jù)庫要考慮數(shù)據(jù)，而不是圖片。這也節(jié)約了服務器。在數(shù)據(jù)庫方面，我把snaps分成不同的類型：所有snaps，最歡迎的snaps，最新的snaps，最新可用的snaps等。當一個snap加入后，被喜歡或者標記成丟棄，代碼會檢查是不是屬于某一類集合并做適當操作。這樣代碼可從準備好的集合中去查詢而不是去在一個巨大的列表中去跑復雜查詢。這就把數(shù)據(jù)從邏輯上隔離劃分到桶中。也可以去排序查詢做地理關聯(lián)，把選擇數(shù)據(jù)給簡化了。

這些多余的事情花了多久呢？大概2、3個小時吧。為什么我要先做這些，因為這些就是我做事的方式，我認為這個APP會成功，也沒有理由說開發(fā)了一個APP就假設它不成。如果我的APP獲得一些口碑但因為技術不好而掛了，我是不能容忍的。我把最小可見規(guī)?；脑瓌t植入到APP中。這就是快樂和痛苦的區(qū)別，也是成為一個APP MVP中的一環(huán)。

為你的MVP選擇正確的工具

如果我用一個更慢的編程語言或者大的框架，我可能需要更多服務器。如果我使用PHP跟Symfony，Python跟Django、Ruby on Rails，我可能花整天去解決APP中最慢的部分或者增加服務器。這些語言和框架在很多范圍內(nèi)都很棒，但對于很低成本的服務預算還是不合適的。也許是因為很多代碼都是用在把數(shù)據(jù)庫記錄映射到框架的邏輯中。這會對CPU很有害，下面給個例子。

之前說過，GoSnaps使用NodeJs作為后端語言和平臺，這樣快速高效。我使用Mongoose作為ORM（對象映射模型）讓MongoDB更像個程序員的寫法。

我也不是Mongoose專家，知道這個庫有很多代碼，所以Mongoose有缺陷的。在上周末，我們的服務器4個NodeJS進程每個都是90%的CPU，這對于800-1000的并發(fā)用戶是不能接受的。我意識到Mongoose在獲取數(shù)據(jù)的時候做了些事情。我選擇使用Mongoose的更輕量的功能去獲取普通JSON而不是復雜的Mongoose對象。

改了之后，NodeJS進程降到了5-10%的CPU使用率。所以說知道你代碼實際做的事情很重要，把負載降了90%。想象如果是個復雜的庫，比如Symfony和Doctrine，僅僅是執(zhí)行這些代碼就需要花很多CPU核，更不要說數(shù)據(jù)庫成為瓶頸了。

選擇一個簡潔和快速的語言對于擴展性很重要，除非你在服務器上花費很多。選擇一個有很多有用庫的語言更重要，因為你想快速搭建MVP。NodeJS，Scala和Go都是符合這些條件的好語言。他們提供了很好的工具和性能。像PHP和Java本身也不慢，但由于大型框架和代碼庫一起用讓應用非常笨重。這些語言對于面向?qū)ο蟮拈_發(fā)和很規(guī)范測試的代碼是很好，但不夠快和方便擴展。我這里也不想去引入編程語言之爭，個人喜歡Erlang，但在MVP中沒用過。

我過去Cloud Games的創(chuàng)業(yè)經(jīng)歷

幾年前，我創(chuàng)立Cloud Games，是HTML5的游戲運營商。開始時候，是B2C的網(wǎng)站，我們花了很大精力去獲取用戶而且?guī)讉€月后也拿到100萬的月活用戶。那時候，我使用PHP、Symfony2、Doctrine和MongoDB作為簡單精煉的基礎結(jié)構(gòu)。我也在Spil Games工作過，當時2億的月活，使用的是PHP，后來遷移到Erlang。當Cloud Games成長到10萬的月活時，我們開始關注Doctrine和MongoDB的服務器瓶頸，因為在PHP庫有很大負載。我也正確了設置了MongoDB，索引和查詢，但服務器在處理能力上還是很難受，后來又做了PHP的APC緩存。

因為Cloudgame.com依舊以靜態(tài)為主。我花了幾天遷移MVP到NodeJS和Redis。同樣的設置，不同的語言。這使負載降低了95%。里面有很多要跟PHP庫打交道的，但一個最小化的NodeJS比最小化的PHP要容易得多。特別是MongoDB和前段代碼都是100%的JavaScript，就像NodeJS，沒了框架和庫的PHP簡直是另一種語言。

我們需要一個干凈的環(huán)境，因為我們是自己投錢de早期創(chuàng)業(yè)團隊。Cloud Games后來做得不錯并且依然基于NodeJS的高效架構(gòu)上。我們可能沒有管理過一個更節(jié)省的技術結(jié)構(gòu)，我們也經(jīng)歷過很多坎坷的創(chuàng)業(yè)歷程。設計一個低成本、高擴展的架構(gòu)對成功非常關鍵。

MVP和擴展性可以共存

如果你的App因為一些熱點和媒體曝光有機會爆發(fā)式增長，一定要考慮你的MVP的擴展性。最小可行產(chǎn)品和可擴展的技術是可以共存的。沒有比搭建一個成功App但后來因為技術原因失敗更慘的事情了。Pokémon Go自己也有很多問題，但它很獨特而且成長足夠快。而小型創(chuàng)業(yè)公司就沒有那么奢侈了。時機就是一切，100萬GoChat用戶和50萬GoSnaps用戶的不同結(jié)局就證明了一切。

轉(zhuǎn)載請聯(lián)系授權并保留出處和作者，不得刪減內(nèi)容。

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。