12月16-17日,由CNCF、網(wǎng)易數(shù)帆、VMware、PingCAP和阿里云聯(lián)合主辦2020 Cloud Native Day云原生生態(tài)大會線上召開,來自聯(lián)合主辦方及字節(jié)跳動、Zilliz、百勝中國等公司的17位重磅演講嘉賓,帶來2天主題分享,解析云原生領軍企業(yè)和組織、頭部用戶的云原生戰(zhàn)略與實踐,剖析云原生技術帶來的機遇與挑戰(zhàn),幫助云原生技術使用者和愛好者加深對技術的理解,同時推進云原生與企業(yè)IT的融合。
在大會的第一天,網(wǎng)易數(shù)帆輕舟事業(yè)部總經(jīng)理陳諤結合網(wǎng)易數(shù)帆旗下輕舟云原生平臺近五年來的三次重大技術變遷,分享了網(wǎng)易及廣大數(shù)字化進程中的企業(yè)在IT、業(yè)務架構上的需求演進背后的邏輯,軟件生產(chǎn)與云原生之間的關系,以及網(wǎng)易數(shù)帆對未來的思考。
陳諤將云原生軟件生產(chǎn)分為三個階段,包括業(yè)務架構微服務化階段、云計算操作系統(tǒng)階段和應用平臺階段,分別以服務治理與監(jiān)控體系建立、中間件全面融合Kubernetes、應用視圖與運維視圖分離為重要特征。他斷言,云原生的發(fā)展已經(jīng)歷了微服務階段,當前處于云操作系統(tǒng)階段,而應用平臺階段的發(fā)展也已經(jīng)起步并將是未來的發(fā)展方向。
云原生的起點:干掉微服務架構的復雜性
微服務階段技術演進的訴求發(fā)端于互聯(lián)網(wǎng)/移動互聯(lián)網(wǎng)的興盛,明晰于微服務架構的復雜性?；ヂ?lián)網(wǎng)時代,業(yè)務方需要在高度的業(yè)務復雜性下快速迭代軟件。陳諤指出,分而治之是最符合直覺的解決辦法,當時微服務架構也已被提出,但拆分后的技術復雜性是不可忽略的因素,需要和迭代效率放在一起來權衡。 而云計算的出現(xiàn)首先解決了碎片化的計算資源獲取問題,剩下的就基于云計算提供一個技術棧來應對微服務架構的復雜性。
針對上述問題,網(wǎng)易數(shù)帆在實踐的過程中逐漸形成了輕舟微服務平臺,包括API 網(wǎng)關、服務治理框架、持續(xù)交付服務、全鏈路應用監(jiān)控和分布式事務等五個組件。其中,持續(xù)交付平臺負責調(diào)用云計算接口準備計算資源,并將制品發(fā)布至云上的各個環(huán)境;API網(wǎng)關解決分散的微服務架構作為一個整體應用對外提供接口的問題;服務治理解決服務的注冊發(fā)現(xiàn)、以及服務間路由策略的問題;全鏈路監(jiān)控解決微服務的監(jiān)控診斷問題;分布式事務中間件解決了服務拆分后事務保障的難題。
高潮:云OS基于K8s整治資源管理,簡化環(huán)境維護
微服務大規(guī)模應用的后遺癥,就是計算資源的生命周期管理、運行時環(huán)境維護復雜以及資源利用率低下等。陳諤舉了兩個例子:一個是大促后彈性資源下線難,將一些節(jié)點下線,影響評估是否準確?服務的剩余副本數(shù)是否合理?服務是否能自動恢復到目標的副本數(shù)?另一個是調(diào)整集群調(diào)度分布困難,如希望將服務分布在不同的物理節(jié)點或邏輯上的服務分組,只能在靜態(tài)初始化時做到,一旦后續(xù)發(fā)生變更就無法很好保障。
容器、Kubernetes的出現(xiàn)使這些問題迎刃而解。容器鏡像帶來了層級化、易于組合/重用的優(yōu)勢,且管理便捷、可與調(diào)度、生命周期管理銜接;Kubernetes則帶來了L1 CMDB,精準維護集群狀態(tài)使調(diào)度策略變更、故障恢復、擴縮容等生命周期管理相關的操作得以實現(xiàn)自動化,同時還支持業(yè)務只需感知Kubernetes API而無需關注IaaS層API?；诖?網(wǎng)易數(shù)帆將業(yè)務、中間件等負載由Kubernetes支撐,并將微服務支撐能力下沉(即Service Mesh),形成一個云計算操作系統(tǒng)。
陳諤分享了網(wǎng)易數(shù)帆云操作系統(tǒng)的三個案例,包括網(wǎng)易內(nèi)部網(wǎng)易內(nèi)部的資源利用率優(yōu)化、高新制造業(yè)客戶的多云管理以及企業(yè)的軟件供應商環(huán)境統(tǒng)一等實踐。(詳情請關注后續(xù)視頻回放。)
云原生未來:應用平臺助推軟件生產(chǎn)能力普惠
網(wǎng)易數(shù)帆在實踐云OS的過程中也發(fā)現(xiàn)了新的問題和新的機遇。
問題是開發(fā)人員的技術棧負擔過重,微服務架構的采用使得中心化的運維職責部分(如容量規(guī)劃以及調(diào)度策略、網(wǎng)絡、存儲配置等)卸載到了研發(fā)角色,而研發(fā)普遍不擅長處理這些工作,“然而我們認為軟件生產(chǎn)能力的提升不應以技術門檻的提高為代價。”陳諤強調(diào)說。
機遇在于統(tǒng)一的運維界面意味著將特定類型應用的運維標準化、自動化的可能性,從開發(fā)到運維轉換,作為在軟件生產(chǎn)過程中最具挑戰(zhàn)的環(huán)節(jié)之一有望得到大幅的優(yōu)化。
作為云原生的底座Kubernetes一直沒有應用層面的抽象,陳諤認為未來需要將應用的概念分離出來,來降低應用開發(fā)人員的認知負擔。當前社區(qū)的OAM模型的嘗試,也是網(wǎng)易數(shù)帆重點關注的一個方向。
在以應用為中心的方向上,網(wǎng)易數(shù)帆希望基于云原生的普及實現(xiàn)軟件生產(chǎn)能力普惠,讓更多的人可以參與到應用開發(fā)中來,并擁有良好的開發(fā)效率。畢竟當前企業(yè)數(shù)字化的過程中,IT團隊的交付能力經(jīng)常成為瓶頸,一些有價值但不是非常核心的系統(tǒng)往往長期處于需求排隊的狀態(tài)。
陳諤表示,軟件生產(chǎn)能力的普惠主要是解決開發(fā)能力與運維能力這兩方面的問題。開發(fā)能力方面通過縮小場景范圍、弱化抽象能力、表達能力,提供所見即所得的編輯能力來降低開發(fā)人員的認知負擔,這也是歷史上低代碼平臺類產(chǎn)品常見的策略。
運維能力方面,運維能力的缺失使非專業(yè)人員的代碼產(chǎn)出無法融入企業(yè)的IT環(huán)境成為標準的企業(yè)服務,從而僅限于個人或小范圍使用,而云原生的技術使我們可以為應用生成標準的運維配置、策略的描述,并且這些配置在云OS的統(tǒng)一運維界面下普遍適用。
網(wǎng)易數(shù)帆的實踐是打造了能與云原生體系結合的低代碼平臺,面向初級開發(fā)者,面向信息管理系統(tǒng)類的應用,基于MVVM的模型,但開發(fā)者無需理解編程語言的抽象、MVVM框架,網(wǎng)絡,遠程調(diào)用等概念,而只需理解業(yè)務的數(shù)據(jù)模型,編寫必要的邏輯,并通過可視化的方式拖拽界面元素實現(xiàn)應用。
陳諤介紹,該平臺設計成能生成符合云原生標準的制品,如容器鏡像與Helm charts,既能在輕舟的容器云中自動部署運行,也能在客戶的Kubernetes集群中部署,簡單應用可以直接通過容器部署。客戶只要有面向K8s的運維機制,無需開發(fā)者提供額外信息即可基于制品部署運維,并能兼容客戶運維體系的規(guī)范。
客戶需要更高級的能力時,也能以輕舟平臺為云OS來擴展持續(xù)交付、自動部署、服務治理、API管理、中間件自動化運維等能力。
（免責聲明：本網(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)容或斷開相關鏈接。 ）
