如何从软件架构的角度设计一个多元交付系统？

Question

对于我的硕士学位最终项目，我决定设计一个无人机传送系统。主要目的是学习设计复杂的系统。

基本用例是：

1. 用户进入商家网上商店，选择产品，选择送货方式为“无人机送货”并选择送货地点。
2. 商家网站，对我们的无人机传送系统（DDS）应用程序进行API调用以注册新的传送订单。（该订单将包含我们需要的所有信息：包裹提取位置和目的地位置......）< / LI>
3. 基于无人机位置的DDS应用程序，基于算法将计算并标记哪个无人机可以在最短的时间内交付此订单。
4. 所选的无人机何时免费提供订单。

到目前为止一切顺利。我的问题与该系统的软件架构有关。我有一些一般性问题和一些具体问题。

一般问题：

• 如何设计这样的系统以实现可扩展性？我的意思是：系统可能会被商家使用，如果他们在100个订单的同时点击我的API，系统必须能够处理它。
• 在设计这样的系统时有哪些好的设计原则或模式？

具体问题：
到目前为止，我已经提出了这种架构：

系统组件：

1. Java（Spring）应用程序
   • Rest web servce
   • 管理dorens和parces的网络界面
   • 用于路由无人机的逻辑和算法
   • RabbitMQ的生产者/消费者
2. Mysql Server
3. RabbitMq
   

系统流程：

1. 商家点击REST API注册订单
2. Java应用程序将订单保存到Mysql数据库。
3. 将订单保存到数据库后，生产者将订单放入RabbitMQ中的队列
4. 消费者使用RabbitMQ订单队列。它接受每个订单并根据算法计算提供最佳交付时间的无人机。每个无人机在RabbitMQ中都有一个单独的队列。在找到最好的无人机后，消费者在RabbitMQ中的无人机队列中插入订单。消费者还会在此过程中询问mysql数据库。
5. 每当无人机空闲时，它将与系统通信以请求下一个命令。系统将查看无人机RabbitMQ队列，并从那里获取下一个订单。

我的问题与消费者和制作人有关：

1. 消费者可以在其中使用逻辑，在我的示例中它将具有确定最佳无人机的算法，为此，它还需要与mysql通信，以检索无人机位置？这是一个好习惯吗？如果不是我怎么能做到不同？

2. 消费者留在申请中的最佳做法是什么？现在，消费者与Web服务在同一服务器上运行，并且代码未与Web服务代码分离。我想也许将来你可能需要将消费者转移到一个单独的服务器上？您认为消费者如何轻松地与应用程序分离？

3. 我认为制作人必须留在应用程序中，我的意思是与Web服务应用程序配合使用。那可以吗？

很抱歉这篇长篇文章，以及我的英语不好。 非常感谢你:)）

Answer 1

是的，消费者应该有逻辑。这是标准EIP routing pattern。

如果您正确地将业务逻辑层与数据访问层分开（您的队列访问是数据访问层），那么让它们共享一个共同项目可能不是问题。您最终可能希望将业务逻辑/域模型与Web服务和路由器/消费者分开，但这些更多是部署和打包问题。

只要您将Web服务代码保留在业务逻辑之外（反之亦然），您可能会没事，您只需要多次部署整个事物，并且只暴露与任何相关的端点。给定部署。如果你通过库分离你的图层，你最终可能会更开心，因为它实际上会强制执行不混合的问题。

是的，必须使用Web服务部署生产者，只需确保您知道它作为数据访问层，它位于单独的包/类中。它将使您的测试更容易。