许愿墙总结文档

技术选型

前端:

Angular
优点:声明式 UI、完善的指令系统、双向数据绑定、模块化、依赖注入、完整的 MVC 以及可以自定义的指令
缺点:自带的路由模块功能比较弱,需要依靠第三方的 uiRouter,整体较笨重,不适合做交互频繁的网页,对于一个页面显示数据量较大的网页性能优化是一个问题,还有就是对 SEO 不友好。

后端:

Node.js
优点:事件驱动以及非阻塞的异步 IO 使它能够很好地应对高并发场景,适合做 IO 密集型的应用
缺点:JS 的单线程限制使其很难利用服务器的多核资源,可靠性较低,一旦挂了就整个服务都崩溃了

数据库:

MongoDB
优点:文档结构的存储方式,能够更好地管理数据,查询速度也更快,也能够减少磁盘 IO;JSON 风格的语法易于理解和掌握
缺点:不支持事务操作,占用空间较大(为避免产生磁盘碎片),删除记录后并不释放空间(为了避免大规模的数据移动)

其他:

静态资源存储使用七牛云存储
实时消息的推送和实时消息传递使用 socket.io
后端使用 Express 框架
开发环境配置使用 Gulp
部署环境使用 BAE

技术难点

1. 如何把图片上传到七牛的过程跟微信 SDK 中的上传图片过程连接起来

问题背景
因为要把愿望的图片保存在七牛的服务器上,虽然七牛有自己的上传组件,但是那个上传组件点击后出现的是选择所有类型文件的界面,我希望上传图片的时候是那种选择相册或拍照的方式,也就是微信 SDK 提供的选择图片接口那样的功能,此时的难点在于怎样把通过微信 SDK 选择到的图片传给七牛。
解决方案
利用了微信 SDK 提供的上传图片接口和七牛的 fetch 接口,当微信选择了图片之后就把图片上传到微信服务器上,上传成功后会返回一个图片的下载链接,然后再用七牛的 fetch 接口向这个下载链接发送请求,获取到图片文件,然后存入七牛空间。

2. 微信无故循环报 access_token 40001 错误

问题背景
许愿墙最后一天的时候男女功能反转,会出现一波用户请求的高峰,在 access_token 过期后,有多个用户同时请求了新的 access_token,access_token 在传输回服务器的过程中由于网络原因导致 access_token 返回的先后顺序跟请求的先后顺序不同,造成服务器缓存的是一个微信服务器不承认的 access_token(因为新请求的 access_token 会把前面的 access_token 覆盖)。
解决方案
增加错误处理,出现问题后清空 access_token 的缓存,然后重新请求新的 access_token。

3. BAE 多个执行单元导致 soket.io 报错

问题背景
这个问题相当于开了多个 node 进程后 socket.io 的消息分配问题,由于有多条进程在运行后台,当有实时消息请求但此时通信双方请求的是不同进程的时候会导致 socket.io 报错。
解决方案
为了解决这个问题,我使用 redis 做了一个事件订阅/发布模型,多个服务器进程订阅发布进程,然后由发布进程统一处理所有的实时请求。

不足之处

  1. 代码的优化不够,对 Angular 和 Node 掌握不够导致很多优化技巧没有用上;
  2. 前期的规划不足导致开发中经常要对之前的代码进行重构;
  3. 权限控制做得不好,没有花时间在这方面;
  4. 开发节奏不够好,难以掌控进度。