大型网站技术架构：核心原理和案例分析（李智慧）-持续更新
2022-02-16 14:48:23 29 举报AI智能生成
全网大型网站亿级流量服务技术架构核心原理和案例分析（李智慧）-持续更新 大型网站架构演化（1） 大型网站架构演化的价值观（2） 大型网站架构模式（3） 大型网站架构要素（4） 大型网站架构案例分析（5）
作者其他创作
大纲/内容
淘宝网的业务发展历程
淘宝网技术架构演化
总结
淘宝网架构演化案例分析
wikipedia网站整体架构
wikipedia前端性能优化
wikipedia服务端性能优化
wikipedia后端性能优化
wikipedia性能优化策略
维基百科的高性能架构设计分析
分布式存储系统的高可用架构
分布式存储系统的故障分类
正常情况下系统访问结构
瞬时故障的高可用解决方案
临时故障的高可用解决方案
永久故障的高可用解决方案
不同故障情况下的高可用解决方案
海量分布式存储系统Doris的高可用架构设计分析
秒杀活动的技术挑战
秒杀系统的应对策略
秒杀系统架构设计
网站秒杀系统架构设计案例分析
写日志也会引发故障
高并发访问数据库引发的故障
高并发情况下锁引发的故障
缓存引发的故障
应用启动不同步引发的故障
大文件读写独占磁盘引发的故障
滥用生产环境引发的故障
不规范的流程引发的故障
不好的编程习惯引发的故障
大型网站典型故障案例分析
3、案例
最好的软件项目管理不是制定计划，组织资源，跟踪修正项目进展，对成员进行激励和惩罚。而是发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终的蓝图和愿景。每个人都是为实现自我价值而努力，不是为了领工资而工作。
一群优秀的人做一件他们热爱的事情，一定能取得成功
一旦做到这一点，项目组每个成员都会自我驱动，自觉合作，寻找达成目标的最优路径并坚韧不大的持续前进。在这个过程中，不需要拙劣的胡萝卜和大棒，最好的奖励就是最终要达成的目标本身，最大的惩罚就是这个美好的目标没有实现。
寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。
没有懒惰的员工，只有没被激发出来的热情。 所有强迫员工加班的管理者都应该为自己的无能而羞愧。
关注人而不是产品
是事情成就了人，而不是人成就了事
发掘人的优秀远比发掘优秀的人更有意义。
发掘人的优秀
在电影《十月围城》中一个年轻的革命党人说“ 我一闭上眼睛，就看到中国的明天 ”，这就是辛亥革命的蓝图。
创业者闭上眼睛就能看到企业的明天。软件产品的开发者闭上眼睛就能看到软件实现价值的那一刻，就是蓝图的力量
什么是蓝图？
产品要做什么，不做什么，要达到什么业务目标，都需要描述清楚
蓝图应该是表述清楚的
产品能为用户创造什么价值，能是吸纳什么样的市场目标，产品最终会长什么样，都需要形象的想象出来
蓝图应该是形象的
不管是内部还是外部沟通，都能够一句话说明白：我们在做什么。蓝图应该写在软件架构设计文档的扉页，写在邮件的签名档，写在内容即时通信群的公告上。
蓝图应该是简单的
在项目过程中，架构师要保持对目标蓝图的关注，对任何偏离蓝图的设计和决定保持警惕，错误的偏离要及时修正，必要的变更妖精打架讨论，并重新获得大家的认同。
架构师要持续保持对目标蓝图的关注
架构师要个项目组全体成员共同描绘一个蓝图，这个蓝图是团队能够认同的，是团队共同奋斗的目标。
共享美好蓝图
不要只有架构师一个人拥有架构
让其他人维护框架与架构文档
共同参与架构
不要企图在项目中证明自己是正确，一定要记住，你是来做软件的，不是来当老大的。所以不要企图区证明自己了不起，永远也别干这种浪费时间，伤害感情的事情。
很多时候，对架构和技术方案的反对意见，其实意味着架构和技术方案被关注，被试图理解和接受。架构师不应该对意见过于敏感，这时架构师应该做的是坦率的分析自己的设计思路，让别人理解自己的想法并努力理解别人的想法，求同存异。
对技术细节的争论应该立即验证而不是继续讨论，当讨论深入到技术细节的时候也意味着问题已经收敛，对于整体架构设计诶，各方意见正趋于一致。
当大家不在讨论架构的时候，表面架构已经融入到项目中、系统和开发中了，架构师越早被项目组遗忘，越表明架构非常成功；项目组离不开架构师，越表示架构还有很多缺陷。
学会妥协
我们活着不是为了工作，不是为了做设计，写程序，这些不是我们生活的目的。
我们活着是为了成就我们自己，而要想成就自己，就必须首先成就他人。
做成一个项目不但要给客户创造价值，为公司盈利，还要让项目成员获得成长。要让他们觉得通过这个项目，自己的知识技能和业务水平都得到了提高。项目结束时，大家会觉得不可思议：如此完美的产品，如此有挑战性的开发居然都是我们完成的。而且每个人都觉得自己在项目中至关重要不可或缺。
每个人都有成就的目标，而工作室达成自我成就的一种手段：通过工作的挑战，发掘自我的潜能，重新认知自我和世界。
架构师作为团队的技术领导者，在项目过程中不要去试图控制什么，带着一个弹性的计划和蓝图推进，团队会管好他们自己
成就他人
架构师Leader艺术
淘宝出现之后，人们发现购物可以更便宜，更便捷。
iPhone出现之后，人们发现手机可以不光用来打电话发短信。
而微信出现之后，人们才发现手机发短信甚至打电话竟然可以不花钱。
有些问题在被解决之后，人们才发现事情原来还可以这样啊。
当体验不能满足期望时，就会觉得出现问题。
如果直面期望和体验之间的差距，就会发现问题所在，找到突破点。
改善体验
降低期望只是回避了问题
降低期望
消除问题有两种手段
所谓问题，就是体验和期望之间的差距。
即使在一流的技术团队里，也一定有数不清的问题，只是人们习惯了这些问题，以至于无视他们的存在。
许多刚加入公司的新员工一开始就急着要做出成绩，但是由于不熟悉环境、四处碰壁、被打消了积极性，反而不利于长远发展 。其实新员工首先要做的事情就是融于团队，跟大家打成一片，只要能和团队一起共进退，你就不是一个人在战斗。等熟悉了情况，只带了水的深浅，在寻找突破口，择机而动。
融于团队，择机而动
新员工tips
在新环境中一时施展不开久开始怀疑自己的能力，进而担心被其他人怀疑自己的能力，于是努力想要证明自己，但是常常事与愿违，反而出乱子，伤害了公司和自己的利益。其实既然能经过层层考核和挑选进入公司，就已经证明你有和工作要求相匹配的能力，你要相信当初选中你的同事的眼光和能力。
新员工最不需要做的事情就是证明自己的能力。
发现问题、寻找突破
问题被发现，他只是问题发现者的问题，而不是问题拥有者的问题，如果想要解决一个问题，就必须提出这个问题，让问题的拥有者知道问题的存在！！！
把“我”的问题表述成“我们的问题”
给上司提封闭式问题，给下属提开放式问题
指出问题而不是批评人
用赞同的方式提出问题
提出问题tips
提出问题，寻求支持
在解决我的问题之前，先解决你的问题
适当的逃避问题
解决问题tips
解决问题，达成绩效
架构师职场攻略
也就是一般意义上的架构师，负责系统架构设计，同时也要负责架构的实施落地，演化发展、推广重构。
设计型架构师
充当救火队员的角色，系统出现故障或者“灵异现象”，会请他们出马解决，有时重要而紧急的项目也会有此类架构师主持。他们通常是公司的元老，对系统有全局性的认识，知道“水有多深”
救火型架构师
对某一领域有较深刻的认识，有时候甚至是鉴定的信仰者，乐于同他人分享自己的知识，希望能够推广自己的技术主张，此类架构师通常有较好的个人影响力。但有时候，由于自身的局限性或者不能跟上技术潮流的发展，会成为忽悠型的“大师”、偶像派的专家。
布道型架构师
架构师中的Geek，对某些问题的研究达到疯狂偏执的境地，精益求精追求完美。通常由于知识技能不够全面，不符合许多企业对架构师“高大全”的要求，此类架构师常有怀才不遇之疑惑。
Geek架构师
按作用划分架构师
夏尔巴人生活在喜马拉雅山麓，协助探险队或者登山爱好者攀登哪些8000米以上被称为“生命的禁区”的雪山，帮助他们运送给养到突击队营地，以及作为向导带领登山队员登顶。每一次成功对于登山队员是一次自我的超越，而对于夏尔巴人，不过是完成了一个工作。
夏尔巴人架构师通常会开发项目中最具技术难度和挑战性的模块，从而为整个项目的顺利进行铺平道路。
夏尔巴人架构师
传说在古希腊，城邦之间发生战争，如果有城邦向斯巴达人求援，斯巴达人只会派出一个人区协助，但是只要这一个人就可以扭转战局。
不管项目有多么艰难复杂，只要有斯巴达人架构师，大家就会坚信，项目一定会顺利完成。斯巴达人架构师带给项目组的，不只是技术和方法，更重要的是必胜的信念。这种信念是架构师自己积累起来的气场和影响力。
斯巴达人架构师
此类架构师或者有傲人的学历，或者有辉煌的履历，或者仪表堂堂，或者口吐莲花，但是公司里面如果有个吃人的怪兽，悄悄地把此类架构师都吃光了，也没人会发现。
达官贵人架构师
按效果划分架构师
负责具体互联网产品的技术架构
当产品业务规划确定后，产品架构师就要开始产品的架构设计了，和运营团队确定PV数，用户数、商品数等产品运营目标、发展规划、非功能指标。
和产品经理确定功能需求、模块划分等功能目标。
和项目经理确定各种开发资源。
获得必要的信息后进行整体架构设计，参与项目开发。
项目架构师一般会参与产品的整个生命周期。
产品架构师
有时候也被称为平台架构师，此类架构师一般有专门的称呼，比如DBA等
此外，根据具体的职责，在数据挖掘、搜索技术、安全诚信、运维监控等领域也有专门的架构师。
基础服务架构师
按职责角色划分架构师
架构目标只是完成功能、通常，这不叫架构
只关注功能的架构师
除了产品功能，架构设计业关注性能、伸缩性、安全性、可用性、系统未来的扩展性，以及上线后易于运维管理、监控报警、故障修复等非功能目标。
关注非功能的架构师
架构设计不但关注功能目标和非功能目标，同时还考虑开发团队的成员特点，进度安排、开发过程等，使架构设计和项目管理完美融合。
关注团队组织和管理的架构师
架构设计不但关注产品的各项功能、非功能指标和开发过程的可实现性，还关注产品运营是否合理方便，能否达到运营目标，技术架构兼顾产品业务架构。
关注产品运营的架构师
不但关注前面提到的所有方面，还会结合技术发展趋势、公司战略目标、个人及团队发展方向，区思考产品未来的发展前景。
为产品的发展演化符合历史发展趋势而设计并未起奠定一个坚实的基础。
关注产品未来的架构师
按关注层次划分架构师
和团队相处日久，通常情况下团队成员感觉不出他的存在，貌似没有她工作也可以完成的很好，但是如果他真的离开了，大家久新联空落落的，没了主心骨。
最好的架构师
深得团队成员的敬重和信任，承担项目中的重要设计开发工作，团队几乎离不开他。
好的架构师
承担了项目中大部分的技术工作，却常常因为团队成员不符合自己的期望而经常雷霆大发。
一般的架构师
既无技术实力也不善于处理人际关系，常被团队成员鄙视，主要工作就是给大家添乱、制造笑话和八卦的谈资。
差的架构师
通过制造压力驱使团队成员努力区完成一些无价值的工作，让每个人都忙碌不堪以使大家都没有注意到他自己其实不能胜任工作。
这种架构师对组织整体和团队成员的伤害无以复加，却常常因为敬业和努力的形象而得到老板的肯定。
最差的架构师
按口碑划分架构师
从问题和需求出发，结合个人经验、组织资源、业界模式进行架构设计，中规中矩，能够切实可行的解决问题满足需求，是架构师中的普通青年。
普通架构师
除了普通架构师那样在架构设计中解决问题，文艺架构师还会在架构设计中进行一些更前瞻性的思考和别出心裁的设计。
此类架构师的设计文档通常透着文艺青年的小清新范儿，喜欢在文档的开头描叙他们与众不同的设计理念和风格。
文艺架构师
不包括那些完全不能胜任架构设计工作的架构师，此类架构师喜欢在架构设计中堆砌概念和模式，设计文档宏大而不着调，面面俱到却不解决具体问题，说起来头头是道却不知如何落地。
其根源不是不了解真正的问题就是不掌握正确的方法。有时候也不排除这样一种可能性：做架构设计的目的是为了炫耀自己知道这么多术语。
1+1架构师
非主流方式划分架构师
漫谈网站架构师
子主题
前端是指用户请求到达网站应用服务器之前经历的环节，通常不包含网站业务逻辑，不处理动态内容。
概述
并不是优化浏览器，而是通过优化响应页面，加快浏览器页面的加载与显示，常用的有页面缓存、合并HTTP减少请求次数，使用页面压缩等
浏览器优化技术
内容分发网络，部署在网络运营商机房，通过将静态页面内容分发到离用户最近的CDN服务器，使用户可以通过最短路径获取内容。
CDN
静态资源，如JS，CSS等文件部署在专门的服务器集群上，和web应用动态内容服务分离，并使用专门的（二级）域名。
动静分离，静态资源独立部署
图片不是指网站Logo，按钮图标等，这些文件术语上面提到的静态资源，应该和JS、CSS部署在一起。这里的图片指用户上传的图片，如产品图片、用户头像等，图片服务同样使用独立部署的图片服务器集群，并使用独立（二级）域名。
图片服务
部署在网站机房，在应用服务器，静态资源服务器、图片服务器之前，提供页面花奴才能服务。
反向代理
域名服务，将域名解析成IP地址，利用DNS可以实现DNS负载均衡，配置CDN也需要修改DNS，使域名解析后指向CDN服务器。
DNS
技术要素
前端架构
网站业务是多变的，网站的大部分软件工程师都是在加班加点开发网站业务，一个好的开发框架至关重要。
一个号的开发框架应该能够分离关注面，使得美工、开发工程师可以各司其事，易于协作。
同时还应该内置一些安全策略，防护web应用攻击。
将分别开发维护的动态内容和静态页面模板集成起来，组合成最终显示给用户的完整页面。
页面渲染
将堕胎应用服务器组成一个集群，通过负载均衡技术将用户请求分发到不同的服务器上，以应对大量用户同时访问时产生的高并发负载压力。
负载均衡
为了实现高可用的应用服务器集群，应用服务器通常设计为无状态，不保存用户请求上下文信息，但是网站业务通常需要保持用户会话信息，需要专门的机制管理session，使得集群内甚至跨集群的应用服务器可以共享session。
session管理
对于访问量特别大而更新又不很频繁的动态页面，可以使其静态化，即生成一个静态页面，利用静态页面的优化手段加速用户访问，如反向代理、CDN、浏览器缓存等。
动态页面静态化
将复杂而又庞大的业务拆分开来，形成多个规模较小的产品，独立开发、部署、维护，除了降低系统耦合度，也便于数据库业务分库。按业务对关系数据库进行拆分，技术难度相对较小，而效果有比较好。
业务拆分
将一台武器服务器虚拟化成多台虚拟服务器，对于并发访问较低的业务，更容易用较少的资源构建高可用的应用服务器集群。
虚拟化服务器
应用层架构
提供基础服务，供应用层调用，完成网站业务。
利用消息队列机制，实现业务和业务、业务和服务之间的异步消息发送及低耦合的业务关系。
分布式消息
提供高性能、低耦合、易用性、易管理的分布式服务，在网站实现面向服务架构（SOA）
分布式服务
通过可伸缩的服务器集群提供大规模热点数据的缓存服务，是网站性能优化的重要手段。
分布式缓存
系统运行需要配置许多参数，如果这些参数需要修改，比如分布式缓存集群加入新的缓存服务器，需要修改应用程序客户端的缓存服务列表配置，并重启应用程序服务器。
分布式配置在系统运行期提供配置动态推送服务，将配置修改实时推送到应用系统，无需重启服务器。
分布式配置
服务层架构
提供数据、文件的持久化访问和管理服务
网站在线业务需要存储的文件大部分是图片、网页、视频等比较小的文件，但是这些文件的数量非常庞大，而且通常都在持续增加，需要伸缩性设计比较好的分布式文件系统。
分布式文件
大部分网站的主要业务是基于关系数据库开发的，但是关系型数据库对集群伸缩性的支持比较差。
通过在应用程序的数据访问层增加数据库访问路由功能，根据业务配置将数据库访问路由到不同的物理数据库上，可实现关系数据库的分布式访问。
目前各种NoSQL数据库层出不穷，在内存管理、数据模型、集群分布式管理等方面各有优势，不过从社区活跃性角度看，Redis、HBase无疑是目前排名靠前的。
链接
redis
HBase
NoSQL数据库
在支持全球范围内数据共享的分布式数据库技术成熟之前，拥有多个数据中心的网站必须在多个数据中心之间进行数据同步，以保证每个数据中心都拥有完整地数据。
在实践中，为了减轻数据库压力，将数据库的事务日志（或者NoSQL的写操作Log）同步到其他数据中心，根据Log进行数据重演，实现数据同步。
数据同步
关系数据库
存储层架构
网站应用中，除了处理用户的实时访问请求外，还有一些后台非实时数据分析要处理。
即使是网站内部的搜索引擎，也需要进行数据增量更新及全量更新、构建索引等，这些操作通过后台系统定时执行。
搜索引擎
根据离线数据，提供数据分析与数据挖掘服务。
数据仓库
社交网站及购物网站通过挖掘人和人之间的关系，人和商品之间的关系，发觉潜在的人际关系和购物兴趣，为用户提供个性化推荐服务。
推荐系统
后台架构
大型网站需要的服务器规模数以十万计，机房物理架构也需要关注。
对于一个拥有十万台服务器的大型网站，每台服务器耗电（包括服务器本身耗电及空调耗电）每年大约需要人民币2000元，那么网站每年机房电费就需要两亿人民币。数据中心能耗问题已经日趋严重，Google、Facebook选择数据中心地理位置的时候趋向选择散热良好，供电充裕的地方。
机房架构
包括机柜大小、网线布局、指示灯规格、不间断电源、电压规格（是48V直流电还是220V民用交流电）等一系列问题。
机柜架构
大型网站由于服务器采购规模庞大，大都采用定制服务器的方式购买服务器整机。
根据网站应用需求，定制硬盘、内存、甚至CPU，同时去除不必要的外设接口（显示器输出接口、鼠标、键盘输入接口），并使得空间结构利于散热。
服务器架构
数据中心机房架构
保护网站免遭攻击及敏感信息泄露。
以HTTP请求的方式发起的攻击，危害最大的就是XSS和SQL注入攻击。但是只要措施得当，这两种攻击都是比较容易防范的。
web攻击
敏感信息加密传输与存储，保护网站和用户资产。
数据保护
安全架构
监控网站的访问情况与系统运行情况，为网站运营决策和运维管理提供支持保障。
通过在网站也页面中嵌入JS脚本采集用户浏览器环境和操作纪律，分析用户行为。
浏览器数据采集
服务器业务数据包括两种，一种是采集在服务器端记录的用户请求操作日志
一种是采集应用程序运行期业务数据，比如待处理消息数目等
服务器业务数据采集
采集服务器性能数据，如系统负载，内存使用率、网卡流量等
服务器性能数据采集
将前述采集的数据以图表的方式展示，以便运营和运维人员监控网站运行状况，做到这一步仅仅是系统监视。
更先进的做法是根据采集的数据进行自动化运维，自动处理系统异常状况，实现自动化控制。
系统监控
如果采集来的数据超过预设的正常情况的阈值，比如系统负载过高，就通过邮件、短信、语音电话等方式发出报警信息、等待工程师干预。
系统报警
数据采集与监控
网站系统架构层次
大型网站架构技术一览
web 服务端可以根据不同用户请求产生动态页面内容。CGI处理动态请求的节本过程如图所示，web服务器将请求数据交给CGI 程序，CGI 程序进行运算处理，生成HTML输出，通过web服务器返回给浏览器。早起主要的CGI编程语言是Perl，高效便捷的开发特性使其成为当时许多网站开发的首选。但是web服务器通过启动独立进程的方式调用CGI程序，消耗许多不必要的资源。Java servlet则以线程方式在Java web容器中调用servlet，比较 CGI方式消耗资源更少。
一般来说CGI技术（广义上也包含Java servlet）被称为脚本模式，CGI程序需要解析 HTTP请求，处理业务逻辑，并在输出流中构造响应信息的HTML。这种技术的优点和缺点是同一个特性----- 可以在CGI程序中做任何事情。CGI程序在获得最大处理能力的同时，也给开发人员带来了麻烦：负责编写业务逻辑程序的程序员不擅长处理HTML，而负责页面构造的美工人员则对程序束手无策。同样维护这样的程序也是一个噩梦，业务代码和页面语法耦合在一起，让人无从下手。
PHP及其随后的ASP、JSP的出现改善了这一局面，与CGI在程序中输出HTML流正好相反，开发人员可以在HTML中嵌入程序代码。这种模式被称为服务器页面模式。直到现在，PHP仍然是许多中小型网站建站首选技术，和Apache、MySQL、Linux共同组成一个强大的web开发平台，被称作LAMP。
CGI程序调用时序模型
答案就是MVC（模型-视图-控制器）模式，
既然 CGI 程序擅长处理请求信息，而服务器页面擅长处理响应页面，那么能不能将两者结合起来呢？
CGI（Common Gateway Interface）通用网关接口
如图所示，控制器接受处理所有的HTTP请求，根据请求信息将其分发给不同的模型对象处理，再根据模型处理结果选择构造视图，得到最终响应信息。使用MVC模式可以很好的分离模型与视图，使得二者完全解耦，互相影响降到最低。
模型和视图分离为系统开发维护带来了诸多好处，为目前web开发流畅的分层架构模式奠定了基础。1、分层模式可以更进一步分离关注面和降低系统的耦合性，通过分层，隔离上层对下层的直接依赖，2、上层设计无需过多考虑下层实现；3、各层之间较少耦合，只要保持接口规范不变，各层可以随意替换和复用。
web开发中通常将服务端划分为三层：表现层 、业务逻辑层、数据源层。1、表现层完成视图展示和用户交互。2、业务逻辑层实现系统的核心逻辑。3、数据源层负责数据存储、交换和通信。这种层次划分是逻辑上的，物理部署上多个层会作为一个应用部署在一起。
web开发的技术发展历程和一些早期主要架构模式，这些模式在企业web应用开发中有许多实践。但是随着互联网应用的快速发展，徐阿偶场景和业务领域都有一些和传统企业应用不同的特点，对系统的可用性、扩展性、响应性能、伸缩性、安全性都提出了更高的要求，网站技术架构也和企业应用技术架构脱离，走上了一条更具创新性的发展之路。
MVC系统调用时序模型
MVC（模型-视图-控制器）模式
web开发技术发展历程
4、架构师
高并发、大流量
高可用
海量数据
用户分布广泛、网络情况复杂
安全环境恶劣
需求快速变更，发布频繁
渐进式发展
大型网站软件系统的特点
1.1 初始阶段的网站架构
初始阶段的网站架构
1.2 应用服务和数据服务分离
应用服务和数据服务分离
1.3 网站使用缓存
使用缓存改善网站性能
1.4 应用服务器集群部署
使用应用服务器集群改善网站的并发处理能力
图1.5 数据库读写分离
数据库读写分离
图1.6 网站使用反向代理和CDN加速访问
使用反向代理和CDN加速网站响应
图1.7 使用分布式文件和分布式数据库
使用分布式文件系统和分布式数据库系统
图1.8 使用NoSQL系统和搜索引擎
使用NoSQL和搜索引擎
图1.9 应用拆分
图1.10 分布式服务
大型网站架构演化发展历程
大型网站架构技术的核心价值不是从无到有搭建一个大型网站，而是能够伴随小型网站业务的逐步发展，慢慢的演化成一个大型网站。
大型网站架构技术的核心价值是随网站所需灵活应对
创新的业务发展模式对网站架构逐步提出更高的要求，才得以创新的网站架构得以发展成熟。
是业务成就了技术，是事业成就可人，而不是相反。所以网站架构师应该对成就自己技术成绩的网站事业心存感激，并努力提高技术回馈业务，才能在快速发展的互联网领域保持持续进步。
不过也有传统企业投身互联网，在业务问题还没有理清楚的时候就从外面挖来许多技术高手，仿照成功的互联网公司打造技术平台，这无疑是南辕北辙，缘木求鱼。而这些高手离开了他们熟悉的环境和工作模式，也是张飞拿着绣花针使不上劲。
驱动大型网站技术发展的主要力量是网站的业务发展
大型网站架构演化的价值观
一味追随大公司的解决方案
为了技术而技术
技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段区解决。
企图用技术解决所有问题
网站架构设计误区
网站的架构技术演化过程难以重现，所以网站架构师更应该对这个过程深刻了解，理解已成熟的网站架构技术方案的来龙去脉和历史渊源，在技术选型和架构决策时才能有的放矢，直击要害。
大型网站架构演化
分层
分割
分布式
集群
异步
冗余
自动化
安全
网站架构模式
架构模式在新浪微博的应用
星界
大型网站架构模式
性能
可用性
伸缩性
扩展性
安全性
大型网站核心架构要素
1、概述
响应时间
TPS
系统性能计数器
不同视角下的网站性能
性能测试指标
性能测试方法
性能测试报告
性能测试策略
网站性能测试
衡量性能的指标
浏览器缓存
页面压缩
页面合理布局
减少cookie传输
浏览器端
分发网站静态内容至离用户最近的网络服务商机房，使得用户可以通过最短路径访问网站获取数据
机房部署反向代理：1、缓存热点文件2、加快请求响应速度3、减轻应用服务器的负载压力
CDN端
web前端性能优化
本地缓存
缓存分类
缓存用法
缓存：通过内存中的热点数据处理用户请求，加快请求处理过程，减轻数据库负载压力
同步转异步：将耗时操作异步化到消息队列进行处理，当前请求直接响应给用户返回
将多台服务器组成一个集群，共同对外提供服务，提高整体服务能力，改善性能
服务集群
使用集群
使用多线程（线程池）
改善内存管理
代码层面
应用服务器端
优先使用索引
尽量利用缓存（数据一致性方案）
NoSQL
优化数据模型
优化存储结构
优化伸缩特性
SQL优化手段
数据库
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
存储性能优化
如何优化性能
高性能架构：瞬时响应：
预测网站容量
对异常指标进行报警
监控性能指标
网站可用性度量
网站可用性考核
网站可用性的度量与考核
高可用的网站架构
通过负载均衡进行无状态服务的失效转移
应用服务器集群的Session管理
高可用的应用
高可用的服务
CAP原来
数据备份
失效转移
高可用的数据
网站发布
自动化测试
预发布验证
代码控制
自动化发布
灰度发布
高可用网站的软件质量保证
监控数据采集
监控管理
网站运行监控
高可用架构: 万无一失：
不同功能进行物理分离实现伸缩
单一功能通过集群规模实现伸缩
网站架构的伸缩性设计
HTTP重定向负载均衡
DNS域名解析负载均衡
反向代理负载均衡
IP负载均衡
数据链路层负载均衡
负载均衡算法
应用服务器集群的伸缩性设计
memcached分布式缓存集群的访问模型
memcached分布式缓存集群的伸缩性挑战
分布式缓存的一致性hash算法
分布式缓存集群的伸缩性设计
关系型数据库集群的伸缩性设计
NoSQL数据库的伸缩性设计
数据存储服务器集群的伸缩性设计
伸缩性架构 ：永无止境：
构建可扩展的网站架构
事件驱动架构
分布式消息队列
利用分布式消息队列降低系统耦合性
webservice与企业级分布式服务
大型网站分布式服务的需求与特点
分布式服务框架设计
利用分布式服务打造可复用的业务平台
可扩展的数据架构
利用开放平台建设网站生态圈
可扩展架构： 随需应变：
XSS攻击
注入攻击
CSRF攻击
其他攻击与漏洞
web应用防火墙
网站安全漏洞扫描
道高一尺魔高一丈的网站应用攻击与防御
单向散列加密
对称加密
非对称加密
密钥安全管理
信息加密技术与密钥安全管理
文本匹配
分类算法
黑名单
信息过滤与反垃圾
风险
风控
电子商务风险控制
安全架构：固若金汤：
2、架构
大型网站技术架构：核心原理和案例分析（李智慧）-持续更新
收藏
0 条评论
下一页
