Planet #0
前段时间在dc的服务器比赛里承担了几次直播员的任务，作为技术栈的一部分，把直播中用到的技术和要点整理成文章记录在了Github上，为了存档，在这里也保存一份，Github链接：https://github.com/SolitudeRA/LOL-eSports-Streaming-Handbook 英雄联盟电竞直播手册（不含国服） In-game观赛UI设计数据 观赛UI Layout 直播工具链 OBS OBS Studio是一款开源的直播工具，可以帮助你快速的开始直播，并且可以帮助你快速的推送直播内容。 下载地址 League prod toolkit 用于英雄联盟电竞直播的开源OBS浮层工具，提供赛前BP，游戏内事件，赛后面板等功能。 Github页面 League observer tool League prod toolkit的本地OB工具，用于与League prod toolkit的LCU端点进行通信，提供游戏内事件监测。 Github页面 Creator Suite Replay / League Director
前言 到了东京之后，由于这几年暂时用不到梯子了，而且同时用着两台同样的10刀服务器有点傻吊，所以就把邮件服务器关掉了，并且换了一个更好的配置来当做主力服务器，计划在挂博客的同时，让它兼任Git与CI&CD服务器的角色，顺便再做一做项目管理。同时兼职这么多任务的话，服务器的备份就很重要，因为一旦爆炸了，就要丢失很多的数据，目前Wordpress的博客是有带Schedule的备份插件在支撑着每周的博客备份任务的，但是别的服务并没有，而且Linode的备份服务还挺贵的，所以需要一个靠谱的备份应用与策略，万一服务器哪天被我玩炸了或者自己抽风爆炸了，还可以自行恢复数据。 之前在实习的时候，由于也要用到Linux(Ubuntu 16.04 LTS)测试机，所以之前用过一阵SystemBack来做系统还原点，但是因为SystemBack只能实现简单的系统备份功能，并且作者在2016年就停止了开发，16.04以后的版本并不能用，所以经过一番查询，我最终选择了Bacula作为服务器的备份应用，看起来很靠谱的样子，虽然也可以用Rsync，但是Rsync看起来很难用的样子，所以还是用了Bacula。经过了两天的折腾，终于是完成了Bacula的部署与配置，在这里记录一下，方便自己以后查阅。
鸽了一年，up又诈尸啦！感谢大家在我咕咕咕的这么长时间里还在看我的视频。最近终于是有了比较长的休息时间，最近会再更几期视频。 Ps.图源： 1. 【Miv4t】Pixiv ID：11246082 2.【Azomo】Pixiv ID：6342480 3.【超凶の狄璐卡】Pixiv ID：22124330 4.【渣音Re.】Pixiv ID：3910079 5.【吟】Pixiv ID：113939 6.【PiNe(パイネ)】Pixiv ID：5403033
经过了毕设答辩之后，PHSS-Core也终于是完成了一个阶段的开发工作，回到家的这几天时间里，由于项目的初期开发都是以实现毕设文档中所计划的功能为目标，所以项目的开发顺序被些许打乱，现如今答辩工作完成，一时间有点不知道下一步该写点什么来推进整个项目的开发进度，所以整个项目的开发陷入了停滞，因此在这里做一下简单的阶段性总结，整理一下目前的进度，规划一下接下来的工作。 经过了紧(lan)锣(lan)密(san)鼓(san)的几个月的开发，整个项目也走到了一个阶段性的节点，截至现在，完成的进度节点有以下几个： 数据库整体结构设计 基于Spring Data JPA的DO层 基于Spring Security的简单登录注册功能 基于FFmpeg与JavaCV的音频元数据获取 基于Metadata的音频自动分类存放 音频查询接口 目前各方面待完成的目标有： DO层： 进一步完善数据库设计，优化查询效率 将实体文件与数据库条目绑定，完成级联更新与删除功能 安全层： 解决React前端配合后台CSRF防御的问题 解决跨域访问问题 将鉴权体系向JSON Web Token平移 添加生物识别登录功能 服务： 进一步研究NIO的功能与特点，提高多文件传输的效率 文档管理 视频管理 电影管理 番组管理 接入弹弹Play API，提供番组查询，订阅，提示
在经过了初期阶段的开发过程后，终于是完成了基本的结构设计与简单的文字性音频元数据读取功能，在初期的结构设计中，Java-Music-Utilities预计有音频转码，音频元数据读写这两个功能。 目前主要有三个类：MusicContainer，Metadata，Converter，分别是音频文件的容器类，元数据获取与集合类，转码类。现在的工作方式是使用MusicContainer的构造器来初始化音频容器，提供Path与byte流两种初始化方式。然后选择将MusicContainer作为唯一参数传入Metadata或Converter的构造其中来初始化元数据容器或者是转码实例。 截止目前，我只实现了文字性元数据的获取，由于JavaCPP-Presents-FFmpeg正处于大版本的更迭期，封面获取的关键性函数的用法缺少文档，所以下一步的计划是在没有文档的情况下依靠简易的JavaDoc来专注完成音频封面的获取，然后再考虑转码类的编写问题，以上。
在PHSS音频管理功能的开发过程中，由于涉及到了音频文件的一些处理工作，包括音频元数据的读取，转码等，处于对开发便捷性的需求，在开发的前期，我在Github上寻找了很长时间音频处理相关的Java库。但事与愿违，经过了一番查询，可能是由于Java在这方面的应用非常少，能找到的相关库都很老旧并且长时间没有更新，还有一些库只是单纯基于命令行版FFmpeg的命令行工具，有点难用，并且Java自带的音频处理接口也都很长时间没有更新，并且支持的音频格式非常少，所以我在不得以自己写工具类的同时，也萌生写一个正经的轮子的想法，因此发起了这个名为Java-Music-Utilities的项目，Github的地址在这里。
Ps.PHSS的这部分开发过程中还衍生出了一个基于FFmpeg的java原生音视频metadata获取的轮子，相关文章可以参考这里。 前言 在完成了简单的安全层架构，实现了基本的登录功能之后，项目中于是进入了较为核心的音视频管理功能的开发阶段，在前期技术选型时，考虑到项目的可维护性与稳定性，我最终选择了FFmpeg作为PHSS的多媒体管理外部库，作为老牌多媒体处理软件，FFmpeg的可用性与稳定性都是经过了多年生产环境检验的。 但是在编写专辑音轨管理功能的具体实现过程中，我发现FFmpeg这个东西竟然找不太到全面且易读的开发相关的Guide和Documentation。并且实际使用过程中所用到的FFmpeg的Java实现（FFmpeg-JavaCPP-Presents，基于JavaCPP，由Bytedeco编写）更是只有一个基本的demo，FFmpeg的其他更深度的内容也是一点都没提，在Google上能找到的也大多都是命令行版的FFmpeg的使用方法，在Github上能找到的音视频metadata获取相关的项目也大多都是基于命令行版FFmpeg或者是其他一些奇奇怪怪的，早已停止更新的第三方库，看起来非常的不靠谱。由于FFmpeg的Java实现是基于JavaCV的子项目，更新一直都非常稳定，所以我还是坚定不移的选择了JavaCPP版FFmpeg作为项目的多媒体处理库，因此我只能自己一点点看那个JavaDoc和网上能找到的一些零星的老版本的开发示例来一点点学习相关的开发知识，在这里记录以下，方便自己和其他有需要的老哥们日后有个参考。（以下叙述是以FFmpeg-JavaCPP作为基础，其基础技术JNI的相关介绍可以点这里）
在完成了PHSS-Core对Spring Security的引入的初期阶段是之后，我又引入了Spring Data REST用来快速构建RESTful的资源访问与操纵API，在实现了Spring Data REST的基本功能之后，又有一个新的问题出现了–那就是REST API下资源的访问权限问题。 在只有Spring Security基础配置的情况下，用户登录后，通过RESTful api(/rest)可以访问到数据库中的所有资源，也就是说当某个登录后，调用/rest/musicAlbumEntities接口，不仅可以看见属于自己的专辑，还可以看见整个数据库中其他用户的专辑。经过对Spring Data REST的说明文档的一番研读，发现最接近我的要求的是@PreAuthorize功能，该注解提供了方法级的安全性控制，也就是说只有特定用户才能访问特定方法，但在经过尝试之后PreAuthorization模型并不能满足我的需求，所以我又将眼光转回到了Spring Security的说明文档上。
在完成了由Hibernate到Spring Data JPA的切换后，我开始了Service层的设计，由于PHSS对安全性以及开发速度的需求，我选择了使用同属Spring Projects系列的Spring Security。 安全是一个非常抽象且不断变化的概念，在如今的Web环境下，一个动态的，不断完善的安全系统显得至关重要。在现代Web应用中，只有建立一个完善的安全层才能尽可能保证各个层级的安全性。 在现在的网络环境中，常见的攻击手段有XSS，SQL注入，CSRF，SSRF，xee，xPath注入等。 我们要做的就是在安全层建立完备的系统来防御这些可以预见的以及其他不可预见的攻击。在系统底层，我们需要处理诸如传输安全与系统识别的问题，最简单的例子就是开启https连接使用X.509认证以防止传输过程中的中间人攻击。然后我们还需要将关键的数据-例如密码与身份证号等各种信息进行加密储存以最大程度的防止系统被攻破后的数据泄露。在Service层，我们需要一套完善的权限管理机制来确保数据只能被拥有相关权限的用户访问到，更加高级的还有方法级的授权验证等。
1.Spring Data JPA 随着开发进度的不断推进，由于对REST服务的需求与对开发速度的需要，加之在设计初期PHSS的整个系统就坚定拥抱了Spring Projects，所以在Service开发开始前的这个节点，我将ORM框架由基本的Hibernate切换到了与Spring的其他各种项目更有亲和性，并且开发更为简便的Spring Data系列，包括Spring data JPA，Spring data REST。
在互联网发展的初期，密码大多是以明文存储的，因为密码被认为是安全的，它需要凭证才能够被访问到。但是，攻击者可以通过SQL注入等攻击方式来获取大量的密码。随着越来越多的密码被这些攻击手段所获取，安全领域的专家们开始意识到需要一中更加安全的方式来保护用户的密码。 随后，安全领域开始鼓励开发人员使用单向散列算法（也称Hash算法，例如SHA256）来将密码进行加密存储。当用户尝试认证时，系统将用户上传的密码hash后与数据库中储存的hash值进行比较，这意味着数据库只需存储密码的单向散列。如果系统被攻破，也只会暴露密码的单向散列，由于在计算上很难通过单向散列值来破解密码，因此这种方法在很大程度上提高了密码的安全性。但是随着黑客技术的发展，攻击者也开始使用彩虹表（Rainbow Tables）来辅助破解，攻击者并不是每次都是在猜测密码，而是通过彩虹表来使用“以空间换时间”的策略来进行密码破解。
由于PHSS的前后端分离特性，在设计PHSS的安全系统的时候了解到了JWT（JSON Web Token）策略，经过了一番权衡，处于对扩展性与易用性的需求，我决定使用JWT鉴权体系。由于JWT的特性，很多信息都将由Token来承载，所以Token的设计也成为了必须关注的一个点。以下关于JWT规约的内容译自jwt.io
在PHSS的设计初期，由于数据库设计经验·的不足以及对于数据库跨表ID唯一性的需求，在一番查询之后我选择了UUID作为整个系统的ID类型。但是在实际代码编写的过程中，由于采用了基于JPA的Hibernate Bootstrap方式，在fetching的时候需要使用JPA提供的基于EntityManager的·fetch方法，比如EntityManager.find()与EntityManager.createQuery()。但不尽如人意的是，在主键采用UUID类型的情况下，JPA所提供的Fetching方法出现了不可预知的问题：在UUID具体值已确定的条件下，使用entitymanager.find()方法通过UUID进行fetching，即使UUID正确，也会出现entity无法找到的问题，尝试两种fetching方式后都无法定位，并且Google和Stackoverflow查询未果后，最终还是决定更换主键策略。在更加深入地研究了各种主键策略之后，发现自己以前对数据库主键的理解还是存在一些问题，所以在这里重新总结一下关于数据库主键策略选择的各种要点。
在开发初期，作为智能家庭服务器(Home server)PHSS在设想下应有以下功能(当然，只是设想。作为一个死宅程序员，其中还夹杂了点私货wwwww)： 个人资料库管理：音乐专辑，视频，电影，动漫番组，电子书籍，插画，文档 个人日程与档案管理：日历，日程提醒，便利贴，番组信息，RSS订阅，新闻抓取 本地Git管理 Google Home与Apple Homekit功能接入，包括家庭用电量统计，智能家电自动控制与场景切换 安全性方面，在支持密码登录的基础上，加入生物信息登录与物理key登录 经过简单的初期设计，半成品数据库结构大致如下: 考虑到Google Home与Apple Homekit接入的复杂性，所以暂时搁置，目前只是大致设计出了个人资料库与个人日程档案的大致数据库结构。由于资料库系统在预期情况下可能发生大量文件读取，所以将文件系统的数据库结构做了一些范式化设计。