Deno源码简析（一）架构

开始

感受又好久好久没写东西了，内心有点忐忑不安：一直埋头工做而不去学习新知识但是程序员的大忌，恰好Deno又正式发布1.0，因此忙里偷闲也要学习一下，那么今天就是带来一波简单的Deno源码分析。

Deno vs Node.js

有人说Deno就是Destroy Node的缩写就是为了替代Node.js而生，也有人说Deno目前不成熟并不能替代如今的Node.js等等；自从Ryan指出Node.js的十大问题而且公开了新的项目Deno，在某乎上立马就展开各类（友好）讨论。不过不管怎么样，有竞争才有进步，Deno已经做为一个挑战者走进咱们的视野，咱们只需客观正视它的优缺点就行了。
不过我的的一些见解，Deno的出现基本意味着这是一场死斗，由于彼此基本特性实在太类似了：v8引擎，单线程异步，背靠着js的生态圈...，基本意味着开发者选择二者其一就永远不须要考虑其二，长远来看用户群可能会分裂吧；而Deno目前在这个基础上主打的是稳定性和安全性，这是服务端开发所必须的，只有知足这两个要求基础上才能去追求更高的性能，因此如今Deno的性能从官方的测试来看跟Node.js比仍是有一段距离，可是我的并不太担忧这一块性能差距，早晚也是会慢慢遇上来的，毕竟才1.0嘛。

前置知识

准备深刻Deno部分知识仍是要提早准备一下的：

• Typescript（对于前端开发大多没啥压力）
• Rust（主打安全和高性能的语言，学习曲线奇高，长期被编译器教作人）
• V8引擎（Isolate，Context，Handle等等概念常记内心）

不得不说，其实rust就是Deno和Node.js分界点，感受Deno的一个潜在目标就是把Deno的生态与rust的生态捆绑在一块儿，这样Deno一开始的生态比较弱的问题也能够获得一些缓解吧，另外对于前端来讲早晚也是须要学习一门静态语言的，rust也是一个不错的选择（rust但是StackOverflow最受欢迎的语言）。

Deno的架构

直接贴上官网的架构图：

这里官方的架构图还没来得及更新，libdeno已经替换成rusty_v8，这样意味着咱们开发native插件的时候能够彻底绕过了c/c++，直接使用rust就能够完成功能开发（加上rust自己自带一个可靠强大的标准库更加驾轻就熟），固然开发者仍是须要了解V8引擎相关的知识了。
再回到架构图上，咱们知道Node.js是由libuv提供调度和io的能力，那么在Deno上这个角色就由rust的Tokio库提供类似的能力，而一开始Deno仍是想使用go语言来提供这样的能力（Ryan果真是go语言的真粉），可是毕竟go语言也是带gc的（一个应用上同时跑两个gc，稳定性实在很难想象）并且性能上也是差rust一截，后面替换成rust也是至关明智的，另外Tokio其实对比libuv也是绝不逊色的（任务调度算法也是参考了go语言的实现）
另外在Deno里面js与rust的交互都会经过Deno.core.send和Deno.core.recv这两个方法，这样作对于应用作审计和权限控制是很是有好处，后面再会分析js和rust是如何交互的。最后例如js异步读取文件这些操做都会扔到Tokio线程池中执行，这也是Deno实现非阻塞的关键点。
而后Deno为了安全的缘由，对资源都作了一层映射，本来系统的文件描述符或者其余资源都映射成了一个rid（非零整数），对资源的操做都须要经过rid进行。

|                       **Linux** | **Deno**                         |
| ------------------------------: | :------------------------------- |
|                       Processes | Web Workers                      |
|                        Syscalls | Ops                              |
|           File descriptors (fd) | [Resource ids (rid)](#resources) |
|                       Scheduler | Tokio                            |
| Userland: libc++ / glib / boost | https://deno.land/std/           |
|                 /proc/\$\$/stat | [Deno.metrics()](#metrics)       |
|                       man pages | deno types                       |

好吧，把全部的概念聚集在一块儿，跟Linux一对比，就会发现Deno真的颇有意思了，难道是想要变成一个轻量级js应用平台吗？官方文档透露的信息实在太少了，感受一些设计意图也没有表达出来，但愿文档可以再详细一点就行了。

项目结构

.
├── cli //负责实现各类接口，包括兼容浏览器的和Deno.xxx
├── core //负责实例化和执行模块代码，处理js与rust之间交互还有实现event-loop
├── deno_typescript //负责编译打包typescript文件和生成v8的snapshot
├── docs //文档
├── std //std标准库
├── target
├── test_plugin
├── third_party
└── tools

本身再整理里面各个模块的依赖关系，大体以下：

固然发现更有趣的是std目录下还有有一个node的模块:

.
├── README.md
├── _fs
├── _utils.ts
├── events.ts
├── events_test.ts
├── fs.ts
├── global.ts
├── module.ts
├── module_test.ts
├── os.ts
├── os_test.ts
├── path.ts
├── process.ts
├── process_test.ts
├── querystring.ts
├── querystring_test.ts
├── tests
├── timers.ts
├── util.ts
└── util_test.ts

是否是看到这些文件名称就有一种至关熟悉的感受，嗯，这就是deno为了兼容node模块所作的一个兼容层，虽然尚未完成，不过至少也知道deno也是有这个意愿去兼容node的模块，或许在下一个版本咱们就能看到deno可以直接使用node的模块去开发应用了。

结束

暂时先介绍到这里，好像一点也没有深刻到代码，真的是标题党，哈哈，下一篇文章再来深刻代码分析。