week4- 典型大型互联网应用系统使用技术方案和手段

用户头像
暖丶冬
关注
发布于: 2020 年 07 月 01 日

前言

典型的大型互联网应用系统,通常需要应对大流量、高并发的网络请求,并满足高可用、高性能、低延迟、可伸缩、易扩展等特性。为了达到目标,分布式、分层、分割等技术方案应运而生,并结合缓存、异步、分库分表、读写分离、分布式缓存等手段来针对性的解决实际问题。



1.高并发

高并发是因系统用户访问而客观存在的问题,解决高并发的问题一般有两种方案:

  • 垂直伸缩:通过升级硬件和网络吞吐来提升系统支持高并发的能力。

优点:能够相对快速的完成支持高并发的能力。在一定规模下耗费的成本也相对低。

缺点:无论硬件配置多么高,对于大规模的并发来说有时候都是无法满足的。



  • 水平伸缩:通过添加服务器提升系统支持高并发的能力。

优点:能够通过添加服务器数量满足大规模并发的场景。

缺点:扩展速度慢,往往都需要架构重构,重新开发来实现,无法满足应急的情况。



常见的技术方案



前端

  • CDN:将用户访问的数据(静态页面和图片之类的)放置到离用户更近的地方,减少网络访问时间,从 而提供访问的效率。

  • 动静分离:将静态资源与动态数据分开在不同的服务器来处理,从而达到提高性能的目的。同时静态资源也方便使用缓存来处理。



异步

互联网场景下,有大量使用分布式消息队列--MQ做异步的场景。常见的MQ有kafka,RocketMQ,RabbitMQ等等。使用MQ可以实现异步,削峰,解耦,限速等功能。



分布式服务

互联网迭代发布的节奏非常频繁,业务逻辑一般比较复杂。这种情况势必要把一个超大的单体应用就行服务拆分,按一定的原则拆分成多个功能相对独立并且逻辑比较单一的子系统,比如:登录,订单,资料,购物车等等,每个子系统单独部署自己的机器,方便后续的维护和扩展。



集群

服务拆分以后,单台机器可能还是挡不住所有请求。基于高性能和高可用方面考虑,需要把服务进行集群化部署后才能对外服务。



负载均衡

互联网场景下,所有对外提供服务的模块都是集群化部署的,此时,每台机器如何进行请求分配,就是负载均衡器所需要解决的问题了。典型的负载均衡有:dns轮询,F5,LVS,nginx负载均衡等等。



NoSQL数据库

典型的NoSQL有Redis,Memcached等key-value型数据库。和传统的关系型数据库不一样的是:NoSQL对事务性和一致性方面支持比较差,但换来的是极高的性能。



搜索引擎

对于那种商品搜索,订单搜索的场景,数据库like语句的性能表现不佳,此时引入专业的基于倒排索引的搜索引擎比如:ES,solr等可以极大地提升搜索性能和搜索质量。



读写分离

因为互联网大多数场景是读多写少,使用缓存基本可以减少90%以上的db请求。但是缓存一般是有过期时间的,甚至有可能存在缓存穿透的问题。这种场景下打到db的读请求可能还是很多,对数据库造成非常大的压力。于是就可以采用这种读写分离的方案,根据实际数据库的读量,搭建一主一从或者一主多从等。



分库分表

主要是解决关系型数据库在互联网场景下的海量数据以及高并发写入的问题。其中分表解决单表数据量过大后导致查询速度变慢的问题,而分库主要是解决单库在高并发写入的情况下扛不住的问题。常见的分库分表方案有:mycat,shardingJDBC和应用层分库分表。



限流

互联网经常有各种诸如秒杀类的热点,引发大量的突增请求。此时为了防止服务突然过载后雪崩,一般会引入一些限流的组件,常见的限流算法有简单计数器法,窗口计数法,漏桶算法,令牌桶算法等,各有优势。



分布式锁

服务集群化部署以后,以往的单机进程内锁可能就要改成分布式锁了。常见的分布式锁有redis分布式锁,zookeeper分布式锁等等。



安全和运维

  • 数据采集

  • 数据监控

  • 攻击与防护

  • 加密和解密



用户头像

暖丶冬

关注

还未添加个人签名 2018.11.09 加入

还未添加个人简介

评论

发布
暂无评论
week4-典型大型互联网应用系统使用技术方案和手段