精选_基于JSP的聊天器_源码打包

# 基于JSP的聊天器 # 1 可行性研究 ## 1.1 技术条件方面的可行性 - 系统：Windows 8.1 Update - 服务器环境：nodejs 0.10.29 - 服务器包管理器：npm - 前端js包管理器：bower - 服务器语言：CoffeeScript - MVC框架：Express 4 - 数据库：MongoDB - ORM框架：Mongoose - 模板引擎：ejs - Web Socket实现解决方案：Socket.IO - 单元测试框架：Karma - 前端页面语言：HTML5 - 层叠样式表语言：CSS3、LESS - 页面脚本语言：Javascript、CoffeeScript - 页面开源框架：Angular.js, JQuary, Bootstrap - 版本控制软件：Git - 版本控制服务：Github - 数据库托管平台：Mongohq - 项目托管平台：Mopaas云 - IDE：JetBrain Webstorm - 编辑器：Sublime Text 3 ## 1.2 可行性分析 本项目作为即时聊天平台，是一个典型的Web App，作为Single-page Application展示可以获得较好的效果。 网页即时通讯主要需要解决的问题是长连接、动态数据绑定以及大量并发访问。 本项目拟使用WebSocket的一个实现Socket.IO以及AngularJS库解决这两大问题，通过这两个工具的搭配使用，可以较好满足SPA6大特点。 Node.js作为单线程异步实现，搭配V8引擎JIT编译的高效，在1000并发条件下满足系统稳定运行是可行的。 # 2 需求分析 ## 2.1 概述 即时聊天平台主要满足的是较大规模用户的同时在线互动需求，并且用户需要实时收到全部消息，显示在窗口中。用户发送的消息，也需要实时广播到其他用户的浏览器端。 ## 2.2 功能需求 - 网站可以注册和登录 - 进入系统后，用户可以修改自己的昵称以及登录密码 - 用户可以看到当前在线的所有用户名单 - 用户可以搜索过滤当前用户 - 用户可以实现和其他用户的即时聊天 - 聊天内容是可以被搜索过滤的 ## 2.3 非功能需求 - 界面美观，操作简单，拥有流畅的用户体验 - 在大规模并发条件下依然保持高速响应 # 3 设计说明 本项目使用AngularJS库作为前端MVVM框架，后端Express以及ejs模板只作为静态服务器以及RESTFUL服务器使用，渲染出基础html页面并给出API接口。 ## 3.1 后台设计 后台数据分两部分，常规AJAX数据使用RESTFUL接口供前端使用。即时长连接数据，即用户聊天相关的用户名单更新、上下线、即时聊天数据等等，则通过Socket.IO发送广播数据触发AngularJS应用更新。 ## 3.2 前端设计 前端动态数据完全使用AngularJS进行数据绑定，通过后台实时改变的$scope对象，实时通过ng- 标签对前端显示数据进行绑定。   ## 3.3 界面设计 **登录界面**  **新用户注册界面**  **应用主界面**  **修改密码界面**  **实时聊天界面**  # 4. 压力测试 ## 4.1 测试环境 - 网络环境：内网 - 压力测试服务器： - 服务器系统：Linux Ubuntu 14.04(Vmware虚拟机) - 服务器配置：Intel(R) Core(TM) CPU i5 2430M 2.40GHz 2 CORES - 内存：4GB - 发包服务器： - 发包工具：apache 2.2.19自带的ab测试工具 - 服务器系统：Windows(R) 8.1 简体中文企业版 64bit - 服务器配置：Intel(R) Core(TM) CPU i5 2430M 2.40GHz 4 CORES - 内存：8GB # 4.2 参数 >url: / >并发：1000 >次数：10 ## 4.3 结果(后续测试不再注释) >This is ApacheBench, Version 2.3 <$Revision: 655654 $> >Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ >Licensed to The Apache Software Foundation, http://www.apache.org/ >Benchmarking localhost (be patient) >Server Software: >Server Hostname:localhost >Server Port:80 >Document Path: / >Document Length:4017 bytes >Concurrency Level: 1000 >/* 整个测试持续的时间 */ >Time taken for tests: 36.869 seconds >/* 完成的请求数量 */ >Complete requests: 10000 >/* 失败的请求数量 */ >Failed requests:0 >Write errors: 0 >/* 整个场景中的网络传输量 */ >Total transferred: 43235848 bytes >HTML transferred: 40170000 bytes >/* 每秒事务数 ，mean 表示这是一个平均值 */ >Requests per second:271.23 [#/sec] (mean) >/* 平均事务响应时间 ，mean 表示这是一个平均值 */ >Time per request: 3686.857 [ms] (mean) >Time per request: 3.687 [ms] (mean, across all concurrent requests) >/* 平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题 */ >Transfer rate: 1145.22 [Kbytes/sec] received >/* 网络上消耗的时间的分解 */ >Connection Times (ms) > min mean[+/-sd] median max >Connect:00 10.0 0 508 >Processing: 188 3570 649.5 37324442 >Waiting: 12 155 447.6 182287 >Total:188 3570 649.6 37324442 >/* 整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中 50 ％ 的用户响应时间小于 3732 毫秒， 66 ％ 的用户响应时间小于 3094 毫秒，最大的响应时间小于 4442 毫秒 */ >Percentage of the requests served within a certain time (ms) > 50% 3732 > 66% 3782 > 75% 3816 > 80% 3830 > 90% 3926 > 95% 4069 > 98% 4105 > 99% 4125 > 100% 4442 (longest request) ## 4.4 结论 本测试在36.869s内完成了10次1000并发测试，所有响应均全部完成，没有失败请求。其中50%请求在3.7s内完成，最长请求时间为4.4s，考虑到服务器性能以及环境，该结果被认为是可以接受的，所以我们可以认为本系统在1000并发情况下是可用的。 # 5 总结 根据大作业的要求，需要制作一个满足6点要求的Single-Page应用，实际上也就是实现了一个Web App。我的第一反应是做一个天气应用，因为之前也做过手机端的此类应用。并且天气数据可以通过开放平台获取，十分方便。之所以最终没有选择，其原因有二：一是天气应用不适合使用Socket，因为完全不需要建立长连接，二是天气Web App对于UI表现要求比较多，而我对于CSS方面并不是很擅长。 那么不妨从需求来考虑，既然想完整实现这6点，那么就从使用范围最低的Socket入手，需要Socket的无外乎实时或者大量连续通信。做游戏肯定不行，那么最适合的也就是即时通信了，也就是IM。 确定了需求，下一步就是技术选型。既然一定要做，那不如用点新东西练练手。所以最初后台是准备用Golang或者Python。最终之所以还是选择Node.js其主要原因还是Socket。目前WebSocket最好的实现——Socket.io还是更适合Node平台。此外因为这个项目也主要是前端技术，相对后台不是那么重要。继续尝试对js增加了解也没什么不好。毕竟js这门语言，真的是越了解越觉得它的深奥。 后台OK了以后（当然数据库、ORM框架之类的选择也是顺其自然的，所以不表），就是更加重要的前端框架。UI使用Bootstrap不用说，MVVM以及模板框架才是重头戏。在花了2个小时查阅各种文档后，最终选择了AngularJS。 下面谈谈为什么。首先前端框架主要是解决这几个问题：数据绑定、前端模板、MVVM、路由。既然我都需要用，那么这些能用