我在考虑如何创建高度可扩展的，最重要的是高度模块化的后端架构。例如，一个大型站点的整个后端生态系统，有可能在未来发展成为一个大型站点。
这将需要非常高度的关注点分离，以至于不仅可以（例如）替换底层数据库（即从Oracle到MySQL），而且可以替换数据库的实际类型可以替换（编辑SQL到KV，反之亦然）。
我设想每个子系统在后端生态系统中公开自己的API的情况。通过这种方式，API可以保持不变，而实现可能会随着时间的推移而发生变化（甚至是根本上）。
系统必须是异构的，因为它不依赖于特定的语言。它必须能够容纳使用不同语言的模块或整个子系统。
然后我想到我想象的只是网络本身的架构。
所以这是我的讨论要点：除了使用（主要）基于文本的协议的开销之外，还有任何压倒一切的原因，为什么复杂的后端架构不应该以我描述的方式实现，或者是否有一些强大的理由我没有使用Twisted，AMQP，Thrift等通信协议？
更新：在@meagar的评论之后，我应该重新提出这个问题：使用一个非常简单，灵活且易于理解的架构（即所有功能作为一系列RESTful API公开）的明显优势足以弥补在后端环境中使用这种架构会产生明显的性能损失吗？
答案 0 :(得分：0)
[code]可以替换实际的数据库类型（ed SQL to KV，反之亦然）。[/ code]
任何在两张桌子之间写下联接的人都会感到难过。如果您希望“能力”切换到KV，那么您不应该公开比KV可以支持的更丰富的API。
你的问题的答案取决于你想要完成的是什么。您希望将每个模块保持在合理的范围内。使用适当的代码物理分层，使用带有副作用契约的已定义接口，为每个接口的每个成功和失败案例使用测试用例。这样，您可以依赖诸如“当用户输入blah页面时，生成用户事实以便调用所有已注册的事实侦听器”之类的事情。这允许您扩展系统而无需从A点到B点的直接调用，同时仍然可以对广泛不同的依赖关系进行某种控制。 （我讨厌无法找到的代码库 - 所有所有对符号的可能引用！）
然而，我们将大量代码和类放入单个系统的事实是因为系统之间的调用通常非常非常昂贵。您希望根据代码模块来考虑彼此的请求。函数调用和REST调用之间的时间差异就像一百万到一百万（也许你可以得到它低至一万到一万，如果你只计算周期，而不是挂钟时间 - 但我不是这样的当然）。此外，数据中心线路上的任何内容都可能会丢失数据包，因为无论您如何努力，都无法实现100％无损数据中心。数据包丢失意味着应用程序响应时间的随机延迟峰值。