浅谈一下单体架构的缺点是什么

随着互联网技术的发展，传统的应用架构已满足不了实际需求，微服务架构就随之产生。那么传统应用架构到底出了什么问题呢?又如何解决?接下来我们将从传统单体架构的问题开始，对为什么需要微服务架构进行详细讲解。

传统单体应用架构的问题

通常我们所使用的传统单体应用架构都是模块化的设计逻辑，程序在编写完成后会被打包并部署为一个具体的应用，而应用的格式则依赖于相应的应用语言和框架。

例如，在网上商城系统中，JavaWeb工程通常会被打成WA R包部署在Web服务器上，而普通Java工程会以JAR包的形式包含在WA R包中，如图1-1所示。

早期单体架构图

上图中的这种应用开发风格很常见，它易于开发和调试，并且易于部署。在用户量不多时，此种架构方式完全可以满足需求，但随着用户人数的增加，一台机器已经满足不了系统的负载，此时我们就会考虑系统的水平扩展。通常情况下，我们只需要增加服务器的数量，并将打包好的应用拷贝到不同服务器(如Tomcat)，然后通过负载均衡器(如Apache、Nginx)就可以轻松实现应用的水平扩展，如图所示。

在早期，单体架构的这种扩展方式可以很好的满足使用需求，但随着时间的推移，这种方式就会产生很多问题，具体表现如下：

1.应用复杂度增加，更新、维护困难

一个简单的应用会随着时间的推移而逐渐变大。一旦应用变的庞大而又复杂，那么开发团队将会面临很多问题，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都很难进行二次开发或维护。

2.易造成系统资源浪费

虽然使用负载均衡的方式可以对项目中的服务容量进行水平扩展，但由于传统单体架构的代码中只有一个包含所有功能的WA R包，所以在对服务容量扩容时，只能选择重复的部署这个WA R包来扩展服务能力，而不仅仅是扩展了所需的服务。这样导致其他不需要扩展的服务也进行了相应的扩展，但这种扩展是不需要的，因此这种方式会极大的浪费资源。

3.影响开发效率

当一个应用越大时，启动时间就会越长。开发和调试的过程中，如果有很大一部分时间都要在等待中渡过，那么必然会对开发效率有极大的影响。

4.应用可靠性低

传统单体应用架构在运行时的可靠性比较低，当所有模块都运行在一个进程中时，如果任何一个模块中出现了一个Bug，可能会导致整个进程崩溃，从而影响到整个应用。

5.不利于技术的更新

传统单体应用架构一旦选定使用某些技术，则后期的开发和扩展将在这些技术的基础上实现。如果需要更改某种技术，则可能需要将整个应用全部重新开发，这种成本是非常大的。当然，传统单体应用架构的问题还不只这些，但出现这些问题的根本原因可以说就是由于传统单体架构中一个WA R包内包含了系统的所有服务功能所导致的。随着业务变的越来越多，问题也就越来越多。

如何解决传统应用架构的问题

针对传统单体架构的问题，大部分企业通过SOA(Service-Oriented Architecture，面向服务的架构)来解决上述问题。

SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去，因此基于SOA架构的应用可以理解为一批服务的组合。

同样以网上商城为例，一个简单的SOA系统如图1-3所示。

SOA系统

从上图可以看出，SOA将原来的单体架构按照功能细分为不同的子系统，然后再由各个子系统依赖服务中间件(这里指企业服务总线Enterprise Service Bus，简称ESB)来调用所需服务。

使用SOA可以将系统切分成多个组件服务，这种通过多个组件服务来完成请求的方式有很多好处，具体如下：

l把项目拆分成若干个子项目，不同的团队可以负责不同的子项目，从而提高开发效率;

l把模块拆分，使用接口通信，降低了模块之间的耦合度;

l为企业的现有资源带来了更好的重用性;l能够在最新的和现有的应用之上创建应用;

l能够使客户或服务消费者免予服务实现的改变所带来的影响;

l能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。

虽然使用SOA解决了单体架构中的问题，但多数情况下，SOA中相互独立的服务仍然会部署在同一个运行环境中(类似于一个Tomcat实例下，运行了很多web应用)。和单体架构类似，随着业务功能的增多，SOA的服务会变得越来越复杂。本质上看，单体架构的问题并没有因为使用SOA而变的更好。

针对单体架构和SOA的问题，许多公司(如Amazon、eBay和NetFlix)通过采用微处理结构模式解决了系统架构中的问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。随着微服务的使用，微服务架构的思想也随之产生。

到此这篇关于浅谈一下单体架构的缺点是什么的文章就介绍到这了,更多相关单体架构的缺点内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • Java架构设计之六步拆解 DDD

    Java架构设计之六步拆解 DDD

    目录 引言 项目需求信息 DDD落地实践 战略设计 1.业务分析 (1)事前准备 (2)邀请参会的人 (3)业务讨论 2.领域建模 (1)领域对象分析 (2)构建业务聚合 3.划分边界上下文 战术设计 1.微服务拆分 2.领域分层 3.代码结构 总结 引言 相信通过前面几篇文章的介绍,大家对于 DDD 的相关理论以及实践的套路有了一定的理解,但是理解 DDD 理论和实践手段是一回事,能不能把这些理论知识实际应用到我们实际工作中又是另外一回事,因此本文通过实际的业务分析把之前文章中涉及的理论和手段

  • java同步器AQS架构AbstractQueuedSynchronizer原理解析

    java同步器AQS架构AbstractQueuedSynchronizer原理解析

    目录 引导语 1.整体架构 1.1.类注释 1.2.类定义 1.3.基本属性 1.3.1.简单属性 1.3.2.同步队列属性 1.3.3.条件队列的属性 1.3.4.Node 1.3.5.共享锁和排它锁的区别 1.4.Condition 2.同步器的状态 3.获取锁 3.1.acquire排它锁 3.1.1.addWaiter 3.1.2.acquireQueued 3.2.acquireShared获取共享锁 4.总结 引导语 AbstractQueuedSynchronizer 中文翻译叫做

  • Java Rabbitmq中四种集群架构的区别详解

    Java Rabbitmq中四种集群架构的区别详解

    目录 主备模式 远程模式 镜像模式 多活模式 Federation插件 总结 Rabbitmq 四种集群架构 1. 主备模式 2. 远程模式3. 镜像模式  4. 多活模式 主备模式 主备模式: warren 兔子窝 一个主.一个备方案 主节点如果挂了 从节点提供服务 和Activemq 利用zk 做主/备一样 主备模式 ----------------------->HaProxy 配置 listen rabbitmq_cluster bind 0.0.0.0:5682 # 配置tcp 模式

  • Java Mybatis架构设计深入了解

    Java Mybatis架构设计深入了解

    目录 架构设计 Mybatis主要构件 Mybatis缓存 总结: 架构设计 我们可以把Mybatis的功能架构分为三层: 1.API接口层:提供给外部使用的接口API,开发人员通过这些本地API来操纵数据库.接口层一接收到调用请求就会调用数据处理层来完成具体的数据处理. Mybatis和数据库的交互有两种方式: 使用传统的Mybatis提供API 使用Mapper代理的方式 2.数据处理层:负责具体的SQL查找.SQL解析.SQL执行和执行结果映射处理等.他主要的目的是根据调用的请求完成一次数

  • Java架构师的5大基本能力你知道吗

    Java架构师的5大基本能力你知道吗

    目录 业务架构师与基础架构师区别 如何做技术选型? 总结 总体而言,架构师负责软件领域的顶层设计.架构师需要根据公司的发展,规划企业未来若干年的架构,制定可落地的架构方案,解决技术难题,做技术选型与攻关,落地具体的架构.优秀的架构师既能做架构方案,也能写具体的架构代码. 架构师要求比较高,要有架构的广度.深度,需要掌握一系列的架构技术栈,要求有架构实战经验,要有很强的系统分析.系统架构.系统设计,业务分析的能力 首先要有架构师的思维,对分布式.高并发.高性能.高可用.可扩展.松耦合.高内聚.可复

  • 浅谈一下单体架构的缺点是什么

    随着互联网技术的发展,传统的应用架构已满足不了实际需求,微服务架构就随之产生.那么传统应用架构到底出了什么问题呢?又如何解决?接下来我们将从传统单体架构的问题开始,对为什么需要微服务架构进行详细讲解. 传统单体应用架构的问题 通常我们所使用的传统单体应用架构都是模块化的设计逻辑,程序在编写完成后会被打包并部署为一个具体的应用,而应用的格式则依赖于相应的应用语言和框架. 例如,在网上商城系统中,JavaWeb工程通常会被打成WA R包部署在Web服务器上,而普通Java工程会以JAR包的形式包含在

  • 浅谈Java开发架构之领域驱动设计DDD落地

    浅谈Java开发架构之领域驱动设计DDD落地

    目录 一.前言 二.开发目标 三.服务架构 3.1.应用层{application} 3.2.领域层{domain} 3.3.基础层{infrastructrue} 3.4.接口层{interfaces} 四.开发环境 五.代码示例 六.综上总结 一.前言 整个过程大概是这样的,开发团队和领域专家一起通过 通用语言(Ubiquitous Language)去理解和消化领域知识,从领域知识中提取和划分为一个一个的子领域(核心子域,通用子域,支撑子域),并在子领域上建立模型,再重复以上步骤,这样周而

  • 浅谈Java分布式架构下如何实现分布式锁

    01分布式锁运用场景 互联网秒杀,抢优惠卷,接口幂等性校验.咱们以互联网秒杀为例. @RestController @Slf4j publicclassIndexController{ @Autowired privateRedissonredission; @Autowired privateStringRedisTemplatestringRedisTemplate; @RequestMapping("/deduct_stock") publicStringdeductStock(

  • 浅谈架构模式变迁之从分层架构到微服务架构

    浅谈架构模式变迁之从分层架构到微服务架构

    前言 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design pattern),对应到架构层面,则有所谓的架构模式(architecture pattern).它们分别从微观和宏观的角度指导着我们设计出良好的软件系统,因此,作为一个软件工程师,我们不仅要熟悉设计模式,对常见的架构模式也要熟稔于心.正如看到一个设计模式的名字脑里就能浮现出大致的结构图,当我们看到一个架构模式的名字时,也要马上想到对应的架构图及其基本特点.比如,当谈到分层架构时,我们就应该想起它的架构图是怎样

  • 浅谈Redis高并发缓存架构性能优化实战

    浅谈Redis高并发缓存架构性能优化实战

    目录 场景1: 中小型公司Redis缓存架构以及线上问题实战 场景2: 大厂线上大规模商品缓存数据冷热分离实战 场景3: 基于DCL机制解决热点缓存并发重建问题实战 场景4: 突发性热点缓存重建导致系统压力暴增 场景5: 解决大规模缓存击穿导致线上数据库压力暴增 场景6: 黑客工资导致缓存穿透线上数据库宕机 场景7: 大V直播带货导致线上商品系统崩溃原因分析 场景8: Redis分布式锁解决缓存与数据库双写不一致问题实战 场景9: 大促压力暴增导致分布式锁串行争用问题优化 场景10: 利用多级缓

  • 浅谈服务发现和负载均衡的来龙去脉

    浅谈服务发现和负载均衡的来龙去脉

    问题缘由 随着时代发展,单机程序遇到了计算力和存储的双重瓶颈,分布式架构应运而生.单体应用通过函数名(标识)便可轻松完成本地函数调用,在分布式系统中,服务(RPC/RESTful API)承担了类似的角色,但请求服务单靠服务名还不够,服务名只是服务能力(服务类型)的标识,还需要指示服务位于网络何处,而部署在云中的服务实例IP是动态分配的,扩缩容.失败和更新则让问题变得更加复杂,静态配置服务实例适应不了新变化,需要更精细化的服务治理能力,为了解决或者说简化这个问题,服务发现作为一种基础能力被抽象和

  • 浅谈php常用的7大框架的优缺点

    一直以来,phper讨论最多的就是php各种框架的优缺点,网上的资料也是比较零散,现把几款主流的框架收集汇总一下,其中本人只是用过Yii2.Laravel.Yaf.Thinkphp这四种框架,因此大部分对各种框架的评价皆来自与网上资料,如果问题,请在评论中指出,共同进步 一.ThinkPHP ThinkPHP(FCS)是一个轻量级的中型框架,是从Java的Struts结构移植过来的中文PHP开发框架.它使用面向对象的开发结构和MVC模式,并且模拟实现了Struts的标签库,各方面都比较人性化,熟

  • [Asp.Net Core] 浅谈Blazor Server Side

    在2016年, 本人就开始了一个内部项目, 其特点就是用C#构建DOM树, 然后把DOM同步到浏览器中显示. 并且在一些小工程中使用. 3年下来, 效果很不错, 但因为是使用C#来构建控件树, 在没有特定语法的情况下, 代码风格不是那么好. 典型的风格大概是这样的: 这个模式挺好的, 有点嫌弃C#代码占比太高, HTML代码靠字符串来完成, 在界面的设计上, 比较吃力. 在2019年秋, Asp.Net 3.0出来了, Blazor Server Side 也正式公布, 可以在VS2019中使用

  • 浅谈Redis哨兵模式的使用

    浅谈Redis哨兵模式的使用

    概述 主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工 干预,费事费力,还会造成一段时间内服务不可用.这不是一种推荐的方式,更多时候,我们优先考虑 哨兵模式.Redis从2.8开始正式提供了Sentinel(哨兵) 架构来解决这个问题. 谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库. 哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独 立运行.其原理是哨兵通过发送命令,

  • 浅谈我是如何用redis做实时订阅推送的

    浅谈我是如何用redis做实时订阅推送的

    前阵子开发了公司领劵中心的项目,这个项目是以redis作为关键技术落地的. 先说一下领劵中心的项目吧,这个项目就类似京东app的领劵中心,当然图是截取京东的,公司的就不截了... 其中有一个功能叫做领劵的订阅推送.什么是领劵的订阅推送?就是用户订阅了该劵的推送,在可领取前的一分钟就要把提醒信息推送到用户的app中.本来这个订阅功能应该是消息中心那边做的,但他们说这个短时间内做不了.所以让我这个负责优惠劵的做了-.-!.具体方案就是到具体的推送时间点了,coupon系统调用消息中心的推送接口,把信

随机推荐