微信号:timyang_net

介绍:技术架构评论、技术生活、技术管理随想

面试题 - 为什么我的朋友圈不见了?

2014-12-25 15:07 TimYang

有如下一个场景,某个服务需要构建一个列表数据返回给调用方(调用方通常是客户端),服务本身是一个数据聚合器,它由内部多个远程服务的数据聚合而生成。在正常情况下,需要将所有内部服务的结果全获取成功后再返回。但是在一个大系统中,多个服务中某个服务出现不稳定的概率会比较大,当出现如图远程服务3不可用的时候,有3种不同的解决思路。


方案1:忽略出错的数据(图中数据3),直接返回数据1、2、4。

方案2:遇到任意失败,整个请求返回错误503 service unavailable。

方案3:忽略出错的数据(图中数据3),并告知调用方出错的范围,需要自定义的返回格式。如 {"load_date3_success": false}


如果你作为一个架构师,会选择哪种方案?


方案一类似架构设计里面常说的优雅降级,在出现问题情况下,除了数据3之外,其它数据可以正常返回,原理上可以将损失降低到最低。但会给用户体验带来一定伤害,并且用户在使用系统时候会存在不确定性的心理。


方案二比较依赖调用方的容错逻辑,如果调用方存在上一次缓存且容错处理得当,用户表面会感受不到这个异常,否则将会返回白页(最坏结果)。即使调用方有容错逻辑,但由于正常的数据不能及时返回,从工程师到用户可能不太容易接受这个结果。


方案三是一个看起来相对合理的方案,但是需要添加自定义的字段,本来这是一个标准的LIST返回,但是需要额外添加一些错误字段如 {"load_date3_success": false}来标识哪些数据返回失败了。同时在调用方也需要实现缓存及容错逻辑。这个方案从服务方到调用方的熵都增加了很多。


在大部分应用中,对于数据列表访问同时还存在未读数的功能,如下图中的小红点数字。如果这个未读数由另外一个API提供(假设这个API功能是正常的),情况就更复杂。如果不提供单独的未读数API,客户端则通常每次需要加载全量新数据才能算出未读数,即使在用户不展开列表的情况下,这样会带来访问速度的下降及客户端更多数据流量的消耗。因此大多数情况提供一个未读数API整体开销会更低。



这时候如果未读数都出来了,远程数据又取不到的情况下,你作为架构师,会选择何种方案?


想更多了解本文提到的相关架构


回复“19”了解影响在线服务的主要因素 - 在线服务的黑天鹅;

回复“13”了解如何通过容错设计实现99.99%可用性;

回复“12”了解分布式服务框架的4项特性;


本文是TimYang原创的有关架构、技术、开发等方面系列文章,可长按下方微信号复制及订阅


TimYang_net


 
猜您喜欢 [译] Python 3.5 协程原理 腾讯TMQ在线沙龙|腾讯手机管家iOS测试实战 这样管理团队,执行力一定杠杠的! 全球最强程序员在哪里? about云spark开发基础之Scala快餐