UDN-企业互联网技术人气社区

板块导航

浏览  : 1019
回复  : 0

[Docker资讯] 介绍NGINX微服务参考架构

[复制链接]
哥屋恩的头像 楼主
发表于 2016-5-17 19:33:13 | 显示全部楼层 |阅读模式

  该微服务参考架构会在今年晚些时候提供,并且将在九月7-9号在德克萨斯州奥斯汀举行的nginx.conf 2016会议讨论详细的细节。现在提前购票有折扣。

  作者注——本博客文章是一个系列文章的第一篇,我们后面将会扩展此篇文章编写新的文章。

  本文将介绍NGINX微服务参考架构,该文章包括微服务参考架构所涉及的三种模型以及相关的话题。我以前已经写了一篇关于微服务应用的web前端文章,我们也有一个非常有用而且受欢迎的系列文章,这些文章是由克里斯?理查森编写的关于微服务应用的设计,除此之外还有许多其他微服务相关的文章和微服务网上研讨会。

  介绍

  NGINX打一开始就一直积极参与微服务的活动,NGINX的轻量级、高性能和灵活等特性非常适合微服务。

  NGINX Docker镜像在Docker Hub上是下载量排名第一的应用镜像,今天你在网络上找到的大多数微服务平台都会在欢迎页面中使用NGINX的某些形式的部署作为演示案例。

  因为我们相信转移到微服务是帮助我们客户取得成功的关键,我们在NGINX已经推出了专门的程序用于支持web应用程序开发和交付。我们还意识到,有许多不同的方法可用于实现微服务。我们认为有必要使模型更加容易为企业开发和交互他们自己的基于微服务的应用程序。

  综合上面所说的,我们这里的NGINX专业服务团队正在开发NGINX微服务参考架构(MRA)——你可以用它来创建你自己的微服务应用的一组模型。

  我们构建这个参考架构的目标主要有三个方面:

  1、为用户和行业提供现成的可以直接使用的基于微服务系统的构建蓝图,快速高效的开发方式。

  2、创建一个平台用于NGINX及NGINX Plus新功能的测试,无论是内部还是将产品核心模块分散成外部,或者是动态模块。

  3、帮助我们理解合作伙伴的系统和组件,以至于我们能从微服务生态中得到一个整体的视角。

  该微服务参考架构也是提供给NGINX客户专业服务中的重要部分,在MRA中,我们尽可能使用开源软件NGINX和NGINX Plus的常用功能和NGINX Plus-specific需要的功能。NGINX Plus的依赖更加强而且模型更加复杂,下面会对此进行描述。通过订阅我们的NGINX Plus,我们预计MRA的很多用户将通过NGINX专业服务和技术支持中受益。

  微服务参考架构的概述

  我们正在创建微服务参考架构使之符合十二要素应用的原则,这些服务被设计成轻量级的、短暂的和无状态的。

  该MRA采用业界标准组件,例如Docker容器;许多各种不同的语言——Java、PHP、Python、NodeJS/JavaScript、Ruby;以及基于NGINX的网络。

  从整体架构转到微服务架构时,应用设计和架构方面其中最大的改变就是要在不同功能组件之间使用网络去通信。在一个单一整体的应用中,组件之间在内存中进行通信。而在微服务架构的应用中,组件之间则需要通过网络通信。所以网络设计和实现变得极为重要。

  为了反映这点,MRA已经使用了三种不同的网络模式去实现,所有这些都使用了开源软件NGINX或NGINX Plus,他们的范围覆盖从相对简单到功能丰富且更加复杂。

  1、代理模式——它是一种简单的网络模型,它适用于在微服务应用中用NGINX Plus作为控制器和API gateway的实现,此模型建立在Docker Cloud之上。

  2、 路由器网络模型——一个更强大的网络方式,它可能在主机之间做负载均衡器,并且管理着系统与系统之间的连接,这种模型与DEIS1.0体系结构相似。

  3、Fabric 模型——它是MRA的皇冠上的明珠,Fabric模型是NGINX Plus在每个容器中的特色。充当一个正向和反向代理的角色。它在高负载系统中工作的很出色,并且在支持SSL/TLS协议,使用NGINX Plus能提供更低的延迟,SSL/TLS长连接,服务发现,在所有微服务中的断路器模式。

  我们的目的是,你们可以使用这些模型作为你们自己的微服务实现的开始,同时我们欢迎您的关于如何改良MRA的反馈,你可以通过在下面添加评论开始。

  每种模型的简要说明如下,我们建议您阅读所有的说明,以便获取如何才能更好使用这些模型的心得。未来的博客文章将介绍每个模型的细节,一篇文章介绍一种模型。

  代理模式简要说明

  代理模型是一种相对简单的网络模型,用它作为一个初始的微服务应用的网络模型是一个很好的起点,或者用它作为转换一个中等复杂单一整体应用的目标模型。

  在代理模式中,NGINX或NGINX Plus作为一个入口控制器,路由分发请求到不同的微服务上。NGINX Plus可以使用动态DNS用于当一个新服务创建时的服务发现。当使用UNINX作为一个API的gateway时,代理模式同样适合作为一个模板使用。

4.png


  如果服务之间需要互相通信,当然基本大多数应用都会需要各种复杂程度的通信,服务注册中心通过集群提供了这些机制。(见本博客文章查看服务之间互相通信的细节。)Docker Cloud使用这个作为默认的解决方法,用于连接另外一个服务,服务通过查询DNS获取到IP地址并往它发送请求。

  一般情况下,代理模式对于简单到中等复杂的应用都是可行的,对于负载均衡它并不是最有效的方法和模式,特别是在规模方面有很大的限制。如果你需要强大的负载均衡能力请使用以下描述的模式。(适用微服务规模和流量都达到很大的场景)

  逐步转向路由器网络模式

  路由器网络模式相对比较复杂,它适合用于创建一个强大健壮的应用,同时它也用于转化不需要Fabric模式能力的那些更加复杂的单一整体应用。

  路由器网络模式比起代理模式需要一个更加强大的网络通信方法,通过在每个主机上运行一个负载均衡器主动管理微服务之间的所有连接。路由器网络模式主要的优点是更加有效和强大的服务负载均衡能力。如果你使用NGINX Plus,你可以通过心跳健康检查去监控某个服务实例并且当此服务出现故障时能优雅地熔断。

3.png


  Deis工作流使用了类似路由器网络模式的方法在服务之间路由流量,在每个主机上的容器上运行若干NGINX实例,进程从etcd服务注册中获取服务信息并且加载到NGINX中,NGINX Plus也可以在此模式下工作。

  最后——支持SSL/TLS的Fabric模式

  在NGINX中我们感到最兴奋的就是Fabric模式,它带来了最令人兴奋的服务保证,包括高性能,负载均衡的灵活性,并且支持单个微服务不同层次的SSL/TLS协议,Fabric模式适合安全性很高的应用和规模很大的应用。

  在Fabric模式中,NGINX Plus被部署到每个容器中,并成为容器进入或出来的HTTP流量的正向或反向代理,应用与本地的所有服务连接通信,并且依赖NGINX Plus做服务发现、负载均衡和监控检查。

2.png


  Deis工作流使用了类似路由器网络模式的方法在服务之间路由流量,在每个主机上的容器上运行若干NGINX实例,进程从etcd服务注册中获取服务信息并且加载到NGINX中,NGINX Plus也可以在此模式下工作。

  最后——支持SSL/TLS的Fabric模式

  在NGINX中我们感到最兴奋的就是Fabric模式,它带来了最令人兴奋的服务保证,包括高性能,负载均衡的灵活性,并且支持单个微服务不同层次的SSL/TLS协议,Fabric模式适合安全性很高的应用和规模很大的应用。

  在Fabric模式中,NGINX Plus被部署到每个容器中,并成为容器进入或出来的HTTP流量的正向或反向代理,应用与本地的所有服务连接通信,并且依赖NGINX Plus做服务发现、负载均衡和监控检查。

1.png


  结论

  NGINX微服务参考架构对于我们来说是一个令人兴奋的开发,并且我们为客户和合作伙伴做了最新的分享。在接下来的几个月里,我们将发布一系列描述微服务参考架构细节的文章,并且我们将在今年的晚些时候使微服务参考架构可用。我们同样也会在九月7-9号德克萨斯州奥斯汀的nginx.conf2016会议上进行讨论。请将你们的反馈发给我们,我们期待您的光临。

原文作者:佚名 来源:开发者头条
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部