梦飞科技 > 中国IDC > 云计算 > 云技术 > 避免大规模故障的微服务架构设计之道

避免大规模故障的微服务架构设计之道

本文首先介绍微服务架构存在的风险,然后针对如何避免微服务架构的故障,提出了多种有效的微服务架构中的方法和技术,其中例如服务降级、变更管理、健康检查和修复、断路器、限流器等。

微服务架构通过定义明确的服务边界,能有效地隔离故障。 和其他分布式系统一样,微服务在网络、硬件和应用层上都会存在更多的问题。由于服务之间是互相依赖,因此任何组件都可能出错导致用户不能访问。为尽可能减少部分中断带来的影响,我们需要构建容错能力强的服务,以从容应对发生的某些中断。

本文在RisingStack’s Node.js Consulting & Development experience一文基础上,介绍了构建和运维高可用的微服务架构系统中最常用的技术和架构模式。

如果读者不熟悉上文中的模式,那并没什么大碍。构建可靠的系统不是一踞而就的。

微服务架构的风险

微服务架构将应用逻辑拆分成服务,服务之间通过网络交互。由于是通过网络调用,而不是在进程中调用,因此这给需要在多个物理和逻辑组件间进行协作的系统带来了潜在的问题和复杂性。分布式系统变得越来越复杂,也导致网络特定故障发生的可能性增大。 

相比传统应用庞大的结构,微服务架构最大的一个优点是团队能独立地设计、开发和部署各自的服务。团队能掌控各自服务的整个生命周期。这也意味者团队无法控制服务的依赖关系,因为这些依赖的服务可能是由其他团队管理。在微服务架构体系下,我们要牢记提供的服务由于是其他人控制,因此可能会由于发布、配置、和其他变更等原因,从而导致服务暂时不可用,而且组件之间互相独立。 

优雅的服务降级

微服务架构最大的优点之一就是当组件出现故障时,能隔离这些故障并且能做到优雅地服务降级。比如,在图片分享应用中,当出现故障时,用户可能无法上传图片,但他们依然能浏览、编辑和分享已上传的图片。 

微服务架构776

微服务故障独立(理论上)

在大多数情况下,是很难实现上图这种优雅地服务降级的,因为在分布式环境下,应用都是互相依赖的,开发者需要实现若干错误处理的逻辑(该部分在本文稍后部分讨论)去应对短暂的故障和中断。

微服务架构881

服务互相依赖,如果无故障转移的逻辑,则会同时失效

变更管理

Google的网站可靠性团队发现大概70%的故障都是由于变更而引起的。当对服务进行修改时—例如发布代码的新版本或者改变一些配置,则总会有可能引起故障或者引入新的错误。

在微服务架构中,服务是互相依赖的。这就是为什么你需要减少故障并且尽可能降低它们的负面影响。为了应对变更带来的问题,你可以实施变更策略管理并且实现其自动回滚。

比如,国外域名 免费域名,当部署新的代码或者修改配置时,应该分步将这些变更部署到服务实例群中的部分实例中,并且进行监控,如果发现关键指标出现问题则能自动进行回滚。

微服务架构1155

变更管理-回滚部署

另一个解决方案是运行两套生产环境。部署的时候只部署变更的应用到其中一套环境中,并且在验证了新发布的版本符合预期后,才将负责均衡的流量指向新的应用,这种方法称为“蓝-绿发布”或者“红-黑发布”。

回退代码并不是坏事情。你不应该在生产环境中部署有问题的代码,并且应该琢磨哪里出错了。当必要时候应该果断回退代码,这越早越好。

健康检查和负载均衡

因为故障或部署、自动扩展等原因,服务实例会不停启动,重新启动及停止。这使得服务暂时或一直停用。为了避免发生这些问题,在负载均衡中应该在路由中设置忽略这些实例,因为它们无法为子系统或用户提供服务。 

我们可以通过外部观察去判断应用实例是否健康。你可以多次调用 

Get /health的端点(endpoint)或者通过自身服务的报告获得相关信息。现在的 

服务发现解决方案会持续从实例中收集健康信息,并且设置负载均衡的路由,让其只指向健康的实例组件。

自我修复

自我修复能帮助恢复应用。我们讨论下当应用遇到崩溃状态后,如何通过相关的步骤去自我修复。在大多数情况下,是通过外部系统监控实例的状态,当服务出现故障一段时间后则会重启服务。在大多数情况下,自我修复的功能是相当有用的,国外域名 免费域名,然而,在某些情况下由于不断地重启服务会带来相关的问题。例如当服务过载或者数据库连接超时,则会导致应用不能反馈正确的服务健康状态。


(责任编辑:梦飞科技)

分享按钮
相关文章