李小年
•2015-04-22 11:30:51 •
科技 8
雲移動應用
餓了麼原來有乙個機房，差不多有兩三百臺機器。但是每個月的業務都在漲，所以運維部門很頭疼，每個月都要採購裝置、上架裝置。機房滿了再部署乙個機房，整個週期又很強，最後不得已把服務部署在雲機房。
每年應用數都在不斷地增長。我前兩天向我們開放平台的同事要了乙個資料，註冊的開發者有一兩百萬，然後活躍的開發者，也就是乙個月內還在經常地不斷上傳應用的這些的廠商，也有達到了20多萬。由此可見，整個行業新的應用是非常非常多的。
那麼大家在創業的過程當中，也遇到了各種各樣的挑戰。有產品上的挑戰，產品同質化，然後流量成本也很高，大家可能要去各個電子市場買流量。然後運營成本也很高，比如說你去拉乙個新使用者，新使用者的成本是越來越高。技術上的挑戰，往往會被忽視。
問題一：流量突然暴增，擴充套件性不足
有一家客戶，他在一周內流量暴漲，連自己都沒有想到在一周內從乙個基本上沒有什麼人用的應用，突然變成了全國人民都非常喜愛用的乙個應用。然後一周內dau就突破了兩百萬。他們的伺服器可能就幾台，他們的程式設計師可能就幾個人。那麼面對著突然到來的流量暴增，技術人員壓力非常大。
我去訪談的時候我坐在他們旁邊，跟技術人員去聊，他說我都好幾天沒有睡覺了，然後因為流量暴漲所帶來的各種各樣的技術問題，在一兩天裡面集中地爆發出來，流量暴漲、程式的bug，被無數人使用之後各種程式bug也會出來。那麼效能問題、架構可擴充套件性問題等等的暴露出來了。
我把第乙個問題列成是業務訪問短時間內暴漲、技術架構彈性不足，導致伺服器壓跨。乙個是說高效能的設計不足，另外是擴充套件性不足。還有就算擴充套件性是足的，那麼幾天裡面的流量暴漲，面臨的乙個問題是說我採購伺服器也沒有那麼快。按照我們常規的採購伺服器的流程的話，可能我去買伺服器、下單，就算按照快的，我在中關村裡面去買乙個伺服器、下單，等把它能夠上架可能也需要幾天工夫，但是在這幾天裡面已經是擋不住了。
另外乙個情況，還有一類企業是這樣的。就是每個月的訪問資料都在漲，也就是說每個月都漲dau漲個10萬。然後這樣的一些公司的運維的同事也很苦逼，每個月都在採購裝置、上架裝置，採購裝置、然後上架裝置，不斷地做著重複性的勞動。這樣的勞動對他來說，一方面是感受到公司快速發展帶來的喜悅，另外一方面也是在不斷地重複性的勞動，他本身的自我的價值認知是不高的，因為一直在做這樣的一些事情。
解決辦法：部署高質量的雲主機
高質量的雲主機。雲的乙個普遍的特性，就是滑鼠點幾下、機器就拿到了。可能是500臺，也可能是1000臺。這樣對於移動應用
的好處不言而喻。你的業務量漲了，你馬上可以把機器部署出來，為了達到快速部署，我們有乙個映象的能力。比如說你是web服務的話，我可以把第一台的web而做個映象，然後買一百臺機器，然後一百臺快速的進行部署，整個部署的速度也是非常快的。
實際的情況呢，從北京的機房到我們上海的雲機房，通過vpn打通之後，資料庫的延時是60毫秒，遠遠超出大家對這個事情的預期。
問題二：安全問題，總有幾個「友商」不太喜歡你的應用
社會很大，總有幾個廠商不太喜歡你們的應用。那麼這樣的情況下，ddos的攻擊，目前的情況來看是越來越頻繁地在出現，而且花樣也越來越多。以前說的最多的是ddos攻擊，現在cc攻擊、主機入侵、木馬植入這種情況越來越多。
還有新的一種情況，在我們o2o裡面是比較明顯的，就是o2o的這些資訊平台都很關注它的上面的商家的資訊。那麼同類應用出來的時候，總是想把這樣的商家的資訊給扒過來，這樣的情況對於o2o的應用來說也是不太能忍，他們也會來求助我們有沒有防扒的一些手段。
還有安全防護。尤其舉辦重大活動的時候，比如說餓了麼要舉行乙個美食街，舉辦重大活動的時候被攻擊、被打趴下，那這個業務基本上沒有辦法幹了。
它整個的反應是很快的。剛開始也沒有這麼快，我們已經打磨挺長時間了，現在可以做到幾秒內馬上就可以進行響應。前陣子，有一次大的攻擊，是500g流量，對我們的乙個機房進行攻擊，它快速作出了響應，幾秒內就把攻擊流量轉移到另外的乙個地方去了。那麼其他的流量都能夠正常進來，我們所有的業務都能夠正常的去運作。像這樣乙個問題，如果說你不是放在雲機房的話，可能碰到這樣的情況還是挺棘手的。
「大禹」，「大禹」這個防禦體系跟「宙斯盾」有點不太一樣。「宙斯盾」是在機房前頭加了乙個防禦盾，誰來打我，我就把流量乾掉。那麼「大禹」是說我在全國有400多個接入點，我在網域名稱解析的時候就是就近解析到某乙個節點去的。那麼再通過那些節點再到我們的雲機房。
當有使用者來打擊的時候，網域名稱解析、我可能把它解析到某個oc節點上，它打趴下乙個節點，我其他的節點都還是正常的。它打趴下哪乙個節點都沒有關係。那麼我們這套的「大禹」的分布式的防禦系統，最高可以支援2t的ddos攻擊，所以這個容量已經是非常高了。
今天要講的從35萬到600萬訂單的應用其實就是滴滴打車。
滴滴打車，2023年和快的死磕的時候，其實拼的、燒的是錢。但是拼的是他們的後台的伺服器。當時的情況就是誰扛不住、那誰就輸了。
那麼這種架構是怎麼實現出來的，羅馬不是一天建成的，但是滴滴打車這種架構也不是一下子就做成了的。
比如說出現個lvs單機故障，也就是單點，整個乙個系統的關鍵節點出現問題，乙個主件掛掉、那麼整個路徑就全部掛掉。還有乙個就是儲存系統的故障，然後還有網路故障，交換機流量滿了。因為當時不是bgpip的，所以說在不是bgpip的，在跨網、跨運營商的時候，在流量高的時候就會出現丟包率高、延時高，使用者體驗就下降了。
還有乙個就是webserver扛不住，他們當時webserver用了很多，有狀態的，就導致它需要擴容的時候根本沒有短期內把它擴上去，就機器都加不上去。還有就是mysql扛不住，鏈結數上限這些問題。
滴滴打車是有三個主要的問題，乙個是使用者的下單，第二個是司機搶單，第三個就是系統分單。其中使用者下單的時候，使用者下了單會不停地看這個單的情況，而司機搶單的時候，他搶了單會不停地上報他的座標，還有就是系統分單、它會有很大的計算量來匹配司機和使用者。所有的應用的關鍵點都落實到他們的資料上，都是到mysql上面來。所有的大量的資料讀取，都是他們的mysql來扛。當訂單量大的時候就扛不下去了，很多的應用最後就卡在資料庫這裡了。
分系統解耦，其實這就是解決你有機器、你架不上去的這些問題，來讓你的裝置、你的系統能夠平行的擴。
nosql快取記憶體，把它的那些常用的熱資料用mysql這種可以高併發的、記憶體很快的速度來把它扛下來。
高效能的cdb。其實高效能的cdb，目前就是我前兩天和我們做資料庫的總監談過一次，他說我們現在測出來的我們實際的高效能cbd馬上推出來，可以到4w+qps。
最後就是機房保障。
打造一款億級應用你會碰到哪些問題？
餓了麼原來有乙個機房，差不多有兩三百臺機器。但是每個月的業務都在漲，所以運維部門很頭疼，每個月都要採購裝置 上架裝置。機房滿了再部署乙個機房，整個週期又很強，最後不得已把服務部署在雲機房。a11每年應用數都在不斷地增長。我前兩天向我們開放平台的同事要了乙個資料，註冊的開發者有一兩百萬，然後活躍的開發...
如何打造一款成功的產品
1.我們是做什麼的？2.我們的核心價值是什麼？3.競品的產異化在 我們要做的產品是什麼。滿足什麼使用者人群的什麼需求，我們產品最大的核心競爭力是什麼？與其他同類競品的差異化是什麼？使用者為何要選擇你的產品，而不是選擇其他，如果這些問題都沒有搞清楚，就等於沒有方向。2.我們的直接競爭對手？如果我們發現...
一款面試複習應用原始碼
為了更好地準備面試 特點 二 第三方引用 1 下拉重新整理android ultra pull to refresh 2 mob移動雲服務 3 logger除錯日誌外掛程式 4 應用崩潰異常提示crashwoodpecker 三 執行截圖 四 匯入說明 注意 1 建立表後系統會預設提供objecti...