【问题标题】：What's an acceptable latency for service/message bus服务/消息总线可接受的延迟是多少
【发布时间】：2016-02-19 18:12:45
【问题描述】：
我正在开发一个简单的 RPC 样式消息总线，其中微服务将存在于不同的虚拟机上。
我只是在 EC2 上为 RabbitMQ、服务器和客户端使用 c4.large 实例测试一个简单的概念证明。
我注意到往返服务器的往返时间约为 100 毫秒，其中约 20 毫秒用于连接到 amqp 服务器，另外约 80 毫秒用于返回一个简单的字符串。
每个 RPC 请求的开销为 100 毫秒，这似乎相当高。这种架构风格是否存在典型的可接受延迟？我应该看看不同的工具吗？
【问题讨论】：
标签：
amazon-ec2
architecture
rabbitmq
latency
microservices
【解决方案1】：
消息总线通常用于支持异步处理的应用程序。一个非常简单的例子是发送电子邮件以响应应用程序中发生的状态变化。
在这方面，100ms 是相当快的。
如果您试图在应用程序中保持快速同步操作，您不会对将消息总线作为其中的一部分感到满意。
请注意，上面的语句是指外部消息总线。进程内消息传递机制可以以更少的延迟构建，但这可能不是您在微服务架构上下文中所需要的。
我应该看看不同的工具吗？
不，您有适合微服务架构的工具。但是您应该问自己以下问题：
- 微服务架构是我的应用程序的正确选择吗？
- 如果是，我是否有合适的服务边界？