2017-04-09 4 views
-1

私の修士号の最終プロジェクトでは、私は無人機配送システムを設計することにしました。主な目的は、複雑なシステムを設計することを学ぶことです。ソフトウェアアーキテクチャの観点から、どのようにして納品システムを設計していますか?

は、基本的なユースケースはこれです:

  1. ユーザーは、商人のオンラインショップに行き、製品を選択し、「ドローン・デリバリー」として配信方法を選択し、彼の配信場所を選択します。
  2. マーチャントのウェブサイトでは、当社のドローン配送システム(DDS)アプリケーションへのAPI呼び出しにより、新しい配送オーダーを登録しています(注文には必要なすべての情報が含まれています:小包のピックアップ場所と目的地...)
  3. Dronesの位置に基づいたDDSアプリケーションは、アルゴリズムに基づいて最短時間でこの無人飛行を行うことができる無人機を計算してマークします。
  4. 選択された無人機は無料です。

これまでのところとても良いです。私の質問は、このシステムのソフトウェアアーキテクチャに関連しています。私はいくつかの一般的な質問といくつかの特定の質問があります。

一般的な質問:

  • どのようにスケーラブルであるために、このようなシステムを設計していますか?私は、システムがマーチャントによって使用される可能性があります.100人のオーダーで同時にAPIにヒットした場合、システムはそれを処理できる必要があります。
  • このようなシステムを設計する際に、良い設計原則やパターンには何がありますか?

具体的な質問:
これまでのところ私は、このアーキテクチャを思い付いています

システムコンポーネント:

  1. のJava(春)アプリケーション
    • レストウェブservce
    • dorensとparces
    • のRabbitMQ
  2. MySQLサーバ
  3. のRabbitMQ

システムフローの

  • プロデューサ/コンシューマルーティングドローン用
  • タマンロジックおよびアルゴリズム:

    1. マーチャント注文を登録するためにREST APIをヒット
    2. Javaアプリケーションは注文をMysqlデータベースに保存します。
    3. 注文をデータベースに保存した後、プロデューサは注文をRabbitMQのキューに入れます。
    4. 消費者がRabbitMQ注文キューを消費します。それは各注文を取り、配送に最適な時間を提供する無人機のアルゴリズムに基づいて計算します。各無人機はRabbitMQに別のキューを持っています。最良の無人機を見つけた後、消費者はその注文をRabbitMQの無人機待ち行列に挿入する。消費者はこのプロセス中にmysqlデータベースに問い合わせを行います。
    5. 無人機は無料であるたびに、システムと通信して次の注文を求めます。システムは無人機のRabbitMQキューを調べ、そこから次の順序を取る。

      1. はそれが最高のドローンを決定するアルゴリズムを持っています私の例では、消費者がそれにロジックを持っていることをOKです:

      私の質問は、消費者と生産に関連していますこれを行うには、無人機の位置を取得するためにmysqlと話をする必要がありますか?これは良い練習ですか?どうすれば違うのですか?

    6. 消費者がアプリケーションに留まるのがベストプラクティスですか?現在、コンシューマはWebサービスと同じサーバー上で実行されており、コードはWebサービスコードから分離されていません。将来、別のサーバーでコンシューマーを移動する必要があるかもしれないと私は考えていますか?消費者がアプリケーションから簡単に分離できるように、どのように考えていますか?

    7. プロデューサーはアプリケーションにとどまっていなければならないと私は考えています。つまり、ウェブサービスアプリと結びついています。それは大丈夫ですか?

    申し訳ありませんが、長いポストと私の貧しい英語です。 ありがとうございました:)

  • 答えて

    0

    はい、コンシューマにはロジックが必要です。これは標準EIP routing patternです。

    ビジネスロジックレイヤーをデータアクセスレイヤーから適切に分離すると(キューアクセスはデータアクセスレイヤーです)、共通のプロジェクトを共有することはおそらく問題にはなりません。最終的には、ビジネスロジック/ドメインモデルをWebサービスとルータ/コンシューマから分離したいと思うかもしれませんが、それははるかに展開とパッケージングの懸案事項です。

    Webサービスコードをビジネスロジックから守っている限り(またその逆もあります)、おそらく大丈夫でしょう。すべてを何度も展開し、関連するエンドポイントだけを公開する必要があります任意の配備。あなたは実際に懸念を混ぜ合わせないようにするため、ライブラリを使ってレイヤーを分割すると、最終的にもっと幸せになるかもしれません。

    はい、プロデューサをWebサービスとともにデプロイする必要があります。データアクセスレイヤーとして認識されていることを確認してください。そのレイヤーは別のパッケージ/クラスにあります。テストがはるかに簡単になります。

    +0

    ありがとうございました、今はすべてがより明確です。 –

    関連する問題