C114通信網(wǎng)  |  通信人家園

技術(shù)
2021/10/13 20:58

云原生:加速企業(yè)數(shù)字化轉(zhuǎn)型的新引擎

移動Labs  王超

Labs 導讀

中國移動云能力中心王超應邀參加由中國信通院主辦的2021可信云大會,并在云原生分論壇發(fā)表了以《移動云云空間的云原生轉(zhuǎn)型實踐分享》為主題的演講,以下是精彩內(nèi)容分享。

作者簡介:

王超,中國移動云能力中心SaaS產(chǎn)品部技術(shù)專家組成員,曾負責能力開放平臺、服務治理平臺、移動云云網(wǎng)盤等產(chǎn)品及項目的研發(fā)工作,架構(gòu)設計及研發(fā)管理經(jīng)驗豐富,在互聯(lián)網(wǎng)大型業(yè)務系統(tǒng)的規(guī)劃、設計與調(diào)優(yōu)方面有深入研究。

1 定義云原生

數(shù)字世界再一次加速,我們已經(jīng)從云化時代發(fā)展到了云原生時代。似乎整個行業(yè)都在討論云原生,包括分布式系統(tǒng)、微服務、容器化、無服務器計算以及其他新興技術(shù)和架構(gòu)的作用,但 IT 從業(yè)人員和決策者仍然對云原生的真正含義以及利用云原生技術(shù)可達到的最終目標存有困惑。自從Paul Fremantle在2010年首次提出Cloud Native概念后,許多組織和專家都嘗試定義云原生:

Paul Fremantle (2010年)

他認為,應用程序當前可能無法充分利用云環(huán)境,需要考慮一些技術(shù)屬性,中間件和應用才能在云環(huán)境中良好運行(更好的利用資源、更快的配置、更好的治理),成為“Cloud Native”,此時云原生可以認為是一種云上應用構(gòu)建理念。這些核心技術(shù)屬性包括:分布式、彈性、多租戶、自助服務、精細計量和計費、增量部署和測試

Matt Stine(2015年)

Matt Stine在《Migrating to Cloud-Native Application Architectures》一書中表示,在單體應用向云原生遷移的過程中,需要從組織架構(gòu)、技術(shù)和文化等多個方面共同變革。同時為云原生提出了一組最佳實踐:十二因子、微服務、敏捷基礎設施、基于API的協(xié)作、反脆弱性。

CNCF(2015年)

云原生計算基金會(CNCF)成立,將云原生定義為:容器化封裝、自動化管理、面向微服務。

Matt Stine(2017年)

Matt Stine在一次媒體小組討論中表示,云原生架構(gòu)具有以下六個屬性:模塊化(通過微服務)、可觀察性、可部署性、可測試性、可處理性、可替換性。

CNCF(2018年)

云原生計算基金會(CNCF)重新定義云原生為:云原生技術(shù)有助于各組織在公有云、私有云和混合云等現(xiàn)代、動態(tài)環(huán)境中,構(gòu)建和運行可彈性擴展的應用。代表技術(shù)包括容器、服務網(wǎng)格、微服務、不可變基礎設施和聲明式API。

這些技術(shù)能夠構(gòu)建韌性好、可管理和便于觀察的松散耦合系統(tǒng)。結(jié)合可靠的自動化手段,云原生技術(shù)使得工程師能夠輕松地對系統(tǒng)做出頻繁和可預測的重大變更。

綜上我們可知,云原生的定義一直在不斷變化和演進中,但始終有一個核心的目標:“以應用為中心,實現(xiàn)價值用云”,讓我們的應用系統(tǒng)和IT架構(gòu)完全基于云原生,讓我們的業(yè)務系統(tǒng)生于云、長于云。

2 企業(yè)數(shù)字化進程的啟示

讓我們再回顧一下,企業(yè)數(shù)字化的三個階段以及它們的特點:

階段1:前云時代

軟件開發(fā):使用瀑布模型,完整的軟件一般需要數(shù)年時間才能完成開發(fā)交付,并且在進行新功能發(fā)布或者其他增量時,花費的時間較久。開發(fā)、QA和運維是不同的團隊,協(xié)作不多。

基礎設施:一開始直接使用物理硬件,后隨著服務器虛擬化的興起,可以使用性能更強大的物理服務器來部署虛擬服務器。

運維:運維任務通常手工完成,限制了系統(tǒng)可運維的規(guī)模。經(jīng)過一段時間的發(fā)展,技術(shù)人員開始嘗試使用配置管理工具,以減少維護基礎設施帶來的工作量和復雜度。

階段2:云化時代

軟件開發(fā):技術(shù)人員開始使用敏捷開發(fā)模型和DevOps體系,以替代瀑布模型,這使得可以更快、更高質(zhì)量地完成軟件開發(fā)及交付。

基礎設施:云將運行應用程序所需的資源和依賴作為即開即用的服務提供。應用構(gòu)建者將云作為一種新型IT基礎設施,使得他們可以專注于核心業(yè)務部分而無需關(guān)心底層基礎架構(gòu)。

運維:云上運維和管理的自動化程度進一步提升,包括開通、配置、擴容和自我恢復。

階段3:云原生時代

軟件開發(fā):單體應用程序逐漸被微服務、服務網(wǎng)格和無狀態(tài)計算等新技術(shù)改變,結(jié)合云原生產(chǎn)品,開始真正充分利用云的關(guān)鍵特性。

基礎設施:云通過平臺提供多種服務支撐。應用構(gòu)建者通常采用多云或混合云方法,將應用程序和服務部署在最能發(fā)揮價值的地方。

運維:基于分布式構(gòu)建的應用系統(tǒng),開始使用全新的部署方法:容器和彈性調(diào)度平臺,這些在基礎設施中增加的抽象,能夠使運維人員以新的方式觀察和處理系統(tǒng)健康狀態(tài)及性能表現(xiàn)。

 

在云化時代,企業(yè)將IT系統(tǒng)搬遷上云,業(yè)務應用都部署和運行在云上,消除傳統(tǒng)硬件的束縛,實現(xiàn)了敏捷化的資源編排能力。通過池化資源,一定程度上解決了部署、運維方面的難題,但傳統(tǒng)應用在架構(gòu)、交付、部署形式等方面并沒有充分體現(xiàn)對云關(guān)鍵屬性的應用,無法發(fā)揮云的正真價值。

隨著企業(yè)數(shù)字化進程不斷推進,對云的理解和應用也更加深入,應用構(gòu)建者們意識到僅僅簡單地將IT系統(tǒng)搬遷上云,往往無法真正享受云帶來的最大價值,需要由現(xiàn)在的ON CLOUD進階到IN CLOUD,同時使用云提供的新生能力與既有能力有機協(xié)同,基于云原生的技術(shù)、架構(gòu)和服務來構(gòu)建企業(yè)應用,充分利用云的優(yōu)勢來助力企業(yè)應用和業(yè)務發(fā)展,將企業(yè)的數(shù)字化建設、業(yè)務智能升級帶入新階段。

3 云原生應用的概念和特點

對應用來說,云原生是一個形容詞,體現(xiàn)的是應用為云而生的需求:應用需要做什么樣的設計才能正真實現(xiàn)價值用云,這背后是一套“以應用為中心” 的技術(shù)體系和方法論,用于指導構(gòu)建和運行云上應用。換句話說,云原生強調(diào)的IN CLOUD,并不是指應用所在的位置,而是指應用構(gòu)建和運行的方式。

在云原生的語義下,“以應用為中心”并不等于重應用、輕平臺,相反是平臺上探、復雜性下沉,云平臺通過云服務和產(chǎn)品,接管應用構(gòu)建過程中更多的標準功能和非功能性特性,減輕乃至消除了應用對存儲、計算、網(wǎng)絡等資源的關(guān)注和依賴,云平臺通過標準產(chǎn)品提供技術(shù)及業(yè)務能力,使應用能專注在業(yè)務需求實現(xiàn)上。

3.1 云原生應用

云原生應用是傳統(tǒng)應用的再進一步,是為云而設計的應用程序,基于云構(gòu)建,依賴云上服務和能力,最大化運用云的潛能,發(fā)揮云的價值,旨在充分利用云計算模型以提升速度、靈活性和質(zhì)量,同時降低部署風險。云原生應用的立意并不關(guān)注應用程序在哪里運行,而是關(guān)注應用程序如何構(gòu)建、部署和管理。

云原生應用自身基于云原生技術(shù)(微服務、容器化、CICD等),完成設計與構(gòu)建,同時通過與云平臺提供的相關(guān)可靠產(chǎn)品及能力(容器服務、安全產(chǎn)品、中間件等)充分整合,盡可能的剝離非功能性特性及邏輯(韌性/容錯、可觀測性、安全、連續(xù)性、一致性),讓云接管,從而輕量化應用。

3.1.1 云原生應用特點

敏捷:應用迭代周期更短,能快速應對外部變化,用最少的試錯來達到最終目標。

彈性/可擴展:應用可隨業(yè)務流量自動擴縮容,具備較高的業(yè)務抗性。同時,具備對現(xiàn)有基礎設施的橫向、縱向擴展能力。

分布式:應用遵循低耦合的分布式模式,各個節(jié)點可以部署在不同的網(wǎng)絡/地域中。

3.1.2 云原生應用的開發(fā)和傳統(tǒng)應用開發(fā)之間的差異

云原生應用更加關(guān)注上市速度,所以應用開發(fā)需要更多敏捷、服務化開發(fā)及持續(xù)交付的方法。通過供跨開發(fā)團隊和交付團隊的DevOps協(xié)作、更加模塊化的架構(gòu)以及靈活可擴展的基礎設施提供支撐,讓云原生應用支持多種環(huán)境,具備良好的可移植性。

對應用來說,簡單的轉(zhuǎn)向微服務架構(gòu)并不能帶來企業(yè)數(shù)字業(yè)務所需的服務質(zhì)量和交付頻率,同樣的,僅采用支持敏捷開發(fā)或IT自動化的工具不會提高云原生應用的構(gòu)建速度。想要成功構(gòu)建良好的云原生應用,需要的是實踐、技術(shù)、流程和思維方式的有機結(jié)合。

云原生應用開發(fā)有兩個互補的部分:云上應用服務或中間件,可以加速云原生應用的開發(fā);云上基礎設施服務或容器平臺,可以加速云原生應用的交付和部署。

3.1.3 云原生應用開發(fā)及交付的四項原則

·基于服務化的架構(gòu)

服務化架構(gòu),例如微服務,提倡構(gòu)建模塊化、松散耦合的業(yè)務服務。微服務的優(yōu)勢可以提升應用的構(gòu)建速度而不會增加過多的復雜性,帶來良好的獨立性和業(yè)務敏捷性。

·基于API的通信交互

多個服務之間通過輕量、技術(shù)棧無關(guān)的API暴露和交互,能降低部署、擴展和維護的復雜性和開銷。

·基于容器的基礎設施

云原生應用使用容器在不同環(huán)境和基礎設施(包括公有云、私有云和混合云)之間實現(xiàn)真正的應用可移植性。容器技術(shù)能在單個操作系統(tǒng)中為多個應用服務劃分計算資源,并確保應用服務之間的安全與隔離。使用Kubernetes等容器編排平臺,實現(xiàn)一定的業(yè)務抗性和彈性。

·DevOps流程

DevOps原則側(cè)重于與交付團隊(包括開發(fā)、QA、安全和  運維團隊)協(xié)作構(gòu)建,共同交付應用程序。同時,使用DevOps自動化功能,支持定期增量和持續(xù)交付,并引入灰度發(fā)布、藍綠發(fā)布等來保持一定的業(yè)務連續(xù)性。

4 云原生應用構(gòu)建實踐

4.1 轉(zhuǎn)向微服務

云原生應用的特點包括分布式和敏捷,這就要求將單體應用拆分為多個服務(分布式系統(tǒng)),而使用微服務架構(gòu)是將應用程序拆分為較小服務的可靠方法,它有以下優(yōu)勢:

·可擴展/解耦

擴展單個服務,而不是應用整體,且服務可部署在任意網(wǎng)絡節(jié)點

·互不干擾的技術(shù)棧

相互獨立,遠程通信,按需選型

·易于開發(fā)

服務小且獨立,研發(fā)過程更可控,適合小兵團組合作戰(zhàn)

·易于交付

每次更改涉及特定服務而不是整體,以較小的增量開發(fā)來滿足單次交付需求

微服務的概念自2011年首次提出起,就展現(xiàn)出了比SOA更加優(yōu)越的特性,在各類方法論和支撐技術(shù)加持下,微服務架構(gòu)的分布式系統(tǒng)易于具備敏捷性、彈性、可擴展等方面的優(yōu)勢,深度契合云上應用的要求,那么如何設計一個良好的微服務架構(gòu)系統(tǒng)呢,可以從以下幾個方面考慮:

⑴ 服務設計原則

·無狀態(tài)計算

服務節(jié)點不持有狀態(tài),支持微服務在運行中,隨時按需彈性擴縮容。這也是分布式架構(gòu)的關(guān)鍵點之一,將無狀態(tài)的計算與有狀態(tài)的數(shù)據(jù)分開,微服務計算節(jié)點只負責狀態(tài)數(shù)據(jù)的分發(fā)與處理,而有狀態(tài)數(shù)據(jù)的存儲則依賴后端的各類中間件中。

·圍繞業(yè)務、先粗后細

微服務架構(gòu)的分布式系統(tǒng)要求我們的系統(tǒng)拆分成一個個獨立且松散耦合的服務進程,要為每個服務劃分好明確的邊界,通常圍繞業(yè)務,以界限上下文關(guān)聯(lián)和聚合形成服務,而不是通過技術(shù)屬性。在系統(tǒng)設計早期,可以將上下文界定的較粗,以較粗的粒度形成微服務,在后續(xù)的規(guī)劃、設計與運行中,對服務有了更多認識后,再調(diào)整界定粒度,進一步拆分或者合并。

·容錯與自我保護

微服務架構(gòu)帶來的問題之一就是復雜的服務依賴,并且隨著時間推移,每個服務都可能依賴更多的服務,在調(diào)用鏈的某些服務不可用時,可能會因為調(diào)用堆積引起雪崩效應,無限的影響上游服務,需要有良好的機制(例如引入斷路器),識別依賴服務的健康狀態(tài),并在發(fā)生問題時保護自身。

·冪等性、一致性

這是分布式系統(tǒng)永恒的話題之一,由于微服務眾多,眾多的服務請求都在網(wǎng)絡中發(fā)生,當發(fā)生網(wǎng)絡抖動、重復請求等異常情況時,服務需要具備良好的冪等設計來避免請求被重復處理。此外,在微服務架構(gòu)的系統(tǒng)中,狀態(tài)在多個服務之間流轉(zhuǎn),需要一致性來確保業(yè)務得到正確的處理,這就涉及到強一致性和最終一致性在系統(tǒng)中應用。

·向前和向后兼容

微服務的優(yōu)勢之一就是各個服務可以獨立演進和迭代,而服務間復雜的依賴關(guān)系顯而易見就帶來了各個微服務版本兼容的問題,向后兼容要求服務自身迭代不能影響其他服務對自己身依賴和調(diào)用,實現(xiàn)多版并存,向前兼容要求服務自身能夠接受并消化其他服務的迭代,保持系統(tǒng)穩(wěn)定。

⑵ 系統(tǒng)設計原則

·服務自治

單個微服務就是單個獨立的自治實體,體現(xiàn)在技術(shù)選型自由、部署自由、研發(fā)語言自由等方面,同時能夠自治業(yè)務邏輯和數(shù)據(jù),需要從上到下(接入層、業(yè)務層、數(shù)據(jù)層等)全面的獨立,服務暴露出API(Application Programming Interface,應用編程接口),服務間通過API進行通信和調(diào)用。

·分層依賴

微服務整體架構(gòu)設計需要分層,例如劃分出核心服務層、公共服務層、基礎服務層等,定義好服務的上下游關(guān)系落到具體的分層,并約定依賴方向,做好分層依賴,避免產(chǎn)生循環(huán)依賴導致系統(tǒng)整體耦合性上升。

·高效服務通信

微服務架構(gòu)中的各個微服務之間通常通過遠程通信實現(xiàn)調(diào)用,通信的實現(xiàn)方式直接影響了服務間調(diào)用的效率和成功率,這就需要考慮技術(shù)選型,例如選擇具備多路復用、雙向流通信、二進制傳輸?shù)忍匦缘男滦蛡鬏攨f(xié)議和組件。

·適當異步消息傳遞

當在多個微服務上下文中傳遞消息時,各自微服務不同的部署規(guī)模和處理能力帶來了服務間可能的調(diào)用堆積,可以使用適當?shù)漠惒较鬟f機制(請求響應異步、事件驅(qū)動異步、消息隊列異步),減少系統(tǒng)整體耦合度、提升處理性能。

·面向運維

微服務架構(gòu)下產(chǎn)生了繁多的獨立服務實例,為系統(tǒng)運行期的運維帶來了一定的復雜性,所以要把運維復雜性考慮到系統(tǒng)的設計階段,由內(nèi)而外的實現(xiàn)可觀測性、可部署性及可運維性。

在這個過程中,我們要清楚的意識到“微”不是目的,“敏捷”才是我們的最終目標,要依托微服務的理念,將應用程序打造成一個業(yè)務敏捷、技術(shù)敏捷的云原生應用。

4.2 應用容器化

應用微服務化之后為集成和交付帶來了挑戰(zhàn),而容器和微服務就像豆?jié){油條一樣天生一對,是當下流行的開發(fā)實踐,可將應用程序轉(zhuǎn)換成可移植、可擴展、高效且易于管理的較小服務集合。

容器是一種輕量級的虛擬化技術(shù),能夠在單一主機上提供多個隔離的操作系統(tǒng)環(huán)境 ,通過一系列的namespace進行進程隔離,每個容器都有唯一的可寫文件系統(tǒng)和資源配額。容器技術(shù)分為運行時和編排兩層,運行時負責容器的計算、存儲、網(wǎng)絡等,編排層負責容器集群的調(diào)度、服務發(fā)現(xiàn)和資源管理。

中國云原生用戶調(diào)研報告(2020)中調(diào)查數(shù)據(jù)顯示,60%以上的用戶已在生產(chǎn)環(huán)境中應用容器技術(shù)。43%的用戶已將容器技術(shù)用于核心生產(chǎn)業(yè)務,19%的用戶已將容器技術(shù)用于非核心生產(chǎn)環(huán)境。僅10%的用戶未考慮使用容器技術(shù)。同時,容器運行時多元化發(fā)展趨勢已經(jīng)顯現(xiàn),但Docker仍是現(xiàn)階段最主要的選擇。83%的用戶容器運行時技術(shù)選用Docker,9%的用戶選用 Containerd。此外,Kubernetes延續(xù)在容器編排技術(shù)領域的優(yōu)勢地位,63%的用戶容器運行時技術(shù)選用Kubernetes,17%的用戶選用Docker Swarm。

容器技術(shù)能為使用者能帶來以下優(yōu)勢:

·更快的初始化和執(zhí)行

·更細的隔離與服務共存

·更輕松的編排管理

·更便捷的制品交付

在實際的研發(fā)過程中,常常有以下幾種訴求:

·在研發(fā)生命周期中,分別部署到不同的環(huán)境

·業(yè)務服務快速啟動/拆除/擴縮容

·業(yè)務服務實例混部

·只關(guān)心應用運行,而不關(guān)心在哪里運行

以上兩者可以發(fā)現(xiàn),容器技術(shù)的優(yōu)勢可以匹配研發(fā)過程中的訴求,容器可以幫助解耦應用和基礎設施,提高業(yè)務敏捷性,是實現(xiàn)“以應用為中心”架構(gòu)的重要支撐。通過云、容器、微服務三者協(xié)同工作,將應用的開發(fā)和交付提升到傳統(tǒng)方法和技術(shù)無法達到的新高度,大大增加了應用生命周期的敏捷性和可靠性。

通常,云上的容器服務能提供高性能可伸縮的容器應用管理服務,容器化應用的生命周期管理可以提供多種應用發(fā)布方式。容器服務簡化了容器管理集群的搭建工作,整合了調(diào)度、配置、存儲、網(wǎng)絡等,打造云端最佳 容器運行環(huán)境。使用容器技術(shù),用戶可以將微服務及其所需的所有配 置、依賴關(guān)系和環(huán)境變量打包成容器鏡像,輕松移植到全新的服務器 節(jié)點上,而無需重新配置環(huán)境,這使得容器成為部署單個微服務的最理想工具。

4.3、持續(xù)交付流水線

應用微服務化與容器化之后,還是會面臨“更快且頻繁交付”和“系統(tǒng)穩(wěn)定且可靠”之間的矛盾。而持續(xù)交付(Continuous delivery)是一種軟件工程方法,旨在以更快的速度和更高的頻率來構(gòu)建、測試和發(fā)布軟件。可以使生產(chǎn)中的應用程序進行更多增量更新,該方法有助于降低成本、耗時和交付變更的風險。使用者可通過完整的工具鏈,深度集成代碼倉庫、制品倉庫、項目管理、自動化測試等類別中的主流工具,快速實踐。

由上圖可以看到,持續(xù)交付是持續(xù)集成模型基礎上的延伸,使研發(fā)周期自動化更進一步,能夠快速發(fā)布到演示或UAT環(huán)境、以及執(zhí)行自動化的系統(tǒng)集成測試。

4.3.1 實踐原則

在建設持續(xù)交付流水線的過程中,可以遵循以下策略:

⑴ 版本控制與分支策略

·可審核、可重復

每一次的版本構(gòu)建都是可審核且可重復的,能夠利用版本控制策略回溯,以應對流水線中可能出現(xiàn)的失敗。

·包含整個交付物(代碼、數(shù)據(jù)庫、配置)

版本控制不能僅僅包含代碼,也要包含變更涉及的所有內(nèi)容,避免遺漏,產(chǎn)生不一致。

·頻繁的分支合并

盡早、頻繁的合并分支,有利于發(fā)現(xiàn)最新的修改,能夠及時處理沖突。

⑵ 持續(xù)交付流水線

·合適的工具

采用合適的工具構(gòu)建自己的流水線,考慮學習成本、維護、效果等多方面的因素。

·數(shù)據(jù)驅(qū)動

通過每一次自動化動作的指標量化數(shù)據(jù),來驅(qū)動流水線向前或向后推進。

·控制與改進

通過每一次構(gòu)建的動作效果與反饋,不斷改進流水線,添加自動化動作或者更新技術(shù)工具。

⑶ 更多的自動化

·檢測、構(gòu)建、測試

在流水線中引入更多的自動化動作,盡量減少手工參與,可以覆蓋檢測、構(gòu)建、測試等多個環(huán)節(jié)。

·覆蓋整個交付物

自動化的動作不僅要覆蓋代碼,也要包含全部交付物,例如腳本、SQL、配置等,避免遺漏。

·重復的體力勞動

如果在流水線上有重復的人工體力勞動,都建議嘗試將其納入自動化動作。

⑷ 良好的反饋機制

·全周期反饋

反饋機制要包含整個持續(xù)交付周期,對每一次動作都要有所響應,避免遺漏。

·快速反饋

在持續(xù)交付中,流水線要能夠在構(gòu)建時快速給出結(jié)果,避免團隊等待而降低敏捷性。

·團隊積極響應反饋

團隊成員需要建立起迅速響應流水線反饋的文化,及時修改問題,提升效率,降低風險。

4.3.2 持續(xù)交付流水線樣例

一個典型的用于生產(chǎn)的持續(xù)交付流水線如上圖,充分融合了技術(shù)、流程與團隊,通過自動化動作與持續(xù)反饋機制,不斷發(fā)現(xiàn)交付物中的問題并予以修正,能夠大大降低部署到生產(chǎn)環(huán)境的風險。

持續(xù)交付并不要求最終交付物自動化部署到生產(chǎn)環(huán)境,在持續(xù)交付的語義下,生產(chǎn)環(huán)境部署變更是兩階段完成的,第一階段采用持續(xù)交付給出穩(wěn)定的交付物,實現(xiàn)制品晉級并分發(fā)到發(fā)布制品庫,通過上線審核后,再通過發(fā)布管理平臺或其他方式部署到生產(chǎn)環(huán)境。

4.4、與云融合

從使用效用方面看,云原生極大的釋放了云的紅利,云原生充分繼承了云的設計思想,應用會更多基于云上進行本土應用開發(fā),即云原生應用更加適合云的架構(gòu),而云計算也為云原生應用提供較好的基礎支撐。云計算的發(fā)展已進入成熟期,云原生作為新型基礎設施支撐數(shù)字化轉(zhuǎn)型的重要支撐技術(shù),逐漸在人工智能、大數(shù)據(jù)、邊緣計算、5G等新興領域嶄露頭角,成為驅(qū)動數(shù)字基礎設施的強大引擎。

對使用者來說,使用云上提供的服務或產(chǎn)品,有助于剝離非功能性需求,敏捷化研發(fā)過程,實現(xiàn)提質(zhì)降本增效。以移動云為例,目前規(guī)劃提供了多線條的產(chǎn)品線來支撐快速、高效的構(gòu)建云原生應用。

云原生開發(fā)者服務

包括微服務治理引擎、DevOps工具鏈、應用開放平臺等,為開發(fā)者提供端到端的協(xié)同服務和研發(fā)工具,降低數(shù)字化技術(shù)使用門檻,提高資源的復合利用率,提升協(xié)作和交付效率。

云原生中間件產(chǎn)品線

包括消息隊列、數(shù)據(jù)庫、大數(shù)據(jù)、AI能力等,提供優(yōu)勢云數(shù)能力及各類云上中間件,能將功能從應用中剝離,在運行時為應用動態(tài)賦能。

云原生計算產(chǎn)品線

包括容器服務、Serverless等,封裝異構(gòu)基礎設施提供負載支撐,有效解決異構(gòu)環(huán)境部署一致性問題,促進了資源的標準化。

5 結(jié)語

云上應用的共性需求促進了云上服務及產(chǎn)品的演進,云上服務及產(chǎn)品的繁榮也進一步促進了云上應用構(gòu)建和運行形式的更新,這是一個雙向價值促進的過程。對應用本身來說,除了圍繞云原生代表技術(shù)來設計與構(gòu)建之外,還要與云提供的各類服務及產(chǎn)品深度整合,根植于云,隨云而動--“to be Cloud Native”。

讓我們再回看Paul Fremantle在10多年前提到的未來:

strongly believe that it is only once a system really implements these attributes that it starts to give the full benefits of running in a cloud. And the benefits of "Cloud-Native" systems are immense: better utilization of resources, faster provisioning, better governance.

如今,未來已來。

參考文獻

[1] 《云原生2.0白皮書》  -  中國信通院.

[2] 《mi-path-to-cloud-native-apps》  -   redhat.

[3] 《云計算發(fā)展白皮書2020》 - 中國信通院.

[4] 《云原生發(fā)展白皮書2020》 - 中國信通院.

給作者點贊
0 VS 0
寫得不太好

免責聲明:本文僅代表作者個人觀點,與C114通信網(wǎng)無關(guān)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實,對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,并請自行核實相關(guān)內(nèi)容。

熱門文章
    最新視頻
    為您推薦

      C114簡介 | 聯(lián)系我們 | 網(wǎng)站地圖 | 手機版

      Copyright©1999-2024 c114 All Rights Reserved | 滬ICP備12002291號

      C114 通信網(wǎng) 版權(quán)所有 舉報電話:021-54451141