中國數據存儲服務平臺

時速云:微服務發展看Service Mesh,Service Mesh發展看落地經驗

前言:當前,微服務改造正在許多企業當中如火如荼地進行,然而,微服務改造帶來許多新問題成了進一步發展的障礙,在這一背景下,Service Mesh應運而生,Service Mesh將是微服務進一步發展的關鍵。從實際出發,時速云基于自研技術克服了Service Mesh落地中的各種障礙,這個過程中我們也感悟到,業務微服務架構的進一步發展,技術的先進性是持續演進的方向,而如何更好的結合企業實際場景才是推進服務網格落地的關鍵。

2013年,有一個叫Docker的容器技術突然火了起來,2015年前后,在大眾創業、萬眾創新的號召下,企業服務市場涌現出了多家容器創業公司。而今,這些基于容器的創業公司,有的已經消失,有的慢慢的一步步走來,可能沒人能預想到容器生態是今天這般繁榮景象,但至少2015年的一些未知現在已經有了確定答案。

基于容器技術的微服務大行其道

首先,容器技術確實如人們想象中的那樣有突破性,就如當時所說的,是繼傳統虛擬化之后的又一大創新技術。傳統虛擬化和容器確實有一定的替代關系,越來越多的容器化應用采用直接部署在裸機服務器而不是傳統虛擬化架構之上。

更重要的是,企業驗證了容器技術的可用性和穩定性,有動力也有決心對應用做微服務化改造。

2020年,時速云技術總監張壽紅在談到技術與應用發展時表示,如今基于容器技術的PaaS平臺已經非常成熟,企業已經基本無障礙地快速部署上PaaS平臺,許多企業正在使用容器應用,并且正在對現有應用做微服務化改造。

企業之所以熱衷于構建微服務架構,主要是因為,沒有微服務架構之前的單體應用時代,應用的每次變更都非常困難,可謂是牽一發動全身。而微服務架構能為每一個微服務獨立開發、部署、升級,進行彈性伸縮,它會使得應用的升級在局部完成迭代更新,不會對整體應用造成影響。這就是微服務的魅力所在。

微服務的出現也帶來了許多新的問題,Service Mesh正是為了解決它帶來的新問題而生的,Service Mesh是企業落地微服務架構的關鍵,有了Service Mesh,企業才能放心大膽地用上微服務,可以說,Service Mesh是擺在所有容器創業公司面前的,繼企業PaaS平臺之后的第二大考題。

微服務帶來的新問題

微服務改造就是將原來一個個單體應用拆分為若干個微服務,優勢很明顯,帶來的問題也非常顯而易見。

從管理的角度看。當微服務數量特別多的時候,架構會變得非常復雜,更重要的是,當一個微服務出現問題可能會影響到許多其它微服務。隨之而來的是,如此復雜的架構下,故障排查從何做起?如何快速定位故障點呢?

從安全的角度看,當微服務從單體應用拆分之后,原來在一個進程里的調用至少會分散到兩個進程里去,在一個進程里的調用沒有安全問題,但拆開后的調用可能會跨網絡、跨系統甚至跨數據中心來調用,帶來很大的安全隱患。

Service Mesh本質上是一張負責微服務之間通信的網絡,它是服務間的一個通訊層,它本身不與應用代碼耦合,而且還能捕獲到底層環境的動態變化并作出調整。Service Mesh無需程序員關注它,讓程序員只需要關注自身業務代碼就行了,這就是Service Mesh存在的意義。

從本質上來說,沒有Service Mesh的話,微服務也能正常工作,此前的微服務框架間的通訊采用SDK的方案,這一方案有較大侵入性,說白了,就是需要寫應用程序代碼的程序員關注到它,與Service Mesh相比,高下立判。

微服務框架的技術流派

早期,業內主流的Service Mesh方案是用Linkerd來實現的,但Linkerd只有數據面的能力,而后,Istio出現后提出了控制平面的概念,為的是讓服務治理的策略配置進行統一控制,這一思想奠定了Service Mesh的架構基礎,也就是控制平面和數據平面兩部分。

Istio不僅架構先進,而且背后還有IBM以及谷歌這樣的業內巨頭的大力支持,于是很快就成了業內標準,幾年前,在谷歌的力推下Kubernetes(K8s)不久便一統江湖了,巨頭的技術影響力可見一斑。

嚴格來說,Istio實現的是控制平面,但缺少數據平面,后來,Istio默認的數據面是使用Envoy來做的。本以為Istio和Envoy的組合將是大多數選擇,但張壽紅表示,時速云在控制平面用的是Istio,而數據平面用的是自研的一套方案。

這樣選擇是有原因的,在張壽紅看來,雖然Envoy在穩定性和性能方面表現還不錯,但它最大的問題是在于維護成本高,考慮到在企業落地微服務架構時經常需要做許多定制化的開發,所以,直接拿Envoy來用是不行的,需要在Envoy基礎上做許多開發。

但問題是,Envoy是用C++開發的,而云原生領域絕對主流的開發語言是Go語言,考慮到維護成本的問題,時速云最后選擇了自研之路。其實,Go語言工程師的成本也很高,但當絕大多數都是由Go語言來完成,而少部分由C++語言來完成的話,確實比較別扭。

Service Mesh落地難的問題

Service Mesh是一個說起來比較美好,但并不容易落地的技術方案,目前來看,國內在生產環境中Service Mesh的落地案例一直非常少,在張壽紅看來,主要原因在于由國際巨頭主導的技術方案在中國企業落地時出現了水土不服,國內企業使用的通信協議以及服務的部署形態與國際其他地區有所不同,需要部署落地時候有針對性地加入一些功能。

常見的尷尬是,許多企業在針對Service Mesh做技術驗證時,系統運行的很順暢,但真到落地的時候,則會發現困難重重,這些問題導致Service Mesh在國內落地困難的尷尬,如何化解這些尷尬呢?

時速云作為國內Service Mesh落地方案經驗頗多的一家,指出了三點。

首先是要增強方案的易用性,張壽紅介紹說,增強易用性是大勢所趨,Istio也意識到了易用性的重要性,最近更新的Istio新版本也著重增強了易用性。而在未來,則是會考慮做一些自動化運維的能力,以此強化易用性。

其次是針對特定場景的能力,現有架構,比如Istio主要是針對容器化部署場景開發的,但實際上企業里有容器化應用,同時也有許多在虛擬機環境,這需要Service Mesh方案能具備治理異構部署微服務的能力,企業內部環境其實非常復雜,這要求有較高的適用性。

第三點是優化性能,由于Service Mesh需要用到一層代理,不可避免的會造成性能損耗,用戶對于Service Mesh的性能有顧慮也是一大阻礙因素,用戶不希望性能損耗影響業務。張壽紅表示,性能優化也只能一步一步來,通過數據平面和控制平面下手。

時速云在方案上著眼于三個要注意的點,在實際落地中,更多靠自研能力將Service Mesh方案集成到用戶現有的架構中,對接用戶原有的日志、監控等各種系統,這對于定制化開發的能力要求很高。

技術已不是競爭壁壘,落地經驗才是

在談到友商的競爭差異時,張壽紅表示,從根本上來講,同類廠商在技術上的差異性很小,主要差異體現在實際落地的案例和經驗上,而時速云是目前國內少數有一些落地經驗的一家。

從張壽紅的介紹中了解到,金融行業用戶在容器方面的探索走的比較靠前,金融行業用戶正在將大量的負載從虛擬化平臺遷移到容器平臺上,這為基于Service Mesh的微服務架構落地打下了很好的基礎。

以某大型綜合型保險集團為例,先是采用了時速云的PaaS平臺,而在今年,該集團上線了新平臺,在內部構件了技術中臺,背后的支撐架構就是時速云的Service Mesh, 據了解,該集團項目目前在生產環境上線了大約幾千個微服務。

性能是保險客戶非??粗氐姆矫嬷?,在上線到生產環境前,時速云的Service Mesh經過了嚴格的性能和穩定性測試,以幾萬級別的負載量測試,最后只實際部署幾千個微服務,足見金融用戶的謹慎,但也恰好反映出用戶對于Service Mesh本身的認可。

像該集團案例這樣,先上容器云PaaS平臺,而后在此基礎上上線Service Mesh是比較常見的實施路徑。事實上,容器云PaaS平臺是微服務架構的基礎,目前業內的容器云PaaS平臺本身各方面已經非常的成熟,而且,企業也非常認可容器云PaaS平臺的實際作用,也都會將其視為容器化改造的第一步。

盡管有了容器云PaaS平臺的基礎,但仍要Service Mesh解決許多對接原有系統的需求,好在時速云采用了自研的策略,在面對有許多歷史負擔用戶時,能處理各種復雜的、非業內標準的協議,滿足大型企業的需求。而那些復用開源社區Istio + Envoy的方案則更適合沒有歷史負擔的中小企業用戶。

結語

如今的容器云PaaS已經是送分題,而Service Mesh才是拉分題,而Service Mesh最核心的競爭力就是經過實際驗證,具備生產環境上線的能力。Service Mesh關系重大,業務上的所有調用都要經過Service Mesh,所以,在上線前,必須要經過長期的測試驗證,時速云與友商最大的不同在于此,而現在,時速云已經度過了這一階段。

未經允許不得轉載:存儲在線 » 時速云:微服務發展看Service Mesh,Service Mesh發展看落地經驗
分享到: 更多 (0)
天津快乐十分奖金多少