【分布式】互联网架构的演变

互联网架构主要解决的问题
高并发
海量数据
什么是分布式

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

任务分解
结点通信
分布式和集群的关系
分布式：一个业务拆分为多个子业务，部署在不同的服务器上
集群：同一个业务，部署在多个服务器上

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

发展历史
计算机的发展历史
1946年情人节第一台电子数字计算机，在美国宾夕法尼亚大学诞生，可以进行每秒五千次的加法运算，由美国人莫克利发明
1964年，大型机 IBM SYSTEM/360 被发明，具有超强的计算能力和可靠性。当时通常用于金融、政府。大型主机的出现，引领了软件朝集中式发展
大型主机后，计算机共有两条发展趋势：
x86 CPU 朝个人PC机发展
RISC CPU 朝小型机发展
大型机时代，软件往集中式发展，成为当时软件架构的主流。

分布式架构的发展历史
PC机的性能不断提升，给分布式提供了条件
企业开始去 IOE 运动： IBM小型机、Oracle、EMC存储设备
2013年5月17日，最后一台IBM小型机下线
淘宝大约在08年开始去IOE，将其架构替换为: PC机、MySql、SSD硬盘和Fusion-IO

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

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

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

存储器：数据库、缓存
运算器：业务员逻辑、程序
控制器：硬负载、软负载
输入设备/输出设备：用户界面
数据流/指令流/控制流：RPC调用、消息
分布式架构演变过程
一个公司的架构在一开始一定不是最完美的，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的

第一阶段 单应用架构

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

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

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

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

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

用户请求如何转发到具体的应用服务器上
如果每次访问到服务器不同，如何维护session信息，如何进行session共享
负载问题解决：

硬件负载均衡器，F5，完善，可以解决session共享的问题，但是比较昂贵
软负载均衡
Session跨域共享问题解决：

session sticky， 保证请求落在同一台服务器上
session replication， session复制，早期常用的解决方案，每台服务器上都保存session，会造成session网络同步开销，占用空间更大
session集中存储，存储在DB或者缓存（redis）中
cookie ，无需在服务器上保存会话信息，将会话信息保存在cookie中，一般时access_token(userid/token/timstamp)，access_token需要进行ip验证，防止access_token被截获，造成安全问题
为了解决上述问题，架构就变成了如下：

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

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

如何进行读写分离？答：mysql提供了master/slave模式
应用层如何对数据源选择？答：使用第三方数据库中间件，比如mycat
第五阶段 引入搜索引擎
用户频繁的搜索导致度数据库压力继续增大，使用 sql like搜索效率极低，此时开始引入搜索引擎集群，搜索操作都会经过搜索引擎，大大减缓了读库的压力。

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

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

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

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

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

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