为什么使用微服务网关（微服务为什么要用网关）

本篇文章给大家谈谈为什么使用微服务网关，以及微服务为什么要用网关对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享为什么使用微服务网关的知识，其中也会对微服务为什么要用网关进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Spring Cloud
• 2、微服务有什么作用？
• 3、微服务网关层
• 4、spring cloud gateway的作用（面试）
• 5、微服务之网关聚合模式
• 6、【分享】什么是API网关？大公司为什么都有API网关？

Spring Cloud

本文中我们主要介绍微服务开发框架——Spring Cloud。尽管Spring Cloud带有"Cloud"的字样，但它并不是云计算解决方案，而是Spring Boot的基础上构建的，用于快速构建分布式系统的通用模式的工具集。

Spring Cloud有以下特点:

由上图可知，Spring Cloud是以 英文单词+SR+数字 的形式命名版本号的。那么英文单词和SR分别表示什么呢？
因为Spring Cloud是一个综合项目，它包含很多子项目。由于子项目也维护着自己的版本号，Spring Cloud采用了这种命名方式，从而避免与子项目的版本混淆。其中英文单词如Edware是伦敦某地铁站名，它们按照字母顺序发行，可以将其理解为主版本的演进。SR表示"Service Release"，一般表示Bug修复。

版本兼容性如下

版本内容

可参考官方文档： https://spring.io/projects/spring-cloud#overview

我的上一篇博客(微服务理论篇)中谈到，对单体应用进行服务拆分得到各个微服务，而这些服务又是相互独立的，那么我们如何知道各个微服务的健康状态、如何知道某个微服务的存在呢？由此、一个拥有服务发现的框架显得尤为重要。这也就是Eureka诞生的原因。

综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

通过使用Eureka已经实现了微服务的注册与发现。启动各个微服务时，Eureka Client会把自己的网络信息注册到Eureka Server上。似乎一切更美好了一些。然而，这样的架构依然有一些问题，如负载均衡。一般来说，各个微服务都会部署多个实例。那么服务消费者要如何将请求分摊到多个服务提供实例上呢？

如果服务提供者相应非常慢，那么消费者对提供者的请求就会被强制等待，知道提供者响应或超时。在高负载场景下，如果不作任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统崩溃。
微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。而这种由于"基础服务故障"导致"级联故障"的现象称为雪崩效应。

如图所示，A最为服务提供者（基础服务），B为A的服务消费者，C和D是B的服务消费者。当A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。
那么Hystrix是如何容错的呢？

以下对该图做个简单讲解：

Zuul作为微服务架构中的微服务网关。微服务架构经过前几个组件的组合，已经有了基本的雏形了，那么我们为什么还要使用微服务网关呢？我们可以想象，一般情况下我们一个业务并不是只调用一个接口就可以完成一个业务需求。
如果让客户端直接与各个微服务通信，会有以下问题：

如图，微服务网关封装了应用程序的内部结构，客户端只须跟网关交互，而无须直接调用特定微服务接口。同时，还有以下优点：

为什么要同一管理微服务配置？
对于传统的单体应用，常常使用配置文件管理所有配置。例如一个Spring Boot 项目开发的单体应用，可以将配置内容放到application.yml文件中。如果需要切换环境，可以设置多个Profile,并在启用应用时指定spring.profile.active={profile}。
而在微服务架构中，微服务的配置管理一般有以下需求：

微服务有什么作用？

维基上对微服务的定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
微服务的最重要的单一特征可能是，由于服务较小且可独立部署，因此不再需要繁琐的行动才能更改应用程序中的一行文字。
在微服务模型中，组件是独立部署的，并通过REST，事件流和消息代理的某种组合进行通信-因此，可以针对该服务优化每个单独服务的堆栈。技术一直在变化，由多个较小的服务组成的应用程序随着更理想的技术的发展而变得更容易且成本更低。
使用微服务，可以单独部署单个服务，但是也可以单独扩展它们。由此带来的好处是显而易见的：如果正确完成，微服务比单片应用程序所需的基础结构要少，因为微服务仅支持对需要它的组件进行精确缩放，而对于单片应用程序则不需要整个应用程序。
比如像HC服务网格是基于Istio及容器技术的微服务治理平台，以无侵入方式为多语言、不同部署形态的异构应用提供服务治理、服务监控和安全控制等微服务管理能力。能够将服务通信、观测与安全能力下沉到基础设施层，降低分布式应用开发复杂度，为应用运维减负，推动企业应用整体向服务治理平台迁移，提升IT系统的整体承载能力、高可用能力。

微服务网关层

API网关是所有客户端的统一入口。路由服务可以被用于很多目的，例如日志、限流、认证，从而做到应用无感知。API网关对于任意一种处理请求有两种方式处理。一部分请求只要简单路由到相应的服务；还有一些请求需要拆分到多个服务。API Gateway是实现微服务重要的组件之一，常用的网关Zuul, Nginx, Spring Cloud, Linkerd，Envoy，UnderTow。

为了评估API网关各自的性能，我们使用Apache的ab作为压测工具。（另外还可以用Gatling做性能测试）

测试结果和心得如下：

spring cloud gateway的作用（面试）

网关是整个微服务API请求的入口，负责拦截所有请求，分发到服务上去。可以实现日志拦截、权限控制、解决跨域问题、限流、熔断、负载均衡，隐藏服务端的ip，黑名单与白名单拦截、授权等，常用的网关有zuul(netflix的，但是已经停更了)和spring cloud gateway (springcloudalibaba)。这里主要讲springcloud gateway，springcloud gateway是一个全新的项目,其基于spring5.0 以及springboot2.0和项目Reactor等技术开发的网关,其主要的目的是为微服务架构提供一种简单有效的API路由管理方式.

过滤器：对单个服务器的请求进行拦截控制

网关：对所有的服务器的请求进行拦截控制

zuul：是Netflix的，是基于servlet实现的，阻塞式的api，不支持长连接。

gateway：是springcloud自己研制的微服务网关，是基于Spring5构建，能够实现响应式非阻塞式的Api，支持长连接

相同点：都是可以实现对api接口的拦截，负载均衡、反向代理、请求过滤等，可以实现和网关一样的效果。

不同点：Nginx采用C语言编写，Gateway属于Java语言编写的， 能够更好让我们使用java语言来实现对请求的处理。

Nginx 属于服务器端负载均衡器。

Gateway 属于本地负载均衡器。 

路由 : 网关的基本模块，有ID，目标URI，一组断言和一组过滤器组成

断言：就是访问该旅游的访问规则，可以用来匹配来自http请求的任何内容，例如headers或者参数

过滤器：这个就是我们平时说的过滤器，用来过滤一些请求的，gateway有自己默认的过滤器，具体请参考官网，我们也可以自定义过滤器，但是要实现两个接口，ordered和globalfilter
a. 客户端发送请求，会到达网关的DispatcherHandler处理，匹配到RoutePredicateHandlerMapping。

b. 根据RoutePredicateHandlerMapping匹配到具体的路由策略。

c. FilteringWebHandler获取的路由的GatewayFilter数组，创建 GatewayFilterChain 处理过滤请求

d. 执行我们的代理业务逻辑访问。

微服务之网关聚合模式

使用网关可以将多个单独为什么使用微服务网关的请求聚合到一个请求中。当客户端必须对多个不同的后端系统进行多次调用操作时为什么使用微服务网关，此模式很有用。

有时候执行单个任务时，客户端可能必须对不同的各个后端服务进行多次调用。因为他们依赖于多个服务，那么客户端必须调用不同的服务接口以完成这次请求，这样就会导致请求过多而浪费很多的资源。当任何新功能或服务添加到应用程序时，从而会进一步增加资源需求和网络调用。客户端和后端之间的这种混乱调用可能会对应用程序的性能和规模产生负面影响。微服务架构使这个问题变得更加普遍，因为围绕许多小型服务构建的应用程序自然会有更多的跨服务调用。

在下图中，客户端向每个服务发送请求（1,2,3）。每个服务处理请求并将响应发送回应用程序（4,5,6）。通常具有高延迟的蜂窝网络上，以这种方式使用单独的请求是低效的并且可能导致连接中断或请求不完整。虽然每个请求可以并行完成，但应用程序必须为每个请求发送，等待和处理数据，所有这些都在不同的连接上，从而增加了失败的可能性。

使用网关来减少客户端和服务之间的干扰。网关接收客户端请求，将请求分派给各种后端系统，然后聚合结果并将它们发送回请求客户端。
这种模式可以有效减少应用程序对后端服务的调用请求数，而且在高延迟网络上的应用程序的性能有大的提升。

在下图中，应用程序向网关发送请求（1）。该请求包含一组附加请求。网关分解这些请求并通过将每个请求发送到相关服务来处理每个请求（2）。每个服务都返回对网关的响应（3）。网关聚合每个服务的响应并将响应发送到应用程序（4）。应用程序发出单个请求，并且只从网关接收一个响应。

1.网关不应该在后端服务中引入服务耦合
2.网关应该和后端服务位置很近，以尽可能减少延迟。
3.网关服务可能须要做ha。确保网关设计合理，以满足您的应用程序的可用性要求。
4.网关可能是性能瓶颈。确保网关具有足够的性能来处理负载，并且可以扩展以满足您的预期增长。
5.对网关执行负载测试，以确保不会导致服务的级联故障。
6.使用隔板，断路，重试和超时等技术实现弹性设计。
7.如果一个或多个服务调用花费的时间太长，则可以接受超时并返回部分数据集。考虑您的应用程序将如何处理此方案。
8.使用异步I / O来提升程序的吞吐量。
9.通过分布式跟踪对全链路进行监控。
10.监控请求指标和响应大小。
11.考虑将缓存数据作为故障转移策略来处理故障。
12.不要将聚合构建到网关中，而是考虑在网关后面放置聚合服务。请求聚合可能具有与网关中的其他服务不同的资源要求，并且可能影响网关的路由和卸载功能。

1.客户端需要与多个后端服务通信才能完成操作
2.客户端可以使用具有明显延迟的网络，例如蜂窝网络。

1.您希望客户端对单个服务的请求次数（比如获取10个学生的信息，你只有一个单个查询学生信息的接口）。在这种情况下，最好向服务添加批处理操作。
2.客户端或应用程序位于后端服务附近，延迟不是一个重要因素。

以下示例是教你如何使用Lua创建简单的网关聚合NGINX服务。

【分享】什么是API网关？大公司为什么都有API网关？

在这篇文章中将我们一起来探讨当前的API网关的作用。
一、API网关的用处
API网关我的分析中会用到以下三种场景。

二、API网关在企业整体架构中的地位
一个企业随着信息系统复杂度的提高，必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等，在架构上应该将这三种应用区别开，三种应用的安排级别、访问方式也不一样。
因此在我的设计中将这三种应用分别用不同的网关进行API管理，分别是：API网关（OpenAPI合伙伙伴应用）、API网关（内部应用）、API网关（内部公网应用）。

三、企业中在如何应用API网关
1、对于OpenAPI使用的API网关来说，一般合作伙伴要以应用的形式接入到OpenAPI平台，合作伙伴需要到 OpenAPI平台申请应用。
因此在OpenAPI网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求OpenAPI网关需要提供API给这个用户平台进行访问。
如下架构：

当然如果是在简单的场景下，可能并不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用id/密钥等，这种情况下也就不需要合作伙伴门户子系统。
2、对于内网的API网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的API服务治理平台。
当企业将所有的应用使用微服务的架构管理起来，那么API网关就起到了微服务网关的作用。
而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理，那么API网关起到的就是API服务治理的作用。
架构参考如下：

3、对于公司内部公网应用（如APP、公司的网站），如果管理上比较细致，在架构上是可能由独立的API网关来处理这部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的API网关。
如果使用独立的API网关，有以下的好处：
• 面向合作伙伴和面向公司主体业务的优先级不一样，不同的API网关可以做到业务影响的隔离。
• 内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。
• 内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。
基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。

四、API网关解决方案
私有云解决方案如下：
• Kong是基于Nginx+Lua进行二次开发的方案
https://konghq.com/
• Eolinker和Kong比较接近，但是因为是国内公司开发的，后续的技术支持和培训比较友好。
https://www.eolinker.com
• Netflix Zuul，zuul是spring cloud的一个推荐组件， https://github.com/Netflix/zuul
• orange,这个开源程序也是国人开发的，不过这个是个人开发不是公司。
http://orange.sumory.com/
公有云解决方案：
• Amazon API Gateway， https://aws.amazon.com/cn/api-gateway/
• 阿里云API网关， https://www.aliyun.com/product/apigateway/
• 腾讯云API网关， https://cloud.tencent.com/product/apigateway
自开发解决方案：
• 基于Nginx+Lua+ OpenResty的方案，可以看到Eolinker，Kong，orange都是基于这个方案。
• 基于Netty、非阻塞IO模型。通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案。
• 基于Node.js的方案。这种方案是应用了Node.js天生的非阻塞的特性。
• 基于java Servlet的方案。zuul基于的就是这种方案，这种方案的效率不高，这也是zuul总是被诟病的原因。
五、企业怎么选择API网关
现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关，当然这些网关的基础功能肯定是没有问题，但是二次开发，扩展功能、监控功能可能就不能满足部分用户的定制需求了。
另外很多企业因为自身信息安全的原因，不能使用外网公有网的API网关服务，这样就只有选择私有云的方案了。
在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用，无法做到定制的合作伙伴门户，这也不适合于部分企业的需求。
如果作为微服务网关，大多数情况下是希望网关服务器和服务提供方服务器是要在内网的，在这里情况下也只有私有云的API网关才能满足需求。
综合上面的分析，基础公有云的API网关只有满足一部分简单客户的需求，对于很多企业来说私有云的API网关才是正确的选择。 关于为什么使用微服务网关和微服务为什么要用网关的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 为什么使用微服务网关的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务为什么要用网关、为什么使用微服务网关的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。