【51CTO快訊】京東商城在昨天搞了一個“京東圖書瘋搶三小時”活動，不過卻因為大量的“網(wǎng)頁無法顯示”，訂單無法提交而招來用戶的一片罵聲，最終僅產(chǎn)生數(shù)十萬訂單，平均一秒鐘才幾十個。

51CTO推薦專題：電子商務(wù)浪潮下的服務(wù)器高并發(fā)應(yīng)對方案

做活動搞得服務(wù)器頂不住，京東已經(jīng)不是***次遭遇。京東CEO劉強東昨天發(fā)布微博數(shù)篇，表示要“增加三倍服務(wù)器，活動再搞一次”，以及要請“信息部同事們喝咖啡”。

事實上，不僅京東商城有此困惑，其他的不少電子商務(wù)網(wǎng)站也有這樣的困惑。根據(jù)一些業(yè)內(nèi)的數(shù)據(jù)，在國內(nèi)的眾多電商網(wǎng)站當中，除了阿里的服務(wù)器過萬外，其余的大多在500-2000之間，且大多數(shù)是.NET架構(gòu)。劉強東在早期做過一些財務(wù)系統(tǒng)和小的企業(yè)級應(yīng)用系統(tǒng)，京東也因此在早期選用了.NET架構(gòu)；然而，互聯(lián)網(wǎng)這種高并發(fā)、大流量的應(yīng)用環(huán)境和企業(yè)內(nèi)部環(huán)境是有非常大的區(qū)別的。京東商城目前維持30萬的日平均訂單量已然不易，一旦要進行活動，用戶訂單一擁而上，現(xiàn)有的架構(gòu)根本無法處理。

那么，京東要如何才能擺脫現(xiàn)在的困境？

從運維的角度來看，僅僅增加三倍服務(wù)器肯定帶不來三倍的并發(fā)訂單處理能力。在劉強東當天的微博后面現(xiàn)在已經(jīng)有9千多條評論，其中不少來自技術(shù)人；在筆者所在的一些技術(shù)群里也在討論這個問題，其中不乏有見地的評論。小編從中挑選一些，整理如下：

管理、人才方面

李錚_Reason：活動之前沒有對預期流量進行充分評估么？這種活動不是經(jīng)常進行，增加3倍服務(wù)器是否會浪費資源？活動在搞一次，是否合算過財務(wù)，是否問過市場部？從公司來講還是要尊重各個部門的努力；從營銷來講，這條微薄估計比一個Q的營銷效果都好。

霍泰穩(wěn): 也許京東從這件事上能夠了解技術(shù)人員其實挺重要的，多讓技術(shù)人員外出交流還是很有必要的。此前邀請京東的朋友出來分享，總是很困難！

焦若雷[[48923]]：動態(tài)應(yīng)用的突發(fā)看來依然是京東包括很多未來量會增長到很大的電子商務(wù)網(wǎng)站的瓶頸。出現(xiàn)這種問題的原因可能與你們業(yè)務(wù)線和運維的溝通不充足有關(guān)，但也不排除本身你們在大規(guī)模動態(tài)應(yīng)用突發(fā)上的運維管理經(jīng)驗缺失及技術(shù)缺失。

老熊:大的電商，不叫技術(shù)部，叫信息部，京東也是獨一家吧

Norman程：市場部是否有把這次活動可能導致每小時進十幾萬的訂單的信息傳遞到各個業(yè)務(wù)系統(tǒng)呢？今天是門戶及訂單系統(tǒng)宕機，明天會不會是供應(yīng)鏈和物流呢？

程序員-釗雄Johnson：（一）從技術(shù)的角度，服務(wù)器壓力均衡不是靠增加幾臺服務(wù)器就能解決的問題。淘寶積聚著一批優(yōu)秀的JAVA人才，數(shù)據(jù)庫人才，天天為服務(wù)器保駕護航，保證了正常運行。多方面的技術(shù)積聚，才是問題的解決。您作為老大，您為您IT部門做了哪些？電子商務(wù)，無電子，何來商務(wù)。

程序員-釗雄Johnson：（二）京東采用.NET平臺，在均衡壓力上需要積累。它需要***的團隊，***的管理制度，足夠的技術(shù)積累。人才，***的待遇，招***的人才。京東，或者這次事件只是一個開始，它應(yīng)該不是一個偶然，應(yīng)該說是個必然。技術(shù)不革新，人才不革新，問題還是遲早爆發(fā)。

@池建強:在技術(shù)上淘寶和京東完全不是一個層面上的，看看各個技術(shù)大會淘寶的分享吧。這種情況下談什么Java還是.Net，就毫無意義了。

kwkmko：全面一點吧，市場部和策劃部有沒有計算或者預計一個比較靠譜的流量？并且遞交給信息部備案？財務(wù)有沒相關(guān)條款支持設(shè)備更新？總協(xié)調(diào)人是否預計到這樣的情況？信息部有沒有預算支持應(yīng)急的設(shè)備……

池建強: 阿里玩的是平臺，順道把電商做了；京東玩的就是電商，順手搞搞技術(shù)。

技術(shù)改造方面

南非蜘蛛: 是不是應(yīng)該先找出瓶頸，優(yōu)化架構(gòu)，加機器也不一定可以徹底解決

靜觀參眾妙：作為一個軟件從業(yè)人員，我完全理解今天上午服務(wù)器經(jīng)常出現(xiàn)service too busy的現(xiàn)象；但作為一個軟件測試人員，我完全不能理解京東的業(yè)務(wù)系統(tǒng)貌似沒有經(jīng)過嚴格的大數(shù)據(jù)量壓力測試。

foxtree[[48923]]：壓力在數(shù)據(jù)庫，不是多幾倍服務(wù)器能搞定的，除非程序重構(gòu)適應(yīng)分布式的硬件

雪中飛_：量變引起質(zhì)變吧，并發(fā)量小的網(wǎng)站剛開始可以不太關(guān)注底層技術(shù)架構(gòu)，量大的網(wǎng)站要提前布局，否則到時候就措手不及。而底層技術(shù)平臺需要時間和經(jīng)驗去堆積。

何雪峰：這個不是簡單加服務(wù)器就能解決的，涉及接入帶寬數(shù)，數(shù)據(jù)庫并發(fā)處理能力，中間層并發(fā)處理能力，京東訂單系統(tǒng)并發(fā)處理能力，磁盤寫入速度，排隊事務(wù)處理

kewell119：建議你們看看《編寫高質(zhì)量代碼—改善C#程序的157個建議》

淘寶四虎：有了這么大的壓測量，應(yīng)該收集不少性能數(shù)據(jù)，接下來好好分析性能瓶頸，花個半年時間解決一下。

365-姜志林：就情況看，問題可能出在數(shù)據(jù)庫，web端向數(shù)據(jù)庫大量提交訂單，db并發(fā)造成死鎖等待。web端繼續(xù)等待，建議采用分布式設(shè)計及文件級數(shù)據(jù)緩存，同時優(yōu)化底層數(shù)據(jù)庫設(shè)計。

霧散云暖：時間再長也沒用，關(guān)鍵要改進你們的后臺，學學人家亞馬遜、當當，首先備貨要足，其次購物車要能保留信息，第三貨品搜索頁面上***直接根據(jù)ip地址或者啥的顯示出當?shù)赜袩o貨狀態(tài)

京Piedro-Conte董金：我覺得比較現(xiàn)實的還是 請IBM 之類的公司 給京東做設(shè)計（編者注：雖然IT外包一般不是互聯(lián)網(wǎng)企業(yè)的優(yōu)先選擇，不過隨著互聯(lián)網(wǎng)技術(shù)的細分，由于術(shù)業(yè)有專攻，細分領(lǐng)域的外包相信也會逐漸變成趨勢。）

大熊[[48924]]：其實，這個時刻最應(yīng)該給京東提供幫助的是微軟。微軟應(yīng)該考慮無償給京東這樣的電商大鱷提供.Net的所有技術(shù)服務(wù)，甚至更多幫助。因為，像京東這樣有著幾千人研發(fā)團隊的企業(yè)還堅持使用.Net架構(gòu)的已經(jīng)幾乎沒有了，如果連京東都這樣一掛再掛，很難相信以后還會有哪個大型商業(yè)網(wǎng)站敢再選用.Net架構(gòu)。

有關(guān)彈性云

數(shù)據(jù)中心亂彈:是否可以租賃amazon的計算能力應(yīng)急突發(fā)高峰？或國內(nèi)誰會***推出類EC2這種服務(wù)？

zysno1: 如果是這種規(guī)模的企業(yè)使用彈性計算，其實不需要全部hosting上來，它可以用彈性計算來支撐那部分突增。就類似CDN那樣。彈性計算使這種階段性的資源使用方式成為可能

你對于國內(nèi)電子商務(wù)遇到的這種困境有何看法？歡迎探討！ 

【51CTO.com獨家特稿，轉(zhuǎn)載請注明原文作者和出處?！?/p>

【編輯推薦】

1. 高性能ASP.NET站點構(gòu)建之識別性能瓶頸
2. 十大服務(wù)器常見“性能瓶頸”(圖)
3. 細數(shù)十個最令人頭疼的性能瓶頸