TLTR:サーバーの場所や使用されているテクノロジーに関係なく、認証とユーザー情報のサービス間で通信するための良い方法は何ですか
マイクロサービスについて学習しようとしていますが、ユーザー情報へのアクセスにアプローチし、複数のサービスでアクセスを制御する方法が少しわかりません。私がこれに完全に間違って近づいているかどうか私に知らせてください。
たとえば、ブログCRUD操作の基本的なサービスと、画像やビデオをアップロードおよび保存するためのサービスがあります。私はまだAuthorizationまたはUsersで何もしていません(ただし、最終的にモデルに存在するUserIdを考慮しています(たとえば、作成者、コメント投稿者などのブログモデルObjectID)。
私はこれを可能な限り分離したいと思っています(何よりも学習目的で)。現時点ではすべてをNode.jsで構築していますが、nginx、java /などのさまざまなテクノロジーを交換できるようにしたいと考えています。 go / pythonサービスまたは別のストレージ(現在はmongoですが、オプションとしてsqlに切り替えられるようにしたい)
現在、これらをどのように構造化しているかは、両方のサービスをExpress.jsアプリとして構築しており、現在、node-http-proxyを使用してExpressサービスにプロキシしています(これは、今のところnginxを設定して保存するためだけですが、していませんnginxにも依存したい)。
どのようにアプローチすればよいですか:
認証されたユーザーまたは一部のルート(たとえば、新しい投稿の作成時または更新/削除時)であり、投稿を既読にするときではありません(最終的にはロールも組み込みたい)
たとえば、ブログの作成者に保存されているユーザーのIDからユーザー情報を入力し、それをユーザー情報に置き換えます(単一のアプリでは、マングースの入力を使用できます)。
主な目的は、AuthとUsersを別々のサービスに保持し、他のサービスで呼び出して、たとえば別の物理サーバーに配置されている場合に別のDBに保存できるようにすることです。
誰かが私にHTTP / Sを使用してこれを行うことができると提案しましたが、これを行うためのより良い方法があり、実装例を誰かに教えてもらえますか?Node.jsが望ましいですが、必須ではありません
これにはおそらくいくつかのサービスレジストリが必要ですが、これをどのように実装するかについて少し迷っています
独自のアプリケーションとしての認証レイヤーは、SOA設計に非常によく適合します。マイクロサービスデータベースに直接アクセスできないHTTPエンドポイントがあります。SOAのベストプラクティスは次のとおりです。
私たちにとってサービス指向とは、公開されたサービスインターフェイスを介した唯一のアクセスで、データを操作するビジネスロジックでデータをカプセル化することを意味します。サービスの外部からの直接のデータベースアクセスは許可されておらず、サービス間でのデータ共有もありません。
--Werner Vogels、Amazon CTO
http://martinfowler.com/microservices/への参照
認証レイヤーまたはサービスとは何ですか?1つのサーバーが認証がまだ確立されていることをどのように確認しますか?クライアントベースの永続性の一種は、ドメイン名に厳密にフックされたHTTP cookieです。したがって、明示的な認証手順がないと、複数のドメイン間で同じcookieを再利用することは容易ではありません。
http_requestが目立たない認証を提供できる特定のキーまたはヘッダーを渡すことができる場合、このモジュールはバージョン1.5.4以降の組み込みのNginxコアになりました:http://nginx.org/en/docs/http/ngx_http_auth_request_module.html
location /upload {
auth_request /auth;
...
}
location = /auth {
internal;
proxy_pass http://auth_service.localhost;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
http://auth_service.localhost(独自のURLを選択)を介してアクセスできるエンドポイントは分離されており、独自のデータベースがあり、ユーザーを認証するかどうかという1つのことだけを実行します。メカニズムは、特定のキーやヘッダー、さらにはIPアドレスに依存する可能性があります。後続の多くの要求を抑制するために、応答をキャッシュできます。
SOAは難しいですが、これをよく読むことをお勧めします:https://www.nginx.com/blog/introduction-to-microservices/
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加