知识点总结

系统架构

互联网系统面临的挑战

• 高并发

• 大流量

• 高可用

• 海量数据

• 用户分布广泛，网络情况复杂

• 安全环境恶劣

• 需求快速变更，发布频繁

• 渐进式发展（好的互联网产品都是运营出来的）



应对高并发挑战的两个技术方向

• 垂直伸缩



通过升级硬件和网络吞吐能力可以实现垂直伸缩。由于不需要改变应用架构，所以通常

被认为是最简单的短期伸缩性方案。



1. 通过使用 RAID（独立冗余磁盘阵列）增加 I/O 吞吐能力。

2. 通过切换到 SSD（固态硬盘）改善 I/O 访问速度。

3. 通过增加内存减少 I/O 操作 。 • 通过升级网络接口或者增加网络接口提高网络吞吐能力。

4. 更新服务器使用更多处理器或者更多超线程。



• 垂直伸缩的缺点（并非一直是线性增加）



1. 达到某个程度后，增加计算能力需要的更多的花费。

2. 垂直伸缩有物理极限。

3. 操作系统的设计或者应用程序自身制约着垂直伸缩最多只能达到某个点。



• 水平伸缩（初期成本高，过了某个节点之后变得更有优势）



水平伸缩是指通过增加服务器提升计算能力的一类架构方法。

水平伸缩被认为是伸缩性的圣杯，水平伸缩可以克服垂直伸缩带来的单位计算成本随计

算 能力增加而迅速飙升的问题。

另外，水平伸缩总是可以增加更多服务器，这样，就不会像垂直伸缩那样遭遇到单台服

务器的极限。



互联网架构的演化



架构演化第零阶段：最简单的互联网应用架构



应用程序+本地文件系统+本地数据库



架构演化第一阶段：应用数据分离



应用程序独立部署，文件服务器单独部署，数据库服务器单独部署



架构演化第二阶段：使用缓存改善系统性能



应用程序+本地缓存，远程分布式缓存服务器，文件服务器，数据库服务器



架构演化第三阶段：使用应用服务器集群改善系统的并发处理能力



负载均衡调度服务器，应用服务器集群，文件服务器，数据库服务器，远程分布式缓存服务器



架构演化第四阶段：数据库读写分离



负载均衡调度服务器，应用服务器集群，文件服务器，数据库服务器进行主从分离，远程分布式缓存服务器



架构演化第五阶段：使用反向代理喝CDN 加速网站响应



CDN服务器，反向代理服务器，负载均衡调度服务器，应用服务器集群，文件服务器，数据库服务器进行主从分离，远程分布式缓存服务器



架构演化第六阶段：使用分布式文件系统和分布式数据库系统



CDN服务器，反向代理服务器，负载均衡调度服务器，应用服务器集群，分布式文件服务器，分布式数据库服务器，分布式缓存服务器



架构演化第七阶段：使用 NoSQL 和搜索引擎



CDN服务器，反向代理服务器，负载均衡调度服务器，应用服务器集群，分布式文件服务器，分布式数据库服务器，分布式缓存服务器，搜索引擎服务器，NoSQL服务器



架构演化第八阶段：业务拆分



将业务拆分部署到不同的服务器集群，扩容和集群的伸缩更灵活。不同的服务器之间通过RPC调用，消息队列等进行通信。



架构演化第九阶段：微服务及中台化



系统中的公用服务微服务化，这些微服务统一起来提供更复杂的功能就是中台化。



架构演化第十阶段 大数据与智能化



互联网架构模式



架构模式



每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这

样，你就能一次又一次的使用该方案而不必做重复工作。

模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用。

互联网架构模式就是试图去描述那些为解决互联网系统高性能、高可用、易扩展、可伸

缩、安全等目标，被很多互联网应用重复使用的一些解决方案，这些解决方案是互联网

软件系统的重要组成部分。



• 分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，

每个部分负责一部分相对比较单一的职责，然后通过上层对下层依赖和调用组成一个完

整的系统。



• 分割



分割就是在纵向方面对软件进行切分。

系统越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割

开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，

便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。



• 分布式



对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将

不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着解决同样的问

题可以使用更多的计算机，计算机越多，CPU、内存、存储资源也就越多，能够处理的

并发访问和数据量就越大。

1. 分布式应用和服务

2. 分布式静态资源

3. 分布式数据和存储

4. 分布式计算



• 集群

使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块，

比如网站的首页，还需要将独立部署的服务器集群化，即多台服务器部署相同应用构成

一个集群，通过负载均衡设备共同对外提供服务。



• 缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第

一手段，现代 CPU 越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计

中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。

1. CDN

2. 反向代理

3. 本地缓存

4. 远程缓存



• 异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间越少直接关系，

那么就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了前

面提到的分层、分割、分布等手段，还有一个重要手段是异步，就是将一个业务操作分

成多个阶段，每个阶段之间通过共享数据而不是直接调用的方法进行协作。

1. 提高系统可用性

2. 加快网站响应速度

3. 消除并发访问高峰



• 冗余

互联网应用需要7×24小时连续运行，但是服务器总有可能会出现故障，特别是服务器规

模比较大的时候，服务器宕机是必然事件。要想保证在服务器宕机的情况下网站依然可

以继续服务，数据不会丢失，就需要一定程度的服务器冗余运行，数据冗余备份。



• 自动化（主要是运维方向）

在无人值守的情况下网站可以正常运行，一切都可以自动化是网站的理想状态。目前互

联网的自动化架构设计主要集中在运维方面。



• 安全



互联网的开放特性使得其从诞生起就面对巨大的安全挑战，网站在安全架构方面也积累

了许多模式：通过密码和手机校验码进行身份认证；登录、交易等操作需要对网络通讯

进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理；为了防止机器

人程序滥用网络资源供给网站，网站使用验证码进行识别；对于常见的用于攻击网站的

XSS 攻击，SQL 注入，进行编码转换等相应处理；对于垃圾信息、敏感信息进行过滤；

对转账交易等重要操作根据交易模式和交易信息进行风险控制。



互联网系统架构核心要素



高性能

性能是互联网的一个重要指标，除非是没得选择，否则用户无法忍受一个响应缓慢的应 用。一个打开缓慢应用会导致严重的用户流失，很多时候系统性能问题是系统架构升级

优化的触发器。可以说性能是互联网系统架构设计的一个重要方面，任何架构设计方案

都必须考虑可能会带来的性能问题。

也正是因为性能问题几乎无处不在，所以优化网站性能的手段也非常多，从用户端到数

据库，从代码到机房部署，影响用户请求的所有环节都可以进行性能优化。



高可用



因为互联网分布式系统使用的服务器硬件通常是普通的商用服务器，这些服务器的设计

目标本身并不保证高可用，也就是说，很有可能会出现服务器硬件故障，也就是俗称的

服务器宕机。大型互联网系统通常都会有上万台服务器，每天都必定会有一些服务器宕

机，因此系统高可用架构设计的前提是必然会出现服务器宕机，而高可用设计的目标就

是当服务器宕机的时候，服务或者应用依然可用。

系统高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储在多

台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数

据丢失。



可伸缩



大型互联网应用通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性

是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增

长的数据存储需求。

衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添

加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中

可容纳的总的服务器数量是否有限制。



可扩展



可扩展架构的主要手段是事件驱动架构和分布式服务。



安全



互联网是开放的，任何人在任何地方都可以访问系统。系统的安全架构就是保护系统不

受恶意访问和攻击，保护网站的重要数据不被窃取。

衡量系统安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应

对策略。



互联网架构技术汇总



• 前端架构

• 网关及应用层架构

• 服务层架构

• 存储层架构

• 后台架构

• 数据中心机房架构

• 安全架构

• 数据采集与监控



前端架构



1. App 及 Web 开发技术

2. 浏览器及 HTTP 优化技术

3. CDN

4. 动静分离

5. 图片服务

6. 反向代理

7. DNS



网关及应用层架构



1. 网关架构

2. 负载均衡

3. 动态页面静态化

4. 业务拆分



服务层架构



1. 微服务框架

2. 分布式消息队列

3. 分布式缓存

4. 分布式一致性（锁）服务



存储层架构



1. 分布式文件

2. 分布式关系数据库

3. NoSQL 数据库



后台架构

1. 大数据平台

2. 搜索引擎

3. 推荐引擎

4. 数据仓库



运维与安全

1. 数据采集与展示

2. 数据监控与报警

3. 攻击与防护

4. 数据加密与解密



维基百科技术架构

• GeoDNS(地理位置的域名服务器)

• LVS提供的负载均衡服务器

• squid 反向代理服务器

• PHP组成的应用服务器

• 对象缓存服务器

• Lighttpd图片服务器

• mysql数据库服务器

• lucene 构建搜索引擎

• 缓存内容失效通知



淘宝业务发展及技术架构

从首页看业务发展（03年起）

• C2C 到B2C

• 首页商品类目（买卖的专业性）

• 搜索功能



前期技术发展历程



• 2003.5 - 2004.1

1. 非典时期

2. LAMP

3. MySQL读写分离



• 2004.1 - 2004.5（技术要为业务服务）

1. MySQL迁移至Oracle（垂直伸缩能最快速解决问题）

2. 引入SQL Relay中间件



• 2004.2 -2004.10

1. php迁移至java

2. MVC框架WebX

3. 项目管理工具AntX

4. 引入搜索引擎ISearch



• 2004.10 - 2006.10

1. weblogic迁移至jboss

2. 支持分库的数据访问框架

3. 抛弃EJB

4. 引入Spring

5. 基于BDB的缓存，ESI

6. 建立CDN

7. 类目属性体系



• 2006.10 - 2007.10

1. 分布式缓存Tbstore(后来的Tair)

2. 分布式存储TFS

3. 分布式搜索引擎



宅米网技术变迁



宅米业务规模变迁

• 融资金额

• 峰值日订单

• 技术团队规模



宅米技术架构体系变迁



架构1.0

• 移动APP

• 移动web

• 负载均衡

• 应用服务器集群

• mysql数据库



存在的问题

• 数据库负载压力大

• 请求响应速度慢

• 50万峰值订单



架构2.0

• 移动APP

• 移动web

• CDN服务

• 负载均衡

• 应用服务器集群

• 分布式文件系统（图片）

• 大数据平台

• kafka消息队列

• mysql 主从服务器集群

• Redis集群（缓存商品信息）



架构2.0存在的挑战



• 代码耦合严重，相同代码重复开发

• 订单表达到数据存储极限

• 200万峰值订单



架构3.0

• 移动APP

• 移动web

• CDN服务

• 负载均衡

• 应用服务器集群

• 分布式文件系统（图片）

• 大数据平台

• kafka消息队列

• mysql 主从服务器集群

• Redis集群（缓存商品信息）

• 可复用业务提取出来作为微服务发布（分布式集群）

• MongoDB(数据的冷热分离)



大数据平台



宅米技术团队组织变迁

1.0 按技术栈

• 技术部

• 后端组

• web组

• APP组



2.0 按产品线

• 技术部

• 买家组

• 卖家组

• 后台组



3.0



• 技术部

• 产品研发部

• 买家组

• 卖家组

• 后台组

• 测试组



• 架构运维部

• 架构组

• 运维组



• 数据平台部

• 数据平台组

• 数据分析组



• 项目管理组



技术团队管理



• 构建自驱动的闭环

1. 不要分配任务，去完成目标而不是完成工作

2. 加班既不是目的也不是手段

3. 亡羊补牢，没事不要瞎折腾

• 只有优秀的员工才能创建出优秀的企业

1. 为员工的成长买单

2. 先关注人，后关注事

3. 快乐工作



总结



通过第四周的课程知识对互联网系统架构中的挑战以及对应的解决方案有了深刻的认知，并通过对互联网系统架构演进课程的学习，对整个行业发展的演进过程进行了全面的学习。

学习了解了互联网架构模式的核心要素很受启发，结合了目前的工作更明确了提升推进工作进度的方向。通过学习维基百科，淘宝及宅米网的技术变迁。对渐进式发展的互联网产

品有了更加深入的理解。尤其宅米网技术团队组织结构的调整变迁，让我意识到我当前所在团队也存在着同样的问题。参照之下对团队下一步的调整管理有了新的思路。很感谢。