管理过程-微服务运维实战：管理有状态服务

将管理任务作为一次性进程运行。在我们的示例中，所有进程都作为Docker容器执行，显然满足了这一要求。——通过

现在通过了十二个因素中的九个。我们的目标是要满足所有十二个因素吗？其实这个问题是错的。一个措辞更好的问题是，我们是否打算满足所有十二个因素。通常情况下做不到。世界不是一夜之间建成的，我们不能抛弃所有的老代码而让一切重新开始。即使可以，十二因素应用程序原则也有一个很大的谬误，即假设存在一个完全由无状态服务组成的系统。

无论采用哪种架构风格（包括微服务），应用程序都有状态！在微服务风格的架构中，每个服务可以有多个实例，每个服务实例应该设计成无状态的。这意味着，服务实例不会在操作过程中存储任何数据。因此，无状态意味着任何服务实例都可以从其他地方获取执行一个动作所需的所有应用程序状态。这是微服务风格应用程序的一个重要的架构约束条件，因为它支持弹性、伸缩性，并允许任何可用的服务实例执行任何任务。尽管状态不在我们正在开发的服务中，但它仍然存在，需要以某种方式进行管理。我们没有开发存储状态的数据库，这并不意味着它不应该遵循相同的原则，并具有可伸缩性、容错性、弹性等。

因此，所有系统都有状态，但是，如果服务可以干净地将行为与数据分离，并且能够获取执行任何动作所需的数据，则服务可以是无状态的。

十二因素应用程序原则的作者是否会如此短视以至于认为状态不存在？他们的确不是这样的。他们认为，除了我们编写的代码之外，所有东西都是由其他人维护的服务。以MongoDB为例，它的主要目的是存储状态，所以它当然是有状态的。十二因素应用程序原则的作者假设我们愿意让其他人管理有状态的服务，并只关注我们正在开发的服务。(www.xing528.com)

在某些情况下，虽然我们可能选择使用云供应商维护的Mongo作为服务，但在许多其他情况下，这样的选择并不是最有效的。如果说还有什么其他原因的话，这种服务往往是非常昂贵的。当我们没有知识或能力维护后台服务时，这种成本往往是值得付出的。然而，当自己运行一个数据库时，可以期待更好的和更便宜的结果。这种情况下，它是我们的服务之一，显然是有状态的。我们没有编写所有服务这一事实并不意味着我们没有运行它们，因此，我们要对它们负责。

好消息是，我们失败的三个原则都与状态有关。如果能够以一种在停止时保持其状态并在所有实例之间共享状态的方式创建服务，那么我们会设法使整个系统都是云原生的。可以在任何地方运行它，根据需要扩展它的服务，并使系统容错。

还没有涉及的难题中的唯一主要部分就是创建和管理有状态的服务。在本章之后，你将在Swarm集群中运行任何类型的服务。

下面将从创建一个Swarm集群开始本章的实际部分。现在只使用AWS作为演示。这里探讨的原则可以应用于几乎任何云计算供应商，也可以应用于本地服务器中。