避免不完全的云原生（四）：技术和基础设施角度.docxVIP

避开不完全的云原生（四）：技术和基础设备角度 为了实现云原生，我们必需向部署组件的平台提很多要求。平台应当供应一种通用的机制，不管我们部署什么，它都能供应挂念，让我们不用考虑非功能性问题，同样，还应当“内置”平安性。因而，我们对平台的次要要求有： ·?弹性资源力量 ·?不行知部署和操作 ·?默认平安设置 假如开发人员要提高他们的生产力，就需要能够专注于编写制造业务价值的代码。这意味着平台应当处理负载平衡、高可用性、可伸缩性、弹性，甚至灾难恢复等问题。在部署时，我们应当能够指定高级的非功能性需求，而由平台完成剩下的工作。在这方面，我们将使用 Kubernetes 容器编排作为一个强大（实际上无处不在）的例子，但是云原生确定不限于 Kubernetes 平台。 Kubernetes 集群可依据所部署的组件的需求，供应 CPU、内存、存储、网络等资源的自动化、弹性配置。资源池可以分布在很多物理机上，也可以分布在很多独立地区的多个可用区域上。它担任找到你所需要的资源，并将组件部署到这些资源中。你只需要指定需求——需要什么资源，它们应当或不应当扩展，以及它们应当如何扩展和升级。对于基于虚拟机的平台，我们也可以这样说，但正如我们将要看到的，容器带来了更多的东西。 假设我们遵照了上一节的架构准绳，在容器中交付应用程序组件，让 Kubernetes 以标准化的方式执行部署和后续操作，而不考虑任何特定容器的内容。假如组件基本上是无形态的、可抛弃的、细粒度的、良好解耦的，那么平台就很简约以通用的方式部署、扩展、监控和升级它们，而不需要了解它们的内部结构。对于每一种软件，现在都有一种逐渐抛弃专有安装和拓扑配置的趋势，像 Kubernetes 这样的标准就是其中的一部分。现在，它们都以相同的方式工作，我们可以受益于操作的全都性、学习曲线的降低以及附加功能（如监视和功能管理）更广泛的适用性。 最终，我们期望平台内置了平安，这样，我们从第一天起就可以信任它是平安的应用程序运转环境。我们不应当每次设计一个新组件时都需要重新设计平安内核；相反，我们应当能够从平台承继一个模型。在抱负情况下，这应当包括身份管理、基于角色的访问管理、爱护外部访问和内部通信。我们留意到，在这个例子中，Kubernetes 本身只是部分处理方案；对于一个完整的平安处理方案，还需要添加一些元素，比如用于内部通信的服务网格，以及用于入站流量的入站把握器。 轻量级运转时 要想实现操作灵敏性，就要保证组件尽可能简约和轻量级。这可以归结为三个次要特性。 ·?快速启动/关闭 ·?基于文件系统的安装和配置 ·?基于文件系统的代码部署 为了实现可用性和可伸缩性，组件必需能够快速创建和销毁。也就是说，容器内的运转时必需可以优雅地启动和关闭。它们还必需能够处理不优雅地关闭。这意味着有很多优化可能可以做：从删除依靠项，削减初始化过程中的内存占用，到在镜像构建中启用编译“左移”。至少，运转时应当能够在几秒内启动，这个期望值会不断降低（如Quarkus）。 假如接受持续集成，我们还期望构建尽可能简约、快速。大多数现代运转时已经不再需要单独安装软件，而只需将文件放到文件系统上。类似地，依据定义，不行变镜像不应当在运转时更改，它们通常从属性文件读取配置，而不是通过自定义运转时命令接收配置。 同样，实际的应用程序代码也可以放在文件系统中，而不是在运转时部署。这些特性组合在一起，使得构建能够通过简约的文件复制快速完成，格外适合容器镜像的分层文件系统。 操作自动化 假如我们能够作为发布的一部分，交付在运转时配置处理方案的整个举动方案（包括基础设备和拓扑结构的全部方面），会怎样样呢？假如我们可以将举动方案存储在代码存储库中，并可以像处理应用程序代码那样触发更新，情况会怎样？假如我们让操作人员这个角色聚焦于实现环境自治和自愈，会怎样？这些问题引出了一些关键的方法，我们应当以不同的方式处理基础设备： ·?基础设备即代码 ·?存储库触发的操作（GitOps） ·?站点牢靠性工程 正如前面所争辩的，基于镜像的部署已经使部署的全都性提高了很多。然而，这只交付了代码及其运转时。我们还需要考虑如何部署、扩展和维护处理方案。在抱负情况下，我们期望能够将全部这些都作为“代码”和组件的源代码一起供应，以确保在不同环境中构建时的全都性。 术语“基础设备即代码”最后关注的是编写底层基础设备（比如虚拟机、网络、存储等）的脚本。编写基础设备脚本并不是什么新颖事，但有越来越多的公用工具，如 Chef、Puppet、Ansible 和 Terraform，大大推动了这方面的进展。这些工具首先假定有可用的硬件，然后在硬件上预备并配置虚拟机。好玩的是，当我们迁移到容器平台时，这个过程会有什么变化。 在抱负情况下，我们的应用程序应当可以假设，已经有一个 Ku