沙龍回顧丨雲計算進入多元架構,雲原生時代的挑戰與機遇

近日,京東雲聯合英特爾舉辦“破局丨雲原生時代IT基礎設施變革”技術沙龍,來自京東的4位技術大咖分別就混合多雲基礎發展趨勢、京東在大規模集羣管理的遇到的問題及解決方式、京東DevOps破局以及混合多雲下PaaS組件接入的挑戰及難點等話題展開分享,揭祕混合多雲基礎設施的發展與變革,爲企業數字化轉型提供借鑑意義。

雲原生的出現,帶來了一種新的建設思路和開發模式。從技術特徵來看,雲原生所具備極致的彈性能力、服務自治故障自愈能力、大規模可複製能力,極大發揮了雲的優勢,提升業務應用的迭代速度,加速數字基礎設施升級。而今越來越多的企業願意技術架構向“雲原生”演進,Gartner報告就曾預測到2022 年,將有75%的全球化企業將在生產中使用雲原生的容器化應用。

隨着雲原生的持續升溫,它跨過了概念階段,逐漸的進入到了應用落地的快速發展期,越來越多的企業意識到僅改變IT基礎設施已經無法滿足當前業務需求,也難以快速應對多方面的挑戰,如何高效管理多種基礎設施?如何在應用開發及業務創新層面實現運營效率提升?本期沙龍與開發者進行了深入的互動和技術交流。下文是由四位老師演講內容整理而成:

1/混合多雲基礎設施的未來

image.png

京東雲事業羣高級總監 何小鋒

IT基礎設施指用於支持政府、企業級特殊需求個體的IT環境所需要的一系列IT硬件資源及基礎軟件的集合,主要包括計算資源、存儲資源、網絡資源、實現虛擬化及管理服務器的底層軟件。按照部署環境的不同,IT基礎設施可劃分爲傳統IT基礎設施和雲基礎設施。部署在非雲環境下的基礎設施爲傳統IT基礎設施,部署在雲計算環境下成爲雲基礎設施,其中雲基礎設施可以繼續分爲公有云基礎設施和私有云基礎設施。


企業數字化轉型的需求、雲計算技術的不斷成熟並在各個行業的持續滲透,大數據、人工智能、物聯網等技術持續創新也給雲計算服務帶來更大的市場發展空間,《Frost&Sullivan》研究報告曾預測:中國的雲基礎設施市場的年複合增長速度將達到 37.0%,並在 2023 年達到 4935.9億元的市場規模。

image.png

《Frost&Sullivan》研究報告

 

混合多雲發展趨勢

伴隨着IT基礎設施的高速增長,混合多雲的理念持續深入,依託多雲管理、雲網協同、安全能力的提升,越來越多的企業願意採用混合雲部署方式。

從我國政策方面看,“十四五”規劃和2035年遠景目標綱要草案中將“加快數字發展,建設數字中國”作爲獨立篇章,描繪了未來五年數字中國建設的新藍圖。具體到雲計算產業,規劃綱要草案指出,要加快推進雲操作系統迭代升級,推動超大規模分佈式存儲、彈性計算、數據虛擬隔離等技術創新,提高雲安全水平,並以混合云爲重點培育行業解決方案、系統集成、運維管理等雲服務產業。

從行業的發展趨勢上看,在全球範圍內,混合雲已經成爲企業用雲的主要形式。從國內市場來看,企業應用混合雲的比例仍處於較低水平,但有很大潛力和成長空間。據《Flexera:2020年雲計算報告》調查顯示,86%的企業正在使用多個公有云服務;60%的企業報告使用多個私有云;53%的企業同時使用多種公有云和私有云的混合。

image.png

Flexera:2020年雲計算報告

企業在使用混合雲的過程中也面臨挑戰,一方面,多雲架構的複雜性帶來多雲管理的複雜性。

另一方面,多雲管理工具對於經濟高效地管理雲資源以及確保強大的治理和安全性至關重要,然而,只有三分之一的組織在利用多雲管理工具。

雲原生混合多雲管理平臺-京東云云艦

隨着數字化時代的到來,混合雲已經成了兵家必爭之地,頭部雲廠商持續在混合雲加大投入。企業在選擇混合雲廠商會面臨三個問題:

1、不同的雲廠商提供過的服務能力、PaaS不一致

2、容易被公有云廠商鎖定,成本高,不能方便的進行跨雲遷移

3、沒有一致的用戶體驗,對開發者不友好,交付效率不高。

雲原生作爲雲計算下一代技術基礎,已成爲事實標準,憑藉其極致的彈性能力、服務自治故障自愈能力、大規模可複製能力、異構資源標準化的架構特性可以有效解決上述面臨的三個問題,並快速幫助企業實現數字化轉型。

京東是雲原生最早的實踐者和受益者之一。早在2014年,京東就率先將Docker容器技術大規模應用至生產環境。2016年成功從OpenStack切換到JDOS 2.0的Kubernetes技術棧,打造了完整高效的PaaS平臺。基於內部實踐和技術積累,京東雲構建了雲原生混合多雲管理平臺——京東云云艦。雲艦提供一致的容器運行環境(COS) 、PaaS能力(T-PaaS)和應用開發運行平臺(DevOps) 。基於京東多年雲原生的大規模容器、PaaS、DevOps和微服務實踐,幫助客戶構建雲計算場景,在異構基礎設施上提供一致的能力,簡化跨雲遷移,可以真正做到“上的去,下的來”

2/京東零售雲原生介紹與案例

image.png

京東零售Kubernetes負責人  周光

 

京東雲原生平臺演進之路

京東的容器建設始於2014年,作爲國內最早大規模在生產環境進行容器化部署的公司之一,京東的雲原生平臺JDOS演進也經歷了幾個階段,2014年基於Openstack的JDOS1.0上線,實現了業務隔離;2015年經歷了618和11.11兩次大促的考驗,具備了秒級伸縮功能;2016年完備了鏡像中心和監控體系並持續對網絡和存儲層進行優化;2017年擁抱開源,大規模使用Kubernetes,形成了以kubernetes爲基礎的應用容器平臺JDOS 2.0;2018年上線阿基米德調度體系,基於應用特性做持續優化;從2019年開始,我們的雲原生平臺開始支持大數據相關的業務,在離線計算、在線計算都有一些成果;2020年在跨集羣、跨機房等這些保障方面做了一些工作。

目前,業務層面來看,目前京東商城核心交易都跑在雲原生平臺上;集團內的供應鏈、物流等業務也都在使用JDOS平臺;技術層面來看,京東自己的基礎中間件包括數據庫業務、分佈式緩存、消息系統等也全部使用容器化在管理;一些計算系統相關的,例如離線計算、AI算力相關的系統也正在全面擁抱容器化。

京東如何用雲原生關鍵技術實踐賦能技術團隊

先說一下大家都比較關注的流水線發佈。理想的狀態,應用部署在測試環節通過的情況下就可以直接上線,但真實的情況是面對京東非常複雜的核心繫統,上線步驟非常多,測試環境通過通過了部署到生產環境還會不會出現意想不到的問題,需要預熱的緩存不預熱會不會出現什麼問題,這些情況如果人工驗證需要花費大量的人力成本,所以我們必須基於容器構建高效的流水線。那麼我們現在的流水線發佈具備以下3個特點:
1、流水線僅需簡單配置即可自動化完成摘量、更新、校驗、自動化測試、掛量等操作,達到快速部署、敏捷試錯。

2、支持自定義流水線、自定義流水線節點,且流水線在設計時增加外部接入點,方便將各研發團隊的能力集成到流水線中,確保產品的能夠高可用、可持續、高質量且安全的快速交付價值。

3、支持多種項目管理系統的對接集成,通過API接口調用、JSF接口形式以及JMQ消息的形式完成對接,貫穿項目需求、任務、人員同持續集成環節的信息流,完整的管理整個項目生命週期。

再談一下大家比較關注的中間件部署。京東的基礎服務全部基於微服務來做,目前也在大規模使用service mesh,基於容器平臺我們可以快速完成單元化部署,在不同城市的機房可以分發流量到不同的單元,在大促的時候,這種方式可以保障系統的穩定和快速切換。

最後說一下京東的阿基米德調度。京東有大量的服務器資源,以往在大促前各個業務主要靠新增機器來應對高峯的瞬時流量,應用業務系統資源申請量和使用量之間差距巨大,同時,資源使用呈現明顯的高峯低谷,不同的機器的資源使用率差距較大。而且也面臨着資源碎片和時空不均的情況。阿基米德調度是怎麼解決這些問題的呢?

1、基於預測的智能調度:利用機器學習、深度學習算法,對應用的資源使用情況進行畫像統計,並能對應用的未來資源使用情況進行預測,將在線與離線應用合理的進行混合調度部署。
2、監控指標的精準驅逐與碎片整理:由於不同批次採購的服務器規格性能不同,通過批處理任務進行統一填充式調度,以達到資源碎片的填充利用和資源的時空複用的效果。
3、調度器仿真系統及回放功能:通過模擬器+線上數據回放,對調度請求進行仿真模擬,形成新的數據建模,並優化調度方案,爲智能調度提供更優方案。

京東通過阿基米德平臺的高效調度實現靈活高效的IT基礎設施,提升行業資源效率,降低IT成本,將其打造成爲行業的公共基礎設施服務,實現行業共享的價值最大化。

京東如何用雲原生關鍵技術實踐賦能技術團隊

最後我們通過一個案例,來看下基於雲原生平臺,京東是怎麼部署實時計算和離線計算的。

image.png

京東的實時計算體量很大,目前都是部署在雲原生平臺上來做,我們現在要保證的是實時計算系統在平臺上的穩定性,這是非常難的一點,因爲實時計算系統和一般的應用不同,舉例來說,當機器故障、磁盤有問題、CPU負載等狀態時,容器會受到影響,部署在容器上的實時計算就會變慢,這個時候就需要我們介入去分析這個影響。比如CPU達到一定的異常負載,就應該驅除這種負載,但是對驅除要有一個分析,比如在線的應用,因爲可以實時感知到流量的變化去進行自動調動,就不需要驅逐。而且驅逐要分層,實時計算可能有社會級、公司級、部門級,我們研究不同的級別,從低往高進行批量適當的分步驟的進行驅逐,以達到容器運行的穩定。這是容器和實時計算結合的一個難點。

接下來再說離線計算,我們先看一張圖。

image.png

左邊這種圖顯示,在凌晨的時候,因爲要計算前一天的各種數據各種報表,離線系統的CPU使用率會飆高。而右邊的圖展示了商城交易業務因爲在凌晨使用的人少,所以CPU使用率極低。那麼是否可以通過容器進行調度,把凌晨閒置的交易業務的CPU資源調度起來支持離線計算系統,保證離線計算不受影響支持業務?

在把這種美好的想法落地的時候還是遇到了一些坑,第一個問題就是磁盤,當時資源調度的主要是批處理的業務,這種任務對磁盤的容量要求不太大,但是對磁盤I/O要求很高,這就擠佔了原本跑在上邊的在線敏感業務,所以我們按照容器級別對I/O進行了控制,通過對不同業務的I/O進行控制,保證在不影響在線業務的情況下調配資源給遷移過來的離線任務,增加混部密度。

第二個問題是CPU的分級調度,雖然在系統層面我們做了一些控制但是先計算調度過來還是對系統有衝擊,比如CPU利用率會飆升,我們通過降低離線的任務的CPU權重,實現Job調度類,來管理離線業務。如圖所示進行離線任務的分級和控制,可以在在線業務服務質量的不下降的前提下,提高整機CPU利用率,達到降本增效的目的。

最後一塊是網絡,調度過程中有可能引起網絡的堵塞和抖動影響到在線業務。我們通過兩個方式來解決這個問題,一個是業務分級,在容器內對業務打標,保證在線業務的高優先級在node節點優先轉發並確保交換機的轉發策略一致;第二是業務限流,對同一優先級pod總流量限流和針對單一pod限流來解決網絡帶來的問題。

最後總結一下,經過7年的技術演進,我們支撐了京東零售百萬級的容器部署、調度和穩定性的挑戰,幫助業務技術團隊具備編譯構建、流水線發佈、中間件部署、serverless等關鍵技術實踐,很好地支撐了業務的發展。同時也積極探索在大數據和AI系統的雲原生化,爲降本增效做出了很好的實踐。

3/DevOps高效研發破局之道 

image.png

京東雲事業羣總監  賀玉芝

數字化時代,政企客戶軟件交付普遍會面臨人員能力不足、工程管理規範混亂、工具選擇和維護成本高等普遍困境。那麼在這種困境下,企業如何實現上下同如何敏捷轉型?如何按需交付實現更快的價值?質量效率和穩定性到底如何更好的提升?這是政企客戶面臨的一個巨大難題。接下來將通過幾個方面來詮釋京東如何探索解決這些問題的。

京東DevOps高效研發破局之道

image.png

 

上圖是京東高效交付的黃金三角鏈路,我們提供一站式覆蓋軟件交付的整個全生命週期的DevOps工具平臺,基於工具平臺提供的DevOps能力可以支撐京東萬人研發去建機制,組流程,落實踐,並且效能度量又可以利用數據反向驅動效能提升,實現效能的閉環。這個黃金三角鏈路目前支撐京東近兩萬研發的管理和工程實踐,目前在系統裏承載的項目數和應用數達到三萬,單日部署九千多次,這幫助我們實現了更快更可靠,端到端可持續的交付價值。

image.png

上圖是DevOps落地全景圖,從過程改進角度看,我們的平臺功能模塊覆蓋需求管理、研發過程管理、敏捷開發、測試、發佈、運維運營及整個軟件交付生命週期管理。在此功能之上,需求統一收口、透明可視化流程流轉、需求透明流轉和跟蹤以及研發過程管理如何靈活的排兵佈陣,均是能夠從源頭保證資源靈活調整,實現資源最大化。

從工程實踐角度看,京東在開發、測試和運維也有着豐富的最佳實踐落地,比如需求和代碼、流水線、發佈、測試、上線等實現雙向的關聯,或者是代碼提交後自動驅動觸發持續集成,持續部署、持續交付,同時京東也在持續關注整個研發交付週期裏的交付效率和交付能力,形成全集團的統一標準。

支撐萬人研發的管理和工程實踐

當業務複雜到一定程度,協作的團隊越來越多,能否保證拉通需求和研發,能否保證在敏捷研發的體系下協同成爲了最大的難題。京東是如何做的呢?

image.png

如上圖所示,協同的最頂層是戰略協同,那麼從戰略開始就需要通過OKR層層分解,用項目支撐OKR落地。同時,也要從組織的角度自上而下的關注業務的價值,做統一的產品需求規劃,包括業務需求、用戶需求、產品需求等,也要做層層拆分,將不同的子需求受理到不同的研發團隊支撐它流轉、迭代、發佈上線、度量、運營等,保證需求和研發打通,形成業務閉環。

從組織協同角度,需求流轉時,支持跨企業跨部門跨項目跨產品流轉,在縱向可以看到通過項目去管理項目的範圍、進度、成本、質量、風險,實現敏態&穩態項目管理的雙模,從工程實踐角度,去雙向關聯代碼,實現所有過程的流轉都是可追溯的,最後以一個全局的視角去關注用戶價值以及研發整個鏈路中的各個環節。

通過這套機制,可以在大型研發組織中打破“組織煙囪”,確保需求在研發流程中正常流轉,讓研發團隊目標對齊,協同爲用戶提供價值。

支撐萬人研發的效能度量體系

數字化轉型過程中,研發效能成爲企業核心競爭力。京東的研發效能度量工具,目標是希望高效交付用戶價值,讓研發效能可量化、可分析、可提升。所以在流程方面,首先定義了核心效能指標,通過結果指標評估結果,通過過程指標指導改進,同時建立了價值流交付模型,通過度量平臺採集DevOps工具網絡的各類數據,形成度量報表。基於效能分析模型逐層下鑽,找到影響效率或質量的根因,最終去量化驅動改進。

image.png

 

圖是效能度量平臺的邏輯架構,總體分爲四層。接入層支持JDBC等不同方式的數據接入;存儲層對維度表、彙總表進行匯聚,形成各項指標;在統計分析層做實時處理、離線處理或者智能分析、效能告警,最終在展現層爲不同的用戶,包括管理者、最高決策層、業務負責人,最終提供一個全鏈路、多層級、多角色、多維度的效能報表。

image.png

上圖是效能度量指標全景圖,京東從業務價值、交付成本、客戶滿意度三點出發的,持續關注交付效率、交付質量和交付能力。左邊的指標體系及右邊的最佳實踐是相輔相成的,指標的提升可以通過最佳實踐來輔助效能做提升。除了度量指標全景圖外,研發效能度量平臺多層級儀表盤支持多層級,同時還提供了自定義報表的功能,也就是大家熟知的BI報表的能力。

image.png

針對不同層級關心的指標不同,我們也設置了個性化的儀表盤幫助他們各取所需,提升最核心的指標。

京東DevOps一體化平臺

根據Forester報告,42%的企業的痛點是需要整合企業內部既有的4到10個DevOps工具;而根據Gartner的報告,70%的企業需要用業務價值流驅動實現更快交付。京東DevOps平臺也經歷了從信息化過渡到平臺化演進到數智化的階段。

image.png

上圖是DevOps平臺的整體架構,這裏引入了DDD建模思想。在底層我們把通用的支撐領域下沉,成爲平臺基礎組件,實現業務領域的所有的組件都複用基礎組件;核心業務領域我們採用的是前後端分離的架構,在前端我們採用微前端的架構,後端我們採用微服務的架構。

基於這種架構,讓DevOps平臺具備了完備的可配置性和可擴展性:平臺底座基於微前端架構,通過組件化技術,支持用戶自研組件的註冊、熱插拔,能方便、快捷地集成私有化用戶的自研系統;可二次開發功能擴展點,滿足個性化業務功能需求。流水線具有豐富的原子能力,如編譯、部署、測試以及常用工具(sh/mail等),並支持用戶自定義原子能力。

最後總結一下,京東雲DevOps平臺-行雲統一支撐京東集團內部,包含京東零售/科技 /物流/保險等多種業態;通過京東高效交付的黃金三角鏈路,幫助企業內部拉通研發和需求,讓大規模協同成爲可能;通過建立科學的度量體系,幫助團隊識別研發瓶頸,解決研發效能的痛點;而具備Open API、插件生態、組件化能力和多層級選線管控的DevOps數智化基礎設施是支撐這一切的基石。

4/基於雲原生技術打造的混合多雲統一PaaS能力

image.png

京東雲事業羣總監  王碧波

隨着越來越多的企業擁抱雲原生,混合多雲開始成爲主流場景,同時也是非常複雜的場景。當PaaS遇到混合多雲時,會出現一些痛點,總結起來3大類:PaaS能力不足、多雲PaaS能力不統一、PaaS能力不夠雲原生。爲了解決這些痛點,一般會採用五種解決方案,這些方案各有優劣,京東採用的是“雲原生平臺+PaaS市場”的方案。

構建雲艦TPaaS技術中臺一站式解決混合多雲挑戰

採用“雲原生平臺+PaaS市場”方法,可以在各種私有云、多雲、混合雲環境爲客戶提供一致的數據庫和中間件等各類基礎技術組件能力,我們將其取名爲雲艦-TPaaS。

因爲京東PaaS能力非常多,將這些PaaS能力以統一的方式提供出來,就要選擇非常好的基礎、非常統一的方式來做。在這個基礎上將PaaS運維運行需要的標準能力,以統一的方式接入到市場裏面,接入後PaaS能力可以以非常靈活的方式按需使用。

雲艦-TPaaS支持各種主流公有云、私有云、物理機、虛擬機,支持各種網絡模型、存儲模型,支持多雲多集羣的管理。既支持創建京東的K8S集羣,也可以基於各家雲平臺去創建京東K8S集羣;還可以對接各家雲平臺的API接口,實現集羣自動創建自動伸縮,同時也支持納管客戶已有的標準集羣。背後的實現是基於社區的Cluster API來實現的,它通過提供聲明式API和工具,來簡化集羣的部署和整個生命週期的管理。

京東基於這套工具來實現擴展的技術架構的支持。它定義集羣、機器這樣一些標準的模型,針對標準模型實現標準控制器,用這些控制器來根據聲明的集羣聲明,自動將集羣構建出來。實現裏面每一種雲的基礎設施都可以有自己的描述,然後針對定義的描述可以實現相應雲基礎設施的協同。

隨後,王碧波老師分享了五個TPaaS組件示例,PostgreSQL、Redis、ChubaoFS、SGM、MPaaS,通過組件的特性展示了基於雲艦是如何通過大量雲原生TPaaS組件統一混合多雲場景的PaaS能力。

雲艦TPaaS如何賦能業務場景

先說雲艦TPaaS如何解決京東內部的多場景統一架構場景的。京東有龐大的內部系統,需要基於物理基礎設施部署PaaS能力;又有公有云產品,需要基於IaaS環境之上的PaaS能力;同時各類京東產品的對外賦能又需要將PaaS部署在客戶各種已有基礎設施之上。這些不同場景在之前應用的不同的技術棧,導致研發、運維工作無法對齊。通過我們把PaaS能力搬到標準k8s之上,我們這三塊的需求實現多場景的統一架構,在這三套裏面都是基於同一套平臺去運行同樣的基礎的組件,通過這種方式實現技術架構的統一以及研發成本的節約,也保證了運行的穩定性,降低了交付難度。

image.png

再來看一個增強私有云能力的案例。客戶在自有的私有云上面建設了Kubernetes集羣,但部署的數據庫和中間件都是開源的組件,沒有專業的技術人員能深入瞭解所使用的開源組件,導致他們的數據庫、中間件在穩定性上一直存在問題,同時也缺乏系統的管理能力。客戶接入雲艦平臺TpaaS後,利用TpaaS數據庫和中間件的組件,使它整套系統的穩定性、性能、管控能力有了很大的提升,可以更高性能、更穩定的支撐新的業務。

image.png

最後再看一個多雲統一平臺的案例。客戶原來只使用一家公有云,隨着業務的擴張,原有公有云服務商從產品到服務再到價格都出現了很多問題。但是因爲客戶使用了這家公有云特有的PaaS產品,導致切換雲服務商或者採用第二家雲服務商非常困難,從而也無法進行成本優化。爲了解決多雲的問題,在部署了雲艦TPaaS後,將新業務切換到在公有云上使用雲艦TPaaS,這樣就在多個公有云上有了一套統一的容器PaaS和DevOps能力,解綁了單一公有云的限制。後續也會在私有云上也接入雲艦平臺TpaaS,真正實現了混合多雲的統一能力。

image.png

總之,在混合多雲的場景裏,原有的PaaS使用方式有很多問題,我們選擇了Kubernetes作爲一個新的雲時代的操作系統的底座,把我們所有的PaaS能力搬到Kubernetes上,然後以雲原生Kubernetes的技術和理念去重新實現整套PaaS的能力,從而使我們整套PaaS能力既可以去補充客戶現有的IaaS能力的不足,也可以幫助客戶把業務實現混合多雲的架構,還可以幫助客戶的業務能力在他的客戶那裏做私有化的部署。

數智化的浪潮已來臨,我們每個人身處其中。從生產、經貿、研發再到生活的方方面面,京東雲正在全方位賦能產,創造更價值未來,京東雲還將開放哪些技術和能力,幫助傳統企業抓住轉型的機遇,讓我們拭目以待。

點擊查看技術沙龍視頻回放,回覆關鍵詞“PPT210327”獲取演講 PPT和視頻資料。

圖片

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章