具有负载平衡的REST服务

我一直在考虑REST服务的优点,整个无状态和会话亲和力"东西".令我印象深刻的是,如果您的基础架构中的许多计算机上有多个部署的服务版本,并且它们都在给定资源上运行,那么该资源的状态存储在哪里？

在基础设施中使用分布式缓存的单个主机,以及在服务内部进行更改的任何状态,它只是获取/放入缓存是否有意义？这将允许任何数量的已部署服务用于加载平衡原因,所有服务都看到相同的资源状态视图.

如果您正在设计一个高负载系统(通常意味着高可靠性),那么单点故障绝不是一个好主意.如果提供一致视图的服务出现故障,那么最好不要随着数据库查询所有内容而大幅降低性能,最坏的情况是整个应用程序停止工作.

在你的问题中,你似乎担心一致性.如果要了解有关eBay架构的信息,那就是在可用性/冗余/性能与一致性之间进行权衡.您可能会发现不需要100%的一致性,您可以稍微"混乱".

分布式缓存(如内存缓存)可用作分布式哈希表的后备,后者已广泛用于创建可扩展的基础架构.如果正确实现,缓存可能是多余的,缓存可以动态加入和离开环.

REST本身也是可缓存的,因为可以通过适当使用头(ETag)和软件(例如Squid代理作为反向代理)来缓存HTTP层.通过标头指定缓存的一个缺点是它依赖于客户端解释并尊重它们.

然而,用Phil Karlton的话来说,缓存很难.您必须对缓存的数据,缓存数据以及如何使缓存无效进行选择.无效可以通过以下方式完成:

通过基于计时器的方法(缓存2分钟,然后重新加载)

更新进入时,使包含相关数据的所有缓存无效.

我偏向基于计时器的方法,因为它更容易实现,你可以相对确定地说系统中存在多长时间的数据(例如,公司详细信息将在2小时内更新,股票价格将在10秒内更新) .

最后,高负载还取决于您的使用情况,并且根据交易量,这可能不适用.方法(如果您愿意)可能如下:

确保系统在没有缓存的情况下正常运行(是否有效)

它是否符合性能标准(例如请求/秒,正常运行时间目标)

优化瓶颈

在需要时实现缓存

毕竟,您可能首先没有性能问题,并且您可以使用单个数据库和良好的备份策略.

我认为负载均衡Web应用程序的传统观点是,您可以在多个应用程序服务器上使用REST服务,并从单个数据库服务器检索资源数据.

但是,通过使用超媒体,REST服务可以轻松地对应用程序进行垂直分区,以便某些资源来自一个服务,而另一些来自不同服务器上的另一个服务.这将允许您在某种程度上扩展,具体取决于您的域,而不具有单个数据存储.显然,使用REST,您将无法跨这些服务进行事务更新,但确实存在这种分区很有价值的情况.

如果您正在寻找需要真正扩展的架构,那么在尝试解决分布式缓存的问题之前,我建议在CQS架构(视频)上查看Greg Young的内容.