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