Update cloud-native-philosophy.md

参照原文更新文档层次

cloud-native/cloud-native-philosophy.md

@@ -153,7 +153,7 @@
 
 设计具有弹性的应用程序可能是整本书本身。我们将在云原生应用程序中考虑弹性的两个主要方面：为失败设计和优雅降级。
 
-### 为失败设计
+#### 为失败设计
 
 唯一永远不会失败的系统是那些让你活着的系统（例如心脏植入物和刹车系统）。如果您的服务永远不会停止运行，您需要花费太多时间设计它们来抵制故障，并且没有足够的时间增加业务价值。您的SLO确定服务需要多长时间。您花费在工程设计上超出SLO的正常运行时间的任何资源都将被浪费掉。
 
@@ -171,7 +171,7 @@
 
 有些故障不能也不应该被设计到应用程序中（例如，网络分区和可用区故障）。该平台应自主处理未集成到应用程序中的故障域。
 
-### 优雅降级
+#### 优雅降级
 
 云原生应用程序需要有一种方法来处理过载，无论它是应用程序还是负载下的相关服务。处理负载的一种方式是优雅降级。 “站点可靠性工程”一书中描述了应用程序的优雅降级，因为它提供的响应在负载过重的情况下“不如正常响应准确或含有较少数据的响应，但计算更容易”。
 
@@ -181,21 +181,21 @@
 
 尽管优雅的降级和失败处理都应该在应用程序中实现，但平台的多个层面应该提供帮助。如果采用微服务，则网络基础设施成为需要在提供应用弹性方面发挥积极作用的关键组件。有关构建弹性网络层的更多信息，请参阅附录A.
 
-### 可用性数学
+> **可用性数学**
-
+>
-云原生应用程序需要在基础设施之上建立一个平台，以使基础设施更具弹性。如果您希望将现有应用程序“提升并转移”到云中，则应检查云提供商的服务级别协议（SLA），并考虑在使用多个服务时会发生什么情况。
+> 云原生应用程序需要在基础设施之上建立一个平台，以使基础设施更具弹性。如果您希望将现有应用程序“提升并转移”到云中，则应检查云提供商的服务级别协议（SLA），并考虑在使用多个服务时会发生什么情况。
-
+>
-让我们拿运行我们的应用程序的云来进行假设。
+> 让我们拿运行我们的应用程序的云来进行假设。
-
+> 
-计算基础设施的典型可用性是每月99.95％的正常运行时间。这意味着您的实例每天可能会缩短到43.2秒，并且仍在您的云服务提供商的SLA中。
+> 计算基础设施的典型可用性是每月99.95％的正常运行时间。这意味着您的实例每天可能会缩短到43.2秒，并且仍在您的云服务提供商的SLA中。
-
+>
-另外，实例的本地存储（例如EBS卷）也具有99.95％的可用性正常运行时间。如果幸运的话，他们都会同时出现故障，但最糟糕的情况是他们可能会在不同的时间停机，让您的实例只有99.9％的可用性。
+> 另外，实例的本地存储（例如EBS卷）也具有99.95％的可用性正常运行时间。如果幸运的话，他们都会同时出现故障，但最糟糕的情况是他们可能会在不同的时间停机，让您的实例只有99.9％的可用性。
-
+>
-您的应用程序可能还需要一个数据库，而不是自己安装一个计算可能的停机时间为1分26秒（99.9％可用性）的情况下，选择可靠性为99.95％的更可靠的托管数据库。这使您的应用程序的可靠性达到99.85％，或者每天可能发生2分钟和9秒的宕机时间。
+> 您的应用程序可能还需要一个数据库，而不是自己安装一个计算可能的停机时间为1分26秒（99.9％可用性）的情况下，选择可靠性为99.95％的更可靠的托管数据库。这使您的应用程序的可靠性达到99.85％，或者每天可能发生2分钟和9秒的宕机时间。
-
+>
-将可用性乘到一起可以快速了解为什么应以不同方式处理云。真正不好的部分是，如果云提供商不符合其SLA，它将退还其账单中一定比例的退款。
+> 将可用性乘到一起可以快速了解为什么应以不同方式处理云。真正不好的部分是，如果云提供商不符合其SLA，它将退还其账单中一定比例的退款。
-
+>
-虽然您不必为停机支付费用，但我们并不知道世界上存在云计算信用的单一业务。如果您的应用程序的可用性不足以超过您收到的信用额度，那么您应该真正考虑是否应该运行这个应用程序。
+> 虽然您不必为停机支付费用，但我们并不知道世界上存在云计算信用的单一业务。如果您的应用程序的可用性不足以超过您收到的信用额度，那么您应该真正考虑是否应该运行这个应用程序。
 
 ### 声明式，非反应式