[项目总结] 为某银行开发一个开业线上活动的H5网站

0x00：写在前面

甲方给出的大致需求是做一个移动端 H5 的活动网站，需要实现微信登录、在线点播视频，抽奖、奖品发放等功能，但距离甲方的活动上线的时间只有7天左右，所以还需要考虑是否能在这个时间区间内实现所有的需求。

经过需求的梳理以及参考类似的产品过后，得出可能会遇到一些难点（没有动手实现过的需求）例如对接一些微信的API、视频在线点播、微信红包自动发放等。但这些都是在可以接收的范围内的，查文档查案例，边学边做，顺便也可以将近期所学得的知识点用在该项目当中来。0x02：需求分析

甲方给出的活动流程如下：

1. 前三天进行推文和长图传播，最终弄实现形式是H5（包括微电影+抽奖）
2. 三天三部微电影，观看完整视频后可获得一次（仅有一次）抽奖机会，奖品大多数是红包
3. 并生成二维码进行分享传播，别人扫你的二维码可增加人气值和最多一次的抽奖机会
4. 人气值在最后一天体现，每天的H5要有人气值的排行榜。
5. 第四天做答案揭晓，并在朋友圈做广告推广（推广这块由另一位老板负责）根据排行榜抽取最终的大奖

开发周期：7 天时间实现所有需求，第 8 天早上上线，活动持续 4 天时间，第 11 天下午活动结束。

0x03：需求整理

1. 用户点击【开启新起点】按钮，浏览企业信息
2. 观看一部微电影视频，观看结束后提示用户获得一次抽奖机会
3. 抽奖成功，显示当前的抽奖结果，在【我的奖品】内可以查看抽奖记录
4. 引导用户点击【生成邀请海报】点击保存海报图片，引导用户分享到朋友圈或者微信好友
5. 成功邀请好友进入到页面，用户额外获得一次抽奖机会，邀请者人气值增加，用户每邀请成功一个用户，都会获取一定的人气值，但抽奖机会只能额外增加一次。
6. 点击【活动锦囊】查看当前人气排行榜，以及自己的积分数量和排名

0x04：业务流程总结

微信登录授权流程

1. 用户进入活动页面，为用户重定向至微信授权页面，等待用户选择 “同意” 或 "拒绝" 授权。
2. 用户同意授权，微信授权服务会自动重定向到 redirect_uri 中的 URL，也就是我们的后端的用户登录接口，并且会携带用户的 tempcode
3. 后端的用户登录接口接收到 tempcode 并使用 tempcode 去获取用户的 access_token 等信息，获取成功后微信会返回 access_token 以及用户的 openid、unionid 等信息（公众号需要绑定微信开发平台才能获取到unionid，unionid 可以作为该微信号的唯一标识）
4. 携带 access_token 获取该用户的微信信息，并添加或者更新到数据库内。
5. 生成JWT令牌，为用户重定向至活动主页，并在重定向时携带生成的 JWT 令牌信息。

用户在线点播视频流程

1. 由于在线点播视频使需要携带 playauth 才能进行播放，后端使用 spring task 开启定时任务，每隔一段时间向阿里云 vod 服务获取新的 playauth（playauth 默认的过期时间为7200秒，所以我们需要提前一些时间去更新）
2. 用户点击播放视频，向后端接口请求该视频的播放信息，例如视频ID、视频标题、描述信息、playauth等
3. 后端接收到请求后，首先校验用户携带的JWT令牌是否合法。
4. 令牌校验失败，则会响应的效应的信息到前端，前端再要求用户重新信息授权登录。
5. 令牌校验通过，返回指定视频的播放信息到前端。
6. 前端播放器携带获取到的视频 id 以及 playauth 访问阿里云VOD服务，获取该视频的播放流。
7. 接收视频的流数据，播放视频。
8. 每个一段时间向后端发送当前视频的播放进度，后端接收到请求后做相应的记录，并且响应当前的记录状态到前端
9. 后端以用户首次提交进度作为播初始提交时间，当检测到用户当前提交的播放进度符合要求时，对比用户第一次与最后一次提交的时间的差来判断用户是否存在作弊行为。
10. 用户完成当天的视频观看任务，增加一次抽奖机会。

抽奖流程

1. 用户点击抽奖，显示腾讯滑块验证码，要求用户通过该验证码后才能进行下一步操作。
2. 滑块通过，将滑块验证码的行为数据加密后发送到腾验证码服务进行校验
3. 腾讯验证码服务返回校验后的信息到前端，但此时前端还无法判断用户是否通过了校验
4. 前端将收到的验证信息发送到后端服务，后端首先会校验用户的 jwt 令牌是否合法（防止接口薅羊毛的人恶意调用）令牌校验通过后将接收到验证信息后再次向验证码服务请求校验。
5. 验证码服务返回校验结果，校验失败则返回响应的结果到前端，前端收到后要求用户重新通过验证码后才能进行后续的操作。
6. 验证码校验成功，根据预设的概率来计算抽奖等级，如果抽到的是现金红包，则为用户重定向至红包的领取页面。

用户分享海报增加积分流程

1. 用户 A 进入海报分享页面，前端以携带用户 ID 的链接作为参数生成一个二维码，点击生成海报，生成图片。
2. 用户 B 扫描用户 A 分享海报中的二维码，访问用户 A 的分享链接并且要求用户B进行微信授权。
3. 用户 B 同意授权，在微信授权接口的 state 参数中携带用户A的 userid 作为 friendid，并重定向至后端登录接口
4. 后端接口获取用户 B 的微信信息，根据用户的 openid 判断该用户是否为新注册的用户，如果是则根据携带的friendid 为用户 A 增加一次邀请积分。
5. 生成 JWT 令牌信息，为用户B重定向至活动主页。

0x05：实现过程总结

具体的实现思路以及伪代码的过程都写在了思维导图中。

https://www.processon.com/view/link/5ee39247f346fb1ae55ef6d3

0x06：项目中用到的技术栈

前端

后端

0x07：个人职责

• 负责与甲方对接、讨论需求
• 数据库设计
• 后端业务功能实现
• 项目部署、交付、运维

前端页面设计与实现的工作由 邓老板 负责

0x08：开发流程总结

0x09：最终实现效果

微信登录授权

视频在线点播

抽奖

自动发放红包

用户抽中现金红包后，后端返回一个重定向的请求，为用户重定向至红包代发平台的领取地址，领取成功后，代发平台又为用户重定向至我们的中奖页面，并显示用户的中奖金额，如下图

同时用户的微信消息中会收到一个服务通知，如下图所示

点击服务通知可以看到红包代发平台的领取消息，并且我们可以自定义一些活动的信息

点击领取红包，红包会自动存入我们的微信零钱当中，如下图

积分排行榜

0x0A：项目总结

• 过度的需求分析以及伪代码设计，这样做虽然逻辑能够严谨，但并不适用这种完成周期较短的项目，最终可能会导致某个功能整体的实现时间变得更长。解决方案是：分析需求后简单的罗列步骤，尽快的开始具体的代码编写，开发过程中可以进行单元测试。
• 项目完成周期过短，甲方对页面效果要求高，且还未确定最终的页面效果、文案（开发两天后，该项目甲方所要求的页面效果的平面图在项目上线的前一天还在变动，预期的规划跟不上甲方的变化）
• 未在活动前收集用户联系方式或要求用户先关注公众号，导致在活动结束后无法通知未关注公众号的用户填写收货信息。
• 上线前的安全策略没有准备妥当，例如可以使用 nginx 的一些模块来限制 IP 的某个时间内的 请求频率，再配合 iptables 进行访问控制，还有 行为验证码、令牌校验等机制（使用滑块等行为验证码可以大幅度的提高羊毛党的成本，也能最大程度的减少用户体验的损耗）但由于甲方的活动在几天内就要上线，我们需要在短时间内实现所有需求，没有多余的时间去考虑这些问题，当然，这也是因为我们这方面经验，否则这些在开始的时候就应该安排人手去着手准备，导致上线后被羊毛党使用爬虫脚本配合代理池来高频的访问我们的后端接口导致我们的带宽被占用，影响正常用的访问。
• 没有坚持每天都对当天完成的进度进行复盘总结，原因是在后续的几天时间里面，全天时间都花在了需求讨论和实现上，每天都是忙到晚上11点左右才回宿舍，已经再无精力去做总结，给出的解决方案是在往后的项目开发总，每天分段对开发的进度和情况进行复盘，例如午饭后、晚饭后、睡觉前，分段完成从而减少复盘时的焦虑。
• 完成周期以及合同纠纷问题。如果周期较短按最低需求先实现（避免扣细节的习惯）保证截至当天能够交付或者上线，产品顺利上线后再做优化和迭代。

再次感谢 邓老板 的陪同作战 150 多个小时（上线当天两个人连续作战 40 多个小时没有休息）项目最后能够顺利交付离不开队友的积极配合与支持，虽然上线当天还是出了一些状况，但是整体来说还是很好，通过本次项目也收获到了不少实际开发中的经验。

0x0B：其他

微信网页授权的 “坑”

day4的上午，开始对微信登录的逻辑进行分析，查阅微信开放平台对于网站应用开发的文档，预期是使用之前审核通过的 “网站应用” 进行相关的开发

经过测试后发现，在开放平台提供给 “网站应用” 文档内的 "微信登录开发指南" 只能实现PC端的二维码扫码登录，而并不适用于移动端H5的需求（移动端的需求应该是打开网页后直接弹出授权请求）

PC端扫码后提示授权

移动端直接提示授权

经过资料的查阅，以及在询问经验丰富的大哥，最后在 segmentfault 提出的问题 得到了答复，最终确认了移动端 H5 网站要想实现微信登录授权，必须通过微信公众号来进行，而微信开发平台上的 “网站应用” 只适用于PC端网站进行扫码登录。微信为每个用户提供了公众平台的 测试账号 ，但API操作上有次数和频率的限制，并不适用于投入生产使用。

下午，最后还是把甲方的公众号权限要了过来，交付相关的权限后查阅 微信开放文档 进行相关流程的测试，最终实现了微信登录授权到信息获取的全过程，满足了该项目的需求，接下来是对整个后端的登录、校验流程的设计。整个下午都在使用思维导图对流程进行设计，没有进行实际的编码操作。

晚上，继续完善了登录流程的设计，整打算进行实际的编码，然后想到跟邓老板先讨论一下这个登录设计逻辑有无问题，经过分析后发现，设计的流程当中需要频繁的访问微信的授权 API 获取用户信息，且根据我们的需求，有更高效的方案，经过2个多小时的讨论后，最终决定使用 JWT 来实现无状态的令牌校验，既能防止用户对令牌进行篡改，也能实现令牌自动失效的需求，而无需再将令牌储存到 redis 内进行过期校验。

使用goaccess实时分析、监控nginx日志

参考文档

https://blog.csdn.net/liyyzz33/article/details/89945844

配置实时刷新

https://www.jianshu.com/p/b134995ae16c

效果图