「微服务架构」基于Nginx的三种微服务参考架构
|
副标题[/!--empirenews.page--]
Introducing the NGINX Microservices Reference Architecture (this post)
另请查看有关微服务的其他NGINX资源：
介绍 NGINX从一开始就参与了微服务运动。 NGINX的轻巧，高性能和灵活性非常适合微服务。 NGINX Docker映像是Docker Hub上排名第一的应用程序映像，您今天在Web上找到的大多数微服务平台都包含一个演示，它以某种形式部署NGINX并连接到欢迎页面。 因为我们认为转向微服务对于客户的成功至关重要，我们NGINX已经启动了一个专门的程序来开发支持Web应用程序开发和交付这种地震转变的功能和实践。我们还认识到，实现微服务有许多不同的方法，其中许多方法都是新颖的，并且特定于各个开发团队的需求。我们认为需要使用模型来使公司更容易开发和交付自己的基于微服务的应用程序。 考虑到这一切，NGINX专业服务部门正在开发NGINX微服务参考架构(MRA) - 一组可用于创建自己的微服务应用程序的模型。 MRA由两部分组成：三个模型中的每一个的详细描述，以及实现我们的示例照片共享程序的可下载代码，Ingenious。三种型号的唯一区别是用于为每种型号配置NGINX Plus的配置代码。这一系列博客文章将提供每个模型的概述说明; Ingenious示例程序的详细描述，配置代码和代码将在今年晚些时候推出。 我们构建此参考架构的目标有三个：
微服务参考架构也是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。它们的范围从相对简单到功能丰富且更复杂：
我们的目的是您使用这些模型作为您自己的微服务实现的起点，我们欢迎您提供有关如何改进MRA的反馈。 (您可以从添加到下面的评论开始。) 以下是每种模型的简要说明;我们建议您阅读所有描述，以便开始了解如何最好地使用一个或多个模型。未来的博客文章将详细描述每个模型，每个博客文章一个。 代理模型简介 代理模型是一种相对简单的网络模型。它是初始微服务应用程序的出色起点，或者是转换中等复杂的单片遗留应用程序的目标模型。 在代理模型中，NGINX或NGINX Plus充当入口控制器，将请求路由到微服务。当创建新服务时，NGINX Plus可以使用动态DNS进行服务发现。当使用NGINX作为API网关时，代理模型也适合用作模板。  如果需要进行服务间通信 - 并且大多数应用程序都处于任何复杂程度 - 服务注册表提供集群内的机制。 (有关服务间通信机制的详细列表，请参阅此博客文章。)Docker Cloud默认使用此方法;为了连接到另一个服务，服务查询DNS并获取IP地址以发送请求。 通常，代理模型适用于简单到中等复杂的应用程序。它不是负载平衡最有效的方法/模型，特别是在规模上;如果您有严重的负载平衡要求，请使用下面描述的模型之一。 (“Scale”可以指大量的微服务以及高流量。) 编辑器 - 有关此模型的深入探索，请参阅MRA，第2部分 - 代理模型。 路由器网格模型 路由器网格模型中等复杂，非常适合强大的新应用程序设计，也适用于转换不需要Fabric模型功能的更复杂的单片遗留应用程序。 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
