マイクロサービスアーキテクチャのメールサービス
SendgridやMandrillなどのAPIを使用してメールを送信する場合、マイクロサービスアーキテクチャでメールの送信を処理する必要があるのは誰ですか？
- それは単なるHTTP APIであるため、各マイクロサービスは独自に送信する必要があります（短所のいくつか：各マイクロサービスはシステム内の各ユーザーの電子メールを知っている必要があります、長所：実装が簡単）
- 別のマイクロサービスがイベントに基づいてメールを送信する必要があります（短所：単一障害点、長所：メールはこのマイクロサービスでのみ認識され、プロファイルでメールを変更すると1か所のみが変更されます）
コメントでライヴが指摘したように、それは明確な答えではありません。多くはあなたの優先順位がどこにあるかに依存します。
単一の中央メールサービスは、マイクロサービス環境で最もクリーンで最も「適切」な場合があります。それは確かに私が真剣に検討したいことです。
しかし、使用可能なメールサービスの詳細を抽象化するために構成可能なメールライブラリを構築し、メールを送信する必要がある各マイクロサービスをリンクすることは、実行可能な別のオプションです（もちろん、何十年にもわたって行われてきたことです）。
最初のオプションの利点（アーキテクチャの純粋さを超えて）は、電子メール環境で何かが変更されても、変更する必要があるのは1つだけであるということです。欠点は、単一障害点が導入されたことです。作成したメールサービスが何らかの理由で停止した場合、どこからでもメールを送信できなくなります。もちろん、複数のインスタンスとロードバランサーを実行してそれらの間のトラフィックを転送することで、複雑さを犠牲にして、そのリスクを部分的に軽減できます。
2番目のオプションには、メールライブラリが変更された場合にすべてのマイクロサービスを再構築および再デプロイする必要があるという明確な欠点があります。
外部APIをベンダーに依存しないAPIで内部サービスにラップするのが最適です。このように、単一のサービス変更で外部APIベンダーを切り替えることができます。
あなたが持っているすべてのサービスは潜在的に単一障害点です（それらはすべて本質的なことをしていると仮定します）。これが問題である場合は、自動フェイルオーバーを備えたロードバランサーの背後にある冗長なステートレスサービスを使用して高可用性の設定を確認するか、サービス間の通信が信頼できるメッセージブローカーを介して行われるため、サービスの適度なダウンタイムが発生するまでメッセージブローカーソリューションを確認してください。再びメッセージを受信する準備ができています。