一般而言，业务诉求作为架构设计的输入。
需求清单
对于语音识别产品而言，需满足的需求，举例如下：
功能需求
- 文件转写。
- 长文件转写，时长大于60秒，小于X小时，X可以指定为5。
- 短文件转写，时长小于60秒。
- 实时语音识别。
- 长语音识别，时长大于60秒，小于Y小时，Y可以指定为5。
- 短语音识别，时长小于60秒。
- 支持多个语种。
- 其它功能需求，比如：
- 前处理
- 支持多种音频文件格式。
- 支持多种采样率和位深。
- 支持去回声和抗噪。
- 支持在音频文件中处理多个声道。
- 中间处理
- 支持VAD。
- 支持区分音频文件中的多个讲话人。
- 支持输出文本对应的时间偏移。
- 支持使用热词提高字准率。
- 后处理
- 支持输出标点符号。
- 支持输出拼音类语言的大、小写。
- 支持数字、符号的归一化处理。
- 前处理
非功能需求
- 集成多个合作伙伴。
- 云云对接，即将请求转发给合作伙伴开放在公网的API服务，通过公网API访问的形式集成其语音识别能力。
- 集成软件包，即将合作伙伴的语音识别服务部署在相同的机房内，通过内网API访问的方式集成其语音识别能力。
- 集成算法库，集成合作伙伴的语音识别能力。
- 集成算法模型，基于相同的算法库，合作伙伴提供模型，进而集成其语音识别能力。
- 控制并发路数。
- 通过接口接入的基础设施，限制并发TPS。
- 基于当前可用的并发路数，限制可以接入的请求数量。
- 基于各个应用的业务推广情况，定义并发路数的最低、最高配额，保证基本的并发路数。
- 基于各个应用的业务实际情况，定义调用量的最高配额，控制调用量。
- 支持扩容。
- 通过扩容硬件的方式，增加服务能力。
- 针对某具体应用的实际情况，通过扩容，满足其业务诉求。
- 针对某具体业务场景的实际情况，通过扩容，满足其业务诉求。
技术指标
- 文件转写场景下的时延类指标，比如
- 转写比，即端到端处理时长与语音文件时长的比值。这个指标不是越小越好，需结合投入的硬件成本综合考虑，定义符合预期的指标目标值。
- 语音识别场景下的时延类指标，比如
- 首字时延
- 尾字时延
- 蹦字时延
- 模型文件的大小，影响如下：
- 决定了软件包版本构建的时间、安装服务的时间、启动服务的时间，是影响版本交付效率的直观因素。
- 模型文件占用的空间越大，则加载模型后，进程占用的内存空间则越大。这对硬件规格和技术方案、部署方案有直接的影响。
- 一定载荷下可提供的并发路数。
运营类需求
- 支持记录具体应用使用语音识别服务的业务调用量。
- 支持基于调用量，对具体应用进行计费。
运维类需求
- 提供日志，比如：
- 提供业务调试日志。
- 提供接口访问日志。
- 提供监控能力。
- 提供对基础设施的监控，比如CPU使用率、内存使用率、硬盘使用率等，以及必要的告警。
- 提供对业务组件的监控，比如进程是否存在，进程的CPU、内存使用率等，以及必要的告警。
- 提供对关键业务指标的监控，比如当前各服务实例在用、可用的并发路数，各业务可用、在用的并发路数等。
安全类需求
- 在云服务API层面增加保护，比如：
- 提供鉴权能力。
- 提供参数校验能力。
- 抵御DOS攻击的能力。
- 对用户数据的管理，包括但不限于：
- 使用安全通道传输用户数据。
- 使用加密方式保存用户数据。
- 允许用户删除数据。
- 允许用户指定数据的保存周期。
- 用户未提供数据保存周期时，系统支持自动删除。
架构方案
基于前述举例列出的需求，整体方案中包括如下组件：
- 业务类组件
- 接入网关
- 安全网关
- 业务网关
- 算法服务
- 支撑类组件
- 运维服务
- 运营服务
- 开发者服务
接入网关
主要职责有：
- 对外提供安全协议的请求通道，比如HTTPS。
- 限制业务请求的速率。
- 基于协议规则的请求流控。
安全网关
主要的职责是对外部发来的请求进行鉴权，拦截非法请求。
当鉴权通过时，补充必要的数据字段，比如应用标识等。
业务网关
主要的职责有：
- 对请求消息中的字段，进行校验，从而拦截非法请求。
- 依据请求消息，依据一定的业务规则，选择合适的算法服务来提供服务。
- 依据一定的业务规则，从指定的算法服务的集群中，挑选一个实例来提供服务。
- 记录业务调用量。
- 记录计费数据。
- 记录必要的运维数据。
- 记录必要的调试日志。
- 基于业务规则的请求流控。
算法服务
算法服务，提供语音识别的基本能力。
依据与合作伙伴的协作方式，算法服务包含如下类型：
- 云云集成，请求转发至合作伙伴开放在公网的API服务。
- 软件包集成，合作伙伴的软件包和自有的组件部署在相同的基础设施上，算法服务与其通过内网API的方式集成。
- 算法库集成，使用JNI方式，算法服务集成合作伙伴提供的算法库文件。
- 算法模型集成，算法服务集成模型，提供服务。
运维管理服务
主要职责是供运维人员管理、分析业务系统运行情况，包含的内容比较广，比如：
- 软件仓库
- 部署管理
- 配置管理
- 运维数据管理
- 采集系统
- 离线监控系统
- 在线监控系统
- 告警系统
运营服务
主要职责是供产品、运营人员分析业务运行现状，比如：
- 运营数据管理
- 采集系统
- 报表系统
- 告警系统
开发者服务
主要职责是供开发者管理业务的运行情况，比如：
- 订阅服务
- 计费报表
技术决策点
划分业务组件中各个组件的职责时，存在一些决策点，对设计方案存在影响，因此需要深入考虑。
语音识别过程可以划分为前、中、后三阶段的处理操作，依据前述架构方案，结合业务场景，需要思考这三个阶段在分别哪个业务组件上交付。
关于前处理
对于实时语音识别，假如使用手机作为录音设备，则可以限定录制时使用的音频文件格式、采样频率、位深、声道的数量，去回声和搞噪可以交给录音设备来完成，因此不涉及复杂的前处理。
对于文件转写，则无法限定音频数据文件的录制设备、文件格式、采样频率、位深、声道数量、录制环境等，因此需要支持前处理。相关的前处理特性，可能的实现位置有业务网关或者算法服务。
假如前处理在业务网关组件上实现，则下载文件、提取音频时长、记录计费数据、记录计量数据、基于业务规则的请求流控等可以一并实现。前处理的音频文件，需要将上传至公共存储，由算法服务下载。
本方案的优点：
- 在业务网关层面可以实现文件有效性的检查，避免将非法文件传递至算法服务，浪费算法服务器的算力。
- 在业务网关层面实现基于业务规则的请求流控，提前拦截非法请求，避免浪费算法服务的算力。
本方案的缺点：
- 业务网关和算法服务需要通过存储服务来传递音频文件，算法服务多了一次下载文件的操作。
假如前处理在算法服务上实现，业务网关组件只需转发请求，而下载文件、提取音频时长、记录计费数据、记录计量数据、基于业务规则的请求流控等特性均需要在算法服务来实现。
本方案的优点：
- 只涉及一次下载文件的操作。
本方案的缺点：
- 算法服务组件的数量比较多，假如音频文件保存在公网的存储服务上，则均需要开放外网访问权限。
- 对于文件有效性的检查延迟到了算法服务组件，恶意的请求可能会占用算法服务的算力资源。
- 基于业务规则的请求流控延迟到了算法服务组件，同样占用了算法服务的算力资源。
关于提取音频文件中音频数据的时长，处理音频文件中多个声道，目前比较简单的方案是使用开源软件FFmpeg来实现。但这款软件存在一些问题，比如：
- License非商业友好。
- 处理音频文件时，比较消耗CPU。
- 为支持某些特定的音频格式时，需要增加一些额外的编码、解码库，编译FFmpeg的过程比较曲折。此外，音频格式涉及到的开源软件，其License可能非商业友好。此外，部分项目的代码比较旧，长期无人维护，遇到问题时会比较尴尬。
- 偶尔会不稳定，对音频文件执行操作时会失败，但事后使用相同的音频文件重现问题时，发现问题无法复现。
关于后处理
语音识别的结果中没有标点符号，作为书面形式阅读时会增加很多障碍，不同的句读可能会产生不同的理解，从而出现不必要的歧义。对于中文而言，这个现象尤其严重。因此为了提升可读性，需要在语音识别输出的结果进行处理，增加必要的标点符号，比如句号、逗号、探号、问号等。
对于拼音类语言，比如英语、法语等，相同的单词在不同场景下，其大小写形式可能会不同，比如the President和the president，前者指代现总统，而后者仅为泛指。为了提升可读性，需要对语音识别输出的结果进行处理，增加合理的大、小写形式。
对于数字、单位等词汇，语音识别的结果中均表示为文字，与通常使用的书面表达形式不同，阅读体验比较差，因此有必要依据一定的规则或者场景将其还原为常见的表达形式，改善阅读体验。
针对上述三个特性，决策点有：
- 实现方案，使用机器学习模型实现，还是使用代码基于一定的规则来实现。
- 实现位置，在业务网关实现，还是在算法服务实现。