17年，中国互联网技术走出国门【腾讯篇】

要说哪些公司代表了中国互联网技术的前沿，估计大多数人都会脱口而出：BAT（百度、阿里、腾讯）。中国互联网发展20多年，经历了QQ、游戏、微信红包、双11等等亿万级访问事件的洗礼，已经走到了世界技术前沿。著名技术媒体InfoQ中国CEO KevinHuo的一句话道出了今天中国互联网技术水平的变化“我们不仅有In，还要有Out（输出）”。

Kevin说的“Out”，就是指中国顶尖互联网企业在美国旧金山的【China Tech Day】向全球同行分享技术成果的盛事。作为全球最大的社交平台之一，腾讯拿出了引以为傲的看家本领：海量服务之道2.0

作为世界级技术大会，爆满那是必须的

负责本次分享的是腾讯社交事业群后台高级技术总监Bisonliao/廖念波。作为一个在腾讯潜心研究10年技术，掌握十亿级核心系统的OS、服务集群、海量存储全能技术专家，在大会上会给老外show什么看家本领？这本身就是一个有趣的话题。

腾讯的海量服务之道

柔性可用

Bison在会上再次回顾了“柔性可用”的老话题，他认为，在移动互联网时候，柔性就是退而求其次，不要刚性的依赖某个环节或者特性。在产品特性方面，当不能提供最完美服务的时候，退而求其次的进行降级，提供可替代的不那么完美的服务。例如QQ服务中的好友列表展现，如果拉不到好友备注，就展现昵称；或者是当资源有限，而多个产品特性存在资源争用时，停掉优先级不高的特性，保证优先级高的特性。

例如当内网或者外网带宽存在瓶颈的时候，关闭发送图片/文件这样的通信能力，保证文本消息的通信能力；在技术实现方面，某一个业务流程可能包含多个环节，有的环节是关键的，有的环节是非关键的。对于非关键环节，如果处理失败了，可以评估是否忽略该环节以继续后续流程。

例如加好友业务流程，其中包括 “询问安全模块是否恶意”、“询问数据挖掘模块如何给用户推荐智能备注”等非关键环节，如果这些环节的模块因为网络等原因故障了，那么加好友流程应该忽略这里的失败，继续后续环节。

柔性可用需要服务的运营是精细化且尽在掌握的。以前面的带宽瓶颈的危机为例，如果服务方能对各种特性按重要性分级（登录>文本消息>图片消息>好友状态呈现>键盘活动提示），那么我们可以视危机情况按重要性停掉低级别的特性；这也要求各个特性间的实现要解耦和独立，不能出现停掉某个特性而影响高级别的特性的情况。

在错综复杂的网络拓扑、部署架构和调用关系间，服务方要能清楚的知道某个资源有哪些业务在争用，例如某条内网专线上跑了那几个特性的流量？分别是多少Gbps？电力资源出现瓶颈时，如果需要停掉某个机架能否第一时间快速的给出受到影响的模块以及他们的容灾情况，进而预见哪些业务特性会受到影响？

柔性逻辑需要健壮且自动的柔性和实际演练。例如在QQ登录流程中，如何判断后端某个非关键模块故障了？ 一个鲁棒且简单的设计是：请求超时或者系统错误的时候，重试一次，如果重试还失败，那就跳过该环节。这个设计简单、健壮，且可以认为时刻都在被验证，因为每一分钟都会有一定的网络正常超时出现，这个机制不断在被验证。

柔性逻辑一定要尽量自动化生效，不可以依靠人工来打开柔性开关的方式。因为故障随时可能出现，一旦出现，通过人工配置开关生效的方式时间会导致服务影响时间很长，同时也可能会出现误操作或操作不熟导致更大问题。如果不能做到自动化生效，那么柔性策略需要定期的演练，加以验证。

柔性可用要求对模块远程调用设置合理的超时时间。模块间调用的超时时间如果设置不合理，会导致柔性策略失效，如：A调用B是300ms超时，B调用C是500ms超时；B对C有柔性，调用C超时的时候会柔性的继续后续环节，但是在这个场景里等B成功应答A的时候，A已经超时了，柔性没有起到任何作用。如果B还需要调用D、E模块，整个流程会更加复杂，这种场景需要业务对整体流程环节拓扑以及梳理关键/非关键环节以确保可用性，同时要能够有方法演习检测（如通过工具注入模拟后端调用高延时）。

柔性可用要求在远程调用失败时要进行有节制的重试。重试是柔性可用会用到的策略，但是简单的无节制向后端重试也会引发雪崩加剧后端压力。通过频率限制或者成功率限制可以保证合理且有重试，并且最好能对重试逻辑进行组件化。

安民告示

安民告示看似是一个非常“没技术含量”的点，但在bison眼里，他一直在强调安民告示对一个亿级系统的重要性。什么是安民告示？它指的是某个服务/app在发生重大故障的时候，在独立于通常业务的IT设施之外，有一个可以直达用户的通道，告诉用户发生了什么事情。

安民告示的不可替代性，在于其他渠道如微博容易以讹传讹，假消息淹没真消息；客服在重大故障的时候，已经被打爆了，或者用户也不知道该怎么联系客服，或者知道客服电话也懒得打；新闻发布会太慢触达面有限。

安民告示同时能够避免用户恐慌和误解，达到安抚和降级的作用；能够避免对手故意炒作和抹黑；能够缓解运维开发同事修复故障的时候的压力，使得工作进展更顺利；能够给避免用户盲目重试从而导致后台服务过载。

安民告示的部署和实现要具备下述特性：

1、独立性。安民告示系统需要与业务IT的基础设施解耦，要做到业务IT基础设施（网络、服务器、机房）故障的情况下，安民告示系统还可用。不能因为业务的变更和升级，导致安民告示系统的不稳定。

2、健壮性。安民告示系统应该尽量的简单、多分布，保证健壮性，比如就是一个简单的http静态页面。

3、自动化。安民告示系统不要设计为有个配置开关然后等故障的时候人工去打开，因为在出现故障的时候一般不记得有这个开关，另外记起来了，也可能找不到那个开关，因为系统太多，又经年不用，没有人记得这个开关如何设置，更何况是在出现故障压力很大的情况下。具体到互联网服务，可以做一个app，装在关键运维人员的手机上，后台一旦发现有问题，就推送提示到app，强请示要不要发安民告示，运维人员一键完成安民告示提醒。整个流程需要定期演习。

Crash应对

Crash几乎是移动开发无法避免的问题，亿级装机时的app cash可以是很可怕的。从纯粹开发的角度来看，crash通常比较难以规避，且定位困难；从后台服务的角度，crash甚至可能导致整个服务不可用。在开发过程用中一些防止crash出现的措施如加强防御性编程，并且使用protocol buffer等比较成熟的IDL工具；代码充分测试，且不允许用公共服务的正式环境进行测试；对于跨部门的服务调用，需要加强部门间信息的同步。

除此之外，腾讯进一步在进程监控和快速拉起以及轻重分离部署上降低了crash产生的危害。快速拉起组件会在服务crash的时候会捕获信号并保存栈信息用于开发者查找问题，然后在毫秒级内快速拉起进程；轻重分离部署强调了公共服务进行分set部署，每个set对应一组不同的调用者，就像防火帘一样隔离重要的服务以及不重要的服务，保证互相不受影响。

过载保护

Bison在演讲中强调，过载保护关注的是在请求量超过服务最大处理能力的场景下对服务本身的保护。过载保护最重要的一点，不是说要加强系统性能、容量，成功应答所有请求，而是保证在高压下，系统的服务能力不要陡降到0，而是顽强的对外展现最大有效处理能力。这里需要注意的是，通常来说系统服务能力抖降到0的原因是由于系统接收缓冲区满等原因，导致系统接受以及处理请求的总体耗时超过了前端用户的请求超时时间，此时系统所有的计算能力都是在做无用功。过载保护需要系统做到下述方面：

1、每个系统要做好自我保护，量力而为，而不是尽力而为。对于超出自己处理能力范围的请求，要勇于拒绝；每个系统要有能力发现哪些是有效（尚未超时）的请求，哪些是无效（前端已经判定超时）的请求，该拒绝的请求（超出整个系统处理能力范围的或已经超时的无效请求）越早拒绝越好。就像上海机场到市区的高速上，刚出机场就有电子公示牌显示，进入市区某某路段拥堵，请绕行；

2、前端系统有保护后端系统的义务，SLA中承诺多大的能力，就只给到后端多大的压力。这就要求每一个前后端接口的地方，都有明确的负载约定，一环扣一环。对于后端系统的重试机制，需要有节制。

3、对于用户的重试行为，要适当的延缓。例如登录发现后端响应失败，再重新展现登录页面前，可以适当延时几秒钟，并展现进度条等友好界面。当多次重试还失败的情况下，要通过其他途径安抚用户，如安民告示；在产品特性设计和发布上，要尽量避免某个时刻导致大量用户集体触发某些请求的设计。

从In到Out的历史意义

事实上，根据腾讯对外技术分享窗口腾讯大讲堂宣传的资料，海量服务之道2.0远不止以上四点，中国的互联网企业技术实力，也远不止会上几个专家讲师所能涵盖，但透过china tech day，我们看到的一个重大转变是，中国已经首次从纯粹的技术输入国，转变成有进有出的技术强国。