13 接下来该做什么？
本章涵盖内容
-
回顾我们所取得的成果
-
接下来的方向
第 12 章结束了我们构建 Cube 编排器的工作。让我们回顾一下我们所取得的成就：
-
我们设计并实现了工作器组件。
-
我们设计并实现了管理器组件。
-
我们创建了一个存储接口，使我们能够实现用于存储任务和事件的内存和持久数据存储。这个接口随后被工作器和管理器组件所使用。
-
我们构建了一个调度器接口，然后重构了我们最初的轮询调度实现，使其符合这个接口。我们还编写了一个更复杂的调度器，称为 E-PVM。
-
最后，我们用一个合适的命令行界面（CLI）取代了简陋的 main.go 程序。这个 CLI 使我们能够独立运行工作器和管理器组件，甚至可以在不同的机器上运行。这个 CLI 还使我们能够执行管理操作：我们可以启动和停止任务、查询任务状态，以及获取编排系统中每个节点状态的概览。
虽然这一切都很 “不错”，但那又怎样呢？我们能用所获得的知识做些什么呢？从理论上来说，对这些问题的答案是，我们可以编写一个新的具备生产质量的编排器，一个可以与 Kubernetes 或 Nomad 等竞争或取代它们的东西。就个人而言，我觉得这个答案不太现实。Kubernetes 在行业中已经有了稳固的地位，而如果由于某种原因，你或你的公司不想使用 Kubernetes，Nomad 是一个不错的替代方案。不过，还有更实际的答案。
13.1 参与 Kubernetes 及相关工具的开发
虽然你可能不会编写自己的通用编排器，但你可以为 Kubernetes 做出贡献。请记住，Kubernetes 项目是开源的，而且它也是用 Go 语言编写的。截至撰写本文时，其代码库已有超过 3500 名贡献者。同样，也许你有兴趣为 K3s 项目做出贡献。K3s 被打包成单个二进制文件，它自称为 Kubernetes 的轻量级版本，目标是边缘计算、物联网、开发以及其他较小类型的部署（即那些不是 “网络规模” 的部署）。K3s 也是用 Go 语言编写的。
或者也许你想开发 Kubernetes 或 Nomad 的相关工具。凭借你对编排系统工作原理的了解，你可以为像 K9s（github.com/derailed/k9…）或 Wander（github.com/robinovitch…）这样的项目做出贡献。K9s 和 Wander 都为管理和使用 Kubernetes（K9s）和 Nomad（Wander）集群提供了终端用户界面（或 TUI）。
为什么你想为这些项目做出贡献呢？你能从中得到什么呢？也许你有一些这些项目目前无法满足的需求。通过为项目做出贡献，你可以满足自己的个人需求，同时也能帮助其他可能觉得你的贡献有用的人。或者也许你只是想为一个开源项目做出贡献。看到自己的名字被列为项目仓库的贡献者之一，会有一种满足感。
13.2 管理器 - 工作器模式与工作流系统
Kubernetes 和 Nomad 是通用编排系统的例子，它们使用了有时被称为管理器-工作器模式的架构。正如我们在 Cube 编排器的实现中所看到的，管理器-工作器模式有一个管理器组件，它管理着一组工作器，用于运行任务。在 Cube（以及 Kubernetes 和 Nomad）的情况下，这些任务恰好是可用于构建复杂分布式系统的应用程序。然而，还有其他类型的系统也使用这种管理器-工作器模式。
其中一种其他类型的系统是工作流系统。工作流系统为用户提供了一种编程方式来定义和运行一系列任务。虽然这听起来与编排系统类似，但工作流系统更加专门化，专注于自动化定义明确的流程中的步骤。一个流行的工作流系统是 Apache Airflow（github.com/apache/airf…）。
如果你在 DevOps 或网站可靠性工程（SRE）团队工作，你很可能已经在使用一个或多个工作流系统。你的团队可能负责管理许多为开发团队提供基础设施的服务，而开发团队正在为面向用户的产品编写代码。基础设施服务可能包括数据库、虚拟机、Kubernetes 或 Nomad 集群、构建工具等等。所有这些服务都有管理它们的流程。而且这些流程几乎肯定可以分解为可以自动化的离散步骤。所以，帮助你自动化管理这些服务的一个选择可能是编写你自己的专用工作流系统。
13.3 管理器-工作器模式与集成系统
还有其他地方可以应用对管理器 - 工作器模式的了解。例如，在我目前的团队中，我们意识到我们集成服务的原始版本很脆弱，并且在我们展望不久的将来时，很难扩展以满足公司的需求。这个集成服务相当简单直接：它需要从物联网设备摄取数据，对这些数据应用一些转换，然后将数据转发到其他目的地（数据库、监控系统、财务系统等）。我们最初的实现只支持一些硬编码的转换。此外，我们将其构建到我们的单体后端系统中，并且没有提供任何合理的方法来随着时间的推移对其进行扩展。
因此，我们开始设计一个新的集成服务。在为这个新服务进行设计时，我意识到我所描述的实际上是一个可以使用管理器-工作器模式的服务。与通用编排系统中的任务不同，我们集成系统的主题是工作流。我们有一个工作器组件，负责执行每个工作流的各个步骤。我们还有一个管理器组件，负责管理任务，例如在系统中创建、更新和删除工作流，以及将来自设备的传入请求分派给各个工作器。有了这个新设计，我们在操作集成系统方面有了更大的灵活性。我们可以在现有的单体系统中运行它，选择拆除原来的集成服务并用这个新的替代。我们可以将它作为一个单独的微服务运行，所有组件在一台机器上的单个进程中运行（非常适合开发目的）。或者我们可以将系统的各个组件作为单独的进程运行，在一台或多台不同的机器上。这对生产环境非常好，并且使我们能够根据需要进行扩展。
13.4 结束语
前面的例子只是你可以将从本书中获得的知识应用到实际情况中的几种方式。因此，你花在编写 Cube 编排器上的时间不仅仅是一次学术练习。
归根结底，我希望你也能从中获得乐趣！
以下是我们所涵盖内容的回顾：
- 要根据思维模型将代码组织成 Go 类型，请参阅第 2 章。
- 要使用 Docker API 启动和停止容器，请参阅第 3 章。
- 要在任务的生命周期内管理任务状态，请参阅第 4 章。
- 要使用 chi 路由器编写 HTTP API，请参阅第 5 章和第 8 章。
- 要将任务调度到一组工作器上，请参阅第 7 章和第 10 章。
- 要使用 BoltDB 库将任务存储在键值数据存储中，请参阅第 11 章。
- 要使用 Cobra 库编写命令行应用程序，请参阅第 12 章。
