出處:https://zhuanlan.zhihu.com/p/330779168

如果你正在尋找在 Mixer 方案以外觀察服務網格的更優解，本文正符合你的需要。

Apache Skywalking ︰特別為微服務、雲原生和容器化（Docker、Kubernetes、Mesos）架構而設計的 APM（應用效能監控）系統。

Envoy 訪問日誌服務 ︰訪問日誌服務（ALS）是 Envoy 的擴充套件元件，會將所有透過 Envoy 的請求的詳細訪問日誌傳送出來。

背景

Apache SkyWalking 一直透過 Istio Mixer 的介面卡，支援服務網格的可觀察性。不過自從 v1.5 版本，由於 Mixer 在大型叢集中差強人意的表現，Istio 開始棄用 Mixer。Mixer 的功能現已遷至 Envoy 代理，並獲 Istio 1.7 版本支援。

在去年的中國KubeCon 中， 吳晟 和 周禮贊 基於 Apache SkyWalking 和 Envoy ALS，釋出了改良方案：既減低了 Mixer 帶來的效能影響，也同時保持服務網格中同等的可觀察性。這個方案最初是由吳晟、 高洪濤 、周禮贊和 Dhi Aurrahman 在 Tetrate.io 實現的。

如果你正在尋找在 Mixer 方案之外，為你的服務網格進行觀察的最優解，本文正是你當前所需的。在這個教程中，我們會解釋此方案的運作邏輯，並將它實踐到 bookinfo 應用上。

運作邏輯

從可觀察性的角度來說，Envoy 一般有兩種部署模式︰Sidecar 和路由模式。 Envoy 代理可以代表多項服務（見下圖之 1），或者當它作為 Sidecar 時，一般是代表接收和傳送請求的單項服務（下圖之 2 和 3）。

在兩種模式中，ALS 發放的日誌都會帶有一個節點標記符。該標記符在路由模式時，以 router~ （或 ingress~）開頭頭，而在 Sidecar 代理模式時，則以 sidecar~ 開頭頭。

除了節點標記符之外，這個方案［1］所採用的訪問日誌也有幾個值得一提的欄位︰

downstream_direct_remote_address ︰此欄位是下游的 直接遠端地址 ，用作接收來自使用者的請求。 注意 ︰它永遠是對端實體的地址，即使遠端地址是從 x-forwarded-for header 、代理協議等推斷出來的。

downstream_remote_address ︰遠端或原始地址，用作接收來自使用者的請求。

downstream_local_address ︰本地或目標地址，用作接收來自使用者的請求。

upstream_remote_address ︰上游的遠端或目標地址，用作處理本次交換。

upstream_local_address ︰上游的本地或原始地址，用作處理本次交換。

upstream_cluster ︰ upstream_remote_address 所屬的上游叢集。

我們會在下面詳細講解各個欄位。

Sidecar

當 Envoy 作為 Sidecar 的時候，會搭配服務一起部署，並代理來往服務的傳入或傳出請求。

代理傳入請求 ︰在此情況下，Envoy 會作為伺服器端的 Sidecar，以 inbound|portNumber|portName|Hostname[or]SidecarScopeID 格式設定 upstream_cluster 。

SkyWalking 分析器會檢查 downstream_remote_address 是否能夠找到對應的 Kubernetes 服務。

如果在此 IP（和埠）中有一個服務（例如服務 B）正在執行，那我們就會建立起服務對服務 的關係（即服務 B → 服務 A），幫助建立拓撲。再配合訪問日誌中的 start_time 和 duration 兩個欄位，我們就可以獲得延遲的指標資料了。

如果沒有任何服務可以和 downstream_remote_address 相對應，那請求就有可能來自網格以外的服務。由於 SkyWalking 無法識別請求的服務來源，在沒有源服務的情況下，它簡單地根據拓撲分析方法生成資料。拓撲依然可以準確地建立，而從伺服器端偵測出來的指標資料也依然是正確的。

代理傳出請求 ︰在此情況下，Envoy 會作為客戶端的 Sidecar，以 outbound|<port>|<subset>|<serviceFQDN> 格式設定 upstream_cluster 。

客戶端的偵測相對來說比代理傳入請求容易。如果 upstream_remote_address 是另一個 Sidecar 或代理的話，我們只需要獲得它相應的服務名稱，便可生成拓撲和指標資料。否則，我們沒有辦法理解它，只能把它當作 UNKNOWN 服務。

代理角色

當 Envoy 被部署為前端代理時，它是獨立的服務，並不會像 Sidecar 一樣，代表任何其他的服務。所以，我們可以建立客戶端以及伺服器端的指標資料。

演示範例

在本章，我們會使用典型的 bookinfo 應用，來演示 Apache SkyWalking 8.3.0+ （截至 2020 年 11 月 30 日的最新版本）如何與 Envoy ALS 合作，聯手觀察服務網格。

安裝 Kubernetes

在 Kubernetes 和虛擬機器器（VM）的環境下，SkyWalking 8.3.0 均支援 Envoy ALS 的方案。在本教程中，我們只會演示在 Kubernetes 的情境，至於 VM 方案，請耐心期待我們下一篇文章。所以在進行下一步之前，我們需要先安裝 Kubernetes。

在本教程中，我們會使用Minikube 工具來快速設立本地的 Kubernetes（v1.17 版本）叢集用作測試。要執行所有必要元件，包括 bookinfo 應用、SkyWalking OAP 和 WebUI，叢集需要動用至少 4GB 記憶體和 2 個 CPU 的核心。

安裝 Istio

Istio 為配置 Envoy 代理和實現訪問日誌服務提供了一個非常方便的方案。內建的配置設定檔為我們省去了不少手動的操作。所以，考慮到演示的目的，我們會在本教程全程使用 Istio。

啟動訪問日誌服務

演示的設定檔沒有預設啟動 ALS，我們需要重新配置才能夠啟動 ALS。

istioctl  manifest install \        --set meshConfig.enableEnvoyAccessLogService=true \        --set meshConfig.defaultConfig.envoyAccessLogService.address=skywalking-oap.istio-system:11800

範例指令 --set meshConfig.enableEnvoyAccessLogService=true 會在網格中啟動訪問日誌服務。正如之前提到，ALS 本質上是一個會發放請求日誌的 gRPC 服務。配置 meshConfig.defaultConfig.envoyAccessLogService.address=skywalking-oap.istio-system:11800 會告訴這個gRPC 服務往哪裡傳送日誌，這裡是往 skywalking-oap.istio-system:11800 傳送，稍後我們會部署 SkyWalking ALS 接收器到這個地址。

注意 ︰

你也可以在安裝 Istio 時啟動 ALS，那就不需要在安裝後重新啟動 Istio︰

istioctl install --set profile=demo \               --set meshConfig.enableEnvoyAccessLogService=true \               --set meshConfig.defaultConfig.envoyAccessLogService.address=skywalking-oap.istio-system:11800kubectl label namespace default istio-injection=enabled

部署 Apache SkyWalking

SkyWalking 社群提供了 Helm Chart ，讓你更輕易地在 Kubernetes 中部署 SkyWalking 以及其依賴服務。 Helm Chart 可以在 GitHub 倉庫 找到。

# Install Helmcurl -sSLO https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gzsudo tar xz -C /usr/local/bin --strip-components=1 linux-amd64/helm -f helm-v3.0.0-linux-amd64.tar.gz# Clone SkyWalking Helm Chartgit clone https://github.com/apache/skywalking-kubernetescd skywalking-kubernetes/chartgit reset --hard dd749f25913830c47a97430618cefc4167612e75# Update dependencieshelm dep up skywalking# Deploy SkyWalkinghelm -n istio-system install skywalking skywalking \        --set oap.storageType='h2'\        --set ui.image.tag=8.3.0 \        --set oap.image.tag=8.3.0-es7 \        --set oap.replicas=1 \        --set oap.env.SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS=k8s-mesh \        --set oap.env.JAVA_OPTS='-Dmode=' \        --set oap.envoy.als.enabled=true \        --set elasticsearch.enabled=false

我們在 istio-system 的名稱空間內部署 SkyWalking，使 SkyWalking OAP 服務可以使用地址 skywalking-oap.istio-system:11800 訪問，在上一步中，我們曾告訴過 ALS 應往此處發放它們的日誌。

我們也在 SkyWalking OAP 中啟動 ALS 分析器︰ oap.env.SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS=k8s-mesh 。分析器會對訪問日誌進行分析，並解析日誌中的 IP 地址和 Kubernetes 中的真實服務名稱，以建立拓撲。

為了從 Kubernetes 叢集處獲取元資料（例如 Pod IP 和服務名稱），以識別相應的 IP 地址，我們還會設定 oap.envoy.als.enabled=true ，用來申請一個對元資料有訪問權的 ClusterRole 。

export POD_NAME=$(kubectl get pods -A -l "app=skywalking,release=skywalking,component=ui" -o name)echo $POD_NAMEkubectl -n istio-system port-forward $POD_NAME 8080:8080

現在到你的瀏覽器上訪問 http://localhost:8080 。你應該會看到 SkyWalking 的 Dashboard。 Dashboard 現在應該是空的，但稍後部署應用和生成流量後，它就會被填滿。

部署 Bookinfo 應用

執行︰

export ISTIO_VERSION=1.7.1kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_VERSION/samples/bookinfo/platform/kube/bookinfo.yamlkubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_VERSION/samples/bookinfo/networking/bookinfo-gateway.yamlkubectl wait --for=condition=Ready pods --all --timeout=1200sminikube tunnel

現在到你的瀏覽器上進入 http:// localhost/productpage 。你應該會看到典型的 bookinfo 應用畫面。重新整理該頁面幾次，以生成足夠的訪問日誌。

完成了！

這樣做，你就成功完成設定了！再檢視 SkyWalking 的 WebUI，你應該會看到 bookinfo 應用的拓撲，以及它每一個單獨服務的指標資料。

疑難解答

kubectl get pods -Akubectl -n istio-system logs -f $(kubectl get pod -A -l "app=skywalking,release=skywalking,component=oap" -o name)kubectl -n istio-system logs -f $(kubectl get pod -A -l "app=skywalking,release=skywalking,component=ui" -o name)UTC +0

自定義伺服器名稱

SkyWalking 社群在 ALS 方案的 8.3.0 版本中，作出了許多改善。你現在可以在對映 IP 地址時，決定如何用 service 和 pod 變數去自定義伺服器的名稱。例如，將 K8S_SERVICE_NAME_RULE 設定為 ${service.metadata.name}-${pod.metadata.labels.version} ，就可以使服務名稱帶上版本的標籤，類似 reviews-v1 、 reviews-v2 和 reviews- v3 ，而不再是單個服務 review ［2］。

在 VM 上使用 ALS

Kubernetes 很受歡迎，可是 VM 呢？正如我們之前所說，為了替 IP 找到對應的服務，SkyWalking 需要對 Kubernetes 叢集有訪問權，以獲得服務的元資料和 Pod 的 IP。可是在 VM 環境中，我們並沒有來源去收集這些元資料。

在下一篇文章，我們會介紹另外一個 ALS 分析器，它是建立於 Envoy 的元資料交換機制。有了這個分析器，你就可以在 VM 環境中觀察服務網格了。萬勿錯過！

如果你希望在 ALS 方案或是混合式網格可觀察性上獲得商業支援，TSB 會是一個好選項。

Additional Resources 額外資源

KubeCon 2019 的錄影影片。在官方網站上獲得更多有關 SkyWalking 的最新訊息吧。在我們 Tetrate 的部落格上閱讀更多有關 SkyWalking 的資訊吧。訂閱Tetrate 收聽更多有關 SkyWalking 和可觀察性的電子報。

如有任何問題或反饋，傳送郵件至 [email protected]。

Apache SkyWalking 創始人吳晟和 SkyWalking 的核心貢獻者柯振旭都是 Tetrate 的工程師。 Tetrate 的內容創造者編輯與貢獻於本文章。 Tetrate 幫助企業採用開源服務網格工具，包括 Istio、Envoy 和 Apache SkyWalking，讓它們輕鬆管理微服務，在任何架構上執行服務網格，以至現代化他們的應用。

出處:https://zhuanlan.zhihu.com/p/330779168