マイクロサービスを備えたパブリックAPIファサード
各サービスが一連のアクティビティを担当し、RESTfulインターフェースをその機能に公開するマイクロサービスインフラストラクチャについて考えてみます。たとえば、チャットアプリケーションを想定します。
ユーザーの作成を担当する1つのサービスと、メッセージの作成を担当する2番目のサービスがある場合があります。
ここで、公開用のRESTアプリケーションへのインターフェースを作成します。マイクロサービスにこの公開ファサードを作成するためのベストプラクティスはありますか？いくつか興味があります。主に：
- どのレイヤーが認証/承認を処理する必要があるか（基礎となるサービスの場合-このデータを共有するか、それぞれが独自の認証を実装するか）
- 明らかにこのアプリケーションでは、メッセージはユーザーからユーザーに送信されます。ただし、メッセージサービスは、何にでも使用できるように簡単に記述できます。パブリックプロキシは、ユーザー情報を決定してメッセージサービスに委任する必要がありますか？
一般的な2つの承認モデルがあります。信頼できるサブシステムと委任です。
- Trustedサブシステムは、ユーザー作成とメッセージ作成サービスがAPIアプリケーションを信頼してユーザー認証と承認を実行するアーキテクチャです。このモデルでは、APIアプリケーションは（ネットワークACL、トークン、x509証明書などを介して）信頼されており、無制限の容量で両方のサービスとやり取りできます。
- Delegationは、APIがユーザーの代わりにマイクロサービスを呼び出す代替アーキテクチャです。このようなモデルでは、APIとマイクロサービスの両方が承認を処理し、マイクロサービスはAPIアプリケーションのIDと元の要求を行ったユーザーの要求の両方を検証します。 APIは、ユーザーがリクエストを行うために認証および承認されていることを検証し、「メッセージ」マイクロサービスは、アプリケーションが信頼されていることと、ユーザーがメッセージの作成を承認されていることを検証します。
これら2つのアプローチの間にはトレードオフがあります。信頼できるサブシステムは実装が簡単なアーキテクチャですが、委任により、より高度なセキュリティ機能を実現できます。アプリケーションの場合、信頼できるサブシステム戦略に従う方がはるかに簡単なので、APIの "ファサード"でauthn/authzを構築することを強く検討します（おそらくゲートウェイの方がWordの方が優れていますか？）。
編集：答えは、メッセージサービスが何をしているか、およびその職務を実行するために必要なデータに大きく依存します。メッセージサービスがメッセージをリアルタイムでWebソケットにルーティングするだけの場合、メッセージがデータベースに永続化される場合とは要件が異なる場合があります。ただし、一般的には、サービスがユーザーサービスに直接結合されていなくても、ユーザーIDとやり取りする可能性があります（たとえば、メッセージを送信者ID、受信者ID、メッセージとしてテーブルに格納します）。