華爲多年實踐：ServiceComb在Service Mesh的探索與思考

內容來源：2018 年 6 月 27 日，華爲微服務架構師田曉亮在「LC3微服務Workshop | 深刻解讀ServiceComb」進行《ServiceComb的ServiceMesh思考及在華爲雲的實踐》的演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3606 | 10分鐘閱讀

觀看嘉賓演講視頻及PPT，請點擊：t.cn/E2vZBkB

摘要

咱們今天圍繞三個主題來說，首先會講一下Service Mesh在華爲多年的實踐，另外會介紹一些實踐的方法，最後會介紹幾個案例來帶你們看一下，咱們是怎麼在實踐中幫助企業在生產環境中使用Service Mesh。

華爲內部演進

實際上咱們在作微服務的時候，整個演進的過程當中要解決不少微服務架構帶來的複雜的問題。我我的曾實現過一個Go版本的微服務開源框架，這個框架有大概2萬行左右的代碼，並交付給業務使用，這個過程耗時很是長，實際上通常的公司是沒有這個實力去交付的，另外可能還須要一些時間去讓開發者去適應框架。

對此的另外一種解決方案是使用Service Mesh，這是一個網絡模型，不一樣於開發框架在應用層和應用耦合在一塊兒，以解決微服務的複雜問題。Service Mesh是在TCP IP之上提供代理的方式和Application解耦，而後幫你去作發現、熔斷、限流、監控等事情，這些都是在五層協議來作的。

其實能夠這樣看待，過去的Application是跑在tcp ip之上，如今這些服務跑在Service Mesh服務網絡之上，並且這個過程不須要對原有代碼進行一點修改。

實際上華爲內部很早就已經有了很是多的實踐。13年的時候實現了微服務開發平臺中的IR組件，它是在每個節點上有一個內部路由，這個節點上全部的Application由平臺部署，部署進去以後由有一個叫RouterAgent組件將APP註冊到zookeeper上，同時RouterAgent會刷新IR中的路由表，這樣的就能夠作發現了。

Application之間的全部通訊呢都是經過Router來進行的，可是它是由nginx實現的，因此有幾個缺點。首先一旦節點掛了以後，節點上的全部Application即進不來也出不去，通訊就都沒有了。另外擴展性受到必定侷限，語言生態不像Go語言Java那麼好。

咱們在15年的時候又作了一個叫sidecar的組件，這也是一個大框架下的組件。它的原理其實已經和如今的Service Mesh很是像了，利用了kubernetes的一個pod下能夠又多個容器的能力，一個container是承載業務，另一個container就是sidecar。全部服務的請求都要經過sidecar進行發送接收，通常來講這些Service都是HTTP的service。sidecar其實也有本身的一些缺點，好比說它是Java開發的，你們都知道，java虛擬機是很是的佔用資源的，如今每一個微服務都要起一個虛擬機，總的來講不夠清亮，因此sidecar其實不符合Service Mesh的最佳實踐。

Mesher

後來咱們用Go語言重寫了Mesher組件，由於當時咱們聽到了這個概念以後，認爲能夠根據他的理論來實現一個咱們本身的組件，而後咱們就用了go語言去寫。那麼好處是什麼？首先它的性能極高，並且佔用資源很是小，很是符合Service Mesh的標準，由於它不會佔用你的數據中心不少的資源。

能夠看到上圖中，Mesher在一個pod裏邊和服務跑在一塊兒，它在內部支撐了不少的微服務的特性，好比發現、壟斷、負載均衡、動態配置。它還會幫你維護健康，最後作發現的時候，是基於本地緩存。

上圖是Mesher的詳細架構。上面的那塊是一個控制面板，支持多種的生態，-ServiceComb、Istio、Zipkin等，它和目前比較火的ECU平臺最大的一個不一樣點，就是可以支持異構的基礎設施，不會綁定kubernetes，還能夠部署在說有云、Bare metal、VM上面。

註冊發現

這個是咱們註冊發現的設計，它是作了兩個抽象，一個叫註冊器，一個叫服務發現。這樣作的好處是可以支持客戶端註冊發現，也就是說當你沒有像kubernetes這樣的平臺的時候，能夠進行自注冊。自行註冊到Service Center上面，而後經過Service Discovery去作發現。當使用相似於ECU這樣的平臺的時候，因爲它們會幫你自動維護生命週期，因此這個時候就不須要再去自注冊或者維護心跳了，此時能夠選擇只運行一個Service Discovery來適配這個平臺，這樣就很是靈活了。

基於微服務元數據的路由管理

在Service Discovery之上會有一層統一的緩存模型，基於它們能夠作很是豐富的路由管理。流量進來後會首先判斷此次請求的特徵，從請求中能夠知道要訪問的目標服務是什麼，這裏最關鍵的一個點就是你的服務名是什麼，最後經過服務名來查遠程或本地的路由表，決定service name的對所對應的metadata是什麼，而後根據這些元數據去本身的本地緩存中查出真實的service instance列表，最後進行訪問。

多協議支持

對於多協議支持咱們抽象了一個Invocation，經過Invocation能夠把不一樣的協議接入到統一的模型當中，而且享有一樣的治理能力，好比路由管理、限流、監控，這些功能呢都被集成到Handler Chain裏，Handler Chain處理的就是Invocation對象。而真實在網絡間進行傳輸的仍是協議的以及和協議相兼容的數據包。

ServiceComb Service Center架構嚴禁

這是咱們後來推動的Service Center的架構演進，首先咱們抽象了一個Adaptor層去適配不一樣的註冊發現，怎麼作其實是因爲數據中心會愈來愈大，而且咱們認爲任何一種雲其實它都都是不可靠的。因此後來咱們搭建了本身的私有云的中心，而後作了混合雲，推動Service Centere架構演進也是但願它可以支持多雲。除了這個價值以外，它還能夠支持異構，好比把VM和K8S進行混編，可以讓你在一個地方看到全部的數據中心以及全部異構設施中的微服務。

一站式解決方案

這個是咱們的一個一站式解決方案，基於ServiceComb解決方案，Mesher，go chassis等組件,支持java，go語言編程框架和多語言接入，讓你使用統一的管理平臺進行管理。

Istio生態

咱們的另外一個策略是在開源方面擁抱Istio生態，和別的地方不一樣的，咱們會把go chassis開發框架接入到Istio當中，這樣作的一個好處就是能夠提高服務的總體性能。由於實際上Service Mesh的方案，因爲是一個服務代理，因此說全部的請求數據都會有一個從用戶到內核，再從內核到用戶的過程，整個過程都是要乘二的，因此性能實際上是會有下降，一些對性能很敏感的用戶，可能會傾向於使用侵入框架。而Istio正好提供Service Mesh方案，因此咱們把go chassis帶入到Istio中，同時把Mixer也帶進去，成爲一個數據面的替換方案。

用戶案例

這個咱們的其中一個用戶的案例，當時他們內部的有一個用PHP寫的樓宇管理系統，核心的業務就是管理大樓的一些設備和服務人員。當時他們在內部實踐的時候，以爲這個單體服務其實挺好的，因此想作成一個SaaS服務拿出去賣。

可是單體安裝的整個過程是很是複雜的，全部他們的對服務進行了拆分，拆分以後每一個服務都跑在Mesher之上，經過華爲的註冊中心進行註冊發現，此時就有了彈性伸縮的能力。當有一個新的用戶來的時候，只須要用統一的鏡像去拉新的container就能夠了。這整個從改造到上線的過程，實際上只用了一個月，速度仍是是很是快的。

Mesher技術路線圖

這個是Mesher的技術路線，實際上咱們17年11月份的時候就發佈了國內第一款商用級別的Service Mesh，基於咱們過去的微服務經驗，以及幾年前作的相似Service Mesh的工做。後續咱們又進行了一些迭代，在這一年的迭代中還同時幫助多家企業把Service Mesh帶到生產中。

今年比較大的一個特性是支持了GRPC協議，以及幫助用戶快速的把Mesher帶到本身的k8s環境當中。將來咱們要作的主要是和SQL和開源社區的對接。

以上爲今天的分享內容，謝謝你們！