微服务网关生产级（微服务网关的主要功能）

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

本文目录一览：

• 1、生产级基于SpringCloud微服务架构性能优化实战，建议收藏
• 2、Spring Cloud——微服务网关介绍
• 3、微服务网关层
• 4、微服务架构～BFF和网关是如何演化而来
• 5、微服务之网关聚合模式

生产级基于SpringCloud微服务架构性能优化实战，建议收藏

本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。

一般基于SpringCloud的微服务能够脱离传统的tomcat，独立跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以java -jar形式就能跑起来。

所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。

tomcat参数说明：

maxThreads，acceptCount参数应用场景

场景一

场景二

场景三

maxThreads调优

一般说服务器性能要从两个方面说起：

1、cpu计算型指标

2、io密集型指标

所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。

另外，要考虑tomcat的并发请求量大的情况下，对于服务器系统参数优化，如虚拟机内存设置和linux的open file限制。

maxThreads设置多大合适？

我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，服务器的请求响应吞吐量会急剧下降，所以maxThreads的配置绝对不是越大越好。

实际情况是设置maxThreads大小没有最优解，要根据具体的服务器配置，实际的应用场景不断的调整和优化。

acceptCount设置多大合适？

尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

当使用URL进行路由时，则需要对zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis参数控制超时时间。

请求连接的超时时间

请求处理的超时时间

对所有操作请求都进行重试

对当前实例的重试次数，针对同一个服务实例，最大重试次数（不包括首次调用）

对下个实例的重试次数，针同其它的服务实例，最大重试次数（不包括首次server）

注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试

Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？

目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false

还有一种是官方提倡的是 设置超时时间。

在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。

另外，禁用hystrix，官方不推荐 。

hystrix超时设置原则

问题：一个http请求，如果feign和ribbon都配置了重试机制，异常情况下一共会请求多少次？

请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积：

n(请求总次数) = feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)

其中+1是代表ribbon本身默认的请求。

其实二者的重试机制相互独立，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。

Spring Cloud——微服务网关介绍

为了解决以上的问题，API网关应运而生，加入网关后应用架构变为下图所示。

当引入API网关后，在用户端与微服务之间建立了一道屏障，通过API网关对微服务提供了统一的访问入口，所有用户端的请求被API网关拦截，并在此基础上可以实现额外的功能：

OpenResty是一个强大的Web应用服务器，web开发人员可以使用Lua脚本语言调用Nginx支持的各种以C以及Lua模块。

在性能方面，OpenResty可以快速构造出足以胜任10K以上并发连接响应的超高性能Web应用系统。

在国内，360、阿里云、腾讯网、去哪儿、酷狗音乐、新浪等都是OpenResty的深度用户。

但OpenResty是一款独立的产品，与主流的注册中心，存在一定的兼容问题，需要架构师独立实现其服务注册、发现功能。

Zuul是Netflix开源的微服务网关，主要职责是对用户请求进行路由转发与过滤。早期Spring Cloud与Netflix合作，使用Zuul作为微服务架构网关首选产品。

Zuul是基于J2EE Servlet实现路由转发，网络通信采用同步方式。

zuul 是netflix开源的一个API Gateway 服务器，本质上是一个web servlet应用。

Zuul可以通过加载动态过滤机制，从而实现以下各项功能：

Zuul的核心是一系列的filters，其作用可以类比Servlet框架的Filter，或者AOP。工作原理如下图所示：

Zuul可以对Groovy过滤器进行动态的加载，编译，运行。

Zuul2.x设计更为先进，基于Netty 非阻塞和支持长连接， 但是 SpringCloud 目前没有整合。 Zuul2.x 的性能较 Zuul1.x 有较大的提升。

Zuul2.x引入了Netty和RxJava，正如之前的 ZuulFilter 分为了 Pre、Post、Route、Error，Zuul2的Filter分为三种类型：

Spring 自己开发的新一代API网关产品，基于NIO异步处理，摒弃了Zuul基于Servlet同步通信的设计。

Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。

关键特征：

在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1.6 倍。

Spring Cloud Gateway十分优秀，Spring Cloud Alibaba也默认选用该组件作为网关产品。

客户端向 Spring Cloud Gateway 发出请求。如果 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。 过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。

Spring Cloud Gateway 的特征：

参考：
http://www.ityouknow.com/springcloud/2018/12/12/spring-cloud-gateway-start.html

http://www.likecs.com/show-50293.html

https://zhuanlan.zhihu.com/p/299608850?utm_source=wechat_session

https://juejin.cn/post/6844903965352525838

https://blog.csdn.net/weixin_38361347/article/details/114108368

http://www.zyiz.net/tech/detail-98256.html

微服务网关层

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

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

测试结果和心得如下微服务网关生产级：

微服务架构～BFF和网关是如何演化而来

BFF(Backend for Frontend)和网关Gateway是微服务架构中的两个重要概念，这两个概念相对比较新，有些开发人员甚至是架构师都不甚理解。(伟哥一直是做前端的，第一次听师父说BFF这个问题，还以为他说错了，前端没有BFF，BFC倒是有一个🤦‍♂️)

本文用假想的公司案例+图示的方式，解释BFF和网关是什么，它们是怎么演化出来的。希望对架构师设计和落地微服务架构有所启发。

我们先把时间推回到大致2011年左右。假设有一家有一定业务体量的电商公司CoolShop，在这个时间点它已经完成单块应用的解构拆分，内部SOA服务化已经初步完成。这个时候它的无线应用还没有起步，前端用户体验层主要是传统的服务端Web应用，总体服务化架构V1如下图所示。

时间转眼来到2012年初，国内的无线应用开始起风，CoolShop公司也紧跟市场趋势，研发自己的无线原生App。为了能尽快上线，公司的架构师提出如下V2架构，让App直接调用内部的服务：

这个架构有如下问题：

V2架构问题太多，没有开发实施。为解决上述问题，架构师经过思考决定在外部设备和内部微服务之间引入一个新的角色~Mobile BFF。

所谓BFF其实是Backend for Frontend的简称，中文翻译是为前端而开发的后端，它主要由前端团队开发（后端微服务一般由后端团队开发）。BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向无线端设备暴露友好和统一的API，方便无线设备接入访问后端服务。

新的V2.1架构如下图所以：

这个架构的优势是：

V2.1架构比较成功，实施落地以后支持了CoolShop公司早期无线业务的成长。随着业务量进一步增长，投入无线研发的团队也不断增加，V2.1架构也逐渐暴露出如下问题：

为了解决上述问题，架构师经过思考决定在外部设备和内部BFF之间再引入一个新的角色~API Gateway，新的架构V3如下图所示：

新的架构V3有如下调整：

在新的V3架构中，网关承担了重要的角色，它是解耦拆分和后续升级迁移的利器。在网关的配合下，单块BFF实现了解耦拆分，各业务线团队可以独立开发和交付各自的微服务，研发效率大大提升。另外，把跨横切面逻辑从BFF剥离到网关上去以后，BFF的开发人员可以更加专注业务逻辑交付，实现了架构上的关注分离(Separation of Concerns)。

业务在不断发展，技术架构也需要不断的调整来应对需求的变化。近年，CoolShop公司技术团队又迎来了新的业务和技术需求，主要是：

为满足业务需求，架构师对服务化架构又进行了拓展升级，新的V4新架构如下图所示：

V4整体思路和V3类似，只是拓展了新的接入渠道:

V4是一个比较完整的现代微服务架构，从外到内依次分为：端用户体验层-网关层-BFF层-微服务层。整个架构层次清晰，职责分明，是一种灵活的能够支持业务不断创新的演化式架构。

原文地址： https://www.cnblogs.com/dadadechengzi/p/9373069.html

微服务之网关聚合模式

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

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

在下图中，客户端向每个服务发送请求（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服务。 关于微服务网关生产级和微服务网关的主要功能的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关生产级的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关的主要功能、微服务网关生产级的信息别忘了在本站进行查找喔。

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