爲了理解服務網格的必要性，我們將從多個階段來查看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形成網格，因爲它的數據面板允許我們控制上面列出的能力。