微软中国MSDN 点击上方 蓝字关注我们
面对复杂多变的业务和运维环境 ， 很多人绞尽脑汁想要维持业务的持续运转 。
然而很多时候 ， 无论删库跑路导致企业丢失所有关键业务数据 ， 或外部施工出错挖断光缆电线 ， 甚至某些内部或外部基础服务上一个小小的错误配置导致半个地球范围内的服务中断……所有这些或大或小的问题 ， 总会让很多人手忙脚乱处理半天 ， 还会让业务甚至企业声誉遭受不小的影响 。
虽然那句话说得好：破坏稳态的难度越大 ， 我们对系统行为的信心就越强；并且只要能发现某个弱点 ， 我们就有了一个改进目标 。
然而以往在本地部署和运行关键应用时 ， 包括基础架构、底层硬件在内的很多因素可由企业自行掌控 ， 因此发现并解决弱点还是好处理的（也许需要投入大量资金和人力） 。 但当企业开始上云 ， 通过云平台运行这些关键应用时 ， 底层基础架构的管理和维护是由云平台承担的 ， 这时又该如何解决弱点 ， 打造更稳定、更有韧性的运维环境和应用程序？
本文将从设计思路角度出发 ， 告诉你如何提高云原生应用的韧性 ， 确保在遇到事件后业务依然能够稳妥运行 。
与远程服务和资源通信的所有应用程序必须对临时性故障敏感 。 对于云中运行的应用程序尤其如此 ， 因为其环境的性质与通过互联网建立连接的特点 ， 意味着更容易遇到此类问题 。 临时性故障包括客户端和服务瞬间断开网络连接、后台服务暂时不可用 ， 或者并发过大出现的超时等 。 这些错误通常是可以自我修复的 ， 如果能把故障影响控制在一定范围内 ， 则可将对最终用户的影响降至最低 。
为什么云中会出现临时性故障？
任何环境、任何平台或操作系统以及任何类型的应用程序都会发生临时性故障 。 在本地基础架构上运行的解决方案中 ， 应用程序及其组件的性能和可用性通常由昂贵且利用率不足的冗余硬件来保证 。 虽然此方法使故障的可能性降低 ， 但仍可能导致临时性故障 ， 甚至因外部电源/网络问题或其他灾难情况等不可预测的事件而中断 。
托管型云服务（PaaS）可以跨多个计算节点使用共享资源、冗余、自动故障转移和动态资源分配 ， 实现更高的整体可用性 。 但是这些环境的性质意味着更可能发生临时性故障 ， 原因包括：

• 云环境中的许多资源是共享的 ， 为了有效管理这些资源 ， 云通常会严格管控对这些资源的访问 。 例如 ， 某些服务在负载上升到特定级别 ， 或到达吞吐量比率上限时 ， 会拒绝额外连接以便处理现有请求 ， 并为所有现存用户维持服务性能 。 限制有助于为共享资源的邻居与其他租户维持服务质量 。
• 云环境是使用大量商用硬件单元构建而成的 。 云环境将负载动态分散到多个计算单元和基础架构组件上以获得更多性能 ， 并通过自动回收或更换故障单元来提供可靠性 。 这种动态性意味着可能偶尔会发生临时性故障或暂时性连接失败 。
• 在应用程序与资源及其使用的服务之间通常有多个硬件组件 ， 包括网络基础架构 ， 例如路由器和负载均衡器 。 这些附加的组件偶尔会导致额外的连接延迟或临时性连接故障 。
• 客户端与服务器之间的网络状况会不时改变 ， 尤其是通过互联网通信时 。 即使在本地位置 ， 高流量负载也可能减慢通信速度 ， 并造成间歇性的连接故障 。

面临的挑战
临时性故障可能会对用户感知的可用性产生巨大影响 ， 即使应用程序已在所有可预见的情况下进行了全面测试 。 若要确保云托管的应用程序可靠运行 ， 应用程序必须能够应对以下挑战：