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

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

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

[[184476]]

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

一、杭研十年印象

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

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

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

Q：作為杭研的***批員工，您心目中這十年來杭研***的技術成果是什么?

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

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

(網易私有云架構(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生態可以依賴那些很好的庫。所以，能產生直接的效果、擅長解決某些問題，這就是我選擇編程語言的偏好。

至于編程語言的特性，個人更傾向于往 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秒左右完成一個容器的建立(除去鏡像傳輸的時間)。在云計算這個復雜系統里面，做到這一點其實是很不容易的。