微服务技术架构.pptx
- 文档编号:12938971
- 上传时间:2023-06-09
- 格式:PPTX
- 页数:41
- 大小:6.34MB
微服务技术架构.pptx
《微服务技术架构.pptx》由会员分享,可在线阅读,更多相关《微服务技术架构.pptx(41页珍藏版)》请在冰点文库上搜索。
,微服务技术架构,微服务是目前最先进的架构设计思想,在许多国内外大互联网公司得到成功的应用,其核心是化繁为简、化整为零,把应用分解为小的服务模块进行独立开发。
微服务的这一特点使其便于部署到容器,对整个开发、测试、运维都发生了革命性影响,有力地支持了devops开发,提高效率,便于维护升级和故障处理,带来了一系列优势。
那么,微服务有哪些奥秘呢?
下面从技术原理上进行剖析。
化整为零的思路不是开发一个巨大的单体式的应用,而是将应用分解为小的、互相连接的微服务。
一个微服务一般完成某个特定的功能,比如下单管理、客户管理等等。
每一个微服务都是微型六角形应用,都有自己的业务逻辑和适配器。
一些微服务还会发布API给其它微服务和应用客户端使用。
其它微服务完成一个WebUI,运行时,每一个实例可能是一个云VM或者是Docker容器。
SpringCloud是微服务开发的优秀框架,在springBoot的基础上进行开发,SpringCloud为开发者提供了在分布式系统(如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、全局锁、决策竞选、分布式会话和集群状态)操作的开发工具。
使用SpringCloud开发者可以快速实现上述这些模式。
微服务技术大揭秘,1,2,分布式事务处理,目录,4,3,微服务架构基于Eventprocess监控与故障处理数据库设计,5,Docker容器部署微服务6微服务与devops,1微服务架构,微服务架构,微服务的特点在于根据业务提炼不同的服务,系统经过拆分,根据不同的功能划分出基础服务和核心服务。
各子系统调用多个核心服务完成功能,核心服务调用多个基础服务。
核心服务之间和基础服务之间不能互相调用。
一般服务模块只能访问自己的数据库,对其他数据库的数据,通过调用其服务提供的接口完成。
要搞好服务抽象,确定服务边界,确定合适的服务粒度,服务高内聚、低耦合,充分复用,还需要合理划分服务的数据库,实现高度自治。
服务的访问分3种方式:
采用rest方式同步调用服务,支持不同语言和环境。
采用消息方式异步并行调用服务,提高性能和可用性。
3.采用asynTemplate异步调用服务,通过future获取结果。
4.使用rpc方法访问,性能最优,google的grpc很棒。
根据业务的特点,灵活采用上面的方法调用服务,有效地提升系统性能。
微服务架构,复杂度可控:
在将应用分解的同时,规避了原本复杂度无止境的积累。
每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界。
由于体积小、复杂度低,每个微服务可由一个小规模开发团队完全掌控,易于保持高可维护性和开发效率。
独立部署:
由于微服务具备独立的运行进程,所以每个微服务也可以独立部署。
当某个微服务发生变更时无需编译、部署整个应用。
由微服务组成的应用相当于具备一系列可并行的发布流程,使得发布更加高效,同时降低对生产环境所造成的风险,最终缩短应用交付周期。
技术选型灵活:
微服务架构下,技术选型是去中心化的。
每个团队可以根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。
由于每个微服务相对简单,当需要对技术栈进行升级时所面临的风险较低,甚至完全重构一个微服务也是可行的。
容错:
当某一组建发生故障时,在单一进程的传统架构下,故障很有可能在进程内扩散,形成应用全局性的不可用。
在微服务架构下,故障会被隔离在单个服务中。
若设计良好,其他服务可通过重试、平稳退化等机制实现应用层面的容错。
扩展:
单块架构应用也可以实现横向扩展,就是将整个应用完整的复制到不同的节点。
当应用的不同组件在扩展需求上存在差异时,微服务架构便体现出其灵活性,因为每个服务可以根据实际需求独立进行扩展。
微服务架构,做微服务架构设计规划,主要分为以下步骤:
1整体架构设计2业务领域抽象、建模3服务规划与层次划分、数据库设计与划分4服务内流程、数据、契约(接口)定义和技术选型。
微服务架构,微服务架构,微服务架构,微服务架构,微服务架构,微服务架构在基础交付设施自动化上,如下图所示,体现在自动化、容器化交付这个流程中,在平台化的背景下把团队思维转换为DevOps式的,依托Docker和k8s完成了PaaS平台的对接,同时和QA一起协作完成持续交付流程的建立。
微服务架构基于对业务的抽象分解,在计算服务层内部,就可以进行更加细分的层次规划,先是垂直拆分为展现层、计算层、数据资源3大纵层,核心的计算层又细分为3个层次,包括业务流程处理层,通过组装下层服务完成功能;业务逻辑组件是自包含,跨产品线、高度复用的组件;下面公共服务组件是一些通用服务。
然后水平划分为多个服务簇。
如下图所示。
2基于Eventprocess,分布式事务处理,目前微服务事务解决方案有3个:
一、结合MQ消息中间件实现的可靠消息最终一致性二、TCC补偿性事务解决方案三、最大努力通知型方案第一种方案:
可靠消息最终一致性,需要业务系统结合MQ消息中间件实现,在实现过程中需要保证消息的成功发送及成功消费。
即需要通过业务系统控制MQ的消息状态第二种方案:
TCC补偿性,分为三个阶段TRYING-CONFIRMING-CANCELING。
每个阶段做不同的处理。
TRYING阶段主要是对业务系统进行检测及资源预留CONFIRMING阶段是做业务提交,通过TRYING阶段执行成功后,再执行该阶段。
默认如果TRYING阶段执行成功,CONFIRMING就一定能成功。
CANCELING阶段是回对业务做回滚,在TRYING阶段中,如果存在分支事务TRYING失败,则需要调用CANCELING将已预留的资源进行释放。
第三种方案:
最大努力通知型,这种方案主要用在与第三方系统通讯时,比如:
调用微信或支付宝支付后的支付结果通知。
这种方案也是结合MQ进行实现,例如:
通过MQ发送http请求,设置最大通知次数。
达到通知次数后即不再通知。
基于Eventprocess,分布式事务处理,微服务的关键难点在于分布式事务处理,根据CAP理论,微服务架构采用最终一致性实现数据的一致性,这需要采用基于Eventprocess分布式事务处理完成。
目前流行的EP是针对DDD领域架构实现的,对OOD架构不合适,如果采用DDD架构,需要大动干戈推到重来,代价太高,得不偿失。
为此需要创新地设计新的方法来完成事务的处理。
我设计并开发了基于EP的业务系统补偿事务处理框架太极分布式事务处理框架(TJDTH),可以有效地解决这个问题,其优势在于提高了事务的成功率,故障一键恢复,开发方便,简单实用。
现在的项目都是OOD架构,可以很简单地转换为微服务架构,也都可以采用TJDTH太极分布式事务处理框架。
最终一致性EventualConsistency当建立微服务时,我们被强迫面对状态的最终一致性问题,这是因为每个微服务都拥有自己的数据库资源,每个数据库都配置了不同的一致性和可用性权衡策略。
最终一致性是一种用于描述在分布式系统中数据的操作模型,在分布式系统中状态是被复制然后跨网络多节点保存,在关系数据库集群中,最终一致性被用来在集群多个节点之间协调数据复制的写操作,数据库集群中这种写操作挑战是:
各个节点接受到的写操作必须严格按照复制的次序进行,这个次序是有时间损耗的,从这个角度看,数据库在集群节点之间的这种状态复制还是可以被认为是一种最终一致性,所有节点状态在未来某个时刻最终汇聚到一个一致性状态,也就是说,最终达成状态一致性。
当构建微服务时,最终一致性是开发者DBA和架构师频繁打交道的问题,当开始在分布式系统中进行状态处理时,头疼问题更加严重。
核心问题是:
如何在保证数据一致性基础上保证高可用性呢?
基于Eventprocess,分布式事务处理,基于Eventprocess,分布式事务处理,基于Eventprocess,分布式事务处理,基于Eventprocess,分布式事务处理,采用消息获取服务处理的结果,各服务提供补偿服务模块,业务系统提供一个事务处理模块,专门用于处理本业务系统各个服务完成的情况,提供重试、补偿等操作,保证事务的最终一致性。
业务B1各服务调用前后发送消息,包括服务、参数、结果,S1S2C1,S3S4C2,消息队列、存储服务和参数、,事务结果,If(c1=2)/C1成功If(c2!
=2),B1事务处理服务,B1C1S12B1C1S22,B1C2S32,对redotopic消息事务重试未完成服务S4(p)N次If(S4重试fail),定时处理未完成服务,基于Eventprocess,分布式事务处理,3监控与故障处理应用的监控功能,对于分布式系统非常重要。
通过获取系统运行参数,掌握系统运行情况,及时发现并排除故障,所以其重要性显而易见。
这里说的,监控服务的部署及运行情况,和断路器监控不一样,这里主要是监控服务及服务器的各项指标。
监控与故障处理,系统需要埋点,提供详细的log,大多数服务可以采用拦截器来生成log,log存入数据库,为监控系统和故障处理提供有力的支持。
监控包括物理机、虚拟机的内存、cpu、网络、硬盘等系统设施的数据收集,还包括服务调用的情况数据收集和分析,如服务的整个调用链,服务的处理耗时,故障次数,SLA等。
监控系统对不同监控指标设有告警阀值,如果达到阀值则报警,发送短信、微信、邮件,在监控界面弹出提示,还有语音提示,便于管理员及时排除故障。
Spring-Cloud-Sleuth是SpringCloud的组成部分之一,为SpringCloud应用实现了一种分布式追踪解决方案,其兼容了Zipkin,HTrace和log-based追踪,可以直观地看见整个服务的调用链,便于发现问题并优化解决。
故障的解决应该尽量简单快捷,一键搞定,采用大数据和人工智能实现实现自动化和智能化。
监控与故障处理,项目使用开源springboot监控项目spring-boot-admin,监控与故障处理,监控与故障处理,Zipkin是一款开源的分布式实时数据追踪系统(DistributedTrackingSystem),基于GoogleDapper的论文设计而来,由Twitter公司开发贡献。
其主要功能是聚集来自各个异构系统的实时监控数据,用来追踪微服务架构下的系统延时问题。
应用系统需要进行装备(instrument)以向Zipkin报告数据。
Zipkin的用户界面可以呈现一幅关联图表,以显示有多少被追踪的请求通过了每一层应用。
监控与故障处理,Zipkin的用户界面除了可以查看Span的依赖关系之外,还以瀑布图的形式显示了每个Span的耗时情况,可以一目了然的看到各个服务的性能状况。
打开每个Span,还有更详细的数据以键值对的形式呈现,而且这些数据可以在装备应用的时候自行添加。
用户请求的高并发可能会超出系统的处理能力,如果不处理会压垮服务器,并导致雪崩效应,系统会垮掉。
为此需要对系统增加熔断与降级、限流功能,保证系统能可靠工作。
4,数据库设计,1.,微服务架构的数据库是各自独立的,各个服务有自己的数据库,便于单独开,发和维护。
在架构设计的时候,需要根据业务和系统的特点,合理划分数据库,减少冗余,保证数据的一致性和正确性。
2.,数据量大的数据库,需要分库分表,进行垂直和水平拆分,并进行读写分离,,提高性能。
3.,对冷热数据需要分开,热数据存在微服务使用的数据库,冷数据存在hbase或,mongodb。
4.,数据库需要开启log和定期备份,便于在出故障后恢复,确保数据的安全。
5.,大量使用redis缓存,消除数据库瓶颈,提高系统反应速度。
数据库设计,数据库设计,5Docker容器部署微服务,Docker是运行微服务的最佳解决方案,docker+微服务是一个革命。
Docker实际上是一个应用容器的引擎,可以让开发者非常方便地把自己的应用以及这个应用所需要的所有依赖都打进容器镜像当中,且具有可移植性,能够部署到任何服务器上。
项目基于Docker构建,如果把封装的微服务比喻成集装箱的话,k8s则提供了一个大轮船,装载了所有集装箱,为微服务运行提供一个稳定的运行环境,用户也可以在此基础上进行管理。
这里就可以享受到很多云端服务的优势。
微服务采用Kubernetes管理Docker,多个应用系统通过Docker形成集群,Kubernetes可以简单有效地管理各个集群。
Kubernetes的基本单元是Pods,用来定义一组相关的Container。
Kubernetes的优点是可以通过定义一个Replicationcontroller来将同一个模块部署到任意多个容器中,并且由Kubernetes自动管理。
比如定义了一个ApachePod,通过Replicationcontroller设置启动100个Replicas,系统就会在Pod创建后自动在所有可用的Minions中启动100个ApacheContainer。
并且轻松的是,当Container或者是所在的服务器不可用时,Kubernetes会自动通过启动新的Container来保持100个总数不变,这样管理一个大型系统变得轻松和简单。
Docker容器部署微服务,Docker容器部署微服务,容器和微服务:
完美的一对可以将Linux容器视为轻量型的虚拟机,从而可以更灵活地使用、更快速地继承和更容易地分发它们。
Docker是在这方面走在前沿的项目之一。
自2012年启动以来,Docker团队(现在已是公司)提供了一种通过Linux容器构建、打包和分发云本机应用程序的非常简单的方法。
容器与虚拟机有何不同?
每个虚拟机(如下图中的左侧所示)运行自己的来宾操作系统实例,并提供它自己的库和二进制文件。
容器(如右侧所示)是隔离的,它们共享底层的主机OS和库,只打包必要的应用程序二进制文件。
Docker容器部署微服务互通要求的是“可达、快速可达、安全并快速可达”。
一个微服务内部可采用本地方式,而微服务之间采用service地址(无论内部怎么漂移伸缩,对外地址不变),对于公网上的调用,采用宿主机端口映射出去是个可选方式。
Docker容器部署微服务微服务的伸缩与漂移,需要与监控能力结合。
以漂移为例子,漂移有很多触发器,有因为故障的,有基于优化考虑的,比如像优化漂移这种,就要求定义很多维度,包括资源均衡维度、宿主机特性维度、标签配置变更维度等,需结合多维打分对微服务进行合理调度。
微服务和docker,非常适合devops开发,一个image把开发、测试、部署、运维全流程打通,有效地提升效率和质量。
实现企业级DevOps,有很多方式和着手点,比如最常用的就是从持续发布开始。
而我们更聚焦企业的全生命周期,实现基于微服务架构的以下15个:
IAM:
身份识别与访问管理,通过OAuth能力,一次登录,全网通行SPM:
软件产品管理,DevOps平台的核心管理对象:
产品。
以产品维度为入口,管理,包括产品的多版本,每个版本拥有多个组件,组件之间、组件与第三方产品之间的依赖关系等SCM:
软件配置管理,主要是应用配置的管理,在编译打包时通过autoconfig技术,注入到最终部署包SRM:
软件资源管理,资源,即上述产品的运行实例,所以持续发布等都是有SRM发起SEM:
软件环境管理,企业环境千差万别,SEM屏蔽了异构环境的差异性,让上游系统及业务能够松耦合的运行QAF:
质量保证反馈,这个系统负责收集全生命周期的数据反馈,为后续优化演进提供重要依据UMC:
统一监控中心,主要收集日志及资源运行信息,通过计算分析,形成相关报表,同时与告警中心对接,风险异常准实时提示VCS:
版本控制系统,默认集成GITCI:
持续集成系统,默认集成JenkinsBPR:
二进制仓库DPR:
可部署包(镜像)仓库PM:
项目管理系统,可集成redmine或wiki,目前平台是自己实现的IM:
团队间即时通讯系统TM:
租户管理系统MKT:
云市场,平台最终期望作为中间平台,通过市场打通内容提供者与最终用户,6微服务与devops,微服务与devops,微服务与devops,微服务与devops,微服务架构的不足微服务架构也有不足,其中一个跟他的名字类似,微服务强调了服务大小,实际上,有一些开发者鼓吹建立稍微大一些的,10-100LOC服务组。
尽管小服务更乐于被采用,但是不要忘了这只是终端的选择而不是最终的目的。
微服务的目的是有效的拆分应用,实现敏捷开发和部署。
另外一个主要的不足是,微服务应用是分布式系统,由此会带来固有的复杂性。
开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。
更甚于,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。
当然这并不是什么难事,但相对于单体式应用中通过语言层级的方法或者进程调用,微服务下这种技术显得更复杂一些。
另外一个关于微服务的挑战来自于分区的数据库架构。
商业交易中同时给多个业务分主体更新消息很普遍。
这种交易对于单体式应用来说很容易,因为只有一个数据库。
在微服务架构应用中,需要更新不同服务所使用的不同的数据库。
使用分布式交易并不一定是好的选择,不仅仅是因为CAP理论,还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。
分布式事务处理是微服务的一个拦路虎,需要有效的方法解决,目前世界上还没有较为完善的方法,TJDTH可以有效解决此问题。
另外一个挑战在于,微服务架构模式应用的改变将会波及多个服务。
许多改变一般只影响一个服务,而需要协调多服务的改变很少。
测试一个基于微服务架构的应用也是很复杂的任务。
部署一个微服务应用也很复杂,一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。
每个应用实例是需要配置诸如数据库和消息中间件等基础服务。
相对比,一个微服务应用一般由大批服务构成。
成功部署一个微服务应用需要开发者有足够的控制部署方法,并高度自动化。
总之,微服务是一个革命性的新技术,有利于开发复杂的大型项目,提高效率、节约成本、提高质量、便于维护,有许多强大的功能和性能,必将得到广泛应用,在公司的业务开发上,一定能发挥重大作用,全面培训员工掌握此技术,是提高公司核心竞争力的一个关键。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 微服 技术 架构