歷史進(jìn)入2019年，放眼望去，今天的整個(gè)技術(shù)大環(huán)境和生態(tài)都發(fā)生了很大的變化。在己亥豬年春節(jié)剛剛過去的早春時(shí)節(jié)，我們來梳理和展望一下整個(gè)云原生技術(shù)趨勢的發(fā)展，是一件很有意義的事情，這其中有些變化在不可避免地影響著我們身處其中的每一家企業(yè)。

如果說云原生在2017年還僅僅是冒出了一些苗頭，那么2018可以說是普及之年，云原生變成了一個(gè)成熟的、被普遍接受的理念。靈雀云作為云原生理念的擁躉，也不斷順應(yīng)這種趨勢，聚焦云原生的核心場景，圍繞容器平臺、DevOps和微服務(wù)黃金三角進(jìn)行產(chǎn)品的研發(fā)和業(yè)務(wù)場景的落地。

早在1991年Jeffery Moore針對高科技行業(yè)和高科技企業(yè)生命周期的特點(diǎn)，提出了著名的“鴻溝理論”。這個(gè)理論基于“創(chuàng)新傳播學(xué)”，將創(chuàng)新性技術(shù)和產(chǎn)品的生命周期分為五個(gè)階段：創(chuàng)新者(Innovator)、早期使用者(Early adopters)、早期大眾(Early majority)、晚期大眾(Late majority)、落后者(Laggard)。

在Early adopters和Early majority之間有個(gè)巨大的鴻溝(Chasm)，每個(gè)新技術(shù)都會經(jīng)歷鴻溝，大多數(shù)失敗的產(chǎn)品也都是在鴻溝里結(jié)束了其整個(gè)生命周期，能否順利跨越“鴻溝”，決定了創(chuàng)新性技術(shù)的成敗。今天我們嘗試以鴻溝理論為基礎(chǔ)來分析云原生領(lǐng)域顛覆性的創(chuàng)新技術(shù)。

“Kubernetes is Boring”，邊緣創(chuàng)新有亮點(diǎn)

Kubernetes在2017年底成為容器編排事實(shí)標(biāo)準(zhǔn)，之后以其為核心的生態(tài)持續(xù)爆發(fā)，在傳播周期上可以說已經(jīng)跨過鴻溝了，進(jìn)入Early majority早期大眾階段，開始占領(lǐng)潛力巨大的主流市場。

根據(jù)CNCF在2018年8月進(jìn)行的第六次測量容器管理市場的溫度，83%的受訪者更喜歡Kubernetes的容器管理工具，58%的受訪者在生產(chǎn)中使用Kubernetes，42%的受訪者正在進(jìn)行評估以備將來使用，40%的企業(yè)(員工規(guī)模在5000+)正在使用Kubernetes。Kubernetes在開發(fā)人員中已經(jīng)變得非常流行。

回過頭來看，靈雀云從早期全力投入Kubernetes 技術(shù)棧，是最早進(jìn)行Kubernetes產(chǎn)品化的廠商。我們并未滿足于把Kubernetes當(dāng)作一個(gè)容器編排工具來使用，而是將它定位成構(gòu)建上層平臺的核心框架，通過合理運(yùn)用Kubernetes本身的擴(kuò)展機(jī)制、架構(gòu)模式與API規(guī)范，構(gòu)建出一系列“Kubernetes原生”的產(chǎn)品體系。這樣做不僅真正發(fā)揮出Kubernetes作為云計(jì)算核心框架的最大優(yōu)勢，也可以與以Kubernetes為核心的云原生生態(tài)無縫集成。

進(jìn)入主流市場的Kubernetes開始變得“Boring”，這很正常，甚至是一個(gè)好的現(xiàn)象。核心項(xiàng)目的創(chuàng)新速度會減慢，最新的版本中主要關(guān)注點(diǎn)聚焦在穩(wěn)定性、可擴(kuò)展性這些方面，盡可能把代碼從主庫往外推，讓它的主庫變得干凈，其他功能通過一些擴(kuò)展機(jī)制來做，同時(shí)開始關(guān)注安全性。

Kubernetes項(xiàng)目本身已經(jīng)過了現(xiàn)象級創(chuàng)新爆發(fā)的階段，但由Kubernetes獨(dú)特的架構(gòu)屬性催生出的周邊生態(tài)的二次創(chuàng)新仍然在高速發(fā)展，例如諸多與Kubernetes集成或者基于Kubernetes框架開發(fā)的上層服務(wù)與平臺。這個(gè)話題我們下次討論，今天還是主要關(guān)注與Kubernetes項(xiàng)目關(guān)聯(lián)最緊密的創(chuàng)新亮點(diǎn)：

早期容器化workload大多聚焦在無狀態(tài)服務(wù)，跑的最多的是Nginx，而對有狀態(tài)應(yīng)用避諱不談?，F(xiàn)在Kubernetes進(jìn)入主流市場，顯然需要對“現(xiàn)實(shí)中的應(yīng)用”，包括有狀態(tài)服務(wù)提供良好的支持。2019年，對于復(fù)雜應(yīng)用的管理以及Kubernetes本身的自動化運(yùn)維將會更多的表現(xiàn)為Operator。

Operator是基于Kubernetes擴(kuò)展機(jī)制，將運(yùn)維知識編寫成“面向應(yīng)用的Kubernetes原生控制器“，從而將一個(gè)應(yīng)用的整體狀態(tài)作為API對象通過Kubernetes進(jìn)行自動化管理。這個(gè)應(yīng)用通常來說是比較復(fù)雜的有狀態(tài)應(yīng)用，如MySQL數(shù)據(jù)庫、Redis集群、Prometheus等等。現(xiàn)在基本上常見的有狀態(tài)應(yīng)用都有自己相對應(yīng)的Operator，這是一種更為有效的管理分布式應(yīng)用的方式。

其次是應(yīng)用跨集群部署與管理。早期社區(qū)里有Federation聯(lián)邦集群的方案。我們不少大金融客戶都有跨集群部署、管理業(yè)務(wù)的需求。當(dāng)時(shí)深入研究Federation v1之后，覺得這個(gè)方案復(fù)雜度高，觀點(diǎn)性強(qiáng)，對于我們實(shí)際的需求靈活度不足而又不夠成熟。所以我們最終選擇自研跨集群部署。后來出現(xiàn)的Federation v2在設(shè)計(jì)方向上有不小改觀，是我們持續(xù)關(guān)注的項(xiàng)目。

早期采用容器技術(shù)的用戶都會盡可能兼容企業(yè)原有的IT基礎(chǔ)設(shè)施，比如底層物理機(jī)，保留物理機(jī)之上的虛擬層，虛擬機(jī)之上再跑容器。當(dāng)然，面向資源管理的硬件虛擬化和面向應(yīng)用的容器化本質(zhì)上沒有沖突。隨著Kubernetes的普及并且在應(yīng)用上超越了容器編排的范疇，后Kubernetes時(shí)代如何搭建管理基礎(chǔ)設(shè)施是值得思考的。我們也觀察到一些有意思的趨勢，比如在Kubernetes上同時(shí)管理容器和虛擬機(jī)(所謂的“容器原生虛擬化”)，或是使用Kubernetes來管理OpenStack。

總之，Kubernetes在云計(jì)算領(lǐng)域成為既定標(biāo)準(zhǔn)，會越來越多的往下管理所有種類的基礎(chǔ)設(shè)施，往上管理所有種類的應(yīng)用。這類標(biāo)準(zhǔn)的形成對于技術(shù)社區(qū)有很大的益處，會大大降低圍繞Kubernetes技術(shù)投入的風(fēng)險(xiǎn)。因此，我們會看到越來越多的周邊技術(shù)向它靠攏，在Kubernetes之上催化出一個(gè)龐大的云原生技術(shù)生態(tài)。

DevOps獨(dú)辟蹊徑：開放式DevOps工具鏈集成與編排

DevOps理念、方法論和實(shí)踐已經(jīng)走到了Early Majority早期大眾階段，是已被實(shí)踐證實(shí)的高效開發(fā)運(yùn)維方法。做容器的廠商都經(jīng)歷過用容器搞CI/CD，靈雀云也不例外，CI/CD是容易發(fā)揮容器優(yōu)勢的顯而易見的使用場景。在去年，我們做了重大的產(chǎn)品升級，將原來的CI/CD功能模塊擴(kuò)展為完整的DevOps產(chǎn)品—Alauda DevOps平臺，覆蓋應(yīng)用全生命周期。

DevOps包含好幾層概念，首先是組織文化的轉(zhuǎn)變，然后涉及到一系列最佳實(shí)踐，最終這些最佳實(shí)踐需要用工具去落地。我們在幫助很多大型企業(yè)客戶落地DevOps的過程中發(fā)現(xiàn)：

1. 在DevOps的整個(gè)流程里涉及到很多類別的工具，每一個(gè)類別都會有大量的選擇;

2. 每個(gè)客戶的工具選型多少會有些不同，并不存在一個(gè)固定的、完全標(biāo)準(zhǔn)的工具組合;

3. 隨著時(shí)間的推移工具選擇會發(fā)生變化，多數(shù)客戶意識到目前使用中的工具在未來很可能會被替代。

基于這些觀察，Alauda DevOps的定位并不是要提供一個(gè)新的DevOps產(chǎn)品，去取代客戶已有的工具選型。相反，我們致力于打造一個(gè)開放式的DevOps工具鏈集成與編排平臺。

這個(gè)平臺可以靈活的兼容客戶的工具選型，通過集成將各類工具串聯(lián)起來，形成一套工具鏈，通過編排讓DevOps工具鏈與容器平臺聯(lián)動，形成一個(gè)完整系統(tǒng)。同時(shí)，不斷結(jié)合自身的經(jīng)驗(yàn)，提煉DevOps落地的最佳實(shí)踐，平臺將這些最佳實(shí)踐自動化，作為服務(wù)進(jìn)行輸出。這個(gè)思路在和客戶的交流以及實(shí)際落地過程中不斷獲得認(rèn)可。

值得一提的是，我們對于DevOps工具鏈的編排也是基于Kubernetes來實(shí)現(xiàn)的。Kubernetes不僅是出色的容器編排工具，擴(kuò)展之后也很適合編排DevOps工具。換句話說，我們開發(fā)了一套“Kubernetes原生的DevOps平臺”。

微服務(wù)：落地需要一套完整的基礎(chǔ)設(shè)施

提起微服務(wù)治理，很多人會條件反射般的聯(lián)想到某些特定的技術(shù)，例如Spring Cloud，或者Service Mesh。我們不妨先退后一步，系統(tǒng)考慮下企業(yè)微服務(wù)架構(gòu)改造和落地所需要的完整的基礎(chǔ)設(shè)施。

首先，在微服務(wù)應(yīng)用的底層需要一個(gè)應(yīng)用管理平臺，這在今天毋庸置疑是一個(gè)基于Kubernetes的容器平臺。

微服務(wù)本質(zhì)上是分布式應(yīng)用，在我們獲取敏捷性的同時(shí)不可避免的增加了運(yùn)維和管理的難度。微服務(wù)對自動化運(yùn)維，尤其是可觀測性的要求很高。支持微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施必須具備完善的監(jiān)控、告警、日志、分布式追蹤等能力。

在微服務(wù)應(yīng)用的前方，通常需要一個(gè)API網(wǎng)關(guān)，來管理對外暴露的API。API治理策略，包括安全、路由、流控、遙測、集成等對于任何應(yīng)用平臺都重要，但在微服務(wù)架構(gòu)下尤為關(guān)鍵。我們需要通過定義、封裝對外API來屏蔽應(yīng)用內(nèi)微服務(wù)組件結(jié)構(gòu)細(xì)節(jié)，將客戶端與微服務(wù)解耦，甚至為不同客戶端提供個(gè)性化的API。

云原生應(yīng)用的一大準(zhǔn)則是應(yīng)用與狀態(tài)分離。在微服務(wù)架構(gòu)下，每個(gè)微服務(wù)組件更是應(yīng)該完全掌控自己的數(shù)據(jù)。所以，云原生應(yīng)用通常依賴外部數(shù)據(jù)服務(wù)(Backing Services)，而在微服務(wù)架構(gòu)下，多元化持久性(Polyglot Persistence)是常態(tài)，也就是說一個(gè)微服務(wù)架構(gòu)的應(yīng)用會依賴非常多種類的 Backing Services。面向微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施需要將這些外部服務(wù)暴露給微服務(wù)應(yīng)用消費(fèi)，甚至直接支撐各類Backing Services 的部署和管理。

一個(gè)團(tuán)隊(duì)之所以采用微服務(wù)架構(gòu)，一定有敏捷性的訴求。所以通常微服務(wù)團(tuán)隊(duì)也會擁抱DevOps理念。一個(gè)完善的面向微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施需要考慮 DevOps 流程以及工具鏈的自動化。

最后，我們回到狹義的微服務(wù)治理，這里關(guān)注的是微服務(wù)組件之間的連接與通訊，例如服務(wù)注冊發(fā)現(xiàn)、東西向路由流控、負(fù)載均衡、熔斷降級、遙測追蹤等?，F(xiàn)在有個(gè)時(shí)髦的術(shù)語來描述這類功能，就是大家熟悉的Service Mesh。其實(shí)早期 Sping Cloud 之類的框架解決的是類似的問題，但在實(shí)現(xiàn)的方式上，尤其是mesh 和業(yè)務(wù)代碼的耦合度上，有本質(zhì)的區(qū)別。

當(dāng)我們考慮一個(gè)平臺如何支撐微服務(wù)架構(gòu)的時(shí)候，需要涵蓋上述提及的方方面面，從產(chǎn)品的角度我們會保持一個(gè)開放的態(tài)度。這其中一部分需要我們自己去做，其他一些可以借助生態(tài)合作伙伴的能力去補(bǔ)全完善。

此外，微服務(wù)架構(gòu)也進(jìn)入到了后Kubernetes時(shí)代，早期基本上是微服務(wù)作為用例推動容器技術(shù)的發(fā)展。今天已經(jīng)反過來了，成為標(biāo)準(zhǔn)的Kubernetes其實(shí)在驅(qū)動和重新定義微服務(wù)的最佳實(shí)踐。容器和Kubernetes為微服務(wù)架構(gòu)的落地提供了絕佳的客觀條件。

Service Mesh：下一個(gè)亟待爆發(fā)的現(xiàn)象級技術(shù)創(chuàng)新

業(yè)界對于Service Mesh的布道已經(jīng)持續(xù)了一段時(shí)間，我們今天不再重復(fù)基本的概念。當(dāng)我們把Service Mesh和上一代以Spring Cloud為代表的微服務(wù)治理框架以及更早的Service Oriented Architecture (SOA) 作比較的時(shí)候，會看到一個(gè)有意思的演化。

我們知道，SOA有企業(yè)服務(wù)總線(ESB)的概念，ESB重且復(fù)雜，其實(shí)會混雜很多業(yè)務(wù)邏輯。SOA架構(gòu)下，ESB最終容易變成架構(gòu)以及敏捷性的瓶頸。早期推廣微服務(wù)架構(gòu)的時(shí)候，一個(gè)重要的概念就是“Smart Endpoints and Dumb Pipes”，針對的就是SOA下ESB的痛點(diǎn)，從而每個(gè)微服務(wù)能夠獨(dú)立、自治、松耦合。

但是仔細(xì)去想的話，就會發(fā)現(xiàn)它其實(shí)走到了另一個(gè)極端：它把一些基礎(chǔ)設(shè)施提供的能力放到微服務(wù)的業(yè)務(wù)組件里面了，通常每個(gè)組件需要加載一些治理框架提供的庫，或是調(diào)用特定的API，其實(shí)就是在業(yè)務(wù)組件里內(nèi)置了基礎(chǔ)設(shè)施的功能。到了Service Mesh其實(shí)又把它們分開了，從架構(gòu)角度這樣也比較合理，應(yīng)用是純業(yè)務(wù)的東西，里面沒有任何基礎(chǔ)設(shè)施，而提供微服務(wù)治理的基礎(chǔ)設(shè)施，要么在Mesh里面，要么由底層的Kubernetes平臺來提供，對應(yīng)用是透明的。

Istio的出現(xiàn)促使業(yè)界對于Service Mesh的架構(gòu)有了新的共識：控制平面(Control Plane)與數(shù)據(jù)平面(Data Plane)解耦。通過獨(dú)立的控制平面可以對Mesh獲得全局性的可觀測性(Observability)和可控制性(Controllability)，讓Service Mesh有機(jī)會上升到平臺的高度。相對于需要在業(yè)務(wù)代碼層面使用的上一代微服務(wù)治理框架，這點(diǎn)對于希望提供面向微服務(wù)架構(gòu)基礎(chǔ)設(shè)施的廠商，或是企業(yè)內(nèi)部需要賦能業(yè)務(wù)團(tuán)隊(duì)的平臺部門都具有相當(dāng)大的吸引力。

在Data Plane，Envoy的領(lǐng)導(dǎo)者地位毫無爭議。Envoy使用C++開發(fā)，在資源使用效率和性能上(尤其是長尾性能差異)相較早期主要競爭對手Linkerd有明顯優(yōu)勢。Envoy提供基于filter chain的擴(kuò)展機(jī)制，從Kubernetes的成功當(dāng)中我們已經(jīng)學(xué)習(xí)到，可擴(kuò)展性對于大規(guī)模采用十分關(guān)鍵。

Envoy定義了一套“通用數(shù)據(jù)平面API”(Universal Data Plane API)，也就是它的xDS協(xié)議。不僅確保了Envoy本身的動態(tài)可配置性，更重要的是為Service Mesh中Control Plane和Data Plane解耦提供了一個(gè)標(biāo)準(zhǔn)的接口。由于主流Control Plane(例如Istio)對Envoy以及xDS的采納，xDS成為Service Mesh Data Plane API的事實(shí)標(biāo)準(zhǔn)，Envoy也成為無可爭議的Data Plane領(lǐng)導(dǎo)者。

在Control Plane，Istio是最具光環(huán)的明星級項(xiàng)目。它正在引領(lǐng)Service Mesh創(chuàng)造出一個(gè)全新的市場，不過從傳播周期看現(xiàn)在還沒有跨過技術(shù)鴻溝，處于Early adopters階段。

過去一年中，Istio項(xiàng)目在技術(shù)上的表現(xiàn)并不完全令人滿意，主要體現(xiàn)在對其復(fù)雜度的詬病，以及穩(wěn)定性和性能的質(zhì)疑。1.0版本的推出并沒有完全令人信服。不過，這些似乎并不影響Istio在社區(qū)獲得的巨大成功。在開源領(lǐng)域，并不存在對Istio有實(shí)質(zhì)性威脅的競品。可能在經(jīng)歷了Kubernetes之后，以及Istio早期迅猛的發(fā)展和在社區(qū)中巨大的影響力之下，很少有開源項(xiàng)目愿意在Control Plane和Istio正面交鋒。

長遠(yuǎn)來講，Data Plane會慢慢變成commodity，尤其在有了Universal Data Plane API之后。我們有理由相信成熟穩(wěn)健的Envoy會保持領(lǐng)先，但最終多數(shù)用戶會越來越少去關(guān)心具體的Data Plane技術(shù)。這個(gè)情境似曾相識，和當(dāng)初Docker與Kubernetes的關(guān)系有點(diǎn)類似。

下個(gè)階段Service Mesh的賦能和創(chuàng)新會更多聚焦在Control Plane。AWS在Data Plane選擇成熟的Envoy，而自己開發(fā)App Mesh的Control Plane，就很容易理解。靈雀云已經(jīng)在ACE/ACP兩條產(chǎn)品線中集成了Istio，提供企業(yè)就緒的Service Mesh。

云原生為機(jī)器學(xué)習(xí)輸出工程化最佳實(shí)踐

云原生的理念與相關(guān)技術(shù)對于應(yīng)用開發(fā)與交付的巨大價(jià)值已經(jīng)被普遍接受。但云原生不僅僅可以作用在普通的應(yīng)用開發(fā)上。站在容器平臺的角度看，機(jī)器學(xué)習(xí)毫無疑問是一類極為重要新興工作負(fù)載。在未來，可能所有的公司都會是AI公司，所有的應(yīng)用都會是智能應(yīng)用，使用算法、模型就像今天應(yīng)用會依賴數(shù)據(jù)庫一樣普遍。

如果我們分析數(shù)據(jù)科學(xué)家的工作流，會發(fā)現(xiàn)和傳統(tǒng)應(yīng)用開發(fā)有很多相似的挑戰(zhàn)。如何方便的獲取實(shí)驗(yàn)環(huán)境;如何讓實(shí)驗(yàn)可重復(fù);如何將數(shù)據(jù)處理、特征提取、模型訓(xùn)練、模型驗(yàn)證、模型發(fā)布這些步驟自動化，并且可重復(fù);如何讓研究和生產(chǎn)環(huán)境保持一致;如何在生產(chǎn)環(huán)境做模型變更、AB測試、灰度發(fā)布;如何在生產(chǎn)環(huán)境運(yùn)維模型服務(wù);如何將模型服務(wù)化，等等。

在軟件工程領(lǐng)域，云原生的理念、方法論和最佳實(shí)踐已經(jīng)為類似問題找到了良好的解決方案。這些方案其實(shí)非常適合應(yīng)用在機(jī)器學(xué)習(xí)場景。換句話說，我們需要“云原生機(jī)器學(xué)習(xí)”。這仍然是一個(gè)相對早期的概念，從鴻溝理論的周期來看，云原生機(jī)器學(xué)習(xí)大致還處在Innovators創(chuàng)新者嘗鮮的階段。我們?nèi)ツ臧l(fā)布的Alauda Machine Learning (AML) 就是一個(gè)“云原生機(jī)器學(xué)習(xí)平臺”，目標(biāo)是從云平臺的角度，用云原生的思路去落地機(jī)器學(xué)習(xí)工程化的最佳實(shí)踐。

進(jìn)入2019年，巨大的增長空間和發(fā)展勢頭等待著已成事實(shí)標(biāo)準(zhǔn)的Kubernetes和容器技術(shù)繼續(xù)開疆拓土，落地到各種業(yè)務(wù)場景中;DevOps一片蓬勃人氣不減，靈雀云獨(dú)辟蹊徑，通過打造開放式DevOps工具鏈集成與編排平臺，形成完整的工具鏈，將最佳實(shí)踐輸出給客戶;微服務(wù)進(jìn)入到后Kubernetes時(shí)代，Service Mesh技術(shù)日漸成熟，落地將成為新的重點(diǎn)。

云原生技術(shù)不再曲高和寡，高處不勝寒，成為業(yè)內(nèi)主流標(biāo)準(zhǔn)取舍的關(guān)鍵。今天我們提到的上述云原生技術(shù)都是有創(chuàng)新性、顛覆性的技術(shù)，有希望順利跨越鴻溝(Chasm)進(jìn)入主流市場。2019年的云原生技術(shù)將實(shí)現(xiàn)實(shí)實(shí)在在的升級、成熟與落地。靈雀云也將繼續(xù)把領(lǐng)先的技術(shù)、產(chǎn)品和最佳實(shí)踐帶給服務(wù)的客戶，在技術(shù)升級和數(shù)字化轉(zhuǎn)型中做出自己的貢獻(xiàn)。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。