為什麼網易雲能承載網易95%的業務?

ADVERTISEMENT

ADVERTISEMENT

  【IT168 資訊】在容器雲市場競爭愈發激烈的今天,網易雲基礎服務(網易蜂巢)的負責人陳諤確實是一個大忙人。不過,在陳諤的臉上,我們很少能夠看到一絲急躁,似乎十年的磨煉足以讓他面對任何挑戰都能做到有條不紊。

  在陳諤看來,技術架構的劇變發生在Web 2.0爆發之時,之後至今只是平緩期的不斷優化,而網易杭州研究院(下稱杭研)經曆了那個時刻。

  他分享了此後杭研網易私有雲、網易雲基礎服務(網易蜂巢)的研發思路、技術優化路線以及研發管理心得。他表示,雲計算的研發是一定要能夠提升業務研發效率的,SDN、容器、編排管理等技術框架的選擇及應用,都是要回歸於業務架構。意外的是,他還提出編程語言的選擇對雲計算研發的影響會越來越重。

  (網易杭州研究院雲計算平台產品部總監陳諤)

  一、杭研十年印象

  Q:請先介紹您在杭研的早期工作經曆,參與過哪些系統的設計和開發?

  陳諤:我負責過網易博客、網易監控平台、網易消息推送平台以及易信公眾號系統,從2012年起就一直做雲計算,從網易私有雲、網絡虛擬化架構設計,再到現在的網易雲基礎服務(網易蜂巢)。

  早期的網易博客個人首頁,是我開發的,博客的認證授權框架,包括一些和數據庫對接的中間件,運維方面的類似持續發布、持續集成的東西,也是我的工作。

  Q:作為杭研的第一批員工,您心目中這十年來杭研最大的技術成果是什麼?

  陳諤:第一個,我們幾乎是最早做分布式關係數據庫的,而且是把分布式關係數據庫直接用於Web 2.0的產品上,這對於杭研是一個很大的成就。

  另一個,雲計算平台的應用,對整個網易公司的互聯網業務帶來很明顯的推動作用,因為當時我們對服務器的管理、業務的增長都已經到了一個瓶頸,必須有這樣一朵雲,才能實現新的突破。我個人認為這兩個方面是杭研很重要的成果。

ADVERTISEMENT

  (網易私有雲架構(2014年))

  Q:回顧十年,在做私有雲和網易雲基礎服務(網易蜂巢)之前,您參與過多個網易系統的研發,其中哪些是您至今仍然印象非常深刻的經曆?

  陳諤:早期從頭開始做的東西讓我記憶猶新。我剛進入網易的時候,正值Web 2.0概念爆發,整個技術挑戰、技術方向突然和以前完全不一樣,關注點變成水平擴展、高並發、大吞吐量等。我是網易第一個做Web 2.0業務的(網易博客),不僅做博客本身的屬性,同時還做博客的運維,包括版本控製等等。從那個時間點到現在,整個技術體系的發展相對平緩,就那個時間突然跳躍了一下,需要不同的運維手段,做互聯網的似乎變成了做運維的,所以我的印象是比較深刻的。

  回頭來看,那個時候杭研大約有20號人,還分為前台(負責中間件和產品)和後台(負責數據庫),效率還是很高的。

  Q:這些經驗對後來網易雲基礎服務(網易蜂巢)的研發有什麼影響?

  陳諤:其實包括網易雲基礎服務(網易蜂巢)、網易私有雲的研發,都不是從純粹的運維工程師或者系統工程師的角度來做,因為我們以前都是做中間件、做業務的架構師,設計雲平台的時候,我們都會思考如果自己在上面開發業務系統,能否實現很高的研發效率。

  網易雲基礎服務(網易蜂巢)的研發初衷,就是因為我們覺得只是把IaaS系統做好,對提升研發效率的作用還是很有限的。網易雲基礎服務(網易蜂巢)的技術路線,包括一些細節的決策,包括網絡的設計,包括Docker容器、Kubenetes編排技術的選擇,都是從業務架構去考慮的,是來自於前期研發工作積累的經驗。如果我們原來只是運維或者系統工程師,現在的網易雲的形態可能是有很大的不同的,哪怕是Docker的使用方法,都不一定是現在這樣的。

  二、雲計算系統設計法則

  Q:從業務架構的角度考慮,設計雲系統或者分布式系統有沒有一些通用的黃金準則?

  陳諤:我們做雲計算、分布式關係數據庫,都是分布式系統,我認為最核心的是要懂得可以取捨哪些東西,也就是要非常清楚地掌握它的非功能需求是什麼。

  因為分布式系統架構的方式、實現的技術,這十幾二十年沒有太大的突破,該有的理論很早就存在,後面的CAP原理(一致性、可用性、分區容錯性)也只是歸納性的東西。所以,最重要的還是要知道取捨,比如CAP的取捨,還有系統的複雜性與可運維性的取捨,功能很強大但是運維很麻煩也是不行的。

  還有一點,從我個人的偏好出發,采用合適的編程語言做分布式系統也是一件很重要的事情。我們采用OpenStack有很多坑,其實就是Python語言帶來的――不是說Python不好,但是它很多的機製,在公有雲的發展方向上會帶來一些性能、並發的瓶頸。Go語言出現之後,一大批的公有雲產品都是基於Golang開發的,Golang比以前的語言在並發、性能、安全性等方面做得更好,如果是用Java來寫這些系統,要達到一樣的性能效果,需要的研發周期會長很多。所以,從長期的發展來看,編程語言對雲計算研發決策的影響會越來越重。

  Q:能否介紹您對編程語言、編程模型有什麼特別的偏好?您還在編寫代碼?

  陳諤:我個人不會執著於“PHP是世界上最好的語言”之類的想法。比較流行的語言,包括Erlang、Ruby、Java、JavaScript等,甚至像Rust這樣一些偏門的語言,我都會去了解,因為它們擅長於解決某些方面的問題。

  你可以發現我剛才沒提Go,因為我先接觸Erlang,後來又接觸Rust,從我的角度,Go要解決的一部分問題,我可以直接用Erlang來寫,而如果是系統編程,對GC很敏感的,我會傾向於用Rust來寫,如果讓我用Go來寫,我好像沒有什麼動力。包括之前給網易博客做運維需要的腳本語言,我希望用起來簡單,有成熟的庫可以依賴,選擇了Java技術棧,雖然Ruby語法特性更好,但是Java生態可以依賴那些很好的庫。所以,能產生直接的效果、擅長解決某些問題,這就是我選擇編程語言的偏好。

ADVERTISEMENT

  至於編程語言的特性,個人更傾向於往Functional的方向發展,包括一些解決異步方面的問題,個人覺得Reactive這種模型,更加偏向於Functional,會更讓人喜歡。因為它其實是描述解決問題的方法,而不是密密麻麻地寫一堆指令去描述解決問題的過程。這是我接觸各種不同的語言之後逐漸養成的習慣。

  落實到我們整個團隊的開發工作,語言的選擇其實是很實際的:OpenStack就只能選擇Python;網絡、內核相關的東西,就只能選擇C;Docker、Kubernetes的選擇必然是Go。當我們設計一些適配容器的東西,比如寫一個Kubernetes的Controller,雖然有些工程師之前擅長Java,但是我會告訴他去學習Go,用Go來寫。所以這和我們的技術選型是相關的。其實Google也選擇這種組合,這是很有道理的。

  我個人目前也會寫代碼,但是不適合和團隊協作,因為團隊在等待我提交某個模塊或者修複某個Bug的時候,我往往正在進行一些無法離開的溝通工作,這會影響項目進度。所以,我現在只能寫一些Demo,寫一些東西去體驗我們自己的網易雲,嚐試我們的接口。

  三、厚積薄發網易雲

  Q:網易雲承載網易95%的業務,您如何看待網易雲基礎服務(網易蜂巢)所扮演的角色,以及能夠做到95%的關鍵因素?

  陳諤:首先,網易雲能夠承載網易95%業務的背景,是網易的互聯網技術棧是很統一的,因為所有的中間件、公共技術解決方案都出自我們杭研,這使得我們開發一個雲平台把一些服務封裝提供給大家變得很容易。同時杭研掌握了網易運維體系,運維是必須和雲計算配合的,這是最大的基礎。

  其次,網易的互聯網業務都不小,雖然業務的數量不是太多,但是每個大業務對吞吐能力、性能要求都是很極端的,基於網易19年的互聯網技術積累,我們花費大量的精力進行雲化,在IaaS、網絡方面的投入是很大的,而網絡和存儲就是雲計算平台研發最難解決的問題。

  以網絡為例,從第一個版本上線開始,三年之內對於整個網絡的架構、網絡的優化,我們投入的力量是最大的。最開始只有三層,後來完成二層的格局,然後把網絡性能從只能跑千兆網絡,做到一直到接近萬兆,這就經曆了一個很長的優化過程。網絡問題解決之後,上面的業務就好集成,因為計算虛擬化是相對比較成熟的,但各方對網絡實現優化的差異其實是很大的,有些方案連千兆都做不到,尤其是做SDN之後。

  再說網易雲基礎服務(網易蜂巢)。我剛才提到過一個邏輯,在做完傳統IaaS私有雲、網易業務遷移進來後,我們監控大家使用雲的情況,和業務線的技術部門訪談,發現IaaS對業務部門開發效率的提升是非常有限的,有時候甚至起到了反作用。為了解決這個問題,我們才做的網易雲基礎服務(網易蜂巢)。

  網易雲基礎服務(網易蜂巢)的原型,是一套內部的OMAD系統,為了解決業務的CI/CD流程而開發,因為當時容器技術還不成熟,做完這個系統之後,我們發現它對Runtime的管理存在一些問題,比如各方需要不同的Runtime,需要update的時候,或者做集成的時候,就會碰到很多環境的問題。後來我們發現了Docker容器,就用Docker改造系統,把它做成網易雲基礎服務(網易蜂巢),最後做成現在的形態。以PaaS融合IaaS,業務部門無需特別考慮資源,也無需對應用做太大的改變,即可實現應用彈性、DevOps。

  同時,我們也開始選擇了開源的技術棧,因為我們發現,很多東西如果能夠用社區的力量,我們也能掌控這個東西,或者能夠貢獻到上遊,這個東西的生命力會更長久;反而自己折騰的一些東西,過幾年被廢棄的可能性會很大,投資回報是很低的。

  Q:這些經驗對後來網易雲基礎服務(網易蜂巢)的研發有什麼影響?

  陳諤:在用Neutron之前,Nova是一個平坦的大而全的網絡,分割成很多的VLAN,要搞很多路由,要設很多的IP規則做隔離,二層的擴展能力就存在問題;而且安全組的規則、一致性、網絡的調試,已經變得非常複雜,有個地方是不通的,沒有人知道是怎麼回事,這個問題愈演愈烈,所以我們開始嚐試Neutron,並且用SDN的方案。

  我們膽子還是比較大的,有些實踐會同時保留經典網絡和SDN,默認提供經典網絡,我們直接默認提供SDN的私有網絡,這個性能要求非常高,我們就要拚命優化這個東西。現在,從我們業務的角度,一個二層就夠了,很多個二層可能還不相通,還會增加複雜性。一個二層里面,能支持數千個虛擬機節點;從容器的角度,一個租戶下,一張網絡支持數萬個容器應該是沒有問題的,當然一般也不會支撐這麼多。這是我們目前的網絡狀態,當然以後要適應新的IT架構,有可能會支持大二層網絡,二層網絡之間有路由,這是以後的規劃了。

  四、做好產品研發的關鍵

  Q:您提到了很多好技術,但是要把它們整合成為一個雲計算平台產品,達到“網易出品,必屬精品”的境界,有哪些關鍵因素需要注意?

  陳諤:把技術交付給用戶的時候,一定要考慮用戶的真正場景和他的使用方式,了解有哪一些性能是用戶特別關注的,這是很重要的一點。比如剛才說,不應該由用戶處理複雜性,否則,很容易做成一個看似很高大上的實現,某項功能很複雜,結果用戶不是這樣使用,或者他根本不願意去應對這個複雜性。

  有一個很簡單的例子,以前有些虛擬網絡是通過NAT去提供的,有一些浮動IP,我們設計的時候,就要避免這種NAT出去一個浮動IP的情況,因為這可能會造成用戶做長連接業務時,以前能用的寫心跳的程序,突然就不能用了,或者用戶程序依賴本地IP,但是本地看不到IP,他的業務上來就發現不行了,還得改業務。

  我們強調,有時候,你感覺你的設計是高大上的,性能也很好,但是用戶真的上來的時候,他的感受不一定是這樣的。所以,一定是考慮用戶怎麼會使用這個技術去解決他的問題。

  Q:所以還是需要一些非技術最優的折中?

  陳諤:對。包括Docker也是這樣,比如網易雲基礎服務(網易蜂巢)如果直接用Docker的理念,那是很極端的,它覺得根本不應該存在有狀態的、不能隨時掐掉的業務,但實際上我們看到用戶還是需要有狀態的、可以保證硬件故障或者宕機時能夠恢複的有狀態容器――他可能開一個數據庫,不可能從這里宕機,再從另一個地方起來,至少短期之內還做不到這樣的事情。所以你必須先讓他把業務架構搬到雲上面,先能用上Docker的一些鏡像、部署的好處,再逐步幫他做解決方案,讓他用上你提供的更多好處,否則他搬都搬不上來。

  Q:那麼從網易雲基礎服務(網易蜂巢)的角度,目前優化的主要方向都有哪些?

  陳諤:首先,作為雲計算基礎服務,永遠要提升性能指標,包括吞吐能力,而且性能指標必須平穩,不能有太大的波動,所以我們在塊存儲、虛擬網絡性能方面不斷優化,希望也能滿足那些極端的情況。我們認為,只要做基礎設施,就要不停提升網絡IO性能,就會有很大的效果,這是直接影響客戶業務體驗的。

  還有重要的一塊是容器的編排管理,不僅要考慮用戶業務在線上怎麼做編排管理,還要從研發、測試的角度來考慮怎麼利用編排管理的服務來支撐研發的過程。同時Kubernetes也在不停地發展,包括對兩地三中心的支持,我們會保持容器編排管理的持續跟進、優化,使得用戶的業務能夠在盡可能短的時間內獲得到容器雲技術最新進展的支持。

  Q:您會如何帶領研發團隊去實現您的目標?

  陳諤:我目前帶領最多的就是研發工程師。我認為很重要的一點,就是要給大家學習、表現的機會。我們根據研發路線的需求提供一些可以學習的方向,通過學習,還能夠篩選出一些能力基礎很好、有發展潛力的工程師委以重任。所以技術團隊的學習、交流的機會很重要。同時,技術團隊的學習和實踐有了積澱之後,要推動這些人去分享,不管是技術文章,還是技術課堂,優秀的工程師,無論對內對外都要有表現的機會,讓他的價值得到肯定。

  另外就是標準化的管理、目標的設定。從技術的角度,我更傾向於設定目標的管理,而不是KPI的管理。我會告訴大家我們都能認同的目標,比如網絡模塊應該做到哪些目標,網絡抖動可以下降到多少,網絡吞吐量可以到多少,讓他自己在理解項目整體目標的基礎上,再把自己的量化目標定出來。

  分享我們做過的一件很有意思的事情:

  網易雲基礎服務(網易蜂巢)最初的版本,從申請資源開始監測,到虛擬機、容器全部啟動,大概需要兩分半鍾。我認為這個速度太慢,當時就提出要求,希望20秒就能把容器啟動搞定。大家覺得這個事情太困難,幾乎是不可能完成的。但是接下來分解目標,我們不是製定哪個組幾秒鍾的KPI,而是分一些階段性的目標,先優化到1分鍾,再到40秒,再到20秒,讓大家看自己的環節,還有哪些潛力可以挖掘,怎麼可以一步步地進步,設定一些業界有挑戰的、有價值的目標(不是拍腦袋,而是根據業界先進水平或者理論來決定),不斷迭代,朝著目標前進。最後,我們確實實現了在20秒左右完成一個容器的建立(除去鏡像傳輸的時間)。在雲計算這個複雜系統里面,做到這一點其實是很不容易的。

ADVERTISEMENT