從炎熱的夏日中走入到錢塘江畔清涼的網(wǎng)易云會客室，我見到了陳諤，開始這次“輕舟”之行。

　　說實話，初次近距離見到陳諤時，心中有點愕然，作為網(wǎng)易杭研的元老之一、網(wǎng)易云基礎服務的領頭人，我竟然從他身上感到一點點靦腆和技術人員的質樸。聯(lián)想到之前網(wǎng)易云這邊作為背景信息給出的個人介紹，這樣的一位領軍人物，居然自謙自己“對分布式系統(tǒng)設計開發(fā)、云計算平臺系統(tǒng)架構有一定的經驗和理解”，我不禁有些恍然。

　　我接觸和采訪過很多開源和互聯(lián)網(wǎng)公司的技術領袖，陳諤應該是我見過的最溫和而又不失自信的人之一，他的臉上總是浮現(xiàn)著內斂的笑容，讓我們在談話的一開始，就有了一個良好的氛圍。

　

　　受訪者（左）：網(wǎng)易云陳諤，采訪者（右）：老王

　　和很多互聯(lián)網(wǎng)公司推出的云服務一樣，網(wǎng)易云也是一個脫胎于內部實踐的云服務。網(wǎng)易杭州研究院作為整個網(wǎng)易公司的技術攻堅力量和創(chuàng)新業(yè)務孵化團隊，隨著網(wǎng)易業(yè)務和規(guī)模的不斷的變化，杭州研究院面臨著非常大的壓力去做好基礎設施的相關工作。

　　隨著移動互聯(lián)網(wǎng)的到來，原本可以很好應對博客、游戲等業(yè)務的 IT 基礎設施逐漸變得捉襟見肘，原本的資源調度能力無法處理好隨著新業(yè)務和新模式的快速增長和迭代而產生的需求和復雜度。IT 基礎設施成為了當時網(wǎng)易發(fā)展業(yè)務的新瓶頸。

　　為了能夠更好的服務網(wǎng)易內部的業(yè)務， 2012 年，網(wǎng)易杭州研究院組建了專門的云平臺產品部，來建設網(wǎng)易內部使用的云計算平臺，以應對移動互聯(lián)網(wǎng)到來而產生的更加復雜應用帶來的基礎設施需求。

　　隨著網(wǎng)易云產品對內提供服務，規(guī)模上的問題被逐漸解決，但是，產品的研發(fā)模式也在不斷的迭代，網(wǎng)易內部開始不斷地實踐微服務架構。在這個過程中，陳諤感覺到，現(xiàn)有的 IaaS 產品和 PaaS 產品已經漸漸無法支撐來自微服務架構的復雜度，但在那時，云原生理念和技術尚未成熟的時代，對于微服務的探索只能獨立踐行。網(wǎng)易云針對性的提供了 CI/CD、分布式架構鏈路跟蹤、服務治理的工具，幫助用戶更好的去實踐微服務。

　　到了 2015 年 7 月，隨著 CNCF 的成立，這時陳諤發(fā)現(xiàn)，網(wǎng)易云的很多產品和服務，和 CNCF 的理念是一致的或相似的，于是，網(wǎng)易云決定將自己的探索和成果更好地結合社區(qū)的發(fā)展，向社區(qū)貢獻自己的努力，也吸納來自社區(qū)的營養(yǎng)，將網(wǎng)易云的發(fā)展和開源社區(qū)的路線結合起來。

　　也正因為擁抱社區(qū)，網(wǎng)易云很早就走上了 Kubernetes + Docker 的發(fā)展路線。談起對于 Docker 和 Kubernetes 的選擇，陳諤表示，網(wǎng)易云選擇 Docker 和 Kubernetes 并不是偶然之下的決定。

　　實際上，早在 Docker 出現(xiàn)之前，網(wǎng)易云已經開始使用 LXC 技術來進行更細粒度的資源分配，實現(xiàn)了類似的容器技術棧，在此過程中，陳諤及其團隊親歷了 LXC 技術在實施的過程中各種問題和技術缺陷帶來的困擾。而 Docker 的橫空出世使得整個云計算領域眼前一亮。雖然網(wǎng)易云自建的技術棧已經可以滿足當時及近期業(yè)務的需求，但作為具有技術遠瞻力的技術負責人，陳諤知道，相比于得到業(yè)界普遍看好的 Docker，自研的專屬技術棧的生態(tài)環(huán)境狹窄，技術人員的培養(yǎng)成本也居高不下。而另外一方面，Docker 的鏡像機制、分層文件系統(tǒng)機制，也使得之前在 LXC 技術棧里面斬荊披棘的網(wǎng)易云似乎看到容器技術發(fā)展的堂皇大道，使用 Docker 也就變得順理成章。因此，網(wǎng)易云十分自然的就完成了從 LXC 向 Docker 的轉移。

　　我問及 Kubernetes 的選擇，陳諤笑了笑，他提到，網(wǎng)易云對于 Kubernetes 的支持是非常早的，在早期 Kubernetes、Swarm、Mesos 尚三足鼎立的時候，網(wǎng)易云就堅定的投入了 Kubernetes 生態(tài)。這一點和網(wǎng)易云過去在微服務、容器編排方面的實踐是密不可分的。Kubernetes 解決了網(wǎng)易云在過去運維過程中遇到的諸多問題：如何進行彈性伸縮、如何進行服務調度、如何使用配置來進行控制。Kubernetes 所提供的配置能力，特別適合于需要解決微服務架構編排問題的網(wǎng)易云。

　　對于網(wǎng)易云來說，他們并不是一個刻意追求新奇的團隊，相比于新興的技術，網(wǎng)易云更在乎什么能夠解決問題。顯然，對于微服務架構支持最好的 Kubernetes 成為最終之選。

　　網(wǎng)易云和很多云計算公司不同，沒有將目光全部投放在公有云上，而是專注于為企業(yè)提供業(yè)務云化的解決方案。網(wǎng)易云也和容器云廠商的定位不同，容器是網(wǎng)易云的產品，更是網(wǎng)易云的工具，因此網(wǎng)易云雖然很早就應用了 Docker、Kubernetes 等技術，但是并沒有突出這些看起來非常時髦的技術名詞，而是根據(jù)企業(yè)需求，更多的將這些作為服務于上層的微服務產品的基礎。通過結合容器的網(wǎng)絡方案、存儲方案等云原生技術積累，網(wǎng)易云希望更好的服務自己的客戶。

　　陳諤說，網(wǎng)易云之所以選擇了企業(yè)云的路線，更多是因為網(wǎng)易云發(fā)現(xiàn)自身更適合于在云原生領域深耕細作。與其在公有云的紅海中去競爭，不如在云原生領域去深入挖掘，提升技術和競爭力。這樣，就將競爭從 IaaS 層面，提升到了基于云原生體系的 PaaS 層面，避開了紅海的競爭。同時，這種基于 Kubernetes 標準化的 PaaS 服務，其生命力也遠超普通的 IaaS 產品，Kubernetes 的設計使得它能夠消除廠商鎖定，基于其實現(xiàn)的 PaaS 服務可以運行在任何一家 Kubernetes 服務商的云產品上。

　　陳諤還提到，作為一個面向企業(yè)提供解決方案的服務商，網(wǎng)易云和其他的容器云不同的是，更多是希望去靠近企業(yè)的 IT 的技術的認知，不會給企業(yè)造成過多的認知負擔和業(yè)務侵入性。在業(yè)務落地時，能夠根據(jù)企業(yè)的需要來不斷的完成落地，而不是從一開始就要求企業(yè)去實踐容器等，造成更大的負擔。如果不是企業(yè)的需求要做容器化的話，不會第一時間要求用戶完成容器化的遷移。但陳諤也發(fā)現(xiàn)，當用戶真正去實施微服務框架的時候，往往會考慮實施和部署容器化，這時，網(wǎng)易云早已準備好的容器平臺就可以很好的完成這部分的工作。

　　對于不希望進行容器化的企業(yè)，陳諤提到，網(wǎng)易云針對于這些異構的環(huán)境，也提供了不同的解決方案，諸如支持裸金屬集群和虛擬機環(huán)境的服務網(wǎng)格Service Mesh等能力，可以幫助那些不打算做容器化的企業(yè)完成自己的工作。

　　網(wǎng)易云希望自己的產品能夠基于客戶的 IT 策略來考慮，而不是將網(wǎng)易內部的實踐生搬硬套到客戶的業(yè)務中去。

　　在談到網(wǎng)易云內部的 DevOps 實踐時，陳諤提到，在網(wǎng)易云內部其實很早就開始進行了 DevOps 實踐。從 2014 年開始，網(wǎng)易云內部就開始推行服務化的組織架構和協(xié)作方式。在網(wǎng)易云內部，所有的工作都是接口先行，在網(wǎng)易云看到的每一個界面，都是先有接口，后有界面的。每一個接口背后都對應著網(wǎng)易云的一個服務以及對應的研發(fā)團隊。這樣從一開始，網(wǎng)易云就不設立專門的應用運維團隊來負責業(yè)務的發(fā)布和上線，而是由各服務團隊自行完成業(yè)務的發(fā)布和上線。除了 IaaS 層面基礎設施的運維有專門的 SRE 團隊來負責以外，各服務的運維都由各自團隊自行來負責，這使得對應的團隊必須自行解決運維需求。而且，為了更好的協(xié)作，網(wǎng)易云內部的所有的 API ，都會放在一個統(tǒng)一的 API 網(wǎng)關中，所有的用戶都可以借助 API 來完成自己想要的操作，而無需進行 Web 界面的操作。

　　我們還談到了 DevOps 和容器化的關系，在過去的一段時間里，宣傳上總是將二者聯(lián)系起來。在陳諤看來，容器化和 DevOps 的關系實際上是相輔相成的。

　　在他看來，之所以 DevOps 會出現(xiàn)，核心是隨著企業(yè)業(yè)務的不斷服務化拆分、微服務架構的實施，中心化的運維成為瓶頸，這使得企業(yè)不得不去提升運維的能力，去招募更多的運維。但是基于企業(yè)成本的考慮，運維人員的數(shù)量終歸是有限的，因此有一些開發(fā)人員不得不兼任運維工作。但是，開發(fā)人員在運維方面的思路、關注點、風險意識上和傳統(tǒng)運維人員存在一定差異，基于這樣的考慮，需要一批工具來輔助開發(fā)人員進行運維工作，規(guī)范開發(fā)人員可以做的事情。在這樣的一個大背景下，容器技術應運而生了。他相信，即使沒有 Docker 公司搞出了容器化，也會有其他的公司來做出類似的產品，不同的只不過是各家的方案的優(yōu)劣罷了。

　　此次會見陳諤是在網(wǎng)易云創(chuàng)峰會上，而此次大會濃墨重彩介紹的產品之一就是網(wǎng)易輕舟微服務。

　　輕舟微服務是網(wǎng)易云在完成了基礎設施的 Docker、Kubernetes 等改造完成后，基于對業(yè)界的分析和研究后提出來的。出于標準化技術棧的考慮，網(wǎng)易云最終啟動了輕舟微服務的項目，將現(xiàn)有的技術棧，打造成一個個獨立的標準化技術產品。到了 2018 年，在完成了對所有技術棧的標準化以后，將輕舟微服務發(fā)布了出來。

　　陳諤認為，異構系統(tǒng)整合，包括兼容、通信和系統(tǒng)間事務一致性，和多供應商建設，包括多團隊協(xié)作、軟件資產沉淀，是目前企業(yè)在建設在線業(yè)務中臺過程中遇到的最大障礙，而網(wǎng)易輕舟微服務新品的發(fā)布，正是要通過服務網(wǎng)格、分布式事務框架 GTXS、全新 API 網(wǎng)關與原有輕舟產品的整合，完成全�；�在線中臺技術體系升級，幫助企業(yè)完成業(yè)務架構的進化，支撐業(yè)務快速創(chuàng)新。

　

　　網(wǎng)易云陳諤和老王

　　陳諤介紹，輕舟服務網(wǎng)格是基于 Istio 和 CNCF 的 Envoy 等主流開源技術構建，可以實現(xiàn)  Java、Python、NodeJS、Golang 和 PHP 等不同技術棧的兼容和通信，能夠與網(wǎng)易已有微服務框架 NSF 統(tǒng)一管控、互相發(fā)現(xiàn)、互相調用，并且支持容器、虛擬機和裸機部署，將異構系統(tǒng)的支持實現(xiàn)到了業(yè)界領先的程度。

　　在陳諤看來，輕舟微服務的推出，是網(wǎng)易云內部的微服務能力的對外輸出，是網(wǎng)易云內部技術能力的輸出體系，針對企業(yè)客戶，提供了一整套的技術方案，以及對應的咨詢服務和最佳實踐的指導，幫助先前沒有足夠能力獨力完成微服務化的企業(yè)，完成企業(yè)產品和服務的微服務化。

　　很多企業(yè)的獨石應用Monolithic applications隨著企業(yè)的發(fā)展和產品的變遷，都面臨新的挑戰(zhàn)，而微服務化改造是企業(yè)所寄予眾望的一條發(fā)展路徑。但或因為微服務的技術儲備不足，或因為既有業(yè)務的歷史包袱過重，企業(yè)自行開發(fā)微服務體系不但耗時周期過長，而且可能因經驗不足而走了彎路，因此，網(wǎng)易云在推出了輕舟微服務以后，贏得了不少企業(yè)用戶的關注。

　　在實際的使用過程中，輕舟的部署也幫助企業(yè)大幅度提升了新業(yè)務接入的效率和版本發(fā)布的效率。舉個例子來說，如果同時有數(shù)十個微服務的不同版本在開發(fā)，在傳統(tǒng)的模式下，就需要提供數(shù)十個測試環(huán)境來完成測試，但在輕舟下，就可以基于無侵入的流量染色功能重用一套測試環(huán)境，僅將測試流量路由至特定版本微服務，降低了環(huán)境的成本。

　　由于我離開了中國電信好幾年了，近些年我對企業(yè)級產品和服務接觸并不太多。而這次的采訪，使得我對于一直以來缺少了解的網(wǎng)易云和其產品有了更深刻的認識。顯然，網(wǎng)易云在這場云計算大潮中，找到了企業(yè)界真正的痛點，關注到了眾多企業(yè)的真實需求，這種深耕的思路，一方面讓網(wǎng)易云支撐起來網(wǎng)易云音樂、網(wǎng)易考拉等明星產品，另外一方面也使得網(wǎng)易云在企業(yè)上云和 IT 現(xiàn)代化方面不斷攻城略地，取得不菲的成果，這值得云計算領域的細分廠商學習。

　　“穿山甲專訪”欄目是 Linux 中國社區(qū)推出的面向開源界、互聯(lián)網(wǎng)技術圈的重要領軍人物的系列采訪，將為大家介紹中國開源領域中一些積極推動開源，諳熟開源思想的技術人，并辨析其思考、挖掘其動因，揭示其背后所發(fā)生的事情，為關注開源、有志于開源的企業(yè)和技術人標出一條路徑。

　　取名為“穿山甲”寓意有二：取穿山甲挖掘、深入之意來象征技術進步和表征技術領袖的作用；穿山甲是珍稀保護動物，宣傳公益。