您好,登录后才能下订单哦!
本篇内容主要讲解“数据库软件架构演进分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“数据库软件架构演进分析”吧!
应用服务、数据库、文件服务所有资源都放在一台服务器上。
随着系统访问量的再度增加,应用服务的机器压力在高峰期会上升到比较高,这时候就开始考虑增加一台应用服务器所以开始把应用服务,数据库,文件服务分布部署在独立的资源上。
再随着系统访问特点出现了二八定律,80%的业务访问集中在20%的数据上,这时候需要使用本地缓存数据,远程分布式缓存数据,提高访问数据速度,但是缓存的数据量有限,同时存在与应用服务争用内存的情况。这样数据库中访问较集中的一小部分数据存储在缓存服务器中,建设数据库的访问次数,降低数据库的访问压力。
再之后做完数据库的分库分表后,数据库的压力已经降低了,业务不断成熟又开始每天看访问量暴增,发现用户访问系统越来越慢,这时候就发现数据库压力一切正常,应用服务后台阻塞了很多服务请求,应用服务器对每个请求也是比较快的,原因是请求的数量太高了,导致请求都在排队等待,响应速度变慢了。这样开始使用多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。使用集群解决系统高并发,海量数据问题。通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈。
系统访问量高速增长后,慢慢发现系统又开始变慢了,发现数据库写入、更新的这些操作部分,数据库连接的资源竞争激烈,导致系统变慢。我们需要引入主备部署。把数据库划分成读库和写库,通过引入主从数据库服务,读和写操作在不同的数据库服务处理,读库可以有多个,通过同步机制把写库的数据同步到读库,对于需要查询最新写入数据场景,可以通过在缓存中多写一份,通过缓存获取最新数据。
采用CDN和反向代理加速系统的访问速度,为了应付复杂的网络环境和不同地区用户访问,通过CDN和反向代理加快用户访问的速度,通过减轻后端服务器的负载压力。CDN和反向代理都是缓存静态资源。
随着系统的不断运行,数据量开始大幅度增长,这时候发现分库后查询仍然会有些慢,于是数据库采用分布式,文件系统也采用分布式。因为单一服务都满足不了大型系统用户量和业务持续增长的需求,数据库的读写分离也随着业务发展最终也无法满足需求,需要使用分布式数据库以及分布式文件系统来支撑。常见数据库拆分手段是业务分库,根据不同的业务部署在不同的服务器上。
随着业务越来越复杂,对数据存储和检索的需求也越来越复杂,系统需要采用一些非关系型数据库(NOSQL,搜索引擎)来实现。应用服务通过统一数据访问模块访问各种数据,减轻应用服务管理诸多数据源的麻烦。
系统按照业务进行拆分改造,应用服务器按照业务区分进行分别部署。为了应用日益复杂的业务场景,通常使用分而治之的手段将整个系统业务分厂不同的产品线,应用之间通过连接建立关系,也可以通过消息进行数据分发,通过访问同一个数据存储来构建一个关联的完整系统。通过纵向拆分应用服务,将一个大应用拆分为多个小应用,如果新的业务较为独立,那么就直接将其设计部署为一个独立的web应用系统,通过梳理业务,将较少相关的业务剥离出来即可。通过横向拆分,将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务,需要识别出可以复用的业务,设计服务接口,规范服务依赖关系。
公共的应用模块被提取出来,部署在分布式服务器上供应用服务调用。随着业务越拆越小,应用系统整体复杂程度指数级别上升,由于所有应用要和所有的数据库连接,最终导致数据库连接资源又不足了,拒绝服务访问。当服务越来越多,服务URL配置管理变得非常困难,负载均衡器的单节点压力越来越大。
当进一步发展,服务间依赖关系变得错中复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师也不能完整描述应用的架构关系。 服务的调用量越来越大,服务的容量问题暴露,每个服务需要多少台机器支撑,什么时候应该加机器。 服务多了,沟通成本也开始上升,调用某个服务失败该找谁,服务的参数都有什么约定。 一个服务有多个业务消费者,如果确保服务质量,随着服务的不停升级,总有些意想不到的事情发生,比如cache写错了导致内存溢出,故障不可避免,每次核心服务一挂,影响一大片,如何控制故障的影响面,服务是否可以功能降级或者资源劣化。针对以上问题,微服务架构可以一定程度解决。
到此,相信大家对“数据库软件架构演进分析”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。