分布式架构——分布式架构的演进过程(下)

上一篇博客简单介绍了分布式的发展历史和基本概念

本篇博客则将以电商系统为例,详细介绍分布式发展的过程 

假设我们的电商系统中只有三个模块:用户模块,交易模块和商品模块

阶段一:单应用架构

在网站创建初期,经常把所有的东西都在一台机器上部署,这个时候的架构是单应用架构,优点是效率非常高



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

网站上线了,随着时间推移,访问量开始逐渐增大,服务器逐渐的就扛不住了,这个时候就要考虑加机器了,这就进入了第二阶段。

这个阶段增加机器的主要目的是将web服务器和数据库服务器进行拆分,这样不仅提高了单机的负载能力,也提高了容灾能力



第三阶段:应用服务器集群

然而随着访问量的持续增加,单台服务器已经无法满足需求。假设数据库服务器的还未遇到性能问题

此时可以增加应用服务器,这就进入第三阶段——应用服务器集群。



在这个阶段有些问题就逐渐显现出来了,比如:

(1)用户的请求该由哪一台机器进行处理? ——负载均衡(F5/apache/nginx)

(2)如果用户每次请求的机器不同,那么session如何维护?

1、session同步


2、通过第三方存储(redis等)存储session

3、跳过容器对象

这样架构就变为了以下模式。


阶段四:数据库读写分离

随着业务量进一步增加,数据库服务器的I/O能力会存在瓶颈。

首先考虑的是加机器,但是如果直接一分为二,每次读写还要额外判断数据应该在哪台机器上。

基于电商系统数据库读多写少的特点,可以将一个服务器作为写库,另一个库设为读库,

并设置主从同步进行复制。

这样也会带来数据库不一致的问题,这个问题后期有时间会单独讨论。

实际上,如果读库的量远大于写库的访问量,需要设置多个读库时,可以采取以下的结构


阶段五:引入缓存机制 

对于热点数据,没必要每次都去数据库中读取,应该使用 redis、memcache等将这些数据缓存起来


至此,分布式架构的基本框架已经形成。


阶段六:数据库的水平、垂直拆分

数据库永远是最容易造成瓶颈的地方之一,例如阿里巴巴09年“去IOE运动”就是为了解决数据库扩展性瓶颈问题。

在整个架构的编号过程中,所有的数据还是在同一个数据库中的,因此我们可以考虑对数据进行拆分

其中:

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


水平拆分则是把同一个表中的数据拆分到两个甚至更多的数据库中,有些公司的数据库是按照日期分为31*N个数据库


阶段七:应用拆分阶段

随着需求的不断提出,应用的体量也越来越大,因此需要按照领域对业务进行拆分


至此,完整的分布式架构演进过程结束


tips:分布式架构和微服务架构

分布式:

    • 不同模块部署在不同服务器上
    • 作用:分布式解决网站高并发带来问题

而微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。

微服务是可以部署在一台服务器上的。


如果有兴趣,可以加群一起学习。


没有更多推荐了,返回首页