《解密腾讯海量服务之道》讲座笔记

转自：https://baozh.github.io/2015-12/tencent-massive-service-discipline/

 

一直对腾讯作产品的能力比较敬佩的，咱们组作消息推送系统，而腾讯的信鸽就是咱们学习的榜样。京东不少作产品的思想是跟腾讯学的，而京东不少同事也从腾讯过来的(京东合并了腾讯电商)，耳濡目染学到不少东西。

前几天前腾讯的同事给咱们分享了《解密腾讯海量服务之道》，讲了几个腾讯开发产品的经验原则，比较受益，遂总结下。

2个价值技术观, 7个技术手段, 4个意识
腾讯的海量服务之道是由2个价值技术观和7个技术手段，4个意识组成。技术价值观是整体思想，意识是咱们的态度，技术手段是实现技术价值观的手段或者方法。

海量服务的技术价值观

有损服务

CAP理论
理论式系统基础理论CAP为分布式的应用提供了理基础:
C: Consistency，一致性；包括三种类型(强一致性，弱一致性，最终一致性)
A:Availability，可用性（主要指的是快速获取数据的能力，即性能）
P:tolerance of network Partition，分区容错性（亦包括可分布性）

**有损服务经历了3个阶段的演变: **

1. ACID事物保证阶段(金融，电信，石油，银行)
   特色：经过硬件中间件、数据库（支持事务）的层层事务保障，提供给用户非此即彼的服务结果，数据一致性优先于反应速度。
   缺点：系统冗余高，架构复杂，开发维护及运营成本很是高。

2. BASE理论阶段(电商)
   特色：BASE是Basically Available、Soft state、Eventually consistent三个词组的简写。经过牺牲【强一致性】，得到基本可用性和柔性可靠性并要求达到【最终一致性】
   缺点：牺牲部分一致性，只能保证最终一致性。

3. 有损服务阶段(UGC)
   特色：
   a.放弃绝对一致，追求速度极致；
   b.万有一失，让用户重试；
   c.伸缩调度，降级服务；

经过精心细分场景，选择牺牲一部分一致性、完整性，以达到经过较低的成本，可以支持海量服务需求，而且知足服务基本可用。

动态运营

核心思想就是敏捷迭代， 所谓小步快跑，对用户的需求快速反应。简而言之就是“快速求证对用户猜测”的过程。

许多伟人都说过相似的话：用户每每不知道真正想要什么，并且大可能是时间是拿来“试错”的。动态运营就是快速求证对用户猜测的过程，这个过程是创建在以”运营”为中心的设计开发验证模式。

海量服务的7个技术手段

容灾

互联网硬件容灾方案：

事故	容灾方法
光纤断/机房停电	异地部署
服务器硬件故障死机	热备
网络环境恶劣	异地部署就近服务
黑客攻击	DNS建设
程序core	自动拉起
服务雪崩	负载均衡、流量拥塞控制、频率控制

互联网业务逻辑层容灾

1. 独立逻辑的逻辑层，被接入层负载均衡调用。
   经过监控及时扩容，保证系统总体负载能力有冗余，一台服务器死机时，配置系统将其状态置为不可用，将其上的流量（平均）分给系统中其余服务器(s)上。

2. 分号段逻辑的逻辑层，每一个逻辑层只能处理指定号段的请求。
   n+n容灾：1对1容灾，比较奢侈，备份系统要么热备（平时负担50%请求）要么冷备（平时不工做，空跑），事故发生时，备机承担所有请求。
   n+1容灾：备机平时冷备，拥有全局号段路由表，任何一台主机死亡后，备机均可以转成死亡主机的角色，负责相应号段的逻辑工做。

互联网业务数据层容灾

1. 写惟一式同步 
   业务写请求只发给数据层主机，由主机采用快、慢同步结合的方式同步给各台备机。
2. 同时写式同步
   业务将写请求发给全部数据层服务器，获得全部/多数ack才算写完成。Yahoo的Zookeeper使用多数ack（如5台服务器有3+台ack）即成功的方式（读写都是），这种相似投票表决的方式被验证过能够严格保证数据一致性，也不用担忧惟一的主机写失败，可是实现比较复杂。

 

过载保护

在分布式集群系统中，某台设备故障，会形成系统总体的繁忙不可用；在作营销推广时，某个服务单元负载极大的现象会很快蔓延到其它服务单元，最终致使所有服务的不可用；用户群越大，系统规模越大，负载超限的状况扩散的就越快，最终会形成系统总体崩溃。上述现象在天然界用一个最直接的名词就是”雪崩”。

过载保护的四个方法:

1. 轻重分离
   轻重分离的主旨是对服务的内容进行细分，按照高内聚低耦合的方式部署服务，使得局部的过载不扩散到整个系统。

2. 及早拒绝
   问题解决的阶段越早，成本越低，影响越小。所以咱们一个系统的设计原则：【前端保护后端，后端不信任前端】，在发现系统有过载趋势时，前端系统就要开始拒绝新的用户请求接入。

3. 量力而为
   过载保护是立体工程，各个层级都要首先作好自我保护，再考虑对关联系统的保护。运营时要有容量管理（即容量监控）。通常而言，建议容量管理按照70%预警，过载保护按照90%启动。

4. 动态调节
   动态调节的核心思想是系统运营时经过持续监控业务状态数据寻找【平衡点】，造成一个正向动态反馈的循环：
   业务正常状态-> 过载保护状态 -> 业务灰度恢复直到彻底解除过保。

 

负载均衡

负载均衡和过载保护机制很像，其实二者的目地是同样的，即都有效保护后台服务，减轻后台服务的压力，但实现的手段和方法是不同的。并且即便实现了负载均衡，也是须要提供过载保护机制。负载均衡考虑的是把请求合理分配到后台服务器上。 过载保护考虑的是防止后面的服务器的雪崩。

负载均衡的算法：

1. 轮循均衡（Round Robin）
   每一次来自网络的请求轮流分配给内部中的服务器，从1至N而后从新开始。此种均衡算法适合于服务器组中的全部服务器都有相同的软硬件配置而且平均服务请求相对均衡的状况。

2. 权重轮循均衡（Weighted Round Robin）
   根据服务器的不一样处理能力，给每一个服务器分配不一样的权值，使其可以接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器获得更多的使用率，避免低性能的服务器负载太重。

3. 随机均衡（Random）
   把来自网络的请求随机分配给内部中的多个服务器。

4. 权重随机均衡（Weighted Random）
   此种均衡算法相似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

5. 处理能力均衡
   此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小及当前链接数等换算而成）最轻的服务器，因为考虑到了内部服务器的处理能力及当前网络运行情况，因此此种均衡算法相对来讲更加精确，尤为适合运用到第七层（应用层）负载均衡的状况下。

负载均衡算法的实现有软件和硬件两种，这里重点分析软件的实现负载均衡的反向代理方式：
反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的链接请求，而后将请求转发给内部网络上的服务器，并将从服务器上获得的结果返回给internet上请求链接的客户端，此时代理服务器对外就表现为一个服务器。

反向代理负载均衡能以软件方式来实现，如nginx、apache等，也能够在高速缓存器、负载均衡器等硬件设备上实现。反向代理负载均衡能够将优化的负载均衡策略和代理服务器的高速缓存技术结合在一块儿，提高静态网页的访问速度，提供有益的性能；因为网络外部用户不能直接访问真实的服务器，具有额外的安全性。

 

柔性可用

在有损服务价值观支撑下的一种作法：重点接口重点保障，次要接口有损保障，并提供紧急时刻的降级能力，同时在前端设计时，即便降级也能保证用户体验。即不保证完美体验，对非关键路径进行有损，提高系统的可用性。
实现上会结合用户使用场景，根据资源消耗，调整产品策略，设计几个级别的、不一样的用户体验。最大程度的保证关键服务的可用性。对应互联网服务来讲就是要实现两点:

• 要尽量成功返回关键数据
• 要尽量正常接收请求，不能堵死

 

分SET部署

Set化部署主要为海量服务的运营和部署提供支持，为业务部署创建统一的衡量标准和规则。

• 从业务层面来看到是一组服务器的处理能力，处理能力有两个量来描述，PCU（万人/在线）和存储（GB）。
• 来自于成本层面，即这一组服务器有多少台机器和外网带宽。综合评估设定合理的单位服务支撑能力。

SET模型的一个重要特色是较强的自给自足能力，或者说，SET模型在很大程度上是自治的。从这个意义上说，SET模型与集团军也很具备可比性。

SET模型的特色：

• 通常来讲，一个SET模型部署在一个IDC以内。
• 高内聚，或者说自治系统——这是模块化的体现。
• 同一业务的不一样SET间通讯：SET间专线窄带化。这是下降业务对专线带宽占用，同时也是下降专线抖动对业务的影响，提升业务的专线抖动免役力。
• 即便SET间专线故障，独立SET也应至少提供基础服务，而不致停服。

Set化部署的例子：
Qzone日志TDB仓库设定180A1+20B5+20C1+2B2+23A3为一个Set。

 

灰度发布

互联网行业的变化不少很快，致使代码发布也不少，于是引入bug的可能性也大了很多，与服务系统的稳定性造成了突出的矛盾。如何解决这个矛盾？如何既能基本保障服务稳定性，又能进行灵活反应、快速发布？

灰度发布的优点：

1. 灰度发布能下降发布出问题的影响
2. 下降发布正常时的用户感知
3. 下降对测试的依赖

灰度发布的维度：

1. 按照特性（内容维度）
   每次只发布少部分特性、模块

2.按照对象
白名单
Alpha用户
公司用户
用户等级等级
用户号段
其余业务逻辑

 

立体监控

立体监控是对一个业务或者系统进行完整的监控，而业务从系统层次上又能够分为接入层，逻辑层，数据层。或者从基础的资源到用户实际体验来划分：

按照上述层次划分，每层须要监控的技术指标以下：

报警
有了监控，还须要有效的通知方式。目前用的最多的是设置告警了。当某个监控指标不正常时，经过向相关负责人发送告警，以便及时处理。但告警不宜设置过多，非关键的或者重复的告警须要考虑去掉，以避免告警过多，接收人会对告警不敏感。

海量服务的4个意识

大系统作小

大系统小作的核心思想是将功能复杂较大的系统，化大为小，减小模块耦合，下降相关联性，用多个独立的模块来实现总体系统的功能。
总的来讲，大系统小作采用的是化繁为简、分而治之，便于开发和迅速实现；同时当某个模块出了问题时，由于相互独立，能将影响降到最低，不至于扩大影响范围。咱们在实际工做也常常采用这种方法。
好比电商领域，会把系统分红订单模块，商品模块，售后，物流等模块，每一个模块独立实现，互不影响。 再如物流的第二天达项目，就按照交易线，物流线，结算线分开，每快互相独立，定义接口，最后把整个系统分解不少小块。
这样作自己容易开发，还有一点就是为之后系统的扩展和作灰度升级提供方便。便可以只灰度发布某一个模块，而不用发布整个模块。

先抗住再优化

先扛住再优化简单来讲就是先保证业务的正常使用，即先扛住，再来优化。由于在复杂的优化工做交付以前，交互中故障模式的数量早就足以磨灭人们的信心。

1. 排队机制
   游戏满负荷时，给新来的用户弹出提示语“服务器已满，您前方有XXX个玩家在排队。服务器会帮你自动登陆，请您耐心等候”。游戏满负荷时，让新进的玩家定向另外一款小游戏去，让玩家在娱乐中等待。

2. 降压
   QQ相册。原来的方案是用户浏览照片，没按下一张以前就会预加载下张照片，以便提高用户体验。后来发如今高峰期，带宽不够用，用户叫苦连连。如今改成在18:00-20:00时段，取消自动加载照片功能。很快消去了这个封尖。

3. 运营扛法
   当初QQ幻想一想收费，玩15分钟扣1个q点。帐户系统时不时会core，core了之后公司就不能收钱了。可是core的缘由一时又没找到。解决的办法是添加监控脚本，监控到程序不在了就拉起。

干干净净

干干净净能够说是开发人员的一个编程态度。

1. 干干净净对产品而言，咱们常常会看到不少产品从初期简单清晰的功能规划，不断叠加产品逻辑、不断推出新的功能、给用户更多更全的特性入口。而这些不断叠加的逻辑、功能、特性，是不是用户所真正所须要的，每每会被忽视，因此咱们须要干干净净的态度对待产品，善于用减法的思路对待产品。

2. 干干净净对架构而言，不少产品设计之初的架构都比较容易作到清晰高效，而运营过程当中，为了应对一些临时的活动，或针对一些初期未考虑到的特殊状况，等等，新的差别化于初期架构因素会不断被引入，架构层次及定位逐渐再也不清晰，最终很大程度上形成架构效率的下降。

3. 干干净净对开发而言，咱们会看到在开发不断交接更替的状况下，程序中会不断有带有我的风格的代码库、中间件等被引入，在长期发展状况下，不及时清理干净，最终会变得臃肿而难以承接。

4. 干干净净对运营而言，高效的运营须要清晰的运营架构和有序明了的运营环境，实际工做中如由于交替等因素，会形成运营环境中的脚本、目录，甚至进程、端口处于无序的状态，这些都会给后续的运营工做带来很大的风险和低效。

边重构边生活

随着业务的发展：系统变得复杂，功能更增强大；服务器/带宽/成本增长；运营环境如千丝万缕，运维难度增长；代码风格不一；用户数量级不断增长……这些因素，当其发展到某个量级时，会变得臃肿不堪，耗费至关的人力成本和服务器资源，也难以保障服务质量。这就要求咱们：要有勇气和自信重构服务，提供更先进更优秀的系统。