一、互联网架构演变

一、互联网架构的演变

互联网架构主要解决的问题

• 高并发

• 海量数据

什么是分布式

从上图可以看出，要想实现分布式，必须解决两个问题：

1. 任务分解

2. 结点通信

分布式和集群的关系

分布式：一个业务拆分为多个子业务，部署在不同的服务器上

集群：同一个业务，部署在多个服务器上

注意：如果将多个子系统部署在同一服务器上，在网络层面来讲，就不能称为分布式

发展历史

计算机的发展历史

1. 1946 年情人节第一台电子数字计算机，在美国宾夕法尼亚大学诞生，可以进行每秒五千次的加法运算，由美国人莫克利发明

2. 1964 年，大型机 IBM SYSTEM/360 被发明，具有超强的计算能力和可靠性。当时通常用于金融、政府。大型主机的出现，引领了软件朝集中式发展

3. 大型主机后，计算机共有两条发展趋势：

4. x86 CPU 朝个人 PC 机发展

5. RISC CPU 朝小型机发展

大型机时代，软件往集中式发展，成为当时软件架构的主流。

分布式架构的发展历史

1. PC 机的性能不断提升，给分布式提供了条件

2. 企业开始去 IOE 运动： IBM 小型机、Oracle、EMC 存储设备

3. 2013 年 5 月 17 日，最后一台 IBM 小型机下线

淘宝大约在 08 年开始去 IOE，将其架构替换为: PC 机、MySql、SSD 硬盘和 Fusion-IO

架构演变

单机计算机的架构-> 分布式计算机架构

冯诺依曼模型：运算器、控制器、存储器、输入设备、输出设备

计算机架构也可以映射为分布式架构：

1. 存储器：数据库、缓存

2. 运算器：业务员逻辑、程序

3. 控制器：硬负载、软负载

4. 输入设备/输出设备：用户界面

5. 数据流/指令流/控制流：RPC 调用、消息

分布式架构演变过程

一个公司的架构在一开始一定不是最完美的，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的

第一阶段 单应用架构

描述：网站初期，在一台服务器上运行所有的软件，搭建过程效率极高

第二阶段 应用服务器与数据服务器分离

随着负载的提高，单机服务器性能已经无法满足网站的运行，此时可以对将应用服务器与数据服务器分离，既提高了负载能力，又提高了系统的容灾能力

描述：应用服务器与数据服务器完全分离，相互不影响，大大减少网站宕机的风险

第三阶段 应用服务器集群

随着访问量的不断增加，单台应用服务器不再能满足我们的需求，可以通过增加应用服务器的方式对用户请求进行分流，从而提升系统的负载能力

发展到上面的架构，各种问题也就出现：

1. 用户请求如何转发到具体的应用服务器上

2. 如果每次访问到服务器不同，如何维护 session 信息，如何进行 session 共享

负载问题解决：

1. 硬件负载均衡器，F5，完善，可以解决 session 共享的问题，但是比较昂贵

2. 软负载均衡

Session 跨域共享问题解决：

1. session sticky， 保证请求落在同一台服务器上

2. session replication， session 复制，早期常用的解决方案，每台服务器上都保存 session，会造成 session 网络同步开销，占用空间更大

3. session 集中存储，存储在 DB 或者缓存（redis）中

4. cookie ，无需在服务器上保存会话信息，将会话信息保存在 cookie 中，一般时 access_token(userid/token/timstamp)，access_token 需要进行 ip 验证，防止 access_token 被截获，造成安全问题

为了解决上述问题，架构就变成了如下：

第四阶段 数据服务器读写分离

如何提高数据库的性能？如果单纯的部署两台数据库，然后负载到不同的数据库上，一定会造成数据不一致的情况，又因为网站中百分之八十大都是读请求，所以我们可以考虑对数据库进行读写分离。

上面的架构引入了两个新的问题？

1. 如何进行读写分离？答：mysql 提供了 master/slave 模式

2. 应用层如何对数据源选择？答：使用第三方数据库中间件，比如 mycat

第五阶段 引入搜索引擎

用户频繁的搜索导致度数据库压力继续增大，使用 sql like 搜索效率极低，此时开始引入搜索引擎集群，搜索操作都会经过搜索引擎，大大减缓了读库的压力。

问题：搜索引擎索引数据如何同步，是实时增量同步？还是定时全量同步？

第六阶段 引入缓存技术，减缓数据库压力

第七阶段 数据库水平/垂直拆分

用户多，随着数据量的增大，数据库的瓶颈又重新展现出来，此时可以对数据库进行水平拆分和垂直拆分。

• 垂直拆分：将数据库不同业务数据拆分到不同的数据库中

• 水平拆分：将同一表中数据拆分到两个甚至更多的数据库中，水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈，这时可以采取将表拆分到多个数据库中

第八阶段 应用拆分

当业务越来越大，应用服务器压力越来越大时，工程规模也越来越大，我们可以考虑应用拆分，将业务拆分为多个子系统

上述应用拆分后，虽然进行了模块拆分，但是如果要在交易信息中查询用户信息，并不是通过调用用户模块的功能实现的，而实直接在内部使用 sql 查询用户信息，所以每个系统都会有查询用户的 sql，如果用户表结构发生变化，所有子系统都会进行修改，所以需要对用户进行服务抽离：