腾讯海量服务之道（PDF34页）

腾讯海量服务之道AlexHuo写在前面的话•几个产品概览•海量服务之道•例子•总结•期望•很多内容都听过，关键是落实和做到极致。产品一:创新型产品–无KPI压力，有做出东西的压力–语音助手产品，类似Siri–微信电话本/与cntv合作的未来电视/指尖搜索/微信CRM平台/号码检索/视频检索–注重用户场景，体验产品–3RD1PM而QA资源是借的–使用MVP理论–抓数据/服务/精度/召回–手机管家也在用微信电话本相关的服务–目标：服务化–沟通利器：RTX，邮件跟踪，周报，电话沟通，视频会议–优势：小团队，机动性，灵活性，坐的近–领导层的信任：充分授权–PM的职责：从头到尾负责，甚至包括机器机房的申请产品二：手机微博–单周迭代–10个PM(2个运营)/14个RD/2QA–单周评审会/无站会/Story完成即上线/RD有迭代回顾会–RD老大和PM老大是共同的老大（PM出身）–RD的组长负责项目管理–需求拆Story/PM统一过需求/需求评审会–PM子方向：后台基础服务vs对外合作vs运营PM–用户体验意识强，天天自己体验自己的产品产品三：Windows平台电脑管家–onepage评审，方向定下来–产生文档，文档评审–交互图确定，进入开发–showcase都不一定有–不是Scrum，而是迭代开发，一个迭代2周时间，固定时间上线–提示升级和客户端推送，自动发布–20RD5PM分不同的子方向–UE不在RD团队，需要申请资源–中心领导，技术出身–项目计划排期，人天，WBS产品四：网页搜索–在线，离线，相关性，下载–模块团队2-3周迭代–各团队接口人每周定期沟通进度（类似ScrumofScrums）–20+PM/200+RD/30+QA/10OP–持续集成–OP自动化发布–部门老大强烈关注用户体验，每天20+badcase–部门老大技术出身–每次策略上线需要验证BadCase/GoodCase–跨部门协作由PM或者PjM负责–监控系统很强大–自动化测试工具–CODE系统–TAPD管理平台–Jenkins平台–各个部门有研发管理/研发质量团队负责公共资源的管理–BuildfromSource（尽量避免二进制依赖）–主干开发主干发布生成TAG–灰度发布腾讯海量服务之道尝试这样来定义海量•--当在线超过千万；•--当索引超过百亿；•--当数据超过百P；李开复曾说过，如果google采用IBM的行业解决方案的话，google将会破产，因为在传统行业中，每个交易的造价是很昂贵的，它没有办法放量到这样的级别。这就决定了做海量服务的架构取向，我们不可以依赖硬件，也不可以依赖中间件，因为这些都是为比较小的量级的行业所设计的。不同量级的服务，需要不同的系统架构进行应对，同时每增加一个量级，都会有无数的需要优化的地方。打一个比方，在建筑领域，平房、小高层、100米以下楼房和摩天大厦对地基、地震、消防、安防的要求都不一样，而随着楼层的增高，这些要求都是呈几何数的增加。技术价值观之一：有损服务•有损服务–【有损】：腾讯特色，通过精心细分场景，选择牺牲一部分数据一致性、完整性。–举例：UGC产品–类比：小明的故事•好钢用在刀刃上，在资源一定的前提下，在网络条件千变万化的场景中，量力而为，满足用户【快-不要我等】、【简-不要我想】、【了胜于无】的核心需求，设计具备可伸缩、可调度的【柔性系统】成为选择，此所谓【伸缩调度、降级服务】的思想渊源。•腾讯【有损服务】价值观的核心思想是：【放弃绝对一致，追求速度极致】【万有一失，用户重试】【伸缩调度，降级服务】技术价值观之二：动态运营•动态运营–动态运营的核心思想就是敏捷迭代，所谓小步快跑，对用户的需求快速反应。–动态运营的思路就是用户概念，敏捷设计，开发和测试，运营和验证。–迭代模型：以产品特性为中心，缺乏持续改进。–运营模型：以运营为中心，关注反馈和持续改进,永远是beta版本。–从产品出发：产品需求中的“思想”比“做法”更重要；–让整个团队明确ApplicationDefinitionStatement(产品定义描述)；–有新的想法应该尽快实现，在迭代中进化，并通过用户验证；–一个好想法，推迟2个月实现，可能已经不再适应当前用户的需求，也就一文不值了，甚至拉低产品的质量。–优秀的团队=团队能力*迭代速度。–总体上来说，动态运营就是快速求证对用户猜想的过程，这个过程是建立在以”运营”为中心的设计开发验证模式。技术手段之一：容灾•从互联网常见事故看容灾方法：(全网调度)–光纤断/机房停电异地部署–服务器硬件故障死机热备–网络环境恶劣（不同ISP互联）异地部署就近服务–黑客攻击DNS建设–服务雪崩负载均衡、流量拥塞控制、频率控制–程序core自动拉起技术手段之一：容灾•容灾主要分为逻辑层容灾和数据层容灾。•独立逻辑的逻辑层，被接入层负载均衡调用。•分号段逻辑的逻辑层，每个逻辑层只能处理指定号段的请求。•数据层容灾常用方法。–写唯一式同步，业务写请求只发给数据层主机，由主机采用快、慢同步结合的方式同步给各台备机。–同时写式同步,业务将写请求发给所有数据层服务器，得到所有/多数确认才算写完成。技术手段之二：过载保护•轻重分离–轻重分离的主旨是对服务的内容进行细分，按照高内聚低耦合的方式部署服务，使得局部的过载不扩散到整个系统。–渠道分离：如有线、无线服务的分离；–部署分离：如电信、联通、教育、海外服务的分离；–快慢分离：如文字、图片、视频、下载等服务的分离；–用户分离：按set划分系统为用户提供服务，常用的方式是按游戏世界（互娱）、按UIN号段、按UIN取模等方式做到服务的逻辑直至物理的隔离；技术手段之二：过载保护•及早拒绝–问题解决的阶段越早，成本越低，影响越小。–系统的设计原则：【前端保护后端，后端不信任前端】，在发现系统有过载趋势时，前端系统就要开始拒绝新的用户请求接入。技术手段之二：过载保护•量力而为–过载保护是立体工程，各个层级都要首先做好自我保护，再考虑对关联系统的保护。–运营时要有容量管理。•动态调节–动态调节的核心思想是系统运营时通过持续监控业务状态数据寻找【平衡点】，形成一个正向动态反馈的循环：业务正常状态-过载保护状态-业务灰度恢复直到完全解除过载保护。技术手段之三：负载均衡•过载保护考虑的是防止后面的服务器的雪崩。•负载均衡考虑的是把请求合理分配到后台服务器上。–轮循均衡（RoundRobin）–权重轮循均衡（WeightedRoundRobin）–随机均衡（Random）–响应速度均衡（ResponseTime）–最少连接数均衡（LeastConnection）–处理能力均衡•负载均衡的实现的方式目前有硬件方式和软件方式。•软件实现负载均衡的方式主要有DNS负载均衡和反向代理负载均衡。技术手段之四：柔性可用•柔性可用是在有损服务价值观支撑下面的一种方法。•实现上会结合用户使用场景，根据资源消耗，调整产品策略，设计几个级别的、不同的用户体验。•最大程度的保证关键服务的可用性。•对应互联网服务来说就是要实现两点：–要尽可能成功返回关键数据–要尽可能正常接收请求，不能堵死。•这个和有损服务强调的原则是一样的，即不保证完美体验，对非关键路径进行有损，提升系统的可用性。技术手段之五：Set化部署•Set化部署主要为海量服务的运营和部署提供支持，为业务部署建立统一的衡量标准和规则。•第一：从业务层面来看到是一组服务器的处理能力，处理能力有两个量来描述，PCU（万人/在线）和存储（GB）；•第二：来自于成本层面，即这一组服务器有多少台机器和外网带宽。综合评估设定合理的单位服务支撑能力。•Set模型有点类似于集装箱。集装箱通过“三化”（标准化、规模化、模块化），使货运各个环节做到极致，提高货运全流程效率，甚至大力推动了经济全球化进程。•SET模型的特点：–一般来说，一个SET模型部署在一个IDC之内。高内聚，或者说自治系统——这是模块化的体现。–视角更上一层，从业务部署观点看，SET模型是业务部署方法。按照容灾原则，系统中一般应避免单点；同样，业务也往往需要部署两个或以上SET模型。–同一业务的不同SET间通信：SET间专线窄带化。这是降低业务对专线带宽占用，同时也是降低专线抖动对业务的影响，提高业务的专线抖动免役力。即使SET间专线故障，独立SET也应至少提供基础服务，而不致停服。技术手段之六：灰度发布•产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户-忠诚度较高的种子用户-更大范围的活跃用户-所有用户。•在此过程中，产品团队根据用户的反馈及时完善产品相关功能。•灰度发布带来的好处是巨大的：–灰度发布能降低发布出问题的影响；–降低发布正常时的用户感知；–降低对测试的依赖。•灰度策略在架构设计要满足一定的要求（大系统小做），具体灰度有下面几种方式：–按照特性（内容维度），每次只发布少部分特性、模块，温水煮青蛙，减少用户不适，流水作业加快进度；–按照对象，白名单/Alpha用户/公司用户/黄钻等级/用户号段/其他业务逻辑。技术手段之七：立体监控•立体监控是对一个业务或者系统进行完整的监控，而业务从系统层次上又可以分为接入层，逻辑层，数据层。•总的来说，针对每一次层次，都需要采用不同的监控方法和手段。•有了监控，我们还需要有效的通知方式。意识之一：大系统小做•大系统小做的核心思想是将功能复杂较大的系统，化大为小，减少模块耦合，降低相关联性，用多个独立的模块来实现整体系统的功能。•大系统小做采用的是化繁为简、分而治之，便于开发和迅速实现；同时当某个模块出了问题时，因为相互独立，能将影响降到最低，不至于扩大影响范围。•反例：Over-Design（过度设计）意识之二：干干净净•干干净净可以说是开发人员的一个编程态度。•干干净净于产品而言，我们经常会看到很多产品从初期简单清晰的功能规划，不断叠加产品逻辑、不断推出新的功能、给用户更多更全的特性入口。而这些不断叠加的逻辑、功能、特性，是否是用户所真正所需要的，往往会被忽视，所以我们需要干干净净的态度对待产品，善于用减法的思路对待产品。•干干净净于架构而言，很多产品设计之初的架构都比较容易做到清晰高效，而运营过程中，为了应对一些临时的活动，或针对一些初期未考虑到的特殊情况，等等，新的差异化于初期架构因素会不断被引入，架构层次及定位逐渐不再清晰，最终很大程度上造成架构效率的降低。•干干净净于开发而言，我们会看到在开发不断交接更替的情况下，程序中会不断有带有个人风格的代码库、中间件等被引入，在长期发展情况下，不及时清理干净，最终会变得臃肿而难以承接。•干干净净于运营而言，高效的运营需要清晰的运营架构和有序明了的运营环境，实际工作中如因为交替等因素，会造成运营环境中的脚本、目录，甚至进程、端口处于无序的状态，这些都会给后续的运营工作带来很大的风险和低效。意识之二：干干净净•不干净的发展是缓慢渐进的，象是温水里煮青蛙，很容易形成对不干净的状况不以为然，只要系统能跑就好的得过且过心理，针对这种情况需要大家在自己的领域引入一种污染因子的观测思路，及时发现及时清理；•另外，要防止用大扫除的思路来对待不干净，不要想着等积累了足够多的不干净之后来一次大规模的清理工作，实际更需要的是化大扫除为日常的清理，保持系统轻量干净地持续运行。•这种意识是和后面的边重构，边生活是一致的，即要保持代码的简单和可维护性。意识之三：边重构边生活•边重构边生活要求我们：要有勇气和自信重构服务，提供更先进更优秀的系统。•保持代码的简单和可维护性。•重构vs重做意识之四：先扛住再优化•先扛住再优化简单来说就是先保证业务的正常使用，即先扛住，再来优化。因为在复杂的优化工作交付之前，故障的数量早就足以磨灭人们的信心。•有时候不一定改变架构，只需要策略的改变也可以扛（产品策略在这个时候也非常重要）：–排队机制，“服务器已满，您前方有326个玩家在排队。服务器会帮你自动登录，请您耐心等候”；–降压，例如在高峰时刻降压，取消预加载机制；–运营扛法，例如问题原因没有找到之前，通过监控脚本自动拉起Co