大型互联网架构设计

1“大型”网站技术架构探讨2目录大型网站架构的目标与挑战网站架构演变及其技术脉络架构设计理论与原则讨论及总结3大型网站架构的目标与挑战•■何谓“大型”网站？网站日均流量[IP/PV]≈5,972,587PV≈9,376,962≈229,680,000PV≈2,955,981,600≈25,680,000PV≈222,132,000≈5,532,000PV≈25,723,800≈300,000PV≈747,000没有统一的判断标准，流量大小是一个重要指标日均流量至少IP1,000,000才算大型网站4大型网站架构的目标与挑战•■何谓“大型”网站？网站内容是否“动态”才是关键5大型网站架构的目标与挑战•■移动APP的几个重要指标网站内容是否“动态”才是关键6大型网站架构的目标与挑战•■网站架构目标与挑战每个目标背后面临着技术、设计、维护等诸多方面的挑战。而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。负载均衡数据备份异地容灾。。。高速缓存并行计算异地镜像。。。开发框架多层设计业务分割。。。7大型网站架构的目标与挑战网站架构演变及其技术脉络架构设计理论与原则讨论及总结8网站架构演变及其技术脉络■[Step1]Web动静态资源分离及其与DB物理分离优点：“简单”、安全性提高缺点：存在单点，谈不上高可用性（highavailability架构目标）技术点：应用设计要保证可扩展（framework很重要Spring/Beetle）、WebServer动/静态资源分离WebServer（Apache\Nginx\IIS\JBoss…）、DatabaseServer（Mysql\Oracle\Redis…）9■[Step1]技术点—Web动静态资源分离img,doc,js,css等静态资源使用单独的WebHTTPServer处理请求动态页面静态化处理网站架构演变及其技术脉络10■[Step2]采取缓存处理优点：简单有效、维护方便缺点：依然存在单点技术点：客户端（浏览器）缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存网站架构演变及其技术脉络减少对网站的访问减少对Web应用服务器的请求减少对数据库的查询减少文件系统I/O操作11■[Step2]技术点—客户端（浏览器）缓存技术点说明根据HTTP协议特性，修改Header参数（Cache-Control、Expires、Pragma、Last-Modified、Etag），让浏览器来缓存页面（一些优秀开发框架会对此做透明的封装，例如：Beetle）使用HTTP1.1协议，由于httppipelining技术特性，能够使用get请求的决不采取post请求为了节约带宽，压缩页面（Content-Encoding:gzip）；页面各个元素能“小”即“小”，例如：js包压缩，js合并，图片压缩等会话状态信息采取Cookie代替传统使用服务器Sessions对象存储习惯做法；使用Ajax实现页面局部刷新如果可能，可采取浏览器插件技术突破浏览器功能限制，将原本在服务器端运算，尽量迁到浏览器端。ActiveX/Applet/Flash/….HTML5最值得期待，她的出现必定改变整个Web世界能够让浏览器缓存的数据一定要缓存；浏览器能够处理的运算，决不放在服务器端来处理。网站架构演变及其技术脉络12■[Step2]技术点—前端页面缓存采用具备缓存功能的http反向代理服务器作前端页面缓存器，Varnish\Squid\Ncache\AiCache(商业)…【硬件F5】网站架构演变及其技术脉络13■[Step2]技术点—页面片段缓存ESI(EdgeSideIncludes)ESI需要服务器端支持，常见apache(mod_esi)、WebLogic、JSP标签库(JESI)等。网站架构演变及其技术脉络14■[Step2]技术点—本地数据缓存需要从数据库系统和Web应用服务器两个层面考虑缓存优化网站架构演变及其技术脉络技术点说明关系数据库系统（如：Oracle\MySql）QueryCache策略：一般以sql为key来缓存查询结果，尽量不要拼sql，使用PreparedStatement的“？”模式sql；QueryCache大小要根据数据库系统具体情况合理设置，过大只会浪费内存，参考值：128M关系数据库系统DataBuffer策略：就是数据库数据内存缓存器，其访问命中率决定数据库性能，可根据实际物理内存大小适量增大，如：MySql建议buffer值为物理内存60-80%应用服务器Cache包括：对象缓存（例如：对象线程安全，做成单例），更新频率不大数据考虑缓存（如：基表数据、配置文件信息），考虑使用线程池，对象池，连接池等常见java解决方案：map\OSCache\EHCache等15■[Step3]增加机器做HA、数据库读写分离网站架构演变及其技术脉络优点：增加服务器和HA机制，系统性能及可用性得到保证缺点：读写分离，增加程序难度，架构变复杂，维护难度增加技术点：负载均衡、DAL、数据库读写分离16■[Step3]技术点—负载均衡网站架构演变及其技术脉络类型说明DNS负载均衡实现简单、有Cache缺乏灵活性，但对分区域（如构建CDN方案）访问简单有效反向代理软件HAProxy、Nginx、Apache、Lighttpd等硬件产品F5、NetScaler等LVS(LinuxVirtualServer)自己写代码某些情况下简单有效17■[Step3]技术点—数据库读写分离及DAL网站架构演变及其技术脉络■读写分离逻辑分批■负载均衡■失效转移（failover）■数据库分区透明支持■两大实现模式：独立Proxy服务器；单独API库文件各个数据库厂商都有自己复制方案常见通用方案：ETL、GoldenGateTJS…18■[Step4]CDN、分布式缓存、分库网站架构演变及其技术脉络优点：异地缓存有效解决不同地方用户访问过慢的问题；分库策略带来网站性能整体提升缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，架构开始臃肿了技术点：CDN、分布式缓存、Shard分库19■[Step4]技术点—CDN网站架构演变及其技术脉络CDN(ContentDeliveryNetwork)内容分发网络将网站的内容分发到最接近用户的网络“边缘”，使用户可以就近获取，从而解决互联网网络拥挤的状况，提高用户访问的响应速度。适合静态内容很多（如：静态页面、图片、视频等）及页面内容实时性要求不高的网站，如：新闻类门户网站CDN构建可以做的很简单，也可以很复杂，主要根据自己网站实际情况而定20■[Step4]技术点—分布式缓存网站架构演变及其技术脉络本地缓存性能优秀，但容量有限，无伸缩性采用分布式缓存方案突破容量限制，具备良好伸缩性；但分布式涉及远程网络通信消耗其性能本地缓存来得优秀，并可涉及节点状态维护及数据复制问题，其稳定性和可靠性是个挑战。目前流行分布式缓存方案：memcached、membase、redis等，基本上当前的NoSQL方案都可以用来做分布式缓存方案21■[Step4]技术点—分库网站架构演变及其技术脉络读写分离（简单有效，前面已介绍）垂直分区良好的松耦合的模块化设计是垂直分库的前提22■[Step4]技术点—分库网站架构演变及其技术脉络水平分区（Shard）分片Key识别（划分检索依据）是关键是否还有其它招？用NoSql数据库部分替换关系数据库23■[Step5]多个数据中心，向分布式存储和计算的架构体系迈进网站架构演变及其技术脉络优点：多数据中心，带来更高质量区域服务体验；分布式存储及计算架构有效解决pb级数据量存储、检索及计算性能问题缺点：架构复杂、数据同步、一致性及系统维护、技能要求等成本十分高技术点：分布式文件系统、Map/Reduce、Key-Value存储24■[Step5]技术点—向分布式存储计算解决方案[DFS、Map/Reduce、Key-ValueDB]网站架构演变及其技术脉络DFS分布式文件系统，如：Lustre\HDFS\GFS\TFS\FreeNas等Map/Reduce算法（计算框架），基本上现有NoSQL数据库中都支持此算法。Key-ValueDB，也作为NoSQL解决方案，如：BigTable\Tair\Hbase\HyperTable等提供完整解决方案：Google(GFS|Map/Reduce|BigTable)ApacheHadoop(HDFS|Map/Reduce|HBase)25凡客关键系统架构26订单面临的矛盾数据量倍增响应效率还要更高电子商务订单处理优化分析订单查询服务内存硬盘空间索引应用服务器——传统解决方案不能根本上解决问题27热数据DB(SQLServer，NoSQL)冷数据DB(SQLServer，NoSQL)路由服务6个月以上到终结点的冷数据新增热数据2013年订单工作规划——第一个重点项目解决方案：订单数据冷热分离查询订单入口读新建修改订单入口写Hadoop(提供数据分析用)28基于消息队列的订单处理机制1订单处理流程的现有机制2订单处理流程的改进方案3探讨主要内容29订单处理流程的现有机制前台主库后台主库后台只读读数据写数据分发复制创建订单服务及应用1……N订单同步服务*4订单支付服务*4订单取消服务*2订单转有效服务*3订单拦截服务*2下游系统抓取服务现有处理流程存在问题30订单处理流程的现有机制WHY？WHAT？WHERE？TheProblems问题Windows服务不能保证高可用性数据按模流向固定服务单点特性性能瓶颈（转有效服务3*30单/s）Timer组件，两次任务之间需要间隔数据按模大粒度分块，并行度不高相同业务流程，各分支耦合数据库读取频繁压力很大抓取数据模式更新较多时间集中实时数据来源流程存在问题剖析HOWcanwesolvetheseproblems?31基于消息队列的订单处理机制1订单处理流程的现有机制2订单处理流程的改进方案3探讨主要内容32订单处理流程的改进方案使用WCF服务，数据改抓为推；构建基础模块，解耦调用方式。保留windows服务，降低查询频率，查缺补漏，处理失败、异常等情况。使用消息队列，解耦服务依赖，试点验证，选择合适的消息队列。缓存中间数据，减少数据更新，分析业务要求，差别对待一致性。业务驱动纠错机制通信机制缓存数据解决方案订单业务的处理是以使用windows服务从数据库抓取数据的方式驱动根本原因33订单处理流程的改进方案1.1使用WCF服务，数据由抓改推Step1业务流的服务接口实现主要任务风险订单同步服务订单转有效服务订单拦截服务下游业务方服务订单新建服务支付同步服务支付请求服务•完成原windows服务中业务逻辑的wcf封装•各服务按照业务流程组装起来服务调用失败，造成的控制流中断34订单处理流程的改进方案基础模块解决方案主要任务风险完成基础模块开发，达到解耦服务调用方式的目的异步调用服务异常时，线程资源的紧缺造成消费方服务阻塞大量发生异常时的控制，放弃调用，保证消费方的线程资源；使用消息队列FactoryvoidNotify(Actionobjectdel)（统一的事件触发）Handler1（如异步直接调用）Handler2（如写入消息队列）1.2构建基础模块，解耦调用方式Step135订单处理流程的改进方案2保留windows服务，查缺补漏Step2业务流某节点故障？原有Windows服务订单同步服务订单转有效服务订单拦截服