大型网站技术架构核心原理与案例分析

大型网站技术架构核心原理与案例分析第一页，共37页。大型网站架构演化京东案例：2011年末，京东图书促销，并发访问过高浏览页“Serviceistoobusy”紧急采购10台服务器，依然如故刘强东请信息部们人员“喝茶”12306铁路订票网：2012年初，12306春运期间崩溃运营时间很短，缺乏大规模并发处理经验12306架构师对这种访问趋势没概念导致直接崩溃，12306被媒体技术“喷”原因：网站技术架构的问题

互联网发展短短20多年的时间，世界发生了巨大变化：信息检索电子商务文化娱乐社交通信

问题：

一边是火热的发展，一边是不堪重负的网站架构，如何打造高可用、高性能、易扩展、可伸缩且安全的网站，并且迅速能够实现应用。2第二页，共37页。高并发、大流量：

Google日均PV数35亿，日均IP访问数3亿；腾讯QQ1.4亿在线；淘宝12年双11，活动开始一分钟1000万访问用户高可用：7X24小时服务，不间断海量数据：需要存储管理海量数据，需要大量的服务器，百度收录数百亿网页；Google有百万台服务器在全球用户分布：用户分布范围广，全国甚至全球，各地网络环境千差万别，运营商互联互通的问题安全环境恶劣：互联网的开放性，使得网站更容易受到攻击，很多网站泄露密码及重要数据，用户也受到影响需求变更频繁快速：和传统软件不同，互联网产品为了快速适应市场，满足用户需求，产品发布频率高，新版本不

断上线渐进式发展：不是所有网站一开始就是大而全，都是从小网站逐渐发展起来的，好的网站都是慢慢运营出来大型网站架构演化大型网站软件系统的特点3第三页，共37页。大型网站架构演化发展历程初始阶段的小网站应用服务与数据服务分离使用缓存改善网站性能应用服务器集群提高并发处理能力数据库读写分离反向代理和CDN加速网站响应分布式文件系统和分布式数据库使用NOSQL和搜索引擎业务拆分分布式服务发展历程4第四页，共37页。大型网站架构演化发展历程初始阶段的小网站

应用程序、数据库、文件等所有资源在一台服务器上，操作系统通常为Linux、应用程序用PHP开发，部署在Apache上，数据库使用MySQL，汇集各种免费开源软件及一台廉价的服务器就可以开始网站的运营和发展5第五页，共37页。大型网站架构演化发展历程应用和数据分离：改善访问性能和数据存储，支持业务继续发展

业务发展1、越来越多的用户访问（性能变差）2、越来越多的数据存储（存储空间不足）应用和数据分离1、应用服务器单独一台服务器2、文件服务器单独一台服务器3、数据库服务器单独一台服务器侧重点：应用服务器需要强大CPU用于计算逻辑文件服务器需要大磁盘存储文件数据库服务器需要大内存和快速磁盘6第六页，共37页。大型网站架构演化发展历程使用缓存改善网站性能：减少数据访问压力，改善数据库写性能

网站访问的二八定律1、80%的访问集中在20%的数据上2、20%数据集中在内存缓存网站使用缓存1、本地缓存2、远程分布式缓存重点：本地缓存速度快，缓存数据量有限远程分布式缓存采用集群瓶颈即将出现在单一的应用服务器7第七页，共37页。大型网站架构演化发展历程使用应用服务器集群改善网站并发处理能力

业务持续发展1、访问用户持续增加2、网站访问性能不佳应用服务器集群1、通过负载均衡将访问分发应用服务集群2、应用服务器集群是可伸缩性的重点：不要去试图更换强大的服务器采用服务器集群是更好的扩展性能的方式即将出现的瓶颈为数据库服务器8第八页，共37页。大型网站架构演化发展历程数据库读写分离：改善数据库负载过高

业务持续发展1、数据库不能避免读写操作2、用户增多，数据库负载过高数据库读写分离1、数据库主从关系2、数据更新同步重点：数据库读写分离，从数据库主读应用服务器访问数据模块需要改造网站响应的问题解决网络复杂的问题第九页，共37页。大型网站架构演化发展历程使用反向代理和CDN加速网站响应

网络环境复杂1、用户分布范围广2、网络环境复杂反向代理和CDN1、CDN虚拟网络，加速访问响应2、直接访问反向代理服务器重点：CDN节点重新定向访问用户最优原则反向代理和CDN基础应用都为缓存技术分布式文件系统和分布式数据库第十页，共37页。

持续的业务发展1、不是任何一台几台服务器可以支撑2、分布式文件服务器和分布式数据库服务器分布式数据库是网站数据库拆分的最后一招1、数据拆分2、业务拆分重点：服务器集群的应用数据库服务器集群的模式NOSQL数据库和搜索引擎的技术引应用分布式文件服务器和分布式数据库应用大型网站架构演化发展历程第十一页，共37页。

持续的业务越来越复杂1、对数据存储要求复杂2、对数据检索要求复杂NOSQL和搜索引擎对分布式可伸缩支持好1、NOSQL数据库，读操作和非格式数据2、搜索引擎迅速定位数据，降低数据访问重点：NOSQL和搜索引擎应用数据访问模块改造，减少应用程序管理数据业务拆分大型网站架构演化发展历程使用NOSQL和搜索引擎第十二页，共37页。大型网站架构演化发展历程

业务越来越复杂1、应用越来越复杂2、产品和业务越来越繁杂业务拆分，解决日益复杂的应用场景1、产品拆分，首页，订单，商品，支付2、应用之间的数据交换（超链接；消息）

各应用还是集中访问一个数据存储系统

需要考虑应用和数据库连接的资源平衡业务拆分（即应用拆分，应用之间的数据交互）第十三页，共37页。大型网站架构演化发展历程

业务越来越复杂1、应用越来越复杂2、数据库连接资源不足提取公共业务，服用业务连接数据库1、公共业务提取，独立部署2、分布式应用调用业务服务思想

大型网站的架构演化到这里，基本的技术问题都能得到解决，事物发展到一定阶段，都会象更强大方面发展，诸如云计算平台的建设，将资源变成商品出售。分布式服务（服务分布，业务连接共用）第十四页，共37页。大型网站架构演化的价值观

大型网站架构技术的价值观1、大型网站架构的核心价值不是从无到有直接搭建大型网站，而是随着业务的发展慢慢演化而来的，所需的技术也是慢慢演化而来的，不是剧烈的革命和推翻，如GOOGLE；taobao等2、大型网站技术发展的力量是网站发的业务发展，是业务成就了技术，是事业成就了人，所以投身互联网的前提是理清楚业务，而不是四处挖高手，仿照成功的互联网公司打造技术平台，这无疑是南辕北辙，缘木求鱼

两个极端一方面：随着互联网高速发展，越来越多的软件技术和产品从互联网公司诞生，挑战传统软件巨头的江湖地位另一方面：绝大多数的中小网站几十年如一日的使用LAMP技术开发自己的网站，性价比超高的同同时，应付业务绰绰有余第十五页，共37页。网站架构设计的误区

1、一味的追求大公司巨大成功的光环效应，加上挖来的技术高手的影响，网站架构决策时，最有力的的一句话变成了“淘宝就是这样搞的”或者“Google就是这样的结构”,大公司的经验值得借鉴，但不要盲从，失去了坚持自我的勇气2、为了技术而技术：网站架构和技术是为业务而存在的，脱离了业务发展的实际要求，一味追求新技术会增加成本，反而走了弯路。3、企图用技术解决所有问题：往往很多网站运营出了问题，都是考虑用技术去解决，而往往忽略了业务架构，有的时候重新梳理业务架构，调整业务需求，也会解决很多棘手的问题总结：时至今日，大型网站的架构演化方案已经非常成熟，很多网站建立之初就是搭建在大型网站提供云计算服务基础上的，所需要的资源都可以按需购买，线性伸缩，所以亲历网站从小变大的架构演化的工程师越来越少，所以我们更应该去了解和理解网站架构技术方案的来龙去脉和历史渊源，这样才能在技术选型和架构决策时有的放矢。第十六页，共37页。案例分析：12306网站引发的网站架构设计和讨论2012年初，铁道部12306网上购票系统为了解决购票半夜早起，在瑟瑟寒风中排队挨冻的痛苦，然而各种技术和业务的问题，12306无法面对“春运”期间的瞬间海量高并发，出现访问过慢，频繁报错甚至直接无法登陆等现象，顿时国内怨声一片，就此引发很多热帖。第十七页，共37页。案例分析：12306网站引发的网站架构设计和讨论国企=垄断+腐败+低效（媒体和技术公司的看法）问题和难点分析

业务架构问题：

1、对于春运一票难求的中国，火车票网购本身就存在巨大风险2、整点售票改为分时段售票3、售票引入排队机制

技术架构问题：

1、对高并发，高流量预计不足2、网站架构不合理3、架构师缺乏经验第十八页，共37页。案例分析：12306网站引发的网站架构设计和讨论技术改造的关键：“利用云计算资源“，“按需及时扩充“和”快速调整，“建立可伸缩扩展的云应用平台云计算的基础架构虚拟化已经非常成熟，当网络阻塞时，可以动态增加带宽，当服务器CPU到达高位时，可以快速从资源池获取虚拟机资源来分摊负荷。

底层的架构都虚拟化后，网络设备，Web服务器，应用服务器都可以做“伸缩性”的扩展；但遇到一个难点就是“12306的应用系统框架”无法支持可伸缩扩展。原因是关系型数据库无法支持“应用系统”的伸缩扩展。客户已经投入大笔经费在IT方面的建设，但“系统框架设计”还是沿用10几年前的三层设计，而且每年都在原来的基础上做不断的升级。当业务不断成长时，数据量也跟着成长，功能越来越多，但系统性能越来越差。12306网站技术改造思路第十九页，共37页。案例分析：12306网站引发的网站架构设计和讨论12306网站技术改造办法12306最后选择PivotalGemfire作为系统改造的平台，其主要原因如下：1.关联数据节点设计：可以根据客户的业务逻辑特性和数据关联性，将关联性强的数据放置于同一个服务器节点，提高系统性能，避免分布式系统服务器的频繁数据交换。2.将数据移到内存：由于数据是放在内存里面，屏蔽传统数据库频繁访问，CPU与数据库的交互作用，影响服务器性能。内存的数据交换速度远高于磁盘速度上千倍，极大提高系统性能。3.扩展和伸缩性：以Gemfire构建的应用云平台，是以x86PC服务器为主的硬件基础。在保证系统的性能下，此平台可以随着客户业务的成长来任意调配x86服务器的数量，避免以后昂贵的硬件升级带来的困扰。经测试结果显示，整个系统性能可随着服务器的数量的增加实现几乎线性的成长。4.数据可靠性：在同个集群里面可以有多个数据节点备份，数据可以自动同步或是将内存数据持久化到硬盘或是数据库5.跨地域的数据分布或同步：可以透过“广域网”将指定的Gemfire集群的内存数据“实时同步”到异地的数据中心。这是属于“应用层”的数据同步异于传统的“数据库”同步。6.PivotalGemfire使用x86PC服务器，其性价比远远高于Unix小型机。第二十页，共37页。案例分析：12306网站引发的网站架构设计和讨论第二十一页，共37页。某某联通预支充值服务实现办法（3）OCS改造：创建DCO信用账本并开辟空间存储DCO信用额度OCS方需在现有的OCS平台中开辟专门的空间存储DCO信用额度（DCO信用额度是信用账本的上限值，且是固定值，除非DCO平台请求对用户的信用额度进行修改）；OCS方需在现有OCS平台中开辟供DCO使用的专有信用账本（DCO信用账本），用于存储DCO信用余额（信用账本的上限值即为DCO信用额度值）。2.

修改扣费及用户充值时计算逻辑并更新相应账本OCS平台需要对当前现金账本（含：默认信用账本）、DCO信用账本、单停漫游信用账本（被叫信用度账本）的扣费计算逻辑、充值恢复计算逻辑按本文上述的业务需求进行修改；计算逻辑修改的目的是用于计算DCO信用使用后的余额并更新到DCO信用账本、以及计算用户充值时DCO信用账本恢复后的余额并更新到DCO信用账本。3.

开发接口实现OCS平台与DCO平台之间的数据交互（非实时）提取DCO平台上线前的用户打分数据（用户充值记录、用户当前状态）及上线后的每日/每月传输数据（用户充值记录、用户日末余额、用户当前状态、信用额度应答数据），并生成指定格式的数据文件（如：CSV格式）以FTP方式上传到指定的服务器路径；OCS以FTP方式从指定的服务器路径下载批量用户授信请求文件（如：CSV格式），并在OCS平台内对用户的授信额度进行修改；OCS将批量用户授信结果文件（如：CSV格式）以FTP方式上传到指定的服务器路径，由DCO平台对授信结果进行更新。OCS将批量每日传输如4.8所述的用户数据文件（如：CSV格式）以FTP方式上传到指定的服务器路径。22第二十二页，共37页。某某联通预支充值服务实现办法（1）23第二十三页，共37页。某某联通预支充值服务实现办法（2）业务内容实现机制服务生效1)OCS创建DCO信用账本，该账本可以用于扣款2)该信用账本可以按照生效时间启用,失效时间停用3)该信用账本可以根据初始授信额度更新申请表的要求更新4)信用账本创建时需要对用户状态进行校验，仅在有效期内可以创建信用账本。服务使用1)信用额度使用范围为：为用户提供信用额度用于用户所有消费行为（任何消费都可以使用信用账本的额度，包括短信，语音，数据，增值业务，套餐，第三方增值业务等）。2)DCO信用账本的使用优先级：现金账本>DCO信用账本。用户消费过程中，当用户自身余额（现金账本）用尽时，开始使用DCO信用账本；服务取消1)

信用账本做失效处理（将失效时间置为当前时间，并且用户的信用额度为0，坏账为用户当前未恢复的信用额度）2)

任何状态下都可以失效信用账本。3)

用户投诉和坏账用户才会取消信用。信用额度的恢复1)DCO信用账本的恢复优先级为：欠费>DCO信用账本>现金账本2)用户充值时，会将DCO账本的已使用金额进行返还。3)只有现金充值才能恢复信用账本，非现金充值不能用户信用恢复。信用额度的调整信用额度调整时的处理原则为，调减时，OCS需要做出一些判断：如果用户的DCO信用账本余额<信用额度调减量，则不调整，并返回相应的错误代码。24第二十四页，共37页。某某联通预支充值服务实现办法（2）25第二十五页，共37页。预支充值服务整体方案–标准硬件配置方案乙方提供预支充值服务的硬件平台综合安全性和数据传输性能考虑，建议服务器放置于运营商的数据中心内预支充值硬件平台与预付费系统接口相连，进行数据传输预支充值硬件平台遵守运营商安全管理规范，接受运营在硬件层面的监管乙方公司通过VPN远程监控服务的运行情况并提供运行支撑用户NOC服务器1服务器2服务器…服务器n防火墙防火墙交换机交换机交换机eth0eth0eth0eth0eth1eth1eth1eth1ILOILOILOILOeth2eth2eth2eth2ILOZONEILOZONE乙方硬件平台乙方或运营商提供数据中心第二十六页，共37页。需要配合的工作打分、统计数据接口打分通知数据处理接口服务取消/再加入数据接口短信平台数据接口接口开发数据中心内的位置空间;相应网络、电力、环境等;VPN连接数据中心建议使用运营商统一热线电话提供客户服务乙方公司将提供工作平台、培训及相关支撑热线服务建方安排一名经验丰富的业务部门工作人员负责与我方对帐核算需要在预付费系统中开发相应的结算统计报表对帐结算预支充值服务开通技术改造预支充值服务使用与恢复改造其他可能涉及的改造核心逻辑27第二十七页，共37页。接口开发No.数据表1充值信息表2通话消费表3数据消费表4短信或增值消费表5日末余额表6用户状态表7转网用户表8套餐信息表9预支额度表No.数据表1预支额度更新请求表2预支额度更新反馈表No.数据表1预支额度更新请求表2预支额度更新反馈表No.数据表1预支充值服务短信通知2预支充值服务短信退订手机预付费用户预付费系统信用账本…账本资金账本预支充值平台行为分析与打分结算统计客服预支充值管理平台充值/消费打分统计数据接口批量额度更新取消/再加入服务取消/再加入短信平台短信确认与取消1234打分统计数据接口1打分通知数据处理接口2服务取消/再加入数据接口3短信平台数据接口428第二十八页，共37页。接口开发接口接口描述主要功能数据传输方式数据内容数据量估计1打分统计数据接口将用户充值、消费等数据从预付费系统传输到预支充值平台，用于数据分析处理和客户打分非实时，每天晚上批量传输充值数据消费数据日末余额数据用户状态、离网信息等与用户数量直接相关，约为500M~1GB/每日

(*

按照10万用户估计，以下同）2打分通知数据处理接口将打分结果（预支充值额度表）从预支充值平台传输到预付费系统，用于向用户信用模块充值非实时，每月一次批量传输打分结果（预支充值额度表：用户ID、预支充值额度）与用户数量直接相关，初步估计10MB/每月3服务取消/再申请数据接口将用户取消服务的数据从预支充值平台传输到预付费系统系统实时传输/非实时每天晚上传输取消服务的用户列表初步估计，平均小于100条记录每天4短信平台数据接口将预支充值服务的用户及信用额度数据传递给短信平台，用于生成短信提醒用户该项服务主要采用非实时，批量传输方式。提供预支充值服务的用户及预支充值额度根据用户数量，初步估计10MB/每月29第二十九页，共37页。系统改造—打分和服务生效流程手机预付费用户预付费系统信用账本…账本资金账本预支充值平台行为分析与打分结算统计客服预支充值管理平台短信平台1.充值/消费2.充值消费等数据3.预支额度更新5.服务取消/再申请4.下发短信通知6.服务取消/再申请7.预支服务取消/再申请用户消费和充值的详单被将被预付费系统记录这些记录每天晚上通过接口传递到预支充值平台预支充值平台进行客户分析、分类、打分，并把预支额度表(增量数据)通过线下的方式传递给预付费系统，由预付费系统将额度更新到用户的信用帐本，并传回额度更新回执预付费系统通过短信平台通知用户用户可以通过客服热线或短信选择退出/再申请客服人员通过预支充值管理平台（Web）执行查询确认和执行退出/再申请操作，并通知预支充值平台预支充值平台通知预付费系统取消预支额度5.服务取消/再申请6.服务取消/再申请30第三十页，共37页。系统改造—服务使用与恢复量计算使用量计算方式一：预支充值平台通过信用账本的消费记录计算使用量：信用账本使用优先级低于现金账本，恢复优先级高于现金账本可以获得信用账本所有的消费记录可以区分跨账本消费记录另外，关注：消费记录是否包含账本信息如果发生调减账，采用何种方式，是否会对服务计算产生影响手机预付费用户预付费系统信用账本…账本资金账本预支充值平台行为分析与打分结算统计客服预支充值管理平台短信平台1.充值/消费2.充值消费等数据3.预支额度更新5.服务取消/再申请4.下发短信通知6.服务取消/再申请7.预支服务取消/再申请5.服务取消/再申请6.服务取消/再申请31第三十一页，共37页。系统改造—服务使用与恢复量计算使用量计算方法二：预支充值平台通过日末账户总可用余额（预付费系统需要设置每日24:00进行批量余额查询）和用户的预支额度计算预支服务的使用量：如果(日末账户总可用余额-预支额度)<0，预支服务使用量=预支额度–日末账户总可用余额如果(日末账户总可用余额-预支额度)>=0，预支服务使用量=0.

如果用户在当天有充值行为:如果（充值前账户总可用余额-预支额度）<0，预支服务使用量=预支额度–充值前账户总可用余额如果（充值前账户总可用余额-预支额度）≥0，预支服务使用量=0.在用户充值时，优先对预支金额进行恢复，恢复量等于充值前的预支金额使用量。用户充值后，开始下一个预支服务使用量的计算过程。关注点/讨论点：账户总可用余额的计算办法及专用账本的扣费限制手机预付费用户预付费系统信用账本…账本资金账本预支充值平台行为分析与打分结算统计客服预支充值管理平台短信平台1.充值/消费2.充值消费等数据3.预支额度更新5.服务取消/再申请4.下发短信通知6.服务取消/再申请7.预支服务取消/再申请5.服务取消/再申请6.服务取消/再申请32第三十二页，共37页。系统改造—转/离网和服务取消/再加入流程手机预付费用户预付费系统信用账本…账本资金账本预支充值平台行为分析与打分结算统计客服预支充值管理平台短信平台1.转/离网2.转/离网数据9.服务取