网关Zuul科普

2024-09-02 09:58
文章标签 zuul 网关 科普

本文主要是介绍网关Zuul科普,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

点击上方“朱小厮的博客”,选择“设为星标”

后台回复”加群“获取公众号专属群聊入口

欢迎跳转到本文的原文链接:https://honeypps.com/backend/introduction-of-zuul/

为什么要使用网关

不同的微服务一般会有不同的网络地址,而外部客户端(例如手机APP)可能需要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP,可能会调用多个微服务的接口,才能完成一次购票的业务流程,如下图所示。

如果让客户端直接与各个微服务通信,会有以下的问题:

  • 客户端会多次请求不同的微服务,增加了客户端的复杂性。

  • 存在跨域请求,在一定场景下处理相对复杂。

  • 认证复杂,每个服务都需要独立认证。

  • 难以重构,随着项目的迭代,可能需要重新划分微服务。例如,可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信,那么重构将会很难实施。

  • 某些微服务可能使用了防火墙/浏览器不友好的协议,直接访问会有一定的困难。

以上问题可借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层,所有的外部请求都会先经过微服务网关。使用微服务网关后,架构如下所示。

此时,微服务网关封装了应用程序的内部结构,客户端只须跟网关交互,而无须直接调用特定微服务的接口。这样,开发就可以得到简化。不仅如此,使用微服务网关还有以下优点:

  • 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。

  • 易于认证。可在微服务网关上进行认证,然后再将请求转发到后端的微服务,而无须在每个微服务中进行认证。

  • 减少了客户端与各个微服务之间的交互次数。

Zuul 简介

Zuul 是Netflix开源的一个API网关(代码托管地址:https://github.com/Netflix/zuul), 本质上是一个Web Servlet应用。Zuul也是Spring Cloud全家桶中的一员, 它可以和Eureka、Ribbon、Hystrix等组件配合使用。

Zuul的核心是一系列的过滤器,这些过滤器帮助我们完成以下功能:

  • 验证与安全保障: 识别面向各类资源的验证要求并拒绝那些与要求不符的请求。

  • 审查与监控: 在边缘位置追踪有意义数据及统计结果,从而为我们带来准确的生产状态结论。

  • 动态路由: 以动态方式根据需要将请求路由至不同后端集群处。

  • 压力测试: 逐渐增加指向集群的负载流量,从而计算性能水平。

  • 负载分配: 为每一种负载类型分配对应容量,并弃用超出限定值的请求。

  • 静态响应处理: 在边缘位置直接建立部分响应,从而避免其流入内部集群。

  • 多区域弹性: 跨越AWS区域进行请求路由,旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近。

除此之外,Netflix公司还利用Zuul的功能通过金丝雀版本实现精确路由与压力测试。

注:以上介绍来自Zuul官方文档,但其实开源版本的Zuul以上功能一个都没有——开源的Zuul只是几个Jar包而已,以上能力指的应该是Netflix官方自用的Zuul的能力。

快速入门

定义2个服务:hello-server和user-server,他们分别都注册到eureka服务上,示例如下(这里将下面讲到的Zuul也注册上去了):

在未经过网关时,我们可以通过以下2个接口来分别访问hello-server和user-server:

http://localhost:8081/hello
http://localhost:8082/user

现在我们来定义Zuul服务,相关的Maven依赖如下:

<dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-zuul</artifactId><version>2.2.2.RELEASE</version></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId><version>2.2.2.RELEASE</version></dependency>
</dependencies>

application.yml文件中添加如下配置:

spring:application:name: zuul-serviceeureka:client:service-url:defaultZone: http://localhost:8761/eurekaserver:port: 6069

启动类中添加@EnableZuulProxy注解

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.zuul.EnableZuulProxy;@SpringBootApplication
@EnableZuulProxy
public class ZuulServiceApplication {public static void main(String[] args) {SpringApplication.run(ZuulServiceApplication.class, args);}
}

启动程序之后,我们可以通过服务网关访问上面的2个接口:

curl http://localhost:6069/hello-server/hello
curl http://localhost:6069/user-server/user

注意:默认的Zuul结合Eureka会注册到Eureka的服务名作为访问的ContextPath。在Zuul中我们可以自定义配置各种路由规则,这里就不再做相关赘述了。

请求过滤

上面的示例中,我们通过Zuul实现了请求路由的功能,这样我们的微服务应用提供的接口就可以通过统一的API网关入口被客户端访问到了。

每个客户端用户请求服务应用提供的接口时,他们的访问权限往往都有一定的限制,系统并不会将所有的微服务接口对他们开放。然而,目前的服务路由并没有限制权限这样的功能,所有请求都会被毫无保留的转发到具体的应用并返回结果,为了实现对客户端请求的安全校验和权限控制,最简单和粗暴的方法就是在每个微服务应用都实现一套用于校验签名和鉴别权限的过滤器或拦截器。这样有个问题就是功能实现太过冗余。比较好的做法就是将这些校验逻辑剥离出去,构建一个独立的鉴权服务。在完成剥离之后,直接在微服务应用中通过调用鉴权系统服务来实现校验,但是这样仅仅只是解决了鉴权逻辑的分离,并没有在本质上将这部分不属于冗余的逻辑从原有的微服务应用中拆出去,冗余的拦截器或者过滤器依然会存在。

对于这样的问题,更好的做法是通过前置的网关服务来完成这些非业务性质的校验。由于网关服务的加入,外部客户端访问我们的系统已经有了统一的入口,既然这些校验与具体的业务无关,那何不在请求到达的时候就完成校验和过滤,微服务应用端就可以去除各种复杂的过滤器和拦截器了,这使得微服务应用接口的开发和测试复杂度也得到了相应的降低。这就涉及到了zuul的另一个主要功能,请求过滤。

下面通过一个简单的示例来了解一下过滤器的使用:

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import lombok.extern.log4j.Log4j2;import javax.servlet.http.HttpServletRequest;@Log4j2
public class AccessFilter extends ZuulFilter {//过滤器的类型,它决定过滤器在请求的哪个生命周期中执行,这里定义为pre,代表会在请求被理由之前执行。@Overridepublic String filterType() {return "pre";}//过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时,需要根据该方法返回的值来依次执行@Overridepublic int filterOrder() {return 0;}//判断该过滤器是否需要被执行。这里我们直接返回了true,因此该过滤器对所有的请求都生效。实际运行中我们可以利用该函数//来指定过滤器的有效范围。@Overridepublic boolean shouldFilter() {return true;}//过滤器的具体执行逻辑。@Overridepublic Object run() throws ZuulException {RequestContext ctx = RequestContext.getCurrentContext();HttpServletRequest request = ctx.getRequest();log.info("send {} request to {}", request.getMethod(), request.getRequestURI().toString());Object accessToken = request.getParameter("accessToken");if (accessToken == null) {log.warn("access token is empty");ctx.setSendZuulResponse(false);ctx.setResponseStatusCode(401);} else {log.info("access token ok");}return null;}
}

代码示例中的ZuulFilter接口中定义了4个方法:

  • filterType:过滤器的类型(Type),它决定过滤器在请求的哪个生命周期中执行,这里定义为pre,代表会在请求被理由之前执行。(有关过滤器的类型会在下面的篇幅中详细描述)

  • filterOrder:过滤器的执行顺序(Execution Order)。当请求在一个阶段中存在多个过滤器时,需要根据该方法返回的值来依次执行。

  • shouldFilter:判断该过滤器是否需要被执行(Criteria)。这里我们直接返回了true,因此该过滤器对所有的请求都生效。实际运行中我们可以利用该函数。

  • run:过滤器的具体执行逻辑(Action)。

在启动类中添加上这个过滤器:

@Bean
public AccessFilter accessFilter(){return new AccessFilter();
}

此时,再访问 curl http://localhost:6069/hello-server/hello 接口时会报错,状态码为401,正确的访问姿势是:

curl http://localhost:6069/hello-server/hello?accessToken=666

过滤器的生命周期

Zuul中定义了4种标准的过滤器:pre、routing、post以及error,这些过滤器类型对应于请求的典型生命周期。我们参考下面的生命周期图来讲述一下这4种过滤器的作用以及执行顺序。

外部HTTP请求到达API网关服务的时候,首先它会进入第一个阶段pre,在这里它会被pre类型的过滤器进行处理。该类型过滤器的主要目的是在进行请求路由之前做一些前置加工,比如权限限制等。

在完成了pre类型的过滤器处理之后,请求进入第二个阶段routing,也就是路由请求转发阶段,请求将会被routing类型的过滤器处理。这里的具体处理内容就是将外部请求转发到具体服务实例上去的过程,当服务实例请求结果都返回之后,routing阶段完成,请求进入第三个阶段post。

此时请求将会被post类型的过滤器处理,这些过滤器在处理的时候不仅可以获取到请求信息,还能获取到服务实例的返回信息,所以在post类型的过滤器中,我们可以对处理结果进行一些加工或转换等内容,比如为响应添加标准的HTTP Header、收集统计信息和指标等。

另外,还有一个特殊的阶段error,该阶段只有在上述三个阶段中发生异常的时候才会触发。我们通过下面的过滤器执行流程图来加深一下对error过滤器的理解。

一般来讲,正常流程是pre -> route -> post。如果在pre过滤器阶段抛出异常,那么流程是:pre -> error -> post;如果在route过滤阶段抛出异常,那么流程是:pre -> route -> error -> post;如果在post过滤阶段抛出异常,最终流程是:pre -> route -> post -> error。

除了默认的过滤器类型,Zuul还允许我们创建自定义的过滤器类型。例如,我们可以定制一种STATIC类型的过滤器,直接在Zuul中生成响应,而不将请求转发到后端的微服务。

过滤器是Zuul实现API网关功能最核心的部件,每一个进入Zuul的HTTP请求都会经过一系列的过滤器处理链得到请求响应并返回给客户端。就以Zuul的路由功能为例,路由功能在真正运行时,它的路由映射和请求转发都是由几个不同的过滤器完成的。其中,路由映射主要通过pre类型的过滤器完成,它将请求路径与配置的路由规则进行匹配,以找到需要转发的目标地址;而请求转发的部分则是由route类型的过滤器来完成,对pre类型过滤器获得的路由地址进行转发。

Zuul的架构

下图展示了Zuul Core的工作原理,根据此图,我们可以更好地理解Zuul。

Zuul 的过滤器基本上是由 Groovy 语言编写的,这些过滤器起初以文件(以.groovy结尾)的形式存放在特定的目录下面。Zuul中的 FilterFileManager 会定期轮训这些目录,新加入的或者修改过的过滤器会被动态的加载进来。FilterFileManager 读取完 .groovy 文件之后会使用 GroovyComplier 将其编译成为JVM Class,之后再实例化(Class.newInstance)成 ZuulFilter 对象(即过滤器),最终保存在 FilterRegistry 中。FilterRegistry 是图中 FilterLoader 包含的一个对象,所以我们可以说成是:ZuulFilter 对象最终保存在FilterLoader中。

FilterRegistry可以看成是一个ConcurrentHashMap,其中key为.groovy文件的路径,value是动态加载之后的ZuulFilter对象。

Zuul的过滤器之间没有直接的相互通信,他们之间通过一个RequestContext(也可以看成是一个ConcurrentHashMap)来进行数据传递的。RequestContext 类中由 ThreadLocal 变量来记录每个 Request 所需要传递的数据。

当一个请求进入 Zuul 时,首先是交由 ZuulServlet 处理,ZuulServlet 中有一个ZuulRunner对象,该对象中初始化了前面所说的RequestContext。ZuulRunner中还有一个FilterProcessor,这个FilterProcessor从FilterLoader(FilterRegistry)中获取ZuulFilter(s)。有了这些ZuulFilter(s)之后,ZuulServlet首先执行的pre类型的过滤器,再执行route类型的过滤器,最后执行的是post 类型的过滤器,如果在执行这些过滤器有错误的时候则会执行error类型的过滤器。执行完这些过滤器,最终将请求的结果返回给客户端。

Zuul 2.x

5 月 21 日,Netflix 在其官方博客上宣布正式开源微服务网关组件 Zuul 2(Zuul是 Netflix 于 2013 年 6 月 12 日开源的,为了便于区分,下面都将前面所讲的 Zuul 表述为 Zuul 1)。Zuul 2 和 Zuul 1 在架构方面的主要区别在于,Zuul 2 运行在异步非阻塞的框架上,比如 Netty。Zuul 1 依赖多线程来支持吞吐量的增长,而 Zuul 2 使用的 Netty 框架依赖事件循环和回调函数。

Zuul2是一个在 Netty 上运行一系列Filter的服务,执行完成inbound filters之后将请求通过 Netty Client 转发出去,然后将请求的结果通过一系列outbound filters返回,如上图所示。正如之前的ZuulFilter分为了pre、post、routing、error,Zuul 2的Filter分为三种类型:

  • Inbound Filters: 在路由之前执行

  • Endpoint Filters: 路由操作

  • Outbound Filters: 得到相应数据之后执行

Zuul 2大体架构如上图所示,和Zuul 1没有本质上的区别。之前ZuulFilter分为了pre、post、routing、error,Zuul 2的Filter分为三种类型:inbound、endpoint、outbound。在Zuul 2中,过滤器前端用Netty Server代替了原本 Zuul 1中的Servlet,后端过滤器使用Netty Client 代替了HttpClient,这样前后端都可以支持异步(Zuul1可以使用Servlet 3.0规范支持的AsyncServlet进行优化,可以实现前端异步,支持更多的连接数,达到和Zuul2一样的效果)。相比如Zuul 1,Zuul 2在功能上也丰富和优化了很多,比如对HTTP/2、WebSocket的支持。

Zuul 1 vs Zuul 2

Zuul1设计比较简单,代码不多也比较容易读懂,它本质上就是一个同步Servlet,采用多线程阻塞模型,如下图所示。

同步Servlet使用thread per connection方式处理请求。简单讲,对于每一个新入站的请求,Servlet容器都要为其分配一个线程,直到响应返回客户端这个线程才会被释放返回容器线程池。如果后台服务调用比较耗时,那么这个线程就会被阻塞,阻塞期间线程资源被占用,不能执行其他任务。Servlet容器线程池的大小是有限制的,当前端请求量大,而后台慢服务比较多时,很容易耗尽容器线程池内的线程,造成容器无法接受新的请求,Netflix为此还专门研发了Hystrix熔断组件来解决慢服务耗尽资源问题。

这种同步阻塞模式编程模型比较简单,整个请求->处理->响应的流程(call flow)都是在一个线程中处理的,开发调试也便于理解,Debug也比较方便。不过,同步阻塞模式一般会启动很多的线程,必然引入线程切换开销。另外,同步阻塞模式下,容器线程池的数量一般是固定的,造成对连接数有一定限制,当后台服务慢,容器线程池易被耗尽,一旦耗尽容器会拒绝新的请求,这个时候容器线程其实并不忙,只是被后台服务调用IO阻塞,但是干不了其它事情。

总体上,同步阻塞模式比较适用于计算密集型(CPU bound)应用场景。对于IO密集型场景(IO bound),同步阻塞模式会白白消耗很多线程资源,它们都在等待IO的阻塞状态,没有做实质性工作。

Zuul2的设计相对比较复杂,代码也不太容易读懂,它采用了Netty实现异步非阻塞编程模型,如下图所示。

如果需要阅读 Zuul 2源码,通过《[Zuul2源码分析](http://springcloud.cn/view/344)》这篇文章辅助一下也许会事半功倍。

在上图中,你可以简单理解为前端有一个队列专门负责处理用户请求,后端有个队列专门负责处理后台服务调用,中间有个事件环线程(Event Loop Thread),它同时监听前后两个队列上的事件,有事件就触发回调函数处理事件。这种模式下需要的线程比较少,基本上每个CPU核上只需要一个事件环处理线程,前端的连接数可以很多,连接来了只需要进队列,不需要启动线程,事件环线程由事件触发,没有多线程阻塞问题。

异步非阻塞模式启动的线程很少,使用的线程资源少,上下文切换开销也少。非阻塞模式可以接受的连接数大大增加,可以简单理解为请求来了只需要进队列,这个队列的容量可以设得很大,只要不超时,队列中的请求都会被依次处理。异步模式让编程模型变得复杂。异步模型没有一个明确清晰的请求->处理->响应执行流程,它的流程是通过事件触发的,请求处理的流程随时可能被切换断开,内部实现要通过一些关联id机制才能把整个执行流再串联起来,这就给开发调试运维引入了很多复杂性,比如你在IDE里头调试异步请求流就非常困难。

总体上,异步非阻塞模式比较适用于IO密集型(IO bound)场景,这种场景下系统大部分时间在处理IO,CPU计算比较轻,少量事件环线程就能处理。

至于Zuul1和Zuul2的性能比对,Netflix给出了一个比较模糊的数据,大致Zuul2的性能比Zuul1好20%左右,这里的性能主要指每节点每秒处理的请求数。为什么说模糊呢?因为这个数据受实际测试环境,流量场景模式等众多因素影响,你很难复现这个测试数据。即便这个20%的性能提升是确实的,其实这个性能提升也并不大,和异步引入的复杂性相比,这20%的提升是否值得是个问题。Netflix本身在其Blog [References 5] 和 ppt [References 8] 中也是有点含糊其词,甚至自身都有一些疑问的。

那么问题来了,你选则使用Zuul1还是Zuul2, 或者是Spring Cloud Gateway,亦或者是Kong?

Referencs

  1. https://netflixtechblog.com/announcing-zuul-edge-service-in-the-cloud-ab3af5be08ee

  2. https://www.jianshu.com/p/9c104186572d

  3. http://www.itmuch.com/spring-cloud/finchley-16/

  4. http://www.itmuch.com/spring-cloud/zuul/zuul-ha/

  5. https://netflixtechblog.com/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c

  6. https://mp.weixin.qq.com/s/QkeIVTn97VmOc0Y18PAvYQ

  7. https://blog.csdn.net/yang75108/article/details/86991401

  8. https://github.com/strangeloop/StrangeLoop2017/blob/master/slides/ArthurGonigberg-ZuulsJourneyToNonBlocking.pdf

欢迎跳转到本文的原文链接:https://honeypps.com/backend/introduction-of-zuul/

想知道更多?描下面的二维码关注我

后台回复”加群“获取公众号专属群聊入口

【精彩推荐】

  • 咱们从头到尾说一次Java垃圾回收

  • Netty、Kafka中的零拷贝技术到底有多牛?

  • go为什么这么快?

  • 面试前,我们要复习多少Redis知识?

  • Redis性能问题分析

  • 浅谈CAP和Paxos共识算法

  • 聊一聊Java中的文件锁

  • Kafka为什么这么快?

  • Paxos、Raft不是一致性算法嘛?

  • 聊聊Java的几把JVM级锁

  • 越说越迷糊的CAP

  • 大公司为什么都有API网关?

  • 面试官居然问我Raft为什么会叫做Raft!

  • 面试官给我挖坑:URI中的//有什么用

>>> 字节跳动社招内推入口 <<<

>>> 字节跳动校招内推入口 <<<

朕已阅 

这篇关于网关Zuul科普的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1129649

相关文章

计算机网络基础概念 交换机、路由器、网关、TBOX

提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 文章目录 前言一、VLAN是什么?二 、交换机三、路由器四、网关五、TBOXTelematics BOX,简称车载T-BOX,车联网系统包含四部分,主机、车载T-BOX、手机APP及后台系统。主机主要用于车内的影音娱乐,以及车辆信息显示;车载T-BOX主要用于和后台系统/手机APP通信,实现手机APP的车辆信息显示与控

Zuul详细解释

Zuul 是 Netflix 开源的 API 网关,广泛用于微服务架构中。它作为系统的前置网关,主要功能包括路由、负载均衡、限流、安全性管理等。Zuul 最常见的应用场景是作为反向代理,它接收所有来自客户端的请求,并将请求转发给后端的微服务,从而屏蔽了微服务的复杂性。Spring Cloud 集成了 Zuul,使其成为 Spring Cloud 微服务生态系统中的一个重要组件。 为什么使用 Zu

Java后端微服务架构下的服务网关设计:Spring Cloud Zuul

Java后端微服务架构下的服务网关设计:Spring Cloud Zuul 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,服务网关是微服务系统与外部世界的入口点,它负责请求路由、负载均衡、认证、监控等任务。Spring Cloud Zuul是一个基于Spring Boot的网关服务,它为微服务架构提供了一种灵活、高效的网关解决方案。 服务

微服务之网关安全基于Zuul并实现网关限流

微服务网关安全 微服务架构下的问题 处理安全和业务逻辑耦合,增加了复杂性和变更成本 随着业务节点增加,认证服务器压力增大 多个微服务同时暴露,增加了外部访问的复杂性 通过网关处理流程 1、请求令牌。2、转发请求。3、返回令牌。4、转发令牌各客户端应用。5、携带令牌发送请求。6、校验令牌。7、返回校验结果信息。8、访问微服务。 实例 引入依赖 <dependencies><depe

API 网关 OpenID Connect 实战:单点登录(SSO)如此简单

作者:戴靖泽,阿里云 API 网关研发,Higress 开源社区 Member 前言 随着企业的发展,所使用的系统数量逐渐增多,用户在使用不同系统时需要频繁登录,导致用户体验较差。单点登录(Single Sign-On,简称 SSO)正是为了解决这一问题。当用户登录一次后,即可获取所有系统的访问权限,不需要对每个单一系统逐一登录。 目前,SSO 的实现方案常见有以下几种: 基于 JWT:

基于阿里云函数计算(FC)x 云原生 API 网关构建生产级别 LLM Chat 应用方案最佳实践

作者:计缘 LLM Chat 应用大家应该都不陌生,这类应用也逐渐称为了我们日常的得力助手,如果只是个人使用,那么目前市面上有很多方案可以快速的构建出一个LLM Chat应用,但是如果要用在企业生产级别的项目中,那对整体部署架构,使用组件的性能,健壮性,扩展性要求还是比较高的。本文带大家了解一下如何使用阿里云Serverless计算产品函数计算构建生产级别的LLM Chat应用。 该最佳实践会

基于OGC300工业级LORA网关与OM201L数传终端的化工厂人员定位系统解决方案

化工行业作为高风险的行业之一,其安全管理一直备受关注。化工生产过程中涉及到各种危险品和复杂的工艺,一旦发生事故,往往会造成严重的人员伤亡和财产损失。因此,化工企业急需一套可靠的安全管理系统来监测安全隐患、预防事故发生。 在这一背景下,基于先进的LORA自组网技术、BLE高精度定位技术、5G通讯技术、AI图像智能识别技术、云计算与数字孪生技术等前沿技术,北京东用科技提出了一套全新的化工厂人

网关,DNS,MAC地址,子网掩码,网段分别是什么?

网关、DNS、MAC地址、子网掩码和网段是计算机网络中的基础概念,它们在网络通信和数据交换中扮演着关键角色。以下将详细解释每个概念及其功能: 网关 定义:网关(Gateway)又称网间连接器或协议转换器,是用于连接两个高层协议不同的网络的设备。功能:网关主要用来实现不同网络之间的数据传递和通信。在TCP/IP协议中,网关通常是网络通向其他网络的IP地址。例如,主机发现数据包目的主机不在本地网络内

网关桥梁:modbus 转 profinet 网关中频加热机的智能融合之旅

一、项目序章:金属热处理的智慧曙光在金属锻造的辉煌舞台上,中频感应加热电源以其高效节能、精准控温的卓越才艺,成为了热处理、焊接与成型艺术中不可或缺的幕后英雄。然而,随着工业自动化的浪潮汹涌而至,如何让这位英雄融入智能工厂的广阔天地,实现远程指挥与智能操控,成为了新时代的命题。本案例,便是一场关于中频感应加热电源与工业网关携手,共绘智能工厂新蓝图的壮丽篇章。 二、系统蓝图:织就智慧互联的经纬1

Salt Function Flow:深度解析复杂网关编排的优势与实践

系列文章索引: Salt Function Flow 系列文章 在业务流程编排中,处理条件逻辑、并行任务、以及复杂的流程分支是常见的挑战。对于需要高度灵活性和扩展性的项目,Salt Function Flow 提供了强大的网关编排能力,使开发者能够轻松定义和管理复杂的业务流程。本文将深入探讨Salt Function Flow中的复杂网关编排功能,展示其如何通过排他网关、并行执行等功能应对复杂的