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

1、大型网站技术架构核心 原理与案例分析 2015年8月 版权所有 严禁拷贝上海全成通信技术有限公司 2 大型网站架构演化 京东案例： 2011年末，京东图书促销，并发访问过高 浏览页“Service is too busy” 紧急采购10台服务器，依然如故 刘强东请信息部们人员“喝茶” 12306铁路订票网： 2012年初，12306春运期间崩溃 运营时间很短，缺乏大规模并发处理经验 12306架构师对这种访问趋势没概念 导致直接崩溃，12306被媒体技术“喷” 原因：网站技术架构的问题 互联网发展短短20多年的时间，世界发生了巨 大变化： 信息检索 电子商务 文化娱乐 社交通信 问题： 一边是

2、火热的发展，一边是不堪重负的网站架构， 如何打造高可用、高性能、易扩展、可伸缩且安全 的网站，并且迅速能够实现应用。 版权所有 严禁拷贝上海全成通信技术有限公司 3 高并发、大流量： Google日均PV数35亿，日均IP访问数3亿；腾讯QQ1.4亿在线；淘宝12年双11，活动开始一分钟1000万访问用户 高可用：7X24小时服务，不间断 海量数据：需要存储管理海量数据，需要大量的服务器，百度收录数百亿网页；Google有百万台服务器在全球 用户分布：用户分布范围广，全国甚至全球，各地网络环境千差万别，运营商互联互通的问题 安全环境恶劣：互联网的开放性，使得网站更容易受到攻击，很多网站泄露密码

3、及重要数据，用户也受到影响 需求变更频繁快速：和传统软件不同，互联网产品为了快速适应市场，满足用户需求，产品发布频率高，新版本不 断上线 渐进式发展：不是所有网站一开始就是大而全，都是从小网站逐渐发展起来的，好的网站都是慢慢运营出来 大型网站架构演化 大型网站软件系统的特点 版权所有 严禁拷贝上海全成通信技术有限公司 4 大型网站架构演化发展历程 初 始 阶 段 的 小 网 站 应用 服务 与数 据服 务分 离 使用 缓存 改善 网站 性能 应用 服务 器集 群提 高并 发处 理能 力 数 据 库 读 写 分 离 反向 代理 和 CD N加 速网 站响 应 分布 式文 件系 统和 分布 式数

4、据库 使用 NO SQL 和搜 索引 擎 业 务 拆 分 分 布 式 服 务 发展历程 版权所有 严禁拷贝上海全成通信技术有限公司 5 大型网站架构演化发展历程 初始阶段的小网站 应用程序、数据库、文件等所有资 源在一台服务器上，操作系统通常 为Linux、应用程序用PHP开发， 部署在Apache上，数据库使用 MySQL，汇集各种免费开源软件及 一台廉价的服务器就可以开始网站 的运营和发展 版权所有 严禁拷贝上海全成通信技术有限公司 6 大型网站架构演化发展历程 应用和数据分离： 改善访问性能和数据存储，支持业务继续发展 业务发展 1、越来越多的用户访问（性能变差） 2、越来越多的数据存储

5、（存储空间不足） 应用和数据分离 1、应用服务器单独一台服务器 2、文件服务器单独一台服务器 3、数据库服务器单独一台服务器 侧重点： 应用服务器需要强大CPU用于计算逻辑 文件服务器需要大磁盘存储文件 数据库服务器需要大内存和快速磁盘 版权所有 严禁拷贝上海全成通信技术有限公司 7 大型网站架构演化发展历程 使用缓存改善网站性能： 减少数据访问压力，改善数据库写性能 网站访问的二八定律 1、80%的访问集中在20%的数据上 2、20%数据集中在内存缓存 网站使用缓存 1、本地缓存 2、远程分布式缓存 重点： 本地缓存速度快，缓存数据量有限 远程分布式缓存采用集群 瓶颈即将出现在单一的应用服务

6、器 版权所有 严禁拷贝上海全成通信技术有限公司 8 大型网站架构演化发展历程 使用应用服务器集群改善网站并发处理能力 业务持续发展 1、访问用户持续增加 2、网站访问性能不佳 应用服务器集群 1、通过负载均衡将访问分发应用服务集群 2、应用服务器集群是可伸缩性的 重点： 不要去试图更换强大的服务器 采用服务器集群是更好的扩展性能的方式 即将出现的瓶颈为数据库服务器 版权所有 严禁拷贝上海全成通信技术有限公司 大型网站架构演化发展历程 数据库读写分离：改善数据库负载过高 业务持续发展 1、数据库不能避免读写操作 2、用户增多，数据库负载过高 数据库读写分离 1、数据库主从关系 2、数据更新同步

7、重点： 数据库读写分离，从数据库主读 应用服务器访问数据模块需要改造 网站响应的问题解决网络复杂的问题 版权所有 严禁拷贝上海全成通信技术有限公司 大型网站架构演化发展历程 使用反向代理和CDN加速网站响应 网络环境复杂 1、用户分布范围广 2、网络环境复杂 反向代理和CDN 1、CDN虚拟网络，加速访问响应 2、直接访问反向代理服务器 重点： CDN节点重新定向访问用户最优原则 反向代理和CDN基础应用都为缓存技术 分布式文件系统和分布式数据库 版权所有 严禁拷贝上海全成通信技术有限公司 持续的业务发展 1、不是任何一台几台服务器可以支撑 2、分布式文件服务器和分布式数据库服务器 分布式数据

8、库是网站数据库拆分的最后一招 1、数据拆分 2、业务拆分 重点： 服务器集群的应用 数据库服务器集群的模式 NOSQL数据库和搜索引擎的技术引应用 分布式文件服务器和分布式数据库应用 大型网站架构演化发展历程 版权所有 严禁拷贝上海全成通信技术有限公司 持续的业务越来越复杂 1、对数据存储要求复杂 2、对数据检索要求复杂 NOSQL和搜索引擎对分布式可伸缩支持好 1、NOSQL数据库，读操作和非格式数据 2、搜索引擎迅速定位数据，降低数据访问 重点： NOSQL和搜索引擎应用 数据访问模块改造，减少应用程序管理数据 业务拆分 大型网站架构演化发展历程 使用NOSQL和搜索引擎 版权所有 严禁拷

9、贝上海全成通信技术有限公司 大型网站架构演化发展历程 业务越来越复杂 1、应用越来越复杂 2、产品和业务越来越繁杂 业务拆分，解决日益复杂的应用场景 1、产品拆分，首页，订单，商品，支付 2、应用之间的数据交换（超链接；消息） 各应用还是集中访问一个数据存储系统 需要考虑应用和数据库连接的资源平衡 业务拆分（即应用拆分，应用之间的数据交互） 版权所有 严禁拷贝上海全成通信技术有限公司 大型网站架构演化发展历程 业务越来越复杂 1、应用越来越复杂 2、数据库连接资源不足 提取公共业务，服用业务连接数据库 1、公共业务提取，独立部署 2、分布式应用调用业务服务思想 大型网站的架构演化到这里，基本的

10、技术问 题都能得到解决，事物发展到一定阶段，都 会象更强大方面发展，诸如云计算平台的建 设，将资源变成商品出售。分布式服务（服务分布，业务连接共用） 版权所有 严禁拷贝上海全成通信技术有限公司 大型网站架构演化的价值观 大型网站架构技术的价值观 1、大型网站架构的核心价值不是从无到有直接搭建大型网站，而 是随着业务的发展慢慢演化而来的，所需的技术也是慢慢演化而 来的，不是剧烈的革命和推翻，如GOOGLE；taobao等 2、大型网站技术发展的力量是网站发的业务发展，是业务成就了 技术，是事业成就了人，所以投身互联网的前提是理清楚业务， 而不是四处挖高手，仿照成功的互联网公司打造技术平台，这无

11、疑是南辕北辙，缘木求鱼 两个极端 一方面： 随着互联网高速发展，越来越多 的软件技术和产品从互联网公司 诞生，挑战传统软件巨头的江湖 地位 另一方面： 绝大多数的中小网站几十年如一 日的使用LAMP技术开发自己的 网站，性价比超高的同同时，应 付业务绰绰有余 版权所有 严禁拷贝上海全成通信技术有限公司 网站架构设计的误区 1、一味的追求大公司巨大成功的光环效应，加上挖来的技术高手的影响，网站架构决策时，最有力的 的一句话变成了“淘宝就是这样搞的”或者“Google就是这样的结构”,大公司的经验值得借鉴，但不 要盲从，失去了坚持自我的勇气 2、为了技术而技术：网站架构和技术是为业务而存在的，脱离

12、了业务发展的实际要求，一味追求新技 术会增加成本，反而走了弯路。 3、企图用技术解决所有问题：往往很多网站运营出了问题，都是考虑用技术去解决，而往往忽略了业 务架构，有的时候重新梳理业务架构，调整业务需求，也会解决很多棘手的问题 总结： 时至今日，大型网站的架构演化方案已经非常成熟，很多网站建立之初就是搭建在大型网站提供云计算服务基础上的， 所需要的资源都可以按需购买，线性伸缩，所以亲历网站从小变大的架构演化的工程师越来越少，所以我们更应该去了 解和理解网站架构技术方案的来龙去脉和历史渊源，这样才能在技术选型和架构决策时有的放矢。 版权所有 严禁拷贝上海全成通信技术有限公司 案例分析：1230

13、6网站引发的网站架构设计和讨论 2012年初，铁道部12306网上购票系统为了解决购票半夜早起，在瑟瑟寒风中排队挨冻的痛苦，然而各种 技术和业务的问题，12306无法面对“春运”期间的瞬间海量高并发，出现访问过慢，频繁报错甚至直接 无法登陆等现象，顿时国内怨声一片，就此引发很多热帖。 版权所有 严禁拷贝上海全成通信技术有限公司 案例分析：12306网站引发的网站架构设计和讨论 国企 = 垄断 + 腐败 + 低效（媒体和技术公司的看法） 问题和难点分析 业务架构问题： 1、对于春运一票难求的中国，火车票 网购本身就存在巨大风险 2、整点售票改为分时段售票 3、售票引入排队机制 技术架构问题： 1

14、、对高并发，高流量预计不足 2、网站架构不合理 3、架构师缺乏经验 版权所有 严禁拷贝上海全成通信技术有限公司 案例分析：12306网站引发的网站架构设计和讨论 技术改造的关键： “利用云计算资源“，“按需及时扩充“和”快速调整，“建立可伸缩扩展的云应用平台 云计算的基础架构虚拟化已经非常成熟，当网络阻塞时，可以动态增加带宽，当服务器 CPU到达高位时，可以快速从资 源池获取虚拟机资源来分摊负荷。 底层的架构都虚拟化后，网络设备，Web服务器，应用服务器都可以做“伸缩性”的扩展；但遇到一个难点就是“12306 的应用系统框架”无法支持可伸缩扩展。原因是关系型数据库无法支持“应用系统”的伸缩扩展

15、。 客户已经投入大笔经费在IT方面的建设，但“系统框架设计”还是沿用10几年前的三层设计，而且每年都在原来的基础上 做不断的升级。当业务不断成长时，数据量也跟着成长，功能越来越多， 但系统性能越来越差。 1230612306网站技术改造网站技术改造思路思路 版权所有 严禁拷贝上海全成通信技术有限公司 案例分析：12306网站引发的网站架构设计和讨论 1230612306网站技术改造网站技术改造办法办法 12306 最后选择Pivotal Gemfire作为系统改造的平台，其主要原因如下： 1. 关联数据节点设计：可以根据客户的业务逻辑特性和数据关联性，将关联性强的数据放置于同一个服务器节点，提

16、高 系统性能，避免分布式系统服务器的频繁数据交换。 2. 将数据移到内存：由于数据是放在内存里面，屏蔽传统数据库频繁访问， CPU与数据库的交互作用，影响服务器性能。 内存的数据交换速度远高于磁盘速度上千倍， 极大提高系统性能。 3. 扩展和伸缩性：以Gemfire构建的应用云平台，是以 x86 PC服务器为主的硬件基础。在保证系统的性能下，此平台可 以随着客户业务的成长来任意调配x86服务器的数量，避免以后昂贵的硬件升级带来的困扰。经测试结果显示，整个系统性 能可随着服务器的数量的增加实现几乎线性的成长。 4. 数据可靠性：在同个集群里面可以有多个数据节点备份，数据可以自动同步或是将内存数据

17、持久化到硬盘或是数据库 5. 跨地域的数据分布或同步 ：可以透过“广域网”将指定的 Gemfire集群的内存数据“实时同步”到异地的数据中心。 这是属于“应用层”的数据同步异于传统的“数据库”同步。 6. Pivotal Gemfire使用 x86 PC服务器，其性价比远远高于 Unix 小型机。 版权所有 严禁拷贝上海全成通信技术有限公司 案例分析：12306网站引发的网站架构设计和讨论 版权所有 严禁拷贝上海全成通信技术有限公司 22 某某联通预支充值服务实现办法（3） OCS改造： 1.创建DCO信用账本并开辟空间存储DCO信用额度 OCS方需在现有的OCS平台中开辟专门的空间存储DCO

18、信用额度（DCO信用额度是信用账本的上限值，且是固定值，除非DCO平台请求 对用户的信用额度进行修改）； OCS方需在现有OCS平台中开辟供DCO使用的专有信用账本（DCO信用账本），用于存储DCO信用余额（信用账本的上限值即为DCO 信用额度值）。 2. 修改扣费及用户充值时计算逻辑并更新相应账本 OCS平台需要对当前现金账本（含：默认信用账本）、DCO信用账本、单停漫游信用账本（被叫信用度账本）的扣费计算逻辑、充值恢 复计算逻辑按本文上述的业务需求进行修改； 计算逻辑修改的目的是用于计算DCO信用使用后的余额并更新到DCO信用账本、以及计算用户充值时DCO信用账本恢复后的余额并更新 到DC

19、O信用账本。 3. 开发接口实现OCS平台与DCO平台之间的数据交互（非实时） 提取DCO平台上线前的用户打分数据（用户充值记录、用户当前状态）及上线后的每日/每月传输数据（用户充值记录、用户日末余额、 用户当前状态、信用额度应答数据），并生成指定格式的数据文件（如：CSV格式）以FTP方式上传到指定的服务器路径； OCS以FTP方式从指定的服务器路径下载批量用户授信请求文件（如：CSV格式），并在OCS平台内对用户的授信额度进行修改； OCS将批量用户授信结果文件（如：CSV格式）以FTP方式上传到指定的服务器路径，由DCO平台对授信结果进行更新。 OCS将批量每日传输如4.8所述的用户数据

20、文件（如：CSV格式）以FTP方式上传到指定的服务器路径。 版权所有 严禁拷贝上海全成通信技术有限公司 23 某某联通预支充值服务实现办法（1） 版权所有 严禁拷贝上海全成通信技术有限公司 24 某某联通预支充值服务实现办法（2） 业务内容实现机制 服务生效 1) OCS创建DCO信用账本，该账本可以用于扣款 2) 该信用账本可以按照生效时间启用,失效时间停用 3) 该信用账本可以根据初始授信额度更新申请表的要求更新 4) 信用账本创建时需要对用户状态进行校验，仅在有效期内可以创建信用账本。 服务使用 1) 信用额度使用范围为：为用户提供信用额度用于用户所有消费行为（任何消费都可以使用信用账本

21、的额度，包括短 信，语音，数据，增值业务，套餐，第三方增值业务等）。 2) DCO信用账本的使用优先级：现金账本 DCO信用账本。 用户消费过程中，当用户自身余额（现金账本）用尽时，开始使用DCO信用账本； 服务取消 1) 信用账本做失效处理（将失效时间置为当前时间，并且用户的信用额度为0，坏账为用户当前未恢复的信用额度） 2) 任何状态下都可以失效信用账本。 3) 用户投诉和坏账用户才会取消信用。 信用额度的恢复 1) DCO信用账本的恢复优先级为： 欠费DCO信用账本现金账本 2) 用户充值时，会将DCO账本的已使用金额进行返还。 3) 只有现金充值才能恢复信用账本，非现金充值不能用户信用

22、恢复。 信用额度的调整 信用额度调整时的处理原则为，调减时，OCS需要做出一些判断： 如果用户的DCO信用账本余额信用额度调减量，则不调整，并返回相应的错误代码。 版权所有 严禁拷贝上海全成通信技术有限公司 25 某某联通预支充值服务实现办法（2） 版权所有 严禁拷贝上海全成通信技术有限公司 预支充值服务整体方案 标准硬件配置方案 乙方提供预支充值服务的硬件平台 综合安全性和数据传输性能考虑，建议服务器放置于运 营商的数据中心内 预支充值硬件平台与预付费系统接口相连，进行数据传 输 预支充值硬件平台遵守运营商安全管理规范，接受运营 在硬件层面的监管 乙方公司通过VPN远程监控服务的运行情况并提

23、供运行 支撑 用户NOC 服务器 1 服务器 2 服务器 服务器 n 防火墙防火墙 交换机 交换机 交换机 eth0 eth0 eth0 eth0 eth1 eth1 eth1 eth1 ILO ILO ILO ILO eth2 eth2 eth2 eth2 ILO ZONE ILO ZONE 乙方硬件平台乙方或运营商提供 数据中心 版权所有 严禁拷贝上海全成通信技术有限公司 27 需要配合的工作 打分、统计数据接口 打分通知数据处理接口 服务取消/再加入数据接口 短信平台数据接口 接口 开发 数据中心内的位置空间; 相应网络、电力、环境等; VPN连接 数据 中心 建议使用运营商统一热线电话

24、 提供客户服务 乙方公司将提供工作平台、培 训及相关支撑 热线 服务 建方安排一名经验丰富的业务部 门工作人员负责与我方对帐核算 需要在预付费系统中开发相应的 结算统计报表 对帐 结算 预支充值服务开通技术改造 预支充值服务使用与恢复改造 其他可能涉及的改造 核心 逻辑 版权所有 严禁拷贝上海全成通信技术有限公司 28 接口开发 No. 数据表 1 充值信息表 2 通话消费表 3 数据消费表 4 短信或增值消费表 5 日末余额表 6 用户状态表 7 转网用户表 8 套餐信息表 9 预支额度表 No. 数据表 1 预支额度更新请求表 2 预支额度更新反馈表 No. 数据表 1 预支额度更新请求表

25、 2 预支额度更新反馈表 No.数据表 1 预支充值服务短信通知 2 预支充值服务短信退订 手机预付费用户 预付费系统 信用账 本 账本 资金账 本 预支充值平台 行为分析 与打分 结算统计 客服预支充值管 理平台 充值/消费 打分统计 数据接口 批量额度更新 取消/再加入 服务取消/再加入 短信平台 短信确认 与取消 1 2 3 4 打分统计数据接口 1 打分通知数据处理接口 2 服务取消/再加入数据接口3 短信平台数据接口 4 版权所有 严禁拷贝上海全成通信技术有限公司 29 接口开发 接口接口描述主要功能数据传输方式数据内容数据量估计 1打分统计 数据接口 将用户充值、消费等数据从 预付

26、费系统传输到预支充值 平台，用于数据分析处理和 客户打分 非实时，每天晚 上批量传输 充值数据 消费数据 日末余额数据 用户状态、离网信息等 与用户数量直接相关，约为 500M1 GB/每日 (* 按照10万用户估计，以下同） 2打分通知 数据处理 接口 将打分结果（预支充值额度 表）从预支充值平台传输到 预付费系统，用于向用户信 用模块充值 非实时，每月一 次批量传输 打分结果（预支充值额 度表：用户ID、预支充 值额度） 与用户数量直接相关，初步估 计10MB/每月 3服务取消/ 再申请数 据接口 将用户取消服务的数据从预 支充值平台传输到预付费系 统系统 实时传输/非实 时每天晚上传输

27、取消服务的用户列表初步估计，平均小于100条记 录每天 4短信平台 数据接口 将预支充值服务的用户及信 用额度数据传递给短信平台， 用于生成短信提醒用户该项 服务 主要采用非实时， 批量传输方式。 提供预支充值服务的用 户及预支充值额度 根据用户数量，初步估计 10MB/每月 版权所有 严禁拷贝上海全成通信技术有限公司 30 系统改造 打分和服务生效流程 手机预付费用户 预付费系统 信用账 本 账本 资金账 本 预支充值平台 行为分析 与打分 结算统计 客服预支充值管 理平台 短信平台 1.充值/消费 2.充值消费等数据 3.预支额度更新 5.服务取消/再申请 4.下发短 信通知 6.服务取消

28、/再申请 7.预支服务取消/再申请 1.用户消费和充值的详单被将被预付费 系统记录 2.这些记录每天晚上通过接口传递到预 支充值平台 3.预支充值平台进行客户分析、分类、 打分，并把预支额度表(增量数据)通 过线下的方式传递给预付费系统，由 预付费系统将额度更新到用户的信用 帐本，并传回额度更新回执 4.预付费系统通过短信平台通知用户 5.用户可以通过客服热线或短信选择退 出/再申请 6.客服人员通过预支充值管理平台 （Web）执行查询确认和执行退出/ 再申请操作，并通知预支充值平台 7.预支充值平台通知预付费系统取消预 支额度 5.服务取消/再申请 6.服务取消/再申请 版权所有 严禁拷贝上

29、海全成通信技术有限公司 31 系统改造 服务使用与恢复量计算 使用量计算方式一： 预支充值平台通过信用账本的消费记录计 算使用量： a. 信用账本使用优先级低于现金账本，恢 复优先级高于现金账本 b. 可以获得信用账本所有的消费记录 c. 可以区分跨账本消费记录 另外，关注： a. 消费记录是否包含账本信息 b. 如果发生调减账，采用何种方式，是否 会对服务计算产生影响 手机预付费用户 预付费系统 信用账 本 账本 资金账 本 预支充值平台 行为分析 与打分 结算统计 客服预支充值管 理平台 短信平台 1.充值/消费 2.充值消费等数据 3.预支额度更新 5.服务取消/再申请 4.下发短 信通

30、知 6.服务取消/再申请 7.预支服务取消/再申请 5.服务取消/再申请 6.服务取消/再申请 版权所有 严禁拷贝上海全成通信技术有限公司 32 系统改造 服务使用与恢复量计算 使用量计算方法二： 预支充值平台通过日末账户总可用余额（预付费系统 需要设置每日24:00进行批量余额查询）和用户的预 支额度计算预支服务的使用量： 如果 (日末账户总可用余额 - 预支额度) = 0，预 支服务使用量 = 0. 如果用户在当天有充值行为: 如果 （充值前账户总可用余额 - 预支额度） 0， 预支服务使用量 = 预支额度充值前账户总可用 余额 如果 （充值前账户总可用余额 - 预支额度）0， 预支服务使

31、用量 = 0. 在用户充值时，优先对预支金额进行恢复，恢复量等 于充值前的预支金额使用量。用户充值后，开始下一 个预支服务使用量的计算过程。 关注点/讨论点： 账户总可用余额的计算办法及专用账本的扣费限制 手机预付费用户 预付费系统 信用账 本 账本 资金账 本 预支充值平台 行为分析 与打分 结算统计 客服预支充值管 理平台 短信平台 1.充值/消费 2.充值消费等数据 3.预支额度更新 5.服务取消/再申请 4.下发短 信通知 6.服务取消/再申请 7.预支服务取消/再申请 5.服务取消/再申请 6.服务取消/再申请 版权所有 严禁拷贝上海全成通信技术有限公司 33 系统改造 转/离网和服务取消/再加入流程 手机预付费用户 预付费系统 信用账 本 账本 资金账 本 预支充值平台 行为分析 与打分 结算统计 客服预支充值管 理平台 短信平台 1.转/离网 2.转/离网数据 9. 服务取消/再加入结果 3.服务取消/再加入 7.服务取消