在Ubuntu上安装最新版本的Handbrake

工作原理如下

1. 只有一个 request 线程负责 accept 所有的请求，每个请求都有一个 Event handler 和回调，request 线程接收到 request 请求后，首先会为此请求在 Event Loop 中注册一个回调函数，紧接着马上把这个请求丢给线程池中的某个线程处理，然后此 request 线程立马返回，马上就可以处理另外的请求了。
2. 线程池中的线程处理完请求的 Event Handler(DB，网络IO等逻辑) 后，会去调用之前注册好的回调函数返回请求结果

从以上的工作原理可以看出，负责处理请求的 request 线程只需求一个，线程数大大减少!更少的线程意味着更高的内存利用，也意味着线程间的切换开销大大减少!所以显然应该使用这种编程模型。

打个简单的比方，相信大家都有去酒店就餐的经历，对于酒店来说，怎么才能最大化地提高接客效率呢

1. 一种方式是对每一个客人，都安排一位接待员，这名接待员负责客人的接待，入座，上菜等所有流程，显然如果这样安排的话有多少位客人就等安排多少位接待员。
2. 第二种方式是只安排一位接待员，这名接待员在接待客人入座后，立刻回到门口迎接客人，剩下的交给上菜服务员(线程池工作)，这样的话接待员的人数就大大减少了，能极大地提升效率。

最终我们选择了 Spring WebFlux 这种反应式(Reactive)，基于事件驱动的异步非阻塞框架。

反应式编程与 Spring WebFlux 简介

反应式编程简介

反应式编程 (reactive programming) 是一种基于数据流 (data stream) 和 变化传递 (propagation of change) 的 声明式 (declarative) 的编程范式。它是一种编程思想，能够基于数据流中的事件(变化)进行相关反应处理，举个简单的例子：在 a = b + c 这个语句中，要得到 a 的值，如果用传统的编程模型，每次 b 或 c 变化后都需要重新计算以获得 a，而在反应式编程中，我们把 b,c 当作数据流，a 会对 b，c 作出的变化实时响应。

反应式编程有以下几个特点

1、事件驱动

在事件驱动的程序中，组件之间通过松藕合的生产者(也称被订阅者，即 Publisher)和订阅者模式(Subscriber)来实现，这些事件是以异步和非阻塞的方式来接收和发送的，基于事件驱动的编程有啥好处呢，简单地说它是依靠推模式而不是拉模式来动作的，也就是说只有生产者有消息(变化)时才会通知消费者作出响应，也就意味着消费者不需要轮询也不需要等待数据。

 

其中嵌入式网关是以 jar 包的形式集成到业务的工程里的，具体为啥要这样设计，后文会详述。

首先来看 Java 网关为啥要分成核心网关和嵌入式业务网关两部分，直接从接入层打到业务网关不是更省事吗，何必多此一举再加一层核心网关，多加一层不是多了一个损耗吗。

这里有三个原因

1. 核心网关主要起着风控，鉴权、路由协议转换、流控、降级，打点统计(请求报错等)等作用，这些功能对每一个层请求来说都是通用的，统一将这些功能抽离放在核心网关实现更合理。
2. 当然了，可以统一把第一点所述的这些功能放在接入层实现，但这样会让接入层显得很臃肿，另外第一点中有一个很重要的功能，路由协议转换(将 http 转成 dubbo),由于我们的接入层用的是 OpenResty，它是不支持这种协议转换的，除非基于 OpenResty 做二次开发，这样费时费力，也无必要，这样看来抽出一个 Java 核心网关来担任第一点所述的功能是更合理的，计算机界不有一句话么：任何问题，在计算机界都可以通过加入一个中间层来解决。加一个 Java 核心网关符合单一职责，分层的设计理念。
3. 加入一个核心网关，确实多了一层，也多了一个损耗，不过核心网关并不处理具体的逻辑，它主要起着流量转发的作用，而且在下文我们可以看到，它采用了 webflux 这种反应式编程框架，带来的损耗比起引入它带来的优势可以忽略不计。

接下来我们简单谈谈核心网关和业务网关的设计思路。

核心网关技术选型

同步阻塞 VS 异步非阻塞

上节介绍可知 Java 核心网关承担着所有的流量入口，本身会调用大量的业务接口(打到业务网关里)，所以 IO 操作会很频繁，在技术选型上是有要求的， 首先来看看传统的 Spring MVC(servlet 3.0之前)

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!