基于nodejs的小型框架设计与实现毕业设计

基于nodejs的小型框架设计与实现毕业设计内容摘要：

用异步式 I/O 与事件驱动的架构设计。 传统架构对于高并发的解决方案是采用多线程模型，也就是一个系统线程处理一个业务逻辑，通过系统线 程切方式弥补同步式 I/O 的时间开销。 采用的是单线程模型通过异步式的请求方式处理 I/O 调用，减少了切换上下文次数所造成的开销。 运行的过程中将管理一个事件堆栈，不断地循环执行事件然后等待下一个事件的触发。 异步式 I/O 请求完成后将被推送到事件队列，等待主进程进行处理。 基于事件的异步处理机制的 对于所有的网络通信、磁盘读写、数据库操作等都以异步请求的方式实现，最后将执行得到的结果交给事件循环进行处理。 下图 描述了这个机制。 图 进程在进行事件处理时具有时间的唯一性，它不会同时处理多个事件请求，在处理完一个事件后就进程就进入下一个事件循环，检查并继续处理后面的 第 3 页 共 62 页 事件。 这样做优点在于能够集中 CPU 和内存资源快速处理某个事件，并且尽量让耗费资源的 I/O 操作并行执行。 在应对恶意访问方面， 对于低速的 DOS 攻击， 只增加事件堆栈中的请求请求树立，而不会马上给出请求应答，这样有效的减少了线程资源的开销，很大程度上提高了 Web 应用的健壮性和安全性。 由于 采用事件驱动与异步式 I/O 代替多线程，较大幅度的提升性能。 此外 除了使用 Google 的 Chrome V8 作为 JavaScript 引擎，它还使用了高效的 libeio 和库 libev 支持事件驱动和异步式 I/O。 架构的示意图如下 图 12 设计 的开发者从 libev 和 libeio 库中进一步封装出来出 libuv 层。 在 Windows 下， libuv 使用了 Windows 的 IOCP（ Input/Output Completion Port，输入输出完成端口）机制，实现高性能，而对于 Linux、 UNIX,Mac OS X 等操作系统， 的 libuv 库通过使用 libeio 和 libev 的封装来利用 kqueue 或 epoll。 以上简单介绍了。 那么为网络而生的 能够做一下事情。 (1)大规模的社交网络 Web 应用，如微博， FaceBook 等。 (2)具有复杂逻辑的网站；如一般的 MIS系统。 (3)Web Socket 服务器；如游戏引擎。 (6)TCP/UDP 套接字应用程序，即时通信 系统； 第 4 页 共 62 页 (7)客户端 JavaScript 编译器。 由于 具有以上优点，所以对于 web 应用来说 是优秀的开发平台。 平台的非擅长领域 一个优秀的平台能够吸引大量开发者的关注。 有许多传统架构不具备的优点，以至于开发者愿意用 来做应用开发。 但是 与其他任何平台一样，都存在优点和缺点，如果非要使用它的缺点来完成业务需求，那么同样会遇到困难和僵局。 尽管它是高性能的，新颖的，但也不得不写出难以理解的逻辑代码。 与大多数新语言平台本质 一样， 也是旧瓶装新酒。 只不过概念比较新潮 ,它不能完成所有的业务逻辑，或者说它不是万能的。 前一节提到 的平台优点，本节则简要介绍下 的短板所在。 （ 1）多任务的单用户应用 前面介绍的都是服务器端编程，设计时的情况是用户数量很多。 但如果面对的是单用户，譬如本地的命令行工具或者图形界面，那么就不存在所谓的大量并发请求。 于是另一个问题出现了，尽管是单用户，却不一定是执行单任务。 例如在给用户提供界面的时候后台需要进行某个计算，为了使用户界面不出现阻塞状态，不得不开启多线程或多 进程。 而到目前为止 的线程或进程之间的通信还不方便，因为它根本没有资源锁，所以号称不会 死锁。 多进程的 往往是在执行同一任务，通过多进程利用多处理器的资源，但遇到多进程相互协作时， 的短板就出现了。 （ 2）编码与国际化 不支持完整的 UTF8 字符编码，很多字符无法用 string 表示。 实际上来说这不是 本身造成的，问题而是出在 JavaScript 标准上。 目前JavaScript 支持的是双字节的 UCS2 字符集，即两个字节来表示一个 Unicode 字符，这样能表示出来的字符数是 65536。 明显，汉字就不止这个数目。 因此无法表示某些生僻汉字，以及一些较为罕见语言的文字。 这是设计的问题，源于当时设计者的主观判断。 最初的 Unicode 设计者认为 65536 个字符足以表示全世界所有的文字，因 第 5 页 共 62 页 此那个时候兼容 Unicode 的系统或平台，如 Windows、 Java 和 JavaScript 在后来都遇到这个问题。 随后 Unicode 意识到用 2 个字节表示所有字符是远远不够的，随后推出了 UCS4 编码，即用 4 个字节来表示一个 Unicode 字符。 原有的定长编码的UCS2 系统为了变长的 UTF16 编码进行了升级处理，所以只有它向下兼容 UCS2。 UTF16 编码采用定长的双字节编码处理 UCS2 以内的字符，对于以外的部分则使用多字节的变长编码。 这样在通常情况下它的编码是定长的，有利于提高运算效率并且且兼容了 UCS2 编码，缺点是它本质还是变长编码，在应用程序中处理起来还是存在不便之处。 JavaScript 当下支持的仍是定长的 UCS2 编码 而不是 UTF16，因此对于处理使用 UCS4 进行编码 的字符无能为力。 这个缺陷存在于现有的所有 JavaScript 引擎。 包括 Chrome的 V8 引擎在内。 因此你无法处理罕见的字符的时候，想用 实现一个多语言的字典工具是不可能做到的，除非放弃使用 javascript 原有的 string 数据类型，将所有的字符当作二进制的 Buffer 数据来处理。 （ 3）复杂逻辑的事务 的控制流是非线性的，它由一个个事件响应组成，但人的思维却是线性的，当试图转换思维来适应语言或编译器时，就得付出性能或者编码方面的代价。 举个例子，如要实现以下逻辑：从银行取钱，用钱去购买一个虚拟商品，买完以后加入库存数据库，这中间的任何一步都 会涉及数十次甚至更多的的 I/O 操作，而且任何一次操作失败以后都需要进行回滚操作。 这个过程是复杂的线性的，假如拆分为非线性的逻辑，那么其复杂程度将提升几个数量级。 更善于处理那些逻辑简单但访问频繁的任务，而不适合完成逻辑十分复杂的工作。 （ 4）需要大量计算的程序 （在 版本以前）不支持多线程。 的设计者和追随其的开发者坚信单线程和事件驱动的异步式编程比传统的多线程编程运行效率更高。 但实际上多线程通过较大的开销也能达到同样的吞吐量，而且不必为多核环境进行特殊的配置。 对 比而言， 其单线程性的特性，如果需要充分利用多核资源则需要使用多进程的方法才能达到 理想情况下的单线程执行过程会将 100%利用 CPU 核心资源，所有请求须等待当前请求处理完毕后才进入事件循环才能响应。 如果应用是需要进行大量的 第 6 页 共 62 页 计算除非人为地分开计算，否则将会有相当大的请求响应延迟。 不过在实际使用中的 Web 服务器中，很少需要大量计算的部分很少，即使存在，那么不应该被实现为即时的响应。 一般的处理办法是后台处理完成后给前台客户端异同处理完成的通知。 开发框架的原因 刚推广不久，国内还缺少使用 做应用开发的框架。 只提供底层的 接口。 缺少丰富的上层应用接口。 直接使用底层接口做开发需要分析大量的 协议内容。 对于开发效率有着严重的制约。 基于此点，本论文开发设计一个简单小型的 MVC 框架，简化 的使用难度的同时提高开发效率。 目前 web 应用中，普遍使用了 MVC 模式（即 ModelViewController,模型，视图，控制器）。 如基于 JAVA EE 的 Struts2 + Spring3 + jsp MVC 模式等。 借鉴 这些其他平台上现有的框架结构和功能，设计开发 FastJsonWeb 框架。 本框架将封装 的底层接口，对请求数据等提供统一简洁的方式，从而较大幅度的提升开发效率。 基于对不同平台现有框架分析提取出本框架的功能点。 这些功能点包括 路由转发与映射，属性注入， Cookie 实现， Sesison 实现等。 小型的 MVC 框架意味着该框架应具有易用性和高效性，能够很大程度上满足大多数业务的逻辑。 在现有的已存在的 Node 的 MVC 框架中，如 Express,已经能够满足大多数业务逻辑 ，但是因为是 国外开发，其文档资料大多数是英文编写，需要高昂的学习成本，而且大多数功能对于一般的应用是冗余的，加之配置复杂，遇到问题无法得到有效快速的解决途径，贸然采用存在大的风险。 而自己开发，虽然时间周期长但因为其可重用性，还是具有较高的价值。 由于平台的新颖性，多数 API 还处在变化之中，因此设计开发该框架主要存在以下一些问题。 (1) 还处于高速发展阶段， API 不稳定，处在不断更新变化中，如果采用某个固定版本，则可能存在 bug 或者无法使用新特性。 如果跟随版本变化则框架的稳定性无法保证。 第 7 页 共 62 页 (2)。 主要表现在两个方面 ,一是新平台国内研究使用的人暂时不多，遇到问题无法立马得到咨询有效的解决。 二是缺乏中文资料，有关资料只能去 的官方文档查询而且是英文。 问题的交流只能在 Stack Overflow 等国外论坛但是是英文环境，交流存在一定的困难。 (3) 对于 Window 平台支持不是好，一些常用工具无法安装。 缺乏良好的桌面开发环境，对于类 Unix 系统的使用，如 Linux 的发行版 Ubuntu 有生疏性，无法得心应手。 (4)缺乏有效的开发工具。 如今不管哪个系统平台下， javascript 开发 IDE 都很少，或者难以使用，缺乏有效的调试工具，编码效率得不到提高。 （ 5）由于 基于事件驱动和异步 I/O,对于业务逻辑的处理往往不同于一般线性编程，难以打破线性编程的思维僵局。 （ 6） 封装性非常低，对于一些常用操作，如 Cookie,Seesion 等都需要根据 Http 头信息重新实现，难度较大。 （ 7）目前没有任何一个官方文档规定 的代码风格，为了保持框架代码的可读性和可维护性，需要定制某一标准，方便今后的维护。 以上七点主要是分析了 平台存在 的不足和一些设计实现的困难之处。 该章简单的介绍了 平台架构，使用 的局限性和其优点以及框架进行设计与开发存在的难点。 第 8 页 共 62 页 第二章 开发工具及技术综述 本章主要是介绍框架设计与实现过程中主要使用到的设计工具、开发工具、开发平台以及 javascript 的一些高级语言特性。 工具有 vim 和 git，平台主要是 github与 Ubuntu。 除此以外，还将介绍在 Ubutun 下如何搭建 开发平台。 文本编辑器 Vim 简介 Vim 是从 vi 发展出来的一个文本编辑器。 具有代码补全、终端编译及错误跳转等提供编程效率的功能。 Vim 在程序员中被广泛使用，与 Emacs 并列成为类 Unix 系统用户最受欢迎的编辑器。 设计理念 vim 的设计理念是组合。 包括命令组合和模式间的组合。 命令组合 : Vim 强大的编辑能力中很大部分是来自于其普通模式命令。 vim 的设计理念是命令的组合。 例如普通模式命令 dd删除当前行， dj代表删除下一行 ,因为是第一个 d含义是删除 ,j键代表移动到下一行 ,组合后 dj删除当前行和下一行。 类似的命令 组合非常丰富，只要拥有足够的创造力就可以灵活的组合各种命令进行使用，这样就能更加高效的进行文本编辑。 vim 针对程序语言代码编写者。 写代码的时候手需要时刻保持在键盘上 ,随机定位代码、随机删除代码、移动代码、插入代码的操作大大多于阅读、翻页操作，中间卡顿一下效率就大大降低了。 但对普通用户而言 ,顺序写、设置字体格式、翻页读多于随机写删除操作 , 且每个动作之间本身就有很多的停顿 ,用其他 UI 编辑器(word,notePad++等 )效率反而比 VIM 高效 ,使用 vim 进行操作只会徒增代码编写的难度。 主要功能： 第 9 页 共 62 页 全兼容 vi ，分成多个编辑视图 6. 文本编辑历史记忆功能 三种编辑模式 Vim 编辑器具有三种模式，分别是常规模式，插入模式，命令模式，如下图 所示 图 Vim 三种模式的相互转换如下： 常规模式进入命令模式： 在常规模式下输入“ :” . 常规模式进入插入模式： a 光标后插入文本 A 当前行插入文本 i 光标前插入文本 I 当前行 前插入文本 o 当前行的下边插入新行 O当前行的上边插入新行 第 10 页 共 62 页 s 删除光标所在处字符，并进入插入模式 S 删除光标所在的行，并进入插入模式 插入模式进入常规模式：按下 ESC 键即可。 其中插入模式和命令模式之间无法直接转。