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

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

雲原生是什麼？

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

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

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

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

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

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

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

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

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

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

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

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

京東為什麼做雲原生？

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

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

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

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

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

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

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

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

容器化 · 京東雲容器部署 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、記憶體、語言平臺等執行環境，使用者完全不用關心程式碼執行在什麼地方。

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

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

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

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

在IaaS層，持續提供高可靠性、高靈活性、高擴充套件能力、高效能的基礎設施，能夠更好的運行雲原生的各種任務，比如說函式計算等。
在PaaS層，讓使用者更便利的使用雲原生生態，比如服務治理、服務網格等方面的產品都能為使用者提供便捷。

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

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

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

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

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

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

RECOMMEND

推薦閱讀

這大概是今年介紹雲原生最清晰明瞭的文章!

乾貨 | 京東雲Kubernetes叢集最佳實踐

線上公開課 | 從理論走向實踐，多角度詳解Cloud Native