大型网站技术架构核心原理与案例分析(读书笔记)

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

1.概述

网站衡量的标准：高可用，高性能，易扩展，可伸缩，安全

1.1 大型网站特点

1. 高并发
2. 高可用
3. 海量数据
4. 用户分布广泛，网络情况复杂
5. 安全环境恶劣
6. 需求快速变更，发布频繁
7. 渐进式发展

1.2 大型网站演化发展历程

1. 一台服务器（应用程序+数据库+文件）
2. 应用服务和数据服务分离
3. 使用缓存改善网站性能（应用服务器缓存+分布式缓存服务器）
4. 使用应用服务器集群改善网站的并发能力
5. 数据库读写分离
6. 使用反向代理和CDN加速网站响应
7. 使用分布式文件系统和分布式数据库系统（先可以考虑分库分表）
8. 使用NoSQL和搜索引擎
9. 业务拆分 --- 每个业务独立部署 ---- 通过消息队列进行数据分发
10. 分布式服务

1.3 大型网站演化发展价值观

1. 随着业务发展，灵活应对
2. 网站业务驱动

1.4 网站架构误区

1. 一味追随大公司的解决方案
2. 为了技术而不是业务
3. 企图用技术解决所有问题（12306采用分时分段售票，引入排队机制）

2.大型网站架构模式

模式：对于问题和场景的解决方案可重复使用。

2.1 网站架构模式

1. 分层（网络通信协议--每一层关注自己的业务） 禁止跨层调用，以及逆向调用
2. 分割：纵向切分，不同的功能和服务分开包装成高内聚和低耦合的模块单元。
3. 分布式：分布式网络通信，分布式事物
   分布式应用和服务，分布式静态资源，分布式数据和存储，分布式计算（搜索引擎的索引构建，数据仓库的数据分析和统计，定时任务）
4. 集群：多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
5. 缓存：CDN（内容分发网络），部署在距离用户终端最近的网络服务商；反向代理：缓存网站的静态资源；本地缓存，分布式缓存。
6. 异步：业务之间的消息传递不是同步调用，而是将一个操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行协作，典型的生产者，消费者模式。

提高系统可用性，加快网站响应速度，消除并发访问高峰，

7. 冗余：数据库除了定期备份，存档保存，冷备份，主从分离，设置数据中心
8. 自动化：发布，测试，监控报警，自动降级，自动分配资源
9. 安全：身份认证，登录、交易网络通信进行加密，敏感数据加密，XSS，SQL注入进行编码转换等，对于垃圾信息，敏感信息进行过滤，重要操作进行风险控制。

2.2 架构模式在新浪微博的应用

3.大型网站核心架构要素

应用服务器不能保存数据

1. 性能 缓存 异步
2. 高可用 冗余
3. 伸缩性 集群中动态新增机器，新的机器提供无差别的服务
4. 扩展性 不同产品之间是否很少耦合
5. 安全性

2 架构

4.网站的高性能架构（瞬时响应）

4.1 网站性能测试

4.1.1 不同视角下的网站性能

性能测试时性能优化的前提和基础，也是性能优化结果的检查和度量标准。

1. 用户视角的网站性能。

调整浏览器缓存策略，使用CDN服务，反向代理

2. 开发视角的网站性能。

关注响应延迟，系统吞吐量，并发处理能力，系统稳定性

缓存加速获取数据，集群提高吞吐能力，异步消息加快请求响应以及实现削峰，代码优化提高程序性能。

3. 运维视角的网站性能。

基础设施性能和资源利用率，网络运营商的带宽能力，服务器硬件配置，数据中心网络架构，服务器和网络带宽达资源利用率。

使用高性价比的定制服务器，利用虚拟化优化资源，优化骨干网络

4.1.2 性能测试指标

1. 响应时间

发出请求到接受到数据响应的时间。

2. 并发数

系统同时处理请求的数目（同时提交请求的用户数量）。也反映了系统的负载特性。

测试程序通过多线程模拟并发用户的办法测试系统的并发能力，在请求之间加入一个随机等待时间。

3. 吞吐量

单位时间内系统处理的请求数量，体现系统的整体能力。
请求数/s 页面数/s 访问人数/天 处理业务数/小时

TPS-每秒事物数。
HPS-HTTP请求数。

吞吐量：每天通过收费站的数量。
并发数：高速公路正在行驶的车辆。
响应时间：车速。

4. 性能计算器

System Load(系统负载),对象与线程数，内存使用，CPU使用，磁盘，网络I/O

top
top - 10:42:16 up 7 days, 15:55,  2 users,  load average: 0.03, 0.05, 0.05
Tasks: 146 total,   1 running, 145 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.5 us,  0.7 sy,  0.0 ni, 98.7 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 st

4.1.3 性能测试方法

1. 性能测试

对系统不断施加压力，验证系统在资源可接受访问内是否能达到性能预期。

2. 负载测试

对系统不断的增加并发请求以增加系统压力，知道系统的某项或多项性能到达指标的安全临界值。

3. 压力测试

超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能在处理任何请求，以此获得系统最大压力承受能力。

4. 稳定性测试

被系统在特定硬件，软件，网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检查系统是否稳定。

4.1.4 性能测试报告

4.1.5 性能优化策略

1. 性能分析

2. 性能优化

4.2 Web前端性能优化

4.2.1 浏览器访问优化

1. 减少HTTP请求

合并CSS，合并JavaScript，合并图片

2. 使用浏览器缓存

3. 启用页面压缩

4. CSS放在页面最上面， JavaScript放在页面最下面。

5. 减少Cookie传输

4.2.2 CDN加速

CDN(Content Distribute Network内容分发网络)本质是一个缓存。
而且将数据缓存在离用户最近的地方。

CDN能够缓存的一般是静态资源，图片，文件，CSS，Script脚本，静态网页等。

4.2.3 反向代理

缓存静态资源，负载均衡

4.3 应用服务器性能优化

4.3.1 分布式缓存

1. 缓存的基本原理

缓存提高访问速度，提高数据访问的时间。缓存的数据是通过计算得到的，那么减少计算量。

缓存主要用来存放那些读写比很高，很少变化的数据，

2. 合理的使用缓存。

频繁修改的数据。

没用热点的访问。

数据不一致与脏读。

缓存可用性。

通过分布式缓存服务器集群，将缓存数据分布到集群多台服务器上。

缓存预热。

在缓存启动的时候加载热点数据。

缓存穿透。

3. 分布式缓存架构

Memcached

4. Memcached

简单的通讯协议，TCP,序列化（自定义）。

丰富的客户端程序。

高性能的网络通讯。

高效的内存管理。

互不通讯的服务集群架构。

4.3.2 异步操作

使用消息队列将调用异步化。

4.3.3 使用集群

4.3.4 代码优化

1. 多线程

将对象设计为无状态对象（对象本身不存储状态信息）。

使用局部对象：在方法内部创建对象。

并发访问资源是使用锁：通过锁的方式使多线程并发操作变成顺序操作。

2. 资源复用

尽量介绍开销很大的系统资源的创建和销毁，比如数据库连接，网络通讯连接，线程，复杂对象等

采用单例，和对象池。

单例：Web开发中使用贫血模式，丛Service到Dao都是无状态对象，无需要重复创建。

3. 数据结构

   程序 = 数据结构 + 算法

4. 垃圾回收

   JVM stack + heap

   stack : 存储线程上下文信息，方法参数，局部变量

   heap : 存储对象的内存空间，对象的创建和释放，垃圾回收。

   设置Young Generation 和 Old Generation大小尽量减少Full GC.

4.4 存储性能优化

4.4.1 机械硬盘 VS 固态硬盘

4.4.2 B+树 VS LSM树

4.4.3 RAID VS HDFS

1. RAID0

不做数据备份，N块磁盘中只要有一块损坏，数据完整性就被破坏。

2. RAID1

将一份数据同时写入两块磁盘

3. RAID10

结合RAID0和RAID1 将所有磁盘平均分成两份，数据同时在两份磁盘写入RAID1，但是在每一份磁盘里面的N/2块磁盘上利用RAID0技术并发读写。

4. RAID3

数据写入磁盘的时候，将数据分成N-1份，并发写入N-1块磁盘，并在第N块磁盘记录校验数据。

需要频繁跟换数据，每次写入数据都会导致第N块磁盘重写校验数据。

5. RAID5

数据校验不是写入第N块磁盘，而是螺旋式的写入所有磁盘中。

6. RAID6

数据只写入N-2块磁盘，并螺旋式的在两块磁盘中写入校验信息。

7. HDFS

系统在整个存储机器的多台服务器上进行数据并发读写和备份。

MapReduce

4.5 小结

技术服务业务

5.网站的高可用架构（万无一失）

5.1 网站可用性的度量和考核

5.1.1 网站可用性度量

99% 基本可用
99.9 高可用
99.99% 自动恢复的高可用
99.999% 年度小于5分钟

5.1.2 网站可用性考核

5.2 高可用的网站架构

应用层 负载均衡

服务层 集群方式，分布式服务

数据层 数据同步复制

5.3 高可用的应用

5.3.1 通过负载均衡进行无状态服务的失效转移

5.3.2 应用服务器集群的Session管理

1. Session复制

2. Session绑定

利用负载均衡的源地址Hahs算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。

3. 利用Cookie记录Session

4. Session服务器

同一管理Session信息，状态分离。

5.4 高可用的服务

1. 分级管理

部署隔离

2. 超时设置

3. 异步调用

通过消息队列避免服务失败道义整个应用的请求失败。

4. 服务降级

拒绝服务：拒绝优先级低的应用的调用，随机拒绝部分请求

关闭服务：关闭部分不重要的服务，或者不重要的功能，以节约系统开销

淘宝双十一：关闭评价，确认收货等非核心服务。

5. 幂等性设计

5.5 高可用的数据

数据备份，失效转移。

5.5.1 CAP原理

1. 数据持久性

2. 数据可访问性

3. 数据一致性

数据强一致

数据用户一致

存储不一致，但是终端用户访问，通过纠错和校验机制，能正确返回给用户

数据最终一致

5.5.2 数据备份

冷备份

热备份 同步热备 异步热备

5.5.3 失效转移

1. 失效确认 心跳坚持，程序范文失败

2. 访问转移

3. 数据恢复

5.6 高可用网站的软件质量保证

5.6.1 网站发布

负载一部分，一部分处理

5.6.2 自动化测试

回归测试

Selenium

5.6.3 预发布验证

5.6.4 代码控制

5.6.5 自动化发布

5.6.6 灰度发布

部分发布--故障回滚

6.网站的伸缩性架构（永无止境）

网站的伸缩性是指在不需要改变完整的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。

在系统演化过程中，最重要的手段就是使用服务器集群，通过不断的向集群中添加服务器来增强整个集群的处理能力。

6.1 网站架构的伸缩性设计

6.1.1 不同功能进行物理分离实现伸缩

将业务处理流程上的不同部分分离不熟。

将业务分模块部署。

6.1.2 单一功能通过集群规模实现伸缩

6.2 应用服务器集群的伸缩性设计

6.2.1 HTTP重定向负载均衡

6.2.2 DNS域名解析负载均衡

DNS解析作为第一级负载均衡手段。

6.2.3 反向代理负载均衡

6.2.4 IP负载均衡

6.2.5 数据链路层负载均衡

LVS

6.2.6 负载均衡算法

1. 根据负载均衡算法和Web服务器列表计算得到集群中的一台Web服务器的地址。
2. 将请求数据发送到该地址对应的Web服务器上。

常用的算法：

轮询（Round Robin）:所有请求依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同。

加权轮询（Weighted Round Robin）:根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器。

随机（Random）：请求随机分配到各个应用服务器。

最少连接（Least Connections）:记录每个应用服务器正在处理的连接数，将请求分发到最少连接的服务器。

源地址散列（Source Hahsing）：根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期类重复使用。

6.3 分布式缓存集群的伸缩性设计

缓存请求不可以在缓存服务集群中的任意一台处理，必须先找到缓存数据的服务器。

6.3.1 Memcached 分布式缓存集群访问模型

6.3.2 Memcached 分布式缓存集群的伸缩性挑战

一致性算法

6.3.3 分布式缓存的一致性Hash算法

6.4 数据存储服务器集群的伸缩性设计

6.4.1 关系型数据库

主从分离

数据分库：不同业务表部署在不同的数据库集群上，这种方式的制约条件是跨库的表不能Join操纵。

分表

amoeba

cobar gtihub

MyCAT

Atlas

6.4.2 NoSQL 数据库的伸缩性设计

HBase

6.5

具体问题具体对待

7.网站的可扩展架构（随需应变）

扩展性：指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。开闭原则：对扩展开发，对修改关闭。当系统增加新功能的时候不需要对现有系统的结构和代码进行修改。

伸缩性：系统能够通过增加，减少自身资源规模的方式增强（减弱）自己计算处理事物的能力。

7.1 构建可扩展的网络架构

模块化

7.2 利用分布式消息队列降低系统耦合性

7.2.1 事件驱动架构

事件驱动架构：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通讯完成模块间的合作。

生产者-消费者模型

提高系统的响应时间，消息可以暂存队列，消息接受者根据自身负载处理能力控制消息处理速度。

7.2.2 分布式消息队列

实现分布式异步调用

7.3 利用分布式服务打造可复用的业务平台

使用分布式服务降低系统的耦合性。

分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。

巨无霸应用系统的问题：

1. 编译，部署困难。
2. 代码分支管理困难。
3. 数据库连接耗尽。
4. 新增业务困难。

7.3.1 Web Service 与企业级分布式服务

image

服务提供者：通过WSDL(Web Services Description Language)向注册中心描述自身提供的服务接口属性。

注册中心：使用UDDI(Universal Description Discovery And Intergation)统一描述，发现和集成，发布服务提供者提供的服务。

服务请求者：丛注册中心检索到服务信息后，通过SOAP(Simple Object Access Protocol)简单对象访问协议和服务提供者通讯，使用相关服务。

Web Service缺点：

1. 臃肿的注册和发现机制。
2. 低效的XML序列化手段。
3. 开销相对高的HTTP远程通讯。
4. 复杂的部署和维护手段。

7.3.2 大型网站分布式服务的需求与特点

负载均衡：
服务需要部署在一个集群上。分布式服务框架要能够支付服务请求者使用可配置的负载均衡算法访问服务，使用服务提供者集群实现负载均衡。

失效转移：
当某个服务实例不可用，就将访问切换到其他服务实例上，以实现服务整体高可用。

高效的远程通讯：

整合异构系统：
不同的系统可以通讯。

对应用最少侵入：

版本管理：

实时监控：

7.3.3 分布式服务框架设计

Thrift

Dubbo

7.4 可扩展的数据结构

ColumnFamily

7.5 利用开放平台建设网站生态圈

API接口：开放平台暴露给开发者使用的一组API，其形式可以使RESTful,WebService,RPC等各种形式。

协议转换：将各种API输入转换成内部服务可以标识的形式，并将内部服务的返回封装成API格式。

安全：身份识别，权限控制等手段，开放平台还需要分级的访问带宽限制，保证平台资源被第三方应用公平合理的使用。

审计：记录第三方应用的访问情况，并进行监控，计费。

路由：将开发平台的各种访问路由映射到具体的内部服务。

流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用。

7.6 小结

8.网站的安全架构（固若金汤）

8.1 网站应用攻击与防御

8.1.1 XSS攻击

Cross Site Script 跨站点脚本攻击，指黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。

提交恶意脚本，嵌入恶意脚本的连接。

1. 消毒

消毒，提交数据进行字符转义。

2. HttpOnly

避免攻击者获取Cookie信息

8.1.2 注入攻击

SQL注入攻击

消毒 参数绑定

OS注入攻击

8.1.3 CSRF攻击

Cross Site Request Forgery 跨站点请求伪造。

表单Token

验证码

Referer Check 防盗链

8.1.4 other

1. 错误回写 Error Code

2. HTML注释

3. 文件上传

4. 路径遍历

8.1.5 Web应用防火墙

ModSecurity

8.1.6 网站安全漏洞扫描

App Scan

8.2 信息加密技术及密钥安全管理

8.2.1 单向散列加密

MD5,SHA

密码，生成摘要

8.2.2 对称加密

Cookie加密，通讯加密

DES RC

8.2.3 非对称加密

信息传输，数字签名

非对称加密对对称密码进行安全传输。然后使用对称加密技术进行信息加解密。

RSA

8.2.4 密钥安全管理

8.3 信息过滤与发垃圾

8.3.1 文本匹配

正则表达式

Trie树变种

Hash表

8.3.2 分类算法

贝叶斯分类算法

ARCS算法

8.3.3 黑名单

Hash表

布隆过滤器

8.4 电子商务风险控制

8.4.1 风险

账户风险

买家风险

卖家风险

交易风险

8.4.2 风控

1. 规则引擎

2. 统计模型

8.5 小结

没有绝对的安全就像没有绝对的自由。

9. 淘宝网的架构演化案例分析

1. LAMP + 负载均衡
2. Weblogic+Webx+EJB+iBatis+Linux+Oracle+Ant+搜索引擎
3. JBoss+Webx+Spring+iBatis+linux+Oracle+搜索引擎+分布式缓存
4. 。。。

业务驱动

10. 维基百科的高性能架构设计分析

10.1 架构主要组成部分

GeoDNS：基于开源域名服务器关键BIND的增强版本，可将域名解析到离用户最近的服务器。

LVS：基于Linux的开源负载均衡服务器。

Squid：基于Linux的开源反向代理服务器。

Lighttpd:开源的应用服务器，较主流的Apache服务器更轻量，更快速。许多网站使用Lighttpd作为图片服务器。

PHP：免费的Web应用程序开发语言。

Memcached:无中心高性能的开源分布式缓存系统，稳定，可靠。

Lucene：Java开发的全文搜索引擎。

MYSQL：开源的关系数据库管理系统。

10.2 性能优化策略

10.2.1 前端性能优化

使用缓存

内容页面不包括动态信息，以免页面内容缓存很快失效或者包括过时信息。

每个页面内容有唯一的REST风格的URL，以便CDN快速查找并避免重复缓存。

在HTML响应头写入缓存控制信息，通过应用控制内容是否缓存以缓存有效期等。

10.2.2 服务端性能优化

1. 使用APC,一个PHP字节码缓存模块，加速代码执行减少资源消耗。
2. 使用Imagemagick进行图片处理和转换。
3. 使用Text进行文本格式化，特别是将科学公式内容转换成图片格式。
4. 优化部分PHP内置函数的实现方式。

10.2.3 后端性能优化

缓存--将热点数据缓存在分布式缓存系统中

使用较大的服务器内存。

使用RAID磁盘阵列。

将数据库事物一致性设置在较低水平。

如果Master数据库宕机，立即将应用切换到Salve数据库，同时关闭数据写服务。

11 海量分布式存储系统Doris的高可用架构设计分享

12 网站秒杀系统架构设计案例分析

12.1 秒杀活动的技术挑战

1. 对现有业务造成冲击
2. 高并发下的应用，数据库负载
3. 突然增加的网络及服务器带宽
4. 直接下单

12.2 秒杀系统的应对策略

1. 秒杀系统独立部署
2. 秒杀商品页面静态化
3. 租借秒杀活动网络带宽
4. 动态生成随机下单页面URL

12.3 秒杀系统架构设计

1. 控制秒杀页面按钮点亮

JavaScript前端控制。

2. 如何只运行第一个提交的订单被发送到订单子系统

请求数： 全局订单数

12.4 小结

限流 --- 异步

13 大型网站典型故障案例分析

13.1 写日志也会引发故障

log debug 级别。

关闭第三方库日志输出

13.2 高并发范文数据库引发的故障

首页最好是静态的

首页不应该访问数据库，需要从缓存服务器或者搜索引擎服务器获取。

13.3 高并发情况下锁引发的故障

远程访问加锁

13.4 缓存引发的故障

缓存不在是提高性能的一部分。

13.5 应用启动不同步

Apache，JBoss 同时启动 Apache启动成功之后接受请求，大量请求阻塞在JBoss进程中。

13.6 大文件读写独占磁盘

大文件应该使用类似的分布式文件系统。

13.7 滥用生产环境引发的故障

在生产环境进行压力测试

13.8 不规范的流程引发的故障

diff 对比提交

code review

13.9 不好的编程习惯

NPE

14 架构师

14.1 关注人不是产品

营造自我价值的工作氛围

14.2 发掘人的优秀

事情成就了人，而不是人成就了事情。

14.3 共享美好愿景

14.4 共同参与架构

14.5 学会妥协

分享自己的观点

对于技术细节应该立即验证而不是继续讨论

14.6 成就他人

15 网站架构师攻略

15.1 发现问题，寻找突破

15.2 提出问题，寻求支持

1. 我们的问题。
2. 给上司提封闭式问题，给下属提出开放式问题。
3. 指出问题，对事不对人。
4. 你的这个很好，但是我有一个小建议。

15.3 解决问题，达成绩效

16 漫话网站架构师

16.1 按作用划分

1. 设计型架构师
2. 救火型架构师
3. 布道型架构师
4. Geek型架构师

16.2 按效果划分架构师

1. 夏尔巴人架构师

带团队，对于团队成员是一次自我超越，对于他而言只是完成了一个工作。

2. 斯巴达人架构师

16.3 按职责角色划分架构师

1. 产品架构师
2. 基础服务架构师
3. 基础设施架构师

16.4 按关注层次划分架构师

1. 关注功能

2. 关注非功能

3. 关注团队组织与管理

4. 关注产品运营

5. 关注产品未来

16.5 按口碑划分

1. 最好的

2. 好的

3. 一般

4. 差的

5. 最差的

17 常用架构

image

1. 前端架构

前端指用户请求到达网站应用服务器之前，通常不包含网站业务逻辑，不处理动态内容。

浏览器优化技术：页面缓存，合并HTTP请求，页面压缩。

CDN：内容分发网络，部署在网络运营商机房，通过将静态页面内容分发到离用户最近的CDN服务器。

动静分离，静态资源独立部署：静态资源，JS，CSS，文件部署在专门的服务集群上。

图片服务：网站上传的图片资源部署在图片服务器集群。

反向代理：在应用服务器，静态资源服务器，图片服务器之前，提供页面缓存服务。

DNS：域名服务，将域名解析成IP地址，利用DNS可以实现DNS负载均衡，配置CSN也需要修改DNS，使域名解析后指向CDN服务器。

2. 应用层架构

处理网站业务逻辑的地方

开发框架：分离关注面，安全策略，

页面渲染：开发维护的动态内容和静态页面模块集成起来，组合成最终显示给用户的完整页面。

负载均衡：通过负载均衡将用户请求分发到不同的服务器上。

Session管理：应用服务器应该设计成无状态，不保存用户请求上下文信息，需要专门机制管理Session,使集群内甚至跨集群的应用服务器可以共享Session。

动态页面静态化：

业务拆分：

虚拟化服务器：将一台物理服务器虚拟化成多台虚拟化服务器，对于并发访问低的业务，更容易用较少的资源构建高可用的应用服务器集群。

3. 服务层架构

分布式消息：利用消息队列机制，实现业务和业务，业务和服务之间的异步消息发送及低耦合的业务关系。

分布式服务：提供高性能的，低耦合，易复用，易管理的分布式服务。

分布式缓存：缓存热点数据

分布式配置：

4. 存储层脚骨

提供数据，文件的持久化存储访问与管理服务。

分布式文件： 分布式文件系统。

关系数据库：增加数据库访问路由功能，根据业务配置将数据库访问理由道不同的物理数据库上。

NoSQL数据库：

数据同步：保持多个数据中心的数据之间进行数据同步，以保证每个数据中心都拥有完整的数据。

5. 后台架构

搜索引擎：数据增量更新及全量更新，构建索引，这些通过后台系统定时任务执行。

数据仓库：根据离线数据，提供数据分析与数据挖掘服务。

推荐系统：

6. 数据采集与监控

浏览器数据采集：通过页面嵌入JS脚本采集用户浏览器环境与操作记录，分析用户行为。

服务业务数据采集：采集在服务端记录的用户请求操作日志，采集应用程序运行期业务数据。

服务器性能数据采集：系统负载，内存使用率，网卡流量。

系统监控：采集的数据以图表形式展示出来。

系统报警：超过预设正常情况的阈值，就通过邮件，短信，电话提醒。

7. 安全架构

Web攻击：

数据保护：敏感信息加密传输与存储，保护网站和用户资产。

8. 数据中心机房架构

机房架构：

机柜架构：

服务器架构：

18 开发技术发展历程