為什麼要使用 Service Mesh?

ServiceMesher2018-11-24 21:37:13

作者:shiva 譯者:詹葉 原文:https://medium.com/@tak2siva/why-is-service-mesh-8ebcd6ed9eb5

除非你長期與世隔絕,否則你應該聽說過Kubernetes,他已經稱為高速發展的互聯網公司的一條準則。最近又有一個熱門話題--Service Mesh(),它已經被這些高速發展公司用來解決一些特定的問題。所以如果你想了解什麼是Service Mesh,接下來我可以給你一個更好的解釋。

互聯網應用的演進

為了理解Sevice Mesh的重要性,我們通過四個階段來簡短的回顧下互聯網應用的發展歷程。

階段0:單體應用

還記得那些年嗎?所有的代碼庫都打包成一個可執行和部署的軟件包。當然,至今在某些使用場景下這個方式依然是很管用的。但是對於一些業務快速增長的互聯網公司,在應用的可擴展性、快速部署和所有權等方面遇到了阻力。

階段1:

微服務的思思想很簡單,依照SLA(服務等級協議)將單體應用拆分成多個模塊。這種方式運行效果顯著,所以廣泛為企業所接受。現在,每個團隊都用他們喜愛的語言、框架等自由地設計他們的微服務。然後它開始看起來就像下面這樣。

我們曾經在我的一個項目中開玩笑說,那裡有各種語言的微服務:)

儘管微服務解決了單體應用的一些問題,但現在公司有一些嚴重問題。

  • 為每個微服務定義VM(虛擬機)規範

  • 維護系統級別依賴操作系統版本、自動化工具(如chef)等

  • 監控每個服務

對負責構建和部署的人來說這就是一個噩夢。

而且這些服務在虛擬機中共享同一個OS,但為了達到可移植性,服務之間需要隔離或者被封裝到獨立的VM鏡像。微服務典型的架構設計如下圖所示:

但為每個服務/副本安裝在一臺獨立的虛擬機上,花費是非常高的。

階段2:

容器是利用Linux中的 cgroups 和 namespace 的一種新的操作系統級別的虛擬化技術,通過共享主機的操作系統,實現為不同的應用隔離運行環境的。Docker是目前最流行的容器運行時。

所以我們會為每個微服務創建一個容器鏡像並以容器形式發佈成服務。這樣不僅可以在一個操作系統上實現應用運行環境的隔離,而且啟動新的容器相比於啟動新的VM速度更快、成本也更低!使用容器技術之後的微服務設計看起來就像這樣。容器化解決了構建和部署的問題,但還沒有完美的監控解決方案!那要怎麼辦?我們還有其他問題嗎?管理容器!

使用容器運行一個可靠的基礎設施層需要注意以下幾個重要的點:

  • 容器的可用性

  • 生成容器

  • 擴容/縮容

  • 負載均衡

  • 服務發現

  • 調度容器到多個主機

階段3:容器編排

Kubernetes是當下最流行的容器編排工具,它徹底改變了我們對基礎設施的看法。Kubernetes側重於健康檢查,可用性,負載均衡,服務發現,擴展性,跨主機調度容器等等,很神奇!

我們要的就是這樣嗎?

並不完全是,僅僅這樣還不能解決在微服務階段提到的服務監控/觀測的問題。這只是冰山一角。微服務是分佈式的,所以管理微服務不是件容易的事。

我們需要考慮一些最佳實踐來便捷地運行微服務。

  • Metrics(延遲,成功率等)

  • 分佈式鏈路追蹤

  • 客戶端負載均衡

  • 熔斷

  • 流量遷移

  • 限速

  • 訪問日誌

像Netflix這樣的公司已經推出了幾種工具,並接受了那些運行微服務的做法。

  • Netflix Spectator(Metrics)

  • Netflix Ribbon(客戶端負載均衡/服務發現)

  • Netflix Hystrix(熔斷器)

  • Netflix Zuul(邊界路由)

現在,為了滿足這些最佳實踐的唯一方法是在每個微服務上使用一個客戶端庫來解決每個問題。所以每個服務的結構看起來就像這樣。但這是針對像Service A這樣的用JAVA寫的服務,那其他的服務要怎麼辦? 如果我使用其他語言沒有類似java的庫要怎麼辦? 怎樣才能讓所有團隊使用/維護/升級庫版本? 我們公司有上百個服務,我要修改所有應用都使用上面的庫嗎?

發現了嗎?自微服務誕生以來,這些一直都是個問題(語言限制、應用代碼改造)。

階段4:服務網格

目前有多種代理為Service Mesh提供解決方案,如:Envoy、Linkerd和Nginx。本文只關注Envoy的Service Mesh。

Envoy是針對微服務產生的這些問題設計出來的服務代理。

Envoy能夠作為 SideCar 運行在每個應用的旁邊,形成抽象的應用網絡。當基礎設施中的所有服務流量通過Envoy網格流動時,通過一致的可觀察性來問題區域變得容易。

如下圖所示,當把Envoy作為SideCar添加到服務後,所有微服務的入站和出站流量都通過各自的Envoy代理

Envoy擁有許多方便的功能

  • 支持HTTP,HTTP/2和gRPC

  • 健康檢查

  • 負載均衡

  • Metrics

  • 追蹤

  • 訪問日誌

  • 熔斷

  • 重試策略

  • 超時配置

  • 限速

  • 支持Statsd、Prometheus

  • 流量遷移

  • 通過發現服務來動態調整配置(XDS) 等……

所以通過從服務中抽象出整個網絡,使用Envoy作為SideCar形成網格組成數據平面,允許我們控制上面列出的能力。

歡迎反饋,謝謝!

相關閱讀推

Istio

IBM Istio

  • 11月1日 Istio初探(已結束,由孫琳分享)

  • 11月8日 Istio上手

  • 11月15日 Istio的安全管理

  • 11月22日 Envoy

  • 11月29日 使用Istio來監控和可視化微服務

  • 12月6日 Istio mixer - 基本概念,策略、遙測與擴展

  • 12月13日 Istio跨雲管理方案解析

  • 12月20日 Istio使用案例:Serverless 平臺knative

  • 詳情請參考:IBM微講堂之年度大戲《Istio系列》

點擊【閱讀原文】跳轉到ServiceMesher網站上瀏覽可以查看文中的鏈接。

  • SOFAMesh(https://github.com/alipay/sofa-mesh)基於Istio的大規模服務網格解決方案

  • SOFAMosn(https://github.com/alipay/sofa-mosn)使用Go語言開發的高性能Sidecar代理

合作社區

參與社區

以下是參與ServiceMesher社區的方式,最簡單的方式是聯繫我!

  • 加入微信交流群:關注本微信公眾號後訪問主頁右下角有獲取聯繫方式按鈕,添加好友時請註明姓名-公司

  • 社區網址:http://www.servicemesher.com

  • Slack:https://servicemesher.slack.com (需要邀請才能加入)

  • GitHub:https://github.com/servicemesher

  • Istio中文文檔進度追蹤:https://github.com/servicemesher/istio-official-translation

  • Twitter: https://twitter.com/servicemesher

  • 提供文章線索與投稿:https://github.com/servicemesher/trans


閱讀原文

TAGS: