Asynchronous 设计用于同时为异步批处理和同步UI请求提供服务的微服务

我们有一个微服务（用Java编写），其目的是根据一组不同的业务规则验证请求，并将结果返回给源系统。我们在AWS上的ECS集群上的docker容器中运行此功能

目前，它是为批处理请求实现的，其中

批处理系统发布关于主题的SNS消息

SNS订户将消息发布到微服务的SQS队列中

微服务处理请求

Microservice发布关于另一主题的消息，并提供响应

SNS订户将响应发布到批处理系统的SQS队列

批处理系统处理响应

---

我们现在有了一个UI用例，可以在这个微服务中重用逻辑。在这种情况下，UI应该立即接收响应并向用户显示结果。如果UI（通过API网关）向microservice的SQS队列发布消息，我们无法保证及时响应，因为队列中可能有大量来自批处理系统的消息。我们应该为UI请求创建另一个微服务还是有其他方法？

您的微服务是

SQS->process->SQS

。为什么不为流程公开一个API<代码>HTTP请求->流程->HTTP响应。从基础架构的角度来看，这是一个好的实践吗？如果批处理和api都在同一个docker容器中运行，那么批处理可能会占用所有资源，从而影响UIT的性能。然后，它取决于（tm）如何实现队列读取器。是单线程的吗？具有固定线程池的多线程？它还取决于（tm）您对UI请求的要求-您将拥有多少？与批处理请求相比，每秒请求的perc95是多少？等等。我们正在ECS群集上运行该进程，该群集设置为最多自动缩放5个实例，即，我们最多同时处理5个请求（如果需要，我们可以增加）。AWS上自动缩放的问题在于它不是即时的。扩展可能需要15分钟，这对于UI响应来说是不可接受的。UI请求将来自外部用户。目前，我们还没有从用户界面上看到批量的迹象，但它们将明显低于批量，而且是零星的。我们预计批量会随着时间的推移而增加，我们希望能够在全天处理批量，同时仍然能够为用户界面提供服务。如能提供建议，我们将不胜感激