NGINX 微服务参考架构简介

Chris Stetson

作者注：本文是系列博客文章的第一篇：

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

全部6篇博客以及一篇关于微服务应用Web前端<.htmla>的博客已汇编成一本免费电子书。

另请参阅以下有关微服务的NGINX资源：

• Chris Richardson 撰写的一系列实用且广受欢迎的文章，主题是微服务应用设计
• Chris Richardson 的文章汇编成一本免费电子书，并提供使用 NGINX 和 NGINX Plus 实施微服务的更多技巧
• 其他微服务博客文章
• 微服务网络研讨会
• 微服务解决方案页面
• 主题：微服务

简介

从微服务兴起之初，NGINX便参与其中。NGINX轻量、高性能且灵活的特性非常适合微服务。

The NGINX Docker镜像是Docker Hub上下载量领先的应用镜像。目前，网上大多数微服务平台都提供演示，以某种形式部署NGINX并连接到欢迎页面。

我们认为，向微服务转型对客户取得成功至关重要。因此，NGINX启动了一项专项计划，旨在开发相关功能和实践，为Web应用开发和交付领域的这一重大变革提供支持。我们也认识到，微服务的实施方式多种多样，其中许多方式颇具创新性，并针对各个开发团队的具体需求量身定制。我们认为，需要建立相应的模型，帮助企业更轻松地开发和交付自己的微服务应用。

基于上述考虑，NGINX专业服务团队正在开发NGINX微服务参考架构（MRA）。这是一套可用于创建自有微服务应用的模型。

MRA由两部分组成：三个模型各自的详细说明，以及用于实现示例照片共享程序Ingenious的可下载代码。这三个模型之间的唯一区别在于用于为各模型配置NGINX Plus的配置代码。本系列博客文章将概述各个模型；详细说明、配置代码以及Ingenious示例程序的代码将于今年晚些时候发布。

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

• 为客户和业界提供可直接使用的蓝图，用于构建基于微服务的系统，从而加快开发速度并提升开发质量
• 创建一个用于测试NGINX和NGINX Plus新功能的平台，无论这些功能由内部还是外部开发，并随产品核心分发或作为动态模块
• 帮助我们了解合作伙伴的系统和组件，从而全面认识微服务生态系统

微服务参考架构也是面向NGINX客户的专业服务产品的重要组成部分。在MRA中，我们尽可能使用NGINX Open Source和NGINX Plus共有的功能，并在需要时使用NGINX Plus特有的功能。如下所述，越复杂的模型对NGINX Plus的依赖越强。我们预计，许多MRA用户都能从NGINX专业服务和技术支持中受益；订阅NGINX Plus即可获得这些支持。

微服务参考架构概述

我们正在构建符合十二要素应用原则的参考架构。这些服务采用轻量级、临时性和无状态设计。

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

迁移到微服务时，应用设计和架构的一项重大变化是，应用的各个功能组件改为通过网络进行通信。在单体应用中，应用组件在内存中通信；而在微服务应用中，这种通信通过网络进行，因此网络设计和实施变得至关重要。

为体现这一点，MRA采用了3种不同的网络模型，均使用NGINX或NGINX Plus。这些模型从相对简单到功能丰富且更为复杂，具体如下：

• 代理模型：一种简单的网络模型，适合将NGINX Plus用作微服务应用的控制器或API网关。此模型基于Docker Cloud构建。
• 路由器网状模型：一种更稳健的网络方案，在每台主机上部署负载均衡器，并管理系统之间的连接。此模型类似于Deis 1.0。
• Fabric 模型，作为MRA的核心亮点，Fabric 模型在每个容器中部署NGINX Plus，处理所有入站和出站流量。该模型适用于高负载系统，并支持各层级的SSL/TLS；NGINX Plus可为所有微服务降低延迟，并提供持久SSL/TLS连接、服务发现和断路器模式。

我们希望这些模型能成为您实施微服务的起点，也欢迎您就如何改进MRA提出反馈。（可以先在下方的评论区留言。）

下面简要介绍每种模型。建议先阅读所有说明，初步了解如何充分利用其中一种或多种模型。后续博客文章将逐一详细介绍这些模型，每篇介绍一种。

代理模型简介

代理模型是一种相对简单的网络模型。它非常适合作为初始微服务应用的起点，也可作为将转换复杂程度适中的单体旧版应用时采用的目标模型。

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

如果需要服务间通信（大多数具有一定复杂度的应用都需要），服务注册表会在集群内提供相应机制。（有关服务间通信机制的详细列表，请参阅这篇博客文章。）Docker Cloud默认采用这种方法；如需连接到其他服务，服务会查询DNS并获取用于发送请求的IP地址。

通常，代理模型适用于简单到中等复杂度的应用。它并非负载均衡的高效方法或模型，尤其是在大规模环境中；如果负载均衡需求较高，请使用下文介绍的模型之一。（“规模”既可以指微服务数量庞大，也可以指流量较高。）

编者注：如需深入了解此模型，请参阅《MRA，第 2 部分：代理模型》。

升级到路由器网格模型

路由器网格模型的复杂度适中，既适合设计稳健的新应用，也适合改造结构更复杂、且不需要 Fabric 模型功能的单体式旧版应用。

Router Mesh Model采用比Proxy Model更稳健的网络连接方式，在每台主机上运行负载均衡器，并主动管理微服务之间的连接。Router Mesh Model的主要优势是能够在服务之间实现更高效、更稳健的负载均衡。如果使用NGINX Plus，可以实施主动健康检查，以监控各个服务实例，并在实例下线时平稳限制流量。

Deis Workflow采用类似于路由器网格模型的方法，在服务之间路由流量，并在每台主机的容器中运行NGINX实例。启动新的应用实例时，会有一个进程从etcd服务注册表中提取服务信息，并将其加载到NGINX中。NGINX Plus也可以采用此模式，使用多个location及其关联的upstream。

编者注：如需深入了解此模型，请参阅《MRA，第 3 部分：路由器网格模型》。

最后，Fabric 模型（可选 SSL/TLS）

NGINX对Fabric 模型尤为期待。它让微服务的一些重要愿景成为现实，包括高性能、灵活的负载均衡，以及深入到各个微服务的全面SSL/TLS支持。Fabric 模型适用于安全应用，并可扩展以支持超大型应用。

在Fabric Model中，NGINX Plus部署在每个容器内，代理进出容器的所有HTTP流量。应用通过localhost地址建立所有服务连接，并依靠NGINX Plus执行服务发现、负载均衡和运行状况检查。

在我们的配置中，NGINX Plus会查询ZooKeeper，获取应用需要连接的服务的所有实例。例如，将DNS频率设置valid设为1秒后，NGINX Plus会每秒扫描ZooKeeper以检查实例变化，并相应地路由流量。

借助NGINX Plus强大的HTTP处理能力，我们可以使用长连接来维持与微服务的有状态连接，从而降低延迟并提升性能。使用SSL/TLS保护微服务之间的流量时，此功能尤其有价值。

最后，我们使用NGINX Plus的主动健康检查来管理发往健康实例的流量，实际上无需额外成本即可内置断路器模式。

编者注：如需深入了解此模型，请参阅《MRA，第4部分：Fabric模型》。

一款巧妙展示MRA的应用

MRA包含一个用于演示的示例应用，即Ingenious照片共享应用。Ingenious采用三种模型分别实现：Proxy、Router Mesh和Fabric。Ingenious演示应用将于今年晚些时候向公众发布。

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

• 用户和开发者都能轻松理解它的用途。
• 需要管理多个数据维度。
• 可以轻松地在应用中融入美观的设计。
• 它提供非对称计算需求，即高强度与低强度处理相结合，从而能够针对不同类型的功能，对故障转移、扩缩容和监控功能进行贴近实际的测试。

结论

NGINX微服务参考架构是一项令人振奋的进展，不仅对我们如此，对迄今已了解该架构的客户和合作伙伴也是如此。未来几个月，我们将发布一系列博客文章，详细介绍该架构，并计划于今年晚些时候正式推出。我们还将在nginx.conf 2016上详细探讨该架构。会议将于9月7日至9日在得克萨斯州奥斯汀举行。欢迎提供反馈，期待与您见面。

与此同时，不妨亲自试用采用NGINX Plus的MRA。立即开始30天免费试用，或联系我们，探讨您的用例。

关于作者

Chris Stetson

Chris Stetson 的更多博客文章