美文网首页
《大型网站技术架构》读书笔记

《大型网站技术架构》读书笔记

作者: 米达麦亚 | 来源:发表于2017-02-22 17:25 被阅读0次

    大型网站架构演化

    特点

    高并发,大流量 高可用 海量数据 用户广泛,网络情况复杂 安全情况恶劣 需求变更快 渐进式发展

    演变

    1. 一台服务器,LNMP,应用程序访问文件和数据库
    2. 服务和数据分离 应用服务器:处理业务逻辑(CPU) 文件服务器:存储文件(硬盘) 数据库服务器:磁盘检索和数据缓存(硬盘和内存)
    3. 使用缓存 本地缓存和远程分布式缓存 减少数据访问压力,新的瓶颈是应用服务器
    4. 应用服务器集群 分布式,改善并发处理能力 可伸缩性,单服务器再强大也不行 前置负载均衡调度服务器
    5. 数据库读写分离 数据库再次成为瓶颈 多台数据库主从模式,读写分离
    6. 加速响应 缓存,CDN+反向代理 CDN是在网络提供商机房缓存,反向代理是在负载均衡前的网站机房缓存
    7. 分布式文件系统和分布式数据库 通常数据库是拆库,只有单表数据非常大时才使用分布式数据库
    8. 使用nosql和搜索引擎 解决复杂的数据存储和检索需求
    9. 业务拆分
    10. 分布式服务 其实就是业务逻辑层和后端服务分开,业务逻辑层不访问数据

    大型网站架构模式

    1. 分层 应用层:业务和视图展示 服务层:为应用层提供服务支持 数据层:提供数据存储访问服务
    2. 分隔 业务分隔,不同模块
    3. 分布式 一个业务分拆多个子业务,部署在不同的服务器上
    4. 集群 同一个业务,部署在多个服务器上
    5. 缓存 CDN 反向代理 本地缓存(如hhvm的apc) 分布式缓存
    6. 异步 单一服务器:多线程共享内存队列 分布式:消息队列
    7. 冗余 服务器集群,数据库备份
    8. 自动化 自动化发布:自动化代码管理,自动化测试,自动化安全测试,自动化部署 自动化监控 自动化报警 自动化失效转移/恢复 自动化降级 自动化资源分配
    9. 安全 身份验证,加密,攻击防范,过滤,风控

    大型网站核心架构要素

    1. 性能
    2. 可用性
    3. 伸缩性
    4. 扩展性
    5. 安全性

    高性能

    不同视角

    用户视角改善:前端优化,cdn,反向代理等
    开发人员主要使用的优化手段:缓存加速数据读取,集群提高吞吐,异步消息加快请求响应及消峰,代码优化改善程序性能
    运维:建设优化骨干网,虚拟化技术优化资源利用

    性能指标

    响应时间
    并发数:同时请求的数目
    吞吐量:单位时间内系统存储量
    性能计数器:系统负载,cpu/内存/磁盘/IO使用

    性能测试方法

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

    web前端性能优化

    浏览器优化

    减少http请求,合并css/js/图片
    使用浏览器缓存:逐量更新缓存
    启用压缩:带宽良好服务器资源不足时不合适
    CSS放上面,js放下面
    减少cookie传输

    CDN加速

    反向代理

    正向代理隐藏了真实的请求客户端,反向代理隐藏了真实的服务端
    负载均衡,静态缓存

    应用服务器优化

    分布式缓存

    缓存:1.访问数据块的存储介质 2.存储计算后的数据
    本质是内存hash表
    缓存架构:JBossCache:同步式 memcached:不互相通讯,缓存和应用分类
    远程通信设计:1.通信协议:tcp/udp/http 2.通信序列化协议 xml/json/protobuffer

    异步操作

    因为后继操作可能失败,所以需要业务流程配合

    集群

    代码优化

    (都是从java角度)多线程,资源复用(单例和资源池),数据结构,垃圾回收

    存储性能优化

    机械硬盘VS固态硬盘 B+树 VS LSM树 Raid VS HDFS

    高可用

    可用性度量

    2个9,一年小于88个小时;4个9,一年小于53分钟

    高可用架构

    传统企业级应用:昂贵的软硬件IOE,IBM的小/中/大型机及专有OS,oracle数据库,emc存储
    集群:心跳监测

    高可用应用

    应用的无状态性,不保存业务上下文,服务实例完全对等
    负载均衡进行无状态服务的失效转移

    Session(上下文对象)管理

    session复制:所有服务器都保存一份,彼此同步
    session绑定:会话粘滞,相同ip请求发到同一台服务器
    cookie记录session
    session服务器:无状态的应用服务器和有状态的session服务器

    高可用的服务

    分级管理:核心应用和服务使用更好硬件,服务部署隔离
    超时设置:超时重试,请求其他服务器
    异步调用:比如消息通知类
    服务降级:拒绝部分低优先级的服务 或者 关闭部分不重要的功能
    幂等性设计:就是可重入

    高可用数据

    CAP原理:数据一致性,数据可用性,数据分区容忍性,三个条件无法同时满足
    数据备份:冷备份(定时备份),热备份,异步(一主多从),同步(对等,无主从)
    失效转移:失效确认,访问转移,数据恢复

    软件质量保证

    网站发布:关闭负载均衡上部分路由-》关闭服务-》同步代码-》启动服务-》恢复路由
    自动化测试
    预发布验证:预览机外部用户无法访问,绑host或通过ip直接访问
    代码控制:分支开发,主干发布
    自动化发布
    灰度发布:分级上线

    监控

    数据采集

    用户行为日志,服务度日志,客户端浏览器端日志收集
    服务器性能监控(应用程序开发无关)
    运行数据报告(应用程序开发相关)

    监控管理

    系统报警,失效转移,自动降级

    伸缩性

    网站架构伸缩性

    分布式集群,不同功能通过物理分离实现伸缩(纵向分层,横向业务分隔),单一功能通过集群伸缩

    应用服务器集群的伸缩性

    负载均衡:HTTP重定向,DNS域名解析,反向代理,IP负载,数据链路层
    算法:轮询,加权轮询,随机,最少链接,原地址散列(会话粘滞)
    反向代理,IP负载,数据链路层即反向代理模式,透明模式,三角模式
    反向代理:修改源ip,http层 透明模式:不修改源ip,传输层 三角模式:返回时不经过负载均衡,数据链路层
    https://www.zhihu.com/question/20553431 http://lobert.iteye.com/blog/2159970

    分布式缓存集群的伸缩性

    memcached访问模型:应用程序请求memcached客户端的api,客户端内先请求路由算法,分配机器,然后通过通信模块和真正的服务器集群通信
    原始hash算法不适合扩容,一致性hash算法通过hash环,等于划分了很多区间,增加的新节点只会影响相邻的那个节点
    但这样带来了负载均衡的问题。解决方法是增加虚拟层。每个物理节点对应约150个虚拟节点,这样插入时影响小,负载均衡好

    数据存储集群的伸缩性

    关系数据库

    主从读写分离 分库(类似业务分隔,但跨库不能join)
    cobar(DB proxy),支持数据分片,一张表存储在多个数据库中
    cobar系统组件模型:前端通信模块-》sql解析模块->sql路由模块-》sql执行代理模块-》后端通信模块-》结果合并模块-》前端通信模块
    cobar服务器集群伸缩就是普通的应用服务器集群伸缩
    mysql服务器集群伸缩时,cobar利用mysql的数据同步功能,以schema为单位迁移(schema下面有表,视图等)
    数据同步完成-》修改cobar路由配置-》删除原机器中相关schema

    NOSQL数据库

    NOSQL数据库:放弃以关系代数为基础的结构化查询语言(SQL)和事务一致性保证(ACID),强化可伸缩性和高可用性
    Apache HBase

    可扩展

    扩展性是系统设计层面的开闭原则(对扩展开发,对修改关闭),增加新功能不用修改现有系统架构和代码

    可扩展的网站架构

    低耦合(模块间关联性低),模块化(分层和分隔)

    分布式消息队列

    事件驱动架构,消息队列采用发布-订阅模式。发送者发到消息队列,然后消息队列推给接受者。
    应用程序服务器调用远程访问接口将消息推给消息队列服务器,消息队列服务器将消息写入本地内存队列立刻返回成功响应给消息生产者。消息队列服务器根据消息订阅列表查找订阅该消息的消费者应用程序,将消息队列中的消息按先进先出(FIFO)的原则通过远程通信接口发送给消息消费者程序。

    分布式服务

    纵向拆分:大应用拆成小应用 横向拆分:可服用业务拆分
    WebService:服务提供者向注册中心注册,服务请求者从注册中心检索到服务信息后,通过SOAP(简单对象访问协议)和服务提供者通信
    分布式服务框架需要支持除了webService提供的服务注册和发现,服务调用外,还需要支持的特性:负载均衡,失效转移,高效远程通信,整合异构系统(不同语言,不同平台),对应用最小入侵,版本管理,实时监控
    SOA Facebook:thrift 阿里:Dubbo

    可扩展的数据结构

    NoSQL的ColumnFamily(列族)

    开发平台

    api接口,协议转换,安全,审计,路由,流程封装

    安全

    网站攻击和防御

    XSS攻击

    反射型:诱使用户点击嵌入恶意脚本的链接
    持久型:恶意脚本请求保持在web站点中
    防御手段:消毒(转义),httpOnly

    注入攻击

    获取表结构方式:开源,错误回显,盲注
    防御:消毒,参数绑定(orm框架)

    CSRF攻击

    跨站请求攻击
    防御:token验证,验证码,refer check(来源请求,防盗链也是这个功能)

    其他攻击

    ErrorCode,html注释,文件上传,路径遍历

    Web应用防火墙

    统一拦截请求,过滤恶意参数,自动消毒,添加token
    ModSecurity:处理引擎和攻击规则分离的架构

    安全漏洞扫描

    信息加密

    单项散列:md5,sha 通常要加盐
    对称加密:DES,RC 加解密使用相同秘钥
    非对称加密:RSA 用于数据安全传输,数字签名等

    秘钥管理

    秘钥和算法放独立服务器 或 加解密算法在应用系统,秘钥放独立服务器

    信息过滤和反垃圾

    文本匹配:正则表达式,Trie算法,多级hash表
    机器学习:贝叶斯分类算法
    黑名单:hash,布隆过滤器(节约空间,但可能有误判)

    电商风险控制

    风险:账户(盗用,恶意注册),不良买家,不良卖家,交易(盗刷,套现)
    风控:规则引擎(业务规则和规则处理逻辑分离),统计模型(有预测性)

    案例

    淘宝网

    初期LAMP, 应用服务器上分层部署apache+php,mysql主从读写分离
    换用java,自建mvc框架(而不是structs或hibernate),orm框架选择iBatis,数据库为oracle
    应用服务器上为webLogic+Webx+EJB+iBatis,之后放弃EJB改用spring,用免费jboss代替weblogic

    维基百科

    资源利用率高,性能优化好 只有百余台服务器,数十名技术人员
    LAMP,全免费

    主要组成部分

    GeoDNS:BIND增加版,将域名解析到离用户最近的服务器
    LVS:基于linux的开源负载均衡服务器
    Squid:基于linux的开源反向代理服务器
    Lighttpd:开源应用服务器,比Apache更轻量和快速,适合作为图片服务器
    php:免费的web应用开发语言,最流行的网站建站语言
    memcached:无中心高性能的开源分布式缓存系统
    Lucene:java开发的开源全文搜索引擎
    Mysql:开源的关系数据库管理系统

    性能优化

    前端:CDN,Squid缓存
    PHP服务器:使用最好的服务器,apc缓存,图片处理和转换,php的strtr函数替换
    后端:
    多级缓存:热点缓存在内存中;缓存内容直接可用,减少获取后解析代价;memcached代替数据库持久化连接
    数据库:增加服务器内存;牺牲持久可靠性保证性能,如使用raid0,数据库一致性设置在较低水平;主库宕机时关闭写服务

    Doris

    海量分布式kv存储系统,高可用可伸缩的KV存储集群

    架构

    应用服务器集群从管理中心服务器集群获取存储服务器集群配置,然后访问存储服务器。管理中心对存储服务器进行健康心跳检测和故障扩容处理。

    高可用解决方案

    正常情况:写的时候写入全部服务器,读的时候选择一台
    瞬时故障:应用服务器首先重试,还是失败就请求管理中心仲裁
    临时故障:故障服务器不提供服务,写入时先写入临时服务器,恢复后从临时服务器迁入故障期间写的数据
    永久故障:从正常服务器复制数据,而不是从临时服务器迁移

    秒杀

    应对策略

    秒杀系统独立部署:防止高并发拖垮整个网站
    秒杀页面静态化:请求不需要经过应用服务器和数据库
    租借秒杀活动带宽:秒杀新增的带宽,CDN的带宽
    动态生成随机下单页面url:防止用户直接访问下单页url

    架构设计

    控制提交按钮点亮:每次刷新时,更新js文件
    控制订单数:单台先做一次校验,控制数量,提交时候再次验证

    故障案例分析

    日志:level设的太低,吃光硬盘
    高并发访问数据库:首页这样高频访问页面最好是静态的,不应该直接访问DB,数据从缓存获取
    高并发下锁:锁的使用要谨慎
    缓存故障:当缓存全部关闭时,DB吃不消立刻挂掉
    应用启动不同步:先启动php(或java)服务器,然后启动网络服务器(nginx或Apache)
    大文件读写独占磁盘:大小文件分开部署
    滥用生成环境:生产环境不能随便压力测试
    流程不规范:代码提交前diff和cr
    不好的编程习惯:对空对象的处理

    架构师

    领导艺术

    关注人而不是产品。一群优秀人的做事一定会成功。所以领导真谛就是寻找一个值得共同奋斗的目标,营造大家能最大发挥自身价值的氛围。
    发掘人的优秀比发掘优秀的人有意义。是事情成就了人,而不是人成就了事。
    保持对目标蓝图的关注。蓝图应该简单形象,表述清楚。
    共同参与架构,学会妥协,成就他人

    架构师职场攻略

    发现问题,寻找突破-》提出问题,寻找支持-》解决问题,达成绩效
    提问题tip:1.我的问题-》我们的问题 2.给上司封闭式问题, 给下属开放式问题 3.对事不对人 4.用别人能接受的方式

    架构师分类

    产品架构师:具体产品的技术架构 产品业务规划确定后,开始产品架构设计;和运营确定pv,用户数,商品数等产品运营目标,发展规划;和PM确定功能,模块等;和项目经理确定排期和开发资源。整体架构设计,参与项目开发。
    基础服务架构师:平台架构师,负责开发基础框架,公共组件,通用服务等平台类产品。
    基础设施架构师:DBA,op等

    大型网站架构技术

    网站层次:前端-》应用层-》服务层-》存储层-》后台,垂直的安全和数据采集及监控,最低端是数据中心机房

    前端

    浏览器优化:优化响应页面,加快页面加载和显示,常用有页面缓存,合并http减少请求,使用页面压缩等
    CDN:内容分发网络,部署在运营商机房,把静态页面分发到离用户最近的CDN服务器
    动静分离,静态资源独立部署
    图片服务:独立部署集群,独立域名
    反向代理:页面缓存
    DNS:DNS负载均衡

    应用层

    合适的开发框架
    页面渲染
    负载均衡
    Session管理:Session服务器
    动态页面静态化
    业务拆分
    虚拟化服务器

    服务层

    分布式消息:消息队列
    分布式服务:SOA
    分布式缓存
    分布式配置:配置动态推送,无重启生效

    存储层

    分布式文件
    关系数据库
    NOSQL数据库
    数据同步

    后台

    搜索引擎
    数据仓库:根据离线数据,提供数据分析和数据挖掘
    推荐系统

    数据采集和监控

    浏览器数据采集:嵌入JS脚本
    服务器业务数据采集:一种是服务端日志,一种是业务数据
    服务器性能数据采集:系统负载,内存使用率,网卡流量等
    系统监控:数据可视化,自动化运维
    系统报警:邮件,短信,语音电话

    安全

    web攻击:xss,sql注入
    数据保护

    数据中心机房

    机房架构:能耗严重
    机柜架构
    服务器架构:定制服务器

    Web开发技术发展历程

    最初是cgi(通用网关技术),脚本模式,
    浏览器发请求给web服务器,web服务器请求cgi程序,cgi程序解析http请求,处理业务逻辑,构造输出信息,返回给web服务器。web服务器进行必要的http响应信息构造后,返回给http响应给浏览器。
    因为cgi擅长处理请求信息,服务器页面擅长构造响应页面,两者结合起来就是MVC模式。
    控制器接受所有http请求,根据请求分发给不同模型对象处理,再根据处理结构选择构造视图,得到最终响应信息。
    使用mvc让模型和视图分离,为分层架构奠定了基础。

    相关文章

      网友评论

          本文标题:《大型网站技术架构》读书笔记

          本文链接:https://www.haomeiwen.com/subject/fuivittx.html