精华内容
下载资源
问答
  • 单体应用&微服务对比

    2019-03-26 21:11:45
    单体应用微服务各自适用的业务情景?...我们在业务开发过程中遇到过哪些因单体应用过度膨胀带来的问题?微服务是否能解决这些问题? CRM中存在较多业务模块,各业务互相耦合,导致开发效率较低...
    1. 单体应用和微服务各自适用的业务情景?
      1. 单体应用:
        • 初创企业
        • 业务逻辑不复杂
        • 部署效率可接收
        • 没有将服务能力抽出通用的需求
      2. 微服务:
        • 业务逻辑比较复杂且耦合,导致牵一发而动全身
        • 代码体量过大,导致部署效率很低
        • 需要提供通用的服务能力
    2. 我们在业务开发过程中遇到过哪些因单体应用过度膨胀带来的问题?微服务是否能解决这些问题?
      • CRM中存在较多业务模块,各业务互相耦合,导致开发效率较低,且容易造成风险;微服务可以解决这些问题,但性价比太低。
    3. 如何进行服务拆分?
      • 遵循“单一职责原则”
    4. 单体应用&微服务架构图
      在这里插入图片描述
    展开全文
  • 单体应用微服务对比

    千次阅读 2019-03-27 09:26:24
    单体应用适合场景: 1 单体应用架构图: 2、微服务架构图 微服务,服务调用基本组件: 服务描述,注册中心,服务框架,服务追踪,服务治理 3 、 单体应用微服务架构优缺点 单体应用有如下优点: 为人所熟知:...

    1 单体应用架构图举例:

    在这里插入图片描述

    2、微服务架构图举例:

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

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

    单体应用有如下优点:

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

    单体应用的一些不足:

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

    微服务具有如下优点:

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

    微服务具有如下缺点:

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

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

    单体应用适合场景:

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

    微服务适合场景:

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

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

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

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

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

    千次阅读 2019-08-10 07:17:46
    随着互联网应用的发展,在敏捷快速迭代、高可用、高性能、高并发等方面要求越来越高,传统的SOA分布式架构并不适合这种场景,互联网最新流行且最佳的实践方式就是微服务化。 而微服务的首要问题是微服务如何拆分。...

    1 介绍引入

    • 随着互联网应用的发展,在敏捷快速迭代、高可用、高性能、高并发等方面要求越来越高,传统的SOA分布式架构并不适合这种场景,互联网最新流行且最佳的实践方式就是微服务化。

    • 而微服务的首要问题是微服务如何拆分。现在很多的微服务开发团队在设计和实现微服务的时候觉得只要把原来的单体拆小,就是微服务了。但是这不一定是正确的微服务,可能只是一个拆小的小单体。而这种拆分真的能够给我们带来微服务架构的那些好处吗?

    • 随着熟悉“领域驱动设计”方法的工程师发现,由于DDD可以有效的从业务视角对软件系统进行拆解,并且DDD特别契合微服务一个特征:围绕业务能力构建。这样搭建的微服务系统比较合理并且高内聚低耦合。

      下面从DDD的方法论上探讨系统如何拆分之两种方式:

    1.1 聚合根

    • 从广义上讲,领域(Domain)即是一个组织所做的事情以及其中所包含的一切。每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。
    • 领域驱动设计一个重要的概念就是聚合根。聚合可以由单个实体组成,也可以由一组实体和值对象组成。聚合就是一组相关对象的集合。每个集合都有一个根和一个边界。边界定义了聚合的内部都有什么。根是聚合中所包含的一个特定实体。在聚合中,根是唯一允许外部对象保持对它的应用的元素,而边界内部的对象之间则可以互相应用。
    • 从聚合根的特性来看,它是业务系统的一层边界,识别了聚合根后,在重构拆分微服务时,很容易从一个应用迁移到另一个应用。
      在这里插入图片描述

    1.2 限界上下文

    • 限界上下文是一个显式的边界,领域模型便存在于这个边界之内。创建边界的原因在于,每一个模型概念,包括它的属性和操作,在边界之内都具有特殊的含义。一个限界上下文并不是只包含领域模型。诚然,模型是限界上下文的主要“公民”。但是,限界上下文并不只局限于容纳模型,它通常标定了一个系统、一个应用程序或者一种业务服务。由此可见,提炼限界上下文的方法也可以作为微服务的拆分。限界上下文比聚合根是在一个更大的范围限定的服务的边界。
    • 我们如何认为上下文边界的划分是合理的,通常情况下,如果你在不同的上下文中看到了完全相同的对象,这通常意味着你的模型是错误的或者上下文划分不合理。这时候就需要调整上下文或者识别出相识对象的细微区别。

    抽象图:

    在这里插入图片描述
    一个具体例子图:
    在这里插入图片描述

    2 总结

    经过理论的严密推理和大量实践项目的验证,业界绝大多数人士认为DDD是当前软件工程业界设计微服务的最佳实践。其中的很多理念和方法可以用来指导微服务拆分和设计,并且能促进企业软件开发能力的发展,提高开发质量和效率。

    展开全文
  • 微服务应用 微服务拒绝 客户多次说过; 他们无法想象他们的组织使用微服务。 我感到惊讶,因为我知道那些人已经在使用微服务的许多原理。 我可以理解,他们觉得没有必要加入对微服务的炒作,但事实是,无论您...

    微服务 微应用

    微服务拒绝

    客户多次说过; 他们无法想象他们的组织使用微服务。 我感到惊讶,因为我知道那些人已经在使用微服务的许多原理。

    我可以理解,他们觉得没有必要加入对微服务的炒作,但事实是,无论您是否喜欢,您都可能会使用微服务倡导的一些最佳实践。

    拒绝的阶段

    • 一切似乎都在大肆宣传,我们不赞成这样做。
    • 也许不是所有的炒作,但这真的意味着什么。
    • 听起来都很熟悉。
    • 听起来好像我们已经在做。

    正式或非正式地,您很可能已经遵循了一些最佳实践。

    采用最佳做法。

    也许您不喜欢微服务这个名字,也许与微服务相关联的所有事物都不适合您的团队和项目。 相反,让我们考虑如何将要达到的目标正式化,并找到更清晰的采用最佳实践的途径。

    为什么要这么做呢?

    在较大的团队中,关于如何进行可能存在一些分歧。 人们可能会对坏的事情有强烈的感觉,或者对自己拥有的东西感到沮丧,而诱惑就是只丢弃大部分自己的东西或丢弃一切。

    这样做的问题是您冒着淘汰旧的已知问题并放入更多新的未知问题的风险。 您需要进行更改,可能有选择地进行根本性更改,这些更改对于您的团队而言是可管理和可实现的。

    通过规范化您正在谈论的内容,甚至使用流行语,您也可以更清楚地陈述您要实现的目标以及原因。 它为您提供了一种交流您的想法的通用语言。 它可以让您更好地了解自己今天所处的位置以及需要成为的位置。

    最佳做法记分卡。

    使用记分卡,您可以快速了解您的当前位置,快速获胜的位置以及中期所需的位置。 问题的很大一部分; 我们今天在哪里,只是在重新命名您已经拥有的产品。 这篇评论可以使您以某种方式发现自己并没有想象中那么糟糕,而与此同时形成鲜明对比的是最有机会改善的领域。

    初步步骤

    我建议的初始步骤是

    • 重塑您的财产; 您已经有了一些最佳做法。
    • 快速获胜; 低风险的变化可以帮助您改善职位。
    • 中期改进; 在接下来的六个月中您需要实现什么。

    一个例子。

    这是我为60多个开发商的公司的高级经理汇总的计分卡。 在一个小时的时间内,我们从不考虑微服务,到确信这是增强其解决方案的途径。

    表1.最佳实践记分卡
    今天 快速获胜 6个月
    简单的基于组件的设计。 ★★ ★★☆ ★★☆
    由JVM和Machine分发 ★★ ★★ ★★☆
    服务发现 ★★ ★☆ ★★
    抵抗失败的能力 ★☆ ★☆ ★★
    运输不可知 ★★ ★☆ ★★
    异步消息传递。 ★☆ ★★ ★★
    自动化的动态服务部署。 ★☆ ★★ ★★☆
    服务本地私有数据集。 ★★ ★★
    透明的消息传递。 ★★ ★★☆
    Lambda建筑 ★★ ★★ ★★★
    这并不是详尽的清单。 这是我们在第一个小时内进行的审查。

    后两个领域被认为是最重要的改进领域,因为它们都是低风险的,但很有可能揭示出他们所遇到的一些反复出现的问题的原因。

    尤其是,性能和稳定性问题需要有关系统运行状况的质量,详细信息,因此,您可以从有见识的角度了解需要进行哪些更改以修复它。

    结论

    无论您是喜欢还是讨厌微服务,很可能您正在使用某些最佳实践,并且对微服务中使用的最佳实践进行回顾可能会有助于您了解如何改善自己的服务。

    翻译自: https://www.javacodegeeks.com/2016/05/microservices-applying-group-best-practices.html

    微服务 微应用

    展开全文
  • 单体应用对比微服务

    千次阅读 2017-08-18 21:47:37
    说起微服务,首先要对比的是传统的单体应用。单体应用是最早的应用形态,不需要太关注整体性能,项目规模中小型时,开发和部署都挺方便。简单谈谈他的优缺点。 单体应用优点: 方便调试,代码都在一起; 没有分布式...
  • 什么是单体应用?什么是微服务?单体应用的优势和劣势,为什么要从单体应用过渡到微服务?本文能解答这些问题.....
  • 刷新页面?路由拆分?No,动态加载组件。 本文分为以下四部分: 前端微服务化思想介绍 微前端的设计理念 ...然而,我们并不可能去大量地复写已有的应用。 iFrame。你是说真的吗? 另外一个微前端框架 Single...
  • 并讨论了使用微服务架构的优势和劣势,接下来的文章讨论微服务架构的不同方面:使用API网关、进程间通信、服务发现、事件驱动的数据管理以及部署微服务,本篇文章,让我们看下如何把一个单体应用重构为微服务架构的...
  • 单体应用微服务优缺点辨析

    千次阅读 2016-11-26 16:15:32
    近日,Java Code Geeks发表了一篇文章,分析了单体应用微服务的优缺点,并建议使用微服务重构现有的应用程序。 通俗地讲,“单体应用(monolith application)”就是将应用程序的所有功能都打包成一个独立的单元...
  • 本次讲解单体应用微服务的区别 单体应用是将所有功能模块放在一个单一进程中,并且通过在不同的服务器上面复制这个单体进行扩展。 微服务架构是将每一个功能模块分别放进到一个独立的服务中,并且通过跨服务器...
  • 前端应用微服务式拆分

    千次阅读 2018-09-13 14:14:51
    本文分为以下四部分: 前端微服务化思想介绍 微前端的设计理念 实战微前端架构设计 ...然而,我们并不可能去大量地复写已有的应用。 iFrame。你是说真的吗? 另外一个微前端框架 Single-...
  • 单体应用微服务的区别

    千次阅读 2019-04-25 08:31:15
    一、单体应用架构 (一)、单体应用架构概念 一个归档包(可以是JAR、WAR、EAR或其它归档格式)包含所有功能的应用程序,通常称为单体应用。 而架构单体应用的方法论,就是单体应用架构。 (二)、单体架构示意图 ...
  • 微服务的架构下,可以采用快速迭代的方式进行架构的演进,在这个过程中可能会出现各种问题,但在微服务的架构下,即使是某个服务遇到问题,发版修复,也不会导致这个应用系统不可用。腾讯有一条重要发展原则就是...
  • grpc应用微服务的分析,基于python

    千次阅读 2017-06-28 17:13:15
    grpc应用微服务的分析 gRPC 是一个高性能、开源和通用的 RPC 框架,面向移动和 HTTP/2 设计,目前提供 C、Java 和 Go 语言版本,分别是:grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C++, Node.js, ...
  • 为什么k8s天然适合微服务

    万次阅读 2018-08-09 20:24:41
    最近总在思考,为什么在支撑容器平台和微服务的竞争中,Kubernetes 会取得最终的胜出,事实上从很多角度出发三大容器平台从功能方面来看,最后简直是一摸一样。 经过一段时间的思索,以及采访了从早期就开始实践 ...
  • 微服务架构模式语言包含了许多组模式。模式语言的值超出了它的各个模式的总和,因为它定义了模式之间的这些关系: Predecessor - Predecessor模式是一种激励...例如,如果您应用微服务架构模式,则必须应用许多succe
  • 应用集成和微服务

    千次阅读 2019-03-01 14:51:12
    到现在流行微服务。这种演变的本质就是系统功能太大时,需要拆分,这里面,实际上还有一个因素就是一个系统功能部署在一台服务器上所面临的计算能力问题,这种情况下需要进行分布式处理。分布式处理...
  • 什么样的项目适合微服务

    千次阅读 2020-02-17 19:15:59
    它提倡将单一应用划分成一组小的服务,每个服务运行独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API) 。每个服务都...
  • 单体应用微服务改造实践

    千次阅读 2019-05-06 14:26:39
    【摘要】 本文介绍了如何采用一种持续迭代演进的方法将单体应用改造为微服务应用。重点介绍了如何通过自动测试服务和网关服务来构造持续迭代演进的基础设施。文末介绍了如何使用CSE更好的完成这个过程。 微服务的...
  • (1) 为什么要选择微服务架构以及何时选择微服务架构; (2) 讲述实施微服务架构的一些先决条件; (3) 实施微服务架构中重点知识与实践的介绍
  • 【摘要】近年来越来越多的企业开始实践微服务,本文分为上下两篇介绍微服务框架ServiceComb如何帮助企业应用进行微服务化,实现快速交付,并可靠地运行在云端。下篇介绍ServiceComb的通信处理设计。近年来越来越多的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 168,891
精华内容 67,556
关键字:

哪些应用适合微服务