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

大型网站技术架构核心原理与案例分析2015年8月版权所有严禁拷贝上海全成通信技术有限公司2大型网站架构演化●京东案例：2011年末，京东图书促销，并发访问过高浏览页“Serviceistoobusy”紧急采购10台服务器，依然如故刘强东请信息部们人员“喝茶”●12306铁路订票网：2012年初，12306春运期间崩溃运营时间很短，缺乏大规模并发处理经验12306架构师对这种访问趋势没概念导致直接崩溃，12306被媒体技术“喷”原因：网站技术架构的问题互联网发展短短20多年的时间，世界发生了巨大变化：●信息检索●电子商务●文化娱乐●社交通信问题：一边是火热的发展，一边是不堪重负的网站架构，如何打造高可用、高性能、易扩展、可伸缩且安全的网站，并且迅速能够实现应用。版权所有严禁拷贝上海全成通信技术有限公司3●高并发、大流量：Google日均PV数35亿，日均IP访问数3亿；腾讯QQ1.4亿在线；淘宝12年双11，活动开始一分钟1000万访问用户●高可用：7X24小时服务，不间断●海量数据：需要存储管理海量数据，需要大量的服务器，百度收录数百亿网页；Google有百万台服务器在全球●用户分布：用户分布范围广，全国甚至全球，各地网络环境千差万别，运营商互联互通的问题●安全环境恶劣：互联网的开放性，使得网站更容易受到攻击，很多网站泄露密码及重要数据，用户也受到影响●需求变更频繁快速：和传统软件不同，互联网产品为了快速适应市场，满足用户需求，产品发布频率高，新版本不断上线●渐进式发展：不是所有网站一开始就是大而全，都是从小网站逐渐发展起来的，好的网站都是慢慢运营出来大型网站架构演化大型网站软件系统的特点版权所有严禁拷贝上海全成通信技术有限公司4大型网站架构演化发展历程初始阶段的小网站应用服务与数据服务分离使用缓存改善网站性能应用服务器集群提高并发处理能力数据库读写分离反向代理和CDN加速网站响应分布式文件系统和分布式数据库使用NOSQL和搜索引擎业务拆分分布式服务发展历程版权所有严禁拷贝上海全成通信技术有限公司5大型网站架构演化发展历程初始阶段的小网站应用程序、数据库、文件等所有资源在一台服务器上，操作系统通常为Linux、应用程序用PHP开发，部署在Apache上，数据库使用MySQL，汇集各种免费开源软件及一台廉价的服务器就可以开始网站的运营和发展版权所有严禁拷贝上海全成通信技术有限公司6大型网站架构演化发展历程应用和数据分离：改善访问性能和数据存储，支持业务继续发展业务发展1、越来越多的用户访问（性能变差）2、越来越多的数据存储（存储空间不足）应用和数据分离1、应用服务器单独一台服务器2、文件服务器单独一台服务器3、数据库服务器单独一台服务器侧重点：应用服务器需要强大CPU用于计算逻辑文件服务器需要大磁盘存储文件数据库服务器需要大内存和快速磁盘版权所有严禁拷贝上海全成通信技术有限公司7大型网站架构演化发展历程使用缓存改善网站性能：减少数据访问压力，改善数据库写性能网站访问的二八定律1、80%的访问集中在20%的数据上2、20%数据集中在内存缓存网站使用缓存1、本地缓存2、远程分布式缓存重点：本地缓存速度快，缓存数据量有限远程分布式缓存采用集群瓶颈即将出现在单一的应用服务器版权所有严禁拷贝上海全成通信技术有限公司8大型网站架构演化发展历程使用应用服务器集群改善网站并发处理能力业务持续发展1、访问用户持续增加2、网站访问性能不佳应用服务器集群1、通过负载均衡将访问分发应用服务集群2、应用服务器集群是可伸缩性的重点：不要去试图更换强大的服务器采用服务器集群是更好的扩展性能的方式即将出现的瓶颈为数据库服务器版权所有严禁拷贝上海全成通信技术有限公司大型网站架构演化发展历程数据库读写分离：改善数据库负载过高业务持续发展1、数据库不能避免读写操作2、用户增多，数据库负载过高数据库读写分离1、数据库主从关系2、数据更新同步重点：数据库读写分离，从数据库主读应用服务器访问数据模块需要改造网站响应的问题解决网络复杂的问题版权所有严禁拷贝上海全成通信技术有限公司大型网站架构演化发展历程使用反向代理和CDN加速网站响应网络环境复杂1、用户分布范围广2、网络环境复杂反向代理和CDN1、CDN虚拟网络，加速访问响应2、直接访问反向代理服务器重点：CDN节点重新定向访问用户最优原则反向代理和CDN基础应用都为缓存技术分布式文件系统和分布式数据库版权所有严禁拷贝上海全成通信技术有限公司持续的业务发展1、不是任何一台几台服务器可以支撑2、分布式文件服务器和分布式数据库服务器分布式数据库是网站数据库拆分的最后一招1、数据拆分2、业务拆分重点：服务器集群的应用数据库服务器集群的模式NOSQL数据库和搜索引擎的技术引应用分布式文件服务器和分布式数据库应用大型网站架构演化发展历程版权所有严禁拷贝上海全成通信技术有限公司持续的业务越来越复杂1、对数据存储要求复杂2、对数据检索要求复杂NOSQL和搜索引擎对分布式可伸缩支持好1、NOSQL数据库，读操作和非格式数据2、搜索引擎迅速定位数据，降低数据访问重点：NOSQL和搜索引擎应用数据访问模块改造，减少应用程序管理数据业务拆分大型网站架构演化发展历程使用NOSQL和搜索引擎版权所有严禁拷贝上海全成通信技术有限公司大型网站架构演化发展历程业务越来越复杂1、应用越来越复杂2、产品和业务越来越繁杂业务拆分，解决日益复杂的应用场景1、产品拆分，首页，订单，商品，支付2、应用之间的数据交换（超链接；消息）各应用还是集中访问一个数据存储系统需要考虑应用和数据库连接的资源平衡业务拆分（即应用拆分，应用之间的数据交互）版权所有严禁拷贝上海全成通信技术有限公司大型网站架构演化发展历程业务越来越复杂1、应用越来越复杂2、数据库连接资源不足提取公共业务，服用业务连接数据库1、公共业务提取，独立部署2、分布式应用调用业务服务思想大型网站的架构演化到这里，基本的技术问题都能得到解决，事物发展到一定阶段，都会象更强大方面发展，诸如云计算平台的建设，将资源变成商品出售。分布式服务（服务分布，业务连接共用）版权所有严禁拷贝上海全成通信技术有限公司大型网站架构演化的价值观大型网站架构技术的价值观1、大型网站架构的核心价值不是从无到有直接搭建大型网站，而是随着业务的发展慢慢演化而来的，所需的技术也是慢慢演化而来的，不是剧烈的革命和推翻，如GOOGLE；taobao等2、大型网站技术发展的力量是网站发的业务发展，是业务成就了技术，是事业成就了人，所以投身互联网的前提是理清楚业务，而不是四处挖高手，仿照成功的互联网公司打造技术平台，这无疑是南辕北辙，缘木求鱼两个极端一方面：随着互联网高速发展，越来越多的软件技术和产品从互联网公司诞生，挑战传统软件巨头的江湖地位另一方面：绝大多数的中小网站几十年如一日的使用LAMP技术开发自己的网站，性价比超高的同同时，应付业务绰绰有余版权所有严禁拷贝上海全成通信技术有限公司网站架构设计的误区1、一味的追求大公司巨大成功的光环效应，加上挖来的技术高手的影响，网站架构决策时，最有力的的一句话变成了“淘宝就是这样搞的”或者“Google就是这样的结构”,大公司的经验值得借鉴，但不要盲从，失去了坚持自我的勇气2、为了技术而技术：网站架构和技术是为业务而存在的，脱离了业务发展的实际要求，一味追求新技术会增加成本，反而走了弯路。3、企图用技术解决所有问题：往往很多网站运营出了问题，都是考虑用技术去解决，而往往忽略了业务架构，有的时候重新梳理业务架构，调整业务需求，也会解决很多棘手的问题总结：时至今日，大型网站的架构演化方案已经非常成熟，很多网站建立之初就是搭建在大型网站提供云计算服务基础上的，所需要的资源都可以按需购买，线性伸缩，所以亲历网站从小变大的架构演化的工程师越来越少，所以我们更应该去了解和理解网站架构技术方案的来龙去脉和历史渊源，这样才能在技术选型和架构决策时有的放矢。版权所有严禁拷贝上海全成通信技术有限公司案例分析：12306网站引发的网站架构设计和讨论2012年初，铁道部12306网上购票系统为了解决购票半夜早起，在瑟瑟寒风中排队挨冻的痛苦，然而各种技术和业务的问题，12306无法面对“春运”期间的瞬间海量高并发，出现访问过慢，频繁报错甚至直接无法登陆等现象，顿时国内怨声一片，就此引发很多热帖。版权所有严禁拷贝上海全成通信技术有限公司案例分析：12306网站引发的网站架构设计和讨论国企=垄断+腐败+低效（媒体和技术公司的看法）问题和难点分析业务架构问题：1、对于春运一票难求的中国，火车票网购本身就存在巨大风险2、整点售票改为分时段售票3、售票引入排队机制技术架构问题：1、对高并发，高流量预计不足2、网站架构不合理3、架构师缺乏经验版权所有严禁拷贝上海全成通信技术有限公司案例分析：12306网站引发的网站架构设计和讨论技术改造的关键：“利用云计算资源“，“按需及时扩充“和”快速调整，“建立可伸缩扩展的云应用平台云计算的基础架构虚拟化已经非常成熟，当网络阻塞时，可以动态增加带宽，当服务器CPU到达高位时，可以快速从资源池获取虚拟机资源来分摊负荷。底层的架构都虚拟化后，网络设备，Web服务器，应用服务器都可以做“伸缩性”的扩展；但遇到一个难点就是“12306的应用系统框架”无法支持可伸缩扩展。原因是关系型数据库无法支持“应用系统”的伸缩扩展。客户已经投入大笔经费在IT方面的建设，但“系统框架设计”还是沿用10几年前的三层设计，而且每年都在原来的基础上做不断的升级。当业务不断成长时，数据量也跟着成长，功能越来越多，但系统性能越来越差。12306网站技术改造思路版权所有严禁拷贝上海全成通信技术有限公司案例分析：12306网站引发的网站架构设计和讨论12306网站技术改造办法12306最后选择PivotalGemfire作为系统改造的平台，其主要原因如下：1.关联数据节点设计：可以根据客户的业务逻辑特性和数据关联性，将关联性强的数据放置于同一个服务器节点，提高系统性能，避免分布式系统服务器的频繁数据交换。2.将数据移到内存：由于数据是放在内存里面，屏蔽传统数据库频繁访问，CPU与数据库的交互作用，影响服务器性能。内存的数据交换速度远高于磁盘速度上千倍，极大提高系统性能。3.扩展和伸缩性：以Gemfire构建的应用云平台，是以x86PC服务器为主的硬件基础。在保证系统的性能下，此平台可以随着客户业务的成长来任意调配x86服务器的数量，避免以后昂贵的硬件升级带来的困扰。经测试结果显示，整个系统性能可随着服务器的数量的增加实现几乎线性的成长。4.数据可靠性：在同个集群里面可以有多个数据节点备份，数据可以自动同步或是将内存数据持久化到硬盘或是数据库5.跨地域的数据分布或同步：可以透过“广域网”将指定的Gemfire集群的内存数据“实时同步”到异地的数据中心。这是属于“应用层”的数据同步异于传统的“数据库”同步。6.PivotalGemfire使用x86PC服务器，其性价比远远高于Unix小型机。版权所有严禁拷贝上海全成通信技术有限公司案例分析：12306网站引发的网站架构设计和讨论版权所有严禁拷贝上海全成通信技术有限公司22某某联通预支充值服务实现办法（3）OCS改造：1.创建DCO信用账本并开辟空间存储DCO信用额度•OCS方需在现有的OCS平台中开辟专门的空间存储DCO信用额度（DCO信用额度是信用账本的上限值，且是固定值，除非DCO平台请求对用户的信用额度进行修改）；•OCS方需在现有OCS平台中开辟供DCO使用的专有信用账本（DCO信用账本），用于存储DCO信用余额（信用账本的上限值即为DCO信用额度值）。2.修改扣费及用户充值时计算逻辑并更新相应账本•OCS平台需要对当前现金账本（含：默认信用账本）、DCO信用账本、单停漫游信用账本（被叫信用度账本）的扣费计算逻辑、充值恢复计算逻辑按本文上述的业务需求进行修改；•计算逻辑修改的目的是用于计算DCO信用使用后的余额并更新到DCO信用账本、以及计算用户充值时DCO信