scbc.liyongjie.mycinema

分片上传投稿+私人影片仓库管理+协同视频流播放/实时消息互动+好友管理+放映室管理

一.作品概述（功能介绍图）

三.整体开发架构

1.前后端分离开发

2.微服务架构

四.使用工具/技术一览

五.核心技术攻关

1.高效上传

我们所提供的核心体验之一就是自主上传影片，这是我们首要攻克的难点

  - 上传速度要快
  - 反馈体验要好
  - 能妙传判断/续传
  - 开发中----登出/意外断传，关闭窗口/的情况下能续传.....

初步优化:

「我们从一开始的一次性完整传输，到分片+并发+md5校验数据作妙传
前后端需要高度一致的配置，才能完成」
----本地平均250mb/s

进一步优化:

「后台对分片的合并操作利用Java Nio的 FileChannel的transferTo零拷贝优化合并操作，操作执行完毕后，后续的处理（DASH流/缩略图生成）异步多线程执行，快速反馈上传结果给用户」
----本300mb/s（极限可突破）

后期的再优化（开发中）：

「尝试后台不再由SpringBoot内嵌的tomcat去处理分片接收,采用基于Netty搭建一个Http协议的分片上传服务器，尝试采用protostuff（可能web端的上传框架不方便使用）二进制流进行传输，在demo编写环节，后期会替换现有的策略」
----目标突破500mb/s的本地传输速率

2.如何执行生成MPEG-DASH流/影片缩略图

「为了提高放映室的观影体验我们决定采用自适应比特流MPEG-DASH的技术，相比HLS，DASH更具有国际标准/更底的端对端延迟，bilibili与2018年全面采用了MPEG-DASH的技术，如果细心的小伙伴可以发现，看bilibili视频会先一开始模糊再到清楚，这就是自适应比特流」
参考文档pdf（来自谷歌百度）：
https://www.w3.org/2019/03/23-chinese-web-jianqiang-bilibili.pdf

  - 工具选用阶段
  - 如何整合进工程内 
  - 如何保证用户反馈

初步策略：

「采用FFmpeg生成MPEG-DASH流和缩略图的生成（默认为2min处截图），又Java去调用外部程序，执行FFmpeg的相关命令」

初步优化:

「由于Java提供的执行外部程序的缺陷，经常会出现Runtime缓冲区问题导致的线程卡死，我们引用Apache Commons-Exec工具来执行外部程序，并且异步多线程的形式去执行DASH流生成以及缩略图生成的业务」

整合策略:

「该两项业务与上传业务密切挂钩，但又属于相互独立的业务，以及微服务开发的架构，我们进行了业务拆分，将上传与该两项业务独立于两个SpringBoot工程，通过rpc相互调用，保证业务的完整性」

优化RPC调用：

「初期采用Fegin来完成两项业务之间的调用，但经过调研和学习发现，谷歌提供的Grpc速度更快，效率更高，可以提高我们带给用户的反馈，我们决定选用Grpc作为我们远程调用的框架」
-----gRPC基于Netty+Http2.0+Protocol Buffers比传统的RPC要快60%以上

后期的再优化（开发学习当中）:

「通过cdn加速，视频点播服务，云存储技术优化用户的观影体验，还有视频存储的策略也需要升级改造，还有一系列的问题和考验需要我们去解决和面对」

3.协同播放与实时通知

受文档大小限制画质会比较糊

实时通知: 在该作品中会出现很多这种业务，好友申请发起/视频分享申请发起/放映室创建邀请发起/
_实际上还有一个业务----__在线/离线 判断，_我们相对的业务逻辑也就不一样

策略：

「用SpringBoot整合一个基于Netty开发的WebSocket服务器，用来创建长连接，主动推 送信息给客户端。利用这种特性，我们实时传播房主发出的开始/暂停等操作，从而实现协同 播放。」

难点：

「需要维护一个User--Channel的双向映射的Map，才能完成精准的消息投送，服务器每接收到一个活跃的连接，首先需要客户端发送一个BindAskMessage来通知服务端将用户Channel绑定，用户的基本信息来自BindAskMessage实体类内部（这里对每一种消息类型都做了一个封装）」

优化：

「我们将建立两个Netty搭建的WebSocket服务器，一个用于处理主页的相关事务，一个专门处理放映室协同播放/实时聊天的事务，减轻单个服务器连接的压力，和Bind信息混杂不好管理的问题」

后期优化：

「协同播放追求低延时，在实时传递开始/暂停/实时聊天等业务的时候，传统的Json.xml.java对象不如protobuf的性能更高，延时也就更低，后期我们将放映室的数据传输用protobuf替代」

4.UUID生成器

在该作品中存在很多需要UUID作为唯一标识的场景，视频uuid/仓库uuid/房间号uuid等等

生成策略：

「采用github开源的JUG（java-uuid-generator）JUG 可以在每个内核每秒生成数百万个 UUID，有时达到每秒 1000 万个的理论极限」

5.缓存

策略:

「选用Redis作为缓存数据库，缓存一些离线消息/放映室的初始化数据/等等」

6.统一认证

策略：

「Spring cloud gateway + JWT Token + Redis 的网关统一验证身份，在gatetway内构建一个Global Filter 用于拦截请求，验证token的时效性，合法性，redis在这用于缓存token---user相关信息以及token---secret」

六.Base-Api