企业云原生之微服务全面解析.docx

上传人:王** 文档编号:1406101 上传时间:2024-07-06 格式:DOCX 页数:21 大小:149.34KB
下载 相关 举报
企业云原生之微服务全面解析.docx_第1页
第1页 / 共21页
企业云原生之微服务全面解析.docx_第2页
第2页 / 共21页
企业云原生之微服务全面解析.docx_第3页
第3页 / 共21页
企业云原生之微服务全面解析.docx_第4页
第4页 / 共21页
企业云原生之微服务全面解析.docx_第5页
第5页 / 共21页
企业云原生之微服务全面解析.docx_第6页
第6页 / 共21页
企业云原生之微服务全面解析.docx_第7页
第7页 / 共21页
企业云原生之微服务全面解析.docx_第8页
第8页 / 共21页
企业云原生之微服务全面解析.docx_第9页
第9页 / 共21页
企业云原生之微服务全面解析.docx_第10页
第10页 / 共21页
亲,该文档总共21页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《企业云原生之微服务全面解析.docx》由会员分享,可在线阅读,更多相关《企业云原生之微服务全面解析.docx(21页珍藏版)》请在优知文库上搜索。

1、1、单体应用传统应用系统多为单体应用、经典三层架构部署:应用-数据库-中间件,关于该业务领域的功能实现全部在一个软件工程中进行开发,集成发布打成一个程序包更新,其主要优点为:(1)系统整体架构简洁清晰,测试、部署及运维比较简便,中小型项目开发快捷;(2)资源占用较低,不需要分布式开俏;单体由于将所有功能模块耦合在一起,导致其存在如下缺点:(1)系统耦合度高,容错能力低,小的问题可能导致整体的不可用;(2)开发周期长.程序代码冗肿,调试复杂、启动时间慢;(3)Bug修复成本高,每一次线上Bug修复需要全局替换、发布;(4)扩展性差,应对高并发、高吞吐能力差;(5)交付周期长,所有功能一起构建、一

2、起部署、一起发布,代码集成爱杂,出错率高;(6)对于大型项目以及需求变化频次高的系统,至构是必然。综合单体应用的优缺点,其比较适合变化频次较低的中小型系统,具体表现为用户最稳定、需求变化不大以及整体开发工程量微小的项目,比较经典的系统有:资产管理系统、资质管理系统、财务系统、人里系统等。2、微服务2.1赛服务基础设施组件微服务是云原生的主要技术内容之一,是云上应用的主流架构,同时也是应用系统及数据适应云平台的履佳选择,移动互联时代,用户体量及访问18几何式倍增,同时用户需求和行业环境等皆处于快速变化的状态,传统的单体应用受限于其藕合度高、扩展性差、迭代缓慢等缺点已基本不适用与主流应用系统,微服

3、务应运而生.微服务本质上是对传统的单体应用根据业务领域和模块进行划分、解班,拆分成一个一个单独部署、运行的微小应用.单体应用微服务中间件集群例:单体匿售系统更构微服务商城系统通过拆分单体应用为微服务,实现对业务系统的充分解耦,可以收获以下优势:(1)系统松耦合.服务高内聚,代码聚焦指定业务功能或需求,专注度高;(2)系统容错率高,单服务的故障基本不影响整体系统运行,用户体验度高;(3)易扩展、可前后端分离,应对高并发、大流量的场景下可以快速扩容服务节点增大吞吐;(4)快速迭代、试错成本低,可以实现对业务的快速响应.微服务技术架构包括网关、注册中心、配臂中心、腌路监控.流量控制等内容,EEEl.

4、整体如下:OtxmvM*一。一电-eSI,OwMmM_JJ图:微服务椎架(1)服务集群,根据业务功能模块拆分成一个个独自的项目,每个项目完成独自的功能,每个项目又称为独自的服务,每个服务构成了一个服务集群;(2)注册中心,应用系统拆分成多个服务之后,每个服务都有独立的服务信息(IP地址、端口以及功能等),如何让对方知悉服务信息,需要注册中心模块对服务进行整体管理.每个服务在注册中心中注册,当用户进行调用服务,它首先到注册中心拉取服务信息再去调用相对于的服务。(3)负载均衡,多个服务组成服务集群,在进行服务调用是通过负载均衡分担服务调用流后,实现服务高可用的同时也增加服务的并发吞吐.(4)网关,

5、拆分成多个服务之后,涉及到服务之间的调用,一个服务调用了三个服务的模块,在这个服务里,配置三个调用地址,看起来是不是很麻烦?所以就出现了网关,所有的服务调用都调用到网关,然后在网关里配置路由,进行服务的转发,类似于代理的作用。当然网关需要用合注册中心进行使用,去发现转发到哪个服务上去.是为了校验身份和谙求路由,负载均衡.(5)配SS中心,每个服务都会有各自的配置信息,便于统一管理,使用到配25中心,如果想更改服务的配2S中心,就在配置中心上迸行更改,配在中心会通知相关的服务实现配置的日更新.除上述5大基础组件外,微服务还包括链路监控、流控制(限流、熔断、降级)、日志管理、以及常用的中间件服务(

6、文件.缓存、消息队列等)和服务网格等.整路监控是实现云原生可观测性的方式之一,应用系统微服务拆分后,服务之间相互调用,前台页面的一个请求往往涉及后端多个服务的调用实现,宜杂的调用及实现方式造就了一些列的问题,如:问题定位缓慢、故障影响范围不清以及服务依赖不合理等问题,同时服务调用的性能和实时容量也存在不清晰的地方,相关指标如服务吞吐量TPS、服务响应时间、服务调用失败率等难以量化。通过全错路监控从整体维度到局部维度展示各项指标,将跨应用的所有调用使性能信息集中展现,可方便度量整体和局部性能,并且方便找到故障产生的源头,生产上可极大缩短故障徘除时间.有了全镇珞监控工具,我们能够达到:谙求错路追踪

7、,故障快速定位:可以通过调用链结合业务日志快速定位错误信息;可视化:各个阶段耗时,进行性能分析;依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化.数据分析,优化链路:可以得到用户的行为路径,汇总分析应用在很多业务场景.流量控制主要包括流量熔断、限流、降级,是服务实现高性能、高并发、商可用的关键手段之一.熔断是指在服务的依赖调用中,在服务的依赖调用中,被调用方出现故障时,出于自我保护的目的,调用方会主动停止调用,并根据业务需要进行相应处理.之所以需要熔断,是因为假定服务A依赖服务B,当服务B处于正常状态,整个调用是健康的,服务A可以得到服务B的正常响应,当服务B出现故障时比如响应缓慢、超

8、时或是宜接宕机,如果服务A继续诘求服务B那么服务A的响应时间也会增加,进而导致服务A响应缓慢,如果服务A不进行熔断处理,服务B的故障会传导至服务A,最终导致服务A也不可用.限流是针对服务请求数量的一种自我保护机制,当请求数量超出服务的处理能力时,会自动丢弃新来的诘求.之所以需要限流是因为任何一个系统的处理能力都是有极限的,假定服务A的处理能力为QPS=100O,当QPS1000时,由于请求最增大,会出现争抢服务资源的情况(数据库连接、CPU、内存等),导致服务A处理缓慢;当QPS继续增大时,可能会造成服务A响应更加缓慢甚至奔演,如果不进行限流控制,服务A始终会面临着被大流量冲击的风险,做好系统

9、请求流量的评估,制定合理的限流策略,是我们进行系统高可用保护的函要一步.降级是通过开关配覆将某些不重要的业务功能屏蔽掉,以提高服务处理能力.在大促场景中经常会对某些服务进行降级处理,大促结束之后再进行复原.之所以需要降级是在不膨响业务核心链路的情况下,屏蔽某些不生要的业务功能,可以节省系统的处理时间,提供系统的响应能力,在服务器资源固定的前提下处理更多的诘求.服务A缁断模块根据立身处及日志首理也属于可观测性实现方式之一,应用系统服务拆分后,服务、数据库以及中间件等增多,缺乏统一的日志管理将导致问地故障定位且杂、处理时间缓慢等,同时日志缺失、不完整也不符合响应的监管要求.日志管理包括两个方面,一

10、是统一的日志标准,包括日志级别、日志存储位置,日志存储周期等,另一个就是统一的技术架构实现日志采集、日志存储、日志分析、日志展示等.分布式的微服务架构,统一的日志管理平台是必不可少的组件,同时也是提高运维效率和缩短故障定位时间的最佳有效方法之一.道服务H志一标准中间件Il志采集日志分笑日志用洗存传位!存储用明日书分析日志应用日志挖掘分析Il示其他从架构的完整性来说,不管是单体应用还是微服务都需要对中间件进展集中管控的,常用的中间件类型有:消息队列服务、缓存服务、分布式文件服务、任务调度服务、流程引擎服务、搜索服务等。对于中间件的管理主要包括标准统一的高可用部署、性能优化和安全加固、调用与被调用

11、的依赖关系以及配目管理等.图:微服务组件全家桶链路监控2.2 服务网格服务网格是用于处理服务间通信的专用基础设施层,负责在微服务间进行可靠地请求传递.服务网格通常通过一组轻津级网络代理来实现,这些代理与应用程序代码一起部若,而不需要感知应用程序本身。随着规模和豆杂性的增长,服务网格包含的实现的功能越来越多,它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等.其部署结构如下图所示:MkroervkISldrcar图:服务网格部署图服务网格有如下几个特点:应用程序间通讯的中间展轻量级网络代理应用程序无感知解羯

12、应用程序的蚤试/超时、监控、追踪和服务发现如果用一句话来解释什么是服务网格,可以将它比作是应用程序或者说微服务间的TCP/IP,负责服务之间的网络访问、限流、熔断和监控.对于编写应用程序来说一般无须关心TCP/IP这一层(比如通过HTTP协议的RESTfuI应用),同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如SpringCIoud.OSS,现在只要交给服务网格就可以了,从而极大地方便了微服务应用的开发。2.3 微眼旁技术框架微服务基础设施组件众多,其实现的技术框架主要有:DUbbO、SpringCIoud、SpringCIoudAIibaba等.Du

13、bboApacheDubbo是一款RPC服务开发框架,用于解决微服务架构下的服务治理与通信问题,官方提供了Java、Golang等多语言SDK实现.使用Dubbo开发的微服务原生具备相互之间的远程地址发现与通信能力,利用Dubbo提供的丰富服务治理特性,可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求.Dubbo被设计为商度可扩展,用户可以方便的实现流量拦截、选址的各种定制逻相.在国内,Dubbo实质上算是第一代微服务的经典框架,但自2014年暂停更新后,长期止步于Dubbo2版本亘至2017年开源重启、2021年推出3.0,至此Dubbo3被定义为面向云原生的下一代RPC服务框架.3.

14、0基于Dubbo2.x演进而来,在保持原有核心功能特性的同时,Dubbo3在易用性、超大规模微服务实践、云原生基础设施适配、安全性等几大方向上进行了全面升级.ApacheDubbo总体架构能很好的满足企业的大规模微服务实践,因为它从设计之初就是为了解决超大规模微服务集群实践问题,不论是阿里巴巴还是工商银行、中国平安、携程等社区用户,它们都通过多年的大规模生产环境流量对Dubbo的稳定性与性能进行了充分验证,因此,Dubbo在解决业务落地与规模化实践方面有以下优势:开箱即用:易用性高,如JaVa版本的面向接口代理特性能实现本地透明调用;功能丰富,基于原生库或轻信扩展即可实现绝大多数的做服务治理能

15、力面向超大规模微服务集群设计:极致性能,高性能的RPC通信协议设计与实现;横向可扩展,轻松支持百万规模集群实例的地址发现与流量治理高度可犷展:调用过程中对流量及协议的拦截扩展,如Filter.Router.1.B等;微服务治理组件扩展,如Registry、ConfigCenter.MetadataCenter企业级微服务治理能力:国内公有云厂商支持的事实标准服务他架;多年企业实践经验考验,参考用户实践案例Dubbo核心特性主要有高性能RPC通信协议、自动服务(地址)发现、运行态流量管控、丰富的扩展组件及生态、面向云原生设计等。SpringCloud从个人工作经历来看,由于Dubbo的多年停更,给了SpringCloud在国内的快速发展期,最起码我所熟悉的3家公司在进行系统里构时,皆受限于Dubbo的停更转为使用SpringBoot并逐渐发展为全套的SpringCloud,当然SpringCloud也是非甫优秀的框架组合.SpringCloud是分布式微服务架构的一站式解决方案,它提供了一套简单易用的编程模型使我们能在SpringBoot的基础上轻松地实现微服务系统的构建.SpringCloud被称为构建分布式微服务系统的全家桶n,它并不是某一门技术,而是一系列优服务解决方案或框架的有序集合.它将市面上成熟的、经过验证的微服

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > IT计算机 > 并行计算/云计算

copyright@ 2008-2023 yzwku网站版权所有

经营许可证编号:宁ICP备2022001189号-2

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!