一、使用缓存减轻数据库的压力，提升网站性能。二八定律，80%的业务访问集中在20%的数据上。
1.缓存在应用服务器上的本地缓存。（Session）
2.缓存在专门的分布式缓存服务器上的远程缓存。可以采用集群的方式，理论上可以做到无限扩充。（Redis、memcached等）
二、使用服务器集群改善网站的并发处理能力。
1.单一服务器无法满足需求时，不要企图更换更大的服务器。更恰当的做法是增加服务器来分担原有服务器的压力。
2.通过负载均衡调度服务器。
3.数据库读写分离。通过主从配置可以将一台数据库服务器的数据同步到另一台服务器，网站利用数据库的这一功能，实现数据库的读写分离，从而改善数据的负载压力。（MySql数据主从配置，读写分离）
4.使用反向代理和CDN加速网站响应，其基本原理都是缓存，区别在于CDN部署在网络提供商的机房，用户可以从距离自己最近的网络提供商机房获取数据；而反向代理部署在网站的中心机房，用户请求到达后首先访问的是反向代理服务器，如果反向代理服务器缓存有用户请求的资源，则将其直接返回给用户。（Nginx等）
三、使用分布式文件系统和分布式数据库系统。
1.分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才去使用。不到不得已时，网站常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。
2.使用NoSql和搜索引擎。（常用的NoSql有mongodb等，常用的搜索引擎有：elasticsearch、solr等）
四、业务拆分
1.为了应对日益复杂的业务场景，通过分而治之的手段将整个网站拆分成不用的产品线，分归不同的业务团队负责。每个应用独立部署，应用之间可以通过超链接建立关系（在首页的导航链接每个都指向不同的应用地址），也可以通过消息队列进行数据分发，实际最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
五、分布式服务
1.随着业务拆分越来越细，系统部署越来越多，网站维护会越来越困难，在数万台服务器规模的网站中，连接数据太多，会导致数据库连接资源不足，拒绝服务。考虑都很多业务都会执行许多相同的操作，我们可以把这些可复用的业务独立出来，单独部署，通过分布式服务调用共同业务完成具体业务操作。
2.随着云计算技术的日趋成熟，我们可以考虑租用云计算平台，按需付费，弹性扩充。
六、网站架构模式
1.分层（横向切分）。三层分别部署在不同的服务器上，这样可以使网站拥有更多的计算资源应对越来越多的用户访问。分层结构对网站支持高并发向分布式方向发展至关重要。
2.分割（纵向切分）。同一业务内部，如果规模过于庞大，可以考虑继续分割。比如购物业务可以进一步分割成机票酒店业务、3C业务、小商品业务等更细的粒度。
3.分布式
分布式优点：可以解决网站高并发的问题。
分布式缺点：a.分布式意味着服务调用必须通过网络，可能对性能造成比较严重的影响。
b.服务器越多，宕机的概率越高，一台服务器宕机可能导致很多应用不可访问，使网站可用性降低。
c.数据在分布式的环境中保持数据一致性也很困难，分布式事物也难以保证。
d.分布式导致网站依赖错综复杂，开发管理维护困难。
综上所述，分布式设计要视具体情况，切莫为了分布式而分布式。
常用的分布式有以下几种：
a.分布式应用和服务：将分层和分割后的应用和服务模块分布式部署
b.分布式静态资源：网站的静态资源如js、css、logo图片等资源独立分布式部署，并采用独立域名，即江湖中传说的动静分离。
c.分布式数据和存储：关系型数据库分布式、nosql数据库分布式。
d.分布式计算：Hadoop、MapReduce、Spark。
此外还有分布式配置、分布式锁、分布式文件系统等。
4.集群
说白了就是春运买火车票的时候额外增加一些售票窗口。
如何实现多台服务器网站的同步更新？
5.缓存
常用的缓存有以下几种：
a.CDN
b.反向代理
c.本地缓存
d.分布式缓存
6.异步
在单一服务器内部可通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。
异步架构是典型的生产者消费者模式，两者不存在直接调用。
优点：a.提高系统可用性。
b.加快网站响应速度。
c.消除并发访问高峰。
7.冗余
a.至少两台服务器部署网站，防止突然的宕机。
b.数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。
c.为了抵御地震、海啸等不可抗拒的突发自然灾难导致的网站完全瘫痪，可以进行全球范围内部署灾备数据中心。（当然是牛逼吊炸天的公司喽）
8.自动化
自动化失效转移，将失效的服务器从集群中隔离出去，不再处理系统中的应用请求。
9.安全
a.通过密码和手机验证码进行身份认证。
b.登录、交易等操作需要对网络通信进行加密,服务器端存储的敏感数据也要进行加密处理。
c.使用验证码防止机器人程序滥用网络资源攻击网站。
d.对于常见的用于攻击网站的XSS攻击、SQL注入进行编码转换等相应处理。
e.对于垃圾信息、敏感信息进行过滤。
f.对于交易转账等重要操作根据交易模式和交易信息进行风险控制。
七、大型网站核心架构要素
1.性能
a.在浏览器端，可以通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等手段改善。
b.使用CDN缓存热点数据。
c.在服务端，可以使用本地缓存和分布式缓存加快请求处理过程，减轻数据库负载压力。
d.通过异步操作将用户请求发至消息队列等待后续任务处理，而当前请求直接返回响应给用户。
e.可以将多台应用程序服务器组成一个集群共同对外服务，应对多用户高并发，提升整体 处理能力。
f.代码层面，可以使用多线程、改善内存管理等手段优化性能。
g.在数据库服务器端，索引、缓存、SQL优化等系能优化手段都已经比较成熟。还可以考虑使用NoSQL数据库。
2.可用性
a.网站高可用的主要手段是冗余，应用程序部署在多台服务器上同时提供访问，数据存储在多台服务器上互相备份。
应用服务器上不能保存请求的会话信息，否则服务器宕机，会话丢失，即使用户请求转发到其他服务器上也无法完成业务处理。
3.伸缩性
衡量架构的伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器的数量是否有限制。
4.扩展性
网站的可伸缩架构的主要手段是事件驱动架构和分布式服务。
事件驱动架构通常是利用消息队列实现；分布式服务则是将业务和可复用服务分离开来。
5.安全性
衡量网站是否安全的标准是针对现存的和潜在的各种攻击与窃密手段，是否有可靠的应对策略。
八、架构
1.浏览器访问优化
减少http请求。主要手段：合并CSS、合并javascript、合并图片（通过CSS偏移控制）。
2.使用浏览器缓存
a.通过设置http头中的Cache-Control和Expires的属性。
b.在某些时候，静态资源文件的变化需要及时应用到客户端浏览器，这种情概，可以通过改变文件名实现，及更新整个js文件并不是只是更新js文件中的内容，而是生成一个新的js文件并更新html文件中的引用。
c.使用浏览器缓存策略的网站在更新静态资源时，应采用一个文件一个文件逐步更新，并有一定的时间间隔，以免用户浏览器突然大量缓存失效，集中更新缓存，造成服务器负载骤增、网络堵塞的情况。
3.启用压缩
html、css、javascript文件启用GZip压缩。压缩会对服务器和浏览器产生一定的压力，所以要权衡考虑。
4.css放在页面最上面、JavaScript放在页面最下面
如果页面解析时就需要用到JavaScript，这时放到底部就不合适了。
5.减少cookie传输
太大的cookie会严重影响数据传输，因此慎重考虑哪些数据要写入cookie。
6.CDN加速
CDN能够缓存的一般是静态资源，如图片、文件、css、script脚本、静态网页等。
7.反向代理
安全功能、缓存功能、负载均衡提升网站并发能力。
九、应用服务器性能优化
1.分布式缓存
a.网站性能优化第一定律：优先考虑使用缓存优化性能。缓存的本质是一个内存的Hsah表。
2.合理使用缓存
a.缓存预热
缓存系统启动时就把热点数据加载好。
b.缓存穿透
如果因为不恰当的业务或者恶意攻击持续高并发地请求某个不存在的数据，由于缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大压力，甚至崩溃。一个简单的对策就是将不存在的数据也缓存起来（其value值为null）。
3.分布式缓存架构
a.两种架构：一种是以JBossCache为代表的需要更新同步的分布式缓存；一种是以Memcached为代表的不互相通信的分布式缓存。
b.异步操作
十、万无一失：网站的高可用架构
1.Session服务器
2.网站发布
3.自动化测试
目前比较流行的web自动化测试工具是Selenium。
十一、网站的伸缩性架构
1.不同功能进行物理分离实现伸缩。
具体可以分为以下两种：
a.纵向分离：将业务处理流程上的不同部分分离部署。
b.横向分离：将不同的业务模块分离部署。
2.负载均衡
a.HTTP重定向负载均衡（缺点是浏览器需要两次请求服务器才能完成一次访问，性能差，所以此种方案不推荐使用）
b.DNS域名解析负载均衡
大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供web服务器的物理服务器，而是同样提供负载均衡服务的内部服务器，这组内部负载均衡服务器进行负载均衡，将请求分发到真实的web服务器上。
c.反向代理负载均衡（反向代理服务器转发请求在HTTP协议层面。优点是和反向代理服务器功能集成在一起，部署简单。缺点是反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈）
d.IP负载均衡（在网络层通过修改请求地址进行负载均衡）
e.数据链路层负载均衡（使用三角传输模式的链路层负载均衡是目前大型网站广泛使用的手段，Linux平台上最好的链路层负载均衡开源产品是LVS（Linux Virtual Server））
3.负载均衡算法
a.轮询
b.加权轮询
c.随机
d.最少连接：记录每个应用服务器正在处理的连接数，将新到的请求分发到最少连接的服务器。
e.源地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自一个IP地址的请求总在同一个服务器上处理。
4.分布式缓存集群
a.Memcached分布式缓存
5.分布式缓存的一致性Hash算法
6.关系数据库集群
a.MySQL集群伸缩性方案:数据写操作都在主服务器上，有主服务器将数据同步到其他的从服务器，数据库读操作都在从服务器上进行。
b.除了数据库主从读写分离，也可以将不同业务数据表部署在不同的数据库集群上，即俗称的数据分库。这种方式的制约条件是垮裤表不能进行Join操作。
c.单表数据过大的时候，还需要进行分片，将一张表拆开分别存储在多个数据库中。目前比较成熟的支持数据分片的分布式关系数据库产品主要有开源的Amoeba和Cobar。
7.NoSQL
目前使用最广泛的是Apache HBase。
十二、网站的可扩展架构
1.分布式消息队列
十三、网站的安全架构
1.XSS攻击
XSS攻击即跨站脚本攻击。分为另种：一种是反射型XSS攻击；一种是持久型XSS攻击。
主要有两种防攻击手段：
a.消毒--即对某些html危险字符转义。
b.HttpOnly--即浏览器禁止页面JavaScript访问带有HttpOnly属性的Cookie，对存放敏感信息的cookie，可通过对该cookie添加HttpOnly属性，避免被攻击脚本窃取。
2.注入攻击
注入攻击主要有两种形式：SQL注入攻击和OS注入攻击。
a.SQL注入攻击--攻击者需要对数据库结构有所了解才能进行，攻击者获取数据库表结构信息的手段有如下几种：开源（Discuz搭建的论坛，数据结构是公开的）、错误回显（内部错误500错误会显示到浏览器）、盲注（根据页面变化情况判断sql语句的执行情况，据此猜测数据库结构）。
防御手段：
a.首先要避免攻击者猜测到表名等数据库表结构信息。
b.消毒--通过正则匹配，过滤掉请求数据中可能注入的sql，如“drop table等”。
c.参数绑定--强力推荐使用参数化，此方法是最好的防sql注入的方法。
3.CSRF攻击
CSRF（Cross Site Request Forgery，跨站点请求伪造），其核心是利用了浏览器Cookie或服务器Session策略，盗取用户身份。
防御手段主要是识别请求者身份。主要有一下几种方法：
a.表单Token--在页面表单中增加一个随机数作为Token，每次响应页面的Token都不相同，正常页面提交的请求会包含该Token值，而伪造的请求无法获得该值，服务器检查请求参数中Token的值是否存在并且正确以确定请求提交者是否合法。
b.验证码--体验不好，所以在必要时使用，如支付交易等关键页面。
c.Referer check--http请求头的Referer域中记录着请求来源，可通过检查请求来源，验证其是否合法（使用此功能实现图片防盗链）。
4.其他攻击和漏洞
a.Error Code--也称作错误回显。防御手段很简单：通过配置web服务器参数，跳转500页面到专门的错误页面即可。
b.Html注释--删除注释然后再上线。
c.文件上传--用户可能会上传可执行的程序，最有效的防御手段：通过文件过滤，只允许上传可靠的文件类型。
d.路径遍历--攻击者在请求的URL中使用相对路径，遍历系统未开放的目录和文件。防御方法：将js、css订资源文件部署在独立的服务器，使用独立域名，其他文件不使用静态的URl访问，动态参数不包含文件路径信息。
5.web应用防火墙
ModSecurity是一个开源的web应用防火墙。
除了开源的ModeSecurity，还有一些商业产品的web应用防火墙，如NEC的SiteShell。
6.网站安全漏洞扫描
不定期对网站的服务器进行扫描，查漏补缺。
7.信息加密技术及密钥安全管理
a.信息加密技术可分为三类：
单项散列加密--MD5、SHA
对称加密--DES算法、RC算法等
和非对称加密--RSA算法
8.分类算法
a.贝叶斯分类算法(会存在误判)。
b.TAN算法。
c.ARCS算法。
十四、淘宝架构演变
1.2003年LAMP架构
.
2.2004年java+Oracle+MVC框架(自己开发的Webx)+ORM框架（IBatis）
3.2006年
4.现在回归到开源的MySQL及NoSQL系统。有些路，走过后，再回头，不过是一览众山小。
5.秒杀系统的应对策略
a.秒杀系统应独立部署--防止拖垮主网站。
b.秒杀商品页面静态化--将商品描述、商品参数、成交记录和用户评价全部写入一个静态页面，用户请求不需要经过应用服务器的业务逻辑处理，也无需访问数据库。
c.租借秒杀活动网络宽带
d.动态生成随机下单页面URL--避免用户直接访问下单URL。
十五、大型网站典型故障
1.写日志引发的故障
故障原因：大量日志占满磁盘空间
解决办法：关闭不必要的日志
2.高并发访问数据库引发的故障
故障原因：首页频繁访问数据库
解决办法：首页访问频繁，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。首页最好是静态的。
3.高并发情况下锁引发的故障。
故障原因：单例对象多处使用了独一的this。
经验教训：使用锁操作要谨慎。
十六、架构师
没有懒惰的员工，只有没被激发出来的热情。
互联网正在并将继续改变这个世界，一切才刚刚开始，你我正生逢其时！
.................................................................................................................................................................................................................................................................................
以上内容出自李智慧的《大型网站架构》一书，这些只是本人的读书笔记，很多地方记录的不够详尽，哪位大虾如有兴趣，可自行下载原书阅读。