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

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

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

(網(wǎng)易杭州研究院云計算平臺產(chǎn)品部總監(jiān)陳諤)

　一、杭研十年印象

　　Q：請先介紹您在杭研的早期工作經(jīng)歷，參與過哪些系統(tǒng)的設計和開發(fā)?

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

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

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

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

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

(網(wǎng)易私有云架構(2014年))

　　Q：回顧十年，在做私有云和網(wǎng)易云基礎服務(網(wǎng)易蜂巢)之前，您參與過多個網(wǎng)易系統(tǒng)的研發(fā)，其中哪些是您至今仍然印象非常深刻的經(jīng)歷?

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

　　回頭來看，那個時候杭研大約有20號人，還分為前臺(負責中間件和產(chǎn)品)和后臺(負責數(shù)據(jù)庫)，效率還是很高的。

　　Q：這些經(jīng)驗對后來網(wǎng)易云基礎服務(網(wǎng)易蜂巢)的研發(fā)有什么影響?

　　陳諤：其實包括網(wǎng)易云基礎服務(網(wǎng)易蜂巢)、網(wǎng)易私有云的研發(fā)，都不是從純粹的運維工程師或者系統(tǒng)工程師的角度來做，因為我們以前都是做中間件、做業(yè)務的架構師，設計云平臺的時候，我們都會思考如果自己在上面開發(fā)業(yè)務系統(tǒng)，能否實現(xiàn)很高的研發(fā)效率。

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

　二、云計算系統(tǒng)設計法則

　　Q：從業(yè)務架構的角度考慮，設計云系統(tǒng)或者分布式系統(tǒng)有沒有一些通用的黃金準則?

　　陳諤：我們做云計算、分布式關系數(shù)據(jù)庫，都是分布式系統(tǒng)，我認為最核心的是要懂得可以取舍哪些東西，也就是要非常清楚地掌握它的非功能需求是什么。

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

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

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

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

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

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

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

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

　三、厚積薄發(fā)網(wǎng)易云

　　Q：網(wǎng)易云承載網(wǎng)易95%的業(yè)務，您如何看待網(wǎng)易云基礎服務(網(wǎng)易蜂巢)所扮演的角色，以及能夠做到95%的關鍵因素?

　　陳諤：首先，網(wǎng)易云能夠承載網(wǎng)易95%業(yè)務的背景，是網(wǎng)易的互聯(lián)網(wǎng)技術棧是很統(tǒng)一的，因為所有的中間件、公共技術解決方案都出自我們杭研，這使得我們開發(fā)一個云平臺把一些服務封裝提供給大家變得很容易。同時杭研掌握了網(wǎng)易運維體系，運維是必須和云計算配合的，這是最大的基礎。

　　其次，網(wǎng)易的互聯(lián)網(wǎng)業(yè)務都不小，雖然業(yè)務的數(shù)量不是太多，但是每個大業(yè)務對吞吐能力、性能要求都是很極端的，基于網(wǎng)易 19年的互聯(lián)網(wǎng)技術積累，我們花費大量的精力進行云化，在 IaaS、網(wǎng)絡方面的投入是很大的，而網(wǎng)絡和存儲就是云計算平臺研發(fā)最難解決的問題。

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

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

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

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

　　Q：這些經(jīng)驗對后來網(wǎng)易云基礎服務(網(wǎng)易蜂巢)的研發(fā)有什么影響?

　　陳諤：在用 Neutron之前，Nova是一個平坦的大而全的網(wǎng)絡，分割成很多的 VLAN，要搞很多路由，要設很多的 IP規(guī)則做隔離，二層的擴展能力就存在問題;而且安全組的規(guī)則、一致性、網(wǎng)絡的調(diào)試，已經(jīng)變得非常復雜，有個地方是不通的，沒有人知道是怎么回事，這個問題愈演愈烈，所以我們開始嘗試 Neutron，并且用 SDN的方案。

　　我們膽子還是比較大的，有些實踐會同時保留經(jīng)典網(wǎng)絡和 SDN，默認提供經(jīng)典網(wǎng)絡，我們直接默認提供 SDN的私有網(wǎng)絡，這個性能要求非常高，我們就要拼命優(yōu)化這個東西。現(xiàn)在，從我們業(yè)務的角度，一個二層就夠了，很多個二層可能還不相通，還會增加復雜性。一個二層里面，能支持數(shù)千個虛擬機節(jié)點;從容器的角度，一個租戶下，一張網(wǎng)絡支持數(shù)萬個容器應該是沒有問題的，當然一般也不會支撐這么多。這是我們目前的網(wǎng)絡狀態(tài)，當然以后要適應新的 IT架構，有可能會支持大二層網(wǎng)絡，二層網(wǎng)絡之間有路由，這是以后的規(guī)劃了。

　　四、做好產(chǎn)品研發(fā)的關鍵

　　Q：您提到了很多好技術，但是要把它們整合成為一個云計算平臺產(chǎn)品，達到“網(wǎng)易出品，必屬精品”的境界，有哪些關鍵因素需要注意?

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

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

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

　　Q：所以還是需要一些非技術最優(yōu)的折中?

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

　　Q：那么從網(wǎng)易云基礎服務(網(wǎng)易蜂巢)的角度，目前優(yōu)化的主要方向都有哪些?

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

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

　　Q：您會如何帶領研發(fā)團隊去實現(xiàn)您的目標?

　　陳諤：我目前帶領最多的就是研發(fā)工程師。我認為很重要的一點，就是要給大家學習、表現(xiàn)的機會。我們根據(jù)研發(fā)路線的需求提供一些可以學習的方向，通過學習，還能夠篩選出一些能力基礎很好、有發(fā)展?jié)摿Φ墓こ處熚灾厝巍Ｋ约夹g團隊的學習、交流的機會很重要。同時，技術團隊的學習和實踐有了積淀之后，要推動這些人去分享，不管是技術文章，還是技術課堂，優(yōu)秀的工程師，無論對內(nèi)對外都要有表現(xiàn)的機會，讓他的價值得到肯定。

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

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

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

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。