精华内容
下载资源
问答
  • 单体应用和微服务的介绍 一.单体应用 1.什么的单体应用 ​ 项目所有的资源都在一个应用中,打包成一个war包,使用一个tomcat去运行,运行在一个进程中。 2.单体应用的问题 一个模块挂了,整个项目都受影响 单个...

    单体应用和微服务的介绍

    一.单体应用

    1.什么的单体应用

    ​ 项目所有的资源都在一个应用中,打包成一个war包,使用一个tomcat去运行,运行在一个进程中。

    2.单体应用的问题

    • 一个模块挂了,整个项目都受影响
    • 单个tomcat更能处理的并发有限,可以做集群,但是不方便局部(某一个模块)扩展
    • 维护/开发/升级比较麻烦
    • 代码臃肿,编译,打包都比较慢
    • 技术选型单一
    • 数据库选型单一

    二.微服务架构

    1.什么是微服务架构

    ​ 微服务就是把一个大的系统,拆分成多个小的服务,每个微服务只专注一个业务 ,每个服务有各自的进程, 微服务之间使用网络通信协议进行数据交互(通常是基于HTTP的RESTful API)。

    2.微服务的特点

    • 数据库选型多样化
    • 技术选型多样化
    • 每个微服务专注一个业务
    • 每个维护有自己的进程
    • 微服务之间通过网络协议进行通信
    • 方便做局部拓展
    • 开发/维护/升级更方便

    3.微服务缺点

    • 成本高
    • 技术要求比较高
    • 部署麻烦
    展开全文
  • 单体应用和微服务对比

    千次阅读 2019-03-27 09:26:24
    3 、 单体应用微服务架构优缺点 单体应用有如下优点: 为人所熟知:现有的大部分工具、应用服务器、框架脚本都是这种应用程序; IDE友好:像 NetBeans、Eclipse、IntelliJ 这些开发环境都是针对开发、部署、...

    1 单体应用架构图举例:

    在这里插入图片描述

    2、微服务架构图举例:

    在这里插入图片描述
    微服务,服务调用基本组件:
    服务描述,注册中心,服务框架,服务追踪,服务治理

    3 、 单体应用与微服务架构优缺点

    单体应用有如下优点:

    • 为人所熟知:现有的大部分工具、应用服务器、框架和脚本都是这种应用程序;
    • IDE友好:像 NetBeans、Eclipse、IntelliJ 这些开发环境都是针对开发、部署、调试这样的单个应用而设计的;
    • 便于共享:单个归档文件包含所有功能,便于在团队之间以及不同的部署阶段之间共享;
    • 容易部署:只需将单个归档文件复制到单个目录下。
    • 方便调试,代码都在一起;
    • 没有分布式开销,所有服务都在本地容器内;
    • 中小型项目可以快速迭代,不需要太多资源。

    单体应用的一些不足:

    • 不够灵活:对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序,那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率;
    • 妨碍持续交付:单体应用可能会比较大,构建和部署时间也相应地比较长,不利于频繁部署,阻碍持续交付。在移动应用开发中,这个问题会显得尤为严重;
    • 受技术栈限制:对于这类应用,技术是在开发之前经过慎重评估后选定的,每个团队成员都必须使用相同的开发语言、持久化存储及消息系统,而且要使用类似的工具,无法根据具体的场景做出其它选择;
    • 技术债务:“不坏不修(Not broken,don’t fix)”,这在软件开发中非常常见,单体应用尤其如此。系统设计或写好的代码难以修改,因为应用程序的其它部分可能会以意料之外的方式使用它。随着时间推移、人员更迭,这必然会增加应用程序的技术债务。
    • 代码维护难:代码功能耦合高,新人不知道何从下手,维护比较困难;
    • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断;

    微服务具有如下优点:

    • 单独部署,独立开发,易于开发、扩展、理解和维护;
    • 比单体应用启动快;
    • 复杂性低,局部修改很容易部署,有利于持续集成和持续交付;
    • 故障隔离,一个服务出现问题不会影响整个应用;
    • 不会受限于任何技术栈。
    • 微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面组件混合。
    • 易于和第三方应用系统集成。

    微服务具有如下缺点:

    • 需要分布式事务的支持;
    • 效率相对低,团队依赖强,一个服务的版本延迟会拖慢整个应用的开发周期
    • 开发难度大;垮服务的调用通常是不同的机器,甚至是不同的机房,开发人员需要处理超时、网络异常等问题
    • 分布式系统比单体应用架构复杂,随着服务数量增加,管理复杂性增加,极大地增加运维工作量;
    • 故障诊断比较难,不容易定位错误节点;

    4、单体应用和微服务各适用的业务场景

    单体应用适合场景:

    • 业务场景简单
    • 创业团队,项目初期等场景,需要快速开发迭代

    微服务适合场景:

    • 业务场景复杂,核心业务可以独立
    • 业务量大

    5、业务开发中单体应用过渡膨胀带来的问题

    • 数据量大,散落各处,取值不便
    • 牵一发动全身,迭代艰难

    6、应从哪些角度去进行微服务拆分

    • 纵向拆分:从业务维度进行拆分。拆分标准按照业务的关联程度来决定,关联比较密切的业务适合拆分成为一个微服务,功能相对比较独立的业务适合拆分为一个微服务。
    • 横向拆分:从公共且独立功能的维度进行拆分。拆分标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立,不与其他业务耦合。
    • 服务化拆分的前提条件:
      • 服务如何定义,包括通讯协议,接口描述
      • 服务如何发布和订阅(注册中心)
      • 服务如何监控
      • 服务如何治理
      • 故障如何定位
    展开全文
  • 单体应用和微服务的区别

    千次阅读 2019-04-25 08:31:15
    一、单体应用架构 (一)、单体应用架构概念 一个归档包(可以是JAR、WAR、EAR或其它归档格式)包含所有功能的应用程序,通常称为单体应用。 而架构单体应用的方法论,就是单体应用架构。 (二)、单体架构示意图 ...

    一、单体应用架构

    (一)、单体应用架构概念

    一个归档包(可以是JAR、WAR、EAR或其它归档格式)包含所有功能的应用程序,通常称为单体应用。
    而架构单体应用的方法论,就是单体应用架构。

    (二)、单体架构示意图

    在这里插入图片描述

    (三)、单体应用架构的优缺点

    1. 优点
      便于共享:单个归档文件包含所有功能,便于在团队之间以及不同的部署阶段之间共享。
      易于测试:单体应用一旦部署,所有的服务或特性就都可以使用了,这简化了测试过程,因为没有额外的依赖,每项测试都可以在部署完成后立刻开始。
      易于部署:只需将单个归档文件复制到单个目录下。
    2. 缺点
      复杂性高:由于是单个归档文件,所以整个项目文件包含的模块非常多,导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐,混乱的堆在一起,使得整个项目非常复杂。以致每次修改代码,都非常小心,可能添加一个简单的功能,或者修改一个Bug都会带来隐藏的缺陷。
      技术债务:随着时间的推移、需求的变更和技术人员的更替,会逐渐形成应用程序的技术债务,并且越积越多。
      扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。
      阻碍技术创新:对于单体应用来说,技术是在开发之前经过慎重评估后选定的,每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。

    二、微服务架构

    (一)、微服务架构概念

    微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。

    (二)、微服务架构示意图

    在这里插入图片描述

    (三)、微服务架构的优缺点

    1. 优点
      易于开发和维护:一个微服务只会关注一个特定的业务功能,所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
      单个微服务启动较快
      局部修改容易部署:单体应用只要有修改,就得重新部署整个应用。微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
      技术栈不受限制:在微服务架构中,可以结合项目业务及团队的特点,合理的选择技术栈。
      按需伸缩:可根据需求,实现细粒度的扩展。
    2. 缺点
      运维要求高:更多的服务意味着要投入更多的运维。
      分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的问题。
      接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有用到这个接口的微服务都需要进行调整。
    展开全文
  •  不像单体应用很难实现创新,在微服务的架构下,团队完全可以结合不同成员的优势,不限开发语言数据库,在找到更优的解决方案时,可以使用容器部署的方式来屏蔽这种差异,这种方式需要定义约定好不同模块服务直接...

        最近两年,微服务架构盛行,出现了一些优秀的微服务框架,如SpringCloud等。近来工作需要,接触了部分微服务的内容,和之前的传统开发模式不相同,进行对比,有所感。

        首先是看一张简单总结画的图:

    一.单体应用

        单体应用 - 一个war文件包含所有功能的应用程序包。这种很常见,在电信CRM开发团队待过一段时间,像CRM系统,包含复杂的业务逻辑/自服务接口/定时任务/集团接口等等,都在一个war文件里面。每次发布,都是版本管理员拿到一个大war包,上传到WebSphere,再往几十台服务器上推送。好处是All In One,部署测试比较容易,版本管控比较简单。但是随着时间的推移,越来越多的需求被加到war包中,慢慢地,单体应用变得越来越臃肿,上线后运行五六年,war包就有几百兆,可维护性和灵活性低。参考了《SpringCloud与Docker微服务架构实战》一书,结合实际工作项目经历,下面列出单体应用存在的问题:

        1.复杂性高

        拿上面的CRM系统举例,首先本身包含复杂的业务逻辑,电信的三户模型,各种套餐受理规则,服务接口,定时任务,都在一个项目里面。导致的问题是模块之间变得强耦合,边界模糊,依赖关系不清晰,代码质量参差不齐,最后使得项目变得十分复杂。而且容易有Bug的隐患,如果测试错过一个问题点,上线后可能产生生产故障,影响业务办理。

        2.技术债务

        “为了短期的利益,而做了欠考虑的决定所导致的后果。” 随着时间的推移,需求频繁的变更以及开发人员的更迭,会慢慢形成应用程序的技术债务。作为一个开发人员,也确实做过这样的事情:为了赶紧上线,少做一些测试,简单测试没问题后就匆忙上线。上线之后铁定出问题,因为“出来混,迟早要还的”。出问题后,就会有紧急补丁,这个补丁就是之前的欠下的“债务”。此外,紧急补丁多了后,会影响系统的原有设计,可能导致后面开发的时候很难修改。

        3.部署频率低

        单体应用一般是全量部署,每次需求和功能的上线都是重新部署发布整个应用。相比增量发布,全量部署的方式耗时长,影响范围大同时风险高。在此方式下,部署频率不太可能高。上面举例的CRM系统基本是一个月一个版本。同时部署频率低又会导致存在的Bug可能不会很及时的修复,系统的迭代变更可能跟不上快速变化的市场和需求的变更。

        4.可靠性差

        单体应用,当出现稍微大一点的Bug时候,如内存溢出,死循环,可能导致整个应用崩溃。可能客户正在提交订单,突然当前请求所在的服务器崩溃掉,界面得不到响应,影响客户体验。另外,假如通过F5或者负载均衡通过IP或者其他方式负载的情况下,很有可能出现,即使重新登录,客户的请求最后还是会被路由到宕掉的服务器上面,导致业务不能受理。

        5.扩展能力受限

        单体应用只能作为一个整体扩展,要么是增加单台服务器的内存,要么是增加服务器的数量。所有的模块部署在一起,不能根据业务模块进行伸缩。这样可能会造成不必要的资源浪费。

        6.技术创新难

        单体应用往往使用统一的技术平台或方案解决所有的问题。也就是说,对于开发人员来说,项目的技术选型和开发套路都已经规定好了,圈定在一个范围内。每个成员都必须使用相同的开发语言和框架,要想引入新框架或新技术会非常困难。如一个系统使用的是SSH的有一百多万行代码的单体应用,如果想换成SpringMVC或者SpringBoot,这种切换的成本是很高的。

     

    二.微服务

        什么是微服务?2014年,Martin Fowler与James Lewis共同提出了微服务的概念 - 以开发一组小型服务的方式来开发一个独立的应用系统,每个服务都以一个独立进程的方式运行,每个服务与其他服务使用轻量级(通常是HTTP API)的通信机制。这些服务是围绕业务功能构建的,可以通过全自动部署机制独立部署,同时服务会使用最小规模的集中管理(例如Docker)能力,也可以采用不同的编程语言和数据库。

        微服务与单体应用相比,能够更好的满足互联网时代业务快速变化的需要。下面对比单体应用,列出微服务的部分特性:

        1.业务拆分

        业务拆分,即把一个复杂庞大的业务系统划分为若干模块,拆分出各种服务和中心。《企业IT架构转型之道》的介绍,阿里巴巴中台战略中,把复杂的业务拆分出了几大中心:用户中心,商品中心,交易中心,评价中心等等。不同的中心由不同的团队负责开发维护各自的服务,服务之间的交互定义好,内部想要怎样变更都不会影响外部的使用。前面举例的CRM系统在去年也完成了服务拆分改造,由一个单体应用拆分出了用户中心,订单中心等。

        2.持续试错

        听过一个原则 - 演进式设计原则。在系统开发的过程中,可能会遇到各种问题,加上频繁变更的业务需求。在微服务的架构下,可以采用快速迭代的方式进行架构的演进,在这个过程中可能会出现各种问题,但在微服务的架构下,即使是某个服务遇到问题,发版修复,也不会导致这个应用系统不可用。腾讯有一条重要发展原则就是“小步快跑”。

        3.持续集成部署

        相比之前的单体应用,在微服务的架构在,可能被拆分出来几个模块,如前端模块,系统模块,网关模块,权限模块等。不同的模块由不同的团队开发负责,模块化后,更利于使用一些持续集成的工具来简化和提高我们的系统开发运维效率。常用的有Jenkins,关联到Gitlab,可以实现测试人员一键部署,及时测试和发布修复问题。

        4.分布式高可用

        在微服务架构之前,单体应用往往是中心化的,几十台服务器应用通过集中的Oracle数据库来协同工作。中心化模式存在一个隐患,当位于中心的数据库服务器宕机的时候,整片应用服务器都将不可用,后果将是不可想象的。还有另外一种总线ESB模式也存在这种隐患。在微服务架构下,不同模块服务都是独立运行在不同的服务器上,使用的数据库是分布式数据库,以前的一个数据库,现在可能按照服务划分被拆分成多个分布式数据库,每个数据库还能有主备。此外,加上分布式缓存,分布式消息队列等中间件的使用,大大提高了应用系统的可用性。

        5.独立进程

        前面讲到单体应用的扩展性受限,相反,在微服务下,独立进程的方式灵活性很高。拿现在项目中使用到的SpringCloud举例,每个服务模块都是单独的进程(jar包),有系统服务,网关服务,订单服务,假如在某一时刻,发现某个服务的请求比较大,可以通过临时追加进程数量实例,注册到服务中心,分散请求。这种方式下,相比之前整体扩展,进程级别的伸缩对于服务器系统资源能更好的利用。

        6.结合容器技术

        不像单体应用很难实现创新,在微服务的架构下,团队完全可以结合不同成员的优势,不限开发语言和数据库,在找到更优的解决方案时,可以使用容器部署的方式来屏蔽这种差异,这种方式需要定义约定好不同模块服务直接的交互方式。通过容器封装环境,开发人员可以直接将所有软件和依赖直接封装到容器中,打包成镜像,生产环境直接部署镜像,通过容器实现开发测试生产环境的一致。通过容器调度平台管理容器,资源利用率更高。

     

        想到的就是这些,有点晚了,准备休息。有不对的地方,还望大家指正。

    转载于:https://my.oschina.net/javamaster/blog/2966387

    展开全文
  • Monolith(单体应用)架构的缺点 在项目很小的情况下这种单体应用比较简单,但是随着项目越变越大,代码越来越多。就会存在以下缺点。 ①编译难,部署难,测试难 代码量变多,即使更改一行代码,也需花大量时间...
  • 单体应用&微服务对比

    2019-03-26 21:11:45
    单体应用和微服务各自适用的业务情景? 单体应用: 初创企业 业务逻辑不复杂 部署效率可接收 没有将服务能力抽出通用的需求 微服务: 业务逻辑比较复杂且耦合,导致牵一发而动全身 代码体量过大,导致部署效率...
  • 从扩展性角度出发,类比程序设计,对比单体应用和微服务。并对系统架构进行讲述
  • 单体应用微服务

    2021-03-13 10:13:54
    它将单体应用分解为一组服务。虽然功能总量不变,但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平,而这通过单体代码库很难实现。因此,...
  • 单体应用 vs 微服务架构 优点 提升开发交流,每个服务足够内聚,足够小,代码容易理解; 服务独立测试、部署、升级、发布; 按需定制的DFX,资源利用率,每个服务可以各自进行x扩展z扩展,而且,每个服务可以根据...
  • 写这个博客的目的是记录...由于业务需要,当然也为了更好的推广(更好的吹牛逼),需要把单体应用微服务架构进行演进。 制定项目的演进计划 由于原有系统是部署在windows操作系统上,现在需要从windows系统切换到
  • 单体应用对比微服务

    千次阅读 2017-08-18 21:47:37
    说起微服务,首先要对比的是传统的单体应用单体应用是最早的应用形态,不需要太关注整体性能,项目规模中小型时,开发部署都挺方便。简单谈谈他的优缺点。 单体应用优点: 方便调试,代码都在一起; 没有分布式...
  • 本次讲解单体应用微服务的区别 单体应用是将所有功能模块放在一个单一进程中,并且通过在不同的服务器上面复制这个单体进行扩展。 微服务架构是将每一个功能模块分别放进到一个独立的服务中,并且通过跨服务器...
  • 并讨论了使用微服务架构的优势劣势,接下来的文章讨论微服务架构的不同方面:使用API网关、进程间通信、服务发现、事件驱动的数据管理以及部署微服务,本篇文章,让我们看下如何把一个单体应用重构为微服务架构的...
  • 什么是单体应用?什么是微服务?单体应用的优势劣势,为什么要从单体应用过渡到微服务?本文能解答这些问题.....
  • 并讨论了使用微服务架构的优势劣势,接下来的文章讨论微服务架构的不同方面:使用API网关、进程间通信、服务发现、事件驱动的数据管理以及部署微服务,本篇文章,让我们看下如何把一个单体应用重构为微服务架构的...
  • 原标题:笃学私教:Java开发网站架构演变过程-从单体应用到微服务架构详解Java开发网站架构演变过程,到目前为止,大致分为5个阶段,分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给...
  • Java开发网站架构演变过程,到目前为止,大致分为5个阶段,分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给大家详细介绍下这5种架构模式的发展背景、各自优缺点以及涉及到的一些技术...
  • Java开发网站架构演变过程,到目前为止,大致分为5个阶段,分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给大家详细介绍下这5种架构模式的发展背景、各自优缺点以及涉及到的一些技术...
  • Java开发网站架构演变过程,到目前为止,大致分为5个阶段,分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给大家详细介绍下这5种架构模式的发展背景、各自优缺点以及涉及到的一些技术...
  • 以下问题是笔者在实际开发中遇到的问题,这些问题也都是单体应用时不会考虑到,但是分布式应用的时候就必须要考虑这些问题,解决方案原理后续会整理更新,也希望大家积极回复讨论问题,一起学习。 1、多节点部署...
  • 今天给大家介绍基础架构中的一次 API Gateway 升级过程,这次改造的目的是给微服务铺路,使得我们将来可以更快、更灵活更安全的方式快速迭代。技术的挑战我们最近完成开发了一个新的 API Gateway(网关...
  • 一、单体应用架构概念一个归档包(可以是JAR、WAR、EAR或其它归档格式)包含所有功能的应用程序,通常称为单体应用。而架构单体应用的方法论,就是单体应用架构。二、单体架构示意图三、单体应用架构的优缺点1. 优点...
  • 运行应用软件的目的在于提供某种业务价值。价值通过创建使用业务逻辑来传递,以便它可以为一些用户提供服务。从开始创建业务逻辑到最终交付,为用户提供服务之间的时间称之为时效。提供业务价值的成本等于创建业务...
  • 单体应用架构和微服务架构的区别

    千次阅读 2020-02-01 15:49:39
    一、什么是单体应用架构? 以下是官方给出的解释: 一个归档包(可以是JAR、WAR、EAR或其他归档格式)包含所有功能代码的应用程序,通常称为单体应用。 而单体应用架构的方法论,就是单体应用架构。 简单粗暴理解...
  • 微服务是当下最流行的应用架构技术了,它跟容器服务、DevOps合称云时代的三剑客,可以帮我们化解业务发展过快导致的产品迭代压力,让我们可以自由选择最适合团队的技术栈,让系统能够承载互联网海量用户的访问,让...
  • 一个归档包(可以是JAR、WAR、EAR或其它归档格式)包含所有功能的应用程序,通常称为单体应用。单体架构中,所有的业务模块都编写在一个项目中,最终打成war包运行。 软件设计中,经常提及使用经典的3层模型:...
  • 单体应用微服务改造实践

    千次阅读 2019-05-06 14:26:39
    【摘要】 本文介绍了如何采用一种持续迭代演进的方法将单体应用改造为微服务应用。重点介绍了如何通过自动测试服务网关服务来构造持续迭代演进的基础设施。文末介绍了如何使用CSE更好的完成这个过程。 微服务的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,559
精华内容 1,023
关键字:

单体应用和微服务