獵雲網注：如果你的應用有機會因炒作或媒體報導而呈指數級增長，請務必將可擴展性視為MVP的一部分。最小可行產品和可擴展技術的原則是可以共存的，沒有什麽比建立一個本應該成功卻因為技術問題而導致它失敗的應用程式更令人傷心。文章來源：CSDN（ID：CSDNnews），作者：Erik Duindam，作者：虎說。
創業公司似乎普遍認為，你應該建立一個MVP（最低可行產品），而不必過多關注技術的可擴展性。
我多次聽說，只要你的商業模式能夠大規模運作，你就會活得很好，而不必浪費時間和金錢來打造技術可擴展的產品——可擴展性是以後的問題。
不幸的是，這種有點盲目的信念可能會導致很可怕的失敗，例如，Pokemon GoChat。
我想Pokemon GoChat的創造者Jonathan Zarra就吃夠了教訓。通過為Pokémon GO粉絲製作聊天應用程式，他在5天內獲得了100萬用戶。
近期，他一直在與風險投資公司交談，試圖介紹他的發展規劃並通過他的應用獲利。不幸的是，不久後GoChat卻倒閉了。
後來我才知道，Zarra很難為託管1M活躍用戶所需的伺服器付費，他從沒想過會有那麽多用戶。他將此應用程式構建為MVP，後來才關注可擴展性，但是他失敗了。
於是Zarra聘請了Upwork的承包商解決了很多性能問題，承包商表示伺服器成本約為4000美元。那是2016年，我認為他說的不是4000美元的硬體，而是每月或每年4000美元的虛擬伺服器和流量成本。
在我的職業生涯中，我一直在為數億活躍用戶設計和構建網絡平台。
我可以說，對於聊天應用中的1M用戶來說，4000美元是完全不靠譜的金額，即使是MVP，這意味著應用程式的伺服器技術設計很差。為月活達到數百萬用戶構建經濟高效、可擴展的系統並不容易。
但是，通過利用雲上的廉價伺服器來處理相當數量的用戶卻沒有很複雜，這些只需要在構建MVP時考慮到。
1、GoSnaps：5天內獲得100萬用戶，每月只需100美元的伺服器
與GoChat類似，我最近也推出了一款名為GoSnaps（針對PokemonGO粉絲）的應用程式。
GoSnaps是一款在地圖上分享PokémonGO截圖和影像的應用程式，GoSnaps第一天增長到6萬用戶，第二天增加了16萬用戶，5天后增加到了100萬用戶，它現在有150-200k上傳的快照。它在任何時間點大概都有大約1000個用戶同時在線。
我建立了影像識別程式，以自動檢查上傳的影像是否與PokémonGO相關，並調整上傳影像的大小。我在一台價格為100美元/月的中型谷歌雲伺服器上運行整個設定，再加上（廉價）谷歌雲存儲用於存儲影像。
2、GoChat和GoSnap的技術比較
我們來比較GoChat和GoSnaps，這兩個應用程式都能基於地理位置，每秒觸發大量請求以獲取聊天/影像。
一般而言，地理空間查找可以是經緯度位置的多邊形，也可以是特定點。我們選擇前者，每當有人移動地圖時都會觸發此請求。
這些查詢是對數據庫的重複操作，尤其是與排序或過濾相結合。GoSnap每秒都會收到這種類型的搜索請求數百次，GoChat可能也是如此。
GoChat的獨特之處在於它必須每秒獲取並發布大量聊天消息。此前曾對外聲稱整個應用程式每秒有600個請求，這600個請求是地圖請求和聊天消息的組合。
這些聊天消息很小，可以通過簡單的套接字連接完成，並分發給其他聊天者。通常來說，這種頻繁分發是可以通過正確的設定進行管理的，但對於類似MVP的糟糕設定卻是災難性的。
而GoSnaps每秒都會獲取和“點讚”許多影像。由於舊的照片也有一定的相關性，所以照片需要堆積在伺服器上。
由於實際影像檔案存儲在谷歌雲端存儲中，因此作為開發人員，我不需要考慮所請求的影像檔案的數量。谷歌雲可以處理這個，我相信谷歌。
GoSnaps擁有影像識別軟體，可在所有上傳中查找圖案，以查看圖片是否與Pokemon有關。它還會調整影像大小並將其發送到雲存儲。這些都是在CPU和帶寬方面比較的繁重操作，比分發一些聊天消息更重，但頻率較低。
我的結論是這兩個應用程式在可伸縮性複雜性方面非常相似。
GoSnaps處理更大的影像和更重的伺服器操作，GoChat則處理更多小消息。為這兩個應用程式設計架構時需要兩套稍微不同的方法，但同樣複雜。
3、我是如何在24小時內構建可擴展的MVP的？
GoSnaps是作為MVP構建的，它不是專業的商業產品，它是在24小時內完成。
我為hackathons採用了NodeJS模版，並使用了MongoDB數據庫且沒有任何形式的緩存。沒有Redis，沒有Varnish，也沒有花哨的Nginx設定。iOS應用程式是使用原生的Objective-C代碼構建的，其中一些是借用應用程式Unboxd的Apple Maps相關代碼。
那麽我是如何讓它可擴展的呢？
假設我們先不管技術後端品質，MVP只是一場與時間競賽，以盡快建立功能性應用程式。
我會把我的影像放在哪裡？在MongoDB數據庫中，因為它不需要配置，也不需要代碼。查找快照只需在整堆上傳的快照上運行一個簡單的MongoDB查詢即可。一個數據庫集合上只有一個數據庫查詢。但，所有這些都會破壞我的應用程式和應用程式的功能。
因為查看快照必須運行以獲取這些快照的查詢：“查找位置多邊形[A，B，C，D]內的所有快照，不包括標記為濫用的快照，不包括仍在處理的快照，按數量排序喜歡，由有效的PokemonGO照片組成。”
這適用於小型數據集，但在嚴重負荷下，這都是災難性的。即使我將上述查詢簡化為僅包含三個條件/排序操作，也會是災難性的。
為什麽？因為這不是數據庫的使用方式。數據庫應該一次僅查詢一個索引，這對於這些地理空間查詢是不可能的。如果你沒有很多用戶，你就會僥幸成功，但是一旦你獲得成功，你就會失敗，像GoChat一樣。
那我做了什麽呢？
應用影像識別並進行大小調整後，將已調整大小的影像上傳到Google Cloud Storage。這樣，伺服器和數據庫就不會因請求影像而受到攻擊，而且可以節省許多伺服器。
在數據庫方面，我將快照分成幾個不同的集合：所有快照、最喜歡的快照、最新的快照、最新的有效快照等等。每當快照被添加，代碼會檢查它是否屬於其中一個集合並相應地采取行動。
這樣，代碼可以從準備好的集合中查詢，而不是在一大堆亂七八糟的情況下運行複雜的查詢。它只是將數據邏輯分成一些簡單的存儲桶。並且允許我通過一個排序操作僅查詢地理空間坐標，而不是如上所述的複雜查詢。簡單來說：它可以直接選擇數據。
我花了多少時間在這方面上？2到3個小時。
為什麽我這樣做呢？因為我認為我的應用程式會成功。如果我的應用程式成為爆款，然後由於糟糕的技術而死亡，我將無法入睡。我將最小可行的可伸縮性原則融入我的應用程式。這是我認為應該成為應用MVP的一部分。
4、為你的MVP選擇合適的工具
如果我用較慢的編程語言或大框架構建GoSnaps，我將需要更多的伺服器。如果我會使用PHP或者使用Python，或者Ruby on Rails，我會花費很長時間來修複應用程式的性能問題或添加伺服器。相信我，我以前做了很多次。這些語言和框架在許多場景中都很棒，但對於伺服器預算較低的MVP則不然。讓我舉一個例子說明這實際上有多重要。
如上所述，GoSnaps使用NodeJS作為後端語言/平台是快速和有效的。
我使用Mongoose作為ORM來使MongoDB直接工作，儘管我不是Mongoose專家，但我知道這個庫本身就有很大的代碼庫。在上周末的某個時刻，我們伺服器上4個NodeJS進程分別以90％的CPU運行，這對800-1000個並發用戶來說是不可接受的。我意識到它必須是Mongoose在用我獲取的數據做事情，顯然我只需啟用Mongoose的“lean（）”函數來獲取普通的JSON對象而不是神奇的Mongoose對象。在更改之後，NodeJS進程降低到大約5-10％的CPU使用率。我認為了解代碼實際執行的操作的簡單邏輯非常重要。
選擇精簡和快速語言對於可擴展性非常重要，而且還能為伺服器節省了大量資金。選擇具有大量有用庫的語言甚至更重要，因為你希望快速構建MVP。NodeJS、Scala和Go是涵蓋這兩個要求的好語言，它們提供了許多具有良好性能的好工具。像PHP或Java這樣的語言本身並不一定很慢，但通常與大型框架和代碼庫一起使用，這會使應用程式變得繁重。這些語言非常適合乾淨的面向對象開發和經過良好測試的代碼，但不適用於快速和廉價的可擴展性。我不想開始一個大的編程語言論證，所以讓我隻說這是主觀的和不完整的。我個人喜歡Erlang，絕不會將它用於構建MVP。
5、創業公司Cloud Games的經歷
幾年前，我聯合創辦了一個HTML5遊戲發行商Cloud Games。
當我們開始時，我們是一個專注於MENA地區的B2C遊戲網站，我們花了很多精力來獲得用戶，並在幾個月後達到了每月1M活躍用戶（MAU）。
當時，我在一個非常簡單和精簡的設定中使用了PHP、Symfony2、Doctrine和MongoDB。我曾經為Spil Games創造過2億MAU，當時使用PHP然後轉移到Erlang。
在Cloud Games達到大約100,000 MAU之後，由於這些PHP庫的巨大開銷，我們開始看到Doctrine和MongoDB真正的痛苦。我確實以正確的方式設定了MongoDB、索引和查詢，但是伺服器很難處理所有代碼，接著我使用PHP的APC緩存等等。
由於cloudgames.com是靜態的，我可以在幾天內將MVP遷移到NodeJS和Redis。類似的設定，不同的語言，導致負載立即減少了約95％。當然，這與避免使用PHP庫而不是實際語言有關。但是簡約的NodeJS設定比簡約的PHP設定更有意義，特別是因為MongoDB和前端代碼也是100％JavaScript，就像NodeJS一樣。沒有框架和庫的PHP只是另一種語言。
我們需要這種便宜的設定，因為我們是一個自籌資金的早期創業公司。
Cloud Games現在表現不錯，仍然基於經濟高效的NodeJS架構。考慮到我們作為創業公司經歷了一段非常艱難的時期，我們可能無法通過更昂貴的技術設定取得成功。設計低成本、可擴展的架構對於成功至關重要。
6、MVP和可擴展性可以共存
如果你的應用有機會因炒作或媒體報導而呈指數級增長，請務必將可擴展性視為MVP的一部分。
最小可行產品和可擴展技術的原則是可以共存的，沒有什麽比建立一個本應該成功卻因為技術問題而導致它失敗的應用程式更令人傷心。
香港九龍灣馬來街興發大廈15樓D室