2

基本的には、ソース イメージが Azure Blob Storage に格納され、imageresizer が Azure App Service で実行され、Azure CDN が CDN レイヤーである、推奨されるクラウド アーキテクチャを使用します。

それにもかかわらず、ImageResizer v3、Azure App Service デプロイ スロット、および DiskCache で問題が発生しています。

中断を防ぐために、Azure App Service のステージング スロットを使用します。また、DiskCache プラグインも使用します。構成を行わないと、イメージキャッシュはスロット固有の D:\home\site\wwwroot\imagecache\ に書き込まれます。

これにより、次の 2 つの問題が発生します。

  1. スロットを交換すると、使用されているイメージキャッシュが古くなり、多くのイメージが失われます。
  2. App Service プランでは常に古いイメージキャッシュがディスク容量を占有しています。Microsoft のアドバイザーは、DiskCache に仮想ローカル ファイル システムの代わりに Blob Storage を使用することを推奨しています。

BlobCachePlugin または S3CachePlugin がないことに気付きました。これには正当な理由があるのではないかと考えていました。

私の質問は次のとおりです。

  1. ICache インターフェイスを実装するカスタム BlobStorageCachePlugin を使用して Azure Blob Storage にイメージキャッシュを保存しない理由はありますか?
  2. 正当な理由がある場合、デプロイ スロットの問題を回避するために、どの代替アーキテクチャをお勧めしますか?
4

2 に答える 2

0

Web アプリの前に CDN がある場合、DiskCache プラグイン (または要求された Blob Storage キャッシュ) は必要ですか?

画像が Web アプリによって処理されると、CDN エッジ サーバーの 1 つによってキャッシュされます。では、Web アプリ/Blob ストレージに画像をキャッシュする目的は何でしょうか?

于 2017-01-10T19:58:50.217 に答える