欧洲大带宽服务器,seo关键词首页排名,福州婚庆网站建设哪家好,wordpress企业免费主题作者#xff1a;Pter Mrton 译者#xff1a;Jackyrong 本文首先介绍微服务架构存在的风险#xff0c;然后针对如何避免微服务架构的故障#xff0c;提出了多种有效的微服务架构中的方法和技术#xff0c;其中例如服务降级、变更管理、健康检查和修复、断路器、限流器等。… 作者Péter Márton 译者Jackyrong 本文首先介绍微服务架构存在的风险然后针对如何避免微服务架构的故障提出了多种有效的微服务架构中的方法和技术其中例如服务降级、变更管理、健康检查和修复、断路器、限流器等。 微服务架构通过定义明确的服务边界能有效地隔离故障。 和其他分布式系统一样微服务在网络、硬件和应用层上都会存在更多的问题。由于服务之间是互相依赖因此任何组件都可能出错导致用户不能访问。为尽可能减少部分中断带来的影响我们需要构建容错能力强的服务以从容应对发生的某些中断。 本文在RisingStack’s Node.js Consulting Development experience一文基础上介绍了构建和运维高可用的微服务架构系统中最常用的技术和架构模式。 如果读者不熟悉上文中的模式那并没什么大碍。构建可靠的系统不是一踞而就的。 微服务架构的风险 微服务架构将应用逻辑拆分成服务服务之间通过网络交互。由于是通过网络调用而不是在进程中调用因此这给需要在多个物理和逻辑组件间进行协作的系统带来了潜在的问题和复杂性。分布式系统变得越来越复杂也导致网络特定故障发生的可能性增大。 相比传统应用庞大的结构微服务架构最大的一个优点是团队能独立地设计、开发和部署各自的服务。团队能掌控各自服务的整个生命周期。这也意味者团队无法控制服务的依赖关系因为这些依赖的服务可能是由其他团队管理。在微服务架构体系下我们要牢记提供的服务由于是其他人控制因此可能会由于发布、配置、和其他变更等原因从而导致服务暂时不可用而且组件之间互相独立。 优雅的服务降级 微服务架构最大的优点之一就是当组件出现故障时能隔离这些故障并且能做到优雅地服务降级。比如在图片分享应用中当出现故障时用户可能无法上传图片但他们依然能浏览、编辑和分享已上传的图片。 微服务故障独立理论上 在大多数情况下是很难实现上图这种优雅地服务降级的因为在分布式环境下应用都是互相依赖的开发者需要实现若干错误处理的逻辑该部分在本文稍后部分讨论去应对短暂的故障和中断。 服务互相依赖如果无故障转移的逻辑则会同时失效 变更管理 Google的网站可靠性团队发现大概70%的故障都是由于变更而引起的。当对服务进行修改时—例如发布代码的新版本或者改变一些配置则总会有可能引起故障或者引入新的错误。 在微服务架构中服务是互相依赖的。这就是为什么你需要减少故障并且尽可能降低它们的负面影响。为了应对变更带来的问题你可以实施变更策略管理并且实现其自动回滚。 比如当部署新的代码或者修改配置时应该分步将这些变更部署到服务实例群中的部分实例中并且进行监控如果发现关键指标出现问题则能自动进行回滚。 变更管理回滚部署 另一个解决方案是运行两套生产环境。部署的时候只部署变更的应用到其中一套环境中并且在验证了新发布的版本符合预期后才将负责均衡的流量指向新的应用这种方法称为“蓝-绿发布”或者“红-黑发布”。 回退代码并不是坏事情。你不应该在生产环境中部署有问题的代码并且应该琢磨哪里出错了。当必要时候应该果断回退代码这越早越好。 健康检查和负载均衡 因为故障或部署、自动扩展等原因服务实例会不停启动重新启动及停止。这使得服务暂时或一直停用。为了避免发生这些问题在负载均衡中应该在路由中设置忽略这些实例因为它们无法为子系统或用户提供服务。 我们可以通过外部观察去判断应用实例是否健康。你可以多次调用 Get /health的端点endpoint或者通过自身服务的报告获得相关信息。现在的 服务发现解决方案会持续从实例中收集健康信息并且设置负载均衡的路由让其只指向健康的实例组件。 自我修复 自我修复能帮助恢复应用。我们讨论下当应用遇到崩溃状态后如何通过相关的步骤去自我修复。在大多数情况下是通过外部系统监控实例的状态当服务出现故障一段时间后则会重启服务。在大多数情况下自我修复的功能是相当有用的然而在某些情况下由于不断地重启服务会带来相关的问题。例如当服务过载或者数据库连接超时则会导致应用不能反馈正确的服务健康状态。 对于一些场景-比如数据库链接丢失这个时候实现高级的自我修复功能是颇为棘手的。在这种情况下需要为应用添加额外的逻辑去处理这些特例并且让外部系统知道服务的实例不需要立即重新启动。 故障转移缓存Failover Caching 因为网络问题和系统中的变更服务通常会出现故障。然而这些故障中断大多是暂时的这要归功于自我修复和高级负载平衡的功能我们应该找到一个解决方案能使服务即使在出现故障的时候也能工作。这就是故障转移缓存Failover Caching它能帮助为我们的应用提供必需的数据。 失效转移缓存通常使用两个不同的过期日期其中更短的日期指示在正常情况下能使用缓存的时间而更长的一个日期则指示在故障失效的时候能使用缓存中的数据时长。 故障转移缓存 特别需要提醒的是只有当提供过时的数据比没有数据更好的情况下才能使用故障转移缓存。 要设置缓存和故障转移缓存可以在HTTP中使用标准响应头。 例如使用max-age头可以指定某个资源为新资源的最大时间译者注意即设定max-age后浏览器不再发送请求到服务器。可以使用stale-if-error 头去确定在出现故障的情况下从缓存获取资源的时间长短。 现在的CDN和负载均衡器提供了各种缓存和故障转移的解决方案但是你也可以在你的公司中建立一个共享库其中包括这些标准的可靠性解决方案。 重试逻辑Retry Logic 在某些情况下我们可能无法缓存数据或者想对数据进行变更但是操作最终失败了。在这种情况下我们就可以选择重试操作因为我们可以预期资源将在一段时间后恢复或者负载均衡会将请求发送到健康的实例上。 你应该小心地为应用程序和客户端添加重试逻辑因为更大量的重试操作可能会使事情变得更糟甚至阻止应用程序恢复。 在分布式系统中微服务系统重试可能会触发多个其他请求或重试操作并导致级联效应。为减少重试带来的影响你应该减少重试的数量并使用指数退避算法exponential backoff algorithm来持续增加重试之间的延迟时间直到达到最大限制。 由于重试是由客户端浏览器其他微服务等发起的并且客户端在处理请求前后是不知道草走失败的你应该为你的应用程序提供幂等处理能力。例如当你重试购买操作时不应该向客户收两次钱。给每个事务使用唯一的幂等键idempotency-key是解决重试问题的方法。 限流器和负载开关Rate Limiters and Load Shedders 限流是指在一段时间内定义某个客户或应用可以接收或处理多少个请求的技术。例如通过限流你可以过滤掉产生流量峰值的客户和微服务或者可以确保你的应用程序在自动扩展Auto Scaling失效前都不会出现过载的情况。 你还可以阻止较低优先级的流量以便为关键事务提供足够的资源。 限流器可以阻止流量峰值 另外有一种限流器称为 “并发请求限流器concurrent request limiter”。当你有一些比较昂贵和重要的端点(endpoint)希望它不应该被调用超过指定的次数但仍然想要提供流量服务时这个限流器就十分有用了。 使用负载开关可以确保对于关键的事务总能提供足够的资源保障。它为高优先级的请求保留一些资源并且不允许低优先级的事务去占用这些资源。负载开关会根据系统的整体状态做出决定而不是基于单个用户的请求桶request bucket大小。负载设备有助于你的系统恢复因为它们在持续发生故障事件时依然能保持核心功能正常工作。 关于更多限流器和负载开关的知识建议读者参考Stripe的相关文章。 快速且单独失效Fail Fast and Independently 在微服务体系架构中我们希望服务可以快速、单独地失效。为了在服务层面隔离故障我们可以使用隔板模式bulkhead pattern。可以在本文稍后看到相关介绍。 我们也希望我们的组件能够快速失效fail fast因为我们不希望等到断开的实例直到超时。没有什么比挂起的请求和无响应的界面更令人失望。这不仅浪费资源而且还会让用户体验变得更差。我们的服务是互相调用的所以在这些延迟叠加前应该特别注意防止那些超时的操作。 你想到的第一个办法可能是对每个服务的调用都定义超时的级别。这种做法的问题是你不能真正知道到底什么是恰当的超时值因为当网络故障和其他问题发生时某些情况下只会影响一两次操作。在这种情况下如果只有其中一些发生超时你可能不想拒绝所有这些请求。 我们可以说通过使用超时timeout来实现微服务中的快速失败是一种反模式这是应该避免的。可以使用基于操作的成功/失败统计次数的熔断模式而不是使用超时。 舱壁模式Bulkheads 在工业领域中常使用舱壁将划分为几个部分以便在有某部分船体发生破裂时其他部分依然能密封安然无恙。 舱壁的概念也可以在软件开发中用于隔离资源。 通过使用舱壁模式我们可以保护有限的资源不被用尽。例如如果我们有两种类型的操作的话它们都是和同一个数据库实例进行通信并且数据据库限制连接数这时我们可以使用两个连接池而不是使用一个共享的连接池。由于这种客户端和资源分离超时或过度使用池的操作不会令所有其他操作失效。 泰坦尼克号沉没的主要原因之一是其舱壁设计失败水可以通过上面的甲板倒在舱壁的顶部最后整个船淹没。 泰坦尼克号故障的舱壁 断路器Circuit Breakers 为了限制操作的持续时间我们可以使用超时。超时可以防止挂起操作并保证系统可以响应。然而在微服务架构通信中使用静态、微调的超时是一种反模式因为我们处于高度动态的环境中几乎不可能确定在每种情况下都能正常工作的准确的时间限制。 我们可以使用断路器来处理错误而不是使用小型和特定基于事务的静态超时机制。断路器以现实世界的电子元件命名因为它们的行为是都是相同的。你可以保护资源并通过使用断路器协助它们进行恢。断路器在分布式系统中非常有用因为重复的故障可能会导致雪球效应并使整个系统崩溃。 当在短时间内多次发生指定类型的错误断路器会开启。开启的断路器可以拒绝接下来更多的请求 – 就像防止真实的电子流动一样。断路器通常在一定时间后关闭以便为底层服务提供足够的空间来恢复。 请记住并不是所有的错误都应该触发断路器。例如你可能希望忽略客户端问题比如4xx响应代码的请求但要包括5xx服务器端故障。一些断路器还可以有半开关状态。在这种状态下服务发送第一个请求以检查系统的可用性同时让其他请求失败。如果这个第一个请求成功则将断路器恢复到关闭状态并继续接受流量。否则保持打开状态。 断路器 故障测试Testing for Failures 你应该持续地测试系统的常见问题以确保你的服务可各类故障环境下运行。你应经常测试故障以让你的团队对可能发生的事故有所准备。 关于测试你可以使用外部服务来识别服务实例组并随机终止运行组中的一个实例。通过使用这个方法可以针对单个实例故障进行测试你甚至可以关闭整个服务组来模拟云提供商层面的故障中断。 最流行的测试解决方案之一是Netflix的ChaosMonkey工具。 总结 实施和运维可靠的服务并不容易。这需要你付出很多努力还要花费公司更多的成本。 可靠性有很多层次和方面因此针对你的团队找出合适的解决方案是相当重要的。你应该将可靠性成为业务决策流程中的一个因素并为此分配足够的预算和时间。 要点 动态环境和分布式系统-如微服务将导致更高的故障机会。 服务应单独失效实现优雅的服务降级以提升用户体验。 70的问题是由变更引起的恢复可用代码并不总是坏事。 快速单独地失败。团队无法控制其服务依赖关系。 架构模式和技术如缓存、隔离技术、断路器和限流器有助于构建可靠的微服务。 读者可以通过阅读我们免费的电子书Node.js Monitoring, Alerting Reliability 101 e-book以学习可靠的微服务。 作者简介 Péter Márton是RisingStack的CTO , 擅长使用nodejs来构建微服务。他的twitter帐号为 https://twitter.com/slashdotpeter。
