分布式架构演变历史 - 好文

一。分布式架构的发展史

1946年情人节世界上第一台电子数字计算机诞生在美国宾夕法尼亚大学，他的名字是ENIAC。这台计算机占地170平米，重达30吨，每秒可进行5000次加法运算。

第一台计算机的诞生，标志着一个新的it时代到来，一方面计算机的性能每年都在提升，从最早的8位CPU到现在的64位。从早期的MB到现在的GB级别内存，从慢速的机械式硬盘到现在的固态SSD硬盘。

冯诺依曼模型

ENIAC之后，计算机便进入IBM主导的时代，IBM大型机之父吉恩.阿姆达尔被认为是有史以来最伟大的计算机设计师之一。

20世纪80年代，在大型机霸主的时代，计算机架构同事向两个方向发展

1，以CICS（微型处理执行的计算机语言指令）CPU为架构的价格便宜的面向个人的pc

2，以RISC（精简指令集计算机）CPU为架构的价格昂贵的面相企业的小型unix服务器

二。分布式架构发展的里程碑

大型机的出现，凭借着大型机超强的计算和I/O处理能力，稳定性，安全性等，在很长的一段时间内，大型机都是引领计算机行业及商业计算领域的发展。而集中式系统架构也成主流。随着计算机的发展，这种架构越来越难以适应人们的需求。

比如：

1. 由于大型机的复杂型，导致培养一个熟练运维的大型机的人成本很高

2. 大型机很贵，一般只有政府金融电信等行业才能用的起

3.单点问题，一台大型主机出现故障，那么整个系统都处于崩溃状态，这种不可能导致的损失是非常大的。

4. 科技进步，pc机性能越来越好，很多企业放弃使用大型机改用小型机及普通PC来搭建系统架构。

例如：阿里巴巴在2009年的去“IOE”运动

IEO 是指 IBM小型机，Oracle
数据库，EMC的高端存储，2009年去“IOE”战略透漏，到2013年5月17日最后的IBM小型机在支付宝下线。

为什么要去IOE？

采用Oracle数据库，并利用小型机和高端存储设备提供高性能的数据处理和存储服务，随着业务的发展，数据量不断的增长，传统的集中式架构方式在扩展性能方面遭遇瓶颈。

传统的商业数据库，多以集中式架构为主。这些传统的数据库最大的特点就是
集中，将所有的数据都存储在一个数据库中。依靠设备的性能来提供高性能处理和计算。集中式数据库在扩展上主要采用向上扩展的方式，通过增加CPU和内存，磁盘等方式提高处理能力，这种集中式的数据库架构，使得数据库成为了整个系统的瓶颈，已经越来越不适应海量数据对计算能力的巨大需求。

三。分布式系统的意义

1.升级单机处理能力的性价比越来越低，单机的处理能力主要依靠CPU 内存，磁盘通过更换硬件做垂直扩展的方式来提升新能，成本越来越高

2，单机处理能力存在瓶颈

3，单机架构的稳定性和可用性两个指标很难达到。

四。分布式架构系统的演变

一个成熟的系统并不是一开始就设计的非常完善，也不是一开始就具有高性能，高可用，安全性等特性，而是随着用户的增加和业务功能的扩展逐步完善。在这过程中
开发模式，技术架构都会发生重大变化，而针对不同业务特征的系统会有各自的侧重点，像淘宝这类网站要解决的事海量商品搜索下单支付等问题。像腾讯
要解决数亿级别用户的实施消息传输等。每种业务都有自己不同的系统架构。

以Java Web 为例搭建简单的电商系统，从系统来看系统演变的历史，要注意的是接下来模型的演示。关注数据量访问量，网站结构的变化。

加入系统具备功能：用户，商品交易

最初始阶段，单体架构：

网站的初期，经常在单机上跑所有的程序，把所有的软件和应用部署在同一台机子上，这样就完成了一个简单系统的搭建。初期讲究的事效率。

阶段二。应用服务器和数据库服务器分离

随着网站的上线，访问量的增加，服务器负载变高。在服务器还没有超载的时候，重新规划，提上网站性能，加入代码层面已经没办法提升了，在不提高单台机子性能下，增加机子是一个比较好的方式，投入产出比非常高，在这个阶段把web服务器和数据库服务器分开，这样不仅提高单机负载，也能提高容灾能力

阶段三应用服务器集群，应用服务器负载吃紧。

随着时间推移，网站访问量继续增加，单台服务器已经无法满足需求，假如数据库服务器没有达到瓶颈，我们可以增加应用服务器，通过应用服务器集群将用户的请求分流到各个服务器上，从而提高负载能力。此时服务器间没有直接交互，都是通过数据库各自对外交互

系统架构演变到此阶段，新的问题慢慢也会出现

1. 用户请求谁来转发，如何转发？

2. 用户每次方位到的服务器不一样，那么session如何处理？

阶段四，数据库压力变大，数据库实行读写分离

架构演变到这里并不是终点。我们通过上面的方式把应用层的性能提升了，但是数据库的负载过大，且单点安全问题，怎么提高数据库性能，且保证安全，有了前面的思路
我们照猫画虎。但是假如我们单纯的把数据库一分为二，然后对于数据库请求，分别负载到两台机子上，
那么新的问题又来了，数据库数据不统一的问题，所以我们先采用读写分离的方式

这个新的架构又要面临新的问题和挑战

1，主从数据库之间数据同步，可以使用mysql自带的 master-slave 方式实现主从

2，因对数据源的选择，采用第三方数据库中间件例如 mycat

阶段五使用搜索引擎环节度数据库的压力

数据库做读库的话，尝试对模糊查询效率并不好，像电商类的网站搜索是非常核心的功能，几遍做了读写分离这个问题也不能有效解决，那么这个时候就需要引入搜索引擎，使用搜索引擎能大大提高查询效率，但同时也有问题，比如索引的维护

阶段六引入缓存机制环节数据库压力（比如热点数据）

随着访问量的持续增加，逐渐出现许多用户访问同一部分数据的情况，对这些热点数据没必要每次都查询数据库，我们可以使用缓存技术比如 memcache redis
来作为应用层缓存，另外某些场景下我们对用户的某些ip的访问频率做限制，那么放在内存中又不合适，放在数据库总太麻烦，这时候可以使用NoSql的方式比如
mongDB来代替传统数据库

阶段七，数据库的水平和垂直拆分

网站演进的过程中，用户商品交易的数据还在同一个数据库中，尽管采取了缓存
读写分离的方式，但是数据库的压力持续增加，数据库的瓶颈仍是一个很大的问题，因此我们考虑对数据垂直拆分和水平拆分

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

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

阶段八应用拆分

随着业务的发展，越来多应用压力大。工程规模随着业务的发展，越来多应用压力大。。这个时候就可以考虑讲
应用拆分，按照领域模型我们的用户、商品交易拆分成多个子系统我们的用户、商品交易拆分成多个子系统

这样拆分后，可能会有一些相同的代码，如用户操作，商品查询等，
所以会导致每个系统都会有用户查询访问相关操作，这些相同的操作一定要抽离出来，否者就是坑，所有通过走服务化方式解决

那么服务拆分后，各个服务之间如何通信，通过RPC技术，比如 webservice hessian http RMI 等等

前期通过这些技术很好的解决问题，但是互联网的发展是持续不断地，所以架构演变和优化还在继续。。。

热门工具换一换