0

我的并不是一个真正的问题，它更多的是征求意见 - 也许这甚至不是发布它的正确位置。不过，这里的社区消息灵通，尝试一下也无妨……

我正在考虑如何创建一个高度可扩展的，尤其是高度模块化的后端架构。例如，一个大型站点的整个后端生态系统，它有可能在未来发展成一个大型站点。

这将需要非常高度的关注点分离，以至于不仅可以（例如）替换底层数据库（即从 Oracle 到 MySQL），而且可以替换实际类型的数据库（ed SQL 到 KV，或反之亦然）。

我设想每个子系统在后端生态系统中公开自己的 API 的情况。通过这种方式，API 可以保持不变，而实现可能会随着时间而改变（甚至是根本性的）。

系统必须是异构的，因为它不依赖于特定的语言。它必须能够容纳使用不同语言的模块或整个子系统。

然后我突然想到，我想象的只是网络本身的架构。

所以这是我的讨论点：除了使用（主要）基于文本的协议的开销之外，是否有任何压倒一切的原因不应该以我描述的方式实现复杂的后端架构，或者我是否有一些强有力的理由使用 Twisted、AMQP、Thrift 等通信协议时缺少 m？

更新：在@meagar 发表评论之后，我或许应该重新提出这个问题：使用非常简单、灵活且易于理解的架构（即所有功能公开为一系列 RESTful API）的明显优势是否足以弥补明显的性能损失在后端上下文中使用此架构时会发生什么？

4

1 回答 1

0

[code]可以替换数据库的实际类型（将 SQL 转换为 KV，反之亦然）。[/code]

任何在两个表之间编写连接的人都会感到难过。如果您希望“能力”切换到 KV，那么您不应该公开比 KV 支持的 API 更丰富的 API。

您的问题的答案取决于您要完成的工作。您希望将每个模块保持在合理的范围内。使用适当的代码物理分层，使用带有副作用契约的定义接口，为每个接口的每个成功和失败案例使用测试用例。这样，您可以依赖诸如“当用户进入 blah 页面时，会生成一个 user-blah 事实，以便调用所有已注册的事实侦听器”之类的内容。这允许您扩展系统，而无需从 A 点直接调用到 B 点，同时仍然可以对广泛不同的依赖项进行某种控制。（我讨厌无法找到所有可能的符号引用的代码库！）

然而，我们将大量代码和类放入单个系统的事实是因为系统之间的调用通常非常非常昂贵。您想根据代码模块在可能的情况下相互发出请求来思考。函数调用和 REST 调用之间的时间差异大约是一到一百万（如果你只计算周期而不是挂钟时间，也许你可以把它低至一到一万——但我不是这样当然）。此外，数据中心中的任何线路上的任何东西都可能遭受数据包丢失的影响，因为无论您如何努力，都没有 100% 无损数据中心这样的东西。数据包丢失意味着应用程序响应时间中的随机延迟峰值。

于 2011-01-02T06:36:55.507 回答