專訪京東雲：願雲原生不再只有Kubernetes

作者丨Linda

從 2013 年，雲原生（Cloud Native）的概念由 Pivotal 的 MattStine 首次提出，到現在，其技術細節不斷得到社區的完善。雲原生逐漸演變出包括 DevOps、持續交付、微服務、容器、敏捷基礎設施等內容，也形成了一種團隊、文化、技術組織形式和管理方法。企業採用雲原生來構建應用，可以更好地把業務生於“雲”或遷移到雲平台，從而享受“雲”的高效和持續的服務能力。

那麽雲原生究竟有哪些神奇的力量？雲原生技術的發展又面臨著怎樣的境況？京東作為 CNCF 雲原生基金會的白金會員，又是如何利用自身業務場景優勢來推動開源技術的應用實踐？為此 InfoQ 採訪了京東雲產品研發部專家架構師劉俊輝。

1

雲原生是什麽？

在雲原生技術全面爆發之前，我們開發的應用可以被稱為非雲原生應用，非雲原生應用並沒有考慮到應用的彈性和規模性，甚至很多都不具備擴展性，當業務規模擴大時，特別依賴硬體的升級，進而帶來了巨大的成本問題。

相比於傳統開發，雲原生的核心優勢是：

靈活性，可以隨意組合各種應用，通常是基於容器的應用；

彈性，可以按需使用雲的資源，節約成本；

規模性，不再受傳統機房物理機的限制，在雲上幾乎可以做到無限擴展。

除了利用雲本身的特點外，雲原生在成本上、規模上都能更好的適應企業未來發展。

當然，也不排除一些公司上雲後並未明顯降低成本，這類公司業務通常是非常穩定的，並且可預測在未來不會有爆發性增長的需求，那麽企業運維原有的硬體以及維持一個穩定的團隊就足夠了。而真正的互聯網公司，對用戶增長的期待一定是指數級的，這樣就要盡早考慮雲原生的應用。

其實，在國內談雲原生是比較前沿的。

現在的互聯網企業領導者，或多或少會意識到雲或雲原生的價值，但是多和少的程度差別很大，新興的互聯網公司基本上可以 100% 的擁抱雲原生，但老牌企業對傳統架構進行轉型時就會遇到各種問題。

企業上雲可能面臨著三方面的需求：應用的技術改造、人員的技能升級、管理者的觀念轉變。

這三個需求是由易到難的。這其中最困難的就是管理者的觀念轉變，因為決心難下，決定難做。轉變就意味著投入，意味著調整，意味著在短期內可能看不到收益並且會有較大的投入或者是生產力的下降。

如果領導者下定決心去做，還能給企業人員一定的時間去學習、轉型新技能，這之後遇到的技術問題將會是最容易解決的問題。

2

京東為什麽做雲原生？

京東雲，作為具有強產業屬性的雲智能廠商，在雲原生技術的大量投入來自於自身業務的需求，在每年的京東 6.18、京東 11.11 電商促銷季的海量數據和洪水般的流量面前，從電商的前端網站、訂單、結算、支付、搜索、推薦，到後端的倉儲、配送、客服、售後，以及采銷人員使用的各種業務系統都面臨前所未有的挑戰。京東幾千個系統，幾萬個應用，每一個環節正常工作才能保證整體業務順利運行。

因此，京東雲需要一個靈活的、有彈性的、可規模化的平台，這是對雲原生的天然需求。同時，京東雲也要有自己的架構模式，並向著 100% 雲原生努力著。

目前京東雲的實踐主要分成三個階段：

第一階段，在京東雲剛起步時，大量參考了 OpenStack 的實現，基本上是定製化的 OpenStack。之後在使用過程中暴露出的問題比較多，其中一個重大問題是雲原生的規模化，當規模迅速提升時，OpenStack 已經無法滿足需求，會出現各類問題，包括穩定性問題、數據一致性問題等；

第二階段，京東雲用自己研發的組件完全替代了 OpenStack，在這個過程中，一部分業務做到了容器化，並在此期間研發了原生容器容器技術。原生容器可以看作使用容器鏡像的虛擬機。相對於虛擬機更輕量化，能更快捷的啟動；相對於 Docker 容器，能更好的實現安全性和隔離性；

第三階段，也是目前正在做的階段，京東雲希望把所有的業務都容器化、Kubernetes 化，以便擁有快速、一致性的部署能力。

由於用戶規模和業務量龐大，京東雲在運行大規模集群方面也積累了不少經驗，尤其是在集群的可靠性、穩定性、數據的安全性方面表現突出。

3

京東在雲原生上有哪些技術突破？

容器化 ·京東雲容器部署 10x 加速

在傳統情況下，容器啟動時整個容器鏡像都要被加載完才能開始啟動的過程，但從抽樣調研的一些京東容器應用中發現，平均每個容器鏡像只有 10% 會在啟動階段被訪問到。京東雲所做的工作就是實現一邊加載一邊啟動，優先加載啟動所需要的部分，也就是說，典型情況下只要加載 10% 的鏡像的內容就可以完全啟動容器。

據了解，10x 加速的說法是從統計意義上定義的，不同業務模式的容器，啟動模式不同，加速效果也不同。比如在京東雲上運行機器學習的容器，它的鏡像的大小可能超過 10G，相應的啟動速度加速會更明顯。

微服務 · 架構拆分和粒度

企業是否採用微服務、什麽時候採用微服務、如何採用微服務的技術路線，一定是從需求出發的。如果企業是面向互聯網的，像電商、社交網站等，在用戶增長時一定會面臨大量問題，如果不用微服務會導致架構到某個階段被迫重構。但是對於一些客戶數量、模式比較固定的應用，就可以選擇其中具有彈性和規模性需求的部分應用先進行微服務化。

微服務的一個優點在於相互之間可以使用不同的開發語言，在處理不同的任務上發揮各自的優勢。同時，可以根據開發人員的能力，來決定以何種語言開發何種功能，借此來進行整體架構的拆分。

京東雲的微服務平台依托於京東的多可用區部署，可以實現跨可用區的分布式部署。用戶無需任何運維操作，就可以獲得跨機房的高可用性。此外，平台還將微服務框架、彈性部署、日誌分析等系統深度集成，一站式滿足各類運維需求。

自動化運維·雲原生 & DevOps

DevOps 和雲原生是相對獨立的關係，即使沒有雲原生，DevOps 依然是一個非常領先的一個理念。DevOps 存在的價值在於幫助互聯網公司快速的迭代，能讓用戶的需求能在第一時間被滿足，所以 DevOps 要求開發環境和運行環境的一致性，以及灰度發布等快速迭代的能力。

現在的互聯網公司每天發布幾十個變更已是常態，這幾十個變更不只在開發環境，還包括在生產環境中。這種發布變更的模式就是由 DevOps 能力提供的，如果能持續的發布變更，並且不影響用戶的使用，那麽企業就可以比其他的競爭者更好地滿足用戶需求。因此在京東雲，DevOps 和雲原生是非常好的協同關係，而並非強綁定的。

為了更好的在雲原生環境下實踐DevOps ，京東雲做了什麽？

京東雲的 DevOps 目前主要能夠提供全鏈路的部署、監控、運維、服務治理等解決方案，提升企業 DevOps 水準，實現研發、測試、運維高效協同，提升服務效率和整體穩定性。

京東雲提供了代碼倉庫、雲編譯、雲部署等 DevOps 各關鍵環節的產品解決方案，同時提供了代碼流水線產品將 DevOps 全流程貫穿起來，

京東雲提供的服務管理功能，能夠進一步提供基於服務樹的角色權限管理和機器、資源管理自動化運維服務，滿足各種複雜運維場景一鍵式作業，實現自動化運維。

在持續交付方面，基於 Kubernetes 的容器編排方案，提供從代碼編譯構建、部署、流量接入的持續交付流程，未來還將在網絡和調度層進一步進行定製化調優，更切合企業實際場景

另外，京東雲提供從基礎資源到服務可用性、服務性能和業務邏輯的全鏈路監控服務，支持多種類型的監控：基礎監控，進程 / 端口監控，域名監控，當機監控，日誌監控，組件監控，方法監控和自定義監控。進一步形成故障發現 – 故障定位 – 故障恢復整個故障生命周期閉環，降低 MTTR。

Serverless·函數計算和原生容器

通常，企業在建一個網站時，至少需要一個虛擬伺服器或是物理伺服器。但有了無伺服器架構的概念後，一些擁抱前沿技術的公司就把網站轉移到了無伺服器技術上。二者最大的區別是無伺服器的網站不再需要外部伺服器模塊，所有動態的內容、資源、框架類的部分靜態內容，都可以通過無伺服器提供。因此 Serverless 能夠幫助應用開發者擺脫伺服器等底層基礎設施管理的負擔，專注於業務層的創新。

無伺服器技術目前並無公認的定義，京東雲認為伺服器技術目前有三種實現：

第一種是真正的無伺服器，就是所謂的函數計算；

第二種是類似京東雲的原生容器，容器直接呈現給用戶，並且背後不需要有虛擬機來支持；

第三種是應用的比較廣泛的無伺服器，背後的虛擬機由雲廠商來提供，但是對用戶不可見，仍然是以虛擬機的方式來提供容器。

根據現在企業的運作模式不難判斷，無伺服器未來大部分會遷移到函數計算，至於以分離容器形式存在的無伺服器未來會不會保留，目前還沒有結論。

京東雲在無伺服器方面開放了兩個層面的服務：函數計算產品和原生容器，其主要考慮因素包括穩定性、可靠性和安全性，其中還包括規模化和快速部署能力。

函數計算方面，京東雲和 AWS 的 Lambda 以及 Azure 的 Function 類似，都是需要用戶提供一段代碼，這段代碼以 HTTP 的入口形式可以訪問。代碼可以用 Java 等多種語言寫出，處理完用戶請求後給出一定的反饋，整體代碼的生存周期就是請求的處理過程。代碼是由函數計算來提供包括 CPU、記憶體、語言平台等運行環境，用戶完全不用關心代碼運行在什麽地方。

當並發請求非常多時，平台就會運行這段代碼容器的多個副本，這樣就能做到：用戶無需預留計算資源，僅僅根據調用的時長、次數來付費。這種情況是目前為止計算資源能做到的最小化分配粒度。粒度越小時，越有可能填滿伺服器的計算能力，粒度越大，後期就可能有越多的計算能力被閑置。

此外，InfoQ 記者還了解到，目前京東雲比較關注的開源項目集中在 Kubernetes 生態，比如京東雲的原生容器與 Kubernetes 的結合，他們希望能將原生容器和 Kubernetes 通過一個比較緊密的方式結合在一起。比如在 Kubernetes 裡的 Kata Container，其在 Kubernetes 裡使用了更安全的容器；還有 Rancher Labs 基於 K8s 推出的輕量級的 Kubernetes 發行版 K3s，可以滿足在邊緣計算環境中運行在記憶體和處理能力受限的小型、易於管理的 Kubernetes 集群日益增長的需求。

4

京東雲在雲原生上的未來規劃

京東雲原生未來的整體規劃主要包括三個方面：

在 IaaS 層，持續提供高可靠性、高靈活性、高擴展能力、高性能的基礎設施，能夠更好的運行雲原生的各種任務，比如說函數計算等；

在 PaaS 層，讓用戶更便利的使用雲原生生態，比如服務治理、服務網格等方面的產品都能為用戶提供便捷；

在 DevOps 層，提供 DevOps 產品，其緊密集成了 IaaS 和 PaaS 的應用產品，讓用戶能有一個端到端的雲原生開發和運行環境。

在函數計算方面，京東雲目前主要通過函數服務和 API 網關構建後端，未來還將提供更加靈活的拓展架構，幫助用戶獲得更豐富和個性化的應用程序體驗。另外，目前京東雲能夠通過對象存儲上傳事件來觸發多個函數，完成實時圖片或文件篩選、轉存、創建縮略圖、轉換視頻編碼等處理分析，未來通過增強事件觸發機制，能讓用戶更快速部署複雜的應用與服務，構建更為彈性、可靠的後端系統。

在原生容器方面，京東的產品推出時 Kubernetes 還沒這麽流行。所以為了實現節點容量的無限大，是通過一個叫 virtul kubelet 的一個插件讓 Kubernetes 集群擁有一個虛擬節點。而如今，原生容器完全看用戶需求。如果是一次性的任務處理批量計算工作，這種方式是非常有效的；因為虛擬節點可能會在某些方面不能實現 Kubernetes 所有的接口，某些特殊應用可能需要一定的適配工作，例如 daemonset。京東雲正在考慮把原生容器運行的節點暴露出來，並提供和現在 Kubernetes 所有接口兼容的一個應用。而在 Docker 方面，京東雲希望能向輕量化發展，可以隨時創建、隨時銷毀，並且可以隨時隨地創建更多的副本。

在 DevOps 方面，京東雲會進一步提供一站式的 DevOps 服務，集成代碼、編譯、調試、部署、監控運維各個環節，降低用戶的遷移、使用門檻和使用成本。

在雲原生領域，軟體技術很少有像 Kubernetes 一樣在短短幾年時間就得到廣泛的支持的。當聊到雲原生的未來，劉俊輝談到：“雲原生裡 Kubernetes 是一個優秀的代表，但是他不能是唯一的代表，我們會有各種各樣的場景、各種各樣的需求，需要各種各樣的雲原生工具或者應用來完成。我希望能有與 Kubernetes 競爭的一個產品，讓大家有更多的選擇。同時，我也希望未來會有對電信平台應用、5G 應用、邊緣計算等更友好的雲原生平台的出現。”

劉俊輝，京東雲產品研發部專家架構師。對計算（虛機、容器）、網絡（傳統網絡及虛擬網絡）、存儲（雲硬碟及雲文件系統）產品有深入理解。擁有多項專利，涉及網絡、存儲及數據中心領域。