专业网站建设行业现状,网页设计师个人简历,软文网站有哪些,wordpress 图片加速简介#xff1a;本篇是微服务高可用最佳实践系列分享的开篇#xff0c;系列内容持续更新中#xff0c;期待大家的关注。
作者#xff1a;三辰#xff5c;阿里云云原生微服务基础架构团队技术专家#xff0c;负责 MSE 引擎高可用架构 本篇是微服务高可用最佳实践系列分享…简介本篇是微服务高可用最佳实践系列分享的开篇系列内容持续更新中期待大家的关注。
作者三辰阿里云云原生微服务基础架构团队技术专家负责 MSE 引擎高可用架构 本篇是微服务高可用最佳实践系列分享的开篇系列内容持续更新中期待大家的关注。 引言
在开始正式内容之前先给大家分享一个真实的案例。 某客户在阿里云上使用 K8s 集群部署了许多自己的微服务但是某一天其中一台节点的网卡发生了异常最终导致服务不可用无法调用下游业务受损。 我们来看一下这个问题链是如何形成的
ECS 故障节点上运行着 K8s 集群的核心基础组件 CoreDNS 的所有 Pod它没有打散导致集群 DNS 解析出现问题。 该客户的服务发现使用了有缺陷的客户端版本nacos-client 的 1.4.1 版本这个版本的缺陷就是跟 DNS 有关——心跳请求在域名解析失败后会导致进程后续不会再续约心跳只有重启才能恢复。 这个缺陷版本实际上是已知问题阿里云在 5 月份推送了 nacos-client 1.4.1 存在严重 bug 的公告但客户研发未收到通知进而在生产环境中使用了这个版本。风险环环相扣缺一不可。
最终导致故障的原因是服务无法调用下游可用性降低业务受损。下图示意的是客户端缺陷导致问题的根因 Provider 客户端在心跳续约时发生 DNS 异常心跳线程正确地处理这个 DNS 异常导致线程意外退出了注册中心的正常机制是心跳不续约30 秒后自动下线。由于 CoreDNS 影响的是整个 K8s 集群的 DNS 解析所以 Provider 的所有实例都遇到相同的问题整个服务所有实例都被下线在 Consumer 这一侧收到推送的空列表后无法找到下游那么调用它的上游比如网关就会发生异常。
回顾整个案例每一环每个风险看起来发生概率都很小但是一旦发生就会造成恶劣的影响。
所以本篇文章就来探讨微服务领域的高可用方案怎么设计细化到服务发现和配置管理领域都有哪些具体的方案。
微服务高可用方案
首先有一个事实不容改变没有任何系统是百分百没有问题的所以高可用架构方案就是面对失败风险设计的。
风险是无处不在的尽管有很多发生概率很小很小却都无法完全避免。
在微服务系统中都有哪些风险的可能 这只是其中一部分但是在阿里巴巴内部十几年的微服务实践过程中这些问题全部都遇到过而且有些还不止一次。
虽然看起来坑很多但我们依然能够很好地保障双十一大促的稳定背后靠的就是成熟稳健的高可用体系建设。
我们不能完全避免风险的发生但我们可以控制它的影响这就是做高可用的本质。
控制风险有哪些策略
注册配置中心在微服务体系的核心链路上牵一发动全身任何一个抖动都可能会较大范围地影响整个系统的稳定性。策略一缩小风险影响范围
集群高可用
多副本不少于 3 个节点进行实例部署。多可用区同城容灾将集群的不同节点部署在不同可用区AZ中。当节点或可用区发生的故障时影响范围只是集群其中的一部分如果能够做到迅速切换并将故障节点自动离群就能尽可能减少影响。
减少上下游依赖
系统设计上应该尽可能地减少上下游依赖越多的依赖可能会在被依赖系统发生问题时让整体服务不可用一般是一个功能块的不可用。如果有必要的依赖也必须要求是高可用的架构。
变更可灰度
新版本迭代发布应该从最小范围开始灰度按用户、按 Region 分级逐步扩大变更范围。一旦出现问题也只是在灰度范围内造成影响缩小问题爆炸半径。
服务可降级、限流、熔断
注册中心异常负载的情况下降级心跳续约时间、降级一些非核心功能等针对异常流量进行限流将流量限制在容量范围内保护部分流量是可用的客户端侧异常时降级到使用本地缓存推空保护也是一种降级方案暂时牺牲列表更新的一致性以保证可用性如图微服务引擎 MSE 的同城双活三节点的架构经过精简的上下游依赖每一个都保证高可用架构。多节点的 MSE 实例通过底层的调度能力会自动分配到不同的可用区上组成多副本集群。
策略二缩短风险发生持续时间
核心思路就是尽早识别、尽快处理
识别 —— 可观测
例如基于 Prometheus 对实例进行监控和报警能力建设。 进一步地在产品层面上做更强的观测能力包括大盘、告警收敛/分级识别问题、针对大客户的保障、以及服务等级的建设。 MSE注册配置中心目前提供的服务等级是 99.95%并且正在向 4 个 999.99%迈进。 快速处理 —— 应急响应
应急响应的机制要建立快速有效地通知到正确的人员范围快速执行预案的能力意识到白屏与黑屏的效率差异常态化地进行故障应急的演练。 预案是指不管熟不熟悉你的系统的人都可以放心执行这背后需要一套沉淀好有含金量的技术支撑技术厚度。 策略三减少触碰风险的次数
减少不必要的发布例如增加迭代效率不随意发布重要事件、大促期间进行封网。 从概率角度来看无论风险概率有多低不断尝试风险发生的联合概率就会无限趋近于 1。 策略四降低风险发生概率
架构升级改进设计
Nacos2.0不仅是性能做了提升也做了架构上的升级
升级数据存储结构Service 级粒度提升到到 Instance 级分区容错绕开了 Service 级数据不一致造成的服务挂的问题升级连接模型长连接减少对线程、连接、DNS 的依赖。
提前发现风险
这个「提前」是指在设计、研发、测试阶段尽可能地暴露潜在风险提前通过容量评估预知容量风险水位是在哪里通过定期的故障演练提前发现上下游环境风险验证系统健壮性。如图阿里巴巴大促高可用体系不断做压测演练、验证系统健壮性和弹性、观测追踪系统问题、验证限流、降级等预案的可执行性。
服务发现高可用方案
服务发现包含服务消费者Consumer和服务提供者Provider。
Consumer 端高可用
通过推空保护、服务降级等手段达到 Consumer 端的容灾目的。
推空保护
可以应对开头讲的案例服务空列表推送自动降级到缓存数据。
服务消费者Consumer会从注册中心上订阅服务提供者Provider的实例列表。
当遇到突发情况例如可用区断网Provider端无法上报心跳 或 注册中心变配、重启、升降级出现非预期异常时都有可能导致订阅异常影响服务消费者Consumer的可用性。 无推空保护
Provider 端注册失败比如网络、SDKbug 等原因注册中心判断 Provider 心跳过期Consumer 订阅到空列表业务中断报错
开启推空保护
同上Consumer 订阅到空列表推空保护生效丢弃变更保障业务服务可用
开启方式
开启方式比较简单 开源的客户端 nacos-client 1.4.2 以上版本支持 配置项
SpingCloudAlibaba 在 spring 配置项里增加spring.cloud.nacos.discovery.namingPushEmptyProtectiontrueDubbo 加上 registryUrl 的参数namingPushEmptyProtectiontrue
提空保护依赖缓存所以需要持久化缓存目录避免重启后丢失路径为${user.home}/nacos/naming/${namespaceId}
服务降级
Consumer 端可以根据不同的策略选择是否将某个调用接口降级起到对业务请求流程的保护将宝贵的下游 Provider 资源保留给重要的业务 Consumer 使用保护重要业务的可用性。 服务降级的具体策略包含返回 Null 值、返回 Exception 异常、返回自定义 JSON 数据和自定义回调。
MSE 微服务治理中心中默认就具备该项高可用能力。
Provider 端高可用
Provider 侧通过注册中心和服务治理提供的容灾保护、离群摘除、无损下线等方案提升可用性。
容灾保护
容灾保护主要用于避免集群在异常流量下出现雪崩的场景。
下面我们来具体看一下 无容灾保护默认阈值 0
突发请求量增加容量水位较高时个别 Provider 发生故障注册中心将故障节点摘除全量流量会给剩余节点剩余节点负载变高大概率也会故障最后所有节点故障100% 无法提供服务。
开启容灾保护阈值0.6
同上故障节点数达到保护阈值流量平摊给所有机器最终保障 50% 节点能够提供服务。
容灾保护能力在紧急情况下能够保存服务可用性在一定的水平之上可以说是整体系统的兜底了。 这套方案曾经救过不少业务系统。
离群实例摘除
心跳续约是注册中心感知实例可用性的基本途径。
但是在特定情况下心跳存续并不能完全等同于服务可用。
因为仍然存在心跳正常但服务不可用的情况例如
Request 处理的线程池满依赖的 RDS 连接异常或慢 SQL
微服务治理中心提供离群实例摘除
基于异常检测的摘除策略包含网络异常和网络异常 业务异常HTTP 5xx设置异常阈值、QPS 下限、摘除比例下限
离群实例摘除的能力是一个补充根据特定接口的调用异常特征来衡量服务的可用性。
无损下线
无损下线又叫优雅下线、或者平滑下线都是一个意思。首先看什么是有损下线
Provider 实例进行升级过程中下线后心跳在注册中心存约以及变更生效都有一定的时间在这个期间 Consumer 端订阅列表仍然没有更新到下线后的版本如果鲁莽地将 Provider 停止服务会造成一部分的流量损失。
无损下线有很多不同的解决方案但侵入性最低的还是服务治理中心默认提供的能力无感地整合到发布流程中完成自动执行。免去繁琐的运维脚本逻辑的维护。
配置管理高可用方案
配置管理主要包含配置订阅和配置发布两类操作。
配置管理解决什么问题
多环境、多机器的配置发布、配置动态实时推送。
基于配置管理做服务高可用
微服务如何基于配置管理做高可用方案
发布环境管理
一次管理上百台机器、多套环境如何正确无误地推送、误操作或出现线上问题如何快速回滚发布过程如何灰度。
业务开关动态推送
功能、活动页面等开关。
容灾降级预案的推送
预置的方案通过推送开启实时调整流控阈值等。 上图是大促期间配置管理整体高可用解决方案。比如降级非核心业务、功能降级、日志降级、禁用高风险操作。
客户端高可用
配置管理客户端侧同样有容灾方案。
本地目录分为两级高优先级是容灾目录、低优先级是缓存目录。
缓存目录每次客户端和配置中心进行数据交互后会保存最新的配置内容至本地缓存目录中当服务端不可用状态下会使用本地缓存目录中内容。
容灾目录当服务端不可用状态下可以在本地的容灾目录中手动更新配置内容客户端会优先加载容灾目录下的内容模拟服务端变更推送的效果。 简单来说当配置中心不可用时优先查看容灾目录的配置否则使用之前拉取到的缓存。
容灾目录的设计是因为有时候不一定会有缓存过的配置或者业务需要紧急覆盖使用新的内容开启一些必要的预案和配置。
整体思路就是无法发生什么问题无论如何都要能够使客户端能够读取到正确的配置保证微服务的可用性。
服务端高可用
在配置中心侧主要是针对读、写的限流。 限制连接数、限制写
限连接单机最大连接限流单客户端 IP 的连接限流限写接口发布操作特定配置的秒级分钟级数量限流
控制操作风险
控制人员做配置发布的风险。
配置发布的操作是可灰度、可追溯、可回滚的。
配置灰度 发布历史回滚 变更对比 动手实践
最后我们一起来做一个实践。
场景取自前面提到的一个高可用方案在服务提供者所有机器发生注册异常的情况下看服务消费者在推空保护打开的情况下的表现。
实验架构和思路 上图是本次实践的架构右侧是一个简单的调用场景外部流量通过网关接入这里选择了 MSE 产品矩阵中的云原生网关依靠它提供的可观测能力方便我们观察服务调用情况。
网关的下游有 A、B、C 三个应用支持使用配置管理的方式动态地将调用关系连接起来后面我们会实践到。
基本思路
部署服务调整调用关系是网关-A-B-C查看网关调用成功率。通过模拟网络问题将应用B与注册中心的心跳链路断开模拟注册异常的发生。再次查看网关调用成功率期望服务 A-B 的链路不受注册异常的影响。
为了方便对照应用 A 会部署两种版本一种是开启推空保护的一种是没有开启的情况。
最终期望的结果是推空保护开关开启后能够帮助应用 A 在发生异常的情况下继续能够寻址到应用B。
网关的流量打到应用 A 之后可以观察到接口的成功率应该正好在 50%。
开始
接下来开始动手实践吧。这里我选用阿里云 MSEACK 组合做完整的方案。
环境准备
首先购买好一套 MSE 注册配置中心专业版和一套 MSE 云原生网关。这边不介绍具体的购买流程。
在应用部署前提前准备好配置。这边我们可以先配置 A 的下游是 CB 的下游也是 C。 部署应用
接下来我们基于 ACK 部署三个应用。可以从下面的配置看到应用 A 这个版本 spring-cloud-a-b推空保护开关已经打开。 这里 demo 选用的 nacos 客户端版本是 1.4.2因为推空保护在这个版本之后才支持。
配置示意无法直接使用
# A 应用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: spring-cloud-aname: spring-cloud-a-b
spec:replicas: 2selector:matchLabels:app: spring-cloud-atemplate:metadata:annotations:msePilotCreateAppName: spring-cloud-alabels:app: spring-cloud-aspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.discovery.metadata.versionvalue: base- name: spring.application.namevalue: sc-A- name: spring.cloud.nacos.discovery.namingPushEmptyProtectionvalue: trueimage: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-aports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: spring-cloud-aname: spring-cloud-a
spec:replicas: 2selector:matchLabels:app: spring-cloud-atemplate:metadata:annotations:msePilotCreateAppName: spring-cloud-alabels:app: spring-cloud-aspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.discovery.metadata.versionvalue: base- name: spring.application.namevalue: sc-Aimage: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-aports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi
# B 应用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: spring-cloud-bname: spring-cloud-b
spec:replicas: 2selector:matchLabels:app: spring-cloud-bstrategy:template:metadata:annotations:msePilotCreateAppName: spring-cloud-blabels:app: spring-cloud-bspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.application.namevalue: sc-Bimage: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-bports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi
# C 应用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: spring-cloud-cname: spring-cloud-c
spec:replicas: 2selector:matchLabels:app: spring-cloud-ctemplate:metadata:annotations:msePilotCreateAppName: spring-cloud-clabels:app: spring-cloud-cspec:containers:- env:- name: LANGvalue: C.UTF-8- name: spring.cloud.nacos.discovery.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.cloud.nacos.config.server-addrvalue: mse-xxx-nacos-ans.mse.aliyuncs.com:8848- name: spring.application.namevalue: sc-Cimage: mse-demo/demo:1.4.2imagePullPolicy: Alwaysname: spring-cloud-cports:- containerPort: 8080protocol: TCPresources:requests:cpu: 250mmemory: 512Mi
部署应用 在网关注册服务
应用部署好之后在 MSE 云原生网关中关联上 MSE 的注册中心并将服务注册进来。 我们设计的是网关只调用 A所以只需要将 A 放进来注册进来即可。 验证和调整链路
基于 curl 命令验证一下链路
$ curl http://${网关IP}/ip
sc-A[192.168.1.194] -- sc-C[192.168.1.195]验证一下链路。 可以看到这时候 A 调用的是 C我们将配置做一下变更实时地将 A 的下游改为 B。 再看一下这时三个应用的调用关系是 ABC符合我们之前的计划。
$ curl http://${网关IP}/ip
sc-A[192.168.1.194] -- sc-B[192.168.1.191] -- sc-C[192.168.1.180]接下来我们通过一段命令连续地调用接口模拟真实场景下不间断的业务流量。
$ while true; do sleep .1 ; curl -so /dev/null http://${网关IP}/ip ;done观测调用
通过网关监控大盘可以观察到成功率。 注入故障
一切正常现在我们可以开始注入故障。
这里我们可以使用 K8s 的 NetworkPolicy 的机制模拟出口网络异常。
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:name: block-registry-from-b
spec:podSelector:matchLabels:app: spring-cloud-bingress:- {}egress:- to:- ipBlock:cidr: 0.0.0.0/0ports:- protocol: TCPport: 8080
这个 8080 端口的意思是不影响内网调用下游的应用端口只禁用其它出口流量比如到达注册中心的 8848 端口就被禁用了。这里 B 的下游是 C。
网络切断后注册中心的心跳续约不上过一会儿30 秒后就会将应用 B 的所有 IP 摘除。
再次观测
再观察大盘数据库成功率开始下降这时候在控制台上已经看不到应用 B 的 IP 了。 回到大盘成功率在 50% 附近不再波动。 小结
通过实践我们模拟了一次真实的风险发生的场景并且通过客户端的高可用方案推空保护成功实现了对风险的控制防止服务调用的发生异常。
原文链接
本文为阿里云原创内容未经允许不得转载。
