靈雀雲CTO陳愷：從“鴻溝理論”看雲原生，哪些技術能夠跨越鴻溝？
阿新 • • 發佈：2019-03-11
aws 標準 docker soa 日誌 社區 多少 sql數據庫 ont
如果說雲原生在2017年還僅僅是冒出了一些苗頭，那麽2018可以說是普及之年，雲原生變成了一個成熟的、被普遍接受的理念。靈雀雲作為雲原生理念的擁躉，也不斷順應這種趨勢，聚焦雲原生的核心場景，圍繞容器平臺、DevOps和微服務黃金三角進行產品的研發和業務場景的落地。
早在1991年Jeffery Moore針對高科技行業和高科技企業生命周期的特點，提出了著名的“鴻溝理論”。這個理論基於“創新傳播學”，將創新性技術和產品的生命周期分為五個階段：創新者（Innovator）、早期使用者（Early adopters）、早期大眾（Early majority）、晚期大眾（Late majority）、落後者（Laggard）。
在Early adopters和Early majority之間有個巨大的鴻溝（Chasm），每個新技術都會經歷鴻溝，大多數失敗的產品也都是在鴻溝裏結束了其整個生命周期，能否順利跨越“鴻溝”，決定了創新性技術的成敗。今天我們嘗試以鴻溝理論為基礎來分析雲原生領域顛覆性的創新技術。
“Kubernetes is Boring”，邊緣創新有亮點
Kubernetes在2017年底成為容器編排事實標準，之後以其為核心的生態持續爆發，在傳播周期上可以說已經跨過鴻溝了，進入Early majority早期大眾階段，開始占領潛力巨大的主流市場。
根據CNCF在2018年8月進行的第六次測量容器管理市場的溫度，83%的受訪者更喜歡Kubernetes的容器管理工具，58％的受訪者在生產中使用Kubernetes，42％的受訪者正在進行評估以備將來使用，40％的企業（員工規模在5000 ）正在使用Kubernetes。Kubernetes在開發人員中已經變得非常流行。
回過頭來看，靈雀雲從早期全力投入Kubernetes技術棧，是最早進行Kubernetes產品化的廠商。我們並未滿足於把Kubernetes當作一個容器編排工具來使用，而是將它定位成構建上層平臺的核心框架，通過合理運用Kubernetes本身的擴展機制、架構模式與API規範，構建出一系列“Kubernetes原生”的產品體系。這樣做不僅真正發揮出Kubernetes作為雲計算核心框架的最大優勢，也可以與以Kubernetes為核心的雲原生生態無縫集成。
進入主流市場的Kubernetes開始變得“Boring”，這很正常，甚至是一個好的現象。核心項目的創新速度會減慢，最新的版本中主要關註點聚焦在穩定性、可擴展性這些方面，盡可能把代碼從主庫往外推，讓它的主庫變得幹凈，其他功能通過一些擴展機制來做，同時開始關註安全性。
Kubernetes項目本身已經過了現象級創新爆發的階段，但由Kubernetes獨特的架構屬性催生出的周邊生態的二次創新仍然在高速發展，例如諸多與Kubernetes集成或者基於Kubernetes框架開發的上層服務與平臺。這個話題我們下次討論，今天還是主要關註與Kubernetes項目關聯最緊密的創新亮點：
早期容器化workload大多聚焦在無狀態服務，跑的最多的是Nginx，而對有狀態應用避諱不談。現在Kubernetes進入主流市場，顯然需要對“現實中的應用”，包括有狀態服務提供良好的支持。2019年，對於復雜應用的管理以及Kubernetes本身的自動化運維將會更多的表現為Operator。
Operator是基於Kubernetes擴展機制，將運維知識編寫成“面向應用的Kubernetes原生控制器“，從而將一個應用的整體狀態作為API對象通過Kubernetes進行自動化管理。這個應用通常來說是比較復雜的有狀態應用，如MySQL數據庫、Redis集群、Prometheus等等。現在基本上常見的有狀態應用都有自己相對應的Operator，這是一種更為有效的管理分布式應用的方式。
其次是應用跨集群部署與管理。早期社區裏有Federation聯邦集群的方案。我們不少大金融客戶都有跨集群部署、管理業務的需求。當時深入研究Federation v1之後，覺得這個方案復雜度高，觀點性強，對於我們實際的需求靈活度不足而又不夠成熟。所以我們最終選擇自研跨集群部署。後來出現的Federation v2在設計方向上有不小改觀，是我們持續關註的項目。
早期采用容器技術的用戶都會盡可能兼容企業原有的IT基礎設施，比如底層物理機，保留物理機之上的虛擬層，虛擬機之上再跑容器。當然，面向資源管理的硬件虛擬化和面向應用的容器化本質上沒有沖突。隨著Kubernetes的普及並且在應用上超越了容器編排的範疇，後Kubernetes時代如何搭建管理基礎設施是值得思考的。我們也觀察到一些有意思的趨勢，比如在Kubernetes上同時管理容器和虛擬機（所謂的“容器原生虛擬化”），或是使用Kubernetes來管理OpenStack。
總之，Kubernetes在雲計算領域成為既定標準，會越來越多的往下管理所有種類的基礎設施，往上管理所有種類的應用。這類標準的形成對於技術社區有很大的益處，會大大降低圍繞Kubernetes技術投入的風險。因此，我們會看到越來越多的周邊技術向它靠攏，在Kubernetes之上催化出一個龐大的雲原生技術生態。
DevOps獨辟蹊徑：
開放式DevOps工具鏈集成與編排
DevOps理念、方法論和實踐已經走到了Early Majority早期大眾階段，是已被實踐證實的高效開發運維方法。做容器的廠商都經歷過用容器搞CI/CD，靈雀雲也不例外，CI/CD是容易發揮容器優勢的顯而易見的使用場景。在去年，我們做了重大的產品升級，將原來的CI/CD功能模塊擴展為完整的DevOps產品—Alauda DevOps平臺，覆蓋應用全生命周期。
DevOps包含好幾層概念，首先是組織文化的轉變，然後涉及到一系列最佳實踐，最終這些最佳實踐需要用工具去落地。我們在幫助很多大型企業客戶落地DevOps的過程中發現：
基於這些觀察，Alauda DevOps的定位並不是要提供一個新的DevOps產品，去取代客戶已有的工具選型。相反，我們致力於打造一個開放式的DevOps工具鏈集成與編排平臺。
這個平臺可以靈活的兼容客戶的工具選型，通過集成將各類工具串聯起來，形成一套工具鏈，通過編排讓DevOps工具鏈與容器平臺聯動，形成一個完整系統。同時，不斷結合自身的經驗，提煉DevOps落地的最佳實踐，平臺將這些最佳實踐自動化，作為服務進行輸出。這個思路在和客戶的交流以及實際落地過程中不斷獲得認可。
值得一提的是，我們對於DevOps工具鏈的編排也是基於Kubernetes來實現的。Kubernetes不僅是出色的容器編排工具，擴展之後也很適合編排DevOps工具。換句話說，我們開發了一套“Kubernetes原生的DevOps平臺”。
微服務：落地需要一套完整的基礎設施
提起微服務治理，很多人會條件反射般的聯想到某些特定的技術，例如Spring Cloud，或者Service Mesh。我們不妨先退後一步，系統考慮下企業微服務架構改造和落地所需要的完整的基礎設施。
首先，在微服務應用的底層需要一個應用管理平臺，這在今天毋庸置疑是一個基於Kubernetes的容器平臺。
微服務本質上是分布式應用，在我們獲取敏捷性的同時不可避免的增加了運維和管理的難度。微服務對自動化運維，尤其是可觀測性的要求很高。支持微服務架構的基礎設施必須具備完善的監控、告警、日誌、分布式追蹤等能力。
在微服務應用的前方，通常需要一個API網關，來管理對外暴露的API。API治理策略，包括安全、路由、流控、遙測、集成等對於任何應用平臺都重要，但在微服務架構下尤為關鍵。我們需要通過定義、封裝對外API來屏蔽應用內微服務組件結構細節，將客戶端與微服務解耦，甚至為不同客戶端提供個性化的API。
雲原生應用的一大準則是應用與狀態分離。在微服務架構下，每個微服務組件更是應該完全掌控自己的數據。所以，雲原生應用通常依賴外部數據服務（Backing Services），而在微服務架構下，多元化持久性（Polyglot Persistence）是常態，也就是說一個微服務架構的應用會依賴非常多種類的 Backing Services。面向微服務架構的基礎設施需要將這些外部服務暴露給微服務應用消費，甚至直接支撐各類Backing Services 的部署和管理。
一個團隊之所以采用微服務架構，一定有敏捷性的訴求。所以通常微服務團隊也會擁抱DevOps理念。一個完善的面向微服務架構的基礎設施需要考慮 DevOps 流程以及工具鏈的自動化。
最後，我們回到狹義的微服務治理，這裏關註的是微服務組件之間的連接與通訊，例如服務註冊發現、東西向路由流控、負載均衡、熔斷降級、遙測追蹤等。現在有個時髦的術語來描述這類功能，就是大家熟悉的Service Mesh。其實早期 Sping Cloud 之類的框架解決的是類似的問題，但在實現的方式上，尤其是mesh 和業務代碼的耦合度上，有本質的區別。
當我們考慮一個平臺如何支撐微服務架構的時候，需要涵蓋上述提及的方方面面，從產品的角度我們會保持一個開放的態度。這其中一部分需要我們自己去做，其他一些可以借助生態合作夥伴的能力去補全完善。
此外，微服務架構也進入到了後Kubernetes時代，早期基本上是微服務作為用例推動容器技術的發展。今天已經反過來了，成為標準的Kubernetes其實在驅動和重新定義微服務的最佳實踐。容器和Kubernetes為微服務架構的落地提供了絕佳的客觀條件。
Service Mesh： 下一個亟待爆發的現象級技術創新
業界對於Service Mesh的布道已經持續了一段時間，我們今天不再重復基本的概念。當我們把Service Mesh和上一代以Spring Cloud為代表的微服務治理框架以及更早的Service Oriented Architecture (SOA) 作比較的時候，會看到一個有意思的演化。
我們知道，SOA有企業服務總線（ESB）的概念，ESB重且復雜，其實會混雜很多業務邏輯。SOA架構下，ESB最終容易變成架構以及敏捷性的瓶頸。早期推廣微服務架構的時候，一個重要的概念就是“Smart Endpoints and Dumb Pipes”，針對的就是SOA下ESB的痛點，從而每個微服務能夠獨立、自治、松耦合。
但是仔細去想的話，就會發現它其實走到了另一個極端：它把一些基礎設施提供的能力放到微服務的業務組件裏面了，通常每個組件需要加載一些治理框架提供的庫，或是調用特定的API，其實就是在業務組件裏內置了基礎設施的功能。到了Service Mesh其實又把它們分開了，從架構角度這樣也比較合理，應用是純業務的東西，裏面沒有任何基礎設施，而提供微服務治理的基礎設施，要麽在Mesh裏面，要麽由底層的Kubernetes平臺來提供，對應用是透明的。
Istio的出現促使業界對於Service Mesh的架構有了新的共識：控制平面（Control Plane）與數據平面（Data Plane）解耦。通過獨立的控制平面可以對Mesh獲得全局性的可觀測性（Observability）和可控制性（Controllability），讓Service Mesh有機會上升到平臺的高度。相對於需要在業務代碼層面使用的上一代微服務治理框架，這點對於希望提供面向微服務架構基礎設施的廠商，或是企業內部需要賦能業務團隊的平臺部門都具有相當大的吸引力。
在Data Plane，Envoy的領導者地位毫無爭議。Envoy使用C 開發，在資源使用效率和性能上（尤其是長尾性能差異）相較早期主要競爭對手Linkerd有明顯優勢。Envoy提供基於filter chain的擴展機制，從Kubernetes的成功當中我們已經學習到，可擴展性對於大規模采用十分關鍵。
Envoy定義了一套“通用數據平面API”（Universal Data Plane API），也就是它的xDS協議。不僅確保了Envoy本身的動態可配置性，更重要的是為Service Mesh中Control Plane和Data Plane解耦提供了一個標準的接口。由於主流Control Plane（例如Istio）對Envoy以及xDS的采納，xDS成為Service Mesh Data Plane API的事實標準，Envoy也成為無可爭議的Data Plane領導者。
在Control Plane，Istio是最具光環的明星級項目。它正在引領Service Mesh創造出一個全新的市場，不過從傳播周期看現在還沒有跨過技術鴻溝，處於Early adopters階段。
過去一年中，Istio項目在技術上的表現並不完全令人滿意，主要體現在對其復雜度的詬病，以及穩定性和性能的質疑。1.0版本的推出並沒有完全令人信服。不過，這些似乎並不影響Istio在社區獲得的巨大成功。在開源領域，並不存在對Istio有實質性威脅的競品。可能在經歷了Kubernetes之後，以及Istio早期迅猛的發展和在社區中巨大的影響力之下，很少有開源項目願意在Control Plane和Istio正面交鋒。
長遠來講，Data Plane會慢慢變成commodity，尤其在有了Universal Data Plane API之後。我們有理由相信成熟穩健的Envoy會保持領先，但最終多數用戶會越來越少去關心具體的Data Plane技術。這個情境似曾相識，和當初Docker與Kubernetes的關系有點類似。
下個階段Service Mesh的賦能和創新會更多聚焦在Control Plane。AWS在Data Plane選擇成熟的Envoy，而自己開發App Mesh的Control Plane，就很容易理解。靈雀雲已經在ACE/ACP兩條產品線中集成了Istio，提供企業就緒的Service Mesh。
雲原生為機器學習輸出工程化最佳實踐
雲原生的理念與相關技術對於應用開發與交付的巨大價值已經被普遍接受。但雲原生不僅僅可以作用在普通的應用開發上。站在容器平臺的角度看，機器學習毫無疑問是一類極為重要新興工作負載。在未來，可能所有的公司都會是AI公司，所有的應用都會是智能應用，使用算法、模型就像今天應用會依賴數據庫一樣普遍。
如果我們分析數據科學家的工作流，會發現和傳統應用開發有很多相似的挑戰。如何方便的獲取實驗環境；如何讓實驗可重復；如何將數據處理、特征提取、模型訓練、模型驗證、模型發布這些步驟自動化，並且可重復；如何讓研究和生產環境保持一致；如何在生產環境做模型變更、AB測試、灰度發布；如何在生產環境運維模型服務；如何將模型服務化，等等。
在軟件工程領域，雲原生的理念、方法論和最佳實踐已經為類似問題找到了良好的解決方案。這些方案其實非常適合應用在機器學習場景。換句話說，我們需要“雲原生機器學習”。這仍然是一個相對早期的概念，從鴻溝理論的周期來看，雲原生機器學習大致還處在Innovators創新者嘗鮮的階段。我們去年發布的Alauda Machine Learning (AML) 就是一個“雲原生機器學習平臺”，目標是從雲平臺的角度，用雲原生的思路去落地機器學習工程化的最佳實踐。
靈雀雲CTO陳愷：從“鴻溝理論”看雲原生，哪些技術能夠跨越鴻溝？
歷史進入2019年，放眼望去，今天的整個技術大環境和生態都發生了很大的變化。在己亥豬年春節剛剛過去的早春時節，我們來梳理和展望一下整個雲原生技術趨勢的發展，是一件很有意義的事情，這其中有些變化在不可避免地影響著我們身處其中的每一家企業。如果說雲原生在2017年還僅僅是冒出了一些苗頭，那麽2018可以說是普及之年，雲原生變成了一個成熟的、被普遍接受的理念。靈雀雲作為雲原生理念的擁躉，也不斷順應這種趨勢，聚焦雲原生的核心場景，圍繞容器平臺、DevOps和微服務黃金三角進行產品的研發和業務場景的落地。
早在1991年Jeffery Moore針對高科技行業和高科技企業生命周期的特點，提出了著名的“鴻溝理論”。這個理論基於“創新傳播學”，將創新性技術和產品的生命周期分為五個階段：創新者（Innovator）、早期使用者（Early adopters）、早期大眾（Early majority）、晚期大眾（Late majority）、落後者（Laggard）。
在Early adopters和Early majority之間有個巨大的鴻溝（Chasm），每個新技術都會經歷鴻溝，大多數失敗的產品也都是在鴻溝裏結束了其整個生命周期，能否順利跨越“鴻溝”，決定了創新性技術的成敗。今天我們嘗試以鴻溝理論為基礎來分析雲原生領域顛覆性的創新技術。
“Kubernetes is Boring”，邊緣創新有亮點
Kubernetes在2017年底成為容器編排事實標準，之後以其為核心的生態持續爆發，在傳播周期上可以說已經跨過鴻溝了，進入Early majority早期大眾階段，開始占領潛力巨大的主流市場。
根據CNCF在2018年8月進行的第六次測量容器管理市場的溫度，83%的受訪者更喜歡Kubernetes的容器管理工具，58％的受訪者在生產中使用Kubernetes，42％的受訪者正在進行評估以備將來使用，40％的企業（員工規模在5000 ）正在使用Kubernetes。Kubernetes在開發人員中已經變得非常流行。
回過頭來看，靈雀雲從早期全力投入Kubernetes技術棧，是最早進行Kubernetes產品化的廠商。我們並未滿足於把Kubernetes當作一個容器編排工具來使用，而是將它定位成構建上層平臺的核心框架，通過合理運用Kubernetes本身的擴展機制、架構模式與API規範，構建出一系列“Kubernetes原生”的產品體系。這樣做不僅真正發揮出Kubernetes作為雲計算核心框架的最大優勢，也可以與以Kubernetes為核心的雲原生生態無縫集成。
進入主流市場的Kubernetes開始變得“Boring”，這很正常，甚至是一個好的現象。核心項目的創新速度會減慢，最新的版本中主要關註點聚焦在穩定性、可擴展性這些方面，盡可能把代碼從主庫往外推，讓它的主庫變得幹凈，其他功能通過一些擴展機制來做，同時開始關註安全性。
Kubernetes項目本身已經過了現象級創新爆發的階段，但由Kubernetes獨特的架構屬性催生出的周邊生態的二次創新仍然在高速發展，例如諸多與Kubernetes集成或者基於Kubernetes框架開發的上層服務與平臺。這個話題我們下次討論，今天還是主要關註與Kubernetes項目關聯最緊密的創新亮點：
早期容器化workload大多聚焦在無狀態服務，跑的最多的是Nginx，而對有狀態應用避諱不談。現在Kubernetes進入主流市場，顯然需要對“現實中的應用”，包括有狀態服務提供良好的支持。2019年，對於復雜應用的管理以及Kubernetes本身的自動化運維將會更多的表現為Operator。
Operator是基於Kubernetes擴展機制，將運維知識編寫成“面向應用的Kubernetes原生控制器“，從而將一個應用的整體狀態作為API對象通過Kubernetes進行自動化管理。這個應用通常來說是比較復雜的有狀態應用，如MySQL數據庫、Redis集群、Prometheus等等。現在基本上常見的有狀態應用都有自己相對應的Operator，這是一種更為有效的管理分布式應用的方式。
其次是應用跨集群部署與管理。早期社區裏有Federation聯邦集群的方案。我們不少大金融客戶都有跨集群部署、管理業務的需求。當時深入研究Federation v1之後，覺得這個方案復雜度高，觀點性強，對於我們實際的需求靈活度不足而又不夠成熟。所以我們最終選擇自研跨集群部署。後來出現的Federation v2在設計方向上有不小改觀，是我們持續關註的項目。
早期采用容器技術的用戶都會盡可能兼容企業原有的IT基礎設施，比如底層物理機，保留物理機之上的虛擬層，虛擬機之上再跑容器。當然，面向資源管理的硬件虛擬化和面向應用的容器化本質上沒有沖突。隨著Kubernetes的普及並且在應用上超越了容器編排的範疇，後Kubernetes時代如何搭建管理基礎設施是值得思考的。我們也觀察到一些有意思的趨勢，比如在Kubernetes上同時管理容器和虛擬機（所謂的“容器原生虛擬化”），或是使用Kubernetes來管理OpenStack。
總之，Kubernetes在雲計算領域成為既定標準，會越來越多的往下管理所有種類的基礎設施，往上管理所有種類的應用。這類標準的形成對於技術社區有很大的益處，會大大降低圍繞Kubernetes技術投入的風險。因此，我們會看到越來越多的周邊技術向它靠攏，在Kubernetes之上催化出一個龐大的雲原生技術生態。
DevOps獨辟蹊徑：
開放式DevOps工具鏈集成與編排
DevOps理念、方法論和實踐已經走到了Early Majority早期大眾階段，是已被實踐證實的高效開發運維方法。做容器的廠商都經歷過用容器搞CI/CD，靈雀雲也不例外，CI/CD是容易發揮容器優勢的顯而易見的使用場景。在去年，我們做了重大的產品升級，將原來的CI/CD功能模塊擴展為完整的DevOps產品—Alauda DevOps平臺，覆蓋應用全生命周期。
DevOps包含好幾層概念，首先是組織文化的轉變，然後涉及到一系列最佳實踐，最終這些最佳實踐需要用工具去落地。我們在幫助很多大型企業客戶落地DevOps的過程中發現：
- 在DevOps的整個流程裏涉及到很多類別的工具，每一個類別都會有大量的選擇；2. 每個客戶的工具選型多少會有些不同，並不存在一個固定的、完全標準的工具組合；3. 隨著時間的推移工具選擇會發生變化，多數客戶意識到目前使用中的工具在未來很可能會被替代。
基於這些觀察，Alauda DevOps的定位並不是要提供一個新的DevOps產品，去取代客戶已有的工具選型。相反，我們致力於打造一個開放式的DevOps工具鏈集成與編排平臺。
這個平臺可以靈活的兼容客戶的工具選型，通過集成將各類工具串聯起來，形成一套工具鏈，通過編排讓DevOps工具鏈與容器平臺聯動，形成一個完整系統。同時，不斷結合自身的經驗，提煉DevOps落地的最佳實踐，平臺將這些最佳實踐自動化，作為服務進行輸出。這個思路在和客戶的交流以及實際落地過程中不斷獲得認可。
值得一提的是，我們對於DevOps工具鏈的編排也是基於Kubernetes來實現的。Kubernetes不僅是出色的容器編排工具，擴展之後也很適合編排DevOps工具。換句話說，我們開發了一套“Kubernetes原生的DevOps平臺”。
微服務：落地需要一套完整的基礎設施
提起微服務治理，很多人會條件反射般的聯想到某些特定的技術，例如Spring Cloud，或者Service Mesh。我們不妨先退後一步，系統考慮下企業微服務架構改造和落地所需要的完整的基礎設施。
首先，在微服務應用的底層需要一個應用管理平臺，這在今天毋庸置疑是一個基於Kubernetes的容器平臺。
微服務本質上是分布式應用，在我們獲取敏捷性的同時不可避免的增加了運維和管理的難度。微服務對自動化運維，尤其是可觀測性的要求很高。支持微服務架構的基礎設施必須具備完善的監控、告警、日誌、分布式追蹤等能力。
在微服務應用的前方，通常需要一個API網關，來管理對外暴露的API。API治理策略，包括安全、路由、流控、遙測、集成等對於任何應用平臺都重要，但在微服務架構下尤為關鍵。我們需要通過定義、封裝對外API來屏蔽應用內微服務組件結構細節，將客戶端與微服務解耦，甚至為不同客戶端提供個性化的API。
雲原生應用的一大準則是應用與狀態分離。在微服務架構下，每個微服務組件更是應該完全掌控自己的數據。所以，雲原生應用通常依賴外部數據服務（Backing Services），而在微服務架構下，多元化持久性（Polyglot Persistence）是常態，也就是說一個微服務架構的應用會依賴非常多種類的 Backing Services。面向微服務架構的基礎設施需要將這些外部服務暴露給微服務應用消費，甚至直接支撐各類Backing Services 的部署和管理。
一個團隊之所以采用微服務架構，一定有敏捷性的訴求。所以通常微服務團隊也會擁抱DevOps理念。一個完善的面向微服務架構的基礎設施需要考慮 DevOps 流程以及工具鏈的自動化。
最後，我們回到狹義的微服務治理，這裏關註的是微服務組件之間的連接與通訊，例如服務註冊發現、東西向路由流控、負載均衡、熔斷降級、遙測追蹤等。現在有個時髦的術語來描述這類功能，就是大家熟悉的Service Mesh。其實早期 Sping Cloud 之類的框架解決的是類似的問題，但在實現的方式上，尤其是mesh 和業務代碼的耦合度上，有本質的區別。
當我們考慮一個平臺如何支撐微服務架構的時候，需要涵蓋上述提及的方方面面，從產品的角度我們會保持一個開放的態度。這其中一部分需要我們自己去做，其他一些可以借助生態合作夥伴的能力去補全完善。
此外，微服務架構也進入到了後Kubernetes時代，早期基本上是微服務作為用例推動容器技術的發展。今天已經反過來了，成為標準的Kubernetes其實在驅動和重新定義微服務的最佳實踐。容器和Kubernetes為微服務架構的落地提供了絕佳的客觀條件。
Service Mesh： 下一個亟待爆發的現象級技術創新
業界對於Service Mesh的布道已經持續了一段時間，我們今天不再重復基本的概念。當我們把Service Mesh和上一代以Spring Cloud為代表的微服務治理框架以及更早的Service Oriented Architecture (SOA) 作比較的時候，會看到一個有意思的演化。
我們知道，SOA有企業服務總線（ESB）的概念，ESB重且復雜，其實會混雜很多業務邏輯。SOA架構下，ESB最終容易變成架構以及敏捷性的瓶頸。早期推廣微服務架構的時候，一個重要的概念就是“Smart Endpoints and Dumb Pipes”，針對的就是SOA下ESB的痛點，從而每個微服務能夠獨立、自治、松耦合。
但是仔細去想的話，就會發現它其實走到了另一個極端：它把一些基礎設施提供的能力放到微服務的業務組件裏面了，通常每個組件需要加載一些治理框架提供的庫，或是調用特定的API，其實就是在業務組件裏內置了基礎設施的功能。到了Service Mesh其實又把它們分開了，從架構角度這樣也比較合理，應用是純業務的東西，裏面沒有任何基礎設施，而提供微服務治理的基礎設施，要麽在Mesh裏面，要麽由底層的Kubernetes平臺來提供，對應用是透明的。
Istio的出現促使業界對於Service Mesh的架構有了新的共識：控制平面（Control Plane）與數據平面（Data Plane）解耦。通過獨立的控制平面可以對Mesh獲得全局性的可觀測性（Observability）和可控制性（Controllability），讓Service Mesh有機會上升到平臺的高度。相對於需要在業務代碼層面使用的上一代微服務治理框架，這點對於希望提供面向微服務架構基礎設施的廠商，或是企業內部需要賦能業務團隊的平臺部門都具有相當大的吸引力。
在Data Plane，Envoy的領導者地位毫無爭議。Envoy使用C 開發，在資源使用效率和性能上（尤其是長尾性能差異）相較早期主要競爭對手Linkerd有明顯優勢。Envoy提供基於filter chain的擴展機制，從Kubernetes的成功當中我們已經學習到，可擴展性對於大規模采用十分關鍵。
Envoy定義了一套“通用數據平面API”（Universal Data Plane API），也就是它的xDS協議。不僅確保了Envoy本身的動態可配置性，更重要的是為Service Mesh中Control Plane和Data Plane解耦提供了一個標準的接口。由於主流Control Plane（例如Istio）對Envoy以及xDS的采納，xDS成為Service Mesh Data Plane API的事實標準，Envoy也成為無可爭議的Data Plane領導者。
在Control Plane，Istio是最具光環的明星級項目。它正在引領Service Mesh創造出一個全新的市場，不過從傳播周期看現在還沒有跨過技術鴻溝，處於Early adopters階段。
過去一年中，Istio項目在技術上的表現並不完全令人滿意，主要體現在對其復雜度的詬病，以及穩定性和性能的質疑。1.0版本的推出並沒有完全令人信服。不過，這些似乎並不影響Istio在社區獲得的巨大成功。在開源領域，並不存在對Istio有實質性威脅的競品。可能在經歷了Kubernetes之後，以及Istio早期迅猛的發展和在社區中巨大的影響力之下，很少有開源項目願意在Control Plane和Istio正面交鋒。
長遠來講，Data Plane會慢慢變成commodity，尤其在有了Universal Data Plane API之後。我們有理由相信成熟穩健的Envoy會保持領先，但最終多數用戶會越來越少去關心具體的Data Plane技術。這個情境似曾相識，和當初Docker與Kubernetes的關系有點類似。
下個階段Service Mesh的賦能和創新會更多聚焦在Control Plane。AWS在Data Plane選擇成熟的Envoy，而自己開發App Mesh的Control Plane，就很容易理解。靈雀雲已經在ACE/ACP兩條產品線中集成了Istio，提供企業就緒的Service Mesh。
雲原生為機器學習輸出工程化最佳實踐
雲原生的理念與相關技術對於應用開發與交付的巨大價值已經被普遍接受。但雲原生不僅僅可以作用在普通的應用開發上。站在容器平臺的角度看，機器學習毫無疑問是一類極為重要新興工作負載。在未來，可能所有的公司都會是AI公司，所有的應用都會是智能應用，使用算法、模型就像今天應用會依賴數據庫一樣普遍。
如果我們分析數據科學家的工作流，會發現和傳統應用開發有很多相似的挑戰。如何方便的獲取實驗環境；如何讓實驗可重復；如何將數據處理、特征提取、模型訓練、模型驗證、模型發布這些步驟自動化，並且可重復；如何讓研究和生產環境保持一致；如何在生產環境做模型變更、AB測試、灰度發布；如何在生產環境運維模型服務；如何將模型服務化，等等。
在軟件工程領域，雲原生的理念、方法論和最佳實踐已經為類似問題找到了良好的解決方案。這些方案其實非常適合應用在機器學習場景。換句話說，我們需要“雲原生機器學習”。這仍然是一個相對早期的概念，從鴻溝理論的周期來看，雲原生機器學習大致還處在Innovators創新者嘗鮮的階段。我們去年發布的Alauda Machine Learning (AML) 就是一個“雲原生機器學習平臺”，目標是從雲平臺的角度，用雲原生的思路去落地機器學習工程化的最佳實踐。
靈雀雲CTO陳愷：從“鴻溝理論”看雲原生，哪些技術能夠跨越鴻溝？