设为首页 加入收藏

TOP

大型项目架构演进过程及思考(一)
2019-10-09 20:04:51 】 浏览:388
Tags:大型 项目 架构 演进 过程 思考

淘宝架构

我们以淘宝架构为例,了解下大型的电商项目的服务端的架构是怎样,如图所示

上面是一些安全体系系统,如数据安全体系、应用安全体系、前端安全体系等。
中间是业务运营服务系统,如会员服务、商品服务、店铺服务、交易服务等。
还有共享业务,如分布式数据层、数据分析服务、配置服务、数据搜索服务等。
最下面呢,是中间件服务,如MQS即队列服务,OCS即缓存服务等。

图中也有一些看不到,例如高可用的一个体现,实现双机房容灾和异地机房单元化部署,为淘宝业务提供稳定、高效和易于维护的基础架构支撑。

这是一个含金量非常高的架构,也是一个非常复杂而庞大的架构。当然这个也不是一天两天演进成这样的,也不是一上来就设计并开发成这样高大上的架构的。

这边就要说一下,小型公司要怎么做呢?对很多创业公司而言,很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时,如果系统初期就设计一个千万级并发的流量架构,很难有公司可以支撑这个成本。

因此,一个大型服务系统都是从小一步一步走过来的,在每个阶段,找到对应该阶段网站架构所面临的问题,然后在不断解决这些问题,在这个过程中整个架构会一直演进。
那我们来一起看一下。

单服务器-俗称all in one

从一个小网站说起。一台服务器也就足够了。文件服务器,数据库,还有应用都部署在一台机器,俗称ALL IN ONE

随着我们用户越来越多,访问越来越大,硬盘,CPU,内存等都开始吃紧。一台服务器已经满足不了。这个时候看一下下一步演进

数据服务与应用服务分离

 

 

 

我们将数据服务和应用服务分离,给应用服务器配置更好的 CPU,内存。而给数据服务器配置更好更大的硬盘。

分离之后提高一定的可用性,例如Files Server挂了,我们还是可以操作应用和数据库等。
随着访问qps越来越高,降低接口访问时间,提高服务性能和并发,成为了我们下一个目标,发现有很多业务数据不需要每次都从数据库获取。

使用缓存,包括本地缓存,远程缓存,远程分布式缓存

 

 

 

因为 80% 的业务访问都集中在 20% 的数据上,也就是我们经常说的28法则。如果我们能将这部分数据缓存下来,性能一下子就上来了。而缓存又分为两种:本地缓存和远程缓存缓存,以及远程分布式缓存,我们这里面的远程缓存图上画的是分布式的缓存集群(Cluster)。

思考的点

  1. .          具有哪种业务特点数据使用缓存?
  2. .          具有哪种业务特点的数据使用本地缓存?
  3. .          具有哪种务特点的数据使用远程缓存?
  4. .          分布式缓存在扩容时候会碰到什么问题?如何解决?分布式缓存的算法都有哪几种?各有什么优缺点?

这个时候随着访问qps的提高,服务器的处理能力会成为瓶颈。虽然是可以通过购买更强大的硬件,但总会有上限,而且这个到后期成本就是指数级增长了,这时,我们就需要服务器的集群。需要使我们的服务器可以横向扩展,这时,就必须加个新东西:负载均衡调度服务器。

使用负载均衡,进行服务器集群

 

 


增加了负载均衡,服务器集群之后,我们可以横向扩展服务器,解决了服务器处理能力的瓶颈。

思考的点

  1. .          负载均衡的调度策略都有哪些?
  2. .          各有什么优缺点?
  3. .          各适合什么场景?

打个比方,我们有轮询,权重,地址散列,地址散列又分为原ip地址散列hash,目标ip地址散列hash,最少连接,加权最少连接,还有继续升级的很多种策略......我们一起来分析一下

典型负载均衡策略分析

  1. .          轮询:优点:实现简单,缺点:不考虑每台服务器处理能力
  2. .          权重:优点:考虑了服务器处理能力的不同
  3. .          地址散列:优点:能实现同一个用户访问同一个服务器
  4. .          最少连接:优点:使集群中各个服务器负载更加均匀
  5. .          加权最少连接:在最少连接的基础上,为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重,计算出来的值小的服务器优先被选择。

继续引出问题的场景:

我们的登录的时候登录了A服务器,session信息存储到A服务器上了,假设我们使用的负载均衡策略是ip hash,那么登录信息还可以从A服务器上访问,但是这个有可能造成某些服务器压力过大,某些服务器又没有什么压力,这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈,并且请求不够分散。

这时候我们使用轮询或者最小连接负载均衡策略,就导致了,第一次访问A服务器,第二次可能访问到B服务器,这个时候存储在A服务器上的session信息在B服务器上读取不到。

Session管理-Session Sticky粘滞会话:

 

 

 

打个比方就是如果我们每次吃饭都要保证我们用的是自己的碗筷,而只要我们在一家饭店里存着我们的碗筷,只要我们每次去这家饭店吃饭就好了。

对于同一个连接中的数据包,负载均衡会将其转发至后端固定的服务器进行处理。

解决了我们session共享的问题,但是它有什么缺点呢?

  1. .          一台服务器运行的服务挂掉,或者重启,上面的 session 都没了
  2. .          负载均衡器成了有状态的机器,为以后实现容灾造成了羁绊

Session管理-Session 复制

 

就像我们在所有的饭店里都存一份自己的碗筷。我们随意去哪一家饭店吃饭都OK,不适合做大规模集群,适合机器不多的情况。

解决了我们session共享的问题,但是它有什么缺点呢?

  1. .  &n
首页 上一页 1 2 3 下一页 尾页 1/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇行为型设计模式(下) 下一篇spring cloud 之 -- eureka vs co..

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目