本文的思维导图如下：
本文主要讲解互联网架构随着用户量的增大是如何演进的。
1. 架构的概念系统：是指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。
子系统：由一群有关联的个体所组成的系统，多半会是更大系统中的一部分
模块：从逻辑的角度来拆分系统后，得到的单元就是模块，划分模块的主要目的是职责分离
组件：从物理的角度来拆分系统后，得到的单元就是组件，划分组件的主要目的是单元复用
框架：是指为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。比如MVC就是一种常见的开发规范，而Spring MVC开发框架则是提供MVC规范的基础功能的软件产品
软件架构：指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。
首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。
其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。
架构设计的主要目的是为了解决软件复杂度带来的问题
单台计算机内部为了高性能带来的复杂度
计算机内部复杂度最关键的地方就是操作系统
操作系统和性能最相关的就是进程和线程
多进程和多线程并发问题（同步、通信）
多台计算机集群为了高性能带来的复杂度
任务分配：每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行；分配算法
任务分解：把原来大一统但复杂的业务系统，拆分成小而简单但需要多个子系统配合的业务系统；拆分方式
衡量指标
响应时间
TPS
QPS
系统性能计数器
3.2 可用性
可用性：系统无中断提供其功能的能力
计算高可用带来的复杂度
任务分配
任务分配器和业务服务器的连接管理
存储高可用带来的复杂度
数据同步：将数据从一台机器搬到到另一台机器，需要经过线路进行传输
数据一致性：多个节点中数据的值是一致的，至少对外是一致的
高可用状态决策带来的复杂度
独裁式：存在一个独立的决策主体
协商式：两个独立的个体通过交流信息，然后根据规则进行决策
民主式：多个独立的个体通过投票的方式来进行状态决策
衡量指标
可用性指标：比如4个9
扩展性：系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需少量修改就可以支持，无须整个系统重构或者重建
预测变化带来的复杂度
不能每个设计点都考虑可扩展性
不能完全不考虑可扩展性
所有的预测都存在出错的可能性
应对变化带来的复杂度
剥离变化层和稳定层
提炼出抽象层和实现层
衡量指标
对现有产品透明无影响
不需要改动或很少改动
可伸缩性：通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求
计算可伸缩带来的复杂度
任务分配
状态感知
存储可伸缩带来的复杂度
数据同步
数据一致性
自动扩容
衡量指标
是否可以用多台服务器构成集群
是否容易向集群添加新的服务器或减少现有的服务器
安全：保护系统不受恶意访问和攻击，保护系统重要数据不被窃取
功能上的安全带来的复杂度
XSS攻击：恶意脚本的链接或提交恶意脚本的请求
CSRF攻击：利用cookie或session盗取用户身份，进行非法操作
SQL注入：提交注入恶意SQL命令的请求
密码破解：彩虹表，低安全性密码
架构上的安全带来的复杂度
流量清洗：恶意流量攻击或爬虫抓取网站信息
防刷策略：黑产利用业务规则，疯狂刷有利可图的数据（比如积分，红包）
衡量指标
针对现存或潜在的各种攻击与窃密手段，是否有可靠的应对策略
成本：通过减少服务器成本或人力成本达成低成本的目标
减少服务器成本带来的复杂度
架构设计的附加约束
单机性能优化
减少人力成本带来的复杂度
架构设计的附加约束
项目范围控制
衡量指标
更少服务器提供同样的系统能力
更少的人力完成任务
规模：“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。
功能越来越多带来的复杂度
系统复杂度指数级上升
维护越来越困难
数据越来越多带来的复杂度
查询效率下降
资源不足（计算，内存，硬盘，网络）
衡量指标
功能越来越多对现有系统和开发效率的影响
数据越来越多对现有系统的影响
3.8 可运维性
可运维性：能够融入现有的运维体系，运维团队在相关方面有成熟的的运维经验或运维团队有相关的技术储备能力
现有运维体系带来的复杂度
架构设计的附加约束
运维技术储备带来的复杂度
架构设计的附加约束
引入新技术的风险控制
衡量指标
是否容易融入现有运维体系
引入新技术风险是否可控
应对性能的架构模式
集群
缓存
读写分离
分库分表
异步
并发化
应对可用性的架构模式
冗余
集群
限流
降级
熔断
异地多活
应对扩展性的架构模式
分层
拆分
服务化
微服务
微内核
应对伸缩性的架构模式
集群
拆分
应对安全的架构模式
安全
限流
应对规模的架构模式
拆分
异步
分库分表
数据分区
应对可运维性的架构模式
自动化（发布，测试，监控）
| 阶段 | 用户规模 | 业务阶段 | 技术影响 |
| 婴儿期 | 0~1万 | 初创期 | 用户规模对性能和可用性都没什么压力，单台机器就可以满足 |
| 幼儿期 | 1万~10万 | 初创期 | 用户规模对性能和可用性已经有一点压力了， 单台机器（服务器，数据库）可能已经撑不住了， 需要开始考虑拆分机器，但这个时间拆分比较简单， 因为机器数量不会太多 |
| 少年期 | 10万~100万 | 发展期 | 用户规模对性能和可用性已经有较大压力了，除了拆分机器， 已经开始需要将原来大一统的业拆分为更多子业务了 |
| 青年期 | 100万~1000万 | 竞争期 | 用户规模对性能和可用性已经有很大压力了，集群、多机房等手段 开始用上了。 |
| 壮年期 | 1000万~1亿 | 竞争期&成熟期 | 用户规模对性能和可用性已经有非常大的压力了， 可能原有的架构和方案已经无法扩展下去，需要推倒重来。 |
| 巨人期 | 1亿+ | 成熟期 | 和壮年期类似 |
| 用户规模 | 0~1万 |
| 业务阶段 | 初创期 |
| 技术影响 | 对性能和可用性没什么压力 |
| 架构模式 | 分层 |
| 用户规模 | 1~10万 |
| 业务阶段 | 初创期 |
| 技术影响 | 对性能和可用性有一点压力 |
| 架构模式 | 分层、拆分、集群、自动化 |
| 用户规模 | 10~100万 |
| 业务阶段 | 发展期 |
| 技术影响 | 对性能和可用性 有较大压力 |
| 架构模式 | 分层、拆分 集群、自动化 读写分离、缓存 |
| 用户规模 | 100~1000万 |
| 业务阶段 | 竞争期 |
| 技术影响 | 对性能和可用性 有很大压力 |
| 架构模式 | 分层、拆分、集群 自动化、读写分离 缓存、分库分表 服务化、异步 多机房、限流 降级、熔断 |
| 用户规模 | 1000万~1亿 |
| 业务阶段 | 竞争期&成熟期 |
| 技术影响 | 对性能和可用性有非常大压力 |
| 架构模式 | 分层、拆分、集群、自动化、读写分离、缓存、分库分表 服务化、多机房、限流、降级、熔断、异地多活 |
| 用户规模 | 1亿+ |
| 业务阶段 | 成熟期 |
| 技术影响 | 对性能和可用性 有非常大压力 |
| 架构模式 | 能够用的模式都基本用上 |
和壮年期类似，也是每个企业和技术人员追求的阶段
6. 总结合适原则
合适优于业界领先
真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥最大功效，并且能够快速落地
简单原则
简单优于复杂
无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案
演化原则
演化优于一步到位
首先，设计出来的架构要满足当时的业务需求
其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
最后，当业务发生变化时，架构要扩展、重构、甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等却可以在新架构中延续。
参考资料
《从零开始学架构》
《大型网站技术架构核心原理与案例分析》
《大型网站系统与Java中间件实践》
《亿级流量网站架构核心技术》
《架构真经》
《淘宝技术这十年》
《尽在双11——阿里巴巴技术演进与超越》
《软件架构设计》
参考性能指标
nginx负载均衡性能是3万左右
mc的读取性能5万左右
redis的读取性能6万左右
kafka号称百万级
zookeeper写入读取2万以上
http请求访问大概在2万左右
