不謀全局不足以謀一域——雲原生布道第一篇

鍥子

       參與雲原生轉型項目調研也有近半年時間了,從年初聽同事講雲原生的雲裏霧裏,到開始百度雲原生的概念,然後接觸各大頭部雲廠商,全面鋪開進行方案交流與選型調研,一路走來,確實收穫頗多,進境用一日千里來形容也不爲過。在此也頗爲感嘆命運的變幻無常,也衷心地感激領導給我了這個機會!

一、雲原生定義界定

        關於雲原生的定義有多次發展,從Pivotal公司的Matt Stine於2013年首次提出雲原生(CloudNative)的概念,到2015年,雲原生剛推廣時,Matt Stine在《遷移到雲原生架構》一書中定義了符合雲原生架構的幾個特徵:12因素、微服務、自敏捷架構、基於API協作、扛脆弱性;到了2017年,Matt Stine在接受InfoQ採訪時,將雲原生架構又重新歸納爲模塊化、可觀察、可部署、可測試、可替換、可處理等6大特質;而Pivotal官網對雲原生的最新概括爲4個要點:DevOps+持續交付+微服務+容器。 

        2015年雲原生計算基金會(CNCF)成立,CNCF參與進來後,最初把雲原生定義爲包括:容器化封裝+自動化管理+面向微服務;到了2018年,CNCF又更新了雲原生的定義,把服務網格(Service Mesh)和聲明式API加了進來。

        從這些定義可以看到CNCF將雲原生的定義更偏技術化,更偏向於界定雲原生應用的技術能力特徵,而Matt Stine的定義從技術架構能力特徵,逐步演化到研發管理,顯然更加全面、也更立體化,也因此更容易做普適性推廣,也更符合企業雲原生轉型的全面目標價值,其對雲原生概括爲4個要點——DevOps+持續交付+微服務+容器,其實筆者更傾向於將DevOps與持續交付合二爲一,統稱DevOps——畢竟DevOps敏捷交付體系建設就是爲了持續交付、敏捷迭代業務——因此雲原生體系(而不只是雲原生技術架構或者雲原生應用特徵)的定義,就應該是傳統三駕馬車(DevOps+微服務+容器),這樣才能既囊括技術解決方案,也包含研發管理建設思路,才能真正成爲解鎖企業數字化轉型的“他山之石”。

二、雲計算演進之路

        這三駕馬車中“容器”是承上啓下的至關重要的一層,往下,容器技術代表着IT基礎設施(計算、存儲、網絡等)在資源虛擬化技術成熟並商用之後,在資源標準化道路上的關鍵一步。

        回過頭去看VMare的虛擬化之路,其最初是用於解決個人PC機資源虛擬化的述求,爲的是屏蔽WinTel時代大量兼容型PC機的硬件差異、OS差異(特別是Windows與Linux),以期通過虛擬化構建一個“放之四海皆準”的標準化計算環境,供目標應用程序順利執行。繼而,在此基礎上再拓展出資源動態擴縮容等企業級商用支撐能力,最終形成企業IT架構中Iaas層的商用解決方案,這便是第一代的雲計算技術。在當時的時代背景下,其在資源虛擬化方面的貢獻是革命性的,但是VMare基於普適各類PC機的設計思路,必然需要花費了大量架構精力去做各類異構資源的兼容,因此其虛擬化技術從一開始就是負重前行的,其帶來的巨量性能損耗也是肉眼可見的。

        當然,不可否認,其代表的第一代雲計算技術,爲企業IT架構特別是運行架構的發展做出了非常卓越的貢獻,其彈性擴容、資源超賣、故障遷移等雲計算典型能力特徵,在雲計算技術演進到第三代的今天,依然是評估一朵雲基礎技術能力的關鍵性基礎指標。

        在VMware的資源虛擬化技術基礎上,雲計算第二代技術集中體現在“軟件可定義”這個關鍵詞上,其中尤爲值得大書特書的便是軟件定義網絡(簡稱SDN)。嚴格來說,在VMware將PC級資源實現虛擬化之後,雲平臺已經具備一定的軟件定義計算的能力了,而SDN的出現則大幅下推了軟件可定義的IT體系架構下界——由計算層(主要是OS)下推到了網絡層,而且是數據中心級的網絡層軟件可定義。

        這種演進帶來的技術進化也不僅僅是將網絡控制能力軟件化、虛擬化,而是已經開始產生變革性的局部IT技術架構昇華。例如,頭部雲廠商,在設計雲內VPC之間互聯互通方案時,不約而同地採用了隧道打通方案,從而省去了傳統雲上VPC互通時的網元中轉環節,這一點與傳統雲廠商的設計思路形成鮮明的方案對比。傳統雲廠商依然是按照傳統網絡思維在設計雲上網絡方案,說直白一點,不過是把傳統IDC網絡聯通方案Copy到了雲上,而互聯網廠商,因爲有大流量、高併發等高性能互聯網場景訴求,於是在雲上網絡方案的設計上做了更大膽的突破。其實,如果從這個角度再反過頭來審視“網絡的本質”,你會對網絡有更高一層的認知(後續有機會我們再來深入探討)。

        第二代雲計算技術伴隨着AWS、阿里雲、騰訊雲等公有云廠商的崛起而發揚光大,直至今日依然是熠熠生輝。

        不過,隨着容器技術大規模應用於雲上,基本可以判斷,雲計算技術演進到第三代了,即雲原生時代,而且雲原生時代,對於雲的運用已經提升到了新的層次,以往雲計算對企業運行架構的支持僅僅是停留在IT層面的,即其只是作爲一個IT基礎設施架構的落地方案來展現其價值的,貢獻巨大但依然不夠全面與立體。而云原生在基於雲計算技術的基礎上,演進成了一套體系——容器、微服務、DevOps。這三架馬車是需要長於雲上的(現階段也有大量專家脫離雲,基於其商業目的或自身技術認知侷限,獨獨側重容器來談雲原生,這是非常值得商榷的),筆者的觀點也非常直接鮮明——只有充分結合了雲的能力,才能發揮1+1+1>3的效果,倘若是脫離了雲計算來談雲原生,那是對雲原生的認知根本還沒入門!

三、基於雲計算再來看雲原生三駕馬車——老樹發新芽

        如果單論三駕馬車的單項解決方案,其實都不是新玩意。這三者,也就容器技術看似相對新潮一點,但其實早在2001年,通過 Jacques Gélinas 的 VServer 項目,隔離環境的實施就進入了 Linux 領域,這便是容器技術的雛形。只不過直到2008年,Docker的崛起才讓容器技術發揚光大、廣爲人知(引自RedHat官網《容器簡史》)。因當前Docker+Kubernetes已成容器技術領域事實上的產業標準,因此本文所討論容器相關技術均以此兩類技術爲默認基準。

        微服務技術,就更不新鮮了,藉助下圖,軟件應用架構從最初的單體式架構,到上個世紀80年度的MVC架構(1979年,Trygve Reenskaug在一篇論文中首次提出MVC模型),再到前後端分離後的跨進程互訪的RPC架構(Birrell和Nelson在1984 發表於ACM Transactions on Computer Systems 的論文《Implementing remote procedure calls》對 RPC 做了經典的詮釋),再到上個世紀90年代中期提出、2002年Gartner提攜的SOA,再到2014年Martin Fowler 與 Jam es Lewis共同提出的微服務,其一路就是跟隨着IT技術的演進發展。從技術本質而言,從RPC架構其實就已經與現在的微服務技術同宗同源了。

        而DevOps,最早於2009 年6月,在美國聖荷西舉辦的第二屆Velocity大會上,一個名爲“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演講,便成爲了DevOps 萌發的標誌。

        所以若單論各單項技術(這裏的“技術”不單指開發技術,而是涵蓋整個信息技術知識體系的各項專業技術,有此認知共識,才比較適合閱讀本文),都是10年前的“老”技術了,但是在雲上進行組合之後,所產生的“化學反應”真正標誌着雲原生時代的到來!

1、雲+容器質變性推進計算環境的運行標準化進程

        當前第三代雲計算技術,首先是基於第二代雲計算廠商的公有云大規模實踐發展而來,即便沉澱到私有云領域,基本都是沿用公有云架構,再做的企業級能力下沉,其在基礎資源管理方面,也充分體現了公有云的特點,首先便是基礎硬件的標準化思路的變革——第二代雲對於基礎硬件的標準化思路與第一代雲截然相反,第一代雲計算技術企圖以軟件虛擬化技術去全面兼容市面參差不齊的異構PC機,而正由於在普適兼容方面投入過多,從而導致性能損耗過大,而第二代雲在此方面做了減法,基於大規模公有云實踐經驗,其要求入雲納管的硬件設備,特別是計算服務器首先必須是標準化的(甚至廠商定製化的),要求滿足雲廠商的硬件兼容標準,由此來大幅降低硬件兼容範圍,再針對性地對特定規格機器做針對性調優,以此來大幅降低虛擬化性能損耗。目前頭部廠商均宣稱其基於KVM的虛擬機技術,性能損耗均已能降低到5%以內(優秀者可以到3%以內)。

       由此可以預見,全行業級別的雲服務器規格標準的出臺必然在不遠的將來出臺,並由此倒推整機服務器廠商標準化生產,並上溯倒逼上游零部件廠商做標準化生產,最終實現全行業全產業鏈路的標準化生產。

        第二點,隨着AWS的Nitro硬件卡、阿里神龍卡的出現,結合英特爾的DPDK技術,出現了服務器上網絡處理指令“繞過”CPU、將流量卸載到PCI擴展卡處理的性能優化方案,此方案能大幅提升雲上網絡性能、全雲存儲性能(追趕者還有騰訊雲的黑石、華爲雲的擎天等),基於此類卡的服務器在特定領域(例如網絡、存儲、裸機容器)擁有無可比擬的性能優勢。基於此設想,隨着頭部雲廠商的市場佔比不斷攀升,定製版智能網卡、定製版服務器的市場佔比也將水漲船高,繼而可以更長遠展望一下,智能網卡能否分擔更多特定CPU/GPU的任務(全局內存、CPU資源調度等)?而回到本節中心觀點,在通過增加PCI擴展卡方式提升通用雲服務器特定領域性能的同時(目前已實現的是網絡、存儲,GPU應該是可以預見的),進一步增加雲服務器領域的標準話語權,也能反向推動傳統服務器廠商的標準化生產程度。

        第三點,過往雲端計算資源的全局調度、彈性伸縮能力,均是依託虛擬化技術(不論是VMware的軟件虛擬化,亦或VT-x/VT-d的通用硬件虛擬化技術)來實現,本質上依然是借力雲服務器的宿主機操作系統的資源調度能力來實現,而在“雲服務器定製化、SDN技術的出現使得雲上網絡也可軟件定義、智能網卡能力不斷強化”這三方面因素驅動下,操作系統級控制能力下沉、軟硬一體化的高性能級的全雲資源調度管理成爲了可能,這一點對於傳統虛機類應用或許收益不那麼明顯,但是在容器領域,將是革命性的。容器技術如果要達到商務生產級可用,說到底,依然需要雲服務器上宿主OS環境的全局統一調度可控,故若不能做到OS控制能力下沉到硬件,還是在基於通用服務器的場景下(全局資源調度依然只能依靠虛擬化技術,也即是常見的宿主OS+虛擬OS+Docker容器的運行模式),是無法實現裸金屬容器方案的(即宿主OS上直接運行容器,並實現資源彈性擴展),其實還是無法滿足企業越來越多高性能、大併發、高算力的互聯網場景要求的。只有有了OS控制能力下沉到硬件,容器便能真正運行在硬件服務器環境(即裸金屬),實現硬件服務器級的彈性擴縮容,高性能應用的容器化落地纔有可能,容器才真正有可能全面替代傳統VM。

2、雲+容器+微服務,拔高基礎設施上限至PaaS層,爲傳統企業瞬時提供比肩一線互聯網企業高性能、高可靠應用開發框架的技術能力,並進一步推動企業內開發框架標準化進程

        微服務的核心思想便是能力拆分、功能解耦,其與容器是天然一對,服務的高可用與容量伸縮通過容器技術來自動化實現。同時,基於應用服務的全面容器化之後,應用開放框架中的部分非業務相關的框架能力便能與業務應用剝離,以SideCar方式獨立運行,既能實現應用框架獨立於業務應用的自主升級,也能使業務開發團隊更加聚焦於業務功能開發。同時,爲跨團隊、跨技術棧的全鏈路服務追蹤、全局服務治理提供了方案可能性,這便有了ServiceMesh。

        而即便不用容器技術,僅基於雲+微服務使用場景,應用開發相關的中間件服務(例如常見的Redis、MQ等)也能拓展成爲雲端標準PaaS服務,支持分租戶、實例級隔離使用。此類公共組件,依託雲端的大規模集羣計算能力,可輕鬆提供比肩一線互聯廠商的大併發、高性能、自動彈性擴縮容的高性能中間件能力服務,爲業務應用的性能提升、穩定性提升提供統一、大規模、集羣化、專業化保障。因此,第三代雲計算,PaaS服務也成爲了雲端基礎設施,在短時間內提升傳統企業系統性能、穩定性的同時,也能大幅降低企業應用開發框架的整體建設成本、架構人員能力要求與投入,同時,借力業務上雲的同時,實現應用框架、中間件服務的收斂與標準化,將其版本迭代、能力演進節奏最終實現雲端統一管理,其架構治理前景也是非常可觀的。

3、雲+容器+DevOps,依託運行標準化,降低DevOps對接成本,真正使研發全流程自動化成爲可能。

        基於雲+容器來進行DevOps敏捷化運作,其集中收益點在於——容器應用依賴自包含之後帶來的CD環節(持續發佈)的對接改造成本的大幅降低、基礎運行環境大幅軟件可定義之後系統資源的自動化申請與創建使得研發全流程自動化有了真正落地可能。

        DevOps這個概念並不新鮮,但是在雲原生時代以前,除了一線互聯網企業,鮮有成功案例,其一大原因在於應用依賴環境的多樣性,特別傳統企業,技術棧龐雜、框架版本分支碎片化,歷史包袱非常重,如果要在CD環境對接改造所有的運行環境,成本高、技術複雜度高、發佈後監控反饋對接難度大而導致運行風險也不可控。故而只能在Java等少數“先進”、對接更容易的領域進行,全面推廣可行性便大打折扣。而有了容器化技術之後,業務應用統一打包成依賴自包含的容器鏡像,對運行環境要求大幅降低,DevOps的流水線系統只需要對接統一的容器發佈系統,即可輕鬆實現各類技術棧應用的自動化發佈,再依託統一的容器運行狀態監控機制、ServiceMesh流量劫持能力,在應用發佈後狀態監控環境有了更容易實現的統一解決方案。整體自動化發佈方案更加立體,更具備生產落地可行性。

        第二個原因在於,在傳統機房的基礎設施運行環境,系統運行資源、網絡、安全策略等程序運行相關的配置類資源的開通均是手工操作,即便在編碼研發環節能做到持續集成、自動化構建,應用包自動化推送與部署,中段的配置類資源的創建依然是手工操作,並不能真正實現全流程自動化,也就依然無法實現快速迭代發佈。而在第二代雲計算技術之後,有賴雲上技術、存儲、網絡、安全等資源的軟件可定義,程序運行所需配置類資源通過調用雲端標準接口即可開通,使全流程自動化發佈真正成爲可能。

        第三個問題在於,在ServiceMesh出現以前,大部分應用運行保障相關的框架級非功能特性(如彈性、韌性、安全、可觀測性、灰度等)均需要通過不同技術棧的應用開發框架來保證,甚至在開發框架能力缺失情況下還需要業務開發團隊自己來建設,這就導致了這類特性涉及的運維自動化、運行監控等工具能力也需要重複建設多套,而且很難做標準統一的同等級高質量建設輸出,因此即便前面CI/CD做到了全流程自動化,自動化發佈也不敢在生產放開使用,因爲運行監控手段是不是全局統一的,而且各業務系統的技術棧建設標準也不是統一的。這一點在容器化時代,伴隨着ServiceMesh技術的出現,才真正有了標準化解法。

        綜上所述,在雲原生時代,通過雲上環境的軟件可定義能力、標準化能力,已經可以使大量研發管理操作、運維監控操作由過去的手工處理變爲自動化、標準化的系統動作,從而整體性提升企業IT運維自動化水平、質變性躍升軟件系統基礎架構能力與服務穩定性,最終加快業務研發敏捷迭代速度,也因此,我們可以看到,雲原生時代的三駕馬車,已經不僅僅是針對雲原生應用的技術面的能力表述,而蘊含了依託雲的IT研發全生命週期管理含義與研發團隊組織思想,因此更加立體化,在此,我們可以大膽定義雲原生體系是企業運作管理模式向互聯網模式進化的核心關鍵技術與管理思想、組織流程的深度融合,應該也能成爲實現國家的互聯網+戰略的一條重要路徑。

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