读书时间：
2017年
创新的业务发展模式对网站架构逐步提出更高的要求，才使得创新的网站架构得以发展成熟。是业务成就了技术，是事业成就了人，而不是相反。所以网站架构师应该对自己技术成绩的网站事业心存感恩，并努力提高技术回馈业务，才能在快速发展的互联网领域保持持续的进步。、
网站架构设计误区：
1、一味追随大公司的解决方案
2、为了技术而技术
3、企图用技术解决所有问题
技术是用来解决业务问题的， 而业务问题，也可以通过业务的手段去解决。
我们的现实生活中充斥着几乎千篇一律的人生架构模式：读重点学校，选热门专业，进稳定高收入的政府部门和企业，找门当户对的配偶，生一个孩子继续这个模式………… 但是人生不同于软件，精彩的人生绝不会来自于复制。
大型网站架构演化发展历程
单机
LAMP（linux、apache、mysql、php）
应用服务和数据服务分离
应用服务需要更强的cpu
数据库服务需要快速磁盘检索和数据缓存，需要更快的硬盘
文件服务器需要大硬盘
使用缓存改善网站性能
- 80%的业务访问集中在20%的数据上。 如何缓存一小部分数据提高访问速度
使用应用集群改善网站并发性能
- 通过负载均衡服务器，将访问请求分发到机器中
数据库读写分离
- 读写分离
使用cdn和反向代理加速网站响应
使用分布式文件系统和分布式数据库系统
分库分表
业务分库
使用NOSQL和搜索引擎
业务拆分
- 分而治之将业务分成不同的产品线
分布式服务
重新聚合不同产品线相同功能的服务，独立部署提供共用业务服务
分布式服务调用共用业务服务完成具体业务
大型网站架构演化的价值观
网站的价值在于它能为客户提供什么价值，在于网站能做什么，而不在于它是怎么做的，所以在网站还是很小的时候就去追求网站的架构是舍本逐末，得不偿失。小型网站最需要做的就是为用户提供好的服务来创造价值，得到用户的认可，活下去，野蛮生长。
大型网站架构技术的核心价值不是从无到有搭建一个大型网站，而是能够伴随小型网站业务的逐步发展，慢慢地演化成一个大型网站。在这个漫长地技术演化过程中，不需要放弃什么，不需要推翻什么，不需要剧烈的革命，就那么润物细无声地把一个只有一台服务器，几百个用户的小网站演化成一个几十万台服务器，数十亿用户的大网站。
模式
为了解决大型网站面临的高并发访问、海量数据处理、高可靠运行等一系列问题与挑战，大型互联网公司再实践中提出了许多解决方案。
分层
将系统在横向维度切分为几个部分，每个部分负责一部分相对比较单一的职责。
应用层：负责具体业务和视图展示
服务层：为应用层提供服务支持，比如用户管理服务、购物车服务
数据层：提供数据存储访问服务，如数据库、缓存、文件等
分割
将系统在纵向方面对软件进行切分。
比如在应用层，将不同业务进行分割，将购物、论坛、搜索广告分割成不同的应用，由独立团队负责，部署在不同的服务器上；
同样在服务层也可以按需进行分割
分布式
对于大型网站，分层和分割的一个主要目的就是为了切分后的模块便于分布式部署，即将不同的模块部署在不同的服务器。
分布式在解决网站高并发问题的同时也带来了其他问题：
分布式意味着服务调用必须通过网络，这可能对性能造成比较严重的影响
服务器越多，服务器宕机的概率也就越大，一台服务异常导致的服务不可用可能会导致许多应用不可访问
数据在分布式的环境中保持一致性也非常困难，分布式事务也难以保证
分布式还导致网站依赖错综复杂，开发管理维护困难。
常用的分布式方案有以下几种：
分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算
集群
多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
所以在网站应用中，即使是访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小的集群，目的就是提供系统的可用性
缓存
CDN
反向代理
本地缓存
分布式缓存
异步
优点：
提供系统可用性
加快网站响应速度
消除并发访问高峰
缺点：
处理业务可能会对用户体验、业务流程造成影响，需要产品设计方面的支持。
冗余
网站需要7*24连续运行，但是服务器随时可能出现故障，就需要一定程度的服务器冗余运行，数据冗余备份。
数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实现同步实现热备份。
为了抵御地震、海啸等不可抗力，某些大型网站会对数据中心进行备份，部署灾备数据中心。
自动化
devops运维管理类似
自动化管理、测试、发布、监控、报警、转移等等
安全
通过密码和手机校验码进行身份认证
登陆、交易等操作需要对网络通信进行加密
为了防止机器人程序滥用网络资源攻击网站，网站使用验证码进行识别
常见的xss攻击、sql注入，进行编码转换等相应处理
对于垃圾信息、敏感信息进行过滤
对于交易等重要操作根据交易模式和交易信息进行风险控制
大型网站核心架构要素
性能
常用系统操作响应时间
| 操作 | 响应时间 |
|---|---|
| 数据中查询一条记录（有索引） | 十几毫秒 |
| 机械硬盘一次寻址定位 | 4毫秒 |
| 从机械硬盘顺序读取1M数据 | 2毫秒 |
| 从SSD顺序读取1M数据 | 0.3毫秒 |
| 从redis读取一个数据 | 0.5毫秒 |
| 从内存读取1M数据 | 十几微秒 |
| 网络传输2KB数据 | 1微秒 |
测试指标
响应时间
并发数
吞吐量
性能计数器
测试方法
性能测试
负载测试
压力测试
稳定性测试
优化策略
性能分析 ：检查请求处理得各个环节得日志，分析哪个环节响应时间不合理、超出预期；然后检查监控数据，分析影响性能得主要因素是内存、磁盘、网络还是CPU，是代码问题还是架构设计不合理，或者系统资源确实不足。
性能优化
web前端性能优化
减少http请求
使用浏览器缓存
启用压缩
CSS放上面，js放下面
减少cookie传输
cdn 加速
反向代理
应用服务器性能优化
分布式缓存: 优先考虑使用缓存优化性能
数据不一致与脏读
缓存可用性
缓存预热
缓存穿透
异步操作
使用集群
代码优化
多线程
资源复用
数据结构：原始字符串—>md5—>hashcode ,散列效果好
垃圾回收
存储性能优化
机械硬盘or固态硬盘：机械硬盘特点快速顺序读写、慢速随机读写。
B+树 vs LSM 树
RAID VS HDFS
总结
性能优化的最终目的就是改善用户的体验，使他们感觉网站很快。离开这个目的，追求技术上的所谓高性能，是舍本逐末。 而用户体验的快或是慢，可以通过技术手段改善，也可以通过优化交互体验改善。
即使再技术层面，性能优化也需要全面考虑，综合权衡：性能提示一倍，但服务器数量也增加了一倍；或者响应时间缩短，同时数据一致性也下降，这样的优化是否可以接受？
技术是为业务服务的，离开了业务发展的支持和驱动，技术走不远，甚至还会迷路。
可用性
负载均衡
集群session管理
高可用服务
分级管理
超时设置
异步调用
服务降级
幂等性设计
高可用数据
CAP 原理
数据备份
失效转移
软件质量保证
无影响用户发布方式
自动化测试
预发布验证
代码控制
自动化发布
灰度发布
网站运行监控
监控数据采集
用户行为日志采集
服务器性能监控
运行数据报告
监控管理
系统报警
失效转移
自动优雅降级
总结
1 | 工程师对架构做了许多优化、对代码做了很多重构，对性能、扩展性、伸缩性做了很多改善，但别人未必能直观得感受到，也许你地直接领导都不知道你做的这些意义何在。但如果你负责的产品出了重大故障，CEO都会知道你的名字。 |
伸缩性
应用服务器的集群伸缩
http 重定向负载均衡
DNS域名解析负载均衡（优势基于地理位置的域名解析）
反向代理负载均衡
ip负载均衡
数据链接层负载均衡（三角传输）
分布式缓存集群的伸缩
- 一致性hash算法
数据存储服务器的伸缩
关系型数据库集群
amoeba
cobar
NOSQL
总结
1 | 遇到问题，分析问题，最后总能解决问题。许多问题只是看起来一样，具体问题总是要具体对待的，没有银弹，没有救世主。 |
扩展性
降低系统耦合度，构建可扩展的网站架构。
利用分布式消息队列降低系统耦合性
可以复杂用mq，也可以简单用mysql
- 微服务
大型网站分布式服务的需求和特点
服务注册和发现
负载均衡
失效转移
高效的远程调用
整合异构系统
对应用少侵入
版本管理
实时监控
总结
1 | 马克思的劳动价值理论告诉我们，产品的内在价值在于劳动的时间，劳动的时间不在于个体付出的劳动时间，而在于行业一般劳动时间，资本家只会为行业一般劳动时间买单，如果你的效率低于行业一般劳动时间，对不起，请自愿加班。反之，如果你有一个更有效率的架构，可以更加快速地开发出产品，你至少在这个全行业都加班的领域，你能够按时下班，陪陪家人，看看星星。 |
安全性
攻与防
XSS攻击 —> 消毒、httponly
注入攻击 –> 消毒、参数绑定
CSRF攻击–> 表单token、验证码、referer check
其他漏洞：error code、html注释、文件上传、路径遍历
应用防火墙
- 开源的 modsecurity
安全漏洞扫描
信息过滤与反垃圾
文本匹配： trie算法、降噪预处理
分类算法：贝叶斯算法
黑名单：布隆过滤器
风控
规则引擎
统计模型
总结
没有绝对的安全。网站的相对安全是通过提高攻击门槛达到的。让攻击者为了获得有限的利益必须付出更大的代价，致使得不偿失，望而却步。
