API統合登録モジュール

その他 2024-05-16 10:34:36 訪問数: null

NGINX はクラウドネイティブに進化し、すべて OpenNJetで実現 

1.需要

コントロール プレーンの構成 動的モジュールの増加に伴い、各動的モジュール (宣言型 API は /config を使用) が元々提供していた場所の構成方法が増え、構成項目が増加するため、それぞれが制御する統一された API モジュールの入り口を提供する必要があります。動的モジュール。モジュールは API モジュールに登録し、実行時に登録されたハンドラーを呼び出して実際の関数リクエストに応じた処理を行います。

2. 既存の動的 API モジュール

2.1 既存の API 別モジュール

njet-config-api-module
njet-http-sendmsg-module
njet-http-cache-quick-module
njet-health-check-helper
njet-http-dyn-server-api-module
njet-http-location-api-module
njet-http-range-api-module
njet-http-ssl-api-module
njet-http-upstream-api-module

2.2 既存の動的モジュール構成 (宣言型 API と命令型 API):

server {
        listen       8081;
        
         //声明式api入口
        location /config {
            config_api;
        }       

        location /hc {
            health_check_api;
        }

        //upstream api
        location /api {
             api write=on;
        }

        location /kv {
            dyn_sendmsg_kv;
        }

        location /ssl {
            dyn_ssl_api;
        }

        location /range {
            dyn_range_api;
        }

        location /cache {
            cache_quick_api;
        }

        location /dyn_loc {
           dyn_location_api;
        }

        location /dyn_srv {
           dyn_server_api;
        }
  }

3. 統合登録モジュールソリューション

3.1 統合構成入口 (/api を使用)


    server {
        listen       8081;
        
         #api 统一入口
        location /api {
            dyn_module_api;         #用于解析设置clcf->handler为统一入口handler
            
            #权限校验
            api_limit_except  /v1/dyn_loc {method};
            api_limit_except  /v1/range {method};
        }
        
        location /doc {
            doc_api;
        }
    }

3.2 API モジュールは登録インターフェイスを提供します

•APIモジュールは静的モジュールを使用してコンパイルされ、ctrlヘルパープロセスで初期化されます。

•api_module は、kv モジュールと同様の登録インターフェイスを提供し、各モジュールのキーとハンドラーを保存します。

• 各モジュールは、/v{version}/{module_name} をキーとして各モジュールのハンドラを登録します。最初のバージョンはバージョン 1 です。各 API モジュールの登録キーは次のとおりです。

njet-config-api-module
    /v1/config

njet-http-sendmsg-module
    /v1/kv

njet-http-cache-quick-module
    /v1/cache

njet-health-check-helper
    /v1/hc

njet-http-dyn-server-api-module
    /v1/dyn_srv

njet-http-location-api-module
    /v1/dyn_loc

njet-http-range-api-module
   /v1/range

njet-http-ssl-api-module
   /v1/ssl

njet-http-upstream-api-module
   /v1/upstream_api

3.3 APIモジュールのコンテンツ処理段階のプロセス

• http リクエストが来ると、キー (/v{version}/{module_name}) が URL: /api/v{version}/{module_name}/{other} に従って解析されます。

• キーに基づいて登録されたハンドラーがあるかどうかを確認し、見つかった場合は直接 404 を返さずに、そのハンドラーを呼び出して処理します。

4. api_limit_exc スキーム

4.1 limit_exc ディレクティブの概要

   
構文： 制限例外メソッド…{…}
デフォルト -
コンテクスト： 位置

場所内で許可される HTTP メソッドを制限します。メソッド パラメーターは、GET、HEAD、POST、PUT、DELETE、MKCOL、COPY、MOVE、OPTIONS、PROPFIND、PROPPATCH、LOCK、UNLO​​CK、または PATCH のいずれかになります。 GET メソッドを許可すると、HEAD メソッドも許可されます。他のメソッドへのアクセスは、ngx_http_access_module、ngx_http_auth_basic_module、および ngx_http_auth_jwt_module (1.13.10) モジュール ディレクティブを使用して制限できます。

limit_except GET {
    allow 192.168.1.0/32;
    deny  all;
}

これにより、GET と HEAD を除くすべてのメソッドへのアクセスが制限されることに注意してください。

4.2 api_limit_exc 命令スキーム

4.2.1 要件

目標：

•API モジュールの場合、api_limit_exc ディレクティブを追加します (異なる API モジュールに制限を設定するために複数のディレクティブを構成できます)

制限以外の機能:

•limit_exc ディレクティブは、設定されたロケーションのアクセス許可を制御できます。各ロケーション関数は、アクセス フェーズでのアクセス許可検証のハンドラーを登録します。このディレクティブは、検証に合格した後にのみ、後続のコンテンツ処理フェーズを実行できます。 。

•limit_exc ディレクティブは、メモリ内に名前のない位置構造も生成します。

したがって、次の 2 つの目標を達成するには、新しい api_limit_exc ディレクティブを実装する必要があります。

•複数の項目を設定でき、異なる設定のモジュール URL に対して limit_exc を設定できます。

•API ロケーションは、メモリ内で複数の noname を同時にサポートするロケーション構造を生成でき、http リクエストがあるときに実際の URL に基づいて、構成された適切な limit_exc アクセス許可アクセス制御を呼び出すことができなければなりません。

ノート：

limit_exc が設定されている場合、二重層検証が実行されます。ルールは次のとおりです。

•limit_excel 検証が優先されます。

•limit_exc 認証が必要な場合は、limit_exc によるパスワード認証を使用します。

•limit_exc 許可されている場合、api_limit_exc 設定の権限検証に入ります。

4.2.2 api_limit_exc ディレクティブの概要

   
構文： api_limit_除く module_key メソッド…{…}
デフォルト -
コンテクスト： 位置

limit_exc の module_key パラメータを追加します。このパラメータは、/api/v{version}/{module_name} で始まる各 API モジュールの URL プレフィックス形式です。

声明式api 模块前缀： /api/v1/config

kv模块： /api/v1/kv

cache加速：/api/v1/cache

健康检查： /api/v1/hc

动态VS: /api/v1/dyn_srv

动态location: /api/v1/dyn_loc

动态range: /api/v1/range

动态ssl: /api/v1/ssl

动态upstream： /api/v1/upstream_api

4.2.3 構成例

•htpasswdコマンドの使用方法：

centos：
yum install -y httpd

ubuntu:
apt install -y apache2-utils

密码文件/root/bug/njet1.0/htpasswd 新增用户test 密码是123456
htpasswd -bc /root/bug/njet1.0/htpasswd test 123456

密码文件/root/bug/njet1.0/htpasswd_ssl 新增用户test2 密码是test2
htpasswd -bc /root/bug/njet1.0/htpasswd_ssl test2 test2

 server {
       listen       8081;
       
        #api 统一入口
       location /api {
           dyn_module_api;
           
           #dyn_loc 权限校验， 非GET请求需要校验
           api_limit_except  /v1/ssl GET {
              auth_basic "OpenNJet SSL API";
              auth_basic_user_file /root/bug/njet1.0/htpasswd_ssl;
           }
           
           #range 权限校验， 非PUT请求需要校验
           api_limit_except  /v1/range PUT {
              auth_basic "OpenNJet RANGE API";
              auth_basic_user_file /root/bug/njet1.0/htpasswd;
           }
           
           #其他url请求，不做权限校验
       }
       
       location /doc {
           doc_api;
       }

       location /metrics {
           vhost_traffic_status_display;
           vhost_traffic_status_display_format html;
       }

       location /adc {
           #return 200 "ok";
           content_by_lua_file scripts/http_register.lua;
       }
   }

5. テスト

すべての宣言型 API と命令型 API のインターフェイス プレフィックスが統一されています。

5.1 Ctrl設定ファイル

server {
    listen       8081;
    #api 统一入口
    location /api {
        dyn_module_api;
    }
    
    location /doc {
        doc_api;
    }
}

5.2 モジュールのテスト (機能は変更されません。唯一の変更は、すべての API モジュールの URL の変更です)

すべての宣言型 API と命令型 API のインターフェース接頭辞が /api/v{version}/{module_name} で始まるように変更されます。

声明式api 模块前缀： /api/v1/config
kv模块： /api/v1/kv
cache加速：/api/v1/cache
健康检查： /api/v1/hc
动态VS: /api/v1/dyn_srv
动态location: /api/v1/dyn_loc
动态range: /api/v1/range
动态ssl: /api/v1/ssl
动态upstream|： /api/v1/upstream_api

5.2.1 動的SSL証明書:/api/v1/ssl

画像

5.2.2 ヘルスチェック: /api/v1/hc

画像

5.2.3 ダイナミックレンジ: /api/v1/range

画像

5.2.4 キャッシュアクセラレーション: /api/v1/cache

画像

5.2.5 平方: /api/v1/sq

画像

5.2.6 構成 API: /api/v1/config

5.3 api_limit_exc 権限検証テスト

5.3.1 検証パスワード ファイルの生成例:

centos：
yum install -y httpd

ubuntu:
apt install -y apache2-utils

密码文件/root/bug/njet1.0/htpasswd 新增用户test 密码是123456
htpasswd -bc /root/bug/njet1.0/htpasswd test 123456

密码文件/root/bug/njet1.0/htpasswd_ssl 新增用户test2 密码是test2
htpasswd -bc /root/bug/njet1.0/htpasswd_ssl test2 test2

5.3.2 構成 (SSL と範囲のテストを例として挙げます):

server {
        listen       8081;

        location /api {
            dyn_module_api;

            #针对 ssl 添加校验，用户名密码使用test2/test2
            api_limit_except  /v1/ssl GET {
               auth_basic "OpenNJet API";
               auth_basic_user_file /root/bug/njet1.0/htpasswd_ssl;
            }

            #针对 range 添加校验，用户名密码使用test/123456
            api_limit_except  /v1/range PUT {
               auth_basic "OpenNJet API";
               auth_basic_user_file /root/bug/njet1.0/htpasswd;
            }
            
            #如果同时配置了limit_except, 则优先判断limit_except权限配置，
            #如果limit_except 不检查，则会进入到api_limit_except 权限配置检查
            #limit_except GET{
            #   auth_basic "OpenNJet API";
            #   auth_basic_user_file /root/bug/njet1.0/htpasswd;
            #}
        }
   }

5.3.3 テスト:

5.3.3.1 SSL検証テスト

ssl の場合、GET メソッドは検証せず、他のメソッドは検証するため、get インターフェイスを呼び出してもパスワードを入力できず、put インターフェイスを呼び出した場合は、正しいパスワードを持つ test2/test2 のみがパスワードを入力できます。 。

5.3.3.1.1 テストの取得: 結果を直接返す

画像

5.3.3.1.2 PUT テスト: パスワードを入力する必要があります。パスワードが正しいと、結果が返されます。

正しいパスワードを入力し、コンテンツ処理段階に入ります。

5.3.3.2 範囲検証テスト

範囲の場合、PUT メソッドは検証せず、他のメソッドは検証するため、put インターフェイスを呼び出すとパスワードを入力できなくなり、get インターフェイスを呼び出すとパスワードの入力が要求され、正しいパスワードを持つ test/123456 のみが合格します。 。

5.3.3.2.1 GET テスト: パスワードが必要です

GET にはパスワード test/123456 が必要です

画像

正しいパスワードを入力して結果を返します

画像

5.3.3.2.2 PUT テスト: パスワードを入力する必要はなく、コンテンツ処理段階に直接進みます。

画像

NJet アプリケーション エンジンは、カーネルの再構築を通じて独自のランタイム動的構成読み込み機能を実現し、新世代の高性能 Web アプリケーション エンジンです。 NJet は、高性能のデータ プレーン処理機能を備えており、NJet 独自のコパイロット CoPilot サービス フレームワークを通じて、クラスタリング、高可用性、アクティブ ヘルス チェック、宣言型 API などの複数の補助機能をスケジュールして、機能拡張を促進し、管理/制御機能ペアを分離します。データ プレーンへの影響を考慮すると、NJet アプリケーション エンジンのパフォーマンスは、CNCF が推奨する Envoy アプリケーション エンジンの 3 倍を超えています。メールグループ公式サイト   

未知のオープンソースプロジェクトはどれくらいの収益をもたらすのでしょうか? Microsoftの中国AIチームは数百人を巻き込んでまとめて米国に向かいましたが、 Yu Chengdong氏の転職は 15年間の「恥の柱」に釘付けになったと正式に発表されました。前に、しかし今日、彼は私たちに感謝しなければなりません— Tencent QQ Video は過去の屈辱を晴らしますか？ 華中科技大学のオープンソース ミラー サイトが外部アクセス向けに正式にオープン レポート: 開発者の 74% にとって Django が依然として第一候補であるZed エディターは、 有名なオープンソース企業の元従業員 によって開発されました。 ニュースを伝えた: 部下から異議を申し立てられた後、技術リーダーは激怒し無礼になり、女性従業員は解雇され、妊娠した。 Alibaba Cloud が Tongyi Qianwen 2.5 を正式リリース Microsoft が Rust Foundation に 100 万米ドルを寄付
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/6606114/blog/11104034
おすすめ
ランキング
树莓派计算模块核心板底板Compute module 4 IO Board+树莓派计算模块核心板Compute module 4 CM4可扩展wifi蓝牙模块 emmc定制，烧录Ubuntu系统
13-STM32モノのインターネット開発WIFI（ESP8266）+ GPRS（Air202）システムソリューションWeChatアプレット（WebバージョンMQTT、小規模テスト）
心満たされたピット内Django2.2カスタムエラー・インターフェース
卵2.24.0リリース、エンタープライズクラスのフレームワークのNode.js
C++this 理解
CSSの中国語版のプロパティの非常に包括的な要約！
バブルソートの基本のpython3のアルゴリズムをソート、挿入ソート、選択ソート
QTアプリケーション起動失敗のトラブルシューティング方法
PPTX机械加工安全培训（附下载）
ファイルシステムからサブフォルダーを削除します（C ++サブフォルダーを削除します）
アーカイブ
もっと
2025-04-23(0)
2025-04-22(0)
2025-04-21(0)
2025-04-20(0)
2025-04-19(0)
2025-04-18(0)
2025-04-17(0)
2025-04-16(0)
2025-04-15(0)
2025-04-14(0)

コードワールド

© 2018 codetd.com