互联网架构演变
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
互联网架构索要解决的主要问题：
高并发
海量数据
从上图可以看出，要想实现分布式，必须解决两个问题：
任务分解
结点通信
分布式：一个业务拆分为多个子业务，部署在不同的服务器上
集群：同一个业务，部署在多个服务器上
注意：如果将多个子系统部署在同一服务器上，在网络层面来讲，就不能称为分布式
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，如果用户表结构发生变化，所有子系统都会进行修改，所以需要对用户进行服务抽离：
