037.大型网站技术架构

[b]# 037.大型网站技术架构[/b]

《大型网站技术架构》核心原理与案例分析。
李智慧，电子工业出版社，ISBN-9787121212000

@史荣久 / 2015-04-08 / CC-BY-SA-3.0

[b]## 【前11张】 页码之前[/b]

【好评来袭】「最接地气」，「面试官们怎么办？」，
「实用性和前瞻性」，「互联网基因」，「架构演进」，
「案例检验」，「举重若轻」。

【推荐序一】传统应用为，复杂业务逻辑，功能性，人月问题。
大型网站为，海量访问和数据，非功能性，技术难题。

【推荐序二】是设计出来的？演化出来的？考虑哪些因素？
面临哪些问题，哪些挑战？案例分析秒杀的瞬间高并发。

【自序】2011年末，360buy "Service is too busy"，
「请信息部的同事喝茶」，配图一个杯具，一把刀子。
2012年初，12306，干脆利落，趴窝了起不来。
机械制图（正视，侧视，俯视），架构师「4+1视图」

【致谢】朋友，兄弟，伙伴，贵人，高人，家人。

[b]## 1.大型网站架构演进[/b]

【P2】「全球有近一半的人口使用互联网」，
2014年6月，全球网民30亿 internetworldstats.com

【P2】(一边...一边...)x3，有气势的排比。

【C1.1】①高并发，PV过亿。②高可用，7x24。③海量数据，TB/PB。
④网络复杂，南北，中美。⑤安全性，密码泄露。
⑥需求变更快，发布频繁，每周，每天。⑦渐进式发展，试错。

【C1.2】演进历程：①1台（单机）。②3台（应用+文件+数据）。
③应用层缓存，二八定律。④应用层集群，可伸缩。
⑤数据层读写分离，主从。⑥反向代理，CDN。⑦分布式FS和DB。
⑧NoSQL和搜索引擎。⑨业务拆分，产品线。⑩分布式，服务化。

【C1.3】LAMP，中小型网站绰绰有余。

【C1.3.1】架构核心是随网站所需灵活应对。

【C1.3.2】驱动力量是网站的业务发展。

【C1.4】设计误区：①光环效应，某宝这么搞的。②为了技术而技术。
③奢望技术搞定一切，如业务。

[b]## 2.大型网站架构模式[/b]

【P16】人生架构模式，很精彩的比喻。

【C2.1.1】分层，横切，单一职责。面向接口，服务化。
禁止跨层调用，逆向调用。（说明没划好）

【C2.1.2】分割，纵切，高内聚低耦合，处理单元，模块化。

【区别】分层vs分割：逻辑vs业务，TR-TD。

【C2.1.3】分布式：①应用和服务。②静态资源（js，img）。
③数据和存储。④分布式计算，分布式配置。

【C2.1.4】集群：功能相同+负载均衡。

【区别】分布式vs集群：分布vs集中，全局vs局部。

【C2.1.5】缓存：CDN，反向代理，本地/分布式缓存。
缓存的前提：热度不均，时效不等。（频繁+成本）

【扩展】搜`缓存算法`，知识很多：
命中，Miss，存储（空间+时间），索引，失效，
算法（LFU，LRU，LRU2，2Q，ARC，MRU，Time-based）

【C2.1.6】异步：生产者消费者模式。①可用性高。②响应快。③错峰处理。

【C2.1.7】冗余：冷备，热备，全背，增量背。

【C2.1.8】自动化：发布（代码，测试，部署）。
监控（安全，报警，转移，恢复，降级，均衡）。

【C2.1.9】安全：校验码，验证码，XSS，SQL注入，敏感信息。

【C2.2】微博三层：①基础。②应用。③业务+API。
进化：①同步插粉丝。②异步推线粉丝。③多级缓存。

【C2.3】设计，对问题深刻理解的「微创新」。

[b]## 3.大型网站核心架构要素[/b]

【P26】架构：「最高层次的规划，难以改变的决定」，人生规划也是架构。
关注1+5：功能+（性能，可用，伸缩，扩展，安全）。

【C3.1】性能：浏览器（缓存，页面压缩，减少cookie），静态（CDN），
动态（缓存，异步队列，集群），代码（线程，内存），服务器。
指标（相应时间，TPS）。

【3.2】可用性：99.99%，冗余。

【3.3】伸缩性：集群中增减自适应。App无状态，Cache变路由，SQL分区。

【3.4】扩展性：功能性需求：事件驱动（消息），分布式（服务化）。

【3.5】安全性：恶意访问，攻击，窃密。

[b]## 4.瞬时响应：网站的高性能架构[/b]

【C4】客观指标和主观感受。

【C4.1.1】用户视角：浏览器直观感受。
开发视角：响应，吞吐量，并发能力，稳定性等指标。
运维视角：硬件性能，资源利用率，带宽，服务器，机房。

【C4.1.2】①响应时间（sql十几ms，机械硬盘（寻址4ms，读1M 2ms），内存微妙）。
②并发数（用户>>在线>>并发）。③吞吐量（TPS，TPS，QPS）。④性能计数（System load，进程数，内存，CPU，磁盘，网络）

【C4.1.3】性能测试（预期），负载测试（临界），压力测试（崩溃），稳定性测试。

【C4.1.4】性能测试报告：表格和图表。

【C4.1.5】分析找瓶颈，优化分而治之。

【4.2】前端优化，业务逻辑之前。

【C4.2.1】浏览器优化：减少http请求（合并，js，css，图片）。
浏览器缓存（Cache-Control，Expires，改文件名更新，逐步）。
启用压缩。CSS放最前（优先渲染），JS放最后（延缓执行）。
减少Cookie（静态资源，另设域名，减少Cookie）。

【C4.2.2】CDN 静态资源。

【C4.2.3】反向代理（服务器侧），缓存+安全。

【4.3】应用层优化，缓存，集群，异步。

【4.3.1】第一步考虑缓存。
合理使用：①读写比2:1。②二八热点。③容忍脏读。④失效。⑤预热。⑥穿透。
缓存框架：内存擦车（Memcache）等。

【区别】Memcache和Memcached是有区别，但都指向memcached.org。

【4.3.2】异步：消息队列，削峰平谷。任何能晚做事，都应该晚点做 :D

【4.3.3】集群。

【4.3.4】代码优化：①线程（IO，多核）（线程数=(总时间/非等待时间)x核数）。
②资源复用：单例和池。③数据结构和算法。④垃圾回收（堆H，栈S）。

【4.4】存储优化：机器/SSD。B+Tree/LSM。RAID/HDFS

[b]## 5.万无一失：网站的高可用架构[/b]

【5.1.1】度量：4个9（99.99%）可用，一年最多53分钟不可用。twitter大概2个9。

【5.1.2】量化考核=时间x权重（普通，非核心，核心，严重）

【5.2】高可用的架构：数据和服务冗余，失效转移。

【5.3】高可用的应用：无状态。!Session（复制，hash绑定，Cookie，Session服务）

【5.4】高可用的服务：①分级管理（优先级和隔离）。②超时设置（心跳）。
③异步调用。④服务降级（拒绝低优先级，关闭不重要）。⑤幂等性设计（次数无关）。

【5.5】高可用的数据：CAP（一致，可用，伸缩）（强一致，用户一致，最终一致）。
数据热备（主从，读写）。失效转移（失效确认，访问转移，数据恢复）。

【5.6】高可用网站的软件质量保证：①发布等于宕机，「飞行的飞机换引擎」。
②自动化测试（selenium，casperjs）。
③预发布验证（测试和生产环境差异）。
④代码控制（版本和配置管理）。
⑤自动化发布（周四发布，火车发布模型）。
⑥灰度发布（避免发布回滚，增量发布，AB测试）。

【5.7】网站运行监控：「不允许没有监控的系统上线」

【5.7.1】采集数据：①用户行为日志（服务器+js客户log，storm流计算）。
②服务器性能监控（故障，入侵）。③运行数据报告（缓存命中，响应延时）。

【5.7.2】监控管理：系统报警。失效转移。自动优雅降级。

[b]## 6.永无止境：网站的伸缩性架构[/b]

【C6】伸缩：不改变软硬件设计，仅改变服务器数量来改变服务能力。

【C6.1.1】不同功能物理分离：纵向（先分层），横向（先分业务）。

【C6.1.2】单一功能做集群：垂直升级，水平升级。
（PS：一头拉不动车，找个强壮的拉，再不行才找两头拉）

【C6.2】应用集群的伸缩性设计：HTTP天生无状态。

【C6.2.1】HTTP重定向（302），简单但两次请求一次访问，SEO不好，淘汰了。

【C6.2.2】DNS解析均衡：A记录（地理位置），DNS刷新延迟，控制权在服务商。

【C6.2.3】反向代理：缓存+负载，中转站，会成为瓶颈。

【C6.2.4】IP负载均衡：NAT，内核级，性能高于反向代理（图示的箭头在边缘）。

【C6.2.5】数据链路层负载（广泛使用）：三角传输模式，直接路由方式（DR），LVS。

【C6.2.6】负载均衡算法：轮询（Round Robin），加权轮询，随机，最少连接，源地址Hash。

【C6.3】分布式缓存集群的伸缩性设计：新上线对集群影响最小。

【C6.3.1】memchache：Client（API，路由，集群列表，通讯模块），Cluster。

【C6.3.2】Hash求余，增1台的命中=1/(N+1)。

【C6.3.3】一致Hash：Hash环(2^32，顺时针)，增1台的命中=N/(N+1)。
「计算机的任何问题都可以通过增加一个虚拟层来解决」。
虚拟节点，均摊影响。经验值：1物理对150虚拟。

【C6.4.1】RDBMS集群的伸缩性设计：主写从读，分库分表（Amoeba，Cobar）。
迁移数据，以schema为单位（预见预建）。分布式要避免并分解Join。

【C6.4.1】NoSQL(Not Only SQL)集群的伸缩性设计：HBase（Region）。

【C6.5】伸缩性是架构狮必备。走在业务前面。遇到并解决问题，从来没有救世主。

[b]## 7.随需而变：网站的可扩展架构[/b]

【C7】扩展性（extensibility，开闭原则），伸缩性（scalability，线性资源）

【C7.1】扩展性架构：模块化，低耦合。

【C7.2】消息队列解耦：事件驱动（EDA）（生产消费，发布订阅，ESB，SOA）。

【C7.3】分布式服务：通过接口分解，服务化。

【C7.3.1】WebService（淘汰货）

【C7.3.2】需求特点：负载均衡，失效转移，高效远程通讯，
整合异构系统，对应用最少入侵，版本管理（代码，配置，服务），实时监控。

【C7.3.3】分布式架构：SOA，Dubbo

【C7.4】可扩展的数据结构：NoSQL的ColumnFamily，冗余。

【C7.5】开放，生态：API，协议，安全，审计，路由，流程。

【C7.6】试错，failfast。

[b]## 8.固若金汤：网站的安全架构[/b]

【8.1.1】XSS（Cross Site Script）：危险字符转义。

【8.1.2】注入攻击：SQL注入常见。代码写太烂了 :(

【8.1.3】CSRF：检查（token，验证码，referer）。

【8.1.4】报错太细，HTML注释，文件上传，路径遍历。

【8.1.5】WEB应用防火墙(ModSecurity)

【8.1.6】安全漏洞扫描。

【哎】一个有经验的攻城狮和运营多重要！！

【8.2】加密及密钥：单向散列，对称，非对称（狮友圈内测题有讲）

【8.3】信息过滤与反垃圾：Trie算法，贝叶斯，黑名单。

【8.4】电子商务风险控制：交易安全是底线。

【8.4.1】账户风险（黑，盗，恶意），买家风险（黄牛，询盘），
卖家风险（假，劣），交易风险（盗刷，欺诈，洗钱套现）。

【8.4.2】风控：规则引擎（特征+临界值）。统计模型（机器学习）

【8.5】点到为止，道高一尺魔高一丈。

[b]## 9.淘宝网的架构演化案例分析[/b]

【9.1,9.2】淘宝历程：
2003，3000美金，买来C2C交易软件，对PHP汉化和修改。
2004，模仿eBay，Sun顾问，转java，weblogic，oracle。
此后若干年，拥抱技术，拥抱开源。

【9.3】唯一驱动力，不得已。

【PS】截图不错。能用钱的不用人，能硬件的不软件。

[b]## 10.维基百科的高性能架构设计分析[/b]

【C10】wikipedia.org 2012流量全球第6。

【C10.1】构成：GeoDNS，LVS，Squid，Lighttpd，PHP，Memcache，Lucence，MySQL。

【C10.2.1】前端优化（DNS，CDN，反向代理等），处理80%请求（读操作多）。

【C10.2.2】服务端性能：硬件改善+PHP优化。

【C10.2.3】后端性能优化：缓存Mecached，MySQL牺牲一致性（CAP）

【PS】www.slideshare.net 是个好地方。

[b]## 11.Doris的高可用架构设计分析[/b]

【C11】高可用=服务（可读写）+数据（不丢失）

【PS】Doris最后发布2013-05-21，大阿里的不少开源货不了了之。

【C11.1】宕机，掉线是常态，要热备，要冗余。

【C11.2.1】故障分类：瞬时（秒级，如GC，自愈）。临时（时级，掉线，换件）。
永久（数据丢失）。

【PS】对故障，各有各的运营手册和流程，这里蜻蜓点水。

[b]## 12.网购秒杀系统架构设计[/b]

【C12】秒杀（附加活动，非常态），正常访问的数百上千倍。

【C12.1】技术挑战：①冲击正常业务。②高并发下应用和数据库。
③网络和带宽。④直接下单（爬虫）。

【C12.2】应对策略：①独立部署。②商品页静态化。
③租借活动带宽（CDN）。④动态生成随机下单URL。

【C12.3】架构设计：刷页码，下单。关注点是按钮。
按钮点亮（CDN页码+小JS）。入口过滤，少数下单。

【C12.4】适度公平，娱乐性。

【PS】指引思路，但魔鬼在细节。

[b]## 13.大型网站典型故障案例分析[/b]

【C13】互联网1年=传统3年。牛掰是因经历故障多。

【C13.1】日志写满磁盘：日志Level至少Warn。
（PS：不同的日志框架有不同的性能影响）

【C13.2】高并发SQL：首页访问DB。

【C13.3】高并发锁：synchronized（this/Class）

【C13.4】错关缓存：提高缓存地位，加入手册。

【C13.5】启动顺序：jboss启动太慢，apache开门了。

【C13.6】大文件独占IO：文件按类分服务器。
（PS：数百兆文件怎么来的不清，好像是批处理生成的？）

【C13.7】压力测试生产环境：手册，流程。

【C13.8】内测注掉的代码未打开，发布了：提交看diff和review。

【C13.9】坏习惯，未做null判断。

【C13.10】软件设计的两种风格：「复杂，以使其缺陷没那么明显」
「简单，以使其没有明显缺陷」。

【PS】 以上故障，流程和规范居多，也有素养习惯的。
越发感觉做狮友圈很必要了：制度，手册，细节，周全，攻城狮精神。

[b]## 14.架构师领导艺术[/b]

【C14】PS：这里的架构狮，更像项目经理 :)

【C14.1】关注人而不是产品：
「一群优秀的人做一件他们热爱的事，一定能取得成功」，
自我驱动，胜于管理。

【C14.2】发掘人的优秀：「事情成就了人，而不是人成就了事」，
发掘人的优秀，重于发掘优秀的人。

【C14.3】共享美好蓝图：清楚的（做什么，不做什么，什么目标）。
形象的（什么价值，什么市场，产品什么样）。
简单的（一句话说明白，我们在做什么）。

【C14.4】共同参与架构：PS：思路共讨论，实施分权责。

【C14.5】学会妥协：PS：要知道向什么妥协，妥协什么。

【C14.6】成就他人：成就团队。

[b]## 15.网站架构师职场攻略[/b]

【C15.1】发现问题，寻找突破：「鱼是最后一个看见水的」。

【C15.2】提出问题，寻求支持：做事，做成事的基本套路。
（PS：说事，说ABF方案，多说Yes,but）。

【C15.3】解决问题，达成绩效。绩效 :)

【PS】故事不太虚构，小A同学，运气不错。

[b]## 16.漫话网站架构师[/b]

【C16】架构狮，决定了技术高度和团队能量。

【C16.1】作用划分：设计型（广义的）。救火型（解决灵异现象）。
布道型（技术信仰和主张）。Geek型（高大上）。

【C16.2】效果划分：夏尔巴人（淌雷，攻坚，铺路）。
斯巴达人（技术，方法，信心）。达官贵人（口吐莲花）。

【C16.3】角色划分：产品（项目经理）。
基础服务（平台，框架）。基础设施（运维）。

【C16.4】层面划分：产品功能，非功能，团队管理，产品运营，产品未来。
（PS：涨姿势了，架构狮家族还可以这样）

【C16.5】口碑划分：最好的（不存在）。好的（离不开）。
一般的（重技术+坏脾气）。差的（没实力靠脾气）。
最差的（没事加班）。

[b]## 附录A.大型网站架构技术一览[/b]

【1.前端架构】浏览器优化（快速响应，缓存，压缩，减少请求）。
CDN。动静分离，独立部署。反向代理。DNS。

【2.应用层架构】开发框架（分离关注面，分工协作）。
页面渲染（模版）。负载均衡。Session管理。
动态页面静态化（不太频繁，不需要实时的）。
业务拆分。虚拟化服务器。

【3.服务层架构】分布式x（消息，服务，缓存，配置）

【4.存储层架构】分布式文件。关系数据库。NoSQL。数据同步。

【5.后台架构】搜索引擎。数据仓库。推荐系统。

【6.数据采集与监控】浏览器数据（js）。服务器业务数据（log，统计）。
服务器性能（负载，内存，流量等）。系统监控（图标）。系统报警（阈值）。

【7.安全架构】Web攻击（XSS，SQL注入）。数据保护（敏感加密）。

【8.数据中心】机房架构（电费）。机柜（大小，布线，UPS等）。服务器（按需）。

[b]## 附录B.Web开发技术发展历程[/b]

略。

[b]## 后记[/b]

不要企图设计一个大型网站！（除非12306）。
互联网正在并持续改变世界（尤其移动互联网，物联网，H5）。

[b]## 读后感[/b]

作者文笔很好，但篇幅所限，书的后部分价值密度一般。

「4+1」部分（1-8章），表述清晰，若到此为止甚好。
案例分析（9-13）较浅，不如一些专题的技术博客。
架构师（14-16章），对架构狮（已是或想要）指导不大。

建议阅读方式：对感兴趣的话题，要搜索并深入研究。
4+1部分，关键字搜索，如CAP，XSS，作为专题学习。
案例部分，建议对感兴趣的项目，阅读手册和代码，了解细节。
架构师成长，非鸡汤语录能解决，唯有上战场并活下来。

原文：[url]http://www.trydofor.com/3x/037.isbn-9787121212000.html[/url]