マイクロサービス間の基本的な通信をどのように行うべきかを理解するのに問題があり、他の質問でこれを行うための適切な解決策または標準的な方法を見つけることができませんでした。この基本的な例を使用してみましょう。
請求書を返す請求書サービスがあります。すべての請求書には、ユーザーと製品に関する情報(ID)が含まれています。特定のユーザーの請求書を表示する必要があるビューがある場合は、単純なリクエストを行うだけです。
let url = "http://my-domain.com/api/v2/invoices"
let params = {userId:1}
request(url,params,(e,r)=>{
const results = r // An array of 1000 invoices for the user 1
});
ここで、この特定のビューについて、各請求書の各製品のすべての詳細を取得するために別のリクエストを行う必要があります。
results.map((invoice)=>{
invoice.items.map((itemId)=>{
const url=`http://my-domain.com/api/v2/products/${itemId}`
request(url,(e,r)=>{
const product = r
//Do something else.....
});
});
});
コード例が完全ではないことはわかっていますが、これにより、製品サービスに対して膨大な数(少なくとも1000)のリクエストが生成され、1人のユーザーに対してのみこの種のリクエストを行う1000人のユーザーがいると想像してみてください。
パフォーマンスの問題を回避するために、この数の要求を行うことなく、すべての製品から情報を取得する正しい方法は何ですか?
この種のシナリオには、次のような回避策がいくつか見つかりました。
マイクロサービスアーキテクチャでは、これらはこの種の問題に対処するための正しい方法ですか?私にとって、それらは単純な回避策のように見えます。
編集#1:RemusRusanuの応答に基づく。
Remusの推奨に従って、私は自分のサービスを分離し、それらをもう少し詳しく説明することにしました。
上の画像に示されているように、マイクロサービスは分離され(具体的には請求サービス)、データの所有者になりました。この構造を使用することで、非同期ジョブがある場合や他の2つのサービスがダウンしている場合でも、Billing-serviceが機能することを保証します。
新しい請求書を作成する必要がある場合は、他の2つのマイクロサービス(ユーザー、在庫)を同期的に呼び出してから、請求サービスの「キャッシュ」テーブル(ユーザー、在庫)のデータを更新できます。
これらの「キャッシュ」テーブルが読み取り専用であると想定するのも良いですか?ユーザー/インベントリサービスのみがこの情報を変更して、情報の分離と権限を維持できるようにする必要があるためだと思います。
You need to isolate the services as so they do not share state/data. The design in your question is a single macroservice split into 3 correlated storage silos. Case in point, you cannot interpret a result form the 'Invoicing' service w/o correlating the data with the 'Products' response(s).
Isolated microservices mean they own their data and they can operate independently. An invoice is complete as returned from the 'Invoices' service. It contains the product names, the customer name, every information on the invoice. All the data came from its own storage. A separate microservice could be 'Inventory', that operates all the product inventories, current stock etc. It would also have its own data, in its own storage. A 'product' can exist in both storage mediums, and there once was logical link between them (when the invoice was created), but the link is severed now. The 'Inventory' microservice can change its products (eg. remove one, add new SKUs etc) w/o affecting the existing Invoices (this is not only a microservice isolation requirement, is also a basic accounting requirement). I'm not going to enter here into details of what is a product 'identity' in real life.
自分が尋ねているような質問をしていることに気付いた場合は、マイクロサービスがないことを意味している可能性があります。すべての通信を非同期キューベースのリクエストに置き換えるとどうなるかを考えながら、マイクロサービスの境界について考える必要があります(応答は6日後に届く可能性があります):セマンティクスが壊れている場合は、境界が間違っている可能性があります。セマンティクスが成り立つ場合は、正しい道です。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加