延迟与解耦架构建议答案

【问题标题】：Latency vs decoupling architecture advice延迟与解耦架构建议
【发布时间】：2012-09-20 21:21:43
【问题描述】：

我正在设计系统架构。（Java EE/Spring）

这个系统的主要因素是低延迟。（从端到端谈论大约 1 ms 和更少）

我们已经为这个实时系统计划了几个组件。

我向各位专家提出的问题：我知道耦合和解耦的所有优点（故障转移、分离、维护、扩展等）

我在这里面临的问题是：

例如，假设我在机器 A(app1) 和机器 B(app2) 上有两个不同的应用程序。

一个请求必须通过两台机器。两台机器都处理完请求后，最终的答案将发送给客户端。

这两者之间的集成延迟肯定会比在同一台机器下拥有这些应用程序（网络时间等）更高。

另一方面，我可以独立更新和维护每个应用程序，而无需依赖同一台机器。故障转移、集群、负载平衡也是如此

你有什么建议？我应该考虑什么？延迟与解耦和维护

谢谢，射线。

【问题讨论】：

【解决方案1】：

一个请求必须通过两台机器。两台机器都处理完请求后，最终的答案将发送给客户端。

它可能会增加 0.1 到 0.2 毫秒。这可能是可以接受的。

另一方面，我可以独立更新和维护每个应用程序，而无需依赖同一台机器。

您更可能更新软件而不是硬件。 Hadrware 通常可以在周末等非高峰时间更新。s

故障转移也是如此，

您拥有的机器越多，您的故障点就越多。

聚类

如果您在一台机器上拥有所有集群，则可能不需要集群。

负载均衡

如果您需要使用多台机器，这更有意义。

如果您有一个 Web 应用程序，1 毫秒是相当激进的目标。如果您有网络服务，例如交易系统，则可以根据您的要求实现亚毫秒甚至不到 100 微秒。

【讨论】：

我在谈论试图实现微秒延迟的交易系统方向。在拥有一台以上机器时可以实现吗？你会推荐什么？两者（或更多）之间的网络集成是否应该相当大？（我说的是更新软件然后是硬件）
当我开发一个典型延迟为 80 微的交易系统时（从市场数据进入我们的网络到交易离开），机器之间的网络延迟为 100 微，所以它不是选项。 Infiniband + Java 7 可能比我们拥有的以太网更好。
彼得，你能告诉我你是基于哪种配置来获得这些延迟速度的吗？应用服务器？硬件？谢谢。
我使用 Karaf+iPOJO 作为轻量级 OSGI 容器，否则纯 Java SE 6（现在将使用 7）最小化网络、锁、线程或 GC。当我讨论您可能面临的许多问题时，您可能会发现我的博客很有趣。 vanillajava.blogspot.co.uk
感谢您的链接。我肯定会跟随他们。您对涉及延迟方式的 Spring（在独立环境上）等应用服务器有何看法？它将如何影响我的目标？

【解决方案2】：

处理相同请求的机器越多，延迟就越多 - 这是显而易见的。此外，消除应用程序之间的所有边界 - JVM、线程，并将它们实现为在同一线程上按顺序调用的 2 个过程。

在一种情况下，更多的机器可以减少延迟：在一台机器上分配负载等以释放资源（处理器），以消除拥塞。让不同的工具（货币、股票）在不同的机器上交易。

【讨论】：