专家观点：QCon 专访朱念洋，谈腾讯开放平台关键技术

朱念洋，腾讯开放平台部技术专家，现负责开放平台 OpenAPI 以及相关系统。主导开发了 OpenAPI，并曾参与设计开发了 QQ 空间、腾讯朋友的应用管理、AppStore 等系统。朱念洋在 QCon 杭州 2011 大会上做了名为《开放平台中的 OpenAPI 设计》的演讲，有关幻灯片可以在此下载。会后，InfoQ 中文站对其进行了采访。

InfoQ：腾讯在整合多个平台时，在 API 易用性方面做了哪些工作？

由于腾讯本身在多平台方面的特殊性，多平台 OpenAPI 统一在 OpenAPI 设计原则中占了很大的比重。可以想象一下，如果我们只是简单的将各个平台的数据开放给应用，而没有做任何整合，那么应用在接入腾讯朋友、QQ 空间、微博、Q+、QQGame 等平台都需要变更一次代码，这对应用开发者来说是非常大的成本。

所以针对这种情况，我们把多个平台的数据进行了整合，并达到了统一：

• 同样的 URL！
• 同样的参数、返回格式！
• 同样的调用地址！

举个例子：

• 获取个人信息: /user/info
• 获取用户签名: /user/emotion
• 获取好友列表: /relation/friends
• 是否好友: /relation/is_friend
• …

无论是在朋友还是在空间，当你需要获取个人资料的时候就只需要调用 /user/info，应用的程序不需要因为平台的不同而变更一行代码。

其实实现也是很简单，示意图如下：

当用户从平台进入应用的时候，平台会将一个参数 pf 传给应用，而应用之后在访问 OpenAPI 的时候只需要将 pf 原样传给 OpenAPI 就可以了。

所以整个做完了之后，我们真正实现了对应用开发者来说：

一点接入，多台全部上线，应用无需改动一行代码

InfoQ：内网 DNS 技术在可用性方面发挥了怎样的作用？

大家知道应用在访问 OpenAPI 的时候是通过公网访问的，所以一旦 OpenAPI 的某个机房出现问题时，怎样保证应用能快速切换访问就是个很严峻的问题。

用常规方法我们有几个选择：

• 域名 DNS 变更？
• 应用自己变更调用 IP？

对于第一个方案来说，外网域名 DNS 生效的时间本身就是非常慢的，所以在 DNS 生效之前，应用将在很长时间内处于不可服务状态。

而对于第二个方案，本身就不符合腾讯开放平台尽量降低第三方应用运维成本的原则，而且推动几万款应用去切换 IP 也是件不现实的事情。

那么到底如何解决呢？

考虑到大部分的应用是部署在腾讯提供的服务器上，所以我们针对性的研发了内网 DNS。

那么内网 DNS 有什么特点，能解决上面的问题呢？

• 即时生效
• 应用无感知
• 就近访问
• 安全性高

可以看到内网 DNS 解决了传统 DNS 的一些瓶颈，并且提供了更多的功能。

InfoQ：设计 API 时是否会遇到为了满足不同的需求而做出权衡的地方？如何解决？

我们在设计 OpenAPI 的时候，始终遵循着三个最基本的原则：

• 安全性
• 可用性
• 易用性

而这三个原则的重要程度又是从高到底排列。

所以当产品的需求与这三个原则发生冲突的时候，我们都会用这三个原则来进行取舍。

InfoQ：优秀的 OpenAPI 应该具备哪些特点？

正如我之前提到的，好的 OpenAPI 设计应该有如下原则：

• 安全性
• 可用性
• 易用性

我来简单描述一下：

安全性：

OpenAPI 是连接平台和应用之间的桥梁，这桥梁上流通的是什么呢？是用户的数据。所以 OpenAPI 直接维系着平台、应用、用户三方的数据，任何一方的数据对安全性要求都极其严格，并要求不能有一点疏漏，因此安全性必须作为首要考虑的前提。

可用性：

可用性是什么呢？就是 OpenAPI 能正常提供服务的能力，我们可以想象一下一旦 OpenAPI 出现问题将会带来什么样的后果：开放平台上的所有应用都获取不到好友关系，如果更坏一点，可能就是所有应用都支付不了，最差的情况可能就是所有应用都无法进入。所以 OpenAPI 的可用性要求是极高的，而我们在日常的 OpenAPI 运营中，考虑对 OpenAPI 优化最多的也就是他的可用性。

易用性：

OpenAPI 作为一个对外开放的接口，其易用性的程度直接决定了开发者接入开放平台的门槛，所以我们也必须要尽量高的提高 OpenAPI 的易用性。

InfoQ：“柔性服务”是什么概念？腾讯是如何实施的？

柔性服务是腾讯内部的一个名词，其实我稍作解释，相信大家都能在自己的工作中找到类似的影子。

比如一个人在沙漠里迷失了寻找水源，那么在他还能走的时候，就尽量走；实在走不动了，用爬的；最后爬也爬不了了，起码要保证自己活着。

所以我们针对互联网服务这里，总结出了一个原则：

在能容忍的最长时间内，将最重要的事做完

比如下图：

当我们执行到 3 的时候，发现 CGI 的运行时间已经太长了（比如超过 1 秒），那么为了避免其他请求被堵死，我们就直接返回给调用方了。这个时候虽然数据不是完整的（丢了 4 的数据），但是我们在数据完整和快速响应之间做了一个平衡。从而保证在服务出现问题的时候，大部分的应用还是可以正常使用，只是体验上稍微差一点。

但是仅仅做到这里还是不够的，我们刚才提到了能容忍的最长响应时间，但是这个最长响应时间的值怎么指定呢？

如果指定的很长，比如 1 秒，那么一旦出现问题的时候，相当于每个进程每秒钟只能处理一个请求，根本没有达到我们预期的容灾的效果。

但如果指定的很短，比如 20 毫秒，那么一旦出现一次偶然的网络波动，即使很快会恢复也会导致我们的 OpenAPI 大面积失败。

这两种设置方法都不完美，那么还有什么办法呢？

那就是 EMA 算法，腾讯之前将预测股票走势的 EMA 算法引入来预测 CGI 运行时间的变化，而 EMA 的一个核心原则就是：

当 CGI 运行时间越短的时候，给 CGI 设置的最长超时时间越长；当 CGI 运行时间越长的时候，给 CGI 设置的最长超时时间越短。

如下图所示：

可以看出平均响应时间和动态超时时间基本是沿响应时间上限对称的关系，很直观的描述了这两者之间的关系。

所以到此位置，柔性服务才能真正的发挥作用。

InfoQ：腾讯开放平台下一步有何发展规划？

对于 OpenAPI 这里，目前看到的几点是：

1. 提供更加丰富的业务 OpenAPI，将各个平台的功能全部都开放出来给应用使用
2. 提供更多的支持类 OpenAPI，如存储 API，告警 API，反外挂等，降低应用的开发、运维成本
3. 提高 OpenAPI 本身的可用性，优化 OpenAPI 的性能

InfoQ: 对于从事开放平台的开发人员，你有哪些建议？

OpenAPI 所面向的对象是应用开发者，这和传统互联网服务直面用户是有很大差别的。

所以一定要先站在这个前提下，很多问题才能想的明白。

而对于 OpenAPI 设计本身，还是回到之前提到的安全性、可用性、易用性。

对于安全性这里，一定要从整体考虑，因为 OpenAPI 是一整个体系，一旦某一个地方有漏洞，整个体系都会有被洞穿的危险。

可用性永远是 OpenAPI 的重要指标，所以在架构和开发中就要考虑 OpenAPI 的性能和容灾问题，并建立各种告警机制来保证对 OpenAPI 的服务运行情况了如指掌。

而易用性不用多说了，因为 OpenAPI 面对的是开发者，所以必须要考虑别人在使用时的易用程度。

注：InfoQ 中文站欢迎优质的内容，提供原创稿件和写作意向的读者请发邮件至 cuikang[at]infoq.com。