IT培训-高端面授IT培训机构
云和教育:云和数据集团高端IT职业教育品牌 全国咨询热线:0371-67988003
课程 请选择课程
    校区 请选择校区
      • 华为
        授权培训中心
      • 腾讯云
        一级认证培训中心
      • 百度营销大学
        豫陕深授权运营中心
      • Oracle甲骨文
        OAEP中心
      • Microsoft Azure
        微软云合作伙伴
      • Unity公司
        战略合作伙伴
      • 普华基础软件
        战略合作伙伴
      • 新开普(股票代码300248)
        旗下丹诚开普投资
      • 中国互联网百强企业锐之旗
        旗下锐旗资本投资
      当前位置:
      首页IT问答正文

      单体架构的缺点是什么?

      • 发布时间:
        2023-02-23
      • 版权所有:
        云和教育
      • 分享:

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

      传统单体应用架构的问题

      通常我们所使用的传统单体应用架构都是模块化的设计逻辑,程序在编写完成后会被打包并部署为一个具体的应用,而应用的格式则依赖于相应的应用语言和框架。例如,在网上商城系统中,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系统

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

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

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

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

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

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

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

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

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