微服务网关业务聚合（微服务网关zuul）

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

本文目录一览：

• 1、微服务之网关聚合模式
• 2、微服务 六：服务网关
• 3、什么是微服务架构？主流的微服务如何实现？
• 4、微服务架构～BFF和网关是如何演化而来

微服务之网关聚合模式

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

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

在下图中，客户端向每个服务发送请求（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服务。

微服务 六：服务网关

服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图（15），网关是连接企业内部和外部系统的一道门，有如下关键作用：

服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。

限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。

监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。

日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。

图（15）gateway服务图

除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。

开源的网关组件有Netflix的Zuul，其工作原理如下图。

图（16）zuul工作原理图

在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图(17)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在图（17）的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Façade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。

图（17）简化的微服务架构图

什么是微服务架构？主流的微服务如何实现？

简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
主流的微服务包括微服务网关业务聚合：
1、SpringCloud
Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。
- Eureka:服务注册发现框架；
- Zuul:服务网关；
- Karyon微服务网关业务聚合：服务端框架；
- Ribbon：客户端框架；
- Hystrix：服务容错组件；
- Archaius：服务配置组件；
- Servo：Metrics组件；
- Blitz4j：日志组件；
2、Dubbo
Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
3、lstio
lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。
目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。
- HTTP、gRPC 和 TCP 网络流量自动负载均衡；
- 提供了丰富的路由规则，实现细颗粒度的网络流量行为控制；
- 流量加密、服务件认证，以及强身份声明；
- 全范围（Fleet-wide）的策略执行；
- 深度遥测和报告。

微服务架构～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

关于微服务网关业务聚合和微服务网关zuul的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关业务聚合的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关zuul、微服务网关业务聚合的信息别忘了在本站进行查找喔。

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