4

マイクロサービス アーキテクチャでの Azure サービス プランに関するベスト プラクティスを探しています。容量、リソース、開発者、および全体的なアーキテクチャの点で、それぞれが互いに完全に独立している一連のマイクロサービスがあります。言うまでもなく、1 つのサービスで問題が発生した場合、問題のあるサービスとやり取りしない限り、他のサービスは影響を受けません。これらのサービスは Azure でホストされています

私の質問は、サービス プランと、それらが開発環境やステージング環境にどのように関連するかについてです。これまでは、マイクロサービスのサービス プランを作成し、PersonService と呼んでいました。そのため、PersonService サービス プランを作成し、デフォルト スロットを本番 (個人サービス) にして、別のステージング スロット (個人サービス ステージング) を用意して、ステージング/テストのニーズに対応します。これらはすべて、同じサービス プランで提供されます。

今日、開発者がすべての CPU やメモリを使い果たす恐ろしいバグをステージングに展開すると、本番スロットがそれらのリソースを使い果たし、本質的にステージング環境が本番環境の応答時間に影響を与えるという恐ろしい考えが浮かびました。

これが事実であると考えるのは正しいですか？この問題を回避するために、これをどのように設定することをお勧めしますか? ありがとう

4

1 に答える 1

1

はい、その通りです。person-service-staging が基盤となるサーバーのリソースのかなりの部分を消費し始めると、person-service に影響します。

それを回避することは、現在の設定と優先順位によって大きく異なります。開発/テスト/ステージング サービス プランを追加することは、最も簡単な方法です。これにより、本番サービス プランは本番対応コード専用になります。デプロイメント スロットを使用すると、バージョンを簡単に切り替えることができます (本番環境で何かが壊れていることに気付いた場合は、迅速にロールバックできます)。

これに代わる方法は、テスト パイプラインの一部として展開するステージング専用のサービス プランを用意することです。Azure がサービス プランを立ち上げる速度は、サービス プランをその場で作成および破棄できることを意味します。これにより、ステージング サーバーが運用コードと同じ計画で実行されている場合に、ステージング サーバーに対してパフォーマンス テストを実行できるという利点が得られます。

クラウド コンピューティングの主な利点の 1 つは、使い捨てサーバーを作成できることです。「これが私たちのステージング サーバーだ」という古い哲学から脱却するには、慎重な検討が必要です。CI シナリオであっても - 30 分ごとにコードをデプロイする場合を除きます。- テストするためにいくつかの新しいサーバーを投入する方がはるかにクリーンです。自動化されたテスト パイプラインがなくても、Web ページのボタンに接続されたいくつかの Azure Automation スクリプトの問題にすぎません (ただし、これらのいくつかのスクリプトがどれだけ速く増殖するかは驚くべきことです! はるかに洗練されたものに/複雑）

于 2016-01-02T12:35:11.353 に答える