作者：robot_test_boy
链接：https://www.jianshu.com/p/65176b8c727a
当服务达到了重试次数的上限或者不能对请求发起重试时，开发者可以接纳这个失败结果或者寻找其它后备方案：优雅降级、缓存、功能冗余和桩数据。
1．优雅降级
如果market-data服务出现故障，应用就不再能为终端客户提供评估的价格数据了。为了解决这个问题，应该设计一个可接受的服务降级方案。比如，只展示持有股份数，而不显示估值。这样的话，虽然界面信息有所减少，但是至少要比什么都不显示或者显示错误信息要好一些。在其他领域，比如，电商网站即便在订单派送功能出现问题的情况下，用户仍然可以购买需要的商品。
2．缓存
或者，可以将之前查询的价格数据结果缓存起来，从而减少对market-data服务的查询需要。假定每只股票的价格数据有5分钟的有效期。如果这样的话，holding服务就可以将价格数据缓存5分钟，holding服务可以使用本地缓存，也可以使用单独的缓存系统（如Memcached或者Redis）。这个方案不仅能够提升性能，还可以在遇到临时故障时作为备用以防万一。
3．功能冗余
同样，也可以借助于其他服务来完成同样的功能。设想一下，公司可以从很多来源购买市场数据，每个数据源覆盖的证券票据种类有所不同，需要付出的成本也不同。如果A数据源出现了故障，我们可以向B数据源发起请求来代替。
在一个系统中，存在功能冗余有很多驱动因素：外部整合、结果相似但是性能特征不同的算法，甚至于已经废弃但是还在继续运行的老的功能。在全球的分布式部署中，开发者甚至可以借助于其他区域（region）的服务作为后备方案。微信搜索公众号：Linux技术迷，回复：linux 领取资料 。
只有某些故障场景才能使用替代服务。如果故障的原因是原服务存在代码缺陷或者资源过载，那么将请求重新路由到另一个服务是合理的。但是如果是出现了网络故障，可能就无法使用替代服务了。因为一般情况下，网络故障会影响到多个服务，其中就可能包括想要重新路由过去的服务。
4．桩数据
尽管在当前这个具体的场景中桩数据方案并不合适，但是我们可以在其他一些场景中用桩数据作为后备方案。想象一下亚马逊的“向开发者推荐”模块：如果由于某些原因后端不能获取到个性化的推荐信息，那么这时使用一组非个性化的数据作为备用要比在界面上显示一块空白优雅得多。
--完-- 读到这里说明你喜欢本公众号的文章，欢迎 置顶（标星）本公众号 架构师指南，这样就可以第一时间获取推送了~ 在本公众号 架构师指南，后台回复：架构师，领取2T学习资料 ！ 推荐阅读 1. 后端架构师技术大全（69个点） 2. 架构师如何设计权限系统？ 3. 我怎么才能成为一个架构师 ？ 4. 架构师从0搭建一套订单系统！
本篇文章来源于微信公众号:程序IT圈
原创文章，作者：software，如若转载，请注明出处：https://www.sldh123.com/7338.html
