2017-07-25 7 views
1

私はサービス間の同期通信がアンチパターンであることを知っていますので、私のユースケースに対する良い解決策を探しています。マイクロサービス間の同期REST通信の代替

私はこの2つのサービスがあります。Users Feed Service(UFS):

  • Location Serviceユーザーは今すぐ

スコア管理し、ユーザーの場所

  • Score Serviceを管理し、私は別のサービスを構築する必要があります。指定された場所の近くのユーザーをスコア(降順)で並べ替える必要があります。場所を考えると

    同期ソリューション

    1. 、UFSは、それがスコア・サービス(REST)から彼女のスコアを取得し、それらの一つ一つについてロケーションサービス(REST)
    2. から近くのユーザーをフェッチ
    3. 最後に、メモリ内のユーザーをソートして返します

    代替方法はありますか?私はこのような何かを考えています

    イベントキューソリューション

    • UFSデータベース、またはメモリキャッシュか何かそれがキュー内の変更を待機
    • に格納し、ユーザーの場所とスコアスコアサービスと位置情報サービスが公開された時点でデータを更新する

    このように、クライアントからのリクエストがあった場合、ユーザーフィードサービスはネットワークリクエストを実行する必要はありませんそれは必要なデータを所有しています)

    これは良い解決策ですか?どうすれば改善できますか?大量のユーザーで拡大縮小できますか?

  • +0

    これは、同期ソリューションよりも優れた拡張性を備えています。キューよりも優れており、APIよりも大量に処理されます。ただし、キューに入れられたトランスポートインフラストラクチャの複雑さに対してこれを相殺する必要があります。あなたは時期尚早に最適化していないと確信していますか? –

    +0

    おそらく私です。私は将来の変化を恐れている。同期からキューベースのシステムへの移行は困難です。とにかく、あなたは正しいと思います。たぶん、私は存在しないスケーラビリティの問題を解決しようとしています。ありがとう –

    答えて

    1

    あなたがリストアップしていないいくつかの追加要件があるかもしれませんが、このケースでは、他のサービスから大量のデータを複製するイベントベースのソリューションは工学上の道です。位置service-に変更がある場合にUFS場所を取得する場合、それはスコアサービスに関しては位置

    の変化にロケーションサービスからのイベントへの呼び出しを結ぶことは理にかなって

    、Iはそれを同期的なままにしておいてください。しかし、そのインターフェースは顧客のリストを受け入れます。

    +0

    あなたの答えをありがとう。大量のユーザーをどのように処理できますか?スコアサービスに対するいくつかの呼び出しでそれを分けるべきですか? –

    +0

    大きなものに依存しますか?スコアサービスAPIを変更して、クライアントのリストを受け入れ、最も高いスコアを持つXクライアントを返すようにすることができます - (mのTOP n)次に、データの転送量を大幅に減らす必要があります –

    関連する問題