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

內容來源：2018 年 6 月 27 日，華為微服務架構師田曉亮在“LC3微服務Workshop | 深入解讀ServiceComb”進行《ServiceComb的ServiceMesh思考及在華為雲的實踐》的演講分享。IT 大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

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

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

摘要

實際上我們在做微服務的時候，整個演進的過程中要解決很多微服務架構帶來的複雜的問題。我個人曾實現過一個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的最佳實踐。

後來我們用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物件。而真實在網路間進行傳輸的還是協議的以及和協議相相容的資料包。

這是我們後來推進的Service Center的架構演進，首先我們抽象了一個Adaptor層去適配不同的註冊發現，怎麼做實際上是由於資料中心會越來越大，並且我們認為任何一種雲其實它都都是不可靠的。所以後來我們搭建了自己的私有云的中心，然後做了混合雲，推進Service Centere架構演進也是希望它能夠支援多雲。除了這個價值之外，它還可以支援異構，比如把VM和K8S進行混編，能夠讓你在一個地方看到所有的資料中心以及所有異構設施中的微服務。

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

我們的另一個策略是在開源方面擁抱Istio生態，和別的地方不同的，我們會把go chassis開發框架接入到Istio當中，這樣做的一個好處就是可以提升服務的整體效能。因為實際上Service Mesh的方案，由於是一個服務代理，所以說所有的請求資料都會有一個從使用者到核心，再從核心到使用者的過程，整個過程都是要乘二的，所以效能其實是會有降低，一些對效能很敏感的使用者，可能會傾向於使用侵入框架。而Istio正好提供Service Mesh方案，所以我們把go chassis帶入到Istio中，同時把Mixer也帶進去，成為一個資料面的替換方案。

這個我們的其中一個使用者的案例，當時他們內部的有一個用PHP寫的樓宇管理系統，核心的業務就是管理大樓的一些裝置和服務人員。當時他們在內部實踐的時候，覺得這個單體服務其實挺好的，所以想做成一個SaaS服務拿出去賣。

但是單體安裝的整個過程是非常複雜的，所有他們的對服務進行了拆分，拆分之後每個服務都跑在Mesher之上，通過華為的註冊中心進行註冊發現，此時就有了彈性伸縮的能力。當有一個新的使用者來的時候，只需要用統一的映象去拉新的container就可以了。這整個從改造到上線的過程，實際上只用了一個月，速度還是是非常快的。

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

今年比較大的一個特性是支援了GRPC協議，以及幫助使用者快速的把Mesher帶到自己的k8s環境當中。未來我們要做的主要是和SQL和開源社群的對接。

以上為今天的分享內容，謝謝大家！