澳门新浦京娱乐场网站-www.146.net-新浦京娱乐场官网
做最好的网站

澳门新浦京娱乐场网站:入门梳理,大型网站技

时间过得很快,来淘宝已经两个月了,在这两个月的时间里,自己也感受颇深。下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建一个可 伸缩,高性能,高可用性的分布式互联网应用。

概述

前言

  • 本文是对《大型网站架构设计》(李智慧 著)一书的梳理,类似文字版的“思维导图”
  • 全文主要围绕“性能,可用性,伸缩性,扩展性,安全”这五个要素
  • 性能,可用性,伸缩性这几个要素基本都涉及到应用服务器,缓存服务器,存储服务器这几个方面

罗列了大型网站架构涉及到的概念,附上了简单说明

相关专题:淘宝双11背后高并发技术讨论

三个纬度:演化、模式、要素

概述

  • 三个纬度:演化、模式、要素
  • 五个要素: 性能,可用性,伸缩性,扩展性,安全

前言

  • 本文是对《大型网站架构设计》(李智慧 著)一书的梳理,类似文字版的“思维导图”
  • 全文主要围绕“性能,可用性,伸缩性,扩展性,安全”这五个要素
  • 性能,可用性,伸缩性这几个要素基本都涉及到应用服务器,缓存服务器,存储服务器这几个方面

一 应用无状态(淘宝session框架)

五个要素: 性能,可用性,伸缩性,扩展性,安全

演化历程

图例可参考 大型网站架构演化历程:

  1. 初始阶段的网站架构:一台服务器,上面同时拥有应用程序,数据库,文件,等所有资源。例如 LAMP 架构
  2. 应用和数据服务分离:三台服务器(硬件资源各不相同),分别是应用服务器,文件服务器和数据库服务器
  3. 使用缓存改善网站性能:分为两种,缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
  4. 使用应用服务器集群改善网站并发处理能力:通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
  5. 数据库读写分离:数据库采用主从热备,应用服务器在写数据时访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
  6. 使用反向代理和 CDN 加速网站响应:这两者基本原理都是缓存。反向代理部署在网站的中心机房,CDN 部署在网络提供商的机房
  7. 使用分布式文件系统和分布式数据库系统:数据库拆分的最后手段,更常用的是业务分库
  8. 使用 NoSQL 和搜索引擎:对可伸缩的分布式有更好的支持
  9. 业务拆分:将整个网站业务拆分成不同的应用,每个应用独立部署维护,应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
  10. 分布式服务:公共业务提取出来独立部署

澳门新浦京娱乐场网站 1

演化的价值观

  • 大型网站架构的核心价值是随网站所需灵活应对
  • 驱动大型网站技术发展的主要力量是网站的业务发展

误区

  • 一味追随大公司的解决方案
  • 为了技术而技术
  • 企图用技术解决所有问题

概述

  • 三个纬度:演化、模式、要素
  • 五个要素: 性能,可用性,伸缩性,扩展性,安全

俗话说,一个系 统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢?咱们试想一下,假如我们在session中保存了大量与客户端的状态信 息的话,那么当保存状态信息的server宕机的时候,我们怎么办?通常来说,我们都是通过集群来解决这个问题,而通常所说的集群,不仅有负载均衡,更重要的是要有失效恢复failover,比如tomcat采 用的集群节点广播复制,jboss采 用的配对复制等session状 态复制策略,但是集群中的状态恢复也有其缺点,那就是严重影响了系统的伸缩性,系统不能通过增加更多的机器来达到良好的水平伸缩,因为集群节点间session的 通信会随着节点的增多而开销增大,因此要想做到应用本身的伸缩性,我们需要保证应用的无状态性,这样集群中的各个节点来说都是相同的,从而是的系统更好的水平伸缩。

演化历程

架构模式

模式的关键在于模式的可重复性

  • 分层:横向切分
  • 分割:纵向切分
  • 分布式:分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案:
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 分布式配置,分布式锁,分布式文件,等等
  • 集群:多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务
  • 缓存:将数据放距离计算最近的位置加快处理速度,改善性能第一手段,可以加快访问速度,减小后端负载压力。使用缓存 两个前提条件 :1.数据访问热点不均衡;2.数据某时段内有效,不会很快过期
    • CDN
    • 反向代理
    • 本地缓存
    • 分布式缓存
  • 异步:旨在系统解耦。异步架构是典型的消费者生产者模式,特性如下:
    • 提高系统可用性
    • 加快网站访问速度
    • 消除并发访问高峰
  • 冗余:实现高可用。数据库的冷备份和热备份
  • 自动化:包括发布过程自动化,自动化代码管理,自动化测试,自动化安全检测,自动化部署,自动化监控,自动化报警,自动化失效转移,自动化失效恢复,自动化降级,自动化分配资源
  • 安全:密码,手机校验码,加密,验证码,过滤,风险控制

演化历程

图例可参考 大型网站架构演化历程:

  1. 初始阶段的网站架构:一台服务器,上面同时拥有应用程序,数据库,文件,等所有资源。例如 LAMP 架构
  2. 应用和数据服务分离:三台服务器(硬件资源各不相同),分别是应用服务器,文件服务器和数据库服务器
  3. 使用缓存改善网站性能:分为两种,缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
  4. 使用应用服务器集群改善网站并发处理能力:通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
  5. 数据库读写分离:数据库采用主从热备,应用服务器在写数据时访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
  6. 使用反向代理和 CDN 加速网站响应:这两者基本原理都是缓存。反向代理部署在网站的中心机房,CDN 部署在网络提供商的机房
  7. 使用分布式文件系统和分布式数据库系统:数据库拆分的最后手段,更常用的是业务分库
  8. 使用 NoSQL 和搜索引擎:对可伸缩的分布式有更好的支持
  9. 业务拆分:将整个网站业务拆分成不同的应用,每个应用独立部署维护,应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
  10. 分布式服务:公共业务提取出来独立部署
![](https://upload-images.jianshu.io/upload_images/1001271-b3e91a5822e11c29.png)

OK,上面说了无状态的重要性,那么具体如何实现无状态呢?此时一个session框架就会发挥作用了。幸运的是淘 宝已经具有了此类框架。淘宝的session框架采用的是client cookie实现,主要将状态保存到了cookie里 面,这样就使得应用节点本身不需要保存任何状态信息,这样在系统用户变多的时候,就可以通过增加更多的应用节点来达到水平扩展的目的.但 是采用客户端cookie的 方式来保存状态也会遇到限制,比如每个cookie一般不能超过4K的大小,同时很多浏览器都限制一个站点最多保存20个cookie.淘 宝cookie框 架采用的是“多值cookie”, 就是一个组合键对应多个cookie的 值,这样不仅可以防止cookie数 量超过20, 同时还节省了cookie存 储有效信息的空间,因为默认每个cookie都会有大约50个字节的元信息来描述cookie。

图例可参考大型网站架构演化历程:

核心要素

架构是“最高层次的规划,难以改变的规定”。主要关注五个要素:

  • 性能
  • 可用性(Availability)
  • 伸缩性(Scalability)
  • 扩展性(Extensibility)
  • 安全性

演化的价值观

  • 大型网站架构的核心价值是随网站所需灵活应对
  • 驱动大型网站技术发展的主要力量是网站的业务发展

除了淘宝目前的session框 架的实现方式以外,其实集中式session管理来完成,说具体点就是多个无状态的应用节点连接一个session 服 务器,session服 务器将session保 存到缓存中,session服 务器后端再配有底层持久性数据源,比如数据库,文件系统等等。

初始阶段的网站架构:一台服务器,上面同时拥有应用程序,数据库,文件,等所有资源。例如 LAMP 架构

架构

下面依次对这五个要素进行归纳

误区

  • 一味追随大公司的解决方案
  • 为了技术而技术
  • 企图用技术解决所有问题

二 有效使用缓存(Tair)

应用和数据服务分离:三台服务器(硬件资源各不相同),分别是应用服务器,文件服务器和数据库服务器

高性能

性能的测试指标主要有:

  • 响应时间:指应用执行一个操作需要的时间
  • 并发数:指系统能够同时处理请求的数目
  • 吞吐量:指单位时间内系统处理的请求数量
  • 性能计数器:描述服务器或者操作系统性能的一些数据指标

性能测试方法:

  • 性能测试
  • 负载测试
  • 压力测试
  • 稳定性测试

澳门新浦京娱乐场网站 2

性能优化,根据网站分层架构,可以分为三大类:

  • Web 前端性能优化
    • 浏览器访问优化
      • 减少 http 请求
      • 使用浏览器缓存
      • 启用压缩
      • CSS 放在页面最上面,JavaScript 放在页面最下面
      • 减少 Cookie 传输
    • CDN 加速:本质是一个缓存,一般缓存静态资源
    • 反向代理
      • 保护网站安全
      • 通过配置缓存功能加速 Web 请求
      • 实现负载均衡
  • 应用服务器性能优化:主要手段有 缓存、集群、异步
    • 分布式缓存(网站性能优化第一定律:优化考虑使用缓存优化性能)
    • 异步操作(消息队列,削峰作用)
    • 使用集群
    • 代码优化
      • 多线程(设计为无状态,使用局部对象,并发访问资源使用锁)
      • 资源复用(单例,对象池)
      • 数据结构
      • 垃圾回收
  • 存储服务器性能优化
    • 机械硬盘 vs. 固态硬盘
    • B 树 vs. LSM 树
    • RAID vs. HDFS

架构模式

模式的关键在于模式的可重复性

  • 分层:横向切分

  • 分割:纵向切分

  • 分布式:分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案:分布式应用和服务

    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 分布式配置,分布式锁,分布式文件,等等
  • 集群:多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务

  • 缓存:将数据放距离计算最近的位置加快处理速度,改善性能第一手段,可以加快访问速度,减小后端负载压力。使用缓存 两个前提条件 :1.数据访问热点不均衡;2.数据某时段内有效,不会很快过期

    • CDN
    • 反向代理
    • 本地缓存
    • 分布式缓存
  • 异步:旨在系统解耦。异步架构是典型的消费者生产者模式,特性如下:

    • 提高系统可用性
    • 加快网站访问速度
    • 消除并发访问高峰
  • 冗余:实现高可用。数据库的冷备份和热备份

  • 自动化:包括发布过程自动化,自动化代码管理,自动化测试,自动化安全检测,自动化部署,自动化监控,自动化报警,自动化失效转移,自动化失效恢复,自动化降级,自动化分配资源

  • 安全:密码,手机校验码,加密,验证码,过滤,风险控制

做互联网应用的兄弟应该都清楚,缓存对于一个互联网应用是多么的重要,从浏览器缓存,反向代理缓存,页面缓存,局部页面缓存,对象缓存等等都是缓存应用的场景。

使用缓存改善网站性能:分为两种,缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存

高可用

  • 高可用的网站架构:目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问,主要手段数据和服务的冗余备份及失效转移
  • 高可用的应用:显著特点是应用的无状态性
    • 通过负载均衡进行无状态服务的失效转移
    • 应用服务器集群的 Session 管理
      • Session 复制
      • Session 绑定
      • 利用 Cookie 记录 Session
      • Session 服务器
  • 高可用的服务:无状态的服务,可使用类似负载均衡的失效转移策略,此外还有如下策略
    • 分级管理
    • 超时设置
    • 异步调用
    • 服务降级
    • 幂等性设计
  • 高可用的数据:主要手段是数据备份和失效转移机制
    • CAP 原理
      • 数据一致性(Consisitency)
      • 数据可用性(Availibility)
      • 分区耐受性(Partition Tolerance)
    • 数据备份
      • 冷备:缺点是不能保证数据最终一致和数据可用性
      • 热备:分为异步热备和同步热备
    • 失效转移:由以下三部分组成
      • 失效确认
      • 访问转移
      • 数据恢复
  • 高可用网站的软件质量保证
    • 网站发布
    • 自动化测试
    • 预发布验证
    • 代码控制
      • 主干开发、分支发布
      • 分支开发、主干发布
    • 自动化发布
    • 灰度发布
  • 网站运行监控
    • 监控数据采集
      • 用户行为日志采集(服务器端和客户端)
      • 服务器性能监控
      • 运行数据报告
    • 监控管理
      • 警报系统
      • 失效转移
      • 自动优雅降级

核心要素

架构是“最高层次的规划,难以改变的规定”。主要关注五个要素:

  • 性能
  • 可用性(Availability)
  • 伸缩性(Scalability)
  • 扩展性(Extensibility)
  • 安全性

一 般来说缓存根据与应用程序的远近程度不同可以分为:local cache 和 remote cache。 一般系统中要么采用local cache,要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变 大比较麻烦.

使用应用服务器集群改善网站并发处理能力:通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器

伸缩性

大型网站的“大型”是指:

  • 用户层面:大量用户及大量访问
  • 功能方面:功能庞杂,产品众多
  • 技术层面:网站需要部署大量的服务器

伸缩性的分为如下几个方面

  • 网站架构的伸缩性设计
    • 不同功能进行物理分离实现伸缩
      • 纵向分离(分层后分离)
      • 横向分离(业务分割后分离)
    • 单一功能通过集群规模实现伸缩
  • 应用服务器集群的伸缩性设计
    • HTTP 重定向负载均衡
    • DNS 域名解析负载均衡
    • 反向代理负载均衡(在 HTTP 协议层面,应用层负载均衡)
    • IP 负载均衡(在内核进程完成数据分发)
    • 数据链路层负载均衡(数据链路层修改 mac 地址,三角传输模式,LVS)
    • 负载均衡算法
      • 轮询(Round Robin, RR)
      • 加权轮询(Weighted Round Robin, WRR)
      • 随机(Random)
      • 最少链接(Least Connections)
      • 源地址散列(Source Hashing)
  • 分布式缓存集群的伸缩性设计
    • Memcached 分布式缓存集群的访问模型
      • Memcached 客户端(包括 API,路由算法,服务器列表,通信模块)
      • Memcached 服务器集群
    • Memcached 分布式缓存集群的伸缩性挑战
    • 分布式缓存的一致性 Hash 算法(一致性 Hash 环,虚拟层)
  • 数据存储服务集群的伸缩性设计
    • 关系数据库集群的伸缩性设计
    • NoSQL 数据库的伸缩性设计

架构

下面依次对这五个要素进行归纳

在大部分情况下,我 们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存. 对 于一些读写比不高,同时对数据安全性需求不高的数据,我们可以将其缓存起来从而减少对底层数据库的访问,比如 统计商品的访问次数,统 计API的 调用量等等,可 以采用先写内存缓存然后延迟持久化到数据库,这样可以大大减少对数据库的写压力。

数据库读写分离:数据库采用主从热备,应用服务器在写数据时访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明

可扩展

系统架构设计层面的“开闭原则”

  • 构建可扩展的网站架构
  • 利用分布式消息队列降低耦合性
    • 事件驱动架构(Event Driven Architecture)
    • 分布式消息队列
  • 利用分布式服务打造可复用的业务平台
    • Web Service 与企业级分布式服务
    • 大型网站分布式服务的特点
    • 分布式服务框架设计(Thrift, Dubbo)
  • 可扩展的数据结构(如 ColumnFamily 设计)
  • 利用开放平台建设网站生态圈
高性能

性能的测试指标主要有:

  • 响应时间:指应用执行一个操作需要的时间
  • 并发数:指系统能够同时处理请求的数目
  • 吞吐量:指单位时间内系统处理的请求数量
  • 性能计数器:描述服务器或者操作系统性能的一些数据指标

性能测试方法:

  • 性能测试
  • 负载测试
  • 压力测试
  • 稳定性测试
![](https://upload-images.jianshu.io/upload_images/1001271-318914fcb7fcde84.png)

性能优化,根据网站分层架构,可以分为三大类:

  • Web 前端性能优化

    • 浏览器访问优化减少 http 请求

      • 使用浏览器缓存
      • 启用压缩
      • CSS 放在页面最上面,JavaScript 放在页面最下面
      • 减少 Cookie 传输
    • CDN 加速:本质是一个缓存,一般缓存静态资源

    • 反向代理

      • 保护网站安全
      • 通过配置缓存功能加速 Web 请求
      • 实现负载均衡
  • 应用服务器性能优化:主要手段有 缓存、集群、异步

    • 分布式缓存(网站性能优化第一定律:优化考虑使用缓存优化性能)
    • 异步操作(消息队列,削峰作用)
    • 使用集群
    • 代码优化
      • 多线程(设计为无状态,使用局部对象,并发访问资源使用锁)
      • 资源复用(单例,对象池)
      • 数据结构
      • 垃圾回收
  • 存储服务器性能优化

    • 机械硬盘 vs. 固态硬盘
    • B 树 vs. LSM 树
    • RAID vs. HDFS

OK,我以店铺线的系统为例,在用户浏览店铺的时候,比如店铺介绍,店铺交流区页面,店铺服务条款页面,店铺试衣间页面,以及店铺内搜索界面这些界面更新不是非常频繁,因此适合放到缓存中,这样可以大大减低DB的负载。另外宝贝详情页面相对也更新比较 少,因此也适合放到缓存中来减低DB负载。

使用反向代理和 CDN 加速网站响应:这两者基本原理都是缓存。反向代理部署在网站的中心机房,CDN 部署在网络提供商的机房

网站的安全架构

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段,此外还包括 CSRF,Session 劫持等手段。

  • 攻击与防御
    • XSS 攻击:跨站点脚本攻击(Cross Site Script)
      • 反射型
      • 持久型
    • XSS 防御手段
      • 消毒(即对某些 html 危险字符转义)
      • HttpOnly
    • 注入攻击
      • SQL 注入攻击
      • OS 注入攻击
    • 注入防御
      • 避免被猜到数据库表结构信息
      • 消毒
      • 参数绑定
    • CSRF 攻击:跨站点请求伪造(Cross Site Request Forgery)
    • CSRF 防御:主要手段是识别请求者身份
      • 表单 Token
      • 验证码
      • Referer Check
    • 其他攻击和漏洞
      • Error Code
      • HTML 注释
      • 文件上传
      • 路径遍历
    • Web 应用防火墙(ModSecurity)
    • 网站安全漏洞扫描
  • 信息加密技术及密钥安全管理
    • 单向散列加密:不同输入长度的信息通过散列计算得到固定长度的输出
      • 不可逆,非明文
      • 可加盐(salt)增加安全性
      • 输入的微小变化会导致输出完全不同
    • 对称加密:加密和解密使用同一个密钥
    • 非对称加密
      • 信息传输:公钥加密,私钥解密
      • 数字签名:私钥加密,公钥解密
    • 密钥安全管理:信息安全传输是靠密钥保证的,改善手段有:
      • 把密钥和算法放在一个独立的服务器上
      • 将加解密算法放在应用系统中,密钥放在独立服务器
  • 信息过滤与反垃圾
    • 文本匹配
    • 分类算法
    • 黑名单
高可用
  • 高可用的网站架构:目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问,主要手段数据和服务的冗余备份及失效转移

  • 高可用的应用:显著特点是应用的无状态性

    • 通过负载均衡进行无状态服务的失效转移
    • 应用服务器集群的 Session 管理
      • Session 复制
      • Session 绑定
      • 利用 Cookie 记录 Session
      • Session 服务器
  • 高可用的服务:无状态的服务,可使用类似负载均衡的失效转移策略,此外还有如下策略

    • 分级管理
    • 超时设置
    • 异步调用
    • 服务降级
    • 幂等性设计
  • 高可用的数据:主要手段是数据备份和失效转移机制

    • CAP 原理

      • 数据一致性(Consisitency)
      • 数据可用性(Availibility)
      • 分区耐受性(Partition Tolerance)
    • 数据备份

      • 冷备:缺点是不能保证数据最终一致和数据可用性
      • 热备:分为异步热备和同步热备
    • 失效转移:由以下三部分组成

      • 失效确认
      • 访问转移
      • 数据恢复
  • 高可用网站的软件质量保证

    • 网站发布
    • 自动化测试
    • 预发布验证
    • 代码控制
      • 主干开发、分支发布
      • 分支开发、主干发布
    • 自动化发布
    • 灰度发布
  • 网站运行监控

    • 监控数据采集
      • 用户行为日志采集(服务器端和客户端)
      • 服务器性能监控
      • 运行数据报告
    • 监控管理
      • 警报系统
      • 失效转移
      • 自动优雅降级

三 应用拆分(HSF)

使用分布式文件系统和分布式数据库系统:数据库拆分的最后手段,更常用的是业务分库

伸缩性

大型网站的“大型”是指:

  • 用户层面:大量用户及大量访问
  • 功能方面:功能庞杂,产品众多
  • 技术层面:网站需要部署大量的服务器

伸缩性的分为如下几个方面

  • 网站架构的伸缩性设计

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

      • 纵向分离(分层后分离)
      • 横向分离(业务分割后分离)
    • 单一功能通过集群规模实现伸缩

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

    • HTTP 重定向负载均衡
    • DNS 域名解析负载均衡
    • 反向代理负载均衡(在 HTTP 协议层面,应用层负载均衡)
    • IP 负载均衡(在内核进程完成数据分发)
    • 数据链路层负载均衡(数据链路层修改 mac 地址,三角传输模式,LVS)
    • 负载均衡算法
      • 轮询(Round Robin, RR)
      • 加权轮询(Weighted Round Robin, WRR)
      • 随机(Random)
      • 最少链接(Least Connections)
      • 源地址散列(Source Hashing)
  • 分布式缓存集群的伸缩性设计

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

      • Memcached 客户端(包括 API,路由算法,服务器列表,通信模块)
      • Memcached 服务器集群
    • Memcached 分布式缓存集群的伸缩性挑战

    • 分布式缓存的一致性 Hash 算法(一致性 Hash 环,虚拟层)

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

    • 关系数据库集群的伸缩性设计
    • NoSQL 数据库的伸缩性设计

首先,在说明应用拆分之前,我们先来回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。

使用 NoSQL 和搜索引擎:对可伸缩的分布式有更好的支持

可扩展

系统架构设计层面的“开闭原则”

  • 构建可扩展的网站架构

  • 利用分布式消息队列降低耦合性

    • 事件驱动架构(Event Driven Architecture)
    • 分布式消息队列
  • 利用分布式服务打造可复用的业务平台

    • Web Service 与企业级分布式服务
    • 大型网站分布式服务的特点
    • 分布式服务框架设计(Thrift, Dubbo)
  • 可扩展的数据结构(如 ColumnFamily 设计)

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

系统刚上线初期,用户数并不多,所有的逻辑也许都是放在一个系统中的,所有逻辑跑到一个进程或者一个应用当中,这个时候因为比较用户少,系统访问量低,因此将全部的逻辑都放在一个应用未尝不可。但是,兄弟们都清楚,好景不长,随着系统用户的不断增加,系统的访问压力越来越多,同时随着系统发展,为了满足用户 的需求,原有的系统需要增加新的功能进来,系统变得越来越复杂的时候,我们会发现系统变得越来越难维护,难扩展,同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢?明智的办法就是拆分(这也算是一种解耦),我们需要将原来的系统根据一定的标准,比如业务相关性等分为不同的子系统, 不同的系统负责不同的功能,这样切分以后,我们可以对单独的子系统进行扩展和维护,从而提高系统的扩展性和可维护性,同时我们系统的水平伸缩性scale out大 大的提升了,因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统,而不会像拆分以前,每次系统压力变大的时候,我们都需要对整个大系统进行伸缩,而这样的成本是比较大的,另外经过切分,子系统与子系统之间的耦合减低了,当某个子系统暂时不可用的时候,整体系统还是可用的,从而整 体系统的可用性也大大增强了。

业务拆分:将整个网站业务拆分成不同的应用,每个应用独立部署维护,应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统

网站的安全架构

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段,此外还包括 CSRF,Session 劫持等手段。

  • 攻击与防御

    • XSS 攻击:跨站点脚本攻击(Cross Site Script)

      • 反射型
      • 持久型
    • XSS 防御手段

      • 消毒(即对某些 html 危险字符转义)
      • HttpOnly
    • 注入攻击

      • SQL 注入攻击
      • OS 注入攻击
    • 注入防御

      • 避免被猜到数据库表结构信息
      • 消毒
      • 参数绑定
    • CSRF 攻击:跨站点请求伪造(Cross Site Request Forgery)

    • CSRF 防御:主要手段是识别请求者身份

      • 表单 Token
      • 验证码
      • Referer Check
    • 其他攻击和漏洞Error Code

      • HTML 注释
      • 文件上传
      • 路径遍历
    • Web 应用防火墙(ModSecurity)

    • 网站安全漏洞扫描

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

    • 单向散列加密:不同输入长度的信息通过散列计算得到固定长度的输出

      • 不可逆,非明文
      • 可加盐(salt)增加安全性
      • 输入的微小变化会导致输出完全不同
    • 对称加密:加密和解密使用同一个密钥

    • 非对称加密

      • 信息传输:公钥加密,私钥解密
      • 数字签名:私钥加密,公钥解密
    • 密钥安全管理:信息安全传输是靠密钥保证的,改善手段有:

      • 把密钥和算法放在一个独立的服务器上
      • 将加解密算法放在应用系统中,密钥放在独立服务器
  • 信息过滤与反垃圾文本匹配

    • 分类算法
    • 黑名单

因此一个大型的互联网应用,肯定是要经过拆分,因为只有拆分了,系统的扩展性,维护性,伸缩性,可用性才会变的更好。但是拆分也给系统带来了问题,就是子系统之间如何通信的问题,而具体的通信方式有哪些呢?一般有同步通信和异步通信,这里我们首先来说下同步通信,下面的主题“消息系 统”会说到异步通信。既然需要通信,这个时候一个高性能的远程调用框架就显得非常总要啦,因此咱们淘宝也有了自己的HSF框 架。

分布式服务:公共业务提取出来独立部署java源码 springmvc mybatis SSM获取下载地址   

上 面所说的都是拆分的好处,但是拆分以后必然的也会带来新的问题,除了刚才说的子系统通信问题外,最值得关注的问题就是系统之间的依赖关系,因为系统多了,系统的依赖关系就会变得复杂,此时就需要更好的去关注拆分标准,比如能否将一些有依赖的系统进行垂直化,使得这些系统的功能尽量的垂直,这也是目前淘宝正 在做的系统垂直化,同时一定要注意系统之间的循环依赖,如果出现循环依赖一定要小心,因为这可能导致系统连锁启动失败。

澳门新浦京娱乐场网站 3

OK,既然明白了拆分的重要性,我们看看随着淘宝的发展,淘宝本身是如何拆分系统的。

演化的价值观

首先我们来看以下这个图:作者图片已无法打开,请见谅)

大型网站架构的核心价值是随网站所需灵活应对

从上面的图可以看出淘宝系统的一个演变过程,在这个演变的过程中,我们所说的拆分就出现V2.2和V3.0之 间。在V2.2版 本中,淘宝几乎所有的逻辑都放在(Denali)系统中,这样导致的问题就是系统扩展和修改非常麻烦,并且更加致命的是随着淘宝业务量的增加,如果按照V2.2的架构已经没有办法支撑以后淘宝的快速发展,因此大家决定对整个系统进行拆分,最 终V3.0版本的淘宝系统架构图如下:作者图片已无法打开,请见谅)

驱动大型网站技术发展的主要力量是网站的业务发展

从上图可以看出V3.0版 本的系统对整个系统进行了水平和垂直两个方向的拆分,水平方向上,按照功能分为交易,评价,用户,商品等系统,同样垂直方向上,划分为业务系统,核心业务系统以及以及基础服务,这样以来,各个系统都可以独立维护和独立的进行水平伸缩,比如交易系统可以在不影响其它系统的情况下独立的进行水平伸缩以及功能扩展。

误区

从上面可以看出,一个大型系统要想变得可维护,可扩展,可伸缩,我们必须的对它进行拆分,拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题,关于通信方面,淘宝目前独立开发了自己的高性 能服务框架HSF, 此框架主要解决了淘宝目前所有子系统之间的同步和异步通信(目前HSF主要用于同步场合,FutureTask方 式的调用场景还比较少)。至于系统间的依赖管理,目前淘宝还做的不够好,这应该也是我们以后努力解决的问题。

一味追随大公司的解决方案

四 数据库拆分(TDDL)

为了技术而技术

在前面“应用拆分”主题中,我们提到了一个大型互联网应用需要进行良好的拆分,而那里我们仅仅说了”应用级别”的拆 分,其实我们的互联网应用除了应用级别的拆分以外,还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统,通常就是所说的RDBMS进 行拆分。

企图用技术解决所有问题

好了,确定了这个小节的主题之后,我们回顾一下,一个互联网应用从小变大的过程中遇到的一些问题,通过遇到的问题来引出我们拆分RDBMS的 重要性。

架构模式

系 统刚开始的时候,因为系统刚上线,用户不多,那个时候,所有的数据都放在了同一个数据库中,这个时候因为用户少压力小,一个数据库完全可以应付的了,但是随着运营那些哥们辛苦的呐喊和拼命的推广以后,突然有一天发现,oh,god,用户数量突然变多了起来,随之而 来的就是数据库这哥们受不了,它终于在某一天大家都和惬意的时候挂掉啦。此时,咱们搞技术的哥们,就去看看究竟是啥原因,我们查了查以后,发现原来是数据库读取压力太大了,此时咱们都清楚是到了读写分离的时候,这个时候我们会配置一个server为master节 点,然后配几个salve节 点,这样以来通过读写分离,使得读取数据的压力分摊到了不同的salve节点上面,系统终于又恢复了正常,开始正常运行了。但是好景还是不长,有一天我们发现master这哥们撑不住了,它负载老高了,汗 流浃背,随时都有翘掉的风险,这个时候就需要咱们垂直分区啦(也就是所谓的分库),比如将商品信息,用户信息,交易信息分别存储到不同的数据库中,同时还可以针对商品信息的库采用master,salve模式,OK, 通过分库以后,各个按照功能拆分的数据库写压力被分担到了不同的server上面,这样数据库的压力终于有恢复到正常状态。但是是不是这样,我们就可以高枕无忧了呢?NO,这个NO, 不是我说的,是前辈们通过经验总结出来的,随着用户量的不断增加,你会发现系统中的某些表会变的异常庞大,比如好友关系表,店铺的参数配置表等,这个时候无论是写入还是读取这些表的数据,对数据库来说都是一个很耗费精力的事情,因此此时就需要我们进行“水平分区”了(这就是俗话说的分表,或者说sharding).

模式的关键在于模式的可重复性

OK,上 面说了一大堆,无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”,一个大型的互联网 应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区(分库),然后再到水平分区(分表,sharding)的过程,而在这个过程中,Master/salve 以 及垂直分区相对比较容易,对应用的影响也不是很大,但是分表会引起一些棘手的问题,比如不能跨越多个分区join查 询数据,如何平衡各个shards的 负载等等,这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响,使得底层数据的访问对应用透明化。

分层:横向切分

拿淘宝目前的情况来说,淘宝目前也正在从昂贵的高端存储(小型机 ORACLE)切换到MYSQL,切 换到MYSQL以 后,势必会遇到垂直分区(分库)以及水平分区(Sharding)的问题,因此目前淘宝根据自 己的业务特点也开发了自己的TDDL框架,此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制

分割:纵向切分

五 异步通信(Notify)

分布式:分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案:

澳门新浦京娱乐场网站:入门梳理,大型网站技术架构。在”远 程调用框架”的 介绍中,我 们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是 拆分了以后,子 系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节 中,我 们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既 然说到了异步通信,那 么”消 息中间件”就 要登场了,采 用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.

分布式应用和服务

说 到异步通信,我们需要关注的一点是这里的异步一定是根据业务特点来的,一定是针对业务的异步,通常适合异步的场合是一些松耦合的通信场合,而对于本身业务上关联度比较大的业务系统之间,我们还是要采用同步通信比较靠谱。

分布式静态资源

OK,那 么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想,假如系统有A和B两个 子系统构成,假如A和B是 同步通信的话,那么要想使得系统整体伸缩性提高必须同时对A和B进行 伸缩,这就影响了对整个系统进行scale out.其次,同步调用还会影响到可用性,从数学推理的角度来说,A同 步调用B, 如果A可 用,那么B可 用,逆否命题就是如果B不 可用,那么A也 不可用,这将大大影响到系统可用性,再次,系统之间异步通信以后可以大大提高系统的响应时间,使得每个请求的响应时间变短,从而提高用户体验,因此异步在提高了系统的伸缩性以及可用性的同时,也大大的增强了请求的响应时间(当然了,请求的总体处理时间也许不会变少)。

分布式数据和存储

下面我们就以淘宝的业务来看看异步在淘宝的具体应用。交易系统会与很多其它的业务系统交互,如果在一次交易过程中采用同步调用的话,这就要求要向交易成功,必须依赖的所有系统都可用,而如果采用异步通信以后,交易系 统借助于消息中间件Notify和 其它的系统进行了解耦,这样以来当其它的系统不可用的时候,也不会影响到某此交易,从而提高了系统的可用性。

分布式计算

最后,关于异步方面的讨论,我可以 推荐大家一些资源:

分布式配置,分布式锁,分布式文件,等等

1 . J2EE meets web2.0

集群:多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务

  1. Ebay架构特点(HPTS 2009)

缓存:将数据放距离计算最近的位置加快处理速度,改善性能第一手段,可以加快访问速度,减小后端负载压力。使用缓存两个前提条件:1.数据访问热点不均衡;2.数据某时段内有效,不会很快过期

六 非结构化数据存储 ( TFS,NOSQL)

CDN

在 一个大型的互联网应用当中,我们会发现并不是所有的数据都是结构化的,比如一些配置文件,一个用户对应的动态,以及一次交易的快照等信息,这些信息一般不适合保存到RDBMS中, 它们更符合一种Key-value的 结构,另外还有一类数据,数据量非常的大,但是实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储,另外一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,从而影响到其它 的数据读取性能,因此这些信息也需要和其它信息分开存储,而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中,因此淘宝目前也开发了自己的分布式文件系统TFS,TFS目 前限制了文件大小为2M, 适合于一些小于2M数 据的存放。

反向代理

随 着互联网的发展,业界从08年 下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性3者 不能同时满足,最多只能同时满足两个,我们传统的关系数据采用了ACID的事务策略,而ACID的 事务策略更加讲究的是一种高一致性而降低了可用性的需求,但是互联网应用往往对可用性的要求要略高于一致性的需求,这个时候我们就需要避免采用数据的ACID事 务策略,转而采用BASE事 务策略,BASE事 务策略是基本可用性,事务软状态以及最终一致性的缩写,通过BASE事务策略,我们可以通过最终一致性来提升系统的可用性,这也是目前很多NOSQL产品所采用的策略,包括facebook 的cassandra,apache hbase,google bigtable等,这些产品非常适合一些非结构化的数据,比如key-value形 式的数据存储,并且这些产品有个很好的优点就是水平伸缩性。目前淘宝也在研究和使用一些成熟的NOSQL产品。

本地缓存

七 监控、预警系统

分布式缓存

对于大型的系统 来说,唯一可靠的就是系统的各个部分是不可靠。

异步:旨在系统解耦。异步架构是典型的消费者生产者模式,特性如下:

因 为一个大型的分布式系统中势必会涉及到各种各样的设备,比如网络交换机,普通PC机,各种型号的网卡,硬盘,内存等等,而这些东东都在数量非常多的时候,出现错误的概率也会变大,因此我们需要时时刻刻监控系统的状态,而监控也有粒度的粗细之分,粒度粗一点的话,我们需要对整个 应用系统进行监控,比如目前的系统网络流量是多少,内存利用率是多少,IO,CPU的 负载是多少,服务的访问压力是多少,服务的响应时间是多少等这一系列的监控,而细粒度一点的话,我们就需对比如应用中的某个功能,某个URL的 访问量是多,每个页面的PV是 多少,页面每天占用的带宽是多少,页面渲染时间是多少,静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可少了。

提高系统可用性

前 面说了一个监控系统的重要性,有了监控系统以后,更重要的是要和预警系统结合起来,比如当某个页面访问量增多的时候,系统能自动预警,某台Server的CPU和 内存占用率突然变大的时候,系统也能自动预警,当并发请求丢失严重的时候,系统也能自动预警等等,这样以来通过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题,提高系统的稳定性和可用性。

加快网站访问速度

八 配置统一管理

消除并发访问高峰

一个大型的分布 式应用,一般都是有很多节点构成的,如果每次一个新的节点加入都要更改其它节点的配置,或者每次删除一个节点也要更改配置的话,这样不仅不利于系统的维护和管理,同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的,如果不进行统一的配置管理,就需要再所有的系统上维护一份配置,这样会 造成配置的管理维护很麻烦,而通过一个统一的配置管理可以使得这些问题得到很好的解决,当有新的节点加入或者删除的时候,配置管理系统可以通知各个节点更新配置,从而达到所有节点的配置一致性,这样既方便也不会出错。

冗余:实现高可用。数据库的冷备份和热备份

...

自动化:包括发布过程自动化,自动化代码管理,自动化测试,自动化安全检测,自动化部署,自动化监控,自动化报警,自动化失效转移,自动化失效恢复,自动化降级,自动化分配资源

安全:密码,手机校验码,加密,验证码,过滤,风险控制

核心要素

澳门新浦京娱乐场网站:入门梳理,大型网站技术架构。架构是“最高层次的规划,难以改变的规定”。主要关注五个要素:

性能

可用性(Availability)

伸缩性(Scalability)

扩展性(Extensibility)

安全性

架构

下面依次对这五个要素进行归纳

高性能

性能的测试指标主要有:

响应时间:指应用执行一个操作需要的时间

并发数:指系统能够同时处理请求的数目

吞吐量:指单位时间内系统处理的请求数量

性能计数器:描述服务器或者操作系统性能的一些数据指标

性能测试方法:

性能测试

负载测试

压力测试

稳定性测试

澳门新浦京娱乐场网站 4

性能优化,根据网站分层架构,可以分为三大类:

Web 前端性能优化

浏览器访问优化

减少 http 请求

使用浏览器缓存

启用压缩

CSS 放在页面最上面,JavaScript 放在页面最下面

减少 Cookie 传输

CDN 加速:本质是一个缓存,一般缓存静态资源

反向代理

保护网站安全

通过配置缓存功能加速 Web 请求

实现负载均衡

应用服务器性能优化:主要手段有 缓存、集群、异步

分布式缓存(网站性能优化第一定律:优化考虑使用缓存优化性能)

异步操作(消息队列,削峰作用)

使用集群

代码优化

多线程(设计为无状态,使用局部对象,并发访问资源使用锁)

资源复用(单例,对象池)

数据结构

垃圾回收

存储服务器性能优化

机械硬盘 vs. 固态硬盘

B 树 vs. LSM 树

RAID vs. HDFS

高可用

高可用的网站架构:目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问,主要手段数据和服务的冗余备份及失效转移

高可用的应用:显著特点是应用的无状态性

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

应用服务器集群的 Session 管理

Session 复制

Session 绑定

利用 Cookie 记录 Session

Session 服务器

高可用的服务:无状态的服务,可使用类似负载均衡的失效转移策略,此外还有如下策略

分级管理

超时设置

异步调用

服务降级

幂等性设计

高可用的数据:主要手段是数据备份和失效转移机制

CAP 原理

数据一致性(Consisitency)

数据可用性(Availibility)

分区耐受性(Partition Tolerance)

数据备份

冷备:缺点是不能保证数据最终一致和数据可用性

热备:分为异步热备和同步热备

失效转移:由以下三部分组成

失效确认

访问转移

数据恢复

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

网站发布

自动化测试

预发布验证

代码控制

主干开发、分支发布

分支开发、主干发布

自动化发布

灰度发布

网站运行监控

监控数据采集

用户行为日志采集(服务器端和客户端)

服务器性能监控

运行数据报告

监控管理

警报系统

失效转移

自动优雅降级

伸缩性

大型网站的“大型”是指:

用户层面:大量用户及大量访问

功能方面:功能庞杂,产品众多

技术层面:网站需要部署大量的服务器

伸缩性的分为如下几个方面

网站架构的伸缩性设计

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

纵向分离(分层后分离)

横向分离(业务分割后分离)

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

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

HTTP 重定向负载均衡

DNS 域名解析负载均衡

反向代理负载均衡(在 HTTP 协议层面,应用层负载均衡)

IP 负载均衡(在内核进程完成数据分发)

数据链路层负载均衡(数据链路层修改 mac 地址,三角传输模式,LVS)

负载均衡算法

轮询(Round Robin, RR)

加权轮询(Weighted Round Robin, WRR)

随机(Random)

最少链接(Least Connections)

源地址散列(Source Hashing)

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

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

Memcached 客户端(包括 API,路由算法,服务器列表,通信模块)

Memcached 服务器集群

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

分布式缓存的一致性 Hash 算法(一致性 Hash 环,虚拟层)

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

关系数据库集群的伸缩性设计

NoSQL 数据库的伸缩性设计

可扩展

系统架构设计层面的“开闭原则”

构建可扩展的网站架构

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

事件驱动架构(Event Driven Architecture)

分布式消息队列

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

Web Service 与企业级分布式服务

大型网站分布式服务的特点

分布式服务框架设计(Thrift, Dubbo)

可扩展的数据结构(如 ColumnFamily 设计)

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

网站的安全架构

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段,此外还包括 CSRF,Session 劫持等手段。

攻击与防御

XSS 攻击:跨站点脚本攻击(Cross Site Script)

反射型

持久型

XSS 防御手段

消毒(即对某些 html 危险字符转义)

HttpOnly

注入攻击

SQL 注入攻击

OS 注入攻击

注入防御

避免被猜到数据库表结构信息

消毒

参数绑定

CSRF 攻击:跨站点请求伪造(Cross Site Request Forgery)

CSRF 防御:主要手段是识别请求者身份

表单 Token

验证码

Referer Check

其他攻击和漏洞

Error Code

HTML 注释

文件上传

路径遍历

Web 应用防火墙(ModSecurity)

网站安全漏洞扫描

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

单向散列加密:不同输入长度的信息通过散列计算得到固定长度的输出

不可逆,非明文

可加盐(salt)增加安全性

输入的微小变化会导致输出完全不同

对称加密:加密和解密使用同一个密钥

非对称加密

信息传输:公钥加密,私钥解密

数字签名:私钥加密,公钥解密

密钥安全管理:信息安全传输是靠密钥保证的,改善手段有:

把密钥和算法放在一个独立的服务器上

将加解密算法放在应用系统中,密钥放在独立服务器

信息过滤与反垃圾

文本匹配

分类算法

黑名单

我这里有一个大牛交流群,里面每天更新新的视频新的技术,群里有阿里大牛直播讲解技术,以及Java大型互联网技术的视频免费分享给大家。如果想学习Java工程化、高性能及分布式、深入浅出。性能调优、Spring,MyBatis,Netty源码分析的朋友可以加Java进阶群:454377428,群里有阿里大牛直播讲解技术,以及Java大型互联网技术的视频免费分享给大家

本文由澳门新浦京娱乐场网站发布于服务器,转载请注明出处:澳门新浦京娱乐场网站:入门梳理,大型网站技