http://www.oldrazor.com

互联网架构的演变

  这种结构,web容易挂掉,业务就会终止,由于高可用的需求,出现了下面这样的架构

  2 加了一个web,两个web之间是主备的关系,一个挂了,另一个来代替,用来解决高可用问题

  3 之后发现这样的架构支持的访问量不够了,前端撑不住那么大的访问量,因为前端的访问量和DB的落库有大概是10比1的比例,前端访问10个,会有1个能够落库,所以随着访问量的增加,前端先扛不住了,这个时候主、备结构已经不能解决高可用的问题,所以在web前面加了一个ngx,作为负载均衡进行访问的转发,这个时候,web和web之间的主备关系就不存在了,在ngx进行转发的时候会有一个session保持的操作,再后来就出现无状态的概念,在两个web之间进行轮询,给谁都行

  4当无状态的概念出来以后,web这一层就可以进行多次的横向扩展,这是第一次质的飞越

  5 后来主、备ngx结构也不满足需求了,就在ngx前面加了一个lvs,lvs负责把请求转发给nginx

  这时nginx就解放出来了,不是主、备结构了,而是作为一个层级的结构,可以进行无限横向扩展;

  lvs这里是一个单点,它可以被设计成主、备的结构,一台挂了,另一台接管,但是不能横向扩展。

  注意:lvs不能直接做负载集群,不能说一台不够了,再来一台,做不了负载集群,但是如果负载不够怎么办,它只能抗10到20万的访问量,怎么扩呢?可以一个ip放在一台lvs上,再来一个ip时放到另外一个lvs上边,用这种方式把它进行扩展;

  然后lvs本身的高可用怎么做呢,它做不了高负载,没法扩展它的吞吐量,但是高可用是可以做的,有主、备的结构,一个挂了,另一个接管,就可以了,实际上公司里边的做法,可以做两台lvs互为主、备,4个ip在一边,4个ip在另一边,两台共同提供业务,就做到了高负载,当一台出故障的时候,这个8个ip就可以集中到另外一台lvs上。

  在高可用的集群里边,所有的东西都是负载均衡的,但是如果这不是一个分布式架构,那么在最上层那一点一定会存在一个单点的,就是入口永远会存在一个单点,这个单点一定不能影响它的性能,比如lvs;

  net模式是所有的流量都过它自己,它来做转发,就是你后端ngx所有接来的请求都是从lvs转过来的,这种模式,lvs的压力是最大的,它要承载所有的流量,如果lvs这台机器流量不够的话,它是会被打垮的,所以说一般互联网公司都会用第二种模式:路由模式;

  路由模式就涉及到回环ip(127.0.0.1),路由模式的时候,它的回环地址里会配后端ngx的地址,然后lvs和ngx就会有回环地址的通讯,干啥用呢?就是网络上的包从哪儿来的,还从哪儿回,远程的ie浏览器在访问这个网站的时候,这个包会发给lvs(总入口),lvs通过路由模式把这个包扔给ngx,ngx再找后端服务器,后端服务器响应以后把这个包回给ngx,这个时候ngx和客户的浏览器直接发生通选,不再进过lvs,为什么说路由模式lvs的压力小呢?因为它接收请求包以后,直接分发给后端的ngx,由ngx和客户产生直接的数据关系,只有在头一个包(首包),是过lvs的,其他包都 不过lvs,这时候lvs的压力和负载会特别小,然后这个这时候会用到回环地址,因为网络的包从哪儿来就要从哪儿回,但是ngx回出去的包不再是lvs的ip了,这个时候浏览器会把它的包给扔掉的,因为ip已经不是lvs的ip了,怎么办?这个时候就用到回环地址,ngx回环地址里边配lvs的地址(lvs在回环地址里边也配了ngx的地址),ngx在把这个包发出去的时候,做一次伪装,把自己伪装成lvs的地址,这样客户端就会接受它的包,就会和它通讯,这个时候,lvs只在首包的时候做了一下转发,指定了ngx,所以这个架构里边的核心,就在于lvs用了路由模式,这一套架构中lvs是由中国的一位博士写的,他写这套lvs在全球都在有,可以代替F5(负载均衡的硬件设备)和array,造价方面,单台机器,转发能力在5万的,最少要20万元,是四层转发,现在应该可以7层转发;

  lvs的隧道模式:隧道模式和路由模式类似,区别在于路由模式要求lvs、ngx内网地址要在同一层上,同一个子网里边,但是隧道模式不需要,隧道模式可以跨网,甚至跨广域网去转发,但是垮了3层就不是很稳定,所以在公司里边一般都是用路由模式,跨机房的时候才用到隧道模式,隧道模式和路由模式的工作方式基本是类似的,比较接近,但是更复杂一点,因为要跨广域网,它的ip配置更负载一点。

  至此,lvs作为第一层就不再变化了,第一层始终是主、备的结构,lvs的负载特别小,所有的负载到lvs直接就传给ngx,ngx再往下分发

  所有的web既连master也连slave,连slave只进行读操作,连master只进行写操作,这样把读和写进行分离,这时速度就有一个质的提升

  然后如果一个slave不够的时候,再加一个slave,就解决了这个架构对数据库读的压力,这个时候的网站的并发访问量,理论上可以到万级了

  这个时候要考虑的不只是吞吐量,也要看性能、可靠性,前端已经没有问题了,但是数据库这里有一个单点的问题,后来人们就开始想办法,怎么能保证DB不会出问题呢,后来人们就把DB这块给重构了

  7 在web下面加了一层proxy结构,可以说是转发,也可以说是中间件,这一层结构可以做成集群,这个集群是给数据库做切片的,做成类似于分布式的功能,这一层下来给DB做切片转发,这样DB这一层的库之间就不再有主、从的关系了,都认为是主,挂掉一个,其他的还能正常工作,既做高可用,又做高性能,保证某一台挂掉的时候,另外两台可以做到高可用,如果负载不够的时候,还可以添加

  这个4层结构,可以在很高的性能下,很高的可靠性下做到万级甚至十万级的并发

  这是5年前开始流行的架构,现在的使用率也很高,在对可靠性和性能方面要求不是很高的系统中可以很稳定的应用,但它存在一个问题,就是访问量再大的时候,落库的时候会有一个瓶颈,因为DB不只是做插入和查询,还要做分析和关联,速度会很慢,那怎么办呢?

  8 人们开始在DB层的上边加两个缓存层(读和写),读缓存层是用redis,它也是集群,在业务层下边,DB层的上边,redis从数据库里抽数据,到自己的缓存中,然后提供给业务,只要被缓存命中的数据,读的是特别快的,redis把DB中的热数据提取到缓存层,直接给业务层来用。

  写的话用的是MQ,来实现写的业务,一读一写合起来就大大的提升了并发的处理。

  这个架构中的lvs负责四层转发,nginx做7层转发,4层和7层对应的是osi模型的第四层和第七层,4层转发或7层转发就是对后台服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么转发流量;

  四层就是通过三层的IP地址(虚拟IP),加上四层的端口号,来决定怎样转发流量,七层转发是在四层的基础上,再考虑应用层的特征,比如七层的url、浏览器类别、语言来决定是否要进行负载均衡;

  转发下来后,web做接收,读的时候,热数据从DB里抽到redis里读,就不会因为DB的计算卡着web了,在像双十一这种秒杀的业务,可以把数据提前放到redis里,供web来读,写数据时可以快速的写给mq,之后web就不用管了,用户就可以接着做下一步了,然后mq往DB里一点一点的落库,就是说通过缓存层把高速的web和低速的DB给隔离开,这样给前边的用户体验就会特别好,

  比如双十一之前加购物车,都是提前被写好了放到redis里边,然后下订单都是通过mq来落库,你这边一点刷一下就过去了,你觉得过去了,实际上都在mq里往DB里处理,不可能一下子就落到DB里,目前还没有一家公司能够做到,就算是分布式数据库也不行,分布式数据库只能解决中型的业务场景,解决不了巨型的业务场景,这是这两年很典型的比较火的架构,但是它比不上分布式数据库,这种结构即使很快,如果技术实力不够也只能达到十万级,如果要扩的话,只能是横向的扩,一套一套的往上累加

  lvs,nginx,web这三层不变,下边的缓存层,代理层都没有了,只剩数据库本身了,

  这个DB目前可以撑住10万甚至20万(瞬间的并发写),没有理论上限,各种的复杂的计算在一秒内都可以完成,这就是分布式架构的架构之美,越来越简洁

  它的底层有自己的分布式存储dfs结构,另外有控制节点,还有提供实际计算,运行sql的计算节点,这三部分是没有中心(去中心),可扩展,对称的(坏掉一台、加一台都没问题),可以做到平行的扩展,做到无限制的可行性,也是分布式的目的所在。

  他是怎么做到高速的呢?实际上就是分布式存储和计算的理念,如果有中心的话,需求下来一定是发给一个中心节点上,这个中心就会成为瓶颈,无中心的话,需求下来抛给控制节点,控制节点也没有中心,控制节点接到请求以后告诉它你去哪个计算节点上去,然后计算节点去计算的时候,如果这时所有的数据放到一个dfs上边(存储DB),读写势必会很慢,但是分布式存储它是完全散开的(多个dfs),一个请求过来后是放到所有的计算节点上去算的,然后拿的时候是到所有的dfs上去拿的,这个速度会特别快,这个过程完全都是分布的,所以,这种新型的数据库架构,就可以做到每秒10万个查询、写入、update,也可以做分析,最快可以到每秒10万

  目前能做到千万级别的并发的,有BAT,12360,其他就没有了,这种架构覆盖了当前互联网基本上%95 甚至是99%的需求

  数据在下发的时候,是多副本,挂掉一个机器数据是不会丢失的,它的数据是打散的,这样读的才会快,这个结构出来之后直接干掉缓存层,而且可以支持列式数据库,目前的数据库基本是行式的,列式数据库对那种特别大的数据量支持的特别好

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。