当前位置:首页 > 服务端 > 如何提高微服务的高可用性

如何提高微服务的高可用性

2022年11月09日 23:23:42服务端19

微服务架构现在是个热门话题,微服务的高可用性自然也是企业非常关注的。眼下互联网的架构秘籍三板斧“高可用可扩展,缓存提速,消峰减流去并发”,在微服务架构体系中有着不一样的诠释。

在微服务中消息队列不仅用来消峰,还可以通过消息队列来解决微服务之间的多耦合,把同步调用转化为异步调用,减少调用链路,提升系统稳定性。单体应用拆分为独立的多个无形中增加了系统的响应时间,可以通过本地缓存、分布式缓存相结合的方式来弥补性能的损耗。以前通过内部接口调用的方法变成RPC调用多个服务,服务与服务之间还有依赖关系,每个服务接口响应时间也都不一样,简单的设置单个接口的超时时间已解决不了问题,可通过服务定级,哪些服务不能出问题,哪些服务允许有异常,采用降级、熔断的方式来解决问题,以达到系统的高可用。这三种方式如能合理运用,微服务的高可用性大大提升,所以说缓存、队列、熔断降级成了微服务架构中的新三板斧。

以下是相关技术应用中的一些难点解答,供大家参考。

1、微服务架构中有哪些技术手段必须在设计阶段就需要规划进去?

互联网的三板斧:熔断、消息队列、缓存、这个必须有要考虑进入,另外为了提高响应时间,并行化操作也需要提前考虑。

熔断:保障服务高可用的重要手段,用户的请求将不再直接访问服务,而是通过线程池中的空闲线程来访问服务,如果线程池已满,则会进行降级处理,用户的请求不会被阻塞,至少可以看到一个执行结果(例如返回友好的提示信息),而不是无休止的等待或者看到系统崩溃。

消息队列:消息队列(MQ)是一种不同应用程序之间(跨进程)的通信方法,在微服务中引入消息队列的目的就是为了减少链路,减少依赖。

缓存:为了提高QPS,减少数据库压力,分本地和远程缓存;

2、 缓存是每个互联网应用系统必备的组件,在微服务框架下如何用好缓存来提高系统的QPS?

在缓存的使用场景中,有一种2/8法则的说法,即20%的请求访问DB(如有可能再少一点),80%的请求访问缓存。在微服务场景下,本身是接口调用的现在变成了RPC远程调用了,在一定程度上的确提高了单个接口的响应时间。但是从全局角度看,微服务提高了系统的QPS量级,所以从某种程度上来说,因为PRC的原因提高了单个接口的RT是可以忽略的。当然如果是为了最求极致,想尽可能的降低因为PRC带来的接口响应时间,如果是涉及多个服务调用的,可以并行调用服务,同时将并行结果缓存在本地。后端每个原子服务都会对接缓存,这样能有效提高系统的响应时间。

一般API接口发起请求到后端服务,如果涉及到会调用多个接口,那么会有一层聚合层,通常在聚合层做缓存,缓存分本地缓存(如JVM)或者远端缓存(如Redis或Memcache)。由于是都是分布式架构,所以缓存一般采用TTL自动过期来清除缓存。如果业务量非常大,但是对于数据的不一致有比较高的要求,可以设置1秒。如果要求不高可以设置30秒或者分钟级别都可以。但是在软件架构中通常会使用读写分离来提高QPS,由于缓存会导致数据的不一致性,某些场景如需要数据强一致性,可以通过版本号的方式来处理。比如李四读取A数据的时候version=1,同时有用户张三对记录A做了一次操作,那么version=2。这个时候李四是不能对于记录A做变更操作的。

3、 消息队列MQ在微服务中怎么用,有什么好的技巧?使用MQ一定要考虑幂等性吗?

消息队列(MQ)是一种不同应用程序之间(跨进程)的通信方法。消息队列主要有:异步处理 - 增加吞吐量;削峰填谷 - 提高系统稳定性;系统解耦 - 业务边界隔离;数据同步 - 最终一致性保证。在微服务中引入消息队列的目的就是为了减少链路,减少依赖。举例说,用户注册后系统会给用户发积分,发优惠券,以及一些其他初始化操作。如果不用MQ的话,那么需要依赖积分服务,优惠券服务等其他服务。但是对于用户服务来说,只管注册不管其他的衍生服务,所以发送MQ后其他依赖方消费即可。微服务只要配置了重试机制写入接口都需要考虑幂等性。因为需要考虑网络的抖动,数据包会重复提交,如果没有幂等性就会出现脏数据了。使用消息队列也需要使用幂等性,因为消费端可能在某个环节失败后没有commit,导致消息会再次投递的。

4、 使用熔断降级技术需要考虑哪些方面?哪些参数需要调优?

所谓的降级或熔断是针对非核心业务系统,当非核心业务系统因流量过大而出现响应慢,那么部分请求这个接口会出现降级,当达到一定策略之后就会变成熔断。熔断后可以是时候异步做处理。另外一种情况就是手动指定某个接口熔断,例如某电商会在大促的时候把猜你喜欢或者为你推荐给屏蔽。如果没有熔断方式,那么就需要手动写代码,经过开发-测试-预发-线上环节,比较浪费时间。所有的策略都是为了高可用而做铺垫的。一般使用hystrix来做降级熔断功能,可配置的参数非常多,但是重点需要注意的点:circuitBreaker.requestVolumeThreshold circuitBreaker.errorThresholdPercentage execution.isolation.thread.timeoutInMilliseconds hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 另外,需要支持手动打开熔断器,以防止特殊情况下需要主动打开熔断器。

5、微服务面临压力过大怎么自动进行调整或临时做到弹性增加服务?

流量基本上会分成2种:

1、正常业务流量,运营期间大流量(提前知晓)

2、被攻击流量 大量用户请求峰值基本上都会提前预知,比如运营做活动,会预估用户量,根据这个预估的量来事先做容量扩充。如果是突发性的异常大流量,那就怀疑是否被攻击了,需要做相关网络层面的防护了。一般系统都会基本的保护措施,如, 限流:比如针对IP的限流 黑名单:针对IP的黑名单 通过上述方式基本上能拦截很大的非正常流量,然后系统层面对接口做限流以及降级和熔断来保障平台稳定。

弹性扩容是增加系统能支持的QPS量级。这里涉及到几个需要做无状态的核心组件:

1、缓存:缓存是否支持动态增加;

2、DB:这里的DB是指只读丛库 因为微服务天生支持多实例部署,由于能做到1,2了,那么可以根据营销活动的用户量初步预估下系统在高峰期的QPS会有多少,然后再去计算需要增加多少实例,缓存增加多少只读只读实例,DB增加多少只读实例。

同时需要做好如下3点:1、控制好限流和熔断策略,以防止流量压垮服务。2、热门活动场景,本地+远端缓存一起使用;3、活动期间把一些非核心流程先做熔断处理;

6、微服务主要用什么方法保证高可用呢?硬负载均衡设备还是软负载方式保证?

微服务框架本身就支持了同一个服务发布多个应用实例,且部署的应用和注册中心都有心跳检测,以保障应用都是在线状态。同时框架本身会支持负载均衡以及重试机制,可以确保在单个应用宕机的情况下不影响应用,可以说微服务的框架通过软负载的方式来保证了服务的高可用。

谈到高可用,就想到了微服务,为什么说微服务难,其实并不是难在开发阶段,而且对于整个团队的整体性要求高了。其中包括:运维流程,监控体系。

运维流程:是否有持续集成,是否支持链式部署,支持版本回滚。 

监控体系:慢响应,超时、ERROR能否及时的报警通知。

所有要提高微服务的高可用性,不仅仅是研发的事情,而是开发、运维一体才可以。

7、微服务框架部署时的业务连续性如何考虑?

近年金融行业,尤其是银行业监管越来越严格,对业务连续性要求的更高,银行系统对于由传统架构迁移至微服务有较迫切的需求,目前在实际部署系统时,一般需要考虑系统的同城双活或同城、异地多活,以保障业务连续性。那么在迁移至微服务架构的过程中,微服务架构上对于双活、多活的需求是如何考虑的?如何实现异常情况下快速无中断切换、不同中心间数据一致性等问题是否有解决建议?

解答1:

这个问题信息量比较大,同城双活或同城、异地多活甚至目前跨云的多活都是大家所关注的话题。微服务的定义就是服务独立化、动态扩容等一些优点,所以从微服务角度看并不关注多活,双活,只要服务能正常允许即可。但是从架构角度来看,如需要支持多活,双活,那么一些基础设施是否具备了这些特性,比如Redis,Mysql是否支持双主,是否支持主主自动切换,MQ的是否支持。这些工作量非常的大。个人建议在技术能力、人力都不足的情况下不要搞双活,如非得考虑这方案因素,那还是建议去实施主备模式,即每个机房都部署一模一样的系统,当主的出现问题后把流量切到备用上。

解答2:

目前应该还没有微服务跨数据中心的合适技术,跨数据中心,需要解决微服务调度、服务发布的问题,还需要面对时延挑战。所以比较好的方法是一个应用的微服务尽量都尽量在一个数据中心部署,考虑容灾可以在另一个数据中心也部署统一套应用,前端通过负载均衡或者服务治理引流。

解答3:

这个问题其实展开说还是非常复杂的。底层不用区分上层是基于传统的服务方式,还是微服务方式,只需要注意数据同步问题即可。在应用层面,拆分成微服务后,微服务应用数量大量增加,并且会使用到配置中心,注册中心等微服务分布式组件,这些都对网络要求比较高。所以比较好的方式是在一个业务请求在一个机房内完成,同时每个机房部署各自的微服务框架,减少跨机房流量。同时配置相应的微服务监控模块,以及故障自愈。

8、微服务是否一定要Docker容器化?如果是,原因是什么?优缺点都有哪些?

成本角度:docker或者虚拟机将原本单体物理服务器拆分为多台虚拟机,机器之间的资源也是隔离的,所以成本上有很大程度降低。

部署效率:简单说docker和虚拟机都是一个概念,在服务化的场景下docker比虚拟机强的原因其实也很简单,举个例子,明天需要做一个非常大的影响活动,初步估算下每种核心节点服务需要增加10台集群,目前核心服务有12个,即12*10=120台,需要扩容120台机器。虚拟机做法:开通120个虚拟机,配置环境,设置IP,端口,安装应用,启动,调试。按一个熟手没部署一台需要10分钟,那么累计需要1200分钟,约20个小时 docker做法:由于在部署的时候,每个应用都被做成了一个镜像,所以要发布这120个应用,只需要通过脚本或者命令即可,整个过程约1个小时内完成。所以在服务数量不是很多的情况下,用虚机也是能符合要求的。

9、微服务架构下底层数据存储的实现方式?

微服务的底层数据基本上都是异构的,如MySQL、HBase、Redis、ES、hive等等。业务处理都会先直接写入MySQL,然后通过订阅binLog的方式来做数据同步,一般会将binLog的数据写入MQ,消费方在数据处理的时候需要考虑乱序问题。对于要求强一致性的数据一定要携带版号。

10、我们处在微服务+容器的转型探索时期,如何选择微服务框架,以及链路追踪?

框架选择:微服务框架目前比较火的有dubbo和spring cloud,他们各有利弊。spring cloud个全家桶啥都全,但是真正能用好的并不多,无非是组件的堆叠。dubbo也从阿里自己运营转向apache国际化方向,目前互联网大部分公司都是使用dubbo框架,遇到问题也能通过社区快速解决,响应效率比较快,而且有各种技术沙龙可以学习。

链路追踪:APM的选择性比较多,有开源的,有收费的,目前市面的系统基本都是参考Google的Dapper论文来开发的。如果预算充足,可以选择收费的企业版。好处是比较稳定,遇到问题有专人负责解答。如果研发资源充足,又想自己造轮子,可以选择开源版本,如skywalking,Pinpoint,Zipkin,CAT。skywalking,Pinpoint:基本不用修改源码和配置文件,只要在启动命令里指定javaagent参数即可,对于运维人员来讲最为方便;Zipkin:需要对Spring、web.xml之类的配置文件做修改,相对麻烦一些;CAT:需要在程序中硬编码,侵入性比较大。具体选择哪个,这个根据业务团队的熟悉具体产品的程度来决定。

 

 

 

作者:一棵树~
来源链接:https://blog.csdn.net/MyronCham/article/details/113065742

版权声明:
1、JavaClub(https://www.javaclub.cn)以学习交流为目的,由作者投稿、网友推荐和小编整理收藏优秀的IT技术及相关内容,包括但不限于文字、图片、音频、视频、软件、程序等,其均来自互联网,本站不享有版权,版权归原作者所有。

2、本站提供的内容仅用于个人学习、研究或欣赏,以及其他非商业性或非盈利性用途,但同时应遵守著作权法及其他相关法律的规定,不得侵犯相关权利人及本网站的合法权利。
3、本网站内容原作者如不愿意在本网站刊登内容,请及时通知本站(javaclubcn@163.com),我们将第一时间核实后及时予以删除。


本文链接:https://www.javaclub.cn/server/69233.html

标签: 微服务
分享给朋友:

“如何提高微服务的高可用性” 的相关文章

微服务从代码到k8s部署应有尽有系列(五、民宿服务)

微服务从代码到k8s部署应有尽有系列(五、民宿服务)

我们用一个系列来讲解从需求到上线、从代码到k8s部署、从日志到监控等各个方面的微服务完整实践,整个项目使用了go-zero开发,基本包含了go-zero以及go-zero作者开发的一些中间件,所用到的技术栈基本是go-zero的自研组件。我们用一个系列来讲解从需求到上线、从代码到k8s部署、从日志到...

【微服务架构】SpringCloud组件和概念介绍(一)

【微服务架构】SpringCloud组件和概念介绍(一)

一:什么是微服务(Microservice)    微服务英文名称Microservice,Microservice架构模式就是将整个Web应用组织为一系列小的Web服务。这些小的Web服务可以独立地编译及部署,并通过各自暴露的API接口相互通讯。它们彼此相互协作...

AspNet Core Api Restful +Swagger  实现微服务之旅 (三)

AspNet Core Api Restful +Swagger 实现微服务之旅 (三)

       (1)  访问Rest ful接口时 Token验证  返回数据格式封装 (一)访问时Token验证  返回数据格式封装   1.1访问Api接口 方法 实现...

微服务常见安全认证方案Session token cookie跨域

微服务常见安全认证方案Session token cookie跨域

HTTP 基本认证 HTTP Basic Authentication(HTTP 基本认证)是 HTTP 1.0 提出的一种认证机制,这个想必大家都很熟悉了,我不再赘述。HTTP 基本认证的过程如下: 客户端发送 HTTP Request 给服务器。 因为 Req...

2019年7月最新Java微服务资料

2019年7月最新Java微服务资料

大家好,废话不多说,整理了精心收集了各类资源。 声明,如侵犯个人利益,请联系小编,会立即删除相关资料。领取方式在文末 求转发列表 好了,由于资源太多啦,就不一一列举了。大家按照下面的步骤获取吧! 领取方式:...

SpringCloud从入门到进阶(一)——懂生活就懂微服务

SpringCloud从入门到进阶(一)——懂生活就懂微服务

内容   本文通过生活中的实际场景解释单体应用和微服务应用的关系,以及SpringCloud中各组件的功能和含义。 适合人群   Java开发人员 说明   转载请说明出处:SpringCloud从入门到进阶(一)——懂生活就懂微服务   GitHu...

微服务|springcloud系列之-ribbon使用及原理讲解

微服务|springcloud系列之-ribbon使用及原理讲解

目录 什么是负载均衡?​ 为什么使用负载均衡?  什么是ribbon? ribbon与resttemplate整合 ribbon负载均衡源码跟踪 ribbon的常见配置 ribbon面试必问 总结 什...

Dubbo和Spring Cloud对于微服务架构实现上的区别

一、Dubbo和Spring Cloud的概念 微服务架构(MicroServices Architecture,MSA):微服务架构可以看做是面向服务架构和分布式服务架构的拓展,使用更细粒度的服务(所以叫微服务,而SOA的服务粒度很大)和一组设计准则来考虑大规模的复杂系统...

SpringCloud微服务实战——搭建企业级开发框架(三十):整合EasyExcel实现数据表格导入导出功能

  批量上传数据导入、数据统计分析导出,已经基本是系统必不可缺的一项功能,这里从性能和易用性方面考虑,集成EasyExcel。EasyExcel是一个基于Java的简单、省内存的读写Excel的开源项目,在尽可能节约内存的情况下支持读写百M的Excel:   Java解析、生成Exce...

我对微服务、SpringCloud、k8s、Istio的一些杂想

我对微服务、SpringCloud、k8s、Istio的一些杂想

一、微服务与SOA        “微服务”是一个名词,没有这个名词之前也有“微服务”,一个朗朗上口的名词能让大家产生一个认知共识,这对推动一个事务的发展挺重要的,不然你叫微服务他叫小服务的大家很难集中到一个点上。 业界对微服务与SO...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。