ファイルストレージマイクロサービスの設計
問題の概要：
学習目的でのみSpringアプリケーションを作成しています。ファイル専用のマイクロサービスを作成します。
- 最初は、2つの基本エンドポイント
upload/downloadのみがファイルにあります（ユーザーが直接ではなく、他のマイクロサービスによって使用されます）。 fileテーブルを使用して、そのマイクロサービス専用のデータベースを作成します。少なくとも最初は。- ファイルをクラウドに保存する（つまり、_
Amazon S3_） - ファイルに関するメタ情報を
fileテーブルに保存します。メタとは：Urlをクラウドにファイルする- 名前
- サイズ
- タイプ（ディレクトリまたはファイル）
- 拡張
例フロー：
- マイクロサービス
Aは、ファイルマイクロサービスuploadエンドポイントに画像_user_attachment.jpg_を送信します。 - サーバーは検証、セキュリティチェックなどを行います.
- ファイルをクラウドストレージに送信します。 _
Amazon S3_ - そのファイルに関するメタ情報を
fileというローカルテーブルに保存します。 F.e.追加：INSERT INTO file (url, name, size, type, extension) VALUES ("http://aws.Amazon.com/testapp/pictures/2018-09/picutre.jpg", "picture", 34233, "FILE", "JPG") - アップロード操作を初期化したマイクロサービス
Aにメタ情報を送信します。
クラウドへのアップロードは別のスレッドで非同期に行われ、メッセージブローカーのヘルプを使用することもできます。
質問：
- それはクリーン/良いデザインパターンに準拠したアプローチですか？
- そのアプローチの良い点/悪い点は何ですか？
- どうすればより良い方法でそれを行うことができますか？ （アプリケーション（ローカル）が実行されているマシンにファイル（コンテンツ）を保存したくない）
Misc：
この例は簡単です。商業/大規模プロジェクトの設計には、同様の仮定/基礎があると思います。したがって、fileマイクロサービスに複数のテーブルがあり、それらの構造とマイクロサービスロジックの両方が拡張されていると仮定します。
商用アプリケーションのfile-management-microserviceは、優れたデザインパターンルールに従ってどのように見えるでしょうか？
SOA=のサービスの目標は、他のサービス間で複製する必要があるいくつかのロジックを実行することです。そのロジックが、サービスが存在する理由です。
あなたの場合、あなたはサービスを通じて価値を追加しません。 S3 is自体がサービスである場合、他のサービスは簡単にS3に直接アクセスできます（それはyourサービスではありませんが、ここでは関係ありません）。
仲介サービスに付加価値がないだけでなく、そのコストはかなり高額です。数時間でドラフトできると想像するかもしれませんが、それは事実です。ただし、確実に機能し、すべてのEdgeケースを処理するものを使用するには、キャッシュ、冗長性、中断されたアップロードとリカバリ、大きなファイル、タイムアウト、ブルートフォースとDDOS、パラメーターの特殊文字、権限、IAMに対処する必要があります。と他の何十ものかわいいもの。
したがって、2週間または3週間の開発とおそらく1週間のデバッグ（YMMV、HTTPでの経験がわからない、SOAおよび使用するテクノロジサービスを作成しますが、経験が豊富な場合でも、2週間未満の費用は期待できません。つまり、たくさん）です。
私はそれが商業/大規模プロジェクトでどのように行われるのか知りたいだけでした。
企業は、経験豊富な開発者に1日あたり平均700ドル支払うので、私の見積もりでは2週間とすると、タスクの費用は7,000ドルになります。商業プロジェクトはお金に関するものです。 $ 7,000ほどの金額を節約する機会があれば、彼らはそれを実行します。
この直接的なコストに加えて、ホスティングとコードのメンテナンスの面でコストがかかります。このサービスは何年も維持する必要があり、元の価格よりもはるかに多くの請求書に追加されます。繰り返しになりますが、このすべてのお金は、そのようなサービスsaveが会社に何ができるかを明確に理解せずに浪費されました。帯域幅も他のリソースも節約されません。アマゾンに支払う金額は減らないので...
これだけではありません。仲介サービスに依存するすべてのプロジェクトのメンテナンスのコストも増加します。サービスの場合：
- パッチを適用する必要があり、パッチにはインターフェースの変更が必要です。
- URLを変更して、別の場所に移動する必要がある
- ダウンしていて、クライアントサービスがダウンしないようにするには、サーキットブレーカーが必要です。
- 非推奨であり、クライアントを別のものに移行する必要があります。
即時の予期しないメンテナンスが必要であり、通常はコストもかかります。現在、AmazonのS3よりもyourサービスでこれら4つのことが発生する可能性がはるかに高くなっています。 あなたが悪い開発者だからではありません。ただし、Amazonの規模はサービスの規模とは少し異なるため、クライアントがS3に確実に依存できるようにするために、より多くの労働力を支払う必要があります。
最後に、多くの開発者は、Amazon AWS（および場合によってはS3）の経験があります。これは、あなたが新しい人を雇うとき、S3を直接使用する場合、サービスがどのようにファイルを保存しているかを彼は簡単に理解できることを意味します。間接参照のレベルを追加すると、この利点は失われます。さらに重要なのは、誰かがストレージに問題を抱えるたびに、クライアントサービス、仲介者、またはS3のいずれに問題があるのかを自問する必要があるということです。これにより、デバッグ時間が長くなります。
そう：
それはクリーン/良いデザインパターンに準拠したアプローチですか？
いいえ。サービスが付加価値を与えるときにサービスを追加します。必要以上に複雑なものにしないでください（KISS）。特に、メリットのないレイヤーを追加しないでください。
そのアプローチの良い点/悪い点は何ですか？
良い点：S3に比べてはるかにシンプルなインターフェースを提供するという事実。 AWSに慣れていない開発者にとって、S3は非常に複雑になる可能性があります。
悪い点：すでに上でそれを言った。
どうすればより良い方法でそれを行うことができますか？ （アプリケーション（ローカル）が実行されているマシンにファイル（コンテンツ）を保存したくない）
S3を直接呼び出す。
アルセニによる素晴らしい説明。
この仲介サービスの利点の1つは、呼び出し元（マイクロサービスまたはエンドユーザー）が、使用に使用するストレージを選択できるかどうかです。実際の提案がどれほどかはわかりませんが、重要なドキュメントが複数のクラウドストレージベンダーにまたがって失われるのを恐れて保存することがよくあります。したがって、この中間サービスは、発信者が使用したいストレージを（オプションで）選択するか、デフォルトで発信者の目的に合った最も安いストレージに選択する機能を提供できます。