分布式架构笔记（1）-演进过程

什么是分布式架构？
互联网应用的特点是什么呢？这是主要讲的是高并发，海量的数据。高并发就是指系统在单位时间内收到的请求量很大。海量数据就是海量数据的存储和处理。特别是随着网络的高速发展，传统的单机服务器已经无法满足这种需求，所以就出现了分布式。分布式就通过增加服务器以及心跳等机制把服务器连接起来，协同工作。协同工作需要解决如下两个问题：

• 任务的分解
  把任务就是拆解成若干个独立任务，每个任务在一台节点上运行，实现多任务的并发执行。
• 结点的通信
  节点之间互相通信，需要设计特定的通信协议来实现。协议可以采用RPC或Message Queue等方式。
  **整个发展历程我归结于：单机到集群再到分布式。
  **
• 单机阶段
  互联网发展的早期，因为用户需求量部署很大，软件和应用都是部署在一台机器上。也就是说war和数据库其实都是在一台机器上。

• 服务器和数据库分离阶段

后来随着数量的提升，慢慢的将数据库和war分离开，放在不同的两台机器上。这算是单机阶段慢慢向集群阶段发展。

• 集群阶段
  随着请求量的不断提升，单机阶段已经无法满足用户的需求。这时候通过增加服务器的数量，通过Ngin这个代理服务器进行分流，将用户的需求分流到各个服务器，从而提高各个服务器的承载力。
  

• 集群阶段使用负载均衡器

• 在负载均衡没有出现前，集群阶段会出现单个服务器满了之后再将用户的请求转发给剩下的服务器，这样就会使得单个服务器的压力太大。通过负载均衡器来将用户的请求进行转发，转发给负载较低的服务器，这样就不会出单个服务器压力太大的情况。
  

• 集群阶段的读写分离阶段
  通过负载均衡器以及服务器集群的运用，系统在性能上得到了明显的提升，但是数据库的压力也在慢慢扩大，所以需要对数据库进行优化，优化的方式是通过把数据库进行一分为二，也就是读操作由一台服务器控制，写操作由另一台服务器控制。这样就在一定程度上降低了数据库的压力。
  

• 引入缓存机制缓解数据库的压力
  上面的集群阶段的读写分离阶段又会遇到如下问题：
  （1）、主从数据库之间的数据同步 ； 可以使用mysql自带的master-slave方式实现主从复制。
  （2）、对应数据源的选择 ； 采用第三方数据库中间件，例如mycat。

• 使用搜索引擎缓解读库的压力
  数据库做读库的话，尝尝对模糊查找效率不是特别好，像电商类的网站，搜索是非常核心的功能，即便是做了读写分离，这个问题也不能有效解决。那么这个时候就需要引入搜索引擎了。
  使用搜索引擎能够大大提高我们的查询速度，但是同时也会带来一些附加的问题，比如维护索引的构建。
  

• 引入缓存机制缓解数据库的压力
  随着访问量的持续增加，逐渐出现许多用户访问统一部分内容的情况，对于这些热点数据，没必要每次都从数据库去读取，我们可以使用缓存技术，比如memcache、redis来作为我们应用层的缓存；另外在某些场景下，比如我们对用户的某些IP的访问频率做限制，那这个放内存中又不合适，放数据库又太麻烦，这个时候可以使用Nosql的方式比如mongDB来代替传统的关系型数据库。
  

• 数据库的水平/垂直拆分
  尽管采取了增加缓存，读写分离的方式，但是随着数据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我们可以考虑对数据的垂直拆分和水平拆分

• 应用的拆分
  随着业务的发展，业务越来越多，应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑讲应用拆分，按照领域模型讲我们的用户、商品、交易拆分成多个子系统。这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来，否则就会是一个坑。所以通过走服务化路线的方式来解决。那么服务拆分以后，各个服务之间如何进行远程通信呢？通过RPC技术，比较典型的有：webservice、hessian、http、RMI等等前期通过这些技术能够很好的解决各个服务之间通信问题，but，互联网的发展是持续的，所以架构的演变和优化还在持续。
  

• 解决需求量过大的一些方案：服务降级。
  我们都知道每当双11的时候，淘宝和支付宝的访问量是很大的，这时候就可以实施服务降级，通过关闭一些不常用的服务来提高主要服务的性能，这时候就可以缓解主服务的压力。