目录
1. 难题与方案1.1、亿级流量电商网站的商品详情页系统架构1.2、redis企业级集群架构1.3、多级缓存架构设计1.4、数据库+缓存双写一致性解决方案1.5、缓存维度化拆分解决方案1.6、缓存命中率提升解决方案1.7、缓存并发重建冲突解决方案1.8、缓存预热解决方案1.9、热点缓存自动降级方案1.10、高可用分布式系统架构设计1.11、复杂的高可用分布式系统架构设计1.12、缓存雪崩解决方案1.13、缓存穿透解决方案1.14、缓存失效解决方案 2. 具体措施2.1 页面静态化2.2 图片服务器分离2.3 数据库集群、分库分表2.4 缓存2.5 镜像2.6 负载均衡2.7 CDN加速技术2.8 降级2.9 分层2.10 限流2.11 隔离2.12 超时重试2.13 自动化2.14 冗余2.15 安全2.16 集群2.17 分布式2.18 压力测试2.19 系统优化和容灾2.20 应急预案 3. 九种技术架构3.1 分层3.2 冗余3.3 分隔3.4 异步3.5 分布式3.6 安全3.7自动化3.8集群3.9 缓存1. 难题与方案
1.1、亿级流量电商网站的商品详情页系统架构
面临难题：对于每天上亿流量，拥有上亿页面的大型电商网站来说，能够支撑高并发访问，同时能够秒级让最新模板生效的商品详情页系统的架构是如何设计的?
解决方案：异步多级缓存架构+nginx本地化缓存+动态模板渲染的架构
1.2、redis企业级集群架构
面临难题：如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据+企业级数据备份与恢复?
解决方案：redis的企业级备份恢复方案+复制架构+读写分离+哨兵架构+redis cluster集群部署
1.3、多级缓存架构设计
面临难题：如何将缓存架构设计的能够支撑高性能以及高并发到极致?同时还要给缓存架构最后的一个安全保护层?
解决方案：nginx抗热点数据+redis抗大规模离线请求+ehcache抗redis崩溃的三级缓存架构
1.4、数据库+缓存双写一致性解决方案
面临难题：高并发场景下，如何解决数据库与缓存双写的时候数据不一致的情况?
解决方案：异步队列串行化的数据库+缓存双写一致性解决方案
1.5、缓存维度化拆分解决方案
面临难题：如何解决大value缓存的全量更新效率低下问题?
解决方案：商品缓存数据的维度化拆分解决方案
1.6、缓存命中率提升解决方案
面临难题：如何将缓存命中率提升到极致?
解决方案：双层nginx部署架构+lua脚本实现一致性hash流量分发策略
1.7、缓存并发重建冲突解决方案
面临难题：如何解决高并发场景下，缓存重建时的分布式并发重建的冲突问题?
解决方案：基于zookeeper分布式锁的缓存并发重建冲突解决方案
1.8、缓存预热解决方案
面临难题：如何解决高并发场景下，缓存冷启动导致MySQL负载过高，甚至瞬间被打死的问题?
解决方案：基于flink实时统计热数据的分布式快速缓存预热解决方案
1.9、热点缓存自动降级方案
面临难题：如何解决热点缓存导致单机器负载瞬间超高?
解决方案：基于flink的实时热点发现+毫秒级的实时热点缓存负载均衡降级
1.10、高可用分布式系统架构设计
面临难题：如何解决分布式系统中的服务高可用问题?避免多层服务依赖因为少量故障导致系统崩溃?
解决方案：基于hystrix的高可用缓存服务，资源隔离+限流+降级+熔断+超时控制
1.11、复杂的高可用分布式系统架构设计
面临难题：如何针对复杂的分布式系统将其中的服务设计为高可用架构?
解决方案：基于hystrix的容错+多级降级+手动降级+生产环境参数优化经验+可视化运维与监控
1.12、缓存雪崩解决方案
面临难题：如何解决恐怖的缓存雪崩问题?避免给公司带来巨大的经济损失?
解决方案：全网独家的事前+事中+事后三层次完美缓存雪崩解决方案
1.13、缓存穿透解决方案
面临难题：如何解决高并发场景下的缓存穿透问题?避免给MySQL带来过大的压力?
解决方案：缓存穿透解决方案
1.14、缓存失效解决方案
面临难题：如何解决高并发场景下的缓存失效问题?避免给redis集群带来过大的压力?
解决方案：基于随机过期时间的缓存失效解决方案
2. 具体措施
2.1 页面静态化
活动页面是用户流量的第一入口，所以是并发量最大的地方。
如果这些流量都能直接访问服务端，恐怕服务端会因为承受不住这么大的压力，而直接挂掉。
活动页面绝大多数内容是固定的，比如：商品名称、商品描述、图片等。为了减少不必要的服务端请求，通常情况下，会对活动页面做静态化处理。用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。
这样能过滤大部分无效请求。
但只做页面静态化还不够，因为用户分布在全国各地，有些人在北京，有些人在成都，有些人在深圳，地域相差很远，网速各不相同。
如何才能让用户最快访问到活动页面呢？
这就需要使用CDN，它的全称是Content Delivery Network，即内容分发网络。
使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
2.2 图片服务器分离
图片服务器可以在fastdfs上, 也可以是oss上
对于图片来说是消耗资源的。于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。
2.3 数据库集群、分库分表
分库分表:细分为水平与垂直分库分表。
IO 瓶颈：
第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。
第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。
CPU 瓶颈:
第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。
第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。
2.4 缓存
站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了
2.5 镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
2.6 负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。
第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5
软件四层交换
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。
2.7 CDN加速技术
CDN的实现分为三类：镜像、高速缓存、专线。
镜像站点（Mirror Site），是最常见的，它让内容直接发布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，还必须在各个地区设置镜像服务器，配备专业技术人员进行管理与维护。对于大型网站来说，更新所用的带宽成本也大大提高了。
高速缓存，成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户请求的响应时间，并降低了原始服务器的负载。
CDN服务一般会在全国范围内的关键节点上放置缓存服务器。
专线，让用户直接访问数据源，可以实现数据的动态同步。
CDN的实例
举个例子来说，当某用户访问网站时，网站会利用全球负载均衡技术，将用户的访问指向到距离用户最近的正常工作的缓存服务器上，直接响应用户的请求。
当用户访问已经使用了CDN服务的网站时，其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地DNS的解析请求，而是充分考虑用户发起请求的地点和当时网络的情况，来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。
通过用户定位算法和服务器健康检测算法综合后的数据，可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上，保证用户的访问能得到更及时可靠的响应。
由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了，这就不仅提高了用户的访问质量，同时有效地降低了源服务器的负载压力。
附：某CDN服务商的服务说明
采用GCDN加速方式
采用了GCDN加速方式以后，系统会在浏览用户和您的服务器之间增加一台GCDN服务器。浏览用户访问您的服务器时，一般静态数据，如图片、多媒体资料等数据将直接从GCDN服务器读取，使得从主服务器上读取静态数据的交换量大大减少。
为VIP型虚拟主机而特加的VPN高速压缩通道，使用高速压缩的电信<>网通、电信<>国际（HK）、网通<==>国际（HK）等跨网专线通道，智能多线，自动获取最快路径，极速的动态实时并发响应速度，实现了网站的动态脚本实时同步，对动态网站有一个更加明显的加速效果。
每个网络运营商（电信、网通、铁通、教育网）均有您服务器的GCDN服务器，无论浏览用户是来自何处，GCDN都能让您的服务器展现最快的速度！另外，我们将对您的数据进行实时备份，让您的数据更安全！
2.8 降级
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
降级预案
在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：
一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
错误：比如可用率低于90%,或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。
降级按照是否自动化可分为：自动开关降级和人工开关降级。
降级按照功能可分为：读服务降级、写服务降级。
降级按照处于的系统层次可分为：多级降级。
降级的功能点主要从服务端链路考虑，即根据用户访问的服务调用链路来梳理哪里需要降级：
页面降级、页面片段降级、页面异步请求降级、服务功能降级、读降级、写降级
自动开关降级：超时降级、统计失败次数降级、故障降级、限流降级
人工开关降级：读服务降级、写服务降级
2.9 分层
分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。
在网站的分层架构中，常见的为3层，即应用层、服务层、数据层。应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。
分层架构是逻辑上的，在物理部署上，三层架构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，是网站拥有更多的计算资源以应对越来越多的用户访问。
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。
2.10 限流
在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。
限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。
2.11 隔离
线程隔离：
线程隔离主要是指线程池隔离，在实际使用时，我们会把请求分类，然后交给不同的线程池处理。当一种业务的请求处理发生问题时，不会将故障扩散到其他线程池，从而保证其他服务可用。
进程隔离
由于传统的系统所有功能都集中在一个系统中，为了避免系统其中一个模块功能出现问题导致整个系统无法使用的情况发生，将其该系统拆分成多子系统实现物理隔离，故通过进程隔离使得某一个子系统出现问题时不影响到其他子系统。
集群隔离
随着调用方的增多，当秒杀（并发量特别大功能）类似的服务被刷新会影响到其他服务的稳定性时，应该考虑为秒杀（并发量特别大功能）类似的服务提供单独的服务集群，即分服务分组，这样当某一个分组出现问题时，不会影响到其他分组，从而实现了故障隔离愿景。
机房隔离
随着对系统可用性的要求，会进行多机房部署，每一个机房的服务都有自己的服务分组，本机房的服务应该只调用本机房的服务，不进行跨机房调用。其中，一个机房服务发生问题时，可以通过DNS/负载均衡将请求全部切到另一个机房，或者考虑服务能自动重试其他机房的服务，从而提升系统可用性。
读写隔离
为了提高数据访问，一般采用redis主从模式将读和写进群分离，在正常情况下，当主redis集群出现问题时，从redis集群还是可以用的，从而不影响用户的访问。
动静隔离
例如当用户访问如结算页时，如果JS/CSS等静态资源也在结算页系统中时，很可能因为访问量太大导致带宽被打满导致出现不可用。
为了不影响结算等用户操作的功能，将其JS/CSS等静态资源静态化与用户操作功能分开部署。
资源隔离
最常见的资源如磁盘、CPU、网络；对于宝贵的资源都会存在竞争问题。
我们可以使用JIMDB数据同步时要dump数据，SSD盘容量用了50%以上，dump到同一块磁盘时遇到了容量不足的问题，我们通过单独挂一块SAS盘来专门同步数据。还有如使用Docker容器时，有的容器写磁盘非常频繁，因此要考虑为不同的容器挂载不同的磁盘。
2.12 超时重试
在实际开发过程中，我们见过太多故障时因为没有设置超时或者设置得不对而造成的，而这些故障都是因为没有意识到超时设置的重要性而造成的。如果应用不设置超时，则可能会导致请求响应慢，慢请求积累导致连锁反应，甚至造成应用雪塌。而有些中间件或者框架在超时后进行重试（例如dubbo默认重试两次），读服务天然适合重试，但写服务大多不能重试（如写订单、支付等），重试次数太多会导致多倍请求流量。
例如模拟了Ddos攻击（分布式拒绝服务（DDoS:Distributed Denial of Service）攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS,通常，攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。），后果可能是灾难，因此，务必设置合理的重试机制，并且应该和熔断、快速失败机制配合。所以在进行代码Review时，一定记得Review超时与重试机制。
2.13 自动化
具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。
2.14 冗余
网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。
2.15 安全
网站在安全架构方面有许多模式：通过密码和手机校验码进行身份认证;登录、交易需要对网络通信进行加密;为了防止机器人程序滥用资源，需要使用验证码进行识别;对常见的XSS攻击、SQL注入需要编码转换;垃圾信息需要过滤等。
2.16 集群
对于用户访问集中的模块需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。
服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可;另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。
2.17 分布式
对于大型网站，分层和分隔的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的工作，计算机越多，CPU、内存、存储资源就越多，能过处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
在网站应用中，常用的分布式方案有一下几种.
分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。
分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力;通过使用独立域名加快浏览器并发加载的速度。
分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。
分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。
2.18 压力测试
线下压力测试
通过如Jmeter,Apac,he ab 压力测试系统的某一个接口等（如登录、查询订单）或者某一个组件（例如数据库连接池），然后进行调优（如调优JVM参数，优化代码等），实现单个接口或者组件的性能最优。
线上压力测试
线上压力测试份方式非常多，按读分为读压、写压测和混合压测，按照数据仿真度分为仿真压力测试和引流压力测试，按照给用户提供服务分为隔离集群压力测试和线上集群压力测试。
议，转载请附上原文出处链接及本声明。
2.19 系统优化和容灾
拿到全面的压力测试报告后，接下来就是分析报告，然后进行一些有针对性的优化，如硬件升级、系统扩容、参数调优、代码优化（代码同步改异步）、架构优化（如加缓存、读写分离、历史数据归档）等。在扩容时也需要考虑容灾，比如分组部署、跨机房部署。容灾是通过部署多组（单机房或多机房）相同系统，当其中一组出现问题时，可以切换到另一个分组，保证系统可用
2.20 应急预案
在系统压力测试之后发现一些系统瓶颈，在系统优化之后会提升系统吞吐量并降低响应时间，容灾之后的系统可用性得以保障，但还是会存在一些风险，如网络抖动、某台机器负载过高、某个服务变慢、数据库Load值过高，为了防止因为这些问题而出现系统雪崩，需要针对这些情况制定应急预案，从而在出现突发情况时，有响应的措施来解决掉这些问题。
应急预案可按照如下几步进行：首先进行系统分级，然后进行全链路分析、配置监控，最后制定应急预案。
3. 九种技术架构
3.1 分层
分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。
在网站的分层架构中，常见的为3层，即应用层、服务层、数据层。
应用层，具体负责业务和视图的展示；
服务层，为应用层提供服务支持；
数据层，提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。
分层架构是逻辑上的，在物理部署上，三层架构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，使网站拥有更多的计算资源，以应对越来越多的用户访问。
所以，虽然分层架构模式最初的目的，是规划软件清晰的逻辑结构，以便于开发维护。但在网站的发展过程中，分层结构对网站支持高并发，向分布式方向的发展至关重要。
3.2 冗余
网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。
3.3 分隔
如果说分层是将软件在横向方面进行切分，那么分隔就是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分隔开来，包装成高内聚低耦合的模块单元，不仅有助于软件的开发维护也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
大型网站分隔的粒度可能会很小。比如在应用层，将不同业务进行分隔，例如将购物、论坛、搜索、广告分隔成不同的应用，有对立的团队负责，部署在不同的服务器上。
议，转载请附上原文出处链接及本声明。
3.4 异步
使用异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步执行进行协作。
具体实现则在单一服务器内部可用通过多线程共享内存的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。
异步架构的典型就是生产者消费者方式，两者不存在直接调用。
3.5 分布式
对于大型网站，分层和分隔的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完同样的工作，计算机越多，CPU、内存、存储资源就越多，能过处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
在网站应用中，常用的分布式方案有一下几种.
分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。
分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度。
分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。
分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。
3.6 安全
网站在安全架构方面有许多模式：通过密码和手机校验码进行身份认证；登录、交易需要对网络通信进行加密；为了防止机器人程序滥用资源，需要使用验证码进行识别；对常见的XSS攻击、SQL注入需要编码转换；垃圾信息需要过滤等。
3.7自动化
具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。
3.8集群
对于用户访问集中的模块需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。
服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可；另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。
3.9 缓存
缓存目的就是减轻服务器的计算，使数据直接返回给用户。在现在的软件设计中，缓存已经无处不在。具体实现有CDN、反向代理、本地缓存、分布式缓存等。
使用缓存有两个条件：访问数据热点不均衡，即某些频繁访问的数据需要放在缓存中；数据在某个时间段内有效，不过很快过期，否在会因为数据过期而脏读，影响数据的正确性。
