マイクロサービス アーキテクチャの Nginx リンク トラッキング

ほとんどのマイクロサービス アーキテクチャでは、Nginx は基本的に一般的に使用されるアクセス レイヤー機能であるため、リクエスト ID が検証されて Nginx レイヤーから入力され、Nginx リクエスト ログに出力されることを期待しています。

読書ヒント: この記事は、リンク追跡の完全なソリューションを提供するものではなく、Nginx レイヤーでのリンク追跡のサポート ソリューションのみを提供します。

1 背景の紹介

マイクロサービスの誕生により、メンテナンス性の低さ、スケーラビリティの低さ、柔軟性の低さ (大まかな比較) など、従来のモノリシック アプリケーションの多くの問題が解決されました。マイクロサービス アーキテクチャは優れていますが、多くの課題ももたらします。その中で、トラブルシューティングは解決する必要がある課題の 1 つです。では、多くのアプリケーションやインスタンスにわたる障害の根本原因を見つけるにはどうすればよいでしょうか?

上記の要件に基づいて、各アプリケーションの各トランザクションによって生成されたすべてのログを一元的に収集して表示できます (ただし、ログ センター がある場合のみ)。こうすることで、トランザクションがどのステップで失敗したかをすぐに確認できます。うまくいけば、収集したログや障害を分析した後、グラフィカルなインターフェースで直感的に表示して、二次開発やデータ分析を直接実行することもできます。

たとえば、マイクロサービス呼び出しのトポロジー図を表示し、色を使用して障害を区別できます(一般的に使用される赤: 異常を示す、緑: 正常、黄色: 警告など)。次に、一般的な障害や例外を分類し、次のようなわかりやすい表示を行うことができます (率直に言うと、スタックに直接アクセスする必要はありません)。 NullPointerException: インターフェイスは、どのコード行が null ポインターをスローしたかを直接、わかりやすいプロンプトで表示します。 、入力パラメータは What... (これはこの記事の焦点では​​ないので、あまり意味のないことには触れません。後で機会があれば詳しく紹介します)。

マイクロサービス アーキテクチャ全体のリンク トラッキングを行うには、トランザクションがマイクロサービス センターに入った最初の時点からすべてのログを関連付けるグローバル トランザクション ID が存在することを強く望みます (リンク トラッキングの場合、そのような ID では明らかに十分ではありません)。ただし、ここではこれのみを紹介します）。もちろん、最も理想的なのは、フロントエンドのログ (操作ログ、データ フローなど) を計画することです。

2 Nginx

ほとんどのマイクロサービス アーキテクチャでは、Nginx は基本的に一般的に使用されるアクセス レイヤー機能であるため、リクエスト ID が検証されて Nginx レイヤーから入力され、Nginx リクエスト ログに出力されることを期待しています。ここでは、Nginx 層のトランザクション ID 生成メソッドを実装する方法を 3 つだけ紹介します。

2.1 オプション 2: 組み込み変数に基づくスプライシング

1.11.0 より前のバージョンでは、スプライシングを使用してリクエスト ID を組み立てることができます。参考構成は以下の通りです:

リーリー

パラメータの説明:

• $pid: nginx ワーカープロセス ID
• $connection: 上流サーバーへのリンク ID の数
• $bytes_sent: 送信されたバイト数
• $msec: 現在の時刻、つまり、秒とミリ秒を含む、この変数によって取得される時刻 (. で除算)

2.2 オプション 3: LUA スクリプトに基づく実装

システム /dev/urandom によって生成されたランダムな UUID を使用します。参照スクリプトは次のとおりです:

リーリー

2.3 解決策 1: $request_id の実装に基づく

Nginx在 1.11.0版本中就提供了内置变量 $request_id ，其原理就是生成32位的随机字符串，虽不能比拟UUID的概率，但32位的随机字符串的重复概率也是微不足道了，所以一般可视为UUID来使用即可。参考配置如下：

<span class="hljs-comment"># Nnginx代理默认会把header中参数的 "_" 下划线去掉，所以后台服务器后就获取不到带"_"线的参数名</span>
<span class="hljs-attribute">underscores_<span class="hljs-keyword">in</span>_headers</span> <span class="hljs-literal">on</span>;

<span class="hljs-comment"># 设定日志格式</span>
<span class="hljs-attribute"><span class="hljs-built_in">log</span>_format</span> main  \<span class="hljs-string">'<span class="hljs-variable">$remote_addr</span> - <span class="hljs-variable">$remote_user</span> [<span class="hljs-variable">$time_local</span>] "<span class="hljs-variable">$request</span>" \'
                 \'<span class="hljs-variable">$status</span> <span class="hljs-variable">$body_bytes_sent</span> "<span class="hljs-variable">$http_referer</span>" <span class="hljs-variable">$upstream_http_request_id</span> \'
                 \'"<span class="hljs-variable">$http_user_agent</span>" "<span class="hljs-variable">$http_x_forwarded_for</span>"\';

server {
    location / {
        <span class="hljs-comment"># 如果请求头中已有该参数,则获取即可;如果没有,则使用</span><span class="hljs-variable"><span class="hljs-comment">$request_id</span></span><span class="hljs-comment">进行填充</span>
        <span class="hljs-built_in">set</span> <span class="hljs-variable">$temp_request_id</span> <span class="hljs-variable">$http_x_request_id</span>;
        <span class="hljs-keyword">if</span> (<span class="hljs-variable">$temp_request_id</span> = "") {
            <span class="hljs-built_in">set</span> <span class="hljs-variable">$temp_request_id</span> <span class="hljs-variable">$request_id</span>;
        }
        <span class="hljs-comment"># 屏蔽掉原来的请求头参数</span>
        proxy_<span class="hljs-built_in">set</span>_header  x_request_id        "";
        <span class="hljs-comment"># 设置向后转发的请求头参数</span>
        proxy_<span class="hljs-built_in">set</span>_header  X-Request-Id        <span class="hljs-variable">$temp_request_id</span>;
    }
}
</span>

3 最佳实践

生成交易ID的方式有很多种，但希望使用者结合自身实际情况进行合理取舍，而不要盲目的追求ID的唯一性、可读性和时序性等等。

比如，ID具有时序性虽然有一定的好处，但实际的架构根本没有去使用该时序性，则没必要花大量的精力和做出大量的开发，去实现一个有时序性的交易ID。又比如，觉得UUID可读性太差，从而花了很多成本去开发一个具有一定含义的交易ID（如前几位表示什么意思，多少位到多少位又表示什么意思之类的），开发出来后，实际架构根本没有去解读该ID的地方，则浪费了成本。

但也不是所有人都直接使用UUID就能满足的，比如我需要考虑日志的容量，则可以考虑适当缩减ID的长度（每个ID缩减10个字符串，每笔交易就可能少几百或几千个字符串，再往上规划，还是可以减少一些日志容量的）。

最后，如果有考虑想收集前端的日志的童鞋，建议交易ID就不要使用Long型，因为前端可能会有损失精度的问题。同时也建议使用 $request_id  来填充交易ID。

以上がマイクロサービス アーキテクチャの Nginx リンク トラッキングの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。