精华内容
下载资源
问答
  • 哪些应用适合微服务
    千次阅读
    2020-09-23 11:20:57

    关于单体应用的的简单讲解,点击此处即可查看

    本次讲解单体应用与微服务的区别

    1. 单体应用是将所有功能模块放在一个单一进程中,并且通过在不同的服务器上面复制这个单体进行扩展。
    2. 微服务架构是将每一个功能模块分别放进到一个独立的服务中,并且通过跨服务器分发这些服务进行扩展,只有需要时才复制。
    3. 一个应用程序应该是一组小型服务,通过Http的方式进行互通。

    微服务的优点:

    1. 单体应用中,如果需要改动功能,那么则需要重新部署整个单体应用。
    2. 微服务则只需要重新部署修改的功能模块那个微服务。每一个功能模块都是可独立替换和独立维护的软件单元,完全体现了高可复用性,高可维护性,高可扩展性。
    更多相关内容
  • 一种微应用微服务交互方法、微应用和系统.pdf
  • 微服务的出现就是用来解决这个问题的——把一个庞大的单体应用横向切割成若干个微服务,每个微服务只做一件事,但它仍然包含展现层、应用层和数据层。微服务单独运行,对外暴露 API 接口供其他程序调用。所以说,...
  • 社交应用后台微服务架构实践.docx
  • 本节会体验一下Istio的简单路由功能,并了解整个微服务的调用流程1)在default命令空间开启自动注入功能2)部署服务3)查看服务部署状态4)应用路由规则,
  • 那当微服务应用运行在容器中的时候,我们会遇到哪些常见问题?我们又该如何解决呢?企业应用在向微服务架构转型的过程中,微服务如何划分是最基本的问题。我们可以通过业务架构的梳理来理解业务,并同时使用领域设计...
  • 微服务好像是这两年突然火起来的,其实和很...这些年来,我们帮助一些客户在分布式/微服务架构方面进行了一些尝试与实践,在这个过程中碰到了以前在单体应用下很少需要特意关注的问题。比如数据一致性、比如statelesss
  • 微服务架构的应用性能监控.pdf
  • 单体应用&微服务对比

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

    千次阅读 2022-02-18 11:22:12
    Monolith(单体应用),也称之为单体系统或者是单体架构。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。 也就是将所有的代码及功能都包含在一个WAR包中的项目组织方式。它的组成就是由多个模块...
    Monolith(单体应用), 也称之为单体系统或者是 单体架构 。就是一种把系统中所有的功能、模块耦合 在一个应用中的架构方式。
    也就是将所有的代码及功能都包含在一个WAR包中的项目组织方式。它的组成就是由 多个模块(所有资源)打成一个war包,运行在一个服务器上,也就是 一个进程去运行。典型的就是用SSM框架做的web项目,部署在tomact服务器上。
    缺点:
    技术选择难:
    扩展难:不易进行功能扩展。
    可靠性差
    迭代困难  
    跨语言程度差  
    团队协作难
    优点:
    项目易于管理 
    部署简单    
    MicroService(微服务)架构, 是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。由一个或多个微服务组成。
    那什么是微服务(分布式)?就是 将一个大的应用拆分成多个小的应用(微服务),这些小的应用相对独立,每个小的应用都有自己的容器(Tomcat),有自己的运行进程,这些小的应用通过网络协议(HTTP Rest)进行相互通信,所有的应用一起工作完成整个项目的业务。
    每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。
    系统中的各个微服务可被技术选项,独立开发,独立部署,独立运维,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
    优点:
    方便局部扩展,团队协作方便
    技术选型多样化
    单个微服务的复杂性低,一个微服务就干一件事
    单个微服务容易开发和维护
    服务和服务之间相对松耦合
    数据库选型多样化(分库)
    当项目规模大,微服务整体来说性能好。。。
    缺点:
    微服务之间数据交互速度受网络影响
    技术成本高
    开发成本高,如分布式事务处理
    整个项目总体来看,比较复杂
    微服务的部署比较麻烦
    这里给出一张图片,便于理解单体应用和微服务的区别:
    上面说到技术成本高,那么需要 那些技术栈来实现微服务呢?
    一个微服务架构设计需要以下内容:
    1.服务治理
    2.服务注册
    3.服务调用
    4.服务负载均衡
    5.服务监控
    6.服务开发。。。
    以上这些都有不同的技术去实现,比如:
    服务治理:有阿里的dubbo,
    服务注册:有ZooKeeper,Eureka
    服务调用:有Rest、RPC,
    服务开发:用SpringBoot、Spring、SpringMVC,
    服务配置与管理有:阿里的Diamond
    服务熔断器有:Hystrix、Envoy
    服务负载均衡有: Ribbon、Nginx
    服务接口调用(客户端调用服务的简化工具): Ribbon、 Feign
    服务配置中心管理有:S pringCloudConfig、Chef
    服务路由有(API网关): Zuul
    服务监控有: Zabbix、Nagios、Metrics、Spectator
    消息队列有: Kafka、RabbitMQ、ActiveMQ
    全链路追踪有: Zipkin,Brave、Dapper
    服务部署有: Docker、OpenStack、Kubernetes
    数据流操作开发包有: SpringCloud Stream(封装与Redis,Rabbit、Kafka等发送接收消息)
    事件消息总线有: Spring Cloud Bus
    而目前较成熟的微服务架构就是阿里的dubbo以及Spring中的SpringCloud。这也是我们需要学习的。
    微服务设计几大原则
    1) AKF 拆分原则
    2) 前后端分离原则
    • 前后端技术分离,可以由各自的专家来对各自的领域进行优化,这样前端的用户体验优化效果更好。
    • 分离模式下,前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了,更容易维护。
    • 前端多渠道集成场景更容易实现,后端服务无需变更,采用统一的数据和模型,可以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端。
    3) 无状态服务
    4) 基于RestFul 的通信风格
    • 无状态协议 HTTP,具备先天优势,扩展能力很强。例如需要安全加密,有现成的成熟方案 HTTPS 即可。
    • JSON 报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。
    • 语言无关,各大热门语言都提供成熟的 Restful API 框架,相对其他的一些RPC 框架生态更完善。
    微服务远程调用方式
    1.RPC:
    Remote Produce Call远程过程调用,是一个计算机通信协议。类似的还有RMI。 自定义数据格式,基于原生TCP通信,速度快,效率高。早期的webservice,现在热门的dubbo,都是RPC的典型。
    该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。说得通俗一点就是:A计算机提供一个服务,B计算机可以像调用本地服务那样调用A计算机的服务。
    两个程序进行通讯,必须约定好数据传输格式。就好比两个人聊天,要用同一种语言,否则无法沟通。所以,我们必须定义好请求和响应的格式。另外,数据在网路中传输需要进行序列化,所以还需要约定统一的序列化的方式。
    2.Http:
    http其实是一种网络传输协议,基于TCP,规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。
    现在热门的Rest风格,就可以通过http协议来实现。
    MVC、RPC、SOA、微服务架构之间的区别
    1 MVC 架构
    MVC 架构已经很熟悉了,就是一个单体架构。
    代表技术:Struts2、SpringMVC、Spring、Mybatis 等。
    2 RPC 架构
    RPC(Remote Procedure Call):远程过程调用。它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。   服务与服务之间隔离的,都是通过应用来触发。
    代表技术:Thrift、Hessian 等。
    3 SOA 架构
    SOA(Service oriented Architecture):面向服务架构
    ESB(Enterparise Servce Bus):企业服务总线,服务中介。主要是提供了一个服务与服务之间的交互。
    ESB 包含的功能如:负载均衡,流量控制,加密处理,服务的监控,异常处理,监控告急等。
    代表技术:Mule、WSO2
    4 微服务架构
    微服务就是一个轻量级的服务治理方案。
    代表技术:SpringCloud、dubbo 等
    学习java的,可以关注公众号,可以免费获取毕业设计项目、各种免费软件、资料,笔记哦。

    低价开通公众号,小程序流量主:0.3/人,若有需要联系V:nzdszbd

    展开全文
  • 单体应用微服务浅析

    千次阅读 2018-12-02 00:35:00
    微服务的架构下,可以采用快速迭代的方式进行架构的演进,在这个过程中可能会出现各种问题,但在微服务的架构下,即使是某个服务遇到问题,发版修复,也不会导致这个应用系统不可用。腾讯有一条重要发展原则就是...

        最近两年,微服务架构盛行,出现了一些优秀的微服务框架,如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

    展开全文
  • 微服务背后大的理念是将大型、复杂且历时长久的应用在架构上设计为内聚的服务,这些服务能够随着时间的流逝而演化。微服务这个术语强烈建议服务应该是很小的。社区中有些人甚至建议构建10-100代码行(LOC)的服务。...
  • 构建微服务云原生应用——微服务测试设计和实践.pdf
  • 当你决定采用微服务,你将经历从单一应用到一个复杂系统的转变过程。在这个系统里,你会遇到很多无法预测的行为,因为团队和服务在持续地发生变化,它们被创建、被修改,然后被销毁。系统的快速变更能力为你的组织...
  • 单体应用微服务对比

    千次阅读 2019-03-27 09:26:24
    单体应用适合场景: 1 单体应用架构图: 2、微服务架构图 微服务,服务调用基本组件: 服务描述,注册中心,服务框架,服务追踪,服务治理 3 、 单体应用微服务架构优缺点 单体应用有如下优点: 为人所熟知:...
  • 从单体式应用微服务的架构演变.docx
  • 1. 微服务涉及哪些技术 1.1、基础技术 首先每个微服务都可以看作是单机架构,所以最基础的就要要求你掌握单机架构的知识,单机架构最少量要求掌握的知识包括: java mysql springboot mybatis,mybatis-plus linux ...
  • 应用系统迁移上云和微服务改造经验分享-最佳实践.docx
  • 微服务架构及其应用

    千次阅读 2020-12-18 18:30:12
    前端Web服务由Nginx负载均衡与服务器集群结合,解决前台界面的并发问题;平台保障服务以Eureka为中心,分为API网关、服务注册中心...业务服务基于Spring Cloud开发,分为多个微服务,实现具体业务功能,解决协同问题。
  • 构建微服务云原生应用——微服务测试设计和实践
  • 保险行业应用微服务架构趋势.docx
  • 本章内容从问题开始,循序渐进,带领读者逐步深入微服务架构的各个角落。2005年,PeterRodgers博士在云端运算博览会上提出的微Web服务(Micro-Web-Service),将程序设计成细粒度的服务(GranularServices),以作为...
  • 技改之路:从单块应用微服务,我的血泪总结.docx
  • 微服务、Serverless的出现,都是以不断提高交付效率、缩短交付周期为核心,基于云原生的方式,对架构优化的结果
  • 单体应用微服务的区别

    千次阅读 2019-04-25 08:31:15
    一、单体应用架构 (一)、单体应用架构概念 一个归档包(可以是JAR、WAR、EAR或其它归档格式)包含所有功能的应用程序,通常称为单体应用。 而架构单体应用的方法论,就是单体应用架构。 (二)、单体架构示意图 ...
  • 传统应用系统架构的瓶颈 曾经为物业管理公司架构设计并领导开发过一个互联网+物业增值服务平台项目,刚接手这个系统的时候,这个平台在最初的1.0版本采用的是比较标准的单体应用,Java、Tomcat、MySQL,功能服务也...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 215,854
精华内容 86,341
关键字:

哪些应用适合微服务