《声纹技术：从核心算法到工程实践》第四章：声纹识别的工程部署

4.1从模型到产品

4.1.1 模型不等于产品

4.1.2软件工程相关概念

4.开发环境与构建自动化
要保证整个团队采用相同一个软件构造系统，必须严格安装同一版本的操作系统，其次需要采用一套可以配置编译。连接方式、并描述依赖关系的构建自动化框架。通过该配置文件构建软件，并得到同样的结果

5.软件测试
6.代码评审与持续集成
7.故障追踪与管理
8.文档
9.重构

4.3 全设备端部署

4.3.1 部署方式的分类依据

全设备端部署、全服务器端部署、复合式部署
分类依据：
（1）完成信号处理、特征提取以及神经网络模型推理等任务的语音处理引擎在什么机器上运行
（2）用户的说话人模型存储在什么机器上

4.3.2 版本迭代更新

为了支持声纹识别模型的版本更新，我们将新的模型部署到设备端时，需要立即触发新的声纹录入阶段，重新生成所有用户的说话人模型。也需要把原始的录入音频存储到设备端。只有保存了原始的录入音频，才能保证我们能够随时利用新的声纹米线你给重新进行声纹录入，从而生成新的模型

给每个版本的声纹识别模型制定一个版本号，并将所有版本的模型存储在某个可以从设备端访问的存储服务器上。该存储服务器有一个特殊链接，该链接始终指向最新版本的声纹模型。当我们开发出更好的模型的时候，便手动将该模型上传到服务器中。设备端会定期向服务器查询最新模型的版本号（最好在半夜），如果该版本号高于设备端本地的版本号，则在后台下载新的声纹识别模型。新的声纹模型下载完成后便删除之前的说话人模型，并在后台执行新的声纹录入。
##

4.3.3 资源限制：设备端最大的挑战

降低资源的开销
（1）语音处理引擎减少对其他库的依赖，保证部署到设备端的引擎库占用最小的硬盘资源
（2）语音处理引擎针对具体 的硬件进行优化，降低CPU的负担
（3）架构上减少使用CNN，降低CPU负担
（4）对输入帧进行降采样，降低声纹识别模型的运行次数，节省CPU开销
（5）模型压缩或者模型稀疏化技术，降低模型参数
Compressing deep neural networks using a rank-constrained topology

4.4 全服务器端部署

4.4.1 全服务器端

语音处理和说话人模型都部署在服务器端
设备端操作方便，只用录入音频和与服务器端通信。服务器更复杂
服务器端除了需要用来运行语音处理引擎的云计算服务器，还需要用来存储每个说话人的录入音频和说话人的模型
数据库可以采用键值对，键为每个用户的唯一标识，用户账号或者是哈希码；值则包含该用户的说话人模型以及录入的所有音频。

4.4.2 版本迭代更新

1.单版本离线更新策略
前端服务器不再接受任何声纹录入或者声纹验证的请求，而是向用户相应类似“服务器正在维护升级中，请稍后再试”
服务器后端进行运行更新任务。首先我们需要将所有云计算服务器中的旧版本声纹识别模型替换为新版本模型。这一步完成之后，对于数据库中的每一个用户，先删除其已有的说话人模型，再利用其已有的录入音频，通过部署了的新版本声纹识别模型的语音处理引擎，计算新的说话人模型，并存入数据
（1）该策略需要停用服务器一段时间
（2）后端需要在短时间内完成大量计算，遭遇流量高峰，在离线更新阶段，所有用户的数据都要在后台完成重新完成声纹录入的任务，对数据库和云服务器都会造成极大的负担。

2.单版本在线更新策略
只有在必要时更新相应用户的说话人模型

给每个声纹模型设定一个版本号，在声纹录入阶段，声纹模型的版本号存入生成的说话人模型中；而在每一次声纹验证时，先比较说话人模型中的版本号与云计算服务器中的声纹识别版本号是否一致。不一致则调用新的版本号

缺陷：在模型更新后，任何用户的第一次声纹验证都会遭遇延迟。这种延迟源于需要用新版本的声纹识别模型重新运行声纹录入，延迟取决于录入效率。
难以对后端云计算进行分布式部署，假如后端云计算有很多台服务器，那么在模型更新的过程中，有些机器会率先完成更新，有的会滞后。所以逻辑是只要用户的说话人模型版本与服务器的声纹识别模型版本不符，便重新运行声纹录入以更新该用户的说话人模型——避免发生版本反弹事件（新版本向旧版本迭代）

三种解决方法：
（1）让前端服务器事实与后端服务器保持同步，以追踪哪些后端服务器已经完成了声纹识别模型版本的更新。——但是需要在前端服务器引入复杂的逻辑，因此不常用
（2）第二种方法是在负载均衡中引入哈希法，从而保证每个用户的请求始终被发送到分布式系统的同一个服务器中。保证用户只从旧版本向新版本迭代，不降级
（3）在后端数据库中，对每个用户始终保存两个版本以上的说话人模型。根据后端存储的模型来验证

3.双版本更新策略

后端云服务器上同时运行两个版本的声纹识别模型。后端数据库中，每个用户也同时储存两个版本的说话人模型

4.4.3 负载均衡与故障处理

1.算力扩展
纵向扩展——购买具备更强的CPU、内存。更多硬盘空间
横向扩展——购买更多的服务器，来分担计算任务

横向扩展来增加计算机能力需要一种负载均衡的技术。来自不同设备端的大量请求抵达前端服务器后，前端服务器不会直接将对应的请求发送给后端的云服务器，而是发送给成为负载均衡器的反向代理服务器，再由负载均衡器决定将请求发往哪台云端计算服务器。假如后端有N台正常工作的计算服务器，每台只要处理1/N的流量。
保证每一台服务器都不会超负荷运行：
（1）轮转法：接受的请求轮流发送到各个云计算服务器，从而保证每个服务器的接收流量大致相同
（2）哈希法：根据用户账号或者IP地址计算一个整数哈希值，然后针对该整数求N取余数，再根据该余数选定对应的云计算服务器。这种做法保证每个服务器能够接受的流量大致相同，还可以保证每个用户或者客户端始终使用同一台后端服务器，这样能够更加有效地利用服务器的缓存
（3）自适应法：每一个服务器硬件配置以及计算能力未必相同，将流量均等地分流到每台后端，这样不好。让每台云计算服务器定期向负载均衡器汇报自身的负载情况，而负载均衡器则根据所有后端服务器的负载情况进行分流
负载均衡器往往需要纵向扩展，以保证自身能处理更大的流量

2.单点故障的处理
单个机器节点出现的故障导致整个系统的崩溃
对于数据库来言，最简单的方法就是实时备份。运行后台进程时定期将主数据库复制到备用数据库中。我们可以在每次写入主数据库时候，同时写入备用数据库。两者实现物理意义的隔离
对于云计算服务器，如果采用负载均衡的设计，那么单点故障的检测比较简单，在后台运行一个监视器进程，该进程定期在每一台后端服务器上运行集成测试。一旦监视器发现某台服务器出现问题，便通知负载均衡器，不再让他分配给请求分流。
然而负载均衡器本身作为一台服务器也可能发生单点故障。通常设置一台备用的负载均衡器，考虑到所有的请求都需要经过负载均衡器，因此负载均衡器具有特殊的地位。当其出现问题的时候，通常会立刻向软件工程师和运维工程师发送警报邮件，以确保问题在最短时间内得到解决。
在利用负载均衡器实现单点故障的稳定性时，对于每一个云计算节点，有一个必须的要求，那就是该节点所执行的任务必须是无状态的——该任务的输出仅取决于输入，不依赖其自身的存储。

我们提到的服务器节点，其实不一定是真正物理意义的服务器，还可以是虚拟机，甚至是更先进的Docker。K8s提供了基于容器的自动部署、扩展和管理架构

分布式系统的相关书籍！！！！！

4.5 复合式部署

4.5.1 声纹信息的敏感性

全设备部署不考虑网络通信，不需要实现复杂的版本迭代更新策略，也不需要考虑负载均衡等问题，却需要设备端游足够的计算资源。
当设备端不适合高强度计算时，全服务器端部署就是非常合适的选择。

4.5.2 复合式架构

语音处理引擎扔在服务器端运行，而用户的说话人模型则存储在设备端

在声纹录入阶段，设备端将录入音频发送给服务器端，由服务器运行语音处理引擎，生成说话人模型，然后说话人模型被发送给设备端，并有设备端进行本地存储
在声纹验证阶段，设备端除了要将验证音频发送给服务器端，还需要同事发送存储在本地的说话人模型。服务器端的语音处理引擎根据验证音频的嵌入码和说话人的相似度完成判别，再将验证结果发回设备端。

4.5.3 版本迭代更新

把本来由后端数据库负责的存储替换成用设备端进行存储，但就这一点区别将决定进行模型版本迭代更新的时候，复合式部署将面临新的挑战——服务器端和设备端之间的通信，永远都是由设备端进行单方面触发的。

1.单版本在线更新策略
设备端向服务器发送声纹验证请求的时候，服务器端首先检查设备端发过来的说话人版本是否为最新版本。如果该说话人版本已经是最新的，则直接进行验证，并返回验证结果；如果该说话人模型版本不是最新的，则需要通知设备端重新进行声纹录入，录入完成后，在根据新的说话人模型进行验证，返回验证结果

当服务器端声纹识别模型更新之后，对于每个设备端而言，其下一次验证请求都会遭遇延迟，该延迟源于需要在线重新进行声纹录入。针对这一问题，可行的优化方式是让每个设备端定期于服务器端进行握手通信。即每隔一段时间，设备端在后台与服务器进行通信，检查说话人模型版本是否为最新，如果不是，则在后台发送声纹录入请求。这样一来，只要握手通信发生在版本更新后的一次验证请求之前，该验证请求不会遭到延迟。握手通信可以选择在产品使用频率较低的时段进行，例如设备当地的后半夜。

2.双版本更新策略

服务器端需要同时运行两个版本的声纹识别模型，设备端也同时运行两个版本的说话人模型。声纹录入阶段，服务器端同时生成同一用户的两个版本的说话人模型，发送给设备端进行存储；而在声纹验证阶段，设备端则向服务器端发送验证音频及待验证用户的两个版本的说话人模型，从而保证服务器端的声纹识别模型进行了版本更新，旧版本的声纹识别模型依旧可用。
对于复合式部署而言，即使采取了双版本更新策略，也需要确保及时地运行声纹录入。一旦服务器端相继完成了两次声纹识别模型的更新，而设备端的说话人模型一直未能更新，则会发生模型版本不匹配的情况。在后台运行声纹录入，通常有两种做法：第一种做法是在每次验证请求时，先检查设备端的说话人模型是否包含最新版本，如果不包含，则在后台触发声纹录入；第二种做法是让设备端与服务器定期进行握手通信，检查版本是否匹配，若不匹配，则在后台触发声纹录入。在第二种方法中，定期握手通信的频率要高于声纹识别模型更新的频率。