2017-04-09 10 views
-1

내 석사 학위 최종 프로젝트에서 무인 항공기 인도 시스템을 설계하기로 결정했습니다. 주요 목적은 복잡한 시스템을 설계하는 방법을 배우는 것입니다. ,소프트웨어 아키텍처의 관점에서 어떻게 전달 시스템을 설계합니까?

  1. 사용자가 상인의 온라인 상점에가는 제품을 선택하고, "드론 배달"로 전달 방법을 선택하고 자신의 배달 위치를 선택 :

    기본 사용 사례

    이있다.
  2. 판매자 웹 사이트는 새로운 무전기 주문을 등록하기 위해 무인 항공 시스템 (DDS) 애플리케이션에 API 호출을합니다 (주문에는 필요한 모든 정보가 포함됩니다 : 소포 픽업 위치 및 목적지 위치 ...)
  3. Drones 위치를 기반으로하고 알고리즘을 기반으로하는 DDS 응용 프로그램은 최단 시간에이 무모를 제공 할 수있는 무인 장치를 계산하고 표시합니다.
  4. 선택한 무인 항공기가 무료 인 경우 주문을 배달합니다.

지금까지는 그렇게 좋았습니다. 내 질문은이 시스템의 소프트웨어 아키텍처와 관련이 있습니다. 몇 가지 일반적인 질문과 몇 가지 구체적인 질문이 있습니다.

일반적인 질문 :

  • 어떻게 확장 성하기 위해이 같은 시스템을 설계합니까? 내 말은 : 시스템이 5 월 상인에 의해 사용될 수 있습니다. 동일한 주문으로 100 건의 주문에 API가 부딪혔다면 시스템에서이를 처리 할 수 ​​있어야합니다.
  • 이와 같은 시스템을 설계 할 때 좋은 디자인 원리 또는 패턴은 무엇입니까?

구체적인 질문 :

시스템 구성 요소 :

  1. 자바 (봄) 응용 프로그램
    • 나머지 웹 servce

    • 지금까지 나는이 아키텍처를 내놓았다있다
    • dorens 및 parces
    • RabbitMQ
  2. MySQL 서버
  3. RabbitMq

시스템 흐름에 대한

  • 생산자/소비자 라우팅 드론에 대한
  • 탈취 논리와 알고리즘 :

    1. 상인 주문을 등록하기 위해 REST API를 누르십시오.
    2. 자바 애플리케이션은 주문을 MySQL 데이터베이스에 저장합니다.
    3. 데이터베이스에 주문을 저장 한 후 생산자가 RabbitMQ의 대기열에 주문을 넣습니다.
    4. 소비자가 RabbitMQ 주문 대기열을 사용합니다. 그것은 각 순서를 취하고 배달에 가장 좋은 시간을 제공하는 무인 항공기를 알고리즘을 기반으로 계산합니다. 각 무인 항공기는 RabbitMQ에 별도의 대기열을 가지고 있습니다. 최고의 무인 항공기를 찾은 후 소비자는 RabbitMQ의 무인 항공기 대기열에 주문을 삽입합니다. 소비자는 또한이 과정에서 mysql 데이터베이스를 조사한다.
    5. 무인 항공기가 비어있을 때마다 시스템과 통신하여 다음 주문을 요청합니다. 시스템은 무인 항공기 RabbitMQ 대기열을보고 다음 순서대로 진행합니다.

      1. 가 최고의 무인 항공기를 결정하는 알고리즘을해야합니다 내 예에서, 소비자가 그 안에 논리를 가지고 있음을 확인인가 :

      내 질문은 소비자와 생산자 관련이 있습니다 , 이렇게하려면 무언가 위치를 검색하기 위해 mysql과 대화해야한다. 이것은 좋은 습관입니까? 내가 어떻게 다르게 할 수 있지 않으면?

    6. 소비자가 응용 프로그램을 사용하는 것이 가장 좋습니다. 현재 소비자는 웹 서비스와 동일한 서버에서 실행되고 있으며 코드는 웹 서비스 코드와 분리되어 있지 않습니다. 앞으로는 별도의 서버에서 소비자를 이동해야 할 수도 있습니다. 소비자가 응용 프로그램에서 쉽게 분리 될 수 있다고 어떻게 생각합니까?

    7. 제작자가 응용 프로그램에 있어야한다고 생각합니다. 웹 서비스 앱과 결합되어 있습니다. 그 확인은?

    오랜 게시와 불쌍한 영어. 죄송합니다. 대단히 감사합니다.

  • 답변

    0

    예, 소비자는 로직을 가지고 있어야합니다. 이것은 표준 EIP routing pattern입니다.

    비즈니스 로직 계층을 데이터 액세스 계층과 적절히 구분하면 (큐 액세스는 데이터 액세스 계층입니다), 모두 공통 프로젝트를 공유하는 데 문제가되지 않을 수도 있습니다. 궁극적으로 비즈니스 로직/도메인 모델을 웹 서비스 및 라우터/소비자와 분리하려고하지만 이는 배포 및 패키징에 대한 더 많은 우려입니다.

    비즈니스 로직에서 웹 서비스 코드를 유지하고 (그 반대의 경우도 마찬가지) 오랫동안 모든 작업을 여러 번 배포해야하며, 관련성이 높은 끝점 만 노출하면됩니다. 주어진 배포. 라이브러리를 통해 레이어를 분리하는 경우 궁극적으로 더 행복 할 수 있습니다. 실제로 레이어를 혼합하지 않아도됩니다.

    예, 제작자는 웹 서비스와 함께 배포해야합니다. 데이터 액세스 레이어로 별도의 패키지/클래스에 있다는 것을 알고 있어야합니다. 테스트가 훨씬 쉬워 질 것입니다.

    +0

    감사합니다. 이제 모든 것이 더 명확합니다. –