避免不完全的云原生（一）：云原生到底意味着什么？.docxVIP

避开不完全的云原生（一）：云原生到底意味着什么？ 2021-01-11 很多时候，围绕云原生的争辩会直接进入技术选择，如容器化和微服务。毫无疑问，这些都是云原生项目的潜在组成部分，但确定不是全部。在本系列文章中，我们将从几个不同的角度探究云原生，包括技术和基础设备，还包括架构、设计，以及可能最简约被忽视的人员和流程。用最简约的术语来说，云原生不只是说要迁移到云，而是要充分利用云基础设备和服务的独特性来快速交付业务价值。 云原生的概念在这个术语投入使用之前就已经存在了。从某种意义上说，云原生是从公有云供应商开头供应简约廉价的弹性计算力量实例开头的。接下来的问题就变成了，你该如何编写应用程序来利用这种新的基础设备的机警性，以及你可以因而获得什么业务收益？ 在过去的十年中，云原生方法和技术已经发生了很大的变化，并且仍在不断进展，但是云原生应用程序所要实现的核心的技术和业务目标仍旧没有变，这包括： 灵敏性和生产力：支持业务目标指点下的快速创新。降低维护风险并保持环境的持续更新。 弹性和可伸缩性：以自修复和无停机时间的持续可用性为目标。供应弹性缩放和容量无限的感觉。 优化和效率：优化基础设备和人力资源成本。可以在不同位置和供应商之间自在迁移。 在后续的文章中，当我们回顾云原生的“为什么”时，我们将对这些目标进行更细的分解，但即便从这个简约的定义来看，我们也应当清楚，云原生并不只仅是指简约地迁移到一种新类型的基础设备，其含义要更广泛。然而，虽然这些目标很正确，但我们很难看到它们被应用于具体的云原生环境。我们需要做更多的工作来明确云原生到底是什么意思。 一些与云原生相关的流行的参照标准，比如微服务，以及更早的宣言，比如12要素应用，可能会让你得出这样的结论：云原生是一种架构风格的描述，其他选择都是服从这一架构。这当然有肯定的道理，云原生架构的确存在。然而，为了在云原生应用上取得成功，企业必需有一个更全面的视角。除了架构和基础设备决策，还有组织和过程决策。这让我们生疏到一个关键问题： 技术本身并不能获得业务成果。 下图显示了这些决策之间的相互作用。 技术本身并不能获得业务成果。 在文章“避开不完全的云原生”中，我们举了一个很好的例子，描述了这些方面相互之间是如何链接在一起的，并特地指出了这些链接断开时会发生什么。在本系列文章中，我们将探讨云原生的成功与以下三个关键领域的协同变革的关系：架构与设计、技术与基础设备、人员与流程。下面我们将逐项进行争辩。 技术与基础设备：“云原生”语境下的“云”是什么？ 十多年前，“云”这个词很大程度上指的是位置。通常，它指的是可以通过互联网访问的位于他人数据中心里的基础设备。然而，如今的“云”更多的是指如何与那个基础设备交互。现实上，位置元素已经基本消逝了，由于现在常见的是，一个类似云的设备运转在本人的数据中心里——“私有云”，以及混合处理方案（可能会包含跨云的服务和工作负载）。 所以，如今的云计算更多的是关于你如何与基础设备交互，它至少要供应以下内容： 自助配置：可以即时申请新的虚拟资源（服务器、存储、网络）。 弹性：依据需求自动调整资源（及相关成本）。 自动恢复：资源可按设计在没有人为干涉的情况下从毛病中恢复，将对服务可用性的影响降至最低。 然而，随着云平台及概念的成熟，云原生中的云实际上还意味着对底层基础设备的进一步笼统。 不行变部署——例如，基于容器镜像的部署。 声明式配置——“基础设备即代码”供应将来形态。 运转时无关——平台将组件（例如容器）视为黑盒，不需要理解它们的内容。 组件编排——通过通用的声明式策略和配置赋能管理（监控、伸缩、可用性、路由等）。 在云原生的晚期，这些功能通常是高度专有的，但现在，容器以及容器编排功能（如 Kubernetes）好像已无处不在。像上面这样的列表是针对容器的，还有其他值得留意的选项，如无服务器/函数即服务(function As a service)，它们被进一步从基础设备中笼统出来，而且将来可能会变得愈加突出。 我们可能会涉及更多，如构建自动化、服务网格、日志、跟踪、分析、软件定义网络和存储等等。因而，届时我们将进入云平台上目前看来更专有的方面。期望随着时间的推移，这些方面也会变得愈加标准化。因而，在这里，“云”实际上是指具有上述特性的基础设备和技术。 架构与设计：“云原生”里的“原生”是什么意思？ 我们所说的“原生（native）”是指我们将构建的处理方案不只仅是“运转在云上”，而是特地利用了云平台的独特性。应用程序不会魔法般地承继底层云基础设备的优点，我们必需教会它们方法。 我们在言语上要特殊当心。当我们使用“原生”来指“云平台的独特性”时，我们并不是指特定云供应商的特定方面。那将是“云供应商原生”，实际上，这将完全背离可移植性和使用开放标准的目