读书笔记《building-microservices-with-spring》使用Mesos和Marathon扩展Dockerated微服务
为了充分利用类云环境的全部功能，dockerized 微服务实例还应该能够根据流量模式自动扩展和收缩。但是，这可能会导致另一个问题。一旦有许多微服务，手动管理数千个 dockerized 微服务并不容易。拥有基础架构抽象层和强大的容器编排平台对于成功管理互联网规模的 dockerized 微服务部署至关重要。
本章将解释基本的扩展方法以及 Mesos 和 Marathon 作为基础架构编排层的需求和使用，以在大规模部署微服务时在类似云的环境中实现优化的资源使用。本章还将提供在云环境中设置 Mesos 和 Marathon 的分步方法。最后，本章将演示如何将 dockerized 微服务管理到 Mesos 和 Marathon 环境中。
在本章结束时，我们将了解以下内容：
- Options to scale containerized Spring Boot microservices
- The need to have an abstraction layer and a container orchestration software
- An understanding Mesos and Marathon from the context of microservices
- How to manage dockerized BrownField Airline's PSS microservices with Mesos and Marathon
在 第 12 章 的末尾，使用 Spring Cloud 组件扩展微服务 ，我们讨论了使用 Spring Cloud 组件或使用 Mesos 和 Marathon 的 dockerized 微服务进行扩展的两种选择。在 第 12 章中，使用 Spring Cloud 组件扩展微服务，您学习了如何使用 Spring Cloud 组件扩展 Spring Boot 微服务。
我们实现的 Spring Cloud 的两个关键概念是自注册和自发现。这两个功能支持自动化微服务部署。通过自注册，一旦实例准备好接受流量，微服务就可以通过将服务元数据注册到中央服务注册表来自动宣传服务可用性。一旦注册了微服务，消费者就可以通过使用注册服务发现服务实例，从下一刻开始使用新注册的服务。在此模型中，注册表是此自动化的核心。
下图展示了 Spring Cloud 扩展微服务的方法：
在本章中，我们将重点介绍第二种方法，即使用 Mesos 和 Marathon 扩展 dockerized microserices。它还为我们提供了一项您在 第 12 章, < em>使用 Spring Cloud 组件扩展微服务。当需要额外的微服务实例时，需要手动任务来启动新实例。同样，当没有足够的流量时，应该有一个选项来关闭未使用的实例。在理想的场景下，微服务实例的启动和停止也需要自动化。当服务在按使用付费的云环境中运行时，这一点尤其重要。
自动缩放是一种根据资源使用情况自动缩放 实例，通过复制要缩放的服务来满足商定的 SLA。
系统会自动检测流量的增加，启动额外的实例，并使它们可用于流量处理。同样，当流量下降时，系统会自动检测并通过从服务中取回活动实例来减少实例数量。还需要确保有一定数量的实例始终启动并运行。除此之外，物理机或虚拟机还需要一种自动配置机器的机制。后一部分使用不同云提供商提供的 API 更容易处理。
可以通过考虑不同的参数和阈值来完成自动缩放。其中一些很容易处理，而其中一些处理起来很复杂。以下是总结一些常用方法的要点：
- Scale with resource constraints: This approach is based on real-time service metrics collected through monitoring mechanisms. Generally, the resource scaling approach makes decisions based on the CPU, memory, or the disk of machines. It can also be done by looking at the statistics collected on the service instances itself, such as heap memory usage.
- Scale during specific time periods: Time-based scaling is an approach to scale services based on certain periods of the day, month, or year to handle seasonal or business peaks. For example, some services may experience higher number of transactions during office hours, and considerably less number of transactions outside office hours. In this case, during the day time, services autoscale to meet the demand and automatically downsizes during the off office hours.
- Scale based on message queue length: This is particularly useful when the microservices are based on asynchronous messaging. In this approach, new consumers will be automatically added when the messages in the queue goes beyond certain limits.
- Scale based on business parameters: In this case, adding instances will be based on certain business parameters. For example, spinning up a new instance just before handling sales, closing transactions. As soon as the monitoring service receives a preconfigured business event, such as sales closing minus 1 hour, a new instance will be brought up in anticipation of large volumes of transactions. This will provide fine grained controls on scaling based on business rules.
- Predictive autoscaling: This is a new paradigm of autoscaling, which is different from the traditional real-time metrics-based autoscaling. A prediction engine will take multiple inputs, such as historical information, current trends, and more, to predict possible traffic patterns. Autoscaling will be done based on these predictions. Predictive autoscaling helps in avoiding hardcoded rules and time windows. Instead, the system can automatically predict such time windows. In more sophisticated deployments, the predictive analysis may use cognitive computing mechanisms to predict autoscaling.
为了实现如前所述的autoscaling，它需要在操作系统级别编写大量脚本。 Docker 是实现这一目标的良好一步，因为它提供了一种处理容器的统一方式，而与微服务使用的技术无关。它还帮助我们隔离了微服务，以避免爱管闲事的邻居窃取资源。
但是，Docker 和脚本只能部分解决这些问题。在大规模 Docker 部署的背景下，需要回答的一些关键问题如下：
- How do we manage thousands of containers?
- How do we monitor them?
- How do we apply rules and constraints when deploying artifacts?
- How do we ensure that we utilize containers properly to gain resource efficiency?
- How do we ensure that at least a certain number of minimal instances are running at any point in time?
- How do we ensure that dependent services are up and running?
- How do we do rolling upgrades and graceful migrations?
- How do we rollback faulty deployments?
所有这些前面的问题都表明需要一个解决方案来解决以下两个关键功能：
- A container abstraction layer that provides a uniform abstraction over many physical or virtual machines
- A container orchestration and init system to manage deployments intelligently on top of the cluster abstraction
本章的其余部分将重点讨论这两点。
容器编排工具提供了一层抽象，供开发人员和基础架构团队处理大规模容器化部署。容器编排工具提供的功能因提供商而异。然而，共同点是供应、发现、资源管理、监控和部署。
由于微服务将应用程序分解为不同的 micro 应用程序，因此许多开发人员要求部署更多服务器节点。为了正确管理微服务，开发人员倾向于为每个 VM 部署一个微服务，这进一步降低了资源利用率。在许多情况下，这会导致 CPU 和内存的过度分配。
在许多部署中，微服务的高可用性要求迫使工程师添加越来越多的服务实例以实现冗余。实际上，尽管它提供了所需的高可用性，但这将导致服务器实例未充分利用。
一般来说，与单体应用程序部署相比，微服务部署需要更多的基础设施。由于基础设施成本的增加，许多组织看不到微服务的价值。
下图显示了每个微服务的专用 VM：
为了解决上图中所述的问题，我们需要一个能够执行以下操作的工具：
- Automating a number of activities such as allocation of containers to infrastructure efficiently, which are transparent to the developers and administrators
- Providing a layer of abstraction for the developers so that they can deploy their application against a data center without knowing which machine is to be used for hosting their applications
- Setting rules or constraints against deployment artifacts
- Offering higher levels of agility, with minimal management overheads for developers and administrators, perhaps with minimal human interactions
- Building, deploying, and managing applications cost effectively by driving maximum utilization of the available resources
容器解决了这方面的一个重要问题。我们选择的具有这些功能的任何工具都可以以统一的方式处理容器，而与不延迟的微服务技术无关。
典型的容器编排工具help 将一组机器虚拟化，并将它们作为单个集群进行管理。容器编排工具还有助于在对消费者透明的机器之间移动工作负载或容器。技术布道者和实践者使用不同的术语，例如容器编排、集群管理、数据中心虚拟化、容器调度器、容器生命周期管理、数据中心操作系统等。
其中许多工具目前支持基于 Docker 的容器以及非容器化二进制工件部署，例如独立的 Spring Boot 应用程序。这些容器编排工具的基本功能是从应用程序开发人员和管理员那里抽象出实际的服务器实例。
容器编排工具有助于基础设施的自助服务和供应，而不是要求基础设施团队使用预定义的规范分配所需的机器。在这种自动化容器编排方法中，机器不再预先配置和预分配给应用程序。一些容器编排工具还有助于跨许多异构机器甚至跨数据中心虚拟化数据中心，并创建一个弹性的类似私有云的基础设施。容器编排工具没有标准的参考模型。因此，供应商之间的功能会有所不同。
- Cluster management: This manages a cluster of VMs and physical machines as a single large machine. These machines could be heterogeneous in terms of resource capabilities, but, by and large, machines with Linux as the operating system. These virtual clusters can be formed on cloud, on premises, or a combination of both.
- Deployments: These handle automatic deployments of applications and containers with a large set of machines. It support multiple versions of the application containers, and also support rolling upgrades across a large number of cluster machines. These tools are also capable of handling a rollback of faulty promotes.
- Scalability: This handles automatic and manual scalability of application instances as and when required with optimized utilization as a primary goal.
- Health: This manages the health of the cluster, nodes, and applications. It removes faulty machines and application instances from the cluster.
- Infrastructure abstraction: This abstracts the developers from the actual machine where the applications are deployed. The developers need not worry about the machines, capacity, and so on. It is entirely the container orchestration software's decision to see how to schedule and run the applications. These tools also abstract the machine details, their capacity, utilization, and location from the developers. For application owners, these are equivalent to a single large machine with almost unlimited capacity.
- Resource optimizations: The inherent behavior of these tools is to allocate the container workloads across a set of available machines in an efficient way, thereby reducing the cost of ownership. Simple to extremely complicated algorithms can be used effectively to improve utilization.
- Resource allocations: These allocate servers based on resource availability and constraints set by the application developers. The resource allocation will be based on these constraints, affinity rules, port requirements, application dependencies, health, and so on.
- Service availability: This ensures that the services are up and running somewhere in the cluster. In case of a machine failure, container orchestration automatically handle failures by restarting those services on some other machine in the cluster.
- Agility: Agility tools are capable of quickly allocating workloads to available resources or move the workload across machines if there is change in resource requirements. Also, constraints can be set to realign resources based on business criticality, business priority, and more.
- Isolation: Some of these tools provide resource isolation out-of-the-box. Hence, even if the application is not containerized, resource isolation can be achieved.
各种算法用于资源分配，从简单算法到具有机器学习和人工智能的复杂算法。常用的算法有Random、装箱和< span class="strong">传播。针对应用程序设置的约束将根据资源可用性覆盖默认算法。
上图显示了这些算法如何用部署填充可用机器。在这种情况下，它是用两台机器演示的。
- Spread: This equally distributes the allocation of workloads across available machines., which is shown in diagram A.
- Bin packing: This tries to fill machine by machine and ensure the maximum utilization of machines. Bin packing is especially good when using cloud services in a pay as you use style. This is shown in diagram B.
- Random: This algorithm randomly chooses machines and deploys containers on randomly selected machines, which is shown in diagram C.
有可能使用机器学习和协同过滤等认知计算算法来提高效率。 oversubscriptions 等技术可以更好地利用 利用分配给高优先级任务的未充分利用的资源，包括为尽力而为的任务提供创收服务，例如分析、视频、图像处理等。
微服务的基础设施如果没有正确配置，很容易导致基础设施过大，并且本质上是更高的成本所有权。如前几节所述，具有容器编排工具的类云环境对于在处理大规模微服务时实现成本效益至关重要。
Spring Boot microservices turbo 由 Spring Cloud 项目负责，是利用容器编排工具的理想候选工作负载。由于基于 Spring Cloud 的微服务不感知位置，因此这些服务可以部署在集群中的任何位置。每当服务出现时，它会自动注册到服务注册表并公布其可用性。另一方面，消费者总是寻找注册表来发现可用的服务实例。通过这种方式，应用程序支持完整的流动结构，而无需预先假设部署拓扑。使用 Docker，我们能够抽象运行时，以便服务可以在任何基于 Linux 的环境中运行。
有许多 container 编排软件工具可用。在它们之间进行苹果对苹果的比较是不公平的。即使没有一对一的组件，它们之间的功能也有许多重叠的领域。在许多情况下，组织使用一种或多种这些工具的组合来满足他们的要求。
下图显示了容器编排工具在微服务上下文中的位置：
如上图所示，容器管理或编排工具采用容器形式的一组可部署工件（Services to Execute）和一个一组约束或规则作为部署描述符，然后找到用于部署的最佳计算基础架构，这些基础架构可用并分散在多台机器上。
在本节中，我们将探讨一些市场上流行的容器编排解决方案。
Docker Swarm是Docker的原生容器orchestration解决方案。 Swarm 提供与 Docker 的原生和更深入的集成，并公开与 Docker 的远程 API 兼容的 API。它在逻辑上对 Docker 主机池进行分组，并将它们作为大型单个 Docker 虚拟主机进行管理。而不是应用程序管理员和开发人员决定将容器部署到哪个主机，这个决策将委托给 Docker Swarm。它将根据 bin 打包和传播算法决定使用哪个主机。
由于 Docker Swarm 基于 Docker 的远程 API，与任何其他容器编排工具相比，现有 Docker 用户的学习曲线要少得多。然而，Docker Swarm 是市场上相对较新的产品，它只支持 Docker 容器。
Docker Swarm 使用 manager 和 nodes 的概念。管理器是 administrations 与 Docker containers 用于执行。节点是部署和运行 Docker 容器的地方。
Kubernetes (k8s) 来自谷歌的工程，是写的使用 Go 语言，并在 Google 进行大规模部署的实战测试。与 Swarm 类似，Kubernetes 帮助 跨节点集群管理容器化应用程序。它有助于自动化容器部署和调度以及容器的可扩展性。它支持许多有用的开箱即用功能，例如自动渐进式部署、版本化部署和容器因某种原因失败时的容器弹性。
Kubernetes 架构有 master、nodes 和 pods。主节点和节点一起称为 Kubernetes 集群。主节点负责跨多个节点分配和管理工作负载。节点不过是虚拟机或物理机器。节点被进一步细分为pod。一个 node 可以托管多个 Pod。一个或多个容器在一个 pod 内分组并执行。 Pod 还有助于管理和部署协同定位服务以提高效率。 Kubernetes 还支持标签作为键值对的概念来查询和查找容器。标签是用户定义的参数，用于标记执行常见类型工作负载的某些类型的节点，例如前端 Web 服务器。部署在集群上的服务将获得一个 IP/DNS 来访问该服务。
Kubernetes 对 Docker 提供了开箱即用的支持；但是，与 Docker Swarm 相比，Kubernetes 的学习曲线会更加复杂。 Red Hat 为 Kubernetes 提供商业支持，作为其 OpenShift 平台的一部分。
Mesos 是一个开源框架，最初由加州大学伯克利分校开发，并被 Twitter 大规模使用。 Twitter 主要使用 Mesos 来管理大型 Hadoop 生态系统。
Mesos 与以前的 解决方案略有不同。它更像是一个依赖其他框架来管理工作负载执行的资源管理器。它位于操作系统和应用程序之间，提供机器的逻辑集群。
Mesos 是一个分布式系统内核，它在逻辑上将多台计算机分组并虚拟化为一台大型机器。它能够将大量异构资源分组到一个统一的资源集群中，在该集群上可以部署应用程序。由于这些原因，Mesos 也被称为在数据中心构建私有云的工具。
Mesos 有 master 和 slave 节点的概念。与早期的解决方案类似，主节点负责管理集群，而从节点运行工作负载。它在内部使用 ZooKeeper 进行集群协调和存储。它还支持框架的概念。这些框架负责调度 和运行非容器化应用程序和容器。 马拉松、Chronos和Aurora 是用于调度和执行应用程序的流行 框架。 Netflix 的 Fenzo 是另一个开源 Mesos 框架。有趣的是，Kubernetes 也可以用作 Mesos 框架。
Marathon 支持 Docker a> 容器，以及非容器化的应用程序。 Spring Boot 可以直接在 Marathon 中配置。 Marathon 提供了许多开箱即用的功能，例如支持应用程序依赖项、用于扩展和升级服务的应用程序分组、健康和不健康实例的启动和关闭、滚动提升、回滚失败提升等等。
作为其 DCOS 平台的一部分，Mesosphere 为 Mesos 和 Marathon 提供商业支持。
Nomad 来自 HashiCorp，另一个容器 span> 编排软件。 Nomad 是一个容器编排系统，它抽象了底层机器details 及其位置。与之前探索的其他解决方案相比，它具有更简单的架构。它也很轻。与其他容器编排解决方案类似，它将负责资源分配和应用程序的执行。 Nomad 还接受特定于用户的约束并基于此分配资源。
Nomad 拥有管理所有作业的服务器的概念。一台服务器将充当领导者，其他服务器将充当追随者。它有tasks的概念，它们是smallest 工作单元。任务分为任务组。任务组将具有要在同一位置执行的任务。一个或多个 任务组或任务作为作业进行管理。
Nomad 支持许多工作负载，包括开箱即用的 Docker。 Nomad 还支持跨数据中心部署，并且具有区域数据中心意识。
Fleet 是来自 CoreOS 的容器编排系统。 Feet 在 lower 级别运行，并在 systemd 之上运行。它可以管理应用程序依赖关系并确保所有必需的服务都在集群中的某个位置运行。如果服务失败，它会在另一台主机上重新启动服务。在分配资源时可以提供亲和和约束规则。
Fleet 有 engine 和 agents 的概念。在任何 point 在具有多个代理的集群中。任务提交到引擎，代理运行这些任务 在集群机器上。 Fleet 还支持开箱即用的 Docker。
除此之外，Amazon EC2 容器服务（ECS） , Azure 容器服务 (ACS), Cloud Foundry Diego 和 Google Container Engine 提供 container 编排功能作为 part 的 各自的 云平台产品。
正如我们在上一节中看到的，有许多可用的container 编排解决方案。不同的组织根据其环境选择不同的解决方案来解决问题。许多组织选择带有 Marathon 等框架的 Kubernetes 或 Mesos。在大多数情况下，使用 Docker 作为打包和部署工作负载的默认容器化方法。
在本章的其余部分，我们将展示 Mesos 如何与 Marathon 一起提供所需的容器编排功能。 许多 组织使用 Mesos，包括 Twitter、Airbnb、Apple、eBay、Netflix、Paypal、Uber、Yelp 等.
Mesos 可以被视为数据中心内核。 Enterprise DCOS 是 Mesosphere 支持的商业版 Mesos。为了在一个节点上运行多个任务，Mesos 使用了 resource 隔离概念。它依赖于 Linux 内核的 cgroups 来实现类似于容器方法的资源隔离。它还支持使用 Docker 的容器化 isolation。 Mesos 支持批处理工作负载和 OLTP 类型的工作负载。
下图展示了 Mesos 在逻辑上将多台机器抽象为一个资源集群：
Mesos 是 Apache License 下的开源顶级 Apache 项目。它从较低级别的物理机或虚拟机中抽象出较低级别的计算资源，例如 CPU、内存和存储。
在我们研究为什么我们需要 Mesos 和 Marathon 之前，让我们了解 Mesos 架构。
以下图显示了最简单 Mesos 的架构表示。 Mesos 的关键组件包括一个 Mesos Master、一组从节点、一个 ZooKeeper 服务和 Mesos 框架。 Mesos 框架进一步细分 分为两个组件：一个调度器< /span> 和一个 Executor。
上图中的方框解释如下：
- Master: The Mesos Master is responsible for managing all Mesos slaves. It gets information on the resource availability from all slave nodes and takes responsibility of filling the resources appropriately, based on certain resource policies and constraints. The Mesos Master preempts available resources from all slave machines and pools them as a single large machine. Master offers resources to frameworks running on slave machines based on this resource pool.
为了实现高可用性，Mesos Master 由 Mesos 主控备用支持跨度>组件。即使 master 不可用，仍然可以执行现有的任务。但是，如果没有主节点，则无法安排新任务。主备节点是等待活动主节点发生故障并在发生故障时接管主角色的节点。他们使用 ZooKeeper 进行主领导人选举。在这种情况下，必须满足最低法定人数要求才能进行领导人选举。
- Slave: The Mesos slaves are responsible for hosting task execution frameworks. Tasks are executed on the slave nodes. Mesos slaves can be started with attributes as key value pairs, such as datacenter = X. This will be used for constraint evaluations when deploying workloads. Slave machines share resource availability to the Mesos Master.
- ZooKeeper: This is a centralized coordination server used in Mesos to coordinate activities across the Mesos cluster. Mesos uses ZooKeeper for leader election in case of a Mesos Master failure.
- Framework: The Mesos framework is responsible for understanding the application constraints, accepting resource offers from the master, and, finally, running the tasks on the slave resources offered by the master. The Mesos framework consists of two components: Framework Scheduler and Framework Executor.
- The Scheduler is responsible for registering to Mesos and handles resource offers.
- Executor runs the actual program on the Mesos slave nodes.
该框架还负责执行某些政策和约束。例如，一个约束可以是，比方说，至少 500 MB 的 RAM 用于执行。
该框架是一个可插入的组件，可以用另一个框架替换。其工作流程如下图所示：
- The framework registers with the Mesos Master and waits for the resource offers. The scheduler may have many tasks in its queue to be executed with different resource constraints (task A-D in this example). A task, in this case, is a unit of work that is scheduled. For example, a Spring Boot microservice.
- The Mesos slave offers available resources to the Mesos Master. For example, the slave advertizes the CPU and memory available with the slave machine.
- Mesos Master creates a resource offer based on the allocation policies set and offers it to the scheduler component of the framework. The allocation policies determine to which framework the resources are to be offered and how many. The default policies can be customized by plugging additional allocation policies.
- Scheduler framework components, based on the constraints, capabilities, and policies may accept or reject the resource offering. For example, the framework rejects the resource offer if the resources are insufficient as per the constraints and policies set.
- If the scheduler component accepts the resource offer, it submits one or more task details to the Mesos Master with resource constraints per tasks. Let's say, in this example, it is ready to submit tasks A-D.
- The Mesos Master sends this list of tasks to the slave where the resources are available. The framework executor components installed on the slave machines pick up and run these tasks.
Mesos 支持许多框架，例如：
- Marathon and Aurora for long running processes, such as web applications
- Hadoop, Spark, and Storm for big data processing
- Chronos and Jenkins for batch scheduling
- Cassandra and Elasticsearch for data management
在本章中，我们将使用 Marathon 来运行 dockerized 微服务。
Marathon 是 Mesos 框架实现之一，可以同时运行容器和非容器执行。它专为长时间运行的应用程序而设计，例如 Web 服务器。它将确保以 Marathon 启动的服务将继续可用，即使它所在的 Mesos 从站失败。这将通过启动另一个实例来完成。
Marathon 是用 Scala 编写的，具有高度可扩展性。它提供 UI 和 REST API 以与 Marathon 交互，例如启动、停止、缩放和监控应用程序。
与 Mesos 类似，Marathon 的高可用性是通过运行多个指向 ZooKeeper 实例的 Marathon 实例来实现的。其中一个 Marathon 实例将充当领导者，其他实例将处于待机模式。如果leader master失败，将进行leader选举，并确定下一个活跃的master。
Marathon 的一些基本功能包括：
- Setting resource constraints
- Scale up, scale down, and instance management of applications
- Application version management
- Start and kill applications
Marathon 的一些高级功能包括：
- Rolling upgrades, rolling restarts, and rollbacks
- Blue-green deployments
在 第 12 章中，使用 Spring Cloud 组件扩展微服务，我们讨论了 Eureka 和 Zuul 实现负载均衡。使用容器编排工具，负载平衡和 DNS 服务开箱即用，使用起来更加简单。但是，当开发人员需要代码级控制负载均衡和流量路由时，比如基于业务参数的伸缩场景前面提到过，Spring Cloud 组件可能更适合。
Note
为了更好地理解这些技术，我们将在本章中直接使用 Mesos 和 Marathon。但是，在所有实际场景中，最好使用 Mesosphere DCOS，而不是使用普通的 Mesos 和 Marathon。
DCOS 在普通 Mesos 和 Marathon 之上提供了许多支持性组件，以管理企业级部署。
Note
DCOS 架构在以下链接中有很好的解释：https://dcos.io /docs/1.9/overview/architecture
让我们将用于扩展微服务的组件与 Spring Cloud 组件和 DCOS 提供的类似功能进行并排比较。
以下几点检查了 Spring Cloud 方法和 DCOS 之间的主要区别：
- Configurations are managed using the Spring Cloud Config server when we approach with Spring Cloud for scaling microservices. When using DCOS, configurations can be managed by using one of Spring Cloud Config, Spring Profiles, or tools such as Puppet, Chef, and more.
- The Eureka server was used for managing service discovery and Zuul was used for load balancing with the Spring Cloud approach. DCOS has Mesos DNS, VIPs, and HAProxy based Marathon-lb components to achieve the same.
- Logging and monitoring, explained in Chapter 13, Logging and Monitoring Microservices, is accomplished using Spring Boot Actuator, Seluth, and Hystrix . DCOS offers various log aggregation and metrics collection features out of the box.
在本节中，在 第 14 章，使用 Docker 容器化微服务，将部署到 AWS 云中，我们将使用 管理它们Mesos 和马拉松。
出于演示目的，我们将在本章中仅介绍两种服务（搜索和网站部署）。此外，为简单起见，我们将使用一个 EC2 实例。
使用 Ubuntu< 启动 t2.large EC2 实例/a> 16.04 版 AMI，将用于此部署。在这个例子中，我们使用另一个实例来运行 RabbitMQ；然而，这个可以在same 实例也是如此。
https://mesos.apache.org/gettingstarted/。
- To install Docker, perform the following steps:
- To install Marathon 1.4.3, follow the steps documented in the following link:
- To install ZooKeeper, perform the following steps:
或者，您可以使用 CloudFormation 在 AWS 上使用 DCOS 包分发，它提供开箱即用的高可用性 Mesos 集群。
- Log in to the EC2 instance and run the following commands:
- If you have more slave machines, you may repeat slave commands on those machines to add more nodes to the cluster.
- Open the following URL to see the Mesos console. In this example, there are three slaves running, connecting to the master:
您将看到类似于以下屏幕截图的 Mesos 控制台：
控制台的 Agents 部分显示有三个已激活的 Mesos 代理可供执行。它还表明没有 Active Tasks。
- Open the following URL to inspect the Marathon UI. Replace the IP address with the public IP address of the EC2 instance:
由于到目前为止还没有部署任何应用程序，因此 UI 的 Applications 部分是空的。
在上一节中，我们成功设置了 Mesos 和 Marathon。在本节中，我们将了解如何部署之前使用 Mesos 和 Marathon 开发的 BrownField PSS 应用程序。
Note
本章的完整源代码可在 chapter10 项目中找到Spring5Microservice" target="_blank">https://github.com/rajeshrv/Spring5Microservice。将 chapter9.* 复制到新的 STS 工作区，并将其重命名为 chapter10.*。
在本例中，我们将强制 Mesos 集群绑定到固定端口，但在理想情况下，我们将委托 Mesos 集群将服务动态绑定到端口。此外，由于我们没有使用 DNS 或 HA 代理，我们将对 IP 地址进行硬编码。在现实世界中，将为每个服务定义一个 VIP，并且该 VIP 将被服务使用。此 VIP 将由 DNS 和代理解析。
执行以下步骤以更改 BrownField 应用程序以在 AWS 上运行：
- Update search microservices (
application.properties) to reflect the RabbitMQ IP and port. Also, update the website (Application.javaandBrownFieldSiteController.java) to reflect the IP address of the EC2 machines. - Rebuild all microservices using Maven. Build and push the Docker images to the Docker Hub. The working directory has to be switched to the respective directories before executing these commands from the respective folders:
Docker 映像现已发布 到 Docker Hub 注册表。执行以下步骤来部署和运行 BrownFIeld PSS 服务：
- Start the dockerized RabbitMQ:
- At this point, the Mesos Marathon cluster is up and running and is ready to accept deployments. The deployment can be done by creating one JSON file per service, as follows:
- The preceding JSON will be stored on the
search.jsonfile. Similarly, create a JSON file for other services as well.
JSON结构解释如下：
id: This is a uniqueidof the application and it can be a logical name.Cpus,mem: This sets the resource constraints for this application. If the resource offer does not satisfy this resource constraint, Marathon will reject that resource offer from the Mesos Master.instances: How many instances of this application to start with? In the preceding configuration, by default, it starts one instance as soon as it gets deployed. Marathon will maintain the number of instances mentioned at any point.container: This parameter tells the Marathon executor to use the Docker container for execution.image: This tells the Marathon scheduler which Docker image has to be used for deployment. In this case, this will download thesearch-service:1.0image from the Docker Hub repository,rajeshrv.network: This value is used for Docker runtime to advice on thenetworkmode to be used when starting the new Docker container. This can beBRIDGEorHOST. In this case, theBRIDGEmode will be used.portMappings: The port mapping provides information on how to map internal and external ports. In the preceding configuration,hostPort, set as8090, tells the Marathon executor to use8090when starting the service. SincecontainerPortis set as0, the same host port will be assigned to the container. Marathon picks up random ports if thehostPortvalue is0.
- Once this JSON is created and saved, deploy this to Marathon using the Marathon REST APIs as follows:
- Alternatively, use the Marathon console for deployment as follows:
- Repeat this step for the website as well.
- Open the Marathon UI. As shown in the following diagram, the UI shows that both the applications are deployed and are in the
Runningstate. It also indicates that a1 of 1instance is in theRunningstate.
- If you inspect the search service, it shows
ipand the port it is bound to:
