WASMベースの非侵入型フルリンクA / Bテストプラクティス

その他 2021-03-19 01:51:56 訪問数: null

1背景紹介

ServiceMeshは、ServiceMeshで実行されているマイクロサービスに非侵入型のトラフィック管理機能を提供できることは誰もが知っています。VirtualServiceとDestinationRuleを構成することで、マイクロサービスコードを変更することなく、トラフィック管理、タイムアウト再試行、トラフィックレプリケーション、電流制限、ヒューズなどの機能を実現できます。

トラフィック管理の前提は、サービスのバージョンが複数あることです。複数のバージョンを展開する目的に応じて分類できます。記事の残りの部分を理解しやすくするために、簡単な説明を以下に示します。

  • トラフィックルーティング：リクエスト情報（Header / Cookie / Query Params）に従って、リクエストトラフィックは、指定されたサービス（Service）の指定されたバージョン（Deployment）のエンドポイント（Pod []）にルーティングされます。これは、A / Bテスト（A / Bテスト）と呼ばれるものです。
  • トラフィックシフト：グレー/カナリアを介して公開し、指定されたサービス（Service）の各バージョン（Deployment []）のエンドポイント（Pod []）に無差別かつ比例してリクエストトラフィックをルーティングします。
  • トラフィックの切り替え/ミラーリング：青/緑でアナウンスされ、要求された情報に応じてトラフィックの切り替えが比例して実行され、トラフィックの複製が実行されます。

この記事で説明する方法は、リクエストヘッダーに基づいてフルリンクA / Bテストを実装することです。

1.1機能の説明

Istioコミュニティのドキュメントから、リクエストヘッダーに基づいてトラフィックを特定のバージョンのサービスにルーティングする方法に関するドキュメントと例を簡単に見つけることができます。ただし、この例は、リンク全体の最初のサービスでのみ有効になります。

たとえば、リクエストは3つのABCサービスにアクセスする必要があり、3つのサービスすべてにenバージョンとfrバージョンがあります。望みでは：

  • ヘッダー値をuser:en持つリクエスト、フルリンクルートはA1-B1-C1
  • ヘッダー値をuser:fr持つリクエスト、フルリンクルートはA2-B2-C2

対応するVirtualService構成は次のとおりです。

http:
- name: A|B|C-route
  match:
  - headers:
      user:
        exact: en
  route:
  - destination:
      host: A|B|C-svc
      subset: v1
- route:
  - destination:
      host: A|B|C-svc
      subset: v2

実際の測定では、サービスAのルートのみが期待どおりであることがわかります。BとCは、ヘッダー値に基づいて指定されたバージョンにルーティングできません。

どうしてこれなの？サービスグリッド上のマイクロサービスの場合、このヘッダーは薄い空気の外に表示されます。つまり、マイクロサービスコードは認識されません。したがって、AサービスがBサービスを要求すると、このヘッダーは透過的に送信されません。つまり、AがBを要求すると、このヘッダーは失われます。現時点では、ルーティングのヘッダーと一致するVirtualService構成は無意味です。

この問題を解決するために、マイクロサービスパーティのビジネスの観点から、変更できるのはコードのみです（ビジネスが焦点を当てているすべてのヘッダーを列挙し、透過的に送信します）。ただし、これは煩わしい変更であり、新しいヘッダーを柔軟にサポートすることはできません。

サービスグリッドのインフラストラクチャの観点からは、ヘッダーはビジネス上の意味を持たないkvペアであり、透過的に送信する必要があります。これを行うことによってのみ、サービスグリッドはユーザー定義のヘッダーを無差別に透過的に送信できるため、非侵入型のフルリンクA / Bテスト機能をサポートします。

では、どうすればそれを達成できるでしょうか？

1.2コミュニティのステータス

上で説明したように、ヘッダーを透過的に送信できない場合、VirtualServiceのヘッダーマッチングを構成するだけではこの機能を実現できません。

ただし、ヘッダー透過送信を実現できるVirtualServiceの他の構成はありますか？存在する場合、VirtualServiceを使用するコストは最小限に抑えられます。

さまざまな試み（ヘッダー関連の設定/追加の注意深い構成を含む）の後、私は達成することが不可能であることに気づきました。その理由は、ヘッダーへのVirtualServiceの介入はインバウンドフェーズで発生し、透過的な送信はアウトバウンドフェーズでヘッダーに介入する必要があるためです。マイクロサービスワークロードには、薄い空気の外に表示されるヘッダー値を透過的に送信する機能がないため、このヘッダーは次のサービスにルーティングされるときに失われます。

したがって、VirtualServiceを単独で使用して非侵入型のフルリンクA / Bテストを実行することは不可能であり、コミュニティが提供する既存の構成を直接使用してこの機能をサポートすることはできません。

次に、EnvoyFilterのより高度な構成のみが残ります。これは私たちが最初に望んでいなかった結論です。2つの理由があります：

  1. EnvoyFilterの構成は複雑すぎて、一般ユーザーがサービスグリッドですぐに習得して使用することは困難です。例を示しても、要件が少し変更されると、例はEnvoyFilterを変更するための参照値になりません。
  2. EnvoyFilterが使用されている場合でも、Envoyの現在の組み込みフィルターはこの機能を直接サポートしていないため、LuaまたはWebAssembly（WASM）を使用して開発する必要があります。

1.3実装スキーム

次に、テクノロジーの選択を入力します。私は要約するために1つの文を使用します：

  • Luaの利点はそのコンパクトさですが、その欠点はそのパフォーマンスが理想的ではないことです。
  • WASMの利点は優れたパフォーマンスですが、欠点は開発と配布がLuaよりも難しいことです。
  • WASMの主流の実装はC ++とRustであり、他の言語の実装はまだ成熟していないか、パフォーマンスの問題があります。この記事ではRustを使用しています。

Rustを使用してWASMを開発します。アウトバウンドフェーズでは、EnvoyFilterでユーザーが定義したヘッダーを取得し、それを返します。

WASMパッケージの配布では、Kubernetesのconfigmapストレージが使用され、ポッドはWASM構成を取得して、アノテーションの定義を通じてロードします。（この形式の配布を使用する理由については、後で説明します。）

2技術的実現

このセクションで説明されている関連コード：https：
//github.com/AliyunContainerService/rust-wasm-4-envoy/tree/master/propagate-headers-filter

2.1RUSTを使用してWASMを実装する

1依存関係を定義する

WASMプロジェクトのコアは、Rustを使用してWASMを開発するための基本パッケージであるproxy-wasmという1つのクレートのみに依存しています。さらに、逆シリアル化用のパッケージserde_jsonと、ログを印刷するためのパッケージログがあります。Cargo.tomlこれは次のように定義されます。

[dependencies]
proxy-wasm = "0.1.3"
serde_json = "1.0.62"
log = "0.4.14"

2ビルドを定義します

WASMの最終的なビルド形式は、cと互換性のあるダイナミックリンクライブラリであり、Cargo.toml次のように定義されています。

[lib]
name = "propaganda_filter"
path = "src/propagate_headers.rs"
crate-type = ["cdylib"]

3ヘッダー透過送信機能

まず、構造を次のように定義します。これhead_tag_nameは、ユーザー定義のヘッダーキーの名前head_tag_valueと、対応する値の名前です。

struct PropagandaHeaderFilter {
    config: FilterConfig,
}

struct FilterConfig {
    head_tag_name: String,
    head_tag_value: String,
}

{proxy-wasm}/src/traits.rsメソッドはでtrait HttpContext定義されていon_http_request_headersます。このメソッドを実装して、ヘッダー透過送信機能を完了します。

impl HttpContext for PropagandaHeaderFilter {
    fn on_http_request_headers(&mut self, _: usize) -> Action {
        let head_tag_key = self.config.head_tag_name.as_str();
        info!("::::head_tag_key={}", head_tag_key);
        if !head_tag_key.is_empty() {
            self.set_http_request_header(head_tag_key, Some(self.config.head_tag_value.as_str()));
            self.clear_http_route_cache();
        }
        for (name, value) in &self.get_http_request_headers() {
            info!("::::H[{}] -> {}: {}", self.context_id, name, value);
        }
        Action::Continue
    }
}

3〜6行目は、構成ファイルでユーザー定義のヘッダーのキーと値のペアを取得します。存在する場合は、set_http_request_headerメソッドを呼び出して、キーと値のペアを現在のヘッダーに書き込みます。

7行目は、現在のproxy-wasm実装の回避策です。これに興味がある場合は、次のリファレンスを読むことができます。

2.2ローカル認証（Envoyに基づく）

1WASMの構築

次のコマンドを使用して、WASMプロジェクトをビルドします。wasm32-unknown-unknownこのターゲットは現在、にのみ存在するnightlyため、ビルドする前にビルド環境を一時的に切り替える必要があることを強調しておく必要があります。

rustup override set nightly
cargo build --target=wasm32-unknown-unknown --release

ビルドが完了したら、docker composeを使用してEnvoyをローカルで起動し、WASM機能を確認します。

2エンボイ構成

この例では、Envoyの起動用に2つのファイルを提供する必要があります。1つはビルドされたpropaganda_filter.wasmファイルで、もう1つはEnvoy構成ファイルですenvoy-local-wasm.yaml。回路図は次のとおりです。

volumes:
  - ./config/envoy/envoy-local-wasm.yaml:/etc/envoy-local-wasm.yaml
  - ./target/wasm32-unknown-unknown/release/propaganda_filter.wasm:/etc/propaganda_filter.wasm

Envoyは動的構成をサポートし、ローカルテストは静的構成を使用します。

static_resources:
  listeners:
    - address:
        socket_address:
          address: 0.0.0.0
          port_value: 80
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
...
                http_filters:
                  - name: envoy.filters.http.wasm
                    typed_config:
                      "@type": type.googleapis.com/udpa.type.v1.TypedStruct
                      type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
                      value:
                        config:
                          name: "header_filter"
                          root_id: "propaganda_filter"
                          configuration:
                            "@type": "type.googleapis.com/google.protobuf.StringValue"
                            value: |
                              {
                                "head_tag_name": "custom-version",
                                "head_tag_value": "hello1-v1"
                              }
                          vm_config:
                            runtime: "envoy.wasm.runtime.v8"
                            vm_id: "header_filter_vm"
                            code:
                              local:
                                filename: "/etc/propaganda_filter.wasm"
                            allow_precompiled: true
...

エンボイ構成は、次の3つのポイントに焦点を当てています。

  • 15行目でhttp_filters、名前を定義しheader_filterましたtype.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
  • 32行のローカルファイルパスは/etc/propaganda_filter.wasm
  • 20〜26行目のタイプは構成type.googleapis.com/google.protobuf.StringValueに関連しており、値の内容は{"head_tag_name": "custom-version","head_tag_value": "hello1-v1"}です。ここで、カスタムヘッダーキー名はでcustom-versionあり、値はhello1-v1です。

3ローカル検証

次のコマンドを実行して、dockercomposeを開始します。

docker-compose up --build

ローカルサービスをリクエストする：

curl -H "version-tag":"v1" "localhost:18000"

この時点で、Envoyのログには次の出力があります。

proxy_1        | [2021-02-25 06:30:09.217][33][info][wasm] [external/envoy/source/extensions/common/wasm/context.cc:1152] wasm log: ::::create_http_context head_tag_name=custom-version,head_tag_value=hello1-v1
proxy_1        | [2021-02-25 06:30:09.217][33][info][wasm] [external/envoy/source/extensions/common/wasm/context.cc:1152] wasm log: ::::head_tag_key=custom-version
...
proxy_1        | [2021-02-25 06:30:09.217][33][info][wasm] [external/envoy/source/extensions/common/wasm/context.cc:1152] wasm log: ::::H[2] -> custom-version: hello1-v1

2.3WASMを配布する方法

WASMの配布とは、指定されたポッドがプルするために、WASMパッケージを分散ウェアハウスに保存するプロセスを指します。

1 Configmap + Envoyのローカルメソッド

この方法はWASM配布の最終状態ではありませんが、理解しやすく、単純なシナリオに適しているため、この例では、説明する例としてこのソリューションを最終的に選択しました。configmap自体の仕事はWASM向けではありませんが、configmapとEnvoyのローカルモードは成熟しており、2つの組み合わせで現在のニーズを満たすことができます。

Alibaba Cloud Service GridのASM製品は、すでにこれと同様の方法を提供しています。詳細については、Envoy用のWASMフィルターの作成とASMへのデプロイを参照してください 。

WASMパッケージを設定にパックするために、最初に考慮すべきことはパッケージのサイズです。以下に示すように、パケットカットにはwasm-gcを使用します。

ls -hl target/wasm32-unknown-unknown/release/propaganda_filter.wasm
wasm-gc ./target/wasm32-unknown-unknown/release/propaganda_filter.wasm ./target/wasm32-unknown-unknown/release/propaganda-header-filter.wasm
ls -hl target/wasm32-unknown-unknown/release/propaganda-header-filter.wasm

実行結果は以下のとおりです。カット前後のバッグサイズの比較をご覧いただけます。

-rwxr-xr-x  2 han  staff   1.7M Feb 25 15:38 target/wasm32-unknown-unknown/release/propaganda_filter.wasm
-rw-r--r--  1 han  staff   136K Feb 25 15:38 target/wasm32-unknown-unknown/release/propaganda-header-filter.wasm

configmapを作成します。

wasm_image=target/wasm32-unknown-unknown/release/propaganda-header-filter.wasm
kubectl -n $NS create configmap -n $NS propaganda-header --from-file=$wasm_image

指定されたデプロイメントのパッチ：

patch_annotations=$(cat config/annotations/patch-annotations.yaml)
kubectl -n $NS patch deployment "hello$i-deploy-v$j" -p "$patch_annotations"

patch-annotations.yaml次のように：

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/userVolume: '[{"name":"wasmfilters-dir","configMap": {"name":"propaganda-header"}}]'
        sidecar.istio.io/userVolumeMount: '[{"mountPath":"/var/local/lib/wasm-filters","name":"wasmfilters-dir"}]'

2使節のリモートウェイ

Envoyはlocal、remote正式なリソース定義の両方をサポートしています。比較は次のとおりです。

vm_config:
  runtime: "envoy.wasm.runtime.v8"
  vm_id: "header_filter_vm"
  code:
    local:
      filename: "/etc/propaganda_filter.wasm"
vm_config:
  runtime: "envoy.wasm.runtime.v8"
  code:
    remote:
      http_uri:
        uri: "http://*.*.*.216:8000/propaganda_filter.wasm"
        cluster: web_service
        timeout:
          seconds: 60
      sha256: "da2e22*"

remoteこの方法は元のEnovyに最も近いため、この例では元々この方法が最初の選択肢でした。しかし、実際の測定過程で、パッケージのハッシュ検証に問題があることが判明しました。詳細については、以下のリファレンスを参照してください。さらに、EnvoyコミュニティのDaniel Weeklyは私を称賛し、remoteWASM配布をサポートすることはEnvoyの将来の方向性ではないと述べました。したがって、この例は最終的にこのアプローチを放棄しました。

3 ORAS +ローカルメソッド

ORASは、OCI Artifactsプロジェクトのリファレンス実装であり、OCIレジストリ内のコンテンツの保存を大幅に簡素化できます。

ORASクライアントまたはAPI / SDKを使用して、許可されたメディアタイプのWasmモジュールを登録ライブラリ（OCI互換の登録ライブラリ）にプッシュし、コントローラーを介して指定されたワークロードに対応するポッドにWasmフィルターをデプロイします。ローカルモードでマウントします。 。

Alibaba CloudサービスグリッドASM製品は、WebAssembly（WASM）テクノロジーのサポートを提供します。サービスグリッドユーザーは、ASMを介して拡張WASMフィルターをデータプレーンクラスター内の対応するEnvoyプロキシにデプロイできます。ASMFilterDeployment Controllerコンポーネントを介して、プラグインの動的ロードをサポートし、使いやすく、ホットアップデートをサポートできます。具体的には、ASM製品は、新しいCRDASM​​FilterDeploymentおよび関連するコントローラーコンポーネントを提供します。このコントローラーコンポーネントは、ASMFilterDeploymentリソースオブジェクトを監視し、次の2つのことを行います。

  • コントロールプレーンのIstioEnvoyFilterカスタムリソースを作成し、対応するasmコントロールプレーンistiodにプッシュします。
  • 対応するwasmフィルターイメージをOCIレジストリからプルし、対応するワークロードポッドにマウントします

詳細については、以下を参照してください。WasmおよびORASに基づくサービスグリッド機能の簡素化と拡張。

フォローアップの練習共有では、この方法を使用してWASMを配布しますので、ご期待ください。

同様に、業界では他の友人もこのアプローチを進めている、特にhttp://Solo.ioはWASMパッケージ（OCIの画像）を開発・ビルドが配布して展開することができますそれに基づいて、WASM開発フレームワークのwasmeの完全なセットを提供し、GoをしますWebassemblyハブ。このソリューションの利点は明らかであり、開発からオンラインまでのWASMのライフサイクルを完全にサポートします。しかし、このスキームの欠点も非常に明白です。自己完結型のwasmeは、それを分割してソロシステムを超えて拡張することを困難にします。

Alibaba CloudサービスグリッドASMチームは、WasmフィルターのOCI仕様とそれに対応するライフサイクル管理を共同で推進する方法について、ソロを含む関連業界チームと連絡を取り、顧客がEnvoyの機能を簡単に拡張してサービスグリッドに配置できるようにします。新しい高さに押し上げられました。

2.4クラスター検証（Istioに基づく）

1実験例

WASMがKubernetesのconfigmapに配布された後、クラスター検証を実行できます。例（ソースコード）三サービスが含ま：hello1- - hello2：hello3各サービスには2つのバージョンが含まv1/enとv2/をfr。

各サービスはVirtualServiceとDestinationRuleで構成され、一致するヘッダーを定義し、指定されたバージョンにルーティングします。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello2-vs
spec:
  hosts:
    - hello2-svc
  http:
  - name: hello2-v2-route
    match:
    - headers:
        route-v:
          exact: hello2v2
    route:
    - destination:
        host: hello2-svc
        subset: hello2v2
  - route:
    - destination:
        host: hello2-svc
        subset: hello2v1
----
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: hello2-dr
spec:
  host: hello2-svc
  subsets:
    - name: hello2v1
      labels:
        version: v1
    - name: hello2v2
      labels:
        version: v2

Envoyfilterは次のとおりです。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: hello1v2-propaganda-filter
spec:
  workloadSelector:
    labels:
      app: hello1-deploy-v2
      version: v2
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_OUTBOUND
        proxy:
          proxyVersion: "^1\\.8\\.*"
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
              subFilter:
                name: envoy.filters.http.router
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.wasm
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
            value:
              config:
                name: propaganda_filter
                root_id: propaganda_filter_root
                configuration:
                  '@type': type.googleapis.com/google.protobuf.StringValue
                  value: |
                    {
                      "head_tag_name": "route-v",
                      "head_tag_value": "hello2v2"
                    }
                vm_config:
                  runtime: envoy.wasm.runtime.v8
                  vm_id: propaganda_filter_vm
                  code:
                    local:
                      filename: /var/local/lib/wasm-filters/propaganda-header-filter.wasm
                  allow_precompiled: true

2検証方法

ヘッダーを運ぶリクエストcurl -H "version:v1" "http://$ingressGatewayIp:8001/hello/xxx"はistio-ingressgatewayを介して入力され、リンク全体がヘッダー値に従って指定されたバージョンのサービスに入ります。ここで、ヘッダで指定されversionたようにv2、全体のリンクが
ありますhello1 v2- - 。hello2 v2 hello3 v2結果は以下のとおりです。

検証プロセスと結果は次のとおりです。

for i in {1..5}; do
    curl -s -H "route-v:v2" "http://$ingressGatewayIp:$PORT/hello/eric" >>result
    echo >>result
done
check=$(grep -o "Bonjour eric" result | wc -l)
if [[ "$check" -eq "15" ]]; then
    echo "pass"
else
    echo "fail"
    exit 1
fi

結果：

Bonjour eric@hello1:172.17.68.205<Bonjour eric@hello2:172.17.68.206<Bonjour eric@hello3:172.17.68.182
Bonjour eric@hello1:172.17.68.205<Bonjour eric@hello2:172.17.68.206<Bonjour eric@hello3:172.17.68.182
Bonjour eric@hello1:172.17.68.205<Bonjour eric@hello2:172.17.68.206<Bonjour eric@hello3:172.17.68.182
Bonjour eric@hello1:172.17.68.205<Bonjour eric@hello2:172.17.68.206<Bonjour eric@hello3:172.17.68.182
Bonjour eric@hello1:172.17.68.205<Bonjour eric@hello2:172.17.68.206<Bonjour eric@hello3:172.17.68.182

出力情報Bonjour ericは各サービスのfrバージョンからのものであり、機能検証に合格したことを示しています。

3パフォーマンス分析

EnvoyFilter + WASMを追加した後、機能検証に合格しますが、どのくらいの遅延が発生しますか？これは、サービスグリッドのプロバイダーとユーザーの両方が非常に懸念している問題です。このセクションでは、次の2つの懸念事項を確認します。

  • EnvoyFilter + WASM後の増分遅延オーバーヘッドを増やす
  • WASMバージョンとLuaバージョンのコスト比較

3.1Luaの実装

Luaの実装は、個別のプロジェクトなしでEnvoyFilterに直接書き込むことができます。例は次のとおりです。

patch:
  operation: INSERT_BEFORE
  value:
    name: envoy.lua
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
      inlineCode: |
        function envoy_on_request(handle)
          handle:logInfo("[propagate header] route-v:hello3v2")
          handle:headers():add("route-v", "hello3v2")
        end

3.2圧力測定方法

1つの展開

  • 同じDeployment / Service / VirtualService / DestinationRuleをそれぞれ3つの名前空間にデプロイします
  • でhello-abtest-luaLuaのでEnvoyFilterを展開
  • でhello-abtest-wasmEnvoyFilterでWASMを展開
hello-abtest        基准环境
hello-abtest-lua    增加EnvoyFilter+LUA的环境
hello-abtest-wasm   增加EnvoyFilter+WASM的环境

2つのツール

この例では、圧力測定ツールとしてheyを使用しています。ちょっとの前身はブームで、ab（ApacheBench）の代わりに使用されます。同じ圧力テストパラメータを使用して、3つの環境をそれぞれ圧力テストします。回路図は次のとおりです。

# 并发work数量
export NUM=2000
# 每秒请求数量
export QPS=2000
# 压测执行时常
export Duration=10s

hey -c $NUM -q $QPS -z $Duration -H "route-v:v2" http://$ingressGatewayIp:$PORT/hello/eric > $SIDECAR_WASM_RESULT

ちょっと圧力テストの結果ファイルに注意してくださいsocket: too many open files。結果を最後に表示することはできません。そうしないと、結果に影響します。ulimit -n $MAX_OPENFILE_NUMコマンドを使用して圧力テストパラメータを設定および調整して、結果の精度を確保できます。

3.3レポート

次の図に示すように、3つの結果レポートから4つの主要な指標を選択します。

3.4結論

  1. ベンチマークバージョンと比較して、EnvoyFilterの2つのバージョンを追加すると、平均遅延は数十から数百ミリ秒長くなり、時間のかかる比率の増加は次のようになります。
  • wasm  1.2％(0.6395-0.6317)/0.6317および1％(1.3290-1.2078)/1.2078
  • lua  11％(0.7012-0.6317)/0.6317および20％(1.4593-1.2078)/1.2078
  1. WASMバージョンのパフォーマンスはLUAバージョンよりも大幅に優れています
注：LUAバージョンと比較すると、WASM実装は複数の構成を持つコードのセットです。したがって、WASMの実行プロセスには、LUAよりも構成変数を取得するプロセスが1つ多くあります。

4展望

4.1使用方法

この記事では、技術的な実装の観点から、非侵入型のフルリンクA / Bテストの要件をサポートするために、ユーザー定義のヘッダーを透過的に送信するWASMを実装および検証する方法について説明します。

ただし、サービスグリッドのユーザーとして、この記事に従って段階的に実装するのは非常に面倒でエラーが発生しやすくなります。

Alibaba Cloud Service GridのASMチームは、ASMプラグインカタログメカニズムを開始します。ユーザーは、プラグインカタログでプラグインを選択するだけで、プラグのカスタムヘッダーなどの非常に少数のkv構成を提供できます。 -inを使用して、関連する構成を自動的に生成およびデプロイします。EnvoyFilter+ WASM + VirtualService + DestinationRule。

4.2拡張する方法

この例は、ヘッダーに基づくマッチングルーティング関数のみを示しています。クエリパラメータに基づいてマッチングおよびルーティングする場合、どのように拡張できますか？

これはASMプラグインカタログが細心の注意を払っているトピックであり、最終的なプラグインカタログはベストプラクティスを提供します。

上記。

元のリンク

この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。

おすすめ

転載: blog.csdn.net/weixin_43970890/article/details/114918764
おすすめ
ランキング
ワンポイントほぼ3正確なサイズの見積もり46128582
jqueryのIMGタグを削除
Brain-like sensors: Dynamic Vision Sensor and Dynamic Audio Sensor
フラグメントのAndroidドットスライドスイッチページは以下に示すと
C# 抽象クラス (抽象)
論文研究：堅牢なPDFマルウェア分類子のトレーニングについて
入力タグ付きのファイルをアップロードします（1つの記事を実行できます）
フラッター（9） - 引き出しスライドメニューとパッケージ管理
キーボードフック取得で
話し言葉412毎日20の英単語
アーカイブ
もっと
2024-07-30(0)
2024-07-29(0)
2024-07-28(0)
2024-07-27(0)
2024-07-26(0)
2024-07-25(0)
2024-07-24(0)
2024-07-23(0)
2024-07-22(0)
2024-07-21(0)

コードワールド

© 2018 codetd.com