介绍

想在笔记本电脑上尝试 MongoDB？只需执行一个命令，你就会有一个轻量级的、独立的沙箱。完成后可以删除你所做的所有痕迹。

想在多个环境中使用相同的 程序栈 application stack 副本？构建你自己的容器镜像，让你的开发、测试、运维和支持团队使用相同的环境克隆。

容器正在彻底改变整个软件生命周期：从最早的技术性实验和概念证明，贯穿了开发、测试、部署和支持。

编排工具用来管理如何创建、升级多个容器，并使之高可用。编排还控制容器如何连接，以从多个微服务容器构建复杂的应用程序。

丰富的功能、简单的工具和强大的 API 使容器和编排功能成为 DevOps 团队的首选，将其集成到连续集成（CI） 和连续交付 （CD） 的工作流程中。

这篇文章探讨了在容器中运行和编排 MongoDB 时遇到的额外挑战，并说明了如何克服这些挑战。

MongoDB 的注意事项

使用容器和编排运行 MongoDB 有一些额外的注意事项：

• MongoDB 数据库节点是有状态的。如果容器发生故障并被重新编排，数据则会丢失（能够从副本集的其他节点恢复，但这需要时间），这是不合需要的。为了解决这个问题，可以使用诸如 Kubernetes 中的 数据卷 volume 抽象等功能来将容器中临时的 MongoDB 数据目录映射到持久位置，以便数据在容器故障和重新编排过程中存留。
• 一个副本集中的 MongoDB 数据库节点必须能够相互通信 - 包括重新编排后。副本集中的所有节点必须知道其所有对等节点的地址，但是当重新编排容器时，可能会使用不同的 IP 地址重新启动。例如，Kubernetes Pod 中的所有容器共享一个 IP 地址，当重新编排 pod 时，IP 地址会发生变化。使用 Kubernetes，可以通过将 Kubernetes 服务与每个 MongoDB 节点相关联来处理，该节点使用 Kubernetes DNS 服务提供“主机名”，以保持服务在重新编排中保持不变。
• 一旦每个单独的 MongoDB 节点运行起来（每个都在自己的容器中），则必须初始化副本集，并添加每个节点到其中。这可能需要在编排工具之外提供一些额外的处理。具体来说，必须使用目标副本集中的一个 MongoDB 节点来执行 rs.initiate 和 rs.add 命令。
• 如果编排框架提供了容器的自动化重新编排（如 Kubernetes），那么这将增加 MongoDB 的弹性，因为这可以自动重新创建失败的副本集成员，从而在没有人为干预的情况下恢复完全的冗余级别。
• 应该注意的是，虽然编排框架可能监控容器的状态，但是不太可能监视容器内运行的应用程序或备份其数据。这意味着使用 MongoDB Enterprise Advanced 和 MongoDB Professional 中包含的 MongoDB Cloud Manager 等强大的监控和备份解决方案非常重要。可以考虑创建自己的镜像，其中包含你首选的 MongoDB 版本和 MongoDB Automation Agent。

使用 Docker 和 Kubernetes 实现 MongoDB 副本集

如上节所述，分布式数据库（如 MongoDB）在使用编排框架（如 Kubernetes）进行部署时，需要稍加注意。本节将介绍详细介绍如何实现。

我们首先在单个 Kubernetes 集群中创建整个 MongoDB 副本集（通常在一个数据中心内，这显然不能提供地理冗余）。实际上，很少有必要改变成跨多个集群运行，这些步骤将在后面描述。

副本集的每个成员将作为自己的 pod 运行，并提供一个公开 IP 地址和端口的服务。这个“固定”的 IP 地址非常重要，因为外部应用程序和其他副本集成员都可以依赖于它在重新编排 pod 的情况下保持不变。

下图说明了其中一个 pod 以及相关的复制控制器和服务。

图 1：MongoDB 副本集成员被配置为 Kubernetes Pod 并作为服务公开

逐步介绍该配置中描述的资源：

• 从核心开始，有一个名为 mongo-node1 的容器。mongo-node1 包含一个名为 mongo 的镜像，这是一个在 Docker Hub 上托管的一个公开可用的 MongoDB 容器镜像。容器在集群中暴露端口 27107。
• Kubernetes 的数据卷功能用于将连接器中的 /data/db 目录映射到名为 mongo-persistent-storage1 的永久存储上，这又被映射到在 Google Cloud 中创建的名为 mongodb-disk1 的磁盘中。这是 MongoDB 存储其数据的地方，这样它可以在容器重新编排后保留。
• 容器保存在一个 pod 中，该 pod 中有标签命名为 mongo-node，并提供一个名为 rod 的（任意）示例。
• 配置 mongo-node1 复制控制器以确保 mongo-node1 pod 的单个实例始终运行。
• 名为 mongo-svc-a 的 负载均衡 服务给外部开放了一个 IP 地址以及 27017 端口，它被映射到容器相同的端口号上。该服务使用选择器来匹配 pod 标签来确定正确的 pod。外部 IP 地址和端口将用于应用程序以及副本集成员之间的通信。每个容器也有本地 IP 地址，但是当容器移动或重新启动时，这些 IP 地址会变化，因此不会用于副本集。

下一个图显示了副本集的第二个成员的配置。

图 2：第二个 MongoDB 副本集成员配置为 Kubernetes Pod

90％ 的配置是一样的，只有这些变化：

• 磁盘和卷名必须是唯一的，因此使用的是 mongodb-disk2 和 mongo-persistent-storage2
• Pod 被分配了一个 instance: jane 和 name: mongo-node2 的标签，以便新的服务可以使用选择器与图 1 所示的 rod Pod 相区分。
• 复制控制器命名为 mongo-rc2
• 该服务名为mongo-svc-b，并获得了一个唯一的外部 IP 地址（在这种情况下，Kubernetes 分配了 104.1.4.5）

第三个副本成员的配置遵循相同的模式，下图展示了完整的副本集：

图 3：配置为 Kubernetes 服务的完整副本集成员

请注意，即使在三个或更多节点的 Kubernetes 群集上运行图 3 所示的配置，Kubernetes 可能（并且经常会）在同一主机上编排两个或多个 MongoDB 副本集成员。这是因为 Kubernetes 将三个 pod 视为属于三个独立的服务。

为了在区域内增加冗余，可以创建一个附加的 headless 服务。新服务不向外界提供任何功能（甚至不会有 IP 地址），但是它可以让 Kubernetes 通知三个 MongoDB pod 形成一个服务，所以 Kubernetes 会尝试在不同的节点上编排它们。

图 4：避免同一 MongoDB 副本集成员的 Headless 服务

配置和启动 MongoDB 副本集所需的实际配置文件和命令可以在白皮书《启用微服务：阐述容器和编排》中找到。特别的是，需要一些本文中描述的特殊步骤来将三个 MongoDB 实例组合成具备功能的、健壮的副本集。

多个可用区 MongoDB 副本集

上面创建的副本集存在风险，因为所有内容都在相同的 GCE 集群中运行，因此都在相同的 可用区 availability zone 中。如果有一个重大事件使可用区离线，那么 MongoDB 副本集将不可用。如果需要地理冗余，则三个 pod 应该在三个不同的可用区或地区中运行。

令人惊奇的是，为了创建在三个区域之间分割的类似的副本集（需要三个集群），几乎不需要改变。每个集群都需要自己的 Kubernetes YAML 文件，该文件仅为该副本集中的一个成员定义了 pod、复制控制器和服务。那么为每个区域创建一个集群，永久存储和 MongoDB 节点是一件很简单的事情。

图 5：在多个可用区域上运行的副本集

下一步

要了解有关容器和编排的更多信息 - 所涉及的技术和所提供的业务优势 - 请阅读白皮书《启用微服务：阐述容器和编排》。该文件提供了获取本文中描述的副本集，并在 Google Container Engine 中的 Docker 和 Kubernetes 上运行的完整的说明。

作者简介：

Andrew 是 MongoDB 的产品营销总经理。他在去年夏天离开 Oracle 加入 MongoDB，在 Oracle 他花了 6 年多的时间在产品管理上，专注于高可用性。他可以通过 @andrewmorgan 或者在他的博客（clusterdb.com）评论联系他。

via: https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes

作者：Andrew Morgan 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

写 Go 的人往往对它的错误处理模式有一定的看法。按不同的语言经验，人们可能有不同的习惯处理方法。这就是为什么我决定要写这篇文章，尽管有点固执己见，但我认为听取我的经验是有用的。我想要讲的主要问题是，很难去强制执行良好的错误处理实践，错误经常没有堆栈追踪，并且错误处理本身太冗长。不过，我已经看到了一些潜在的解决方案，或许能帮助解决一些问题。

与其他语言的快速比较

在 Go 中，所有的错误都是值。因为这点，相当多的函数最后会返回一个 error, 看起来像这样：

func (s *SomeStruct) Function() (string, error)

因此这导致调用代码通常会使用 if 语句来检查它们：

bytes, err := someStruct.Function()
if err != nil {
  // Process error
}

另外一种方法，是在其他语言中，如 Java、C#、Javascript、Objective C、Python 等使用的 try-catch 模式。如下你可以看到与先前的 Go 示例类似的 Java 代码，声明 throws 而不是返回 error：

public String function() throws Exception

它使用的是 try-catch 而不是 if err != nil：

try {
  String result = someObject.function()
  // continue logic
}
catch (Exception e) {
  // process exception
}

当然，还有其他的不同。例如，error 不会使你的程序崩溃，然而 Exception 会。还有其他的一些，在本篇中会专门提到这些。

实现集中式错误处理

退一步，让我们看看为什么要在一个集中的地方处理错误，以及如何做到。

大多数人或许会熟悉的一个例子是 web 服务 - 如果出现了一些未预料的的服务端错误，我们会生成一个 5xx 错误。在 Go 中，你或许会这么实现：

func init() {
    http.HandleFunc("/users", viewUsers)
    http.HandleFunc("/companies", viewCompanies)
}

func viewUsers(w http.ResponseWriter, r *http.Request) {
    user // some code
    if err := userTemplate.Execute(w, user); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

func viewCompanies(w http.ResponseWriter, r *http.Request) {
    companies = // some code
    if err := companiesTemplate.Execute(w, companies); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

这并不是一个好的解决方案，因为我们不得不重复地在所有的处理函数中处理错误。为了能更好地维护，最好能在一处地方处理错误。幸运的是，在 Go 语言的官方博客中，Andrew Gerrand 提供了一个替代方法，可以完美地实现。我们可以创建一个处理错误的 Type：

type appHandler func(http.ResponseWriter, *http.Request) error

func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if err := fn(w, r); err != nil {
        http.Error(w, err.Error(), 500)
    }
}

这可以作为一个封装器来修饰我们的处理函数：

func init() {
    http.Handle("/users", appHandler(viewUsers))
    http.Handle("/companies", appHandler(viewCompanies))
}

接着我们需要做的是修改处理函数的签名来使它们返回 errors。这个方法很好，因为我们做到了 DRY 原则，并且没有重复使用不必要的代码 - 现在我们可以在单独一个地方返回默认错误了。

错误上下文

在先前的例子中，我们可能会收到许多潜在的错误，它们中的任何一个都可能在调用堆栈的许多环节中生成。这时候事情就变得棘手了。

为了演示这点，我们可以扩展我们的处理函数。它可能看上去像这样，因为模板执行并不是唯一一处会发生错误的地方：

func viewUsers(w http.ResponseWriter, r *http.Request) error {
    user, err := findUser(r.formValue("id")) 
    if err != nil {
      return err;
    }
    return userTemplate.Execute(w, user);
}

调用链可能会相当深，在整个过程中，各种错误可能在不同的地方实例化。Russ Cox的这篇文章解释了如何避免遇到太多这类问题的最佳实践：

“在 Go 中错误报告的部分约定是函数包含相关的上下文，包括正在尝试的操作（比如函数名和它的参数）。”

这个给出的例子是对 OS 包的一个调用：

err := os.Remove("/tmp/nonexist")
fmt.Println(err)

它会输出：

remove /tmp/nonexist: no such file or directory

总结一下，执行后，输出的是被调用的函数、给定的参数、特定的出错信息。当在其他语言中创建一个 Exception 消息时，你也可以遵循这个实践。如果我们在 viewUsers 处理中坚持这点，那么几乎总是能明确错误的原因。

问题来自于那些不遵循这个最佳实践的人，并且你经常会在第三方的 Go 库中看到这些消息：

Oh no I broke

这没什么帮助 - 你无法了解上下文，这使得调试很困难。更糟糕的是，当这些错误被忽略或返回时，这些错误会被备份到堆栈中，直到它们被处理为止：

if err != nil {
  return err
}

这意味着错误何时发生并没有被传递出来。

应该注意的是，所有这些错误都可以在 Exception 驱动的模型中发生 - 糟糕的错误信息、隐藏异常等。那么为什么我认为该模型更有用？

即便我们在处理一个糟糕的异常消息，我们仍然能够了解它发生在调用堆栈中什么地方。因为堆栈跟踪，这引发了一些我对 Go 不了解的部分 - 你知道 Go 的 panic 包含了堆栈追踪，但是 error 没有。我推测可能是 panic 会使你的程序崩溃，因此需要一个堆栈追踪，而处理错误并不会，因为它会假定你在它发生的地方做一些事。

所以让我们回到之前的例子 - 一个有糟糕错误信息的第三方库，它只是输出了调用链。你认为调试会更容易吗？

panic: Oh no I broke
[signal 0xb code=0x1 addr=0x0 pc=0xfc90f]

goroutine 1103 [running]:
panic(0x4bed00, 0xc82000c0b0)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
github.com/Org/app/core.(_app).captureRequest(0xc820163340, 0x0, 0x55bd50, 0x0, 0x0)
/home/ubuntu/.go_workspace/src/github.com/Org/App/core/main.go:313 +0x12cf
github.com/Org/app/core.(_app).processRequest(0xc820163340, 0xc82064e1c0, 0xc82002aab8, 0x1)
/home/ubuntu/.go_workspace/src/github.com/Org/App/core/main.go:203 +0xb6
github.com/Org/app/core.NewProxy.func2(0xc82064e1c0, 0xc820bb2000, 0xc820bb2000, 0x1)
/home/ubuntu/.go_workspace/src/github.com/Org/App/core/proxy.go:51 +0x2a
github.com/Org/app/core/vendor/github.com/rusenask/goproxy.FuncReqHandler.Handle(0xc820da36e0, 0xc82064e1c0, 0xc820bb2000, 0xc5001, 0xc820b4a0a0)
/home/ubuntu/.go_workspace/src/github.com/Org/app/core/vendor/github.com/rusenask/goproxy/actions.go:19 +0x30

我认为这可能是 Go 的设计中被忽略的东西 - 不是所有语言都不会忽视的。

如果我们使用 Java 作为一个随意的例子，其中人们犯的一个最愚蠢的错误是不记录堆栈追踪：

LOGGER.error(ex.getMessage()) // 不记录堆栈追踪
LOGGER.error(ex.getMessage(), ex) // 记录堆栈追踪

但是 Go 似乎在设计中就没有这个信息。

在获取上下文信息方面 - Russ 还提到了社区正在讨论一些潜在的接口用于剥离上下文错误。关于这点，了解更多或许会很有趣。

堆栈追踪问题解决方案

幸运的是，在做了一些查找后，我发现了这个出色的 Go 错误库来帮助解决这个问题，来给错误添加堆栈跟踪：

if errors.Is(err, crashy.Crashed) {
  fmt.Println(err.(*errors.Error).ErrorStack())
}

不过，我认为这个功能如果能成为语言的 第一类公民 first class citizenship 将是一个改进，这样你就不必做一些类型修改了。此外，如果我们像先前的例子那样使用第三方库，它可能没有使用 crashy - 我们仍有相同的问题。

我们对错误应该做什么？

我们还必须考虑发生错误时应该发生什么。这一定有用，它们不会让你的程序崩溃，通常也会立即处理它们：

err := method()
if err != nil {
  // some logic that I must do now in the event of an error!
}

如果我们想要调用大量方法，它们会产生错误，然后在一个地方处理所有错误，这时会发生什么？看上去像这样：

err := doSomething()
if err != nil {
  // handle the error here
}

func doSomething() error {
  err := someMethod()
  if err != nil {
    return err
  }
  err = someOther()
  if err != nil {
    return err
  }
  someOtherMethod()
}

这感觉有点冗余，在其他语言中你可以将多条语句作为一个整体处理。

try {
  someMethod()
  someOther()
  someOtherMethod()
}
catch (Exception e) {
  // process exception
}

或者只要在方法签名中传递错误：

public void doSomething() throws SomeErrorToPropogate {
  someMethod()
  someOther()
  someOtherMethod()
}

我个人认为这两个例子实现了一件事情，只是 Exception 模式更少冗余，更加弹性。如果有什么的话，我觉得 if err！= nil 感觉像样板。也许有一种方法可以清理？

将失败的多条语句做为一个整体处理错误

首先，我做了更多的阅读，并在 Rob Pike 写的 Go 博客中发现了一个比较务实的解决方案。

他定义了一个封装了错误的方法的结构体：

type errWriter struct {
    w   io.Writer
    err error
}

func (ew *errWriter) write(buf []byte) {
    if ew.err != nil {
        return
    }
    _, ew.err = ew.w.Write(buf)
}

让我们这么做：

ew := &errWriter{w: fd}
ew.write(p0[a:b])
ew.write(p1[c:d])
ew.write(p2[e:f])
// and so on
if ew.err != nil {
    return ew.err
}

这也是一个很好的方案，但是我感觉缺少了点什么 - 因为我们不能重复使用这个模式。如果我们想要一个含有字符串参数的方法，我们就不得不改变函数签名。或者如果我们不想执行写操作会怎样？我们可以尝试使它更通用：

type errWrapper struct {
    err error
}

func (ew *errWrapper) do(f func() error) {
    if ew.err != nil {
        return
    }
    ew.err = f();
}

但是我们有一个相同的问题，如果我们想要调用含有不同参数的函数，它就无法编译了。然而你可以简单地封装这些函数调用：

w := &errWrapper{}

w.do(func() error {
    return someFunction(1, 2);
})

w.do(func() error {
    return otherFunction("foo");
})

err := w.err

if err != nil {
// process error here
}

这可以用，但是并没有太大帮助，因为它最终比标准的 if err != nil 检查带来了更多的冗余。如果有人能提供其他解决方案，我会很有兴趣听。或许这个语言本身需要一些方法来以不那么臃肿的方式传递或者组合错误 - 但是感觉似乎是特意设计成不那么做。

总结

看完这些之后，你可能会认为我在对 error 挑刺儿，由此推论我反对 Go。事实并非如此，我只是将它与我使用 try catch 模型的经验进行比较。它是一个用于系统编程很好的语言，并且已经出现了一些优秀的工具。仅举几例，有 Kubernetes、Docker、Terraform、Hoverfly 等。还有小型、高性能、本地二进制的优点。但是，error 难以适应。 我希望我的推论是有道理的，而且一些方案和解决方法可能会有帮助。

作者简介：

Andrew 是 OpenCredo 的顾问，于 2015 年加入公司。Andrew 在多个行业工作多年，开发基于 Web 的企业应用程序。

via: https://opencredo.com/why-i-dont-like-error-handling-in-go

作者：Andrew Morgan 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出