ServiceMesh入門的起點：構建一個微服務網關

摘要：如果你想在組織內使用落地服務網格，那麼採用基於 Envoy 作爲微服務網關是非常好的一個開始。所以大家如何想在內部測試落地服務網格，不妨嘗試從 Envoy 的微服務網關開始。

本文是在看了國外 Solo 公司 CTO 的博客之後整理的，本來是想按原文翻譯，但是考慮到我自己在公司實踐的思路，還是想把他的思路和我自己的思路做一些結合。所以本文中有部分內容是來自這位高手的思考，也有有我在公司實踐中的思考。

作者是從 Red Hat 跳到 Solo 公司的，這家公司現在主要產品就是基於 Envoy 和 Istio 的網絡治理工具的研發，包括了微服務網關和服務網格上的產品。

他也是很早之前就在思考服務網格雖然很好（至少是思路和理念非常好），而且現在結合 K8S 也有了很好的實現和落地方式。但是人們對這個東西的認知和信心還是不足的，我看到的主要表現在這樣一些方面：

Istio 等相關服務網格的產品還不夠成熟，目前我重點關注 Istio 社區，也是社區 Member。目前看來 Istio 的代碼都還在大幅度的變化，很多設計在不同的大版本中是不斷調整的，這一點就不多說了。剛好這幾天也發佈了 1.6，不過我感覺 1.6 應該會好很多。
大家直觀的感覺是加了 sidecar 之後，網絡調用多了一跳，性能會變差，甚至變得很差。
大家對把服務網格作爲基礎設施這種想法還是比較抗拒，認爲妨礙了他定位問題和提升應用性能。
大家對於微服務框架開發的熱情超過服務網格，很多人認爲服務網格是一種微服務架構實現，所以自然的把微服務框架作爲了服務網格的競爭對手。對於開發同學來說開發微服務框架的成就感要不直接使用服務網格這樣的基礎設施強很多。

以上這幾個點就不展開講了，大家應該能理解我的意思。這也是我這幾年研究和落地服務網格中的一些難點，我認爲這些難點隨着時間的發展將不會成爲問題，尤其我認爲服務網格未來一定會作爲操作系統一樣的基礎設施爲大家提供服務。

但是在目前這個階段我們應該怎麼辦呢？技術不成熟，大家不太接受。我將奈何？

Solo CTO 的文章讓我更堅定了我們目前的思路和做法。下面幾點是他總結的，如何在公司中逐步落地服務網格的方法。

這一次，我開發了這種方法，以便在生產環境中很好的採用服務網格：

深入瞭解最終的服務網格數據面技術。
採用小部分流量使用數據面理想的情況下，首先共享服務網關。
選擇一部分應用，啓用邊車模式的網絡。
慢慢啓用服務網格中最有價值的功能。
重複第 2 步到第 4 步。

目前我們基本也是這個思路，重點在使用 Envoy 作爲微服務網關，開發集成了公司內部的相關基礎組件和業務組件，作爲我們微服務平臺的核心組件。並且在使用中也是按照多集羣部署服務網關，然後在一些可控業務上嘗試啓用服務網格能力。這個能力我們做成了 web 頁面一個按鈕就可以啓用，在實現上其實就是注入一段代碼在業務 pod 中自動注入 istio-proxy。再配合頁面化的配置管理來控制策略實施，或通過頁面進行服務狀態信息可視化等。

再來介紹一下什麼是 Envoy Proxy

Envoy 已經變成大多數服務網格技術中基礎的數據面了。像 Istio，Consul Connect，AWS App Mesh，Grey Matter（和其它已經存在的 API 管理提供商也在逐步採用）都是基於 Envoy 的。

也許大家認爲作爲一個協議代理或者服務網關在技術實現上沒有什麼難度，但是作爲通用的服務代理組件，在實際實現中卻是絕對沒有大家想的那樣簡單。要有可以用戶自己來擴展的機制，遙測信息收集和監控實現，要可以有靜態和動態的配置的方式，對可配置內容的設計抽象，兼顧性能問題等等。如果可以建議大家在實際環境中來真正安裝部署運行測試體驗一下。

總體來說 Envoy 目前是一個非常功能強大，支持多種使用方式和實現複雜的技術組件。在服務網關，服務網格技術中目前是最佳的選擇。

從基於 Envoy 構建一個服務網關開始

如果你想在組織內使用落地服務網格，那麼採用基於 Envoy 作爲微服務網關是非常好的一個開始。作者在他之前寫的一本書《Istio in Action》中就極力介紹 Istio 的服務網關資源。因爲把 Envoy 作爲入口網關是使用 Istio 的最好的開始方式，這樣你在不斷熟悉 Isito 和推廣服務網格文化，讓內部逐步接受，並且探索服務網格的最佳使用方式是非常好的，不用一上來就推動大家都必須啓用邊車。

使用基於 Envoy 的服務網關這意味着你不但可以解決你微服務網關的問題，而且還可以逐步實踐小型化的服務網格。當你部署了服務網關之後，你就可以強有力的掌控流量和路由了（包括百分比的路由，基於協議頭或者方法的路由，還有流量鏡像），還有加密傳輸等。

簡單的網關也是有的，在一般情況下使用也是沒有問題的，作爲網關最大的作用就是管控入口流量。但是通用且強大的網關就可以有很多的用處，所以基於 Envoy 來構建微服務網關是一個非常好的選擇。Envoy 的功能可以說是相當的豐富。

基於 Envoy 構建更好的服務網關

在一般情況下，集羣外的服務來訪問集羣的內的服務，我們都遵循不可信原則，主要原因是安全問題。所以一般要對外提供服務，我們就要解決下面一些問題：

緩存
限頻限流
客戶認證
消息簽名
jwt 驗證（包括和現有的 JWT 系統和認證管理系統集成）
web 應用防火牆
消息轉換
API 的編排等

另外還有一堆其它的功能，比如外部鑑權，內容改寫等等。

Gloo 的做法是基於 Envoy 構建了一個強大的微服務網關，而且基於 xDS 配備了一個好用的控制管理端。使得這個微服務網關既可以作爲微服務網關，也可以繼續深入作爲邊車使用。而在他們的設計單中，首先是可以作爲一個強大的微服務網關來使用。而且他們可以直接和 Istio，Consul， AWS App Mesh 和 Linkerd 等集成。目前他們說已經在很多客戶那裏落地了。

在我們的實踐單中也是這樣一個思路，早期我們使用 OpenResty 來構建我們的微服務網關，插件都是使用 lua 來編寫，直到我們 2 年前遇到了 Envoy 和 Isito，我們綜合對比考慮之後，採用了 Envoy 最爲我們的微服務網關，我們也是和 Consul 結合，利用其 xDS 開發了我們公司內的諸多業務插件，配合使用。目前已經作爲微服務網關在內部大量使用。同時也在逐步積累開發一個基於 Envoy 和 Istio 的控制系統。目標是既可以控制微服務網關，也可以控制服務網格，統一的把集羣內以及多個集羣的網絡流量管理做一個統一。