使用AI聊天机器人的方式
|
图中 Mono.empty 代表创建一个不包含任何元素，只发布消息的队列。发送消息后，会在线程池里处理网关的 slot ，最后处理成功后会调用 onSuccess 方法，处理失败则会调用 onError。下一节我们来看看这些网关 slot 是如何处理的。 网关的责任链设计
不管是核心网关还是嵌入式网关我们都采用了责任链模式来实现网关的核心处理流程，将每个处理逻辑看成一个slot，每个 slot 按照预先设定的顺序先后执行，与开源kong,zuul等类似，我们也采用了PRPE模式(Pre、Routing、Post、Error) 本来是要返回 foobar 对象的，结果最终以 Mono(或 Flux)的形式存在，这样就构建了响应式编程中的生产者(Publisher)，再调用 subscribe 即可完成对生产者的监听消费。
在我们的网关设计中，当收到请求后，使用了 Mono 来充当发布者，如果中间出现了问题，会调用 onError, 最终成功后会调用 onSuccess,以下是网关实现采用的总体框架。 为了让大家更好利用 webflux 编程，Spring 贴心地兼容了 @Controller 等 Spring MVC 的注解在 webflux 的使用，能让使用者更好地过渡到 webflux 编程中来，不过在底层实现中，与 Spring MVC 的实现的请求 InputStream 和响应 OutputStream 不同，webflux 实现了一套反应式的请求(ServerHttpRequest) 和响应(ServerHttpResponse)，这两个类将请求体与响应体以 Flux(Flux 下文会简单介绍下)的形式暴露出来，同时 webflux 底层也实现了基于 Flux的 JSON，XML 的序列化和反序列化，HTML 实图的渲染，Server 发送事件等。 通过介绍可以看到 webflux 实现了从请求到响应，到渲染，事件发送等一整套反应式事件的支持，是的，要最大程度地发挥 webflux 的性能，中间所有的事件都应该以 Mono 或 Flux 响应式事件流的形式存在! WebFlux 的底层实现其实是基于 Reactor 实现的，在 Reactor 的核心类中，以下两个类代表了发布者
这玩意怎么用呢,如下图示 2、实时响应 以我们的网关为例， request 线程接收请求后，快速返回存储结果的上下文，把具体执行交给线程池里的线程(可以认为是后台线程)，处理完成后，异步地将调用结果封装到结果的上下文中，可以看到此过程是完全异步的，也就是说实时响应必须通过异步编程实现，在 Java 8 中，发起调用后可以快速返回 CompletableFuture 对象。 3、弹性机制 事件驱动的松散耦合提供了组件在失败下可以抓获完全隔离的上下文场景，作为消息封装，发送到其他组件时，在具体编程时可以检查错误比如是否接受到，接受的命令是否可执行等等，并决定如何应对。 反应式编程主要工作流程如下
还有一个问题，如果 Publisher 发送消息过快超过 Subscriber 的处理速度了怎么办，所以就得提一下背压(BackPressure)的概念了,知乎网友扔物线对此概念解释我认为非常到位： backpressure 是源自工程学中的概念：在管道运输中，气流或液流由于管道突然变细、急弯等原因导致由某处出现了下游向上游的逆向压力，这种情况称为「backpressure」，相应的在反应式编程中，在数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure 出现，这里的重点在于「Buffer 溢出」，为什么需要 buffer, 因为 Publisher 生产速度大于 Subscriber 的消费速度，所以需要 Buffer, 因为外部条件限制，显然 Buffer 是有上限的，如果生产速度超过 buffer, 则 backpressure 产生，超过 buffer 的话，唯一的选择就是丢掉新事件。 这就好比，比如你的 server 只能承受 5000~6000 的请求，如果你把 buffer 设置为 5000,则一旦请求数超过 5000，则背压产生，超过的请求数丢弃，这样保证了机器不会被源源不断的 Publisher 生产事件压垮，有效提升了网关的可用性。 Spring WebFlux 简介 为了更好地促进反应式编程的应用，在 Java 平台上，Netflix(开发了 RxJava)、TypeSafe(开发了 Scala、Akka)、Pivatol(开发了 Spring、Reactor)共同制定了一个被称为 Reactive Streams 项目(规范)，用于制定反应式编程相关的规范以及接口。
Reactor 基于 Reactive Stream 定制了一套反应式编程框架，而 WebFlux 则是以 Reactor 为基础实现了 Web 领域的反应式编程框架，由于反应式编程的异步非阻塞特性，所以 WebFlux 运行于 Netty , Undertow 等支持异步编程模型的 server 之上，当然也可运行于支持 Servlet 3.1 的 Server 容器上(Servlet 3.1 开始支持异步) （编辑：唐山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
