Contents
  1. 1. 前言
  2. 2. 异步模型之我见
    1. 2.1. 我眼中的异步模型
    2. 2.2. Nodejs 所要达到的异步模式
  3. 3. 服务器拓扑
  4. 4. Java 的异步模型 NIO/AIO
    1. 4.1. 大象能否跳舞
  5. 5. 写在最后
    1. 5.1. 温故中断
    2. 5.2. 慎用 Nodejs

前言

本文是笔者所总结的有关 Nodejs 基础系列之一,

本来打算直接对 Nodejs 的事件机制既 Event 和 EventEmitter 进行剖析,但是发现,如果没有对异步模型在整体上有着一个清晰和直观的认识,便直接对底层的东西进行分析,那就像瞎子摸象,只能知道局部;于是在深入 Nodejs 各个模块之前,笔者打算对异步模型做一个顶层和全盘的分析以后,再逐步的的深入到各个细节当中去;

注明:本文为作者的原创作品,转载需注明出处;

异步模型之我见

我眼中的异步模型

首先,要知道目前的服务器主要有两个派别,一类是科学计算性、一类是 I/O 优化型;有什么区别呢?

  • 科学计算型的服务器主要以消耗 CPU 和内存资源为主,基本上不发生 I/O 读写;所以,这类服务器主要以优化 CPU 计算能力为主,在单位时间内可以执行更多次的计算操作;要特别注意的是,要使得这种类型的服务器的性能发挥至极致,则要求进程尽可能的不要发生同步操作,因为同步操作往往伴随着 CPU 中断,因此则要求无论是进程还是线程都是科学计算型的进程;
  • I/O 优化型的服务器主要以消耗存储资源为主,这里的存储资源主要指的就是磁盘;在没有 DMA 控制器和零拷贝( Zero Copy )技术以前,基本上都需要使用中断 CPU 的方式,使得 CPU 暂停当前的执行,进而处理文件的读写;所以,这里服务器主要以优化 I/O 设备的性能为主;适用于作为文件系统服务器,大型数据库服务器等;

有了上面的背景知识以后,我们再来看看,异步模型的处理流程是怎样的?来看笔者画的下面这张逻辑图,
my asynchronous design mode.png
里面主要分为两类 Request 请求,一类是计算型请求 cal Request,灰黑色方框表示,另一类请求是 I/O 请求(同时有可能兼计算型请求,比如图中的 _db_ Request),由红色方框表示;我们要知道,异步模型的终极目标是什么?它的终极目标就是让所有的处理过程都不发生中断,既是不让 CPU 停止,让它一直执行,以便使得 CPU 达到最大化的性能;可是这么多不同类型的请求,怎么能够保证不发生中断呢?是的,这个的确不容易做到,光靠软件优化是做不到的,必须结合硬件的改良,一起才能做到;

  • 要能够达成这个终极目标,必须想办法让 I/O 操作不对 CPU 发起任何的中断,这个重担就由硬件工程师来完成了,他们设计了 DMA 控制器,以及零拷贝技术完美的解决了 I/O 包括 Socket 流读写过程的中断 CPU 的问题,所以,如图,一旦是 cal 请求以外的其它 I/O 类型请求,将会交给 DMA 控制器执行,当 I/O 请求完毕以后,直接通过回调方式将 I/O 结果的内存地址直接写入 main process 既主进程中,这样就不需要任何 CPU 的中断操作了;
  • Ok,看似一切都可以异步了,无论 cal Request 还是 file Request 都可以异步的执行而无需中断 CPU,但是别忘了,还有 _db_ Request,特别是老牌的 Database,比如 MySQL、Orcale、DB2 等,里面存在着大量的同步操作,同步往往都是通过休眠和唤醒的操作来实现的,其实归根结蒂仍然是靠中断 CPU 来实现的,那该如何是好呢,怎么来处理它的请求呢?其实答案也很简单,把他们的同步请求统统转换成异步的 Socket 请求,这样,main process 就不会发生中断了,这种转换正好是 Nodejs 天生的强项;最常见的做法就是把 database 部署在另外一台 I/O 优化型的服务器上就可以了,main process 只需要和这台服务器通过异步 Socket 进行连接就可以了;这样自然,main process 所在的主机一定能够达到最大化的执行性能;

上述便是笔者眼中的异步模型;

Nodejs 所要达到的异步模式

Nodejs 的异步模型到底想要达成一个什么样的目标?它的野心十足,至少目前对比与其它类型的编程语言来看,它是走得最彻底的,它不仅仅想让 Web Server 变成异步模型,同时也想让 Application Server 也变成异步模型的方式;(备注,Web Server 等价于 Tomcat、Netty 等服务器,Application Server 等价于 Spring 容器或者 J2EE 容器等;)

为什么说 Nodejs 是走得最彻底的呢?因为它天生就是为异步而生的,它的编程语言的底层架构,从出生的那一天起,就是按照异步模型来设计的,因此,它是天生的异步模式的语言;如果说我们 80 后是互联网时代的移民者,那么 00 后就诞生在互联网时代,是互联网时代的真正主人;同样,Java、Python 等语言可以认为是异步模型的移民者,而 Nodejs 是异步模型天生的主人;这就是笔者所认为的 Nodejs 与其它语言最本质的区别!

服务器拓扑

在有了上述的分析以后,笔者胸有成竹的画出了下面的这张拓扑图,

asynchronous topological diagram.png

是的,只要这样部署你的服务器,恭喜你,你的服务器处理 Request 的性能就能达到最大化;(什么,你说汇.. 什么,没听清,再说一遍,哦,汇编,你说用汇编才能最大化,啊,是的,你说对了,CPU 少了无数次的将 Nodejs 转换成 C,再将 C 转换成汇编的过程;不过笔者这里所谓的最大化有个前提,那就是高级语言!)

大哥,别骗我,我见过的拓扑图和架构图比这个复杂多了,你这个算哪门子的拓扑图呢?这么简单?是啊,为什么又不是呢?技术难道就该复杂呀?在你彻底搞懂了它的逻辑以后,去掉边边角角,化繁为简以后,它的确就是这么简单,Nodejs 以异步的方式不断的接收 Request,然后将不必要可能同步的请求转换成异步的 Socket 请求,完了,就这么简单;

是的,清静了,至少笔者的内心清静了;为什么呢?想想 Java 的 Web Server 和 Application Server 你就明白了,你得花多大的力气将 Tomcat 改造成 NIO 或者 AIO 的方式,是的,你说配置一下就好了,那你去试试,看看有没有什么 Bug?当你把 Web Server 搞定以后,Applicaiton Server,是呀 Spring 容器和 J2EE 又该怎么搞呢?这么多的应用和组件都是以同步的方式设计的,难道你去把他们统统都改造成异步的方式… 这就是为什么那么多 Java 工程师和架构师一天到晚费尽心力干的一件事情就是,无止尽的调优,无止尽的堆积服务器,无止尽的架构图,复杂的让你眼花缭乱的架构图;

哎,终于从内心中了解到了做 Java 工程师或者 Java 架构师为什么会那么的苦了,么的苦了,的苦了,苦了,了 ~~~ 无止尽的苦 ~ (听闻某人读到这里以后,喷了,稳住,别喷 ~)

Java 的异步模型 NIO/AIO

浅谈一下 Java 的 NIO/AIO,

大象能否跳舞

大多数 Java 工程师和架构师都对 Nodejs 不屑一顾,Java 不也有 NIO/AIO 嘛,你的异步模型,Java 都有,也都可以有;而且他们为什么不愿意接受 Nodejs 的一个最主要原因(之前包括笔者在内),Java 作为一个老牌的语言,已经有那么多成熟的开源的“轮子”可用,而且又经过这么多年行业的检验,Nodejs 算哪门子老几,一个新鲜出炉的小鲜肉而已;

对,这也是之前笔者一直不愿意接受 Nodejs 的一个主要原因,认为 Nodejs 能干的事情,Java 也能干;但是为什么笔者又改变了呢?为什么又愿意花这么大的力气来对它进行研究呢?嗯~ 好像是,吃饱了没事干呐~~ 呵呵… 开个玩笑;平心而论,就事论事,其实正是因为 Java 的最大的优点,它有那么多成熟的“轮子”,这是它最大的优势,但同时,也是它最大的“弱势”,为什么呢?因为它的“轮子”基本上都是构建在“同步机制”之上的;这样说,不知道你明白了没有?

所以,大象能够跳舞,只是它太累了,背负了太多,太多的负担;如果只是两三个包裹到还好办,但是它背负的是数不清的大山;它已经跳不动了!

写在最后

温故中断

归纳起来,CPU 中断主要经历了那么两个时期,且都是为了解决 CPU 的计算效率和 I/O 设备输入输出效率之间时间差的问题,

  1. CPU 空转,等待 I/O 的反馈
    这个时期,CPU 的中断主要是靠程序自己实现的循环来不断的轮询 I/O 是否反馈,然后继续执行后续的程序逻辑;这个时期与其说是中断,实际上 CPU 是一直在工作,其它的进程都会被阻塞;
  2. 进程休眠,等待 I/O 反馈以后被唤醒
    这个时期的特征是,CPU 不再为了等待 I/O 而空转,转而是保护当前线程的现场,然后让当前的进程休眠,I/O 返回以后,唤醒之前沉睡中的进程,让它继续执行;看似整个过程都水到渠成,但是里面却隐含了巨大的隐患,那就是性能问题,想想,“睡眠”和“唤醒”,有那么容易实现吗?一个进程会有大量的上下文环境来支撑它来执行,也就注定了在这个过程中,在“睡眠”的时候要进行所谓的“保护现场”,其实也就是缓存当前进程的上下文环境,同样,在“唤醒”的时候需要进行所谓的“恢复现场”,其实也就是从内存中读取该进程的上下文环境;说了这么多,聪明的你应该可以感知着一进一出会消耗多少 CPU 资源了吧,何况,当某个进程被“唤醒”的同时,一定会让另一个进程“休眠”,又一次的保护现场;这就是我们常说的,传统编程语言下多线程会出现的频繁上下文切换,当并发量高了以后,就会导致 CPU 因此而效率急剧降低,因为它的大部分工作都是去进行上下文切换了;

实际上,#1 和 #2 所导致的 CPU 中断的罪魁祸首就是“同步”,想想某个进程必须等待 I/O 返回以后才能继续执行,那么没有办法,要么进程空转、要么让进程睡眠和唤醒;所以,只要能够解决应用程序“同步”操作,那么就能解决 CPU 中断的问题;这也就是 Nodejs 这么语言从诞生之日起所背负的使命;

慎用 Nodejs

最后,笔者还是得提一下,Nodejs 最大的优势同时也是它最大的劣势,它最大的优势就是它非常的新,很多东西都可以重头来过,但也正是因为它的新,导致很多“轮子”或许还没有,或许有但还不够成熟;所以,如果你当前的系统不需要非常高的并发,同时对事务完整性和强一致性特别高,比如说金融领域,笔者还是推荐你使用传统的 J2EE 架构;不过这个建议是有时效的,当 Nodejs 变得成熟以后,自然便可以替代 J2EE 的地位了;所以,笔者有必要注明一下提出这个论点的时间点是 2018-02-26;

Contents
  1. 1. 前言
  2. 2. 异步模型之我见
    1. 2.1. 我眼中的异步模型
    2. 2.2. Nodejs 所要达到的异步模式
  3. 3. 服务器拓扑
  4. 4. Java 的异步模型 NIO/AIO
    1. 4.1. 大象能否跳舞
  5. 5. 写在最后
    1. 5.1. 温故中断
    2. 5.2. 慎用 Nodejs