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

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

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

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

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

这样就很明白了,我们在调用获取个人信息接口失败是,返回ret=1即可。

但是这样是否足够了呢?
考虑一下,如果获取个人信息接口此时是超时,那么会导致整个CGI的返回变慢,从而导致接收进程挂死。此时虽然我们做了所谓的柔性服务,但是仍然是无法正常提供服务的。

怎么解决呢?我们需要一个能够动态调整超时时间的算法,当接口的响应时间远大于平常的平均值时,分配给接口的超时时间也要响应的调小。
伪编码如下:

那这里的动态调整算法使用什么呢?目前使用的是EMA来估算出下一时间点应当分配的超时时间,EMA一开始是用于股票的,后来公司的某大牛将其引入进来动态计算超时时间,大家可以google一下EMA的定义。

现在看来问题是解决了,但是这里会有一个比较大的限制,即:

但是万一就是有出现不符合这种限制的情况,该怎么办呢?其实也是有解决方法的,之前我们是只定义了一个g_CGITimeoutMng,他负责分配CGI的总处理时间,但是我们还可以再定义一个g_InterfaceTimeoutMng1,来动态调整某个接口的超时时间。
一般情况下我们仅需要对非关键接口加上这种单独的调整,并且取g_CGITimeoutMng.remainTime()和g_InterfaceTimeoutMng1.remainTime()中的较小值。
示例代码如下:

这样的话,基本就可以完美解决了。

再回来说一下第二种,即有循环调用的问题,其实要做柔性的主要原因也是因为如果不计算使用的时间而直接容错的话,会导致时间很长。
示例代码如下:

PS:

这样,服务才能做到真正的柔性可用。

暂无相关产品

4则回应给“关于柔性服务的一些实践和思考”

  1. hex nuts说道:

    什么叫柔性服务,能不能具体解释一下

    [回复]

    Dante 回复:

    嗯,其实可能不同的公司会有不同的名字,但是意思应该都是一样的,举个简单的例子,你登录QQ,可能这时候拉取会员等级的服务刮掉了,但是这不是关键路径,所以不能影响你正常登录QQ。而且不能因为获取不到会员等级就卡死在登录界面上,对于用户侧来看,就是容许有损的体验~

    [回复]

  2. hex nuts说道:

    原来是这样,那有没有其他的叫法

    [回复]

  3. guojing说道:

    总结的还是很有趣的,实际上,任何设计的时候都要考虑所为的柔韧性的。:)

    [回复]

发表评论