在线客服系统C109个人总结

引言

经过两个多月的开发，软工3的大作业工程终于接近尾声。在5个迭代的开发中，不断的发现问题、解决问题，学习了许多新的知识，团队成员间不断磨合，确实令人难忘。

迭代开发

曾经完成的大作业无论是单人作业还是小组作业，都只规定了一个deadline，只要在ddl之前完成即可，大多数时候都是ddl驱动，临近截止日期再加班加点地完成。这是第一次对过程要求的非常详细的作业。整个开发过程分成了5个迭代，每个迭代持续2周，将整个大作业的完成划分到了10周之中。

说不上喜欢与否，但确实是一种全新的体验。经过这么久我也不得不承认这项大作业不是突击一周两周就可以完成的。

团队协作

4人协作的团队说不上有多大，但也不像2人小组那样可以直接简单的讨论、开发了。版本管理工具的使用相当重要，我们小组的Gitlab是由我来维护的。最开始的时候对Git的使用很不熟练，因为缺少.gitignore而导致不得不删除第一个迭代的提交记录。许多命令在使用时都需要去网上查，不过后来都记在了一个专门的文件里。

成员的分工协作也颇为滞涩，虽然尽量的做到前后端分离，但仍然没能避免进度上的阻塞。由于缺少协作经验，这方面确实需要加强。

系统重构

系统重构可以说是最让人头疼的事情。起初在选择django和mysql作为后端的时候，查找到可以使用dwebsocket进行通信，然而并没有进一步的研究。真正实现时才发现，由于wsgi协议的特性，只有在runserver时websocket才能正常工作，使用uwsgi和nginx部署到服务器上之后实际上websocket无法正常工作。

因此，通讯部分的代码需要整体重构。最终我选择了django-websocket-redis作为通讯模块的核心。这也直接导致redis不得不介入django的部分。于是顺带着添加了redis的缓存机制，并利用其作为辅助数据库。这方面踩了许多坑，我记录在了我的另一篇博客 Django|Nginx|Uwsgi|Redis|Websocket配置、使用与部署 中。

定时任务

在django本身并不支持定时任务，需要引入celery来实现。在作业之初我就已经知道了这个情况，但实际使用还是超出我的预料。

由于上一段讲的，通信模块进行过一次重构。但是，虽然这个django-websocket-redis模块已经相当优秀，可以实现大多数需求，但是仍然一定程度的受到了django和wsgi协议的限制。

最大的问题在于，无法在websocket连接中断时通知后端，也缺少一个简便的接收websocket信息的途径（相反的，发送websocket信息是很方便的）。这就导致了一个严重的问题：当客服或者用户失去了网络连接（失去TCP连接，而不是关闭页面）时，其状态仍以在线状态被维护。而对于websocket信息的接收太过复杂，所以最终使用post请求来维持一个存活时间戳，使用celery定期检测，并将存活时间戳太久未更新的账号判定为下线。

同时，celery还被用于每天、每月清空统计数据，因为有部分统计数据是按周期进行计算的。

所以celery在我们的工程中是必须的。由于在曾经的后端小学期使用过celery，所以起初并没有什么困难。然而当部署到服务器上时，发现celery本身并不能作为守护进程执行。而是需要在celery工程的github上下载脚本自行配置运行。这部分详细内容我记录在了我的另一篇博客 Django|Redis|Celery 配置与部署 中

配置过程中又发现celery虽然可以将redis作为broker运行，但是却无法设置通过unix域套接字通信，这导致我不得不将redis的配置改回TCP。

结语

完成这个大作业收获颇丰。从课上听到了许多专业知识，但是只有亲自实践之后才能体会到这些方法的意义所在。

想来这应该是我这四年印象最深刻的大作业了。