标签归档:柔性服务

RSS feed of 柔性服务

最后更新于 .

前言:这是我最近在公司内部分享的一篇文章,大家反响比较强烈,所以也分享到博客里来。 一转眼,来公司已经三年多了。 这三年里,所属部门在变,地理位置在变,技术也日新月异,但是有很多设计原则却是一直不曾改变的,而这次就是我用自身的实践来谈谈我对其中的一个的理解---有损服务。 记得当年qwang用一个很形象的比喻来解释有损(原话记不太清楚了): 比如一个人在沙漠里迷失了寻找水源,那么在他还能走的时候,就尽量走;实在走不动了,用爬的;最后爬也爬不了了,起码要保证自己活着。 所以我们从这个比喻中起码可以获得如下几个信息:

  1. 问题时,优先保证关键功能
  2. 非关键功能不可以影响关键功能
  3. 在条件允许的情况下,损失越少越好

接下来就从自己印象比较深刻的有损服务项目讲起吧。

一、空间应用列表有损服务优化

想当年,苍井空还是处女,玛利亚还姓圣母。好吧,扯远了,想当年第一款国民级应用《QQ农场》横空出世,其空前的火爆导致空间个人中心应用列表的农场图标变得如此重要。 然而由于各种网络等各种原因,这个列表的展现总是会有一定的失败率,而且只要稍微失败就会招来大批用户的投诉。 我们分析一下这个模块的功能:

  • 正常功能:正常展示用户已经安装的应用列表
  • 关键功能:正常展示用户最关心的基础应用(如日志)、火爆游戏(农场)等的应用列表

于是优化开始了……

Step1. 应用信息本地cache

由于应用列表第一个要获取的就是应用自身的信息 ...

最后更新于 .

最近花了大力气在做openapi的优化,使其尽量柔性可用,借此也有些想法想和大家分享一下。 柔性服务,google一下,在网上并没有这样一个标准的概念,所以应该是公司自己取的一个名字。但是这种概念,相信大家都应该很容易能明白,即:

最大程度的保证关键服务的可用性

通俗点来说,一个人不能走路了,他起码可以说话,不能说话了,起码可以点头,头都不能点了,起码得能活着,即心脏还在跳动。这就是柔性。 对应互联网服务来说就是要实现两点:

1.要尽可能成功返回关键数据
2.要尽可能正常接收请求,不能堵死

笔者总结了一下,只要CGI满足其中一个或几个特点,就可以考虑使用柔性服务:

1.在整个CGI的执行过程中,存在关键路径和非关键路径
2.CGI中存在循环调用接口,导致执行时间不确定

我们分上面两种特点来看: 对于第一种,我们举一个简单的例子,比如有一个CGI,做了两件事情分别是:

1.验证登录态
2.获取用户信息

很明显可以看出,验证登录态这个接口是关键路径,而获取用户信息这个接口是非关键的。所以按照柔性服务的定义,当获取用户信息接口失败时,起码还应该返回登录成功。 但是这个时候毕竟还是要区分出完全成功和部分成功的,所以我们可以定义返回码如下(目前腾讯社区开放平台的openapi就是如下定义):

ret==0 ...