成都网站建设设计

将想法与焦点和您一起共享

数据库软件架构演进分析

本篇内容主要讲解“数据库软件架构演进分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“数据库软件架构演进分析”吧!

成都创新互联凭借在网站建设、网站推广领域领先的技术能力和多年的行业经验,为客户提供超值的营销型网站建设服务,我们始终认为:好的营销型网站就是好的业务员。我们已成功为企业单位、个人等客户提供了成都做网站、成都网站建设、成都外贸网站建设服务,以良好的商业信誉,完善的服务及深厚的技术力量处于同行领先地位。

初始阶段架构

应用服务、数据库、文件服务所有资源都放在一台服务器上。 数据库软件架构演进分析

应用服务和数据服务以及文件服务分离架构

随着系统访问量的再度增加,应用服务的机器压力在高峰期会上升到比较高,这时候就开始考虑增加一台应用服务器所以开始把应用服务,数据库,文件服务分布部署在独立的资源上。 数据库软件架构演进分析

使用缓存架构

再随着系统访问特点出现了二八定律,80%的业务访问集中在20%的数据上,这时候需要使用本地缓存数据,远程分布式缓存数据,提高访问数据速度,但是缓存的数据量有限,同时存在与应用服务争用内存的情况。这样数据库中访问较集中的一小部分数据存储在缓存服务器中,建设数据库的访问次数,降低数据库的访问压力。 数据库软件架构演进分析

使用应用服务器集群架构

再之后做完数据库的分库分表后,数据库的压力已经降低了,业务不断成熟又开始每天看访问量暴增,发现用户访问系统越来越慢,这时候就发现数据库压力一切正常,应用服务后台阻塞了很多服务请求,应用服务器对每个请求也是比较快的,原因是请求的数量太高了,导致请求都在排队等待,响应速度变慢了。这样开始使用多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。使用集群解决系统高并发,海量数据问题。通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈。 数据库软件架构演进分析

数据库读写分离架构

系统访问量高速增长后,慢慢发现系统又开始变慢了,发现数据库写入、更新的这些操作部分,数据库连接的资源竞争激烈,导致系统变慢。我们需要引入主备部署。把数据库划分成读库和写库,通过引入主从数据库服务,读和写操作在不同的数据库服务处理,读库可以有多个,通过同步机制把写库的数据同步到读库,对于需要查询最新写入数据场景,可以通过在缓存中多写一份,通过缓存获取最新数据。

反向代理和CDN加速架构

采用cdn和反向代理加速系统的访问速度,为了应付复杂的网络环境和不同地区用户访问,通过CDN和反向代理加快用户访问的速度,通过减轻后端服务器的负载压力。CDN和反向代理都是缓存静态资源。

分布式系统和分布式数据库

随着系统的不断运行,数据量开始大幅度增长,这时候发现分库后查询仍然会有些慢,于是数据库采用分布式,文件系统也采用分布式。因为单一服务都满足不了大型系统用户量和业务持续增长的需求,数据库的读写分离也随着业务发展最终也无法满足需求,需要使用分布式数据库以及分布式文件系统来支撑。常见数据库拆分手段是业务分库,根据不同的业务部署在不同的服务器上。

NoSql数据库和搜索引擎架构

随着业务越来越复杂,对数据存储和检索的需求也越来越复杂,系统需要采用一些非关系型数据库(NOSQL,搜索引擎)来实现。应用服务通过统一数据访问模块访问各种数据,减轻应用服务管理诸多数据源的麻烦。

业务拆分

系统按照业务进行拆分改造,应用服务器按照业务区分进行分别部署。为了应用日益复杂的业务场景,通常使用分而治之的手段将整个系统业务分厂不同的产品线,应用之间通过连接建立关系,也可以通过消息进行数据分发,通过访问同一个数据存储来构建一个关联的完整系统。通过纵向拆分应用服务,将一个大应用拆分为多个小应用,如果新的业务较为独立,那么就直接将其设计部署为一个独立的web应用系统,通过梳理业务,将较少相关的业务剥离出来即可。通过横向拆分,将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务,需要识别出可以复用的业务,设计服务接口,规范服务依赖关系。

分布式服务

公共的应用模块被提取出来,部署在分布式服务器上供应用服务调用。随着业务越拆越小,应用系统整体复杂程度指数级别上升,由于所有应用要和所有的数据库连接,最终导致数据库连接资源又不足了,拒绝服务访问。当服务越来越多,服务URL配置管理变得非常困难,负载均衡器的单节点压力越来越大。

当进一步发展,服务间依赖关系变得错中复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师也不能完整描述应用的架构关系。 服务的调用量越来越大,服务的容量问题暴露,每个服务需要多少台机器支撑,什么时候应该加机器。 服务多了,沟通成本也开始上升,调用某个服务失败该找谁,服务的参数都有什么约定。 一个服务有多个业务消费者,如果确保服务质量,随着服务的不停升级,总有些意想不到的事情发生,比如cache写错了导致内存溢出,故障不可避免,每次核心服务一挂,影响一大片,如何控制故障的影响面,服务是否可以功能降级或者资源劣化。针对以上问题,微服务架构可以一定程度解决。

到此,相信大家对“数据库软件架构演进分析”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!


本文名称:数据库软件架构演进分析
转载来源:http://chengdu.cdxwcx.cn/article/gghced.html