為什麼要使用服務網格Service Mesh？

banq發表於2018-11-07

為了理解服務網格的必要性，我們將從多個階段來檢視Internet應用程式的簡要歷史。

階段0：巨石單體
記得那些時候？整個程式碼庫打包為一個可執行檔案並已部署。根據用例，這仍然可以更好地工作。
但問題是一些快速增長的公司在擴充套件性，部署，所有權等方面遇到了困難。

第1階段：微服務
想法很簡單，用SLA將monolith分解成多個部分。這種方法運作良好，並被許多公司廣泛採用。
現在，每個團隊都可以大膽地用他們喜歡的語言、框架等來構建他們的微服務。
雖然它解決了第0階段的一些問題，但現在還是存在一些嚴重的問題

  • 為每個微服務配置VM的規範。
  • 使用Chef，OS版本等自動化工具維護系統級依賴性。
  • 監控每項服務。

對於實現生產環境的構建和部署的人來說，這是一場噩夢。並且假設它們共享相同的作業系統但需要隔離，或者出於可移植性原因將它們打包到單獨的VM映象中。為每個服務實現新VM非常昂貴！

階段2：容器化
透過利用Linux中的cgroups和名稱空間，新的作業系統級虛擬化技術透過共享相同的主機作業系統來實現應用程式的隔離環境。Docker是最受歡迎的容器執行時。
因此，為每個微服務建立併發布了一個映象。現在，應用程式被隔離，快速，便宜地啟動新容器，所有這些都可以透過一個作業系統實現！
容器化解決了構建和部署問題。我們還沒有完善的監控解決方案！
我們還有其他問題嗎？
管理容器！
使用容器執行可靠的基礎架構需要注意一些關鍵事項。

  • 容器的可用性
  • 供應容器
  • 向上/向下縮放
  • 負載均衡
  • 服務發現
  • 跨多臺計算機排程容器


階段3：容器編排
Kubernetes是最受歡迎的集裝箱協調器，它徹底改變了我們對基礎設施的看法。
Kubernetes負責健康檢查，可用性，負載平衡，服務發現，可擴充套件性，跨VM的排程容器等。太棒了！
那真是嗎？
不是，請記住，我們尚未解決微服務階段的監控/可觀察性問題。那只是冰山一角。微服務是分散式的管理微服務，但是不是那麼簡單。
我們需要考慮一些最佳實踐來方便地執行微服務。

  • 指標（延遲，成功率等）
  • 分散式跟蹤
  • 客戶端負載平衡
  • 斷路
  • 交通換乘
  • 限速
  • 訪問記錄

像Netflix這樣的公司提出了幾種工具，並經過了微服務執行的實踐考驗。
  • Netflix Spectator（適用於指標）
  • Netflix Ribbon （客戶端LB /服務發現）
  • Netflix Hystrix（斷路器）
  • Netflix Zuul（邊緣路由器）


滿足這些最佳實踐的方法是在每個微服務上使用客戶端庫來解決每個問題。

微服務增加了多個庫！
但服務A是用Java編寫的，其他服務呢？
如果我找不到其他語言的等效庫怎麼辦？
如何讓所有團隊使用/維護/升級庫版本？
我的公司有幾百個服務我應該修改它們以便使用上面的庫嗎？
你現在看到問題了嗎？

自微服務出現以來，這一直是一個問題。

階段4：服務網格

Envoy，Linkerd和Nginx 等多個代理為Mesh提供解決方案。但是這篇文章只關注Envoy Mesh。Envoy是服務代理，設計為管理微服務產生的所有運營問題。
Envoy可以作為邊車與每個應用程式一起執行並抽象網路。當基礎設施中的所有服務流量透過Envoy網格流動時，透過統一的可觀察介面可以很容易地顯示問題區域。
Envoy擁有許多方便的功能

  • 支援HTTP 2，包括gRPC
  • 健康檢查
  • 負載均衡
  • 度量
  • 追蹤
  • 訪問日誌記錄
  • 斷路
  • 重試政策
  • 超時配置
  • 限速
  • Statsd / Prometheus支援
  • 交通流量
  • 使用xDS Server進行動態配置

還有很多！
因此，透過從服務中抽象整個網路並與Envoy形成網格，因為它的資料皮膚允許我們控制上面列出的能力。
 

相關文章