本文
本文主体内容为AWS的灾难恢复白皮书：Disaster Recovery of Workloads on AWS: Recovery in the Cloud
当今时代，越来越多的企业和组织将他们的业务和数据迁移到云上。在云计算的世界里，灾难恢复变得更加关键，因为许多组织依赖于云上的服务和数据中心。但是，与传统 IT 环境不同，云环境具有更大的复杂性和动态性，这使得灾难恢复变得更加困难和重要。
在这个快速发展的云计算行业中，掌握云上的灾难恢复架构已经成为一个必备的技能。无论你是一名云架构师、系统管理员、运维工程师，或者是一名云平台的用户，都需要了解和掌握云上的灾难恢复框架。只有这样，我们才能更好地保护我们的业务并确保它们始终可用。
因此，本文旨在向读者介绍AWS云计算下的灾难恢复架构的诸多相关知识点，希望读者可以通过本文了解到云上的灾难恢复计划的基本原理、最佳实践和工具，并掌握如何设计和实施云上的可靠灾难恢复计划。当然各大云厂商的服务个人使用下来，感觉基本思想都是互通的，所以这里面灾难恢复架构是不限定具体云的设计的。
大家英文水平OK的话，也推荐再阅读一遍原文。 以下内容依据个人侧重有删减，同时加上了个人的一些理解笔记（笔记部分都有明显标记），好了下面让我们一起阅读。
摘要
灾难恢复（Disaster recovery ）是为灾难恢复做准备以及如何从灾难中恢复的过程。
当一个事件发生在主要部署区域上，导致工作负载或系统无法实现其业务目标，被视为灾难。
本文概述了部署到 AWS 上的任何工作负载规划和测试灾难恢复的最佳实践，并提供不同的方法来降低风险并满足该工作负载的恢复时间目标 (RTO) 和恢复点目标 (RPO)。
个人笔记： 灾难恢复 经常会用DR 这个缩写标识， RTO，RPO是DR中两个关键指标，后面会详细介绍含义
介绍
你的工作负载必须正确且一致地执行其预期功能。为了实现这一目标，你必须构建弹性架构。弹性是工作负载从基础设施、服务或应用程序中断中恢复、动态获取计算资源以满足需求以及减轻中断（例如配置错误或暂时性网络问题）的能力。
个人笔记：云计算中 推荐架构在设计过程中将资源标定为动态伸缩，任何资源都可能发生异常或者遭受资源瓶颈限制
灾难恢复 (DR) 是弹性策略的重要组成部分，当灾难发生时考虑工作负载如何做出响应处理（灾难是对业务造成严重负面影响的事件）。此响应必须基于你组织的业务目标，该目标指定工作负载的策略，以避免数据丢失（称为恢复点目标 (RPO)），并减少工作负载无法使用时的停机时间（称为恢复时间目标） RTO）。因此，必须在云中对你的工作负载实现弹性伸缩设计，以满足给定一次性灾难事件的恢复目标（RPO 和 RTO）。作为业务连续性计划 (BCP) 的一部分，此方法可帮助你的组织保持业务连续性。
个人笔记：这里又引入了一个名词 BCP Business Continuity Planning 业务连续性计划， 当你正在做一个大型的工程项目的时候，一定会有一份详细的BCP文档，来应对诸多可能发生的情况。
灾难恢复和可用性
灾难恢复与可用性进行比较，可用性是弹性策略的另一个重要组成部分。灾难恢复衡量的目标是一次事件，而可用性目标衡量的是一段时间内的平均值。
可用性是使用平均故障间隔时间 (MTBF) 和平均恢复时间 (MTTR) 计算的：
这种方法通常被称为多个九，其中 99.9% 的可用性目标被称为“三个九”。
对于你的工作负载，计算成功和失败的请求可能比使用基于时间的方法更容易。在这种情况下，可以使用以下计算：
灾难恢复侧重于灾难事件，而可用性侧重于更常见的小规模中断，例如组件故障、网络问题、软件错误和负载峰值。灾难恢复的目标是业务连续性，而可用性则涉及最大限度地延长工作负载执行其预期业务功能的时间。两者都应该成为你的弹性策略的一部分。
个人笔记： 还记得开始灾难恢复的定义了吗？ 发生在主要部署区域 如果一个区域发生机房级别问题（比如 机房故障）就比较考验我们的架构能力，是否可以具备从其他可用区恢复的能力。
可用性 更多侧重局部问题，配置错误，突发流量高峰，个别实例宕机 等
可用性的衡量指标，大家做服务设计的时候一定会用到的。
什么是灾难
在规划灾难恢复时，请评估针对以下三个主要灾难类别的计划：
- 自然灾害，例如地震或洪水
- 技术故障，例如电源故障或网络连接故障
- 人为行为，例如无意的错误配置或未经授权/外部方访问或修改
这些潜在灾害中的每一个都会产生地理影响，可能是地方性的、区域性的、全国性的、大陆性的或全球性的。在考虑灾难恢复策略时，灾难的性质和地理影响都很重要。例如，你可以通过采用多可用区策略来缓解导致数据中心中断的本地洪水问题，因为它不会影响多个可用区。但是，对生产数据的攻击将要求你调用灾难恢复策略，以故障转移到另一个 AWS 区域中的备份数据。
高可用性不是灾难恢复
可用性和灾难恢复都依赖于一些相同的最佳实践，例如监视故障、部署到多个位置以及自动故障转移。但是，可用性侧重于工作负载的组成部分，而灾难恢复则侧重于整个工作负载的离散副本。灾难恢复与可用性的目标不同，可用性是衡量发生灾难的大规模事件后的恢复时间。你应该首先确保你的工作负载满足你的可用性目标，因为高度可用的架构将使你能够在发生影响可用性的事件时满足客户的需求。你的灾难恢复策略需要与可用性不同的方法，重点是将离散系统部署到多个位置，以便你可以在必要时对整个工作负载进行故障转移。
你必须在灾难恢复规划中考虑工作负载的可用性，因为它将影响你采取的方法。在一个可用区中的单个 Amazon EC2 实例上运行的工作负载不具有高可用性。如果本地洪泛问题影响该可用区，则这种情况需要故障转移到另一个可用区才能满足灾难恢复目标。将此场景与部署的多站点主动/主动的高可用工作负载进行比较，其中工作负载跨多个活动区域部署，并且所有区域都为生产流量提供服务。在这种情况下，即使在不太可能发生的大规模灾难导致某个区域无法使用的情况下，灾难恢复策略也是通过将所有流量路由到其余区域来完成的。
可用性和灾难恢复之间处理数据的方式也有所不同。考虑一种连续复制到另一个站点以实现高可用性的存储解决方案（例如多站点、主动/主动工作负载）。如果主存储设备上的一个或多个文件被删除或损坏，这些破坏性更改可以复制到辅助存储设备。在这种情况下，尽管可用性很高，但在数据删除或损坏时进行故障转移的能力将会受到影响。相反，作为灾难恢复策略的一部分，还需要时间点备份。
业务连续性计划 (BCP)
你的灾难恢复计划应该是组织业务连续性计划 (BCP) 的子集，而不应该是一个独立的文档。如果由于灾难对工作负载以外的业务元素的影响而无法实现工作负载的业务目标，那么维持积极的灾难恢复目标来恢复工作负载是没有意义的。例如，地震可能会阻止你运输在电子商务应用程序中购买的产品 - 即使有效的灾难恢复使你的工作负载保持正常运行，你的 BCP 也需要满足运输需求。你的灾难恢复策略应基于业务需求、优先级和上下文。
业务影响分析和风险评估
业务影响分析应量化工作负载中断对业务的影响。它应该确定无法使用你的工作负载对内部和外部客户的影响以及对你的业务的影响。分析应有助于确定需要以多快的速度提供工作负载以及可以容忍多少数据丢失。然而，值得注意的是，复苏目标不应孤立制定；中断的可能性和恢复成本是有助于了解为工作负载提供灾难恢复的业务价值的关键因素。
恢复目标（RTO 和 RPO）
在创建灾难恢复 (DR) 策略时，组织最常规划恢复时间目标 (RTO) 和恢复点目标 (RPO)。
个人笔记： 通过这张图片可以清晰的理解 RPO 和RTO的区别， RPO是指数据恢复的时间跨度，应该是灾难发生之前的某个时间点（对数据敏感性的要求，金融级别数据基本上不容丢失，业务数据一般可以接受丢失一定跨度时间范围）， RTO则是服务恢复时间跨度，是指服务中断和服务恢复之间的时间差。 最理想的情况当然是RPO和RTO都尽可能的小，但是实际场景下，要根据业务级别，资源投入，以及监管要求等多方面因素来考量，进行架构设计，并不是一味要求更低的RTO和RPO。
恢复时间目标（RTO）是服务中断和服务恢复之间可接受的最大延迟。该目标确定了服务不可用时可接受的时间窗口，并由组织定义。
本文大致讨论了四种灾难恢复策略：备份和恢复、指示灯、热备用和多站点主动/主动。在下图中，企业已经确定了允许的最大 RTO 以及他们可以在服务恢复策略上花费的限制。考虑到业务目标，DR 策略 Pilot Light 或 Warm Standby 将满足 RTO 和成本标准。
恢复点目标 (RPO) 是自上一个数据恢复点以来可接受的最大时间量。该目标确定了上一个恢复点和服务中断之间可接受的数据丢失程度，并由组织定义。
在下图中，企业确定了最大允许的 RPO 以及可用于数据恢复策略的资金限制。在四种 DR 策略中，Pilot Light 或 Warm Standby DR 策略同时满足 RPO 和成本标准。
如果恢复策略的成本高于故障或损失的成本，则不应实施恢复选项，除非存在监管要求等次要驱动因素。进行此评估时，请考虑不同成本的恢复策略。
云中的灾难恢复有所不同
灾难恢复策略随着技术创新而发展。本地灾难恢复计划可能涉及物理运输磁带或将数据复制到另一个站点。你的组织需要重新评估其先前灾难恢复策略的业务影响、风险和成本，以实现其在 AWS 上的灾难恢复目标。与传统环境相比，AWS 云中的灾难恢复具有以下优势：
- 以降低的复杂性从灾难中快速恢复
- 简单且可重复的测试使你可以更轻松、更频繁地进行测试
- 较低的管理开销减少了运营负担
- 自动化的机会减少了出错的机会并缩短了恢复时间
Single AWS Region 单一 AWS 区域
对于因一个物理数据中心中断或丢失而发生的灾难事件，在单个 AWS 区域内的多个可用区中实施高度可用的工作负载有助于缓解自然和技术灾难。在此单一区域内持续备份数据可以降低人为威胁的风险，例如可能导致数据丢失的错误或未经授权的活动。每个 AWS 区域由多个可用区组成，每个可用区都与其他可用区的故障隔离。每个可用区又由一个或多个离散的物理数据中心组成。为了更好地隔离有影响的问题并实现高可用性，你可以在同一区域的多个区域之间划分工作负载。可用区专为物理冗余而设计，并提供弹性，即使在断电、互联网停机、洪水和其他自然灾害的情况下也能实现不间断的性能。
通过在单个 AWS 区域中跨多个可用区进行部署，可以更好地保护你的工作负载免受单个（甚至多个）数据中心故障的影响。为了进一步保证单区域部署，你可以将数据和配置（包括基础设施定义）备份到另一个区域。此策略将灾难恢复计划的范围缩小到仅包括数据备份和恢复。相对于下一节中描述的其他多区域选项，通过备份到另一个 AWS 区域来利用多区域弹性既简单又便宜。例如，通过备份到 Amazon Simple Storage Service (Amazon S3)，你可以立即检索数据。但是，如果你对部分数据的 DR 策略对检索时间有更宽松的要求（从几分钟到几小时），那么使用 Amazon S3 Glacier 或 Amazon S3 Glacier Deep Archive 将显着降低你的备份和恢复策略的成本。
Multiple AWS Regions 多个 AWS 区域
对于包含失去多个相距较远的数据中心的风险的灾难事件，你应该考虑灾难恢复选项，以减轻影响 AWS 内整个区域的自然和技术灾难。以下各节中描述的所有选项都可以实现为多区域架构，以防止此类灾难。
个人笔记：架构设计也是要要有取舍， 对于服务的DR策略，多可用区或者多区域都是需要整体考量，同时对服务来说 多活，热备，冷备 实现的难度以及资源的投入都是需要做好评估和验证。
云中的灾难恢复选项
AWS 中可供你使用的灾难恢复策略大致可分为四种方法，从低成本、低复杂性的备份到使用多个活动区域的更复杂的策略。主动/被动策略使用主动站点（例如 AWS 区域）来托管工作负载并提供流量。被动站点（例如不同的 AWS 区域）用于恢复。在触发故障转移事件之前，被动站点不会主动提供流量。
定期评估和测试你的灾难恢复策略至关重要，这样你才能在必要时有信心调用它。
个人笔记：这张图里生动的列举了四种灾难恢复策略，难易程度，恢复时间，资源成本，这些因素都是大家进行灾难恢复策略选择时需要衡量的。
对于基于架构良好、高度可用的工作负载的一个物理数据中心中断或丢失的灾难事件，你可能只需要一种备份和恢复方法来进行灾难恢复。如果你对灾难的定义超出了物理数据中心对某个区域的破坏或丢失的范围，或者如果你需要满足监管要求，那么你应该考虑指示灯、热备用或多站点主动/积极的。
在选择策略以及实施该策略的 AWS 资源时，请记住，在 AWS 中，我们通常将服务分为数据平面和控制平面。数据平面负责提供实时服务，而控制平面用于配置环境。为了获得最大的弹性，你应该仅使用数据平面操作作为故障转移操作的一部分。这是因为数据平面通常比控制平面具有更高的可用性设计目标。
这里 AWS 服务有类，数据平面，控制平面。
控制平面提供用于创建、读取/描述、更新、删除和列出 (CRUDL) 资源的管理 API。例如，以下都是控制层面的操作：启动EC2实例，创建S3存储，当你启动 EC2 实例时，控制平面必须执行多项任务，例如查找具有容量的物理主机、分配网络接口、生成 IAM 证书、添加安全组规则等。控制平面往往是复杂的协调和聚合系统。
数据平面是提供服务的主要功能。例如，以下是所涉及的每项服务的数据平面的所有部分：正在运行的 EC2 实例本身、读取和写入 EBS 卷、在 S3 存储桶中获取和放置对象，以及回答 DNS 查询和执行运行状况检查的 Route 53。
Backup and restore 备份还原
备份和恢复是减少数据丢失或损坏的合适方法。此方法还可用于通过将数据复制到其他 AWS 区域来缓解区域灾难，或者缓解部署到单个可用区的工作负载缺乏冗余的情况。除了数据之外，你还必须在恢复区域中重新部署基础设施、配置和应用程序代码。为了能够快速重新部署基础设施而不会出现错误，你应始终使用 AWS CloudFormation 或 AWS 云开发工具包 (AWS CDK) 等服务使用基础设施即代码 (IaC) 进行部署。如果没有 IaC，在恢复区域恢复工作负载可能会很复杂，这将导致恢复时间增加，并可能超过你的 RTO。除了用户数据之外，还请务必备份代码和配置，包括用于创建 Amazon EC2 实例的 Amazon 系统映像 (AMI)。你可以使用 AWS CodePipeline 自动重新部署应用程序代码和配置。
个人笔记： 这里原文列出AWS 的多种服务 灾难恢复的的具体解决方案，鉴于篇幅，我没有列出来，感兴趣的可以阅读原文了解。以下几种恢复选项中具体服务 我同样进行了省略。
可以看到这个选项就是冷备，将底层数据周期性备份到其他区域，这里有很多可选方式，s3 CRR， aws backup 图例中是通过sns+lambda 触发定期备份
Pilot light 指示灯
通过试点方法，你可以将数据从一个区域复制到另一个区域，并配置核心工作负载基础设施的副本。支持数据复制和备份所需的资源（例如数据库和对象存储）始终处于开启状态。其他元素（例如应用程序服务器）加载了应用程序代码和配置，但被“关闭”，并且仅在测试期间或调用灾难恢复故障转移时使用。在云中，你可以灵活地在不需要时取消配置资源，并在需要时配置它们。 “关闭”的最佳实践是不部署资源，然后在需要时创建配置和功能来部署它（“打开”）。与备份和恢复方法不同，你的核心基础设施始终可用，并且你始终可以选择通过打开和扩展应用程序服务器来快速配置全面的生产环境。
试点方法通过最大限度地减少活动资源来最大限度地减少灾难恢复的持续成本，并简化灾难发生时的恢复，因为核心基础设施要求已全部到位。此恢复选项要求你更改部署方法。你需要对每个区域进行核心基础设施更改，并将工作负载（配置、代码）更改同时部署到每个区域。可以通过自动化部署并使用基础设施即代码 (IaC) 跨多个账户和区域部署基础设施（将完整基础设施部署到主要区域，并缩小/关闭基础设施部署到灾难恢复区域）来简化此步骤。建议你在每个区域使用不同的帐户，以提供最高级别的资源和安全隔离（如果凭据泄露也是灾难恢复计划的一部分）。
通过这种方法，你还必须减轻数据灾难的影响。连续数据复制可以保护你免受某些类型的灾难的影响，但它可能无法保护你免受数据损坏或破坏，除非你的策略还包括存储数据的版本控制或时间点恢复选项。你可以备份灾难区域中的复制数据，以在同一区域中创建时间点备份。
个人笔记： 这种方式个人认为很考验团队的能力，指示灯选项，相当于备份了底层数据以及整个环境配置，但是整体服务是不激活状态，当发生灾难时，进行启动。 减少了活动资源成本的同时简化了恢复的操作步骤的长度，以及保证核心基础设施的稳定。 但是实际生产中，这种恢复选项是很考验团队的部署配置，以及日常灾难演练，不然无法确保当真正灾难发生时，可以顺利进行切换，激活服务。
Warm standby 热备
热备用方法涉及确保在另一个区域中存在生产环境的缩小但功能齐全的副本。此方法扩展了指示灯概念并缩短了恢复时间，因为你的工作负载在另一个区域始终处于开启状态。此方法还允许你更轻松地执行测试或实施连续测试，以增强你从灾难中恢复的能力的信心。
注意：指示灯和热待机之间的区别有时很难理解。两者都包括你的 DR 区域中的一个环境，其中包含你的主要区域资产的副本。区别在于，如果不先采取额外的操作，指示灯就无法处理请求，而热待机可以立即处理流量（以降低的容量水平）。指示灯方法要求你“打开”服务器，可能部署额外的（非核心）基础设施并进行扩展，而热备用只需要你进行扩展（一切都已部署并运行）。使用你的 RTO 和 RPO 需求来帮助你在这些方法之间进行选择。
备份和恢复以及 Pilot Light 涵盖的所有 AWS 服务还用于热备份，用于数据备份、数据复制、主动/被动流量路由以及包括 EC2 实例在内的基础设施部署。
由于 Auto Scaling 是一种控制平面活动，因此依赖它会降低整体恢复策略的弹性。这是一种权衡。你可以选择预配足够的容量，以便恢复区域可以处理部署时的全部生产负载。这种静态稳定的配置称为热备用（请参阅下一节）。或者，你可以选择配置更少的资源，从而降低成本，但依赖于 Auto Scaling。一些灾难恢复实施将部署足够的资源来处理初始流量，确保较低的 RTO，然后依靠 Auto Scaling 来增加后续流量。
个人笔记： 热备相当于在不同区域拷贝了一份当前整体架构服务，底层数据进行同步，但是备份的服务整体是开启的，但是流量不进入，当需要切换时，底层存储 主从变更，资源扩展，流量切换。
使用过程中，要考虑切换过程中，短时间流量高峰，整体服务尽量要依据可伸缩性进行设计，同时底层数据存储的一致性，也是很考验架构设计团队。
Multi-site active/active 多活
作为多站点主动/主动或热备用主动/被动策略的一部分，你可以在多个区域同时运行工作负载。多站点主/主服务来自其部署到的所有区域的流量，而热备仅服务来自单个区域的流量，其他区域仅用于灾难恢复。通过多站点主动/主动方法，用户可以在部署工作负载的任何区域访问你的工作负载。这种方法是最复杂、成本最高的灾难恢复方法，但通过正确的技术选择和实施，它可以将大多数灾难的恢复时间减少到接近于零（但是数据损坏可能需要依赖备份，这通常会导致非- 零恢复点）。热备采用主动/被动配置，其中用户仅被定向到单个区域，并且 DR 区域不占用流量。大多数客户发现，如果他们要在第二个区域中建立完整的环境，那么主动/主动使用它是有意义的。或者，如果你不想使用两个区域来处理用户流量，那么热待机提供了一种更经济且操作复杂度更低的方法。
对于多站点主动/主动，由于工作负载在多个区域中运行，因此在此场景中不存在故障转移之类的情况。在这种情况下，灾难恢复测试将重点关注工作负载对区域丢失的反应：流量是否从发生故障的区域路由出去？其他区域可以处理所有流量吗？还需要对数据灾难进行测试。备份和恢复仍然是必需的，并且应该定期测试。还应该注意的是，涉及数据损坏、删除或混淆的数据灾难的恢复时间将始终大于零，并且恢复点将始终在发现灾难之前的某个时间点。如果需要多站点主动/主动（或热备用）方法的额外复杂性和成本来保持接近零的恢复时间，那么应该付出额外的努力来维护安全性并防止人为错误，以减轻人为灾难。
个人笔记：多活，也就是多区域同时运行，这个整体架构设计中难度最大，如何保证数据全局一致，如何保证服务请求链路的时延要求，日常维护成本 方方面面 ，个人认为还是要基于业务述求，是否值的投入等比资源来实现多活架构。
个人笔记：总结： 恢复选项这里是内容最繁杂的，原文中会扩展了众多AWS服务以及相应恢复选项下如何进行最佳实践。个人只是保留了主体内容以及一些样例架构图片，如果感兴趣的朋友推荐阅读原文，如果你正在使用AWS服务进行架构设计，十分推荐你花时间好好了解下原文内容，也欢迎留言讨论或者加我个人微信沟通，互相学习。
检测
尽快了解你的工作负载没有提供应有的业务成果非常重要。通过这种方式，你可以快速宣布发生灾难并从事件中恢复。对于积极的恢复目标，响应时间与适当的信息相结合对于实现恢复目标至关重要。如果你的恢复点目标是一小时，那么你需要检测事件、通知相应人员、参与升级流程、评估预期恢复时间的信息（如果有）（不执行灾难恢复计划）、宣布灾难并在一小时内恢复。
测试灾难恢复
测试灾难恢复实施以验证实施并定期测试到工作负载的灾难恢复区域的故障转移，以确保满足 RTO 和 RPO。
要避免的一种模式是开发很少执行的恢复路径。例如，你可能有一个用于只读查询的辅助数据存储。当你写入数据存储并且主数据存储出现故障时，你可能希望故障转移到辅助数据存储。如果你不经常测试此故障转移，你可能会发现你对辅助数据存储功能的假设是不正确的。上次测试时辅助区域的容量可能足够，但在这种情况下可能无法再承受负载，或者辅助区域中的服务配额可能不足。
我们的经验表明，唯一有效的错误恢复是你经常测试的路径。这就是为什么最好使用少量恢复路径的原因。
个人笔记： 也就是我们要周期性进行灾难演练，通过日常的演练发现总结问题，去验证我们的灾难恢复计划是否行之有效。
总结
我们一起学习了AWS关于灾难恢复的相关架构知识，个人还是建议大家，无论你是一名云架构师，还是运维工程师或者是使用云服务的开发人员，都需要比较深刻的了解和掌握云上的灾难恢复框架。只有这样，我们才能更好地保护我们的业务并确保它们始终可用。
延伸阅读
以下是各大云厂商的灾难恢复文档，大家意犹未尽的可以延伸阅读下，每家厂商都会有一些自己的心得经验，值得学习。
- AWS 灾难恢复白皮书 这篇白皮书提供了 AWS 灾难恢复服务的详细信息，包括备份和恢复、故障转移和高可用性、容错和可恢复性。
- 谷歌云灾难恢复指南该指南提供了 Google Cloud 上实现灾难恢复的最佳实践，包括备份和恢复、故障转移和高可用性、容错和可恢复性、网络和数据管理等方面的内容。
- 微软 Azure 灾难恢复指南 此文档概述了 Azure Site Recovery 服务及其功能。其中包括如何使用 Azure Site Recovery 配置和管理基于虚拟机的灾难恢复、Azure VMware 解决方案、物理服务器复制等。
- 阿里云灾备解决方案 阿里云关于通用的灾备解决方案，同城，异地，数据库，双活等。
> 云计算已经是当下技术人员的必学的一门课程，如果有时间也鼓励大家可以多了解学习，提升自己的专业能力，阿里云也有相关认证ACP和ACE，感兴趣的朋友也可以了解一下。如果有任何问题，需要沟通交流也可以添加我的个人微信 **coder_wukong**，备注：云计算，或者关注我的公众号 **WuKongCoder** 日常也会不定期写一些文章和思考。
> 如果觉得文章不错，欢迎大家点赞，留言，转发，收藏 谢谢大家，我们下篇文章再会~~~
