云原生技術成熟度分析及開源探索

中國移動研究院 陳鵬翔

Labs 導讀

2021新年伊始，新冠仍在肆虐，這場人類生命的挑戰(zhàn)改變了人們的生活方式，同時也推動了移動互聯(lián)網(wǎng)和云計算服務的持續(xù)發(fā)展，例如美團、盒馬和多點等生鮮生超APP外送或自取的方式被更多人所接受，而這些APP背后都是云原生技術在做技術支撐。云原生作為云計算最佳的使用方式正在被各類行業(yè)應用廣泛采納和推廣，在國家大力推動各行業(yè)數(shù)字化轉型的契機下，相信云原生技術一定會扎根各行業(yè)，助力各行各業(yè)的高速發(fā)展。

云原生技術包羅萬象，本文旨在厘清其核心技術內涵并提供一種有效的評估云原生技術成熟度的評估方法，并應用此方法評估云原生技術中的容器和微服務等開源技術棧，分享業(yè)界云原生相關的開源項目，并在文章最后給出下一步研究方向。

作者簡介：

陳鵬翔 中國移動研究院研究員，研究方向云原生、微服務、熟悉開源項目和技術貢獻，曾就職于HP等企業(yè)從事NFV架構師工作。

1 云原生技術和本文范圍

云原生技術是由Pivotal的Matt Stine于2013年提出，核心內容為描述一種應用，這應用符合12要素、微服務架構、敏捷基礎設施、基于API協(xié)作和反脆弱性，該描述較為抽象，特別是12要素的具體描述，實際應用起來并不拿來可用。Pivotal于2017年更新了一個具象的描述：云原生是一種構建和運行應用的方法，他利用了云計算交付模型的優(yōu)勢，企業(yè)需要一個平臺來構建和管理云原生應用程序和服務，該平臺實現(xiàn)了自動化且集成了DevOps、持續(xù)部署、微服務和容器等關鍵技術。這個描述更加偏重于平臺側應具備的能力，與“公要善其事必先利其器”如出一轍。這一點上CNCF（Cloud Native Computing Foundation，后簡稱CNCF）做的更純粹。

CNCF成立于2015年，由Google、思科和Docker等參與成立，給出的云原生定義為容器化封裝、自動化管理和面向微服務。顯然從一開始，CNCF就立足于平臺側，因為其下的開源容器調度平臺Kubernetes（后簡稱K8S）在后續(xù)發(fā)生的容器調度平臺大戰(zhàn)中戰(zhàn)勝了Mesos和Docker Swarm，做云原生技術的廠商更愿意把開源應用放到CNCF進行托管。2018年CNCF在托管了服務網(wǎng)格中的翹楚Envoy和Linkerd后，重新定義了云原生技術的范圍，包括容器、服務網(wǎng)格、微服務、不可變基礎設施和聲明式API。

我們給云原生的定義為:一系列面向云計算的技術和管理理念的集合，開發(fā)者要在應用架構、開發(fā)模式和運維部署階段貫穿實現(xiàn)這種理念，最終達到降低開發(fā)運維復雜度，最大限度發(fā)揮云計算的價值的目的。

核心技術包含不限于：

容器：是云原生應用的封裝事實標準，軟件及其依賴封裝到容器鏡像的內部，一次打包，到處部署，通過容器編排調度實現(xiàn)敏捷交付，主要包含容器編排、運行時層（容器運行時，云原生存儲和云原生網(wǎng)絡）等。

微服務：應用開發(fā)方通過標準化服務化開發(fā)方式，將大型應用程序開發(fā)拆解為多個小型服務集合的體系方法。更高級的要求是將微服務基礎能力（比如服務注冊，服務熔斷等）同應用的業(yè)務邏輯徹底解耦，使用平臺側的服務網(wǎng)格能力。主要包含微服務支撐層（服務網(wǎng)格、API網(wǎng)關和服務注冊發(fā)現(xiàn)）等。

無服務計算(Serverless)：是一種構建和管理基于微服務架構的完整流程，允許在服務部署級別而不是服務器部署級別來管理應用部署，構建或使用一個微服務或微功能來響應一個事件。

管理理念包含：

持續(xù)交付：讓單個應用隨時處于可發(fā)布狀態(tài)，通過自動化不斷的將小批量軟件運送到生產(chǎn)環(huán)境中，而不用等待與其他變更綁定到一次發(fā)布中。

DevOps：軟件開發(fā)人員同IT運維運營人員之間的高效協(xié)作方式。采用DevOps研發(fā)模式、自動化工具，實現(xiàn)軟件開發(fā)、測試、部署、維護一體化迭代。

不可變基礎設施：應用的微服務部署之后，內容不可修改，修改的方式就是替換這個應用的微服務；也就是說在生產(chǎn)環(huán)境基礎設施的各層組件（從os、虛擬機到集群，節(jié)點管理和單個節(jié)點的安裝軟件配置）中僅通過替換組件而不是修改組件來更改基礎設施，以此來降低系統(tǒng)的依賴和復雜度。

云原生是一個從應用向下拆解的過程，根據(jù)云原生的核心理念，作為云原生平臺能力的提供方，構建云原生平臺應具備如下核心能力：(見圖1)

圖1

云原生技術體系以容器編排調度為核心，南向接口通過多種容器運行時、存儲和網(wǎng)絡插件可對接異構的基礎設施層（即傳統(tǒng)云計算層），北向接口提供標準聲明式API和用戶自定義資源（CRD）接口，便于構建平臺上的平臺，這些平臺包括微服務支撐層，應用定義與開發(fā)層和觀察與分析層，同時支持無服務計算這種新型服務形態(tài)。

由于云原生技術范圍較大，本文研究范圍為圖1中的紅色框紅色字體的技術棧：容器編排調度，服務網(wǎng)格，服務注冊發(fā)現(xiàn)，API網(wǎng)關和無服務計算，分析在眾多開源項目中組件選型中的技術成熟度。

2 云原生技術成熟度評估方法

圖2

云原生技術成熟度評估模型的評估指標分為兩大類，一類是開源軟件通用評估指標，一類是軟件專用功能指標，每類指標有各自評估維度和算法，最終評估標準，按照

總分=開源軟件通用評估結果* 60% + 軟件專用功能評估結果 * 40%

根據(jù)量化分值情況判斷技術的成熟度水平。以服務網(wǎng)格的通用指標和專用指標為例，看下指標類中權重最高的3個指標項的具體內容：

通用指標：占比最高的3個指標項為托管代碼受關注數(shù)量、代碼貢獻者數(shù)量和主導團隊。

托管代碼，該指標受關注數(shù)量以Github為例，星標代表托管代碼受關注數(shù)量，星標數(shù)量越高，代表該項目更受大家關注，注冊了Github的用戶均可以對關注的項目加星標，定量指標，20000以上為滿分

代碼貢獻者數(shù)量，該指標直接反應了代碼在行業(yè)內的應用情況，代碼貢獻者越多，證明基于該代碼進行商用轉化程度多高，定量指標，500人以上為滿分

主導團隊，代碼開源初期大多有單獨廠商主導開源，好處是如果廠商能力強，軟件發(fā)展方向明確，項目會在短期快速發(fā)展，但對后期加入的廠商來說，會面臨缺乏話語權問題，會導致代碼出現(xiàn)眾多分支，定量指標，代碼托管3年以上且委員會成員7個廠商以上為滿分

專用指標：占比最高的3個指標項為多開發(fā)語言支持，代碼侵入性和性能影響。

多開發(fā)語言支持，微服務同軟件開發(fā)緊密相關，針對java，C#，go等語言都各自使用的微服務框架；第二代微服務框架也提供了支持多語言的能力，定性指標，支持多語言為滿分

代碼侵入性，早期微服務框架與開發(fā)語言綁定，配置信息會編譯到代碼內部；第二代微服務框架提供了無侵入式的方式，定性指標，完全無侵入，應用無感知為滿分

性能影響，微服務組件參與到軟件內部通訊中，性能問題會導致整個軟件提供服務能力的下降；以無服務代理時能力為基準，定量指標，下降10%以內為滿分

3 云原生技術成熟度評估結果

此次主要評估的開源軟件大部分來源于CNCF托管項目，容器調度編排涉及K8S、Swarm和Mesos，服務網(wǎng)格涉及Istio和Linkerd，服務發(fā)現(xiàn)涉及Zookeeper、Etcd和Nacos，API網(wǎng)關涉及Ambassador、Kong和Sentinel，Serverless涉及Knative、Kubeless和OpenFaaS。

3.1 容器編排

從通用和專用兩個方面看，K8S均是大幅度領先，特別是通用評估大類中的主流熱度子類，K8S已經(jīng)將曾經(jīng)從事Openstack、Swarm和Mesos的高端人才集中，以每年更新4個版本小步快跑的策略保持著技術上的領先。Mesos的優(yōu)勢在于對Hadoop和Spark等框架的支持，但缺點是架構偏重，特別是基于Zookeeper做一致性保證。Swarm的優(yōu)勢在于同Docker綁定，安裝Docker即可使用，同時缺點是功能單一。K8S的優(yōu)勢在于通過CRI、CNI和CSI對接多種云計算環(huán)境，通過CRD/Operator等技術對上支持各種平臺上的平臺。從行業(yè)認知來看K8S已經(jīng)是容器調度編排的事實標準。

3.2 服務網(wǎng)格

功能方面，Istio和Linkerd持平，性能方面Linkerd略勝一籌，但國內主流的公有云廠商和私有云廠商主要是基于Istio做持續(xù)的優(yōu)化以提供服務網(wǎng)格能力，并且Istio在螞蟻金服體系內經(jīng)歷過大規(guī)模部署和使用。Istio是Google研發(fā)的，原本計劃于去年貢獻給CNCF，但最終托管在其他組織里，依然掌握在Google手中，相對而言，發(fā)展方向把控上是一家獨大，Istio的最新版本也經(jīng)歷了從微服務到單體的巨大改變，主要是彌補其性能損耗上的問題，Istio和Linkerd從技術的角度看差別很小，考慮遇到問題更容易找到解決辦法，應考慮Istio為主要跟蹤技術棧。

3.3 服務注冊發(fā)現(xiàn)

服務注冊發(fā)現(xiàn)模塊整體得分較低，ZooKeeper由于是基于Java框架開發(fā)，對應用也要求其最好為Java開發(fā)，且歷史比較久遠，整體體量過重，已經(jīng)很少有應用基于它作為服務發(fā)現(xiàn)組件，Nacos是阿里開源的，也是基于Java框架開發(fā)，但提供TCP/DNS/UDP/TLS等多種方式調用，其各方面都不太成熟，而Etcd由于是K8S默認的服務注冊發(fā)現(xiàn)組件，安裝量很大，其社區(qū)相對活躍，基于Golang語言開發(fā)，較為輕量，且提供HTTP和gRPC方式調用。建議以Etcd為主要跟蹤技術棧。

3.4 API網(wǎng)關

API網(wǎng)關在整體微服務體系中處于極為重要的位置，但目前開源軟件整體評分較低，阿里開源的Sentinel更多的是作為一種輔助型插件使用。從生態(tài)和活躍度來看，Kong遙遙領先，Kong的插件有30多種，而Ambassador的插件只有4種。后續(xù)以Kong為主要跟蹤技術棧

3.5 Serverless

Serverless是一種新型的云計算提供方式，目前開源軟件整體評分較低，國內各大主流公有云廠商的Serverless服務大都采用自研的方式，各家SDK沒有統(tǒng)一標準，且與各自提供的多種云服務緊密結合，廠商綁定嚴重。后續(xù)可以跟蹤業(yè)界是否有統(tǒng)一標準，開源軟件方面以Knative為主要跟蹤技術棧。

4 中國移動發(fā)起的網(wǎng)絡云云原生開源探索

中國移動研究院也在網(wǎng)絡云領域積極探索云原生技術的應用場景，主導在Linux基金會發(fā)起業(yè)界首個面向5G及未來網(wǎng)絡的云原生PaaS平臺項目—XGVela。

該項目旨在依托云原生理念及技術在運營商網(wǎng)絡云中引入平臺即服務（PaaS）功能，使運營商可以通過XGVela平臺快速設計、開發(fā)、創(chuàng)新、管理網(wǎng)絡功能和服務。通過這種方式，運營商及設備商將會更多地關注于上層業(yè)務，避免陷入復雜的電信基礎設施。

XGVela平臺將選擇靈活可擴展的PaaS框架，選擇性引用業(yè)界廣泛使用技術成熟度水平高的General PaaS能力，實現(xiàn)General PaaS能力的電信級增強適配，并開發(fā)具有強電信特色的Telco PaaS能力。

目前項目技術委員會由中國移動、中國電信、中國聯(lián)通、愛立信、華為、Intel、Mavenir、Nokia、紅帽、SigScale、STC、風河、ZTE等13家國內外電信運營商、設備商、云服務商組成。種子代碼及項目Wiki請參照原文鏈接。

5 后續(xù)研究方向

云原生技術棧方面，重點研究觀察和分析層的相關技術，包括監(jiān)控相關的prometheus及其相關的exporter，日志相關的EFK整體解決方案，調用鏈相關的Opentracing協(xié)議，Jaeger、Zipkin和Skywarking等APM軟件，這些技術棧雖然沒有服務網(wǎng)格等技術熱度那么受關注，但是這些技術棧對于我們了解應用云原生化程度以及帶來哪些好處，能夠給出客觀可直觀的數(shù)據(jù)。另一個需關注的點就是對于云原生應用的封裝方式，目前已經(jīng)具備的Helm，Operator等，2020年微軟與阿里提出的OAM（Open Application Model）標準與參考實現(xiàn)都是為了更加直觀簡單的描述應用，屏蔽或歸攏復雜的K8S識別的Yaml，為開發(fā)和運維云原生應用降低門檻，從而促進云原生應用的普及。

成熟度方面可以從后評估角度，第一，對平臺應用效果等方面進行評估，平臺能夠提供哪些能力支持云原生應用的快速開發(fā)，自動化集成部署，便捷運維等；第二，對應用進行評估，應用進行微服務改造后，需要給出一個評估模型去評估微服務改造的效果。這兩點都需要同前述云原生技術棧的研究相結合。

云原生技術廣袤，并且總有新的技術棧加入進來，結合不同應用場景的開源項目也層出不窮，我們認為云原生技術的推廣和云原生技術本身的涵蓋范圍的不斷迭代是并行展開的，不能等到云原生技術完全成型時再進行推廣，因此也在積極通過面向網(wǎng)絡云的云原生PaaS項目XGVela基于成熟度高的項目推動產(chǎn)業(yè)落地。也許我們正在嘗試推廣的技術棧以后會被新的技術棧替代，這也正是技術的生命力所在。