模式 核⼼心 (Core) ⾏行为是 ThinkJS 扩展机制中⼀一项⽐比较关键的扩展，⾏行为可以独⽴立调⽤用，也可以整合到标签 (tag) ⾥里⼀一起调⽤用，⾏行为 是执⾏行过程中⼀一个动作或事件。如：路由检测是个⾏行为、静态缓存检测也是个⾏行为。 标签 (tag) 是⼀一组⾏行为的集合，是在系统执⾏行过程中切⾯面处调⽤用的。与 EventEmitter 不同，标签⾥里的⾏行为是按 顺序执⾏行的，当前的⾏行为通过 this.http.websocket; // 通过这个属性可以取到 WebSocket 对象，如：可以将这个对象存在⼀一个对象池⾥里，⽅方⾯面后续使⽤用（⽐比如：⼲⼴广播事件） } JavaScript 建⽴立连接后，浏览器和服务端就可以双向传输数据了。如： 这⾥里传输的 method 为 /websocket/message ，表⽰示对应的 url 为 /websocket/message JavaScript 服务端可以通过 echo ⽅方法向浏览器发送数据，如： 可以通过 end ⽅方法来关闭 websocket 连接。 如果浏览器端将 websocket 关闭了，服务端是可以捕获到这个关闭事件的。捕获需要在 openAction ⾥里进⾏行。 如果项⺫⽬目⾮非常复杂，需要⽀支持不同的数据格式，这时候可以使⽤用⼦子协议的功能。 如： 这⾥里表⽰示浏览器端⽀支持 json 和 soap

} }; 需要将配置 on 的值修改为 true，并重启 Node.js 服务。 事件到 Action 的映射 ThinkJS 里对 WebSocket 的包装遵循了 socket.io 的机制，服务端和客户端之间通过事件来交 互，这样服务端需要将事件名映射到对应的 Action，才能响应具体的事件。配置在 messages 字 段，具体如下： export default { adduser: 'home/socketio/adduser', //adduser 事件处理理的 Action } } 其中 open 和 close 事件名固定，表示建立连接和断开连接的事件，其他事件均为自定义，项目 里可以根据需要添加。 Action 处理 通过上面配置事件到 Action 的映射后，就可以在对应的 Action 作相应的处理。如： export default username, message: self.http.data }); } } emit Action 里可以通过 this.emit 方法给当前 socket 发送事件，如： export default class extends think.controller.base { /** * WebSocket 建⽴立连接时处理理 * @param

文件修改后，如果配置文件编译服务，那么会对文件进行编译，编译到 app/ 目录下。 根据配置 workers 来 fork 对应数目的 Worker。Worker 进程启动完成后，触发 appReady 事件。（可以通过 think.app.on("appReady") 来捕获） 如果文件发生了新的修改，那么会触发编译，然后杀掉所有的 Worker 进程并重新 fork。 如果是 Worker 进程 ，并注册定时任务服务。 加载 src/bootstrap/worker.js 启动文件。 监听 process 里的 onUncaughtException 和 onUnhandledRejection 错误事件，并进行处 理。可以在配置 src/config.js 自定义这二个错误的处理函数。 等待 think.beforeStartServer 注册的启动前处理函数执行，这里可以注册一些服务启动 createServer(port, host, callback) 来创建服务。 如果没有自定义，则通过 think.app.listen 来启动服务。 服务启动完成时，触发 appReady 事件，其他地方可以通过 think.app.on("appReady") 监 听。 创建的服务赋值给 think.app.server 对象。 服务启动后，会打印下面的日志： [2017-07-02

附录：包管理技巧  Addons 扩展插件  process 进程 o Event: 'exit' 事件：'exit' o Event: 'uncaughtException' 事件：'uncaughtException' o Signal Events 信号事件 o process.stdout o process.stderr o process.stdin pump(readableStream, writableStream, [callback]) o util.inherits(constructor, superConstructor)  Events 事件模块 o events.EventEmitter  emitter.addListener(event, listener)  emitter.on(event, listener) emitter.listeners(event)  emitter.emit(event, [arg1], [arg2], [...])  Event: 'newListener' 事件：'newListener'  Buffers 缓冲器 o new Buffer(size) o new Buffer(array) o new Buffer(str, encoding='utf8')

................................................................................... 3 EventEmitter 事件触发器................................................................................................ EventEmitter EventEmitter EventEmitter 事件触发器 事件触发器 事件触发器 事件触发器 Node 中的很多对象都会触发事件，例如：一个 TCP 服务器在收发每个数据流时都触发事件；子进程在退出时 会触发事件。 所有能够触发事件的对象都是 events.EventEmitter 的实例。 事件命名方式使用大小写分隔的风格。例如：'stream', 'data', 'messageBegin'。 可以将函数注册给对象，使其在事件触发时执行， 此类函数被称作‘监听器‘。 通过调用 require('events').EventEmitter， 我们可以使用 EventEmitter（事件触发器）类。 当向 EventEmitters（事件触发器）对象上注册新的时间监听器时，都会触发'newListener'事件。 当事件触发器过程中出现错误时，典型的处理方式是它将触发一个'error'事件。 Error

云端一体，即点即用 8 技术 模块化、NaZve互调、事件模型 Node.js的不足 作为JavaScript虚拟机还不成熟 (缺少完整的libcore) ？ 9 与V8强绑定，解耦或升级很困难 (naZve调用强依赖V8接口) ？ CPU密集的计算场景中存在性能问题 (单线程，事件驱动，GC效率低) ？ Node.js在YunOS中的最佳实践 js在YunOS中的最佳实践 10 对IO优先的Looper机制的改造和优化 难点： 1. Node.js的消息循环机制完全由IO事件来驱动 2. 终端设备的场景在UI渲染及非IO任务的及时响应的需求 Node.js的消息循环: 11 Pending Queue AcZve Queue task task Node.js Queue uv_async_t YunOS对Looper改造的实践 1. 系统任务与Node.js的IO任 务融合，两者地位基本平等， 系统任务优先级略高 2. 系统任务通过异步事件接 入Node.js的队列中 12 SAB + Worker机制的实践 YunOS对多任务的需求： 1. 安全沙箱对多进程的限制(不能使用多进程) 2. 实际应用以计算为主(CPU密集)，对多任务并行有需求 3. 并行任务在通信上的性能要求

2018.06 背景: 1. 基于最初的开发，我创建了了并管理理 Node。 2. 我的主要关注⽬目标是事件驱动的 HTTP server。 3. 这⼀一主要⽬目标对当时服务器器端的 JavaScript 起着关键作⽤用。即使在当时这⼀一点不不 那么明显，但是服务器器端 JS 的成功需要事件循环的助⼒力力。 背景: 2012 年年我离开 Node 项⽬目的时候，当时我觉得 Node（或多或少）实现了了我的预定