設置
上一章
下一章

第三百零三章 云計算競爭

  “去”這個說法,

  是在王堅博士加盟百度研究院、原“大中臺”事業群改組為易趣云。

  隋波提出了公司系統平臺的“自主研發”道路和“云計算”戰略之后。

  在去年初的長城會議上,正式確定的。

  星河系旗下的電商、搜索、社交業務,都是平臺級的應用。

  隨著業務發展,

  無論是海量暴增的數據,還是大規模高并發的互聯網行為、對計算能力的巨大需求……

  現有的傳統服務器架構和集中式r數據庫架構,已經越來越不適應業務擴展的需要。

  不僅成本高,維護費用高。

  甚至可能會導致,系統被主機和硬件廠商所“綁架”,不得不持續增加投入成本。

  而隨著星河系的盤子越來越大。

  所需要付出的升級硬件和維護的代價,也會越來越驚人……

  在這兩年易趣618大促、淘寶雙11促銷活動,電商業務量暴增;百度全球化擴張步伐導致的數據存儲和檢索量激增;易迅在社交和游戲業務上的快速增長等情況下……

  “去”,就更加變得勢在必行了!

  所謂“去”。

  其核心是低成本、線性可控、去中心化(分布式):

  “r替代B小型機;自研數據庫替代r;去,用中低端存儲”。

  簡單來說,

  傳統的代表的是集中式架構,而“去”,就是推動分布式架構代替集中式架構。

  其實質,與“云計算”戰略是緊密相連的。

  在今天的合伙人會議上,

  王堅博士第一次向所有合伙人,詳細闡述了目前“去”和云計算的進度。

  “像我們星河集團這樣大規模的互聯網應用,采用開源、開放的系統架構,這其實并不是什么新的發明。

  國外的、亞馬遜這些公司,都是采用的類似系統架構。

  只不過,它們幾乎一開始就沒有采用商業公司的架構,所以他們不用“去”。

  而我們在前期,由于沒有足夠的技術實力來開發自有系統。

  為了系統的穩定性和高性能的運算存儲,采用了高端的商業公司架構。

  現在基于集團業務發展的需要,同時也積聚了一定的技術實力。

  是時機可以開展自主研發了。”

  王堅顯得頗有感觸:

  “當然,在這個過程中,困難是非常大的……

  多虧了波總、龐總的支持,和所有團隊的認同和協作。

  如果沒有技術、產品和業務等各團隊的相互協同,這是一件不可能的事!”

  根據他的介紹,去的困難,主要是技術層面的……

  比如,“去”,技術架構是關鍵:

  小型機作為系統的主要計算設備承載了大部分的業務,但從擴展性、性價比、核心能力掌控等角度而言,不適宜集團目前業務發展。

  而86單個處理能力一直在提升,應用了分布架構和云計算技術,可以用一個數據中心去替代某一臺大機。

  不過,應用采用分布式架構,提升處理能力,必須對應用代碼進行改造。

  所以,應用層可以直接替換成廉價的86服務器,難點在涉及到部分代碼重構;

  數據層(易趣)也可以采用86服務器或者是數據庫云平臺,分析型業務(百度)則主要遷移到大數據平臺。

  “去”的主要難點,僅限于技術架構,對應用基本無影響。

  但同時,“去”也需要在存儲性能、可靠性和容災方面考慮對策。

  實際上,“去”和“去”,在技術上難度和復雜程度都不算太大……

  “去”真正的難點和重點,

  是“去”!

  因為數據庫非常難被替換。

  它處在整個產品或者產業鏈最底層的位置,替換風險很大,但收益相比起來卻小得多。

  這也是為什么像B、微軟這樣的后來者,也無法取代r。

  而對于星河集團而言,“去”的主要難點在于:

  傳統關系數據庫都是通過外部硬件來保證可用性,在用便宜的機替換高端服務器之后,硬件更容易出故障了,如何保證數據庫高可用?

  高可用和數據一致性如何同時保證?

  分布式系統怎么同時實現的要求?(指:一致性(,)、可用性(b,)、分區容錯性(rr,))

  幾十年來,這么多做數據庫的廠商,國內國外基本沒有人成功過……

  而且從公司的業務發展的角度,也不可能等你幾年把數據庫做出來,再去發展業務。

  更可行的做法,是先基于開源做出一些東西,讓業務先往前走。

  所以,目前王堅為首的技術團隊,采用的是數據切分(r)的策略。

  將部分海量數據應用,先從集中式r切換到分布式集群,從縱向擴展到水平擴展,解決了數據庫擴展性的問題。

  同時,目前百度研究院正在研發自有的分布式關系數據庫——B。

  這里不得不提到一個人,陽振坤博士。

  這也是一位“超級大牛”:

  84級帝大數學系,碩士師從本系的張恭慶院士,后又轉向計算機領域,博士師從計算機系的王選院士。

  大學只用了3年,碩士1年多,24歲成為王選院士博士……

  95年其所在團隊研究成果獲國家科技進步一等獎(排名第四),1997年,32歲被破格晉升為教授、99年成為帝大首批“長江學者獎勵計劃”特聘教授。

  他是跟隨王堅博士,從微軟亞洲研究院“跳槽”,來到百度研究院的十幾名科學家之一。

  目前擔任百度研究院系統數據庫項目組組長、高級技術專家(9)。

  陽振坤博士一直都是研究分布式技術和分布式系統的。

  他十分看好云計算系統的發展機會,在加入百度研究院后,就主動請纓,開始擔綱支持分布式關系數據庫B的研發。

  而王堅對于他的研發項目,也非常支持。

  認為B數據庫,將會是未來星河云計算戰略中,最重要的一環!

  隋波聽到這里,也不禁有些慶幸。

  正是他提前請來了王堅博士,并且全力支持“云計算”戰略。

  才能有這么多前世的技術大牛,匯集到星河旗下,并且能夠提前發揮出巨大的作用……

  最后,王堅博士也向大家匯報了目前集團“去”計劃的工作進度:

  易趣商品庫已在去年6月,完成去“”,計劃于今年年中,完成去“”;

  數據庫,將在今年3月完成去“”,10月完成去“”;

  易迅社交及游戲數據庫,將于今年年10月,一次性完成“去”;

  目前集團數據量最大的易趣交易庫、現金流結算系統;易付寶交易系統和賬戶系統,則預計要到明年底,才能完成去“”。

  之所以各公司的進度不同,主要也是因為不同業務對系統的需求不同。

  比如,

  易迅是即時通訊和社交、游戲業務,注重實時和可靠的在線服務。

  服務要“永不中斷”,對系統的要求是健壯、容災、負載能力強;

  百度是搜索業務,注重分布式計算能力。

  對系統的要求上,不論是扒取海量內容還是響應并發請求都需要高效迅速;

  而易趣是電商業務,最重視的是并發事務的處理,對事務狀態的控制、交易安全的控制……

  盡管平臺系統復雜,技術開發難度大。

  但王堅博士依然稱:

  “預計到2008年,集團所有業務,都將完成去!”

  隋波第一個用力的鼓起掌來!

  他心中興奮莫名。

  雖然“去”,只是星河集團自研系統,邁出的第一步。

  但這一步,卻是最關鍵的!

  因為它實現了星河系在技術領域,“自主”的開始。

  從此之后,

  星河系就可以脫離B、r等國外硬件巨頭的“控制”,擁有更多的話語權……

  而且,“去”還是云計算戰略,實現的前提和基礎。

  “去“的本質是分布化,讓隨處可以買到的架構成為可能,這就是使云計算能夠落地的首要條件。

  超大規模的數據中心建設、高速互聯網絡、計算資源虛擬化(rr)和軟件定義網絡()技術的發展和成熟,是構成云計算發展的技術條件。

  現在已經是2006年了。

  就在今年3月,亞馬遜將會發布3存儲服務、消息隊列及2虛擬機服務。

  這將是現代云計算時代開啟的標志!

  在前世,亞馬遜在云計算的先發優勢,是其成為未來的全球云計算服務市場第一的關鍵。

  阿里前世要到09年才成立阿里云……,起步晚了很多。

  而從全球市場來看,

  2008年也是真正的云計算元年。

  2008年,推出(

  )云服務;

  2009年,微軟推出r云服務;

  隨后,B、r、等巨頭都陸續入局,推出了各自的云服務。

  如果星河集團能夠在08年,就完全實現“去”。

  也就是說,

  到那時,星河也可以推出自己的云服務了!

  雖然早期的云服務,由于技術和網絡的原因,還不太穩定,產品服務還比較單薄。

  但是這個時候,大家都差不多。

  可以先推出免費服務,然后不斷的進行技術積累和改進。

  等到云計算進入爆發期和大發展的階段……

  以星河系龐大的業務生態,數據中心的分布規模。

  能夠一較高下的,估計也就是亞馬遜和微軟兩家了!

  這可是一個千億美元的巨大市場啊……

  而且,在巨頭之間的競爭中,

  云服務還有一個非常重要的戰略作用:

  鞏固生態和高建護城河!

  對于巨頭而言,云服務是鞏固生態、連接合作伙伴的重要利器。

  因為對于企業客戶而言,一旦使用了某家的企業服務,就意味著將企業重要的運營數據放在該平臺上,因此很可能會與這家公司深度綁定在一起。

  換言之,

  巨頭們可以能夠通過服務自己生態體系中的上下游企業,鞏固自己的原有業務和生態帝國。

  此外,云計算的價值,還遠遠不止在商業層面。

  未來,當人口紅利期結束,消費互聯網進入到瓶頸時……

  B端業務,就是所有巨頭競爭的主要領域。

  而B端的產業互聯網,核心就是云服務!

  政府采購、智慧城市、物聯網……

  到那時,巨頭們將會轉型“新基建”。

  5網絡、工業互聯網、物聯網等網絡基礎、人工智能等運算基礎,都將成為必要而普遍的新型基礎設施。

  而云計算和云服務將是其中重要的基礎服務之一。

  可以說,這將是星河系未來二十年,能夠始終屹立于巨頭行列的真正根基所在啊!

  隋波這時看著王堅和龐勇這兩個“云計算”戰略的負責人,

  感覺就像看兩個金娃娃。

上一章
書頁
下一章