英语原文共 36 页，剩余内容已隐藏，支付完成后下载完整资料

第5章

通过以下方式大规模部署微服务

Docker和Kubernetes

到目前为止，我们已经在更高层次上讨论了微服务，涵盖了组织敏捷性，具有依赖关系的思维进行设计，领域驱动的设计以及承诺理论。然后，我们通过三种流行的用于开发微服务的Java框架深入研究了杂草：Spring Boot，Dropwizard和WildFly一群。通过公开和使用REST端点，利用环境配置选项，打包为一体的可执行JAR文件以及公开指标，我们可以轻松利用强大的开箱即用功能。这些概念都围绕微服务的单个实例。但是，当您需要管理依赖关系，获得一致的启动或关闭，运行状况检查以及大规模地微服务负载平衡时，会发生什么？在本章中，我们将讨论那些高级概念，以更全面地了解大规模部署微服务的挑战，而不论其语言是什么。

当我们开始将应用程序和服务划分为微服务时，按照定义，我们将得到更多动人的部分：我们拥有更多的服务，更多的二进制文件，更多的配置，更多的交互点等。我们传统上通过构建Java来处理部署Java应用程序的工作。二进制工件（JAR，WAR和EAR），将它们分段放置在某个位置（共享磁盘，JIRA和工件存储库），打开票证，并希望运营团队以正确的权限和环境将它们按预期部署到应用程序服务器中变量和配置。我们还将应用程序服务器部署在具有冗余硬件，负载平衡器和共享磁盘的群集中，并尽力避免出现故障。我们可能已经围绕基础架构建立了一些自动化功能，并借助Chef或Ansible等出色的工具来支持此功能

使用此模型，我们可以做很多希望，在当前环境中这种方法往往会很快崩溃，没关系 大规模地。是否在Dev / QA / Prod中配置了应用程序服务器，就像在我们的计算机上一样？如果不是，我们是否已经完全掌握了需要进行的更改并表达给业务人员？我们的任何更改是否还会影响在同一应用程序服务器中运行的其他应用程序？运行时组件（如操作系统，JVM和相关的依赖项）是否与我们的开发机器上的组件完全相同？就我们如何配置，调整和运行而言，用于运行应用程序的JVM在很大程度上是我们应用程序的高度耦合的实现细节，因此跨环境的这些变化可能会造成严重破坏。当您开始提供微服务时，您是否在传统服务器上的单独进程中运行它们？进程隔离是否足够？如果一个JVM发疯并占用了100％以上的CPU，会发生什么情况？还是网络IO？还是共享磁盘？如果在该主机上运行的所有服务都崩溃了怎么办？您的应用程序是否旨在适应这种情况？当我们将应用程序拆分成较小的部分时，这些问题变得更加严重。

一成不变的交付

不变的交付概念有助于我们对这些问题进行推理。对于不可变的交付，作为构建过程的一部分，我们尝试减少移动到预烘焙图像中的片段的数量。例如，假设您在构建过程中可以输出操作系统，JVM的预期版本，任何附带工具应用程序以及所有配置的完全烘焙的映像？然后，您可以将其部署在一个环境中，进行测试，然后沿着交付管道将其迁移到生产环境，而不必担心“环境或应用程序是否配置一致”。如果您需要对应用程序进行更改，则可以重新运行该管道，这将生成应用程序的新的不变映像，然后进行滚动升级以交付它。如果不起作用，则可以通过部署上一个映像进行回滚。

听起来不错，但是我们该怎么做呢？可执行JAR是让我们参与其中的一个方面，但仍然不足。JVM是我们微服务的实现细节，那么我们如何捆绑JVM？JVM用本机代码编写，并且具有本机OS级别的依赖关系，我们也需要打包这些依赖关系。我们还将需要配置，环境变量，权限，文件目录以及其他必须打包的内容。所有这些详细信息无法在单个可执行JAR中捕获。其他二进制格式（如虚拟机（VM）映像）可以正确封装这些详细信息。但是，对于每个可能具有不同打包要求的微服务（JVM，NodeJS，Golang，属性文件或私钥），我们很容易看到VM映像和语言运行时组合的爆炸式增长。如果您使用基础结构作为代码来自动执行此操作，并且可以使用适当公开的API来访问基础结构即服务，那么您当然可以完成此操作。实际上，将虚拟机作为自动交付管道的一部分进行构建，正是Netflix为实现这一水平的不变交付所做的工作。但是虚拟机变得难以管理，修补和更改。每个VM使用所需的设备驱动程序，操作系统和管理工具虚拟化整个计算机。

我们还可以探索其他哪些轻型包装和图像格式？

几年前，Docker诞生了一种针对不可变交付的优雅解决方案。Docker允许我们以轻量级，分层的图像格式将应用程序打包成所需的所有依赖项（OS，JVM，其他应用程序依赖项等）。此外，Docker使用这些映像来运行实例，这些实例在Linux容器内运行我们的应用程序，并且具有独立的CPU，内存，网络和磁盘使用率。从某种意义上说，这些容器是应用程序虚拟化或流程虚拟化的一种形式。它们允许进程执行以为这是唯一正在运行的进程（例如，使用ps列出进程）并且您只能在其中看到应用程序的进程），并且它具有对CPU，内存，磁盘，网络和其他资源的完全访问权限，而实际上却没有。它只能使用分配的资源。例如，我可以使用切片启动Docker容器

CPU数量，一部分内存以及可以使用多少网络IO的限制。从Linux容器外部，在主机上，该应用程序看起来就像另一个进程。没有对设备驱动程序，操作系统或网络堆栈以及特殊虚拟机管理程序进行虚拟化。这只是一个过程。这一事实还意味着，我们可以在同一套硬件上运行更多的应用程序，以实现更高的密度，而无需额外的操作系统和VM的其他部分来实现类似的隔离质量。

幕后发生的事情也不是革命性的。功能-名为cgroup中，命名空间和chroot环境，并已内置到Linux内核（并有一段时间了），被用来创建此应用程序的虚拟化的外观。Linux容器已经存在了10多年了，而Solaris和FreeBSD之前就存在进程虚拟化。传统上，使用这些底层Linux原语甚至是更高层次的抽象（如lxc）充其量都是复杂的。Docker出现并简化了围绕Linux容器的API和用户体验。Docker带来了一个客户端CLI，可以轻松启动这些客户端CLI

基于Docker映像格式的Linux容器，现已在开放容器倡议（OCI）中向更大的社区开放。这种易用性和图像格式正在改变我们打包和交付软件的方式。

一旦有了映像，将其中的许多Linux容器分解就变得微不足道了。这些层被构建为基本映像（例如RHEL，Debian或某些其他Linux操作系统）与应用程序文件之间的增量。分发新应用程序只是将新层分发到现有基础层之上。这使得分发映像比在cloud肿的云机映像周围穿梭容易得多。另外，如果存在漏洞（例如，外壳震动，流血等）在基础映像中找到，则可以重建基础映像，而不必尝试修补每个VM。这使在任何地方运行容器变得容易：然后可以通过便携式方式将它们从开发人员的桌面移至开发人员，质量保证或生产中，而无需手动希望所有正确的依赖项都位于正确的位置（此应用程序可以吗？使用JVM 1.6、1.7、1.8？）。如果我们需要通过更改（新应用）进行重新部署或修复基本图像，则只需更改图像中需要更改的图层即可。当我们拥有标准的API和开放格式时，我们可以构建不需要知道或关心容器中正在运行什么的工具。我们如何启动一个应用程序？我们如何停止？我们如何进行健康检查？我们如何汇总日志，指标，和洞察力？我们可以构建或利用以与技术无关的方式执行这些操作的工具。诸如服务发现，负载平衡，容错和配置之类的强大集群机制也可以推到应用程序堆栈的较低层，因此应用程序开发人员不必费力将它们拼凑在一起并使他们的应用程序代码复杂化。

Kubernetes

Google以大规模运行Linux容器而闻名。实际上，在Google上运行的“一切”都在Linux容器中运行，并由其Borg集群管理平台进行管理。谷歌前工程师乔·贝达（Joe Beda）说，该公司每周启动超过20亿个容器。Google甚至帮助创建了使容器成为可能的底层Linux技术。2006年，他们开始从事“过程容器”的工作，最终成为cgroups并被合并到Linux内核代码库中，并于2008年发布。凭借其可操作容器的广度和背景，Google对围绕容器构建的平台产生如此大的影响也就不足为奇了。例如，在Kubernetes之前的一些流行的容器管理项目受到Google的影响：

• 最初的Cloud Foundry创造者（Derek Collison和Vadim Spivak）在Google工作，并花费了数年时间使用Google的Borg集群管理解决方案。
• Apache Mesos是为博士学位论文而创建的，其创建者（Ben Hindman）在Google实习，并与Google工程师就容器群集，调度和管理进行了多次对话。
• Kubernetes是一个开源容器集群管理平台和社区，最初是由在Google上建立Borg的同一位工程师创建的。

早在2013年Docker撼动技术行业时，谷歌就决定将他们的下一代继任者开源到Borg，他们将其命名为Kubernetes。今天，Kubernetes是一个大的，开放的，快速成长的社区与谷歌，红帽，CoreOS，和许多其他人（包括很多的贡献不知疲倦-

Kubernetes

下垂的人！）。Kubernetes带来了许多功能，可以在Linux容器中大规模运行微服务集群。Google在Kubernetes中积累了十多年的经验，因此能够将这种知识和功能用于我们自己的微服务部署正在改变游戏规则。网络规模的公司已经这样做了很多年，其中许多公司（Netflix，Amazon等）不得不手工构建Kubernetes现在已经引入的许多原语。Kubernetes有一些简单的原语，您可以在深入研究示例之前，应该先了解一下。在本章中，我们将向您介绍这些概念。在下一章中，我们将利用它们来管理微服务集群。

豆荚

吊舱是一个或多个Docker容器的分组（例如一堆鲸鱼？）。但是，与Docker容器通常通常是一对一的Pod部署。如果您必须始终将Sidecar，Ambassador或Adaptor部署与应用程序置于同一位置，则可以使用pod对其进行分组。这种抽象也是保证容器亲和力的一种方式（即，Docker容器A将始终与Docker容器B一起部署在同一主机上）。

Kubernetes协调，计划和管理Pod。当我们指的是在Kubernetes内部运行的应用程序时，它在pod内的Docker容器内运行。为Pod分配了自己的IP地址，该Pod中的所有容器都共享该IP（这与普通Docker不同，在后者中，每个容器都获得一个IP地址）。将卷安装到Pod时，它们还会在Pod中运行的各个Docker容器之间共享。

关于豆荚，要了解的最后一件事：它们是可替代的。这意味着它们可以随时消失（因为服务崩溃或集群杀死了它）。它们不像您所关心和培养的VM。荚可以在任何时候被摧毁。在微服务世界中，这符合我们的预期，即事情将会（并且确实）会失败，因此强烈建议我们牢记这一前提编写微服务。当我们在以下各节中讨论其他一些概念时，这是一个重要的区别。

标签

标签是简单的键/值对，我们可以将它们分配给pod，例如release = stable 或tier = backend 。Pod（以及其他资源，但我们将重点放在Pod上）可以具有多个标签，这些标签以松散耦合的方式进行分组和分类，随着您使用Kubernetes的增多，这一点变得显而易见。Google识别出如此简单的结构就可以大规模构建强大的集群，这不足为奇。在标记了Pod之后，我们可以使用标签选择器来查找哪些Pod属于哪个组。例如，如果我们有一些标记为 tier = backend的容器，而另一些标记为tier = fron tend的容器，则使用tier！= frontend的标记选择器表达式。我们可以选择所有未标记为“前端”的窗格。标签选择器用于下面的两个概念：复制控制器和服务。

复制控制器

当谈论大规模运行微服务时，我们可能会谈论任何给定微服务的多个实例。Kubernetes有一个称为ReplicationController的概念，它管理给定微服务集的副本数。例如，假设我们要管理标记为tier = backend和release = stable的pod的数量。我们可以创建一个有适当的标签选择一个复制器，然后能够控制与价值集群中的豆荚数量副本我们ReplicationController。如果我们设置副本count等于10，那么Kubernetes将协调其当前状态以反映给定ReplicationController运行的10个Pod 。如果目前只有5个运行，Kubernetes将再增加5个。如果有20个正在运行，Kubernetes将杀死10个（就您的应用而言，它杀死的10个是不确定的）。Kubernetes会尽一切努力使所需的10个副本状态收敛。您可以想象使用ReplicationController非常容易地控制集群的大小。在下一章中，我们将看到运行Rep licationController的示例。

服务

我们应该了解的最后一个Kubernetes概念是Kubernetes服务。ReplicationControllers 可以控制我们拥有的服务的副本数量。我们还看到豆荚可以被杀死（或者

Kubernetes

自身崩溃或被杀死，可能是作为ReplicationControlle

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[604831]，资料为PDF文档或Word文档，PDF文档可免费转换为Word