领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
专家观点：QCon专访朱念洋，谈腾讯开放平台关键技术
作者 朱念洋 发布于 2011年11月16日
朱念洋，腾讯开放平台部技术专家，现负责开放平台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这里，目前看到的几点是：
- 提供更加丰富的业务OpenAPI，将各个平台的功能全部都开放出来给应用使用
- 提供更多的支持类OpenAPI，如存储API，告警API，反外挂等，降低应用的开发、运维成本
- 提高OpenAPI本身的可用性，优化OpenAPI的性能
InfoQ:对于从事开放平台的开发人员，你有哪些建议？
OpenAPI所面向的对象是应用开发者，这和传统互联网服务直面用户是有很大差别的。
所以一定要先站在这个前提下，很多问题才能想的明白。
而对于OpenAPI设计本身，还是回到之前提到的安全性、可用性、易用性。
对于安全性这里，一定要从整体考虑，因为OpenAPI是一整个体系，一旦某一个地方有漏洞，整个体系都会有被洞穿的危险。
可用性永远是OpenAPI的重要指标，所以在架构和开发中就要考虑OpenAPI的性能和容灾问题，并建立各种告警机制来保证对OpenAPI的服务运行情况了如指掌。
而易用性不用多说了，因为OpenAPI面对的是开发者，所以必须要考虑别人在使用时的易用程度。
注：InfoQ中文站欢迎优质的内容，提供原创稿件和写作意向的读者请发邮件至cuikang[at]infoq.com。
挺好
发表人
ren tian
发表于
勘误
发表人
黄 雯
发表于
Re: 勘误
发表人
崔 康
发表于
3 条回复
关注此讨论 回复