如何提升微服务的幸福感 | 凌云时刻
凌云时刻 · 技术
导读:随着微服务的流行,越来越多公司使用了微服务框架,微服务以其高内聚、低耦合等特性,提供了更好的容错性,也更适应业务的快速迭代,为开发人员带来了很多的便利性。但是随着业务的发展,微服务拆分越来越复杂,微服务的治理也成了一个比较令人头疼的问题.
作者 | 亦盏
来源 | 凌云时刻(微信号:linuxpk)
前言
我相信下面这些场景大家或多或少都遇到过。
场景一:发布是天大的事情,每一次的发布,都会出现执行到一半的请求中断掉,上游继续调用已经下线的节点导致报错的现象。发布时收到各种报错,同时还影响用户的体验,发布后又需要修复执行到一半的脏数据。
上述场景还是在新版本没有任何问题的情况下,如果新版本有问题,则会导致大量业务直接请求到有问题的新版本,轻则修复数据,重则严重影响用户体验,甚至产生资损。最后不得不每次发版都安排在凌晨两三点发布,心惊胆颤,睡眠不足,苦不可言。
场景二:大半夜某个服务节点出现异常,上游仍旧不断地调用,出现很多异常和各种报警短信。被报警吵醒后,想直接在线上修复,有点难,想保留现场又害怕拖垮整个应用,只好先重启为上。
但是这只是治标不治本的方式,因为很难复现从而无法有效定位,可能明天又被吵醒,继续重启。上述场景还是建立在报警系统比较完善的情况下,如果没有完善的报警系统,严重情况可能整个业务系统都被单机异常拖垮。
场景三:公司业务壮大了,部门组织变复杂后,微服务模块越来越多。我不清楚发布的服务到底被谁调用了,所以我不知道能否安全地下线一个服务。我这个应用的这个接口是个敏感接口,我只希望得到我授权的应用才能调用,而不是直接从服务注册中心得到我的地址就能直接调用,但是目前好像还做不到。
以上三个场景确实是使用微服务之后带来的痛点,这时候有个人告诉你,这些问题,我都知道怎么搞定,我有着丰富的经验,知道怎么解决,你肯定很开心。
然后高薪请进来了,确实不错,各种架构图、框架原理,框架修改点都非常清晰而且功能确实完美。最后评估对当前系统的修改成本,需要搭建三套中间件服务端,增加 4 个中间件依赖,修改几万行代码和配置。
“打扰了,还是业务重要,产品经理给的需求还没完成呢,刚刚说的场景也没那么痛苦,不就几个小问题嘛,真的没事。”
这时候 EDAS 告诉你,EDAS 的微服务解决方案,不需要做任何的代码和配置的修改,就能完美地解决上面说的三个场景中的问题。
你,不心动吗?
是的,你没看错,只要你的应用是基于 Spring Cloud 或 Dubbo 最近五年内的版本开发,就能直接使用完整的 EDAS 微服务治理能力,不需要修改任何代码和配置。
为什么 EDAS 用户可以轻松发布
传统的发布流程中,服务提供者停止再启动,服务消费者感知到服务提供者节点停止的流程如下:
1、服务发布前,消费者根据负载均衡规则调用服务提供者,业务正常。
2、服务提供者 B 需要发布新版本,先对其中的一个节点进行操作,首先是停止 Java 进程。
3、服务停止过程,又分为主动注销和被动注销,主动注销是准实时的,被动注销的时间由不同的注册中心决定,最差的情况会需要 1 分钟。
如果应用是正常停止,Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被执行,这一步的耗时可以忽略不计。
如果应用是非正常停止,比如直接使用 kill -9 停止,或者 Docker 镜像构建的时候 Java 应用不是 1 号进程且没有把 kill 信号传递给应用。那么服务提供者不会主动去注销服务节点,而是在超过一段时间后由于心跳超时而被动地被注册中心摘除。
4、服务注册中心通知消费者,其中的一个服务提供者节点已下线。包含推送和轮询两种方式,推送可以认为是准实时的,轮询的耗时由服务消费者轮询间隔决定,最差的情况下需要 1 分钟。
5、服务消费者刷新服务列表,感知到服务提供者已经下线了一个节点,这一步对于 Dubbo 框架来说不存在,但是 Spring Cloud 的负载均衡组件 Ribbon 默认的刷新时间是 30 秒 ,最差情况下需要耗时 30 秒。
6、服务消费者不再调用已经下线的节点。
从第 2 步到第 6 步的过程中,Eureka 在最差的情况下需要耗时 2 分钟,Nacos 在最差的情况下需要耗时 50 秒。在这段时间内,请求都有可能出现问题,所以发布时会出现各种报错,同时还影响用户的体验,发布后又需要修复执行到一半的脏数据。最后不得不每次发版都安排在凌晨两三点发布,心惊胆颤,睡眠不足,苦不可言。
为什么 EDAS 用户不需要修数据
当您的应用部署到 EDAS 之后,EDAS 的无损下线功能会自动在发布新版本的时候做如下的增强,我们主要关注绿色部分的信息:
1、应用在发布前主动向注册中心注销应用,并将应用标记为已下线的状态。
2、在接收到服务消费者请求时,首先会正常处理本次调用,并通知服务消费者此节点已下线,服务消费者会立即从调用列表删除此节点。
3、在这之后,服务消费者不再调用已经下线的节点。
EDAS 的无损下线功能,将原来的从原来的 停止进程阶段 注销服务变成了 prestop 阶段注销服务,将原来的依赖于 注册中心推送,做到了服务提供者直接通知消费者从调用列表中摘除自己。使得下线感知的时间大大减短,从原来的分钟级别做到准实时,确保您的应用在下线时能做到业务无损。
金丝雀发布为 EDAS 用户再加一重保障
在普通的新版本发布场景中,默认情况下请求到各个节点的流量是均匀分布的。
假设服务提供者有 4 台,只要某个节点一发布新版本,就会有 25% 的流量打到新版本。如果新版本存在问题,就会影响线上 25% 的流量,轻则修复数据,重则严重影响用户体验,甚至产生资损。
EDAS 提供的金丝雀发布功能,支持 EDAS 用户在发布新版本之前就提前配置好金丝雀规则,使得只有符合流量特征的流量会调用到新版本,从而可以精准地控制调用到新版本的流量,进行新版本验证。
如图所示,EDAS 的用户可以在发布之前配置好金丝雀规则。
这里以 Dubbo 为例,下图中配置表明 调用
com.alibaba.edas.demo.EchoService.echo(String string) 的流量中,只有参数为 "helloworld" 的流量才会被路由到新版本。
在服务提供者的将服务注册到注册中心前,EDAS 已经将新版本对应的金丝雀规则推送到服务消费者端。服务消费者在调用的时候,会根据金丝雀规则对流量进行分析,并与服务提供者列表中的元数据进行比对,选择正确的调用地址。
除了上图中演示的简单参数比对之外,EDAS 也支持解析更复杂的结构体进行规则配置。当然,如果某个场景只需要控制流量百分比就能满足需求,EDAS 用户也可以直接按比例进行灰度。
EDAS 金丝雀发布 将路由到新版本的流量,从所占总节点数的百分比转变成了根据流量特征进行控制。您可以自由地控制路由到新版本的流量,比如只将内部测试账号的流量路由到新版本,从而做到小心发布、大胆验证。所以,赶紧来 EDAS 进行轻松发布吧。
为什么 EDAS 用户不需要半夜醒来重启机器
开源框架有可能被单点异常拖垮整个应用系统
在微服务架构中,当服务提供者的应用实例出现异常时,服务消费者无法及时感知,会影响服务的正常调用,进而影响消费者的服务性能甚至可用性。
在上图的示例场景中,系统包含 4 个应用,A、B、C 和 D,其中应用 A 会分别调用应用 B、C 和 D。当应用 B、C 或 D 的某些实例异常时(如图中应用 B、C 和 D 标识的各有 1个和 2 个异常实例),如果应用 A 无法感知,会导致部分调用失败;如果业务代码写的不够优雅,有可能影响应用 A 的性能甚至整个系统的可用性。
离群实例摘除给业务系统的稳定性加把锁
为了保护应用的服务性能和可用性,EDAS 支持检测应用实例的可用性并进行动态调整,以保证服务成功调用,从而提升业务的稳定性和服务质量。
如下图所示,EDAS 用户可以在控制台上对应用 A 进行如下配置,从而保证 A 应用的稳定性。
1、异常类型,网络异常指的是 IOException,业务异常在 Spring Cloud 框架中指的是返回值 http 状态码 为 500 ,Dubbo 框架中指的是返回值中包含 Exception。
2、QPS 下限,为了避免调用次数太少,随机性较大从而影响判断的准确性,您可以设置 QPS 的下限,只有 QPS 达到一定值后才进行离群摘除判断。默认为 1 ,可以配置成 0。
3、错误率下限,如果某台服务提供者返回值中,错误的比例超过了配置的这个值,会被判定成需要被摘除。
4、摘除实例比例上限,为了避免摘除过多的机器节点,导致剩余的节点数流量过载,需要配置一个摘除比例的上限,建议不超过 50%。
5、恢复检测单位时间,离群节点被摘除的动作是暂时性的,经过单位时间后,消费者侧会对此节点进行检测。如果节点已经恢复,会将其放回到节点中。如果节点持续被摘除,那么它被摘除的时间会线性增加到最大值。
基于离群实例摘除功能,EDAS 用户不会因为单机异常在半夜醒来重启机器,先安心地睡一觉吧,反正业务也不会受影响。醒来之后机器现场也还在,是拿着保留的现场进行分析,还是直接重启,任君选择。
为什么 EDAS 用户对自己的服务胸有成竹
服务查询一目了然
http://www.taodudu.cc/news/show-1871115.html
相关文章:
- 云原生时代,消息中间件的演进路线 | 凌云时刻
- 进阶之路:深入解读 Java 堆外内存 | 凌云时刻
- Kafka开源转商业实践,助力车主无忧系统稳健 | 凌云时刻
- Kafka从上手到实践 - 初步认知:MQ系统 | 凌云时刻
- Kafka从上手到实践 - 庖丁解牛:Partition | 凌云时刻
- Kafka从上手到实践 - 庖丁解牛:Topic Broker | 凌云时刻
- 开源界也要封闭,OpenSource能否继续无国界 | 凌云时刻
- Code Review 是一场苦涩但有意思的修行 | 凌云时刻
- Kafka从上手到实践 - 庖丁解牛:Producer | 凌云时刻
- Kafka从上手到实践 - 庖丁解牛:Consumer | 凌云时刻
- 全球CT影像20秒诊断,阿里云为新冠AI辅助诊断系统加速 | 凌云时刻
- Kafka从上手到实践 - 实践真知:搭建单机Kafka | 凌云时刻
- 智能制造的灾备问题如何解决? | 凌云时刻
- 开源流媒体服务器:为何一定得再撸个新的 | 凌云时刻
- Kafka从上手到实践 - Kafka CLI:Topic CLI Producer CLI | 凌云时刻
- 啥是数据湖?老子(zǐ)告诉你 | 凌云时刻
- Kafka从上手到实践 - Kafka CLI:Consumer CLI Producer CLI | 凌云时刻
- eBPF Internal: Instructions and Runtime | 凌云时刻
- Kafka从上手到实践 - Kafka CLI:Reseting Offset Config CLI | 凌云时刻
- Kafka从上手到实践 - 实践真知:Kafka Java Producer | 凌云时刻
- 云计算摆摊的可行性分析 | 凌云时刻
- Kafka从上手到实践 - 实践真知:Kafka Java Consumer | 凌云时刻
- 2020阿里云线上峰会预告
- Kafka从上手到实践 - 初步认知:Zookeeper | 凌云时刻
- IT人的地摊不就是开源么 | 凌云时刻
- 官宣!什么是新基建时代的混合云? | 凌云时刻
- 2020阿里云线上峰会预告 | 凌云时刻
- 可用性SLA还不懂?看完这个故事就懂了........ | 凌云时刻
- Kafka从上手到实践-Zookeeper CLI:CRUD zNode | 凌云时刻
- 不能错过!CIO不可不知的“数据经济学” | 凌云时刻
如何提升微服务的幸福感 | 凌云时刻相关推荐
- 如何提升微服务的幸福感?
作者 | 亦盏 前言 随着微服务的流行,越来越多公司使用了微服务框架,微服务以其高内聚.低耦合等特性,提供了更好的容错性,也更适应业务的快速迭代,为开发人员带来了很多的便利性.但是随着业务的发展, ...
- 如何提升微服务的幸福感
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试文章 Photo @ Andreas Weiland 文 | 亦盏 ...
- 阿里云 EDAS 3.0 助力唱鸭提升微服务幸福感
简介:EDAS 3.0 提供的微服务治理,很好的支持了唱鸭 APP 实现微服务应用的发布.监控.管理等日常业务场景.作为运维侧的重要平台和开框架的提供者,EDAS 3.0 帮助用户可以更专注业务.微服 ...
- 从开源自治,到微服务云化,阿里云的这款产品给了一剂提升微服务幸福感的良药
简介:微服务发展至今,因其高内聚.低耦合等特性,以及诸多开源方案带来的开放性,已成为提升架构效率的最佳实践之一.当一项技术或一个框架成为事实标准之后,我们会把更多的注意力聚焦在运维效率和应用可用性的持 ...
- 从开源自治到微服务云化,用这剂良药提升微服务幸福感
前言 微服务发展至今,因其高内聚.低耦合等特性,以及诸多开源方案带来的开放性,已成为提升架构效率的最佳实践之一.当一项技术或一个框架成为事实标准之后,我们会把更多的注意力聚焦在运维效率和应用可用性的持 ...
- 独家:为了永不停机的计算服务 - 五月月刊 | 凌云时刻
凌云时刻 · 极鲜速递 导读:伟大的事业非一日所能成就,不积小流,无以成江海.今日,带你看阿里云智能基础产品在五月所积"跬步". 作者 | 阿里云基础产品 来源 | 凌云时刻(微信 ...
- Game On Serverless:SAE 助力广州小迈提升微服务研发效能
作者:洛浩 小迈于 2015 年 1 月成立,是一家致力以数字化领先为优势,实现业务高质量自增长的移动互联网科技公司.始终坚持以用户价值为中心,以数据为驱动,为用户开发丰富的工具应用.休闲游戏.益智. ...
- 想提升微服务容错性?试试这5种模式
作者 | Igor Perikov 译者 | 陆离 责编 | 徐威龙 出品 | CSDN云计算(ID:CSDNcloud) 在本文中,我将介绍微服务中的几种容错机制及其实现的方法.如果你在维基百科上 ...
- 微服务架构-系统可靠性保障
1.可靠性 可靠性(Reliability)是指微服务系统在面对异常情况时,如关键组件损坏.流量或数据量异常.延迟波动.级联故障传导.分布式集群雪崩.系统过载等等,能够持续保持稳定运行或快速恢复的能力 ...
- GitChat · 架构 | 为什么微服务实施那么难?如何高效推进微服务架构演进
GitChat 作者:顾宇 原文:为什么微服务实施那么难?如何高效推进微服务架构演进 关注公众号:GitChat 技术杂谈,一本正经的讲技术 前言 笔者从 2013 年加入 ThoughtWorks ...
最新文章
- 高校10余位博士抱着孩子参加授位仪式萌翻全场!科研人抱娃毕业成趋势?
- tomcat 修改默认访问根目录
- 人脸对齐端到端Super-FAN
- 【快乐水题】1816. 截断句子
- HTTP Developer's Handbook Part V: Security 读书笔记
- android显示网络图片控件,Android控件之ImageView(二)
- codeigniter mysql查询_php – CodeIgniter MySQL查询不起作用
- 评教数据的存储和显示问题
- c语言字符合法,C语言字符数据的合法形式
- 蓝屏代码查询器1.1.8
- NeoKylin7用户和组管理
- 政府不能替代微软“查户口”
- Python画一个中国地图玩玩
- php 在服务器运行不起,PHP Cookies在localhost上运行良好,但在实时服务器上不起作用...
- Spring boot启动报错ERROR 5208 --- [ restartedMain] o.s.b.d.LoggingFailureAnalysisReporter
- 华为鸿蒙HarmonyOS 简介
- 阿拉伯数字转换成大写的数字
- 滤镜怎么调好看?分享给图片调色的教程
- 心脏滴血漏洞简单攻击
- win10 设置定时关机