「微服务架构」基于Nginx的三种微服务参考架构

时间: 2019-09-15阅读: 97标签: 微服务

介绍

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

NGINX Docker映像是Docker Hub上排名第一的应用程序映像,您今天在Web上找到的大多数微服务平台都包含一个演示,它以某种形式部署NGINX并连接到欢迎页面。

因为我们认为转向微服务对于客户的成功至关重要,我们NGINX已经启动了一个专门的程序来开发支持Web应用程序开发和交付这种地震转变的功能和实践。我们还认识到,实现微服务有许多不同的方法,其中许多方法都是新颖的,并且特定于各个开发团队的需求。我们认为需要使用模型来使公司更容易开发和交付自己的基于微服务的应用程序。

考虑到这一切,NGINX专业服务部门正在开发NGINX微服务参考架构(MRA) - 一组可用于创建自己的微服务应用程序的模型。

MRA由两部分组成:三个模型中的每一个的详细描述,以及实现我们的示例照片共享程序的可下载代码,Ingenious。三种型号的唯一区别是用于为每种型号配置NGINX Plus的配置代码。这一系列博客文章将提供每个模型的概述说明; Ingenious示例程序的详细描述,配置代码和代码将在今年晚些时候推出。

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

  1. 为客户和行业提供随时可用的蓝图,用于构建基于微服务的系统,加速和改进开发
  2. 创建用于测试NGINX和NGINX Plus中新功能的平台,无论是内部开发还是外部开发,分布在产品核心中或作为动态模块
  3. 为了帮助我们了解合作伙伴系统和组件,我们可以从整体上了解微服务生态系统

微服务参考架构也是NGINX客户专业服务产品的重要组成部分。在MRA中,我们尽可能使用NGINX开源和NGINX Plus共有的功能,并在需要时使用NGINX Plus特有的功能。 NGINX Plus依赖关系在更复杂的模型中更强,如下所述。我们预计,MRA的许多用户将受益于NGINX专业服务的访问以及NGINX Plus订阅的技术支持。


微服务参考架构概述

我们正在构建参考架构以符合Twelve-Factor App的原则。这些服务设计为轻量级,短暂的和无状态的。

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

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

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

  • 代理模型 (Proxy Model)- 一种简单的网络模型,适用于实现NGINX Plus作为微服务应用程序的控制器或API网关。该模型建立在Docker Cloud之上。
  • 路由器网格模型(Router Mesh Model ) - 一种更强大的网络方法,每台主机上都有一个负载均衡器,可以管理系统之间的连接。该模型类似于Deis 1.0的体系结构。
  • 织品模型 (Fabric Model) - MRA的皇冠上的明珠,面料模型在每个容器中都有NGINX Plus,处理所有入口和出口交通。它适用于高负载系统,并支持所有级别的SSL / TLS,NGINX Plus提供减少的延迟,持久的SSL / TLS连接,服务发现以及所有微服务中的断路器模式。

我们的目的是您使用这些模型作为您自己的微服务实现的起点,我们欢迎您提供有关如何改进MRA的反馈。 (您可以从添加到下面的评论开始。)

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


代理模型简介

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

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


如果需要进行服务间通信 - 并且大多数应用程序都处于任何复杂程度 - 服务注册表提供集群内的机制。 (有关服务间通信机制的详细列表,请参阅此博客文章。)Docker Cloud默认使用此方法;为了连接到另一个服务,服务查询DNS并获取IP地址以发送请求。

通常,代理模型适用于简单到中等复杂的应用程序。它不是负载平衡最有效的方法/模型,特别是在规模上;如果您有严重的负载平衡要求,请使用下面描述的模型之一。 (“Scale”可以指大量的微服务以及高流量。)

编辑器 - 有关此模型的深入探索,请参阅MRA,第2部分 - 代理模型。


路由器网格模型

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

通过在每个主机上运行负载均衡器并主动管理微服务之间的连接,路由器网状网模型采用比代理模型更强大的网络方法。路由器网格模型的主要优点是服务之间的更高效和稳健的负载平衡。如果使用NGINX Plus,则可以实施活动运行状况检查以监视各个服务实例,并在关闭时优雅地限制流量。


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

编辑器 - 有关此模型的深入探索,请参阅MRA,第3部分 - 路由器网格模型(https://www.nginx.com/blog/microservices-reference-architecture-nginx-router-mesh-model/)。


最后 - Fabric模型,带有可选的SSL / TLS

我们NGINX对Fabric模型最为兴奋。它带来了一些最令人兴奋的微服务承诺,包括高性能,负载平衡的灵活性,以及​​无处不在的SSL / TLS,直到单个微服务的水平。 Fabric模型适用于安全应用程序,可扩展到非常大的应用程序。

在Fabric模型中,NGINX Plus部署在每个容器中,并成为进出容器的所有HTTP流量的代理。应用程序与本地(localhost)主机位置通信以获取所有服务连接,并依赖NGINX Plus进行服务发现,负载平衡和运行状况检查。


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

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

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

编辑 - 有关此模型的深入探索,请参阅MRA,第4部分 - 结构模型(https://www.nginx.com/blog/microservices-reference-architecture-nginx-fabric-model/)。


MRA的巧妙演示应用程序

MRA包括一个示例应用程序作为演示:Ingenious照片共享应用程序。 Ingenious在三种模型中实现 - 代理,路由器网格和结构。 Ingenious演示应用程序将于今年晚些时候向公众发布。

Ingenious是照片存储和共享应用程序的简化版本,la Flickr或Shutterfly。我们选择照片共享应用程序的原因有以下几点:

  1. 用户和开发人员都很容易掌握它的功能。
  2. 需要管理多个数据维度。
  3. 在应用程序中很容易融入漂亮的设计。
  4. 它提供了非对称计算要求 - 高强度和低强度处理的混合 - 可以实现跨不同功能的故障转移,扩展和监视功能的真实测试。


结论

NGINX微服务参考架构对我们来说是一个令人兴奋的发展,对于我们迄今为止共享的客户和合作伙伴而言。 在接下来的几个月里,我们将发布一系列博客文章,详细描述它,我们将在今年晚些时候推出。 我们还将在9月7日至9日在德克萨斯州奥斯汀举行的nginx.conf 2016上详细讨论。 请给我们您的反馈意见,我们期待着与您相见。

原文:https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/


吐血推荐

1.阿里云: 本站目前使用的是阿里云主机,安全/可靠/稳定。点击领取2000元代金券、了解最新阿里云产品的各种优惠活动点击进入...

2.腾讯云: 提供云服务器、云数据库、云存储、视频与CDN、域名等服务。腾讯云各类产品的最新活动,优惠券领取点击进入...

3.站长广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入...

链接: http://www.fly63.com/article/detial/5946

为什么会产生微服务架构?

Web应用架构受系统用户量、开发人员组织方式影响严重。过去二十年互联网迅速发展,Web架构也从单体式演进出微服务,背后还有比如 Martin Fowler 提出的理论支撑。虽然每个人都听说过微服务,但是很多人并不太清楚为什么要这么做

PHP微服务集群搭建

近些年微服务架构大行其道,趁着最近有时间,来捣鼓捣鼓微服务是怎么一回事。微服务的概念由 Martin Fowler 于2014年3月提出:微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间相互协调

采用微服务架构的六个考量因素

新兴技术的下一波浪潮正向我们涌来,人工智能、可穿戴设备、物联网及更多技术变得普及开来。许多组织现面临着管理这些整体式应用程序这个难题。当下,速度和灵活性必不可少

微服务架构如何影响软件开发文化?

微服务,并不仅仅是一种代码构造方式。微服务概念一出现就引发了热烈讨论,很多文章都喜欢将其与整体式架构比较,乃至来自大型企业的用例等。然而,在说起微服务时,开发人员关注的往往是这场革命的技术意义

最终,我们放弃了微服务

微服务被认为是一种理想的架构模式,因此,Steven Lemon 所在公司的领导层决定从单体架构向微服务架构迁移,这让整个开发团队在随后的的日子里苦不堪言,七大现实问题摆在面前无法解决,微服务架构的好处也没有享受到

一个知名网站的微服务架构最佳实现

在Medium,我们的技术堆栈始于2012年的单体Node.js应用程序。我们已经构建了几个卫星服务,但我们还没有制定一个系统地采用微服务架构的策略。 随着系统变得越来越复杂并且团队不断发展

微服务架构之「 调用链监控 」

「 调用链监控 」是在微服务兴起后才有的一种新流行的监控模式。因为在我们传统单体应用的项目中,不存在服务链/调用链的概念,所以也就根本没有调用链监控的需求了

微服务架构下的监控需要注意哪些方面?

微服务本身并没有一个严格的定义,不过从很多人的反馈来看,大家都达成了这样一个共识:微服务是一种简单的应用,大概有10到100行代码。我知道使用代码行数来比较实现其实很不靠谱,因此你能理解这个意思就行,不必过分拘泥于细节

微服务化的不同阶段 Kubernetes 的不同玩法

作为容器集群管理技术竞争的大赢家,Kubernetes已经和微服务紧密联系,采用Kubernetes的企业往往都开始了微服务架构的探索。然而不同企业不同阶段的微服务实践面临的问题千差万别,注定要在技术路线上产生分叉

fly63.com版权所有,内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权,请与小编联系!情况属实本人将予以删除!

广告赞助文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全