NGINX 微服务参考架构简介

作者注–这篇博文是系列文章中的第一篇：

1. NGINX 微服务参考架构简介（本篇博文）
2. MRA，第 2 部分： 代理模型
3. MRA，第 3 部分： 路由器网格模型
4. MRA，第 4 部分： 织物模型
5. MRA，第 5 部分： 调整十二要素应用以适应微服务
6. MRA，第 6 部分： 使用 NGINX Plus 实现断路器模式

所有六个博客，加上一个关于微服务应用的 Web 前端的博客 <.htmla>，都已收集到一本免费电子书中。

另请查看有关微服务的其他 NGINX 资源：

• Chris Richardson 撰写的关于微服务应用设计的系列文章，非常有用且很受欢迎
• Chris Richardson 的文章被汇编成一本免费电子书，并附上了使用 NGINX 和 NGINX Plus 实现微服务的额外提示
• 其他微服务博客文章
• 微服务网络研讨会
• 微服务解决方案页面
• 话题： 微服务

介绍

NGINX 从一开始就参与了微服务运动。 NGINX 的轻量、高性能和灵活性特性非常适合微服务。

NGINX Docker 镜像是 Docker Hub 上下载次数最多的应用镜像，并且您今天在 Web 上找到的大多数微服务平台都包含以某种形式部署 NGINX 并连接到欢迎页面的演示。

因为我们相信转向微服务对于客户的成功至关重要，所以我们在 NGINX 启动了一个专门的计划来开发功能和实践，以支持 Web应用开发和交付的这一巨大转变。 我们还认识到，实现微服务的方法有很多种，其中许多方法都是新颖的并且特定于各个开发团队的需求。 我们认为需要模型来让公司更轻松地开发和交付自己的基于微服务的应用。

考虑到所有这些，我们在 NGINX 专业服务中开发了 NGINX 微服务参考架构 (MRA) - 一组可用于创建自己的微服务应用的模型。

MRA 由两部分组成：对三个模型的详细描述，以及实现我们的示例照片共享程序 Ingenious 的可下载代码。 这三种模型之间的唯一区别是用于为每个模型配置 NGINX Plus 的配置代码。 本系列博客文章将提供每个模型的概述描述；详细描述、配置代码和 Ingenious 示例程序的代码将于今年晚些时候提供。

我们构建此参考架构的目标有三个：

• 为客户和行业提供构建基于微服务的系统的现成蓝图，加速和改进开发
• 创建一个用于测试 NGINX 和 NGINX Plus 新功能的平台，无论是内部开发还是外部开发，并分布在产品核心中或作为动态模块
• 帮助我们了解合作伙伴的系统和组件，以便我们能够全面了解微服务生态系统

微服务参考架构也是为 NGINX 客户提供的专业服务的重要组成部分。 在 MRA 中，我们尽可能使用NGINX 开源和NGINX Plus共有的功能，并在需要时使用 NGINX Plus 特定的功能。 NGINX Plus 依赖性在更复杂的模型中更强，如下所述。 我们预计，许多 MRA 用户将受益于 NGINX 专业服务和技术支持（附带 NGINX Plus 订阅）。

微服务参考架构概述

我们正在构建符合十二要素应用原则的参考架构。服务设计为轻量级、短暂且无状态。

MRA 使用行业标准组件，如 Docker 容器、多种语言（Java、PHP、Python、NodeJS/JavaScript 和 Ruby）以及基于 NGINX 的网络。

转向微服务时，应用设计和架构的最大变化之一是使用网络在应用的功能组件之间进行通信。 在单片应用程序中，应用组件在内存中通信。 在微服务应用中，通信通过网络进行，因此网络设计和实施变得至关重要。

为了反映这一点，MRA 已使用三种不同的网络模型实现，所有模型均使用 NGINX 或 NGINX Plus。 它们的范围从相对简单到功能丰富且更复杂：

• 代理模型——一种简单的网络模型，适合将 NGINX Plus 实现为微服务应用的控制器或API 网关。 该模型建立在Docker Cloud之上。
• 路由器网格模型——一种更为强大的网络连接方法，每个主机上都有一个负载均衡器，并可以管理系统之间的连接。 该模型与Deis 1.0的架构类似。
• 结构模型- 结构模型是 MRA 的精华，每个容器中都配备 NGINX Plus，处理所有进出流量。 它适用于高负载系统并支持所有级别的 SSL/TLS，NGINX Plus 可提供降低延迟、持久 SSL/TLS 连接、服务发现以及跨所有微服务的断路器模式。

我们的目的是让您使用这些模型作为您自己的微服务实现的起点，我们欢迎您就如何改进 MRA 提出反馈。 （您可以从下面的评论开始添加。）

以下是每个模型的简要说明；我们建议您阅读所有说明，以开始了解如何最好地使用一个或多个模型。 未来的博客文章将详细描述每个模型，每个博客文章一个。

代理模型简介

代理模型是一种相对简单的网络模型。 它是初始微服务应用的绝佳起点，或作为转换中等复杂的单片遗留应用程序的目标模型。

在代理模型中，NGINX 或 NGINX Plus 充当入口控制器，将请求路由到微服务。 当新服务创建时，NGINX Plus 可以使用动态 DNS 进行服务发现。 当使用 NGINX 作为API 网关时，代理模型也适合用作模板。

如果需要服务间通信（大多数不同复杂程度的应用都需要这种通信），服务注册表会在集群内提供相应机制。 （请参阅此博客文章以了解服务间通信机制的详细列表。） Docker Cloud 默认使用这种方法；为了连接到另一个服务，服务会查询 DNS 并获取要发送请求的 IP 地址。

一般来说，代理模型适用于简单到中等复杂的应用。 这不是最有效的负载均衡方法/模型，尤其是在大规模情况下；如果您有大量负载均衡要求，请使用下面描述的模型之一。（“规模”可以指大量微服务以及高流量。）

编辑 – 有关此模型的深入探讨，请参阅MRA，第 2 部分 – 代理模型。

升级至路由器网格模型

路由器网格模型具有中等复杂度，非常适合强大的新应用设计，也适合转换不需要 Fabric 模型功能的更复杂、单片的遗留应用程序。

路由器网格模型通过在每个主机上运行负载均衡器并主动管理微服务之间的连接，采取比代理模型更为强大的网络方法。 路由器网格模型的主要优点是服务之间更高效、更强大的负载均衡。 如果您使用 NGINX Plus，您可以实施主动健康检查来监控各个服务实例，并在它们关闭时适当地限制流量。

Deis Workflow使用类似于路由器网格模型的方法来路由服务之间的流量，其中 NGINX 实例在每个主机上的容器中运行。 随着新应用实例的启动，一个进程会从etcd服务注册表中提取服务信息并将其加载到 NGINX 中。NGINX Plus 也可以在此模式下工作，使用各种位置及其相关的上游。

编辑 – 有关该模型的深入探讨，请参阅MRA，第 3 部分 – 路由器网格模型。

最后——Fabric 模型，带有可选的 SSL/TLS

我们 NGINX 人员对 Fabric 模型最为感兴趣。 它实现了微服务的一些最令人兴奋的承诺，包括高性能、负载均衡的灵活性以及深入到单个微服务级别的无处不在的 SSL/TLS。 Fabric 模型适用于安全应用，并且可扩展到非常大的应用。

在 Fabric 模型中，NGINX Plus 部署在每个容器内，并成为进出容器的所有 HTTP 流量的代理。 应用与所有服务连接的本地主机位置对话，并依靠 NGINX Plus 进行服务发现、负载均衡和健康检查。

在我们的配置中，NGINX Plus 向ZooKeeper查询应用程序需要连接的所有服务实例。 例如，将 DNS 频率设置valid设置为 1 秒，NGINX Plus 每秒扫描一次 ZooKeeper 实例变化，并适当地路由流量。

由于 NGINX Plus 具有强大的 HTTP 处理能力，我们可以使用 keepalives 来维护与微服务的状态连接，从而减少延迟并提高性能。 当使用 SSL/TLS 来保护微服务之间的流量时，这是一个特别有价值的功能。

最后，我们使用 NGINX Plus 的主动健康检查来管理流向健康实例的流量，并且本质上免费构建断路器模式。

编辑 – 有关此模型的深入探讨，请参阅MRA，第 4 部分 – 织物模型。

一款巧妙的 MRA 演示应用程序

MRA 包含一个示例应用作为演示：Ingenious 照片共享应用程序。Ingenious 在三种模型（代理、路由器网格和 Fabric）中均有实现。 Ingenious 演示应用程序将于今年晚些时候向公众发布。

Ingenious 是一个照片存储和共享应用的简化版本，类似于 Flickr 或 Shutterfly。 我们选择照片共享应用有几个原因：

• 用户和开发人员都很容易掌握它的作用。
• 有多个数据维度需要管理。
• 在应用程序中加入漂亮的设计很容易。
• 它提供非对称计算要求——高强度和低强度处理的混合——从而能够对不同类型的功能的故障转移、扩展和监控功能进行实际测试。

结论

NGINX 微服务参考架构对于我们以及迄今为止与我们分享该架构的客户和合作伙伴来说是一个令人兴奋的发展。 在接下来的几个月里，我们将发布一系列博客文章来详细描述它，并在今年晚些时候发布它。 我们还将在 9 月 7 日至 9 日在德克萨斯州奥斯汀举行的nginx.conf 2016上详细讨论这个问题。请向我们提供您的反馈，我们期待您的光临。

与此同时，请亲自尝试使用 NGINX Plus 的 MRA – 立即开始30 天免费试用，或联系我们讨论您的用例。