与有状态集群相比，REST的优势

我们都很容易讨论REST的伸缩性——我们可以添加节点来横向伸缩，因为没有状态——这意味着没有会话复制，没有会话关联等等

我的问题是：为什么即使在有状态的应用程序中，我们也不能通过集群实现这种扩展？我还要补充一点，我的重点只是扩展—我不担心节点故障会导致数据丢失或会话注销等—因此，我们可以说，我不需要任何会话复制/缓存

---

那么，与有状态的传统应用程序相比，无状态的RESTful应用程序有什么好处呢？毕竟，有状态的传统应用程序可以通过集群来帮助水平扩展？

这并不是说不能扩展有状态的应用程序，而是它更难扩展，而且更多的应用程序可能出错。为了共享状态，您必须在所有服务器之间引入更多的通信。使用无状态设计，您只需添加更多服务器，它们不需要彼此交谈，甚至不需要知道彼此。任何试图扩展关系数据库以确保所有节点之间数据一致性的人都可以证明所涉及的麻烦。

Hi Mulhall，感谢您的回复…但即使我不想让服务器共享任何状态信息（如会话），服务器之间是否应该相互通信？正如我在问题中所述-可用性不是我想要解决的约束…我真的不明白。如果他们不需要共享状态信息，他们之间的通信是什么？理想情况下，应用程序服务器不应该相互了解。这让你的生活轻松多了。您可以根据需要插入服务器，而不必更新负载平衡器之外的任何其他服务器。我的观点是：服务器应该共享会话等状态信息，以便在一个节点出现故障时，群集中的其他节点可以自由地为“故障”节点的用户提供请求，而不会丢失数据/事务。但是，如果我的要求不是实现这一点-即使用户由于某个节点崩溃而注销，我也可以-其他节点可以重新启动..那么，在这种情况下，REST与有状态相比有什么优势呢？REST主要允许系统持续很长时间而不改变底层传输协议。HTTP就是REST，多年来不需要更新HTTP（REST不是一个协议，而是一组架构约束，HTTP是遵循REST约束的协议）。所以实际上，当大多数人问REST给了我什么时，他们的意思是遵循HTTP协议给了我什么。它为您提供了一个可扩展和持久的系统，就像web一样。真正进化的是通过协议传输的内容类型（例如HTML->HTML4->XHTML->HTML5）。