互联网架构的演进历程

KaKaa__

已于 2022-11-12 13:51:09 修改

阅读量577

点赞数

文章标签：缓存架构 java 服务器数据库

于 2022-11-10 23:59:04 首次发布

本文链接：https://blog.csdn.net/KaKaa__/article/details/127798160

版权

今天来讲讲互联网架构方面的知识.

1.单体架构

在互联网应用的初期,互联网用户相对较少,可以把web服务器和数据库同时部署在一台服务器上.

而在该架构下,一个程序的实现的所有功能模块都被放在了一个web服务器中.

优点:

1.只需要将所有要实现的业务功能都放到这个服务器即可,更加方便开发.

2.测试时只需要将整体进行测试即可.

3.维护服务器时,只需要维护这个服务器中的业务代码,方便查找问题所在.

缺点:

随着用户数的不断增长,所有用户都是对同一个web服务器进行访问,使得服务器所承受的并发压力不断增大,同时Tomcat和数据库之间又要抢占计算机的资源,形成一种竞争现象,使得单服务器的性能越来越差,使得只能适用于小型项目.系统可靠性差,计算能力有限,存储能力有限.

应用场景:

1.数据规模小

2.使用系统的用户量小

3.业务复杂度比较低

技术栈:

1.过去服务端技术:jsp+servlet+javabean或springframework+spring mvc+mybatis/hibernate

2.过去客户端技术:html+css+js+jquery

2.现在服务端技术:springframework+spring mvc+mybatis+springboot

3现在客户端技术:html+css+js+vue

2.Web服务器和数据库服务器分离

由于单体架构Tomcat和数据库会产生竞争现象,因此将Tomcat和数据库服务器分别独立部署,显著的提高了两者的性能,这种系统可称为分布式系统..

但是,虽然解决了竞争现象,还是会因为用户数的增长,并发读写数据库的需求会越来越多,此时数据库就会因为连接数的限制,使得其他用户再次连接会被阻塞,且在读写数据库时频繁的读写硬盘数据,使得系统性能也变得非常差,并发读写数据库成为了瓶颈.

3.本地缓存和分布式缓存应用

为了降低数据库的访问压力,可以采用缓存(cache)的方式.例如，在Tomcat服务器上增加本地缓存，并在外部增加分布式缓存，缓存一些相对热门的数据（热门商品信息或热门商品的html页面等).通过缓存把绝大多数请求在读写数据库前拦截掉，这样降低数据库的访问频次,读写压力.提高请求响应速度.

在引入缓存以后，在一定程度上改善了性能，但也会带来一些问题,例如缓存一致性、缓存穿透/击穿、缓存雪崩等问题.

缓存一致性:数据库与缓存是不同的组件，操作必须有先后顺序，因此会出现数据在缓存中与在数据库中不一致的问题.

缓存穿透:指用户查询数据，在数据库没有，那么自然在缓存中也不会有。这样就导致用户查询的时候,在缓存中找不到,每次都要去数据库再查询一遍,然后返回空(相当于进行了两次无用的查询).这样请求就绕过缓存直接查数据库.

缓存雪崩:由于原有缓存失效,新缓存未到期间 (例如:我们设置缓存时采用了相同的过期时间,在同一时刻出现大面积的缓存过期),所有原本应该访问缓存的请求都去查询数据库了,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机。从而形成一系列连锁反应,造成整个系统崩溃.

4.服务冗余和NGINX负载均衡

Nginx代理的是谁？(服务端的服务器)
- web服务器(例如TOMCAT)

Nginx代理的作用什么？(请求转发,负载均衡)
- NGINX的负载均衡:在访问量较多的时候，可以通过负载均衡，将多个请求分摊到多台服务器上，相当于把一台服务器需要承担的负载量交给多台服务器处理，进而提高系统的吞吐率；另外如果其中某一台服务器宕机，其他服务器还可以正常提供服务，以此来提高系统的可伸缩性与可靠性.
- NIGINX的请负载均衡三大策略:
  - 1).轮询
    - 以循环方式分发对应用服务器的请求，将请求平均分发到每台服务器上。
  - 2).最少连接
    - 轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果，适合请求处理时间长短不一造成服务器过载的情况。
  - 3). ip hash
    - 这个方法确保了相同的客户端的请求一直发送到相同的服务器，这样每个访客都固定访问一个后端服务器。如用户需要分片上传文件到服务器下，然后再由服务器将分片合并，这时如果用户的请求到达了不同的服务器，那么分片将存储于不同的服务器目录中，导致无法将分片合并，该场景则需要使用ip hash策略。
这种架构下Web服务器多了，可以承载的并发也大了，并发多了请求的类型也就多了，此时可能就会有大量的请求击穿缓存去访问数据库，数据库的压力就会巨增，那如何解决这个问题呢？

5.数据库读写分离

把数据库划分为读库(从库)和写库(主库)，读库可以有多个，通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据(因为比如在电商平台,买东西总是浏览的多,而下订单的少)。

解决方案:数据库中间件Mycat,支持数据库读写分离的中间件.可通过它来组织数据库的分离读写和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。当业务逐渐变多，出现不同业务之间的访问量差距较大，不同业务直接竞争数据库，且性能会逐步降低。

6.按业务进行分库

把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑,数据库写服务器通过binlog形式同步到数据库的读服务器.

这样同时导致跨业务的表无法直接做关联分析(每个业务所属不同的数据库,跨库关联很难)，对于这种方案，随着用户数的增长，单机的写库会逐渐会达到性能瓶颈。

7.大表拆小表

比如针对评论数据，可按照商品ID进行hash(按hash值进行分表)，路由到对应的表中存储；针对支付记录，可按照小时创建表(按时间分表)，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。(可以使用shardingsphere.)

这种做法显著的增加了数据库运维的难度，对DBA的要求较高。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈。

8.LVS或F5让多个Nginx负载均衡

由于瓶颈在Nginx，因此无法通过两层的Nginx来实现多个Nginx的负载均衡,处理几十万的并发,此时采用LVS和F5作为网络负载均衡解决方案，如图所示：

其中LVS是软件，运行在操作系统内核态，可对TCP请求或更高层级的网络协议进行转发，因此支持的协议更丰富，并且性能也远高于Nginx，可假设单机的LVS可支持几十万个并发的请求转发；F5是一种负载均衡硬件，与LVS提供的能力类似，性能比LVS更高，但价格昂贵。由于LVS是单机版的软件，若LVS所在服务器宕机则会导致整个后端系统都无法访问，因此需要有备用节点。采用主备架构,可使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台LVS服务器上，浏览器访问虚拟IP时，会被路由器重定向到真实的LVS服务器，当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，把虚拟IP重定向到另外一台正常的LVS服务器，从而达到LVS服务器高可用的效果。此种方案中，由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同。

9.DNS轮询实现机房的负载均衡

在主流大城市部署LVS服务器,将数据同步到不同地方的机房.在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问 www.taobao.com时， DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题.

随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求.