原文： Introducing the Microservices Reference Architecture from NGINX

译者：杰微刊兼职翻译张迪

微服务参考架构将在今年下半年完成，并于2016年9月7日至9日在美国德州奥斯汀举行的nginx.conf 2016上详细讨论。现在提前购票可以享受优惠。

作者注：这篇文章是一系列文章中的第一篇，随着新帖子出现，我们将扩展列表：

1、介绍NGINX 微服务参考架构（此篇文章）；

2、NGINX微服务参考架构第二部分-代理模型；

3、NGINX 微服务参考架构第三部-织物模型。

接下来的文章将介绍三种模型中包含的微服务参考体系结构以及相关的话题。

我为微服务应用程序web前端写了一篇单独的文章。提及微服务应用程序设计，克里斯·理查森有一套非常有用和受欢迎的丛书，再加上许多其他的关于微服务的博客文章和微服务的在线研讨会。

一、简介

NGINX从一开始就参与了微服务运动。NGINX的轻量级、高性能、灵活本质很适合微服务。

NGINX的Docker形象是Docker Hub上的一个下载应用程序图像，如今，大家在Web上发现的微服务平台都包含一个demo，其中都以某种形式部署NGINX并连接到欢迎页面。

因为我们相信，对于客户的成功来说，向微服务的过渡是至关重要的，我们在NGINX上发起了一个专门的项目，开发产品特点和实践来支持web应用程序开发和交付的这一巨变。我们也认识到，可以用许多不同的方法来实现微服务，其中有许多新颖的和独特的方式，满足个人开发团队的需求。我们认为有必要让模型更简化，以方便各个公司开发并交付他们自己的基于微服务的应用程序。

记住这一切，在NGINX专业服务上，我们正在发展NGINX微服务参考架构(MRA)——这是一组模型，您可以使用它们来创建自己的微服务应用程序。

微服务参考架构有两个部分：三种模型的详细描述，还有实现了我们示例照片分享计划的下载代码，很别出心裁。这三个模型之间唯一的区别是每个模型配置NGINXPlus的配置类型代号。这一系列的博客文章将提供每个模型的概览描述，详细描述、配置类型代号，一个巧妙的示例程序的代码将在今年晚些时候推出。

我们建立参考体系结构的目标有三个层面：

1、为客户和业界提供现成的构建基于微服务系统的蓝图，加速和提高发展；

2、为NGINX和NGINX Plus的新功能创建一个测试平台，不管内部或外部，在产品核心或分布式动态模块；

3、帮助我们了解合作伙伴系统和组件，以至于我们在微服务生态系统方面可以得到一个全面的视角。

对于NGINX的客户来说，微服务参考体系结构也是专业服务产品的一个重要部分。在可能的情况下，我们在微服务参考架构中使用的特性与开源NGINX软件和NGINX Plus相同，必要时还要使用NGINX Plus 的特定功能。如下所述，在更复杂的模型中，NGINX Plus的依赖性更强。我们估计，许多微服务参考体系结构用户将受益于NGINX专业服务和技术支持，并附带了一个NGINX Plus订阅。

二、微服务参考体系结构的概述

我们正在构建的参考体系结构要符合Twelve Factor?App的原则。服务被设计为轻量级的、短暂的、无状态的。

微服务参考体系结构使用工业标准组件，如Docker containers，这是一种广泛的语言——Java、PHP、Python、NodeJS / JavaScript，Ruby–和NGINX-based网络。

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

为反映这一点，微服务参考体系结构已经使用三个不同的网络模型，所有这些模型都使用了NGINX或NGINX Plus。他们的变化范围从相对简单到功能丰富且更复杂：

1、代理模型——一个简单的网络模型，适用于实现NGINX Plus控制器或微服务应用程序的API网关。这个模型是建立在Docker Cloud上。

2、路由器网络网格模型——一种更有力的网络方法，在每台主机上都安有负载均衡器并管理系统之间连接。该模型的体系结构与Deis 1.0相似。

3、织物模型——微服务参考体系结构王冠上的一颗明珠，作为正向和反向代理，织物模型的每个container上都有NGINX Plus的特性。它适用于高负载系统，支持各级SSL / TLS，因为NGINX Plus 提供减少延迟、持久的SSL / TLS连接、服务发现和在所有微服务上都有的断路器模式。

我们的目的是，为了实现微服务，使用这些模型作为自己的出发点，我们欢迎任何关于如何提高微服务参考体系结构的反馈。

简要描述每个模型之前，我们建议你阅读所有的描述，开始了解如何最好的使用一个或多个模型。未来的博客文章将描述每个模型的细节。

一）代理模型概述

代理模型是一个相对简单的网络模型。对于微服务初始程序来说，它是一个很好的起点，或者在转换一个适度复杂并有庞大遗留的应用程序时起到目标模型的作用。

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

如果连结装置间的沟通是必须的，并且其沟通要通过应用程序，大多数这种应用程序都具有一定程度的复杂性——服务注册表提供了集群内的机制。(参见这篇博客中连结装置间的通信机制的详细列表)。Docker云在默认的情况下使用这种方法；连接到另一个服务，服务查询DNS并获得一个IP地址，然后发送一个请求。

一般来说，对于简约但适度复杂的应用程序来说，代理模型是可行的。这不是最有效的方法/负载均衡模型，特别是在规模的大小上；如果你有很大的负载平衡需求，可以使用下面描述的模型。(“规模”可以指大量微服务以及高流量)。

二）加强路由器网格模型

路由器网格模型是中等复杂的模型，能够很好地匹配强大的新应用程序设计，也能降低复杂性，整体的遗留应用程序不需要织物模型的能力。

与代理模型相比，路由器网格模型需要一个更加强大的网络方法，因为路由器网格模型需要运行每个主机上的一个负载均衡器，并积极管理微服务之间的连接。路由器网格模型主要的好处是更高效和服务之间的强大的负载均衡。如果你使用NGINX Plus，当他们拍摄下来后您可以实现积极的健康检查，优雅地监控个人服务实例和节流流量。

通过NGINX的实例在每个主机container上的运行，Deis工作流程使用一个类似于路由器网格模型的服务之间通信方式。随着新应用程序的实例启动起来，一个进程会从etcd服务注册表提取服务信息，并将其加载到NGINX。NGINX Plus也可以在这种模式下工作，使用不同的位置和它们相关的上游。

三）最后——织物模型，可选的SSL / TLS

我们在NGINX最感兴趣的就属织物模型了。织物模型给生活带来了一些最令人兴奋的的微服务承诺，包括高性能、弹性负载平衡、并让SSL / TLS在个人微服务水平上无处不在。织物模型适用于安全的应用程序，并且可扩展到非常大的应用程序

在织物模型中，NGINXPlus被部署在每个容器中，成为所有进出容器的HTTP流量的正向和反向代理。为了所有服务连接，应用程序与本地主机的位置进行沟通，并依靠NGINX Plus来做服务发现、负载均衡和健康检查。

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

因为NGINX Plus中强大的HTTP处理，我们可以使用keepalives维护微服务连接状态，并减少延迟和提高性能。使用SSL / TLS确保微服务之间的通信是一个特别有价值的特性。

最后，我们使用NGINX Plus的积极健康检查管理通信，以至于使实例保持健康，从本质上讲，在circuit breaker pattern中构建是免费的。

三、一个巧妙的微服务参考体系结构示例程序

微服务参考体系结构包括一个简单的示例应用程序演示：一个巧妙的照片分享应用。巧妙的实现了三种模型——代理模型、路由器网模型和织物模型。这个巧妙的演示应用程序在今年晚些时候将向公众公布。

这个巧妙的办法的是一个简化版的图片存储和共享应用程序，像Flickr或Shutterfly。我们选择一个照片共享应用程序的原因如下：

1、用户和开发人员很容易理解它；

2、有多个维度数据需要管理；

3、在应用中，很容易融合漂亮的设计；

4、它提供了不对称计算的需求——高强度和低强度的混合处理，这实现了故障转移测试、缩放，并通过不同类型的功能监控特性。

总结

对于我们自己和我们的客户来说，NGINX 的微服务参考体系结构是一个令人兴奋的发明，到目前为止，我们也已经和合作伙伴实现共享。在接下来的几个月里，我们将发布一系列的博客文章来详细描述微服务参考体系结构，我们将在今年下半年让其成为可能。我们还将在nginx.conf 2016（2016年9月7 – 9日在美国德州奥斯汀）上进行详细的讨论。请给我们你的反馈，我们期待着见到你。

文章标签： Nginx 微服务 架构

关注微信公众号“架构说”，加入Q群微群，让架构师带你飞︿(￣︶￣)︿。