【BUAA软工】技术规格说明书
| 项目 | 内容 |
|---|---|
| 班级：北航2020春软件工程 | 博客园班级博客 |
| 作业：技术规格说明书 | 技术规格说明书 |
宏观技术
后端
WEB服务器
WEB服务器选取的是Springboot，作为当下Java语言最主流的WEB框架，这款技术基本上能够支持整个项目技术栈的整合
数据库
数据库选取的是Mysql，暂时不考虑缓存数据库，因为在这个项目中，数据库并不是性能瓶颈。
分布式框架
选取的是Zookeeper+Dubbo，这两项技术原生支持Spring的整合，同时文档全面、社区活跃、功能完备，负载均衡策略可自定义，同时也提供内置几款策略，易于使用。
容器技术
为了便于隔离用户环境，后端选用docker作为容器技术，docker性能较优，同时有官方集群部署方案，十分适合本次项目的应用场景
部署环境
本次项目因为要支持多用户，多环境，无论是对存储空间还是计算能力都有一定的要求，但目前缺少已有测试数据，所以还暂时不能确定最优的结点个数。
但初步计划使用6台服务器，分配为1台负载均衡服务器，1台数据库服务器，2台docker管理服务器，2台docker运行服务器，考虑到未来横向扩展的需求，项目中的设计都为横向扩展预留了接口，从而可以随时进行结点的调整。
前端
前端框架
前端框架使用vue.js进行组织，将前端页面分成各个模块，用不同的vue进行组织；将一些经常用到的函数抽象成模块写在js里
UI框架使用view-ui（原iview）进行设计，部分模块可能需要借助外部其他开源模块。
前后端通信
前后端通信分两条通道进行：基本的数据交互用http协议沟通，terminal的交互使用websocket沟通。
web terminal
前端web terminal使用xterm.js实现，和后端用websocket进行交互
编辑器
编辑器使用Monaco编辑器，作为一个子模块由前端其他模块进行管理，沟通。
产品基础功能设计
架构和接口
项目基本架构
前后端沟通http API
| 请求方法 | 请求路径 | 请求参数 | 用途 |
|---|---|---|---|
| POST | /user/auth | user_id, password | 用户名密码验证 |
| POST | /user/register | user_id, user_name, password | 注册事件 |
| POST | /user/info_update | user_name, password | 账户信息更改 |
| GET | /user/info | 账户信息查询 | |
| GET | /project/info | 获取账户所有工程信息 | |
| POST | /project/new | project_name, project_type | 创建工程 |
| POST | /project/enter | project_id | 进入项目 |
| GET | /project/file_struct | 获取目录树 | |
| GET | /file/content | file_path | 文件内容读取 |
| POST | /file/update | file_path, file_content | 文件内容修改 |
| POST | /file/new | file_path | 新建文件 |
| POST | /file/delete | file_path | 删除文件 |
| POST | /file/move | old_path, new_path | 文件名称修改/移动 |
| POST | /dir/new | dir_path | 目录创建 |
| POST | /dir/delete | dir_path | 目录删除 |
| POST | /dir/move | old_path, new_path | 目录移动 |
| POST | /debug/compile | file_path_list | 项目编译 |
| POST | /debug/run | command | 运行命令 |
返回前端数据的json格式如下：
{
"code": 0, // 返回值，0代表成功，其他值代表相应错误
"message": "response message", // 返回信息
"data": { // 返回数据
// return data
}
}
分析
抽象
在该项目的后端设计中，我们将诸多具体功能抽象为了泛用功能来供前端调用，只提供最基础的完备指令来供前端完成各种具体功能。
例如，在后端只提供类似文件保存、文件下载、文件重命名等功能接口，而这些接口已经能够满足前端实现所有功能的需求。前端可能需要添加新的功能，但是这套接口是泛用的，所以前后端不会耦合在一起，后端的接口始终保持稳定，同时前端依然持有实现上的灵活性。
前端的设计中，同样也采用类似的抽象方法。
对于和后端进行http交互的各种信息，前端计划将这些交互抽象成各个函数，并且设置回调函数参数。前端各个模块想要和后端进行相应的交互时，主需要调用这些交互函数，并设置好回调函数即可。接口设计形式类似如下：
function create_file(file_path, callback) {
/* function content
* ...
*/
callback(data) // function call back
}
内聚/耦合/模块化
在后端的设计中，MVC设计模式的应用使得后端本身就高度解耦，不同的Controller之间没有依赖关系，呈平行结构。
同时，将不同的功能模块进行分类，如身份验证、文件管理等多个模块，使得各个模块之间没有依赖，整个项目模块化，即使有新的功能需求出现，依然可以增加模块做横向扩展。
前端设计的模块化就更加显然了：
- 对于一个页面的设计，可以将页面的各个部件抽象成各个子模块，使用不同的vue进行实现。
- 使用一个页面vue，将各个子模块进行拼接。
- 子模块之间的通信可以使用
$emit的方式进行通信，主要注册好对应的交互函数，就可以实现功能上的对接
这种方式的设计，当后续需要增加功能时，仅需要在对应的子模块接口中新增沟通函数即可，扩展方便。
信息的隐藏和封装
首先是后端方面，在这个项目中，后端基本上是无状态的服务器，也因此免去了很多有状态服务器的状态维护方面的问题，本身就不存在过多的信息传递。
而关于前后端交互方面，我们指定了一套完整的API接口，前端的任何调用只需关心结果，而后端也只会将前端所需要的结果返回，任何服务器内部的多余信息不会被前端感知。前端仅存储渲染页面需要的信息，因此信息的隐藏依赖与后端设计。
界面和实现的分离
在这里，我们指定了一套后端的API接口，任何平台对该接口的访问结果都是一致的，始终呈现的是数据界面，而无关具体实现，后端只关心入参和返回值，而不必关系前端如何使用这些信息。
而前端只需关心传参和API的返回值，然后根据返回值进行相应的处理，即使平台更换，后端的API依然保持不变，请求方式依然不变，返回值依然不变，前端只需使用返回值中的数据即可。
如何处理错误
首先，我们的整个API是属于内部API，前端开发人员有义务做到正确地使用API
同时，在API的设计中，我们也针对错误情况做了处理，当服务器端处理请求出现错误时，会将错误信息而非数据返回前端，根据返回的错误信息，前端可以进一步进行相应的错误处理和漏洞修复。
关于前端的错误处理，会将所有的错误码事先进行设定，在对应模块需要错误处理时根据错误码来识别相应错误来进行处理。
应对灵活变化
上文提到了，首先，我们的API是稳定的，所以面对前端实现的更换，例如，小程序、客户端等，我们的API都无需改变，可以维持稳定。
同时，我们的设计时扁平化的，多个功能模块之间没有依赖，这使得面对新的功能需求，我们只需新增对应的功能模块就可以满足新的需求。
对大量数据的处理能力
这个项目，后端主要有两个并发瓶颈，一个是请求的分发和处理，一个是实际容器内运算。
首先是请求的分发处理。
这里我们采用了Dubbo+Zookeeper的分布式服务提供方式，正如上文说到，我们的后端是无状态后端，所以具有使用这种方式的天然优势。
然后是实际容器内的运算。
这里实际上只能依靠硬件升级，因为每个用户的一个工作区对应一个docker容器，这个是无法做横向或是纵向扩展的，唯一能做的就是硬件升级来支持容器内更快的运算能力。
