前言：當前，微服務改造正在許多企業當中如火如荼地進行，然而，微服務改造帶來許多新問題成了進一步發展的障礙，在這一背景下，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，所以，在上線前，必須要經過長期的測試驗證，時速雲與友商最大的不同在於此，而現在，時速雲已經度過了這一階段。