mongodb - 每 x 秒/分钟发送和接收重复信息的架构

我使用一个移动应用程序，该应用程序每隔一定时间通过重复的 GET 请求发送数据（纬度/经度）；30 秒、1 分钟、5 分钟等，非常小的间隔，就像是一个 SENSOR，这个数据被发送到 Backend，收到请求的数据后，这个数据必须显示在屏幕上。

我的问题是，我当前的架构是面向服务的架构 (SOA)，所以我每次都发出一个 http 请求，问题是每秒/分钟有数百个用户和数百个请求。采用 SOA 是一个错误，对吗？

在寻找替代方案时，我遇到了一个事件驱动架构（event-driven architecture），这会是最好的吗？但它涉及微服务问题等。我落在这里，我没有很多知识......关于如何最好地处理它的任何建议或想法？SOA是个错误？我需要一些指导。

标签： mongodbspring-bootrestwebsocketarchitecture

我不会过多强调架构的名称，因为事件驱动架构意味着所有的通信都是通过系统中生成的事件发生的。在纸上很棒，但很难正确实施。

我的方法将松散地基于使用消息代理（kafka、rabbitmq 等）的微服务架构，其中一个服务接收 GPS 数据（可选地添加一些上下文信息、接收日期、设备 ID，...... ) 并将其发送给代理，以及处理 GPS 数据并将其保存到数据库（集群）的另一个服务。

孤立地讲，我所描述的类似于事件驱动的架构。服务是解耦的，它们通过事件进行交互，但由于这是您应用程序的一部分，因此对所有其他组件强制采用这种模式是不明智的。

一些可能对您有所帮助的提示：

先考虑部署；如果可以的话，使用容器。从 docker-compose 开始设置所有服务的单个实例，然后使用 docker swarm 对其进行扩展。这简化了处理微服务部署。
并非所有东西都必须是微服务。您可以逐个功能开始，并根据需要集成此模式。微服务、SOA、事件驱动比你盲目应用的模式更多的是建议。
拥抱异步通信，因为它可以帮助您处理可伸缩性（您可以更改/扩展通信的一部分而无需更改另一部分）和可靠性（更容易处理不可用的服务，处理峰值负载）。