微服務發展看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 Mes存在的意義。

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

微服務框架的技術流派

早期，業內主流的Service Mesh方案是用Linkyard來實現的，但Linkyard只有數據面的能力，然後，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，因此，在上線前，必需要通過長期的測試驗證，時速雲與友商最大的不一樣在於此，而如今，時速雲已經度過了這一階段。