互联网架构的演进方向

本文的思维导图如下：

本文主要讲解互联网架构随着用户量的增大是如何演进的。

1. 架构的概念

该系统被定义为由若干相互关联的个体构成的一个集合体，在一定规则下运行，并能够执行那些单一实体无法独立完成的任务。

子系统：由一组有联系的个体构成...通常会成为...体系中的一个组成部分

模块：从逻辑角度对系统进行拆分后形成的单元即为系统功能模块，在这一过程中划分出的功能单元即为模块。其划分的目的在于实现系统的功能分离。

模块：基于物理结构对系统进行拆解所得出的单位体。其主要目的旨在实现模块间的高效复用。

框架是指遵循业界标准或满足特定基本任务需求的软件组件规范体系结构。例如MVC被视为一种常见的开发规范而Spring MVC开发框架则是一种能够支撑MVC规范并满足其底层功能需求的软件产品

软件架构 ：包括软件系统的核心组成部分及其创建准则和描述方式。
首先，“系统由一组相互关联的组件、子系统或模块构成”，这些是构成系统的最基本单位；架构必须明确系统包含哪些具体单元。
其次，在系统中各个单元需要按照某种规范进行操作，“遵循特定的运行规则”。

2. 架构的目的

架构设计的主要目的是为了解决软件复杂度带来的问题

3. 架构的复杂度来源

3.1 性能

单台计算机内部的高性能带来了内部复杂度的增加；计算机内部复杂度最关键的地方就是操作系统；进程与线程是操作系统与系统性能之间最为密切相关的元素；多进程与多线程的并发问题涉及同步机制与通信机制的设计与实现。

多台计算机集群因其带来的复杂性而被采用。
如何将业务任务合理分配到各台机器上？同时需要设计适合的分配算法。
如何对原有的统一业务系统进行分解？将其划分成若干小而简单的子系统，并由这些子系统共同完成整体功能。

衡量指标
响应时间
TPS
QPS
系统性能计数器

3.2 可用性

可用性：系统无中断提供其功能的能力

评估高可用对系统复杂度的影响

系统为了保证存储系统的高可用性而承担的数据复杂度。
数据同步操作是通过将被传输到另一台机器的数据经由线路完成传输来实现的。
在多节点系统中各节点所存储的数据值应保持一致状态，并对外保持一致状态。

高效可靠的高可用状态决策涉及的复杂度较高。独裁式的特征是由单一主体进行决策。协商式的采用是一种基于双方互动的信息交流机制，并依据既定规则作出决定的方式。民主式的决策流程则是通过多数投票的形式来达成一致意见的状态方案。

衡量指标
可用性指标：比如4个9

3.3 扩展性

可扩展性是指系统为了适应未来需求变化而具备的一种动态扩展能力。每当新增需求时, 该系统只需无需或仅需进行少量改动即可实现功能支持, 并避免了对整体系统的重构或重建工作。

评估变化所引发的复杂性

应对变化带来的复杂度
剥离变化层和稳定层
提炼出抽象层和实现层

衡量指标
对现有产品透明无影响
不需要改动或很少改动

3.4 可伸缩性

可扩展性：通过持续添加节点来有效应对日益增长的用户并发访问压力，并平衡提升数据存储容量。

计算可伸缩带来的复杂度
任务分配
状态感知

存储可伸缩带来的复杂度
数据同步
数据一致性
自动扩容

评估指标
是否可以使用多台服务器构建集群
是否容易地扩展或缩减现有集群中的服务器数量

3.5 安全

安全：保护系统不受恶意访问和攻击，保护系统重要数据不被窃取

功能层面的安全性所导致的复杂度

架构上的安全带来了实施复杂度的提升。在流量清洗方面主要针对的是恶意流量攻击和爬虫抓取网站信息两大类情况。而防刷策略则是指黑产通过违反业务规则疯狂获取利益的行为，在这种情况下会大量采集和处理数据以达到盈利目的

衡量指标
是否存在针对现有和潜在的多种攻击与窃密手段的有效应对策略

3.6 成本

成本：通过减少服务器成本或人力成本达成低成本的目标

减少服务器成本带来的复杂度
架构设计的附加约束
单机性能优化

减少人力成本带来的复杂度
架构设计的附加约束
项目范围控制

衡量指标
更少服务器提供同样的系统能力
更少的人力完成任务

3.7 规模

规模：“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。

功能越来越多带来的复杂度
系统复杂度指数级上升
维护越来越困难

数据越来越多带来的复杂度
查询效率下降
资源不足（计算，内存，硬盘，网络）

衡量标准
功能对现有系统的开发效率影响越来越大
数据对现有系统的运行效率影响显著提升

3.8 可运维性

可扩展性：具备融入现有运维体系的能力，并且运维团队在相关领域拥有成熟的运维经验或具备相关的技术储备能力。

现有运维体系带来的复杂度
架构设计的附加约束

运维相关技术积累带来的系统复杂度

运维相关技术积累带来的系统复杂度

衡量指标
是否容易融入现有运维体系
引入新技术风险是否可控

4. 架构的模式

应对性能的架构模式
集群
缓存
读写分离
分库分表
异步
并发化

应对可用性的架构模式
冗余
集群
限流
降级
熔断
异地多活

应对扩展性的架构模式
分层
拆分
服务化
微服务
微内核

应对伸缩性的架构模式
集群
拆分

应对安全的架构模式
安全
限流

应对规模的架构模式
拆分
异步
分库分表
数据分区

应对可运维性的架构模式
自动化（发布，测试，监控）

5. 架构的演进方向

阶段	用户规模	业务阶段	技术影响
婴儿期	0~1万	初创期	用户规模对性能和可用性都没什么压力，单台机器就可以满足
幼儿期	1万~10万	初创期	用户规模对性能和可用性已经有一点压力了， 单台机器（服务器，数据库）可能已经撑不住了， 需要开始考虑拆分机器，但这个时间拆分比较简单， 因为机器数量不会太多
少年期	10万~100万	发展期	用户规模对性能和可用性已经有较大压力了，除了拆分机器， 已经开始需要将原来大一统的业拆分为更多子业务了
青年期	100万~1000万	竞争期	用户规模对性能和可用性已经有很大压力了，集群、多机房等手段 开始用上了。
壮年期	1000万~1亿	竞争期&成熟期	用户规模对性能和可用性已经有非常大的压力了， 可能原有的架构和方案已经无法扩展下去，需要推倒重来。
巨人期	1亿+	成熟期	和壮年期类似

5.1 阶段-婴儿期

用户规模	0~1万
业务阶段	初创期
技术影响	对性能和可用性没什么压力
架构模式	分层

5.2 阶段-幼儿期

用户规模	1~10万
业务阶段	初创期
技术影响	对性能和可用性有一点压力
架构模式	分层、拆分、集群、自动化

5.3 阶段-少年期

用户规模	10~100万
业务阶段	发展期
技术影响	对性能和可用性 有较大压力
架构模式	分层、拆分 集群、自动化 读写分离、缓存

5.4 阶段-青年期

用户规模	100~1000万
业务阶段	竞争期
技术影响	对性能和可用性 有很大压力
架构模式	分层、拆分、集群 自动化、读写分离 缓存、分库分表 服务化、异步 多机房、限流 降级、熔断

5.5 阶段-壮年期

用户规模	1000万~1亿
业务阶段	竞争期&成熟期
技术影响	对性能和可用性有非常大压力
架构模式	分层、拆分、集群、自动化、读写分离、缓存、分库分表 服务化、多机房、限流、降级、熔断、异地多活

5.6 阶段-巨人期

用户规模	1亿+
业务阶段	成熟期
技术影响	对性能和可用性 有非常大压力
架构模式	能够用的模式都基本用上

和壮年期类似，也是每个企业和技术人员追求的阶段

6. 总结

遵循合理原则

简洁原则
简单性优先于复杂性
不论是结构上的复杂性还是逻辑上的复杂性都可能导致一系列问题因此在架构设计中在满足需求的前提下选择简洁明了的方案通常会更加高效

演化原则
演化优于一步到位
架构设计必须与当前业务需求相匹配，在实际应用过程中持续积累优化经验。通过逐步优化现有架构以消除不足之处，并及时修正发现的问题，在不断筛选中精简不必要的设计元素以保持简洁高效。
遇到业务调整时，架构需进行升级、重构或彻底重写以适应新的应用场景需求。尽管代码可能需要重构甚至重写但有价值的经验教训技术和逻辑可以在新架构中得到延续和应用。

7. 附录

参考资料

《架构入门必修课》
《巨无霸网站架构核心技术解析及案例研究》
《Java中间件应用实战技巧与最佳实践》
《高并发系统架构核心技术解析与优化方案》
《架构师必读经典著作》
《十年淘宝技术演变之道——核心技术和商业机密揭秘》
《双11大促背后的技术演进分析——从技术到商业的深度洞察》
《软件系统设计思维导引》

参考性能指标

Nginx的负载均衡性能达到约30,000；
MC系统的读取能力约为5, ；
Redis服务器端的读取能力约为6, ；
Kafka平台的能力已达到上百万级别；
Zookeeper节点的吞吐量超过2, ；
HTTP服务器端请求处理能力大约在2万个/秒附近；