本文首先介绍微服务架构存在的风险，然后针对如何避免微服务架构的故障，提出了多种有效的微服务架构中的方法和技术，其中例如服务降级、变更管理、健康检查和修复、断路器、限流器等。
微服务架构通过定义明确的服务边界，能有效地隔离故障。 和其他分布式系统一样，微服务在网络、硬件和应用层上都会存在更多的问题。由于服务之间是互相依赖，因此任何组件都可能出错导致用户不能访问。为尽可能减少部分中断带来的影响，我们需要构建容错能力强的服务，以从容应对发生的某些中断。
本文在RisingStack’s Node.js Consulting & Development experience一文基础上，介绍了构建和运维高可用的微服务架构系统中最常用的技术和架构模式。
如果读者不熟悉上文中的模式，那并没什么大碍。构建可靠的系统不是一踞而就的。
微服务架构的风险
微服务架构将应用逻辑拆分成服务，服务之间通过网络交互。由于是通过网络调用，而不是在进程中调用，因此这给需要在多个物理和逻辑组件间进行协作的系统带来了潜在的问题和复杂性。分布式系统变得越来越复杂，也导致网络特定故障发生的可能性增大。
相比传统应用庞大的结构，微服务架构最大的一个优点是团队能独立地设计、开发和部署各自的服务。团队能掌控各自服务的整个生命周期。这也意味者团队无法控制服务的依赖关系，因为这些依赖的服务可能是由其他团队管理。在微服务架构体系下，我们要牢记提供的服务由于是其他人控制，因此可能会由于发布、配置、和其他变更等原因，从而导致服务暂时不可用，而且组件之间互相独立。
优雅的服务降级
微服务架构最大的优点之一就是当组件出现故障时，能隔离这些故障并且能做到优雅地服务降级。比如，在图片分享应用中，当出现故障时，用户可能无法上传图片，但他们依然能浏览、编辑和分享已上传的图片。
微服务故障独立（理论上）
在大多数情况下，是很难实现上图这种优雅地服务降级的，因为在分布式环境下，应用都是互相依赖的，开发者需要实现若干错误处理的逻辑（该部分在本文稍后部分讨论）去应对短暂的故障和中断。
服务互相依赖，如果无故障转移的逻辑，则会同时失效
变更管理
Google的网站可靠性团队发现大概70%的故障都是由于变更而引起的。当对服务进行修改时—例如发布代码的新版本或者改变一些配置，则总会有可能引起故障或者引入新的错误。
在微服务架构中，服务是互相依赖的。这就是为什么你需要减少故障并且尽可能降低它们的负面影响。为了应对变更带来的问题，你可以实施变更策略管理并且实现其自动回滚。
比如，当部署新的代码或者修改配置时，应该分步将这些变更部署到服务实例群中的部分实例中，并且进行监控，如果发现关键指标出现问题则能自动进行回滚。
变更管理－回滚部署
另一个解决方案是运行两套生产环境。部署的时候只部署变更的应用到其中一套环境中，并且在验证了新发布的版本符合预期后，才将负责均衡的流量指向新的应用，这种方法称为“蓝-绿发布”或者“红-黑发布”。
回退代码并不是坏事情。你不应该在生产环境中部署有问题的代码，并且应该琢磨哪里出错了。当必要时候应该果断回退代码，这越早越好。