本次以Redis为范例，阐述了有道基础架构团队在基础设施容器化道路上的实践，主要将从声明式管理，Operator工作原理，容器编排，主从模式，集群模式，高可用策略，集群扩缩容等方面展开。
Redis 是业务系统中较为常用的缓存服务，常用于流量高峰、数据分析、积分排序等场景，并且通过中间件可以实现系统之间的解耦，提升系统的可扩展性。
传统物理机部署中间件，需要运维人员手动搭建，启动时间较长，也不利于后期维护，无法满足业务快速发展的需求。
云原生相较于传统IT，可以助力业务平滑迁移、快速开发、稳定运维，大幅降低技术成本，节约硬件资源。
云原生中间件是指依托容器化、服务网格、微服务、Serverless等技术，构建可扩展的基础设施，持续交付用于生产系统的基础软件，在功能不变的前提下，提高了应用的可用性与稳定性。
在这种大趋势下，有道基础架构团队开始了云原生中间件的实践，除了本文介绍的 Redis，还包括 Elasticsearch、ZooKeeper 等。
利用云原生技术可以解决当前Redis部署缓慢，资源利用率低等问题，同时容器化 Redis 集群也面临着一些挑战：
对于一个 Redis 集群，我们的期望是能够 724 小时无间断提供服务，遇故障可自行修复。这与Kubernetes API的声明式特点如出一辙。
所谓“声明式”, 指的就是我们只需要提交一个定义好的 API 对象来“声明”我所期望的状态是什么样子，Kubernetes中的资源对象可在无外界干扰的情况下，完成当前状态到期望状态的转换，这个过程就是Reconcile过程。例如，我们通过yaml创建了一个Deployment ,Kubernetes将“自动的”根据yaml中的配置，为其创建好Pod，并拉取指定存储卷进行挂载，以及其他一系列复杂要求。
因此，我们的Redis集群是否可以使用一个类似的服务去完成这个过程呢？即我们需要定义这样的对象，定义服务Reconcile的过程。Kubernetes的Operator刚好可以满足这个需求，可以简单的理解Operator由资源定义和资源构成，在充分解读集群和Operator的关系后，我们将整体架构图设计如下
哨兵模式中Redis服务用一套哨兵集群，使用StatefulSet部署，持久化配置文件。Redis server也采用 StatefulSet部署, 哨兵模式的实例为一主多从。
Redis的资源定义在ETCD中存储一份即可，我们只需要预先提交自定义资源的 yaml配置。如下所示为创建三个副本的Redis主从集群：
Operator 无需任何修改，即可从 Kubernetes 核心中获得许多内置的自动化功能，如使用 Kubernetes 自动化部署和运行工作负载， 甚至可以自动化 Kubernetes 自身。
Kubernetes 的 Operator 模式可在不修改 Kubernetes 自身的代码基础上，通过关联到一个以上的定制资源，即可以扩展集群的行为。Operator 是 Kubernetes API 的客户端，核心功能是充当定制资源的。
用户创建一个CRD自定义资源，ApiServer把CRD转发给webhook，webhook 进行缺省值配置 验证配置和修改配置，webhook处理完成后的的配置会存入ETCD中 ，返回给用户是否创建成功信息。Controller 会监测到CRD，按照预先写的业务逻辑，处理这个CRD，比如创建Pod、处理新节点与旧集群关系等，保证运行的状态与期望的一致。
Redis 集群在 Kubernetes 中的最小部署单位为 Pod，因此在架构设计之前，需预先考虑Redis特性、资源限制、部署形态、数据存储、状态维护等内容，为不同类型的Redis集群配置合适的部署方式。
• limit(资源限制)：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。
Redis 基本不会滥用 cpu，因此配置1-2个核即可。内存根据具体业务使用分配，考虑到部分场景下会fork较多的内存，例如 aof 频繁刷写，aof 重写过程中，Redis 主程序称依旧可以接收写操作，这时会采用 copy on write (写时复制)的方法操作内存数据，若业务使用特点为“写多读少”，那么刷写期间将产生大量的内存拷贝，从而导致 OOM，服务重启。
一个有效的解决方式为减少刷写次数，将刷写操作放在夜间低流量时段进行。减少刷写次数的方法为适当增加auto-aof-rewrite-min-size的大小，可配置使用内存的5倍甚至更大的最小刷写量；其次可以主动触发刷写，判断内存使用达到的配额两倍时进行刷写，实际部署时一般也会预留50%的内存防止OOM。
依据数据是否需要持久化或是否需要唯一标识区分服务为无状态和有状态的服务，Redis集群需要明确主从、分片标识，大部分场景也需要数据持久化，Kubernetes使用StatefulSet来满足这一类需求。StatefulSet的顺序部署、逆序自动滚动更新更能提高Redis集群的可用性。
Redis Server 启动时需要一些配置文件，里面涉及到用户名和密码，我们使用 Configmap 和 Secret 来存储的。Configmap 是 Kubernetes的Api 对象，常用于存储小于1MB的非机密键值对。而 Secret 可以用于存储包含敏感信息的密码、令牌、密钥等数据的对象。
Redis容器化后建立的每个 CR 表示一个完整的Redis服务，具体的服务模式包括哨兵模式和集群模式两种，在进行容器化过程中，除覆盖裸服务器部署结构外，也对架构进行了一定程度的优化。
所有实例共用一组哨兵将进一步提高实例启动速度，并在一定程度上可提高硬件资源利用率，实测单组哨兵可轻松应对百规模的主从集群。
检查是否按照预期启动了全部的Pod，比如创建3个Server，那么需要按照预期启动三个才能继续进行后面的操作。
检查Master的数量，确保该实例仅有一个主节点（数量为0主动选一个；数量大于1手动修复）。
通过在传统Redis Cluster架构中引入代理功能，实现动态路由分发，并基于Kubernetes原生动态扩缩容特性，更易应对突发流量，合理分配使用资源。
• 对于操作单个Key的命令，Proxy会根据Key所属的Slot（槽）将请求发送给所属的数据分片。
• 对于操作多个Key的命令，如果这些Key是储存在不同的数据分片，Proxy会将命令拆分成多个命令分别发送给对应的分片。
（1）处理失败节点, 对部分节点重启后的无效ip、状态为noaddr的僵尸节点进行forget操作；
（2）处理不可信节点 (所有handshake状态的节点)，发生于某一个节点被移除（由forget node触发），但试图加入集群时，即该Pod在Operator角度下存在，但实际集群节点并不需要该节点，处理方式为删掉这个Pod，并再次做forget操作直到Pod被删除。
为StatefulSet中的Pod建立主从关系，同时给其分配Slots。若当前Master数量同预期不一致，则对应扩缩容操作，具体见’集群扩缩容’的横向扩缩容小节。
从代理获取Redis Server信息，将集群信息同步到所有的代理上，代理中不存在的Server ip做移除操作。
若代理中无可用Redis Server, 表示被全部移除，则添加一个，代理可自动发现集群其他Redis节点。
Redis部署最小资源对象为Pod，Pod是Kubernetes创建或部署的最小/最简单的基本单位。
当启动出错，例如出现“CrashLoopBackOff”时，Kubernetes将自动在该节点上重启该Pod,当出现物理节点故障时，Kubernetes将自动在其他节点上重新拉起一个。
Pod未出问题，但程序不可用时，依托于健康检查策略，Kubernetes也将重启该Redis节点。
节点纵向扩容时，使用StatefulSet的滚动升级机制，Kubernetes将逆序重启更新每个Pod，提高了服务的可用性。
Kubernetes本身不处理Redis 多个Pod组建的集群之间的部署关系，但提供了部署策略，为保证特定场景下的高可用，如因物理节点导致所有Redis节点均宕机，CRD在设计中加入了亲和与反亲和字段。
默认使用 podAntiAffinity 做节点打散，如下所示实例instance1的所有 Pod 将被尽可能调度到不同的节点上。
Redis 服务运行期间不可避免的出现各种特殊情况，如节点宕机、网络抖动等，如何持续监测这类故障并进行修复，实现 Redis 集群的高可用，也是 Operator 需解决的问题，下面以哨兵模式模式为例描述集群如何进行故障恢复。
主节点宕机：因物理节点驱逐、节点重启、进程异常结束等导致的Redis主节点宕机情况，哨兵会进行切主操作，然后Kubernetes会在可用物理节点上重新拉起一个Pod。
从节点宕机：哨兵模式的Redis集群未开启读写分离，从节点宕机对服务无影响，后续Kubernetes会重启拉起一个Pod，Operator会将该Pod设置为新主节点的从节点。
集群全部节点宕机：发生概率极小，但基于持久化可将服务影响降至最低，集群恢复后可继续提供服务。
节点网络故障：主从模式下配置了三个哨兵用于集群选主操作，哨兵集群的每一个节点会定时对 Redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。
当节点被一个 Sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。
如果客观下线的 Redis 节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。
纵向扩缩容主要指Pod的CPU、内存资源的调整，基于Kubernetes的特性，只需修改实例对应的spec字段，Operator的调和机制将持续监测参数变化，并对实例做出调整 。当修改cpu 、内存等参数时，Operator同步更新StatefulSet的limit、request信息，Kubernetes将逆序滚动更新Pod，滚动更新时，若停掉的是主节点，主节点的preStop功能会先通知哨兵或者集群进行数据保存，然后做主从切换操作，从而将服务的影响降至最低。更新后的主从关系建立以及哨兵monitor主节点功能也由Operator一并处理，全过程对客户端无感知。主从版、集群版在该场景下均支持秒级断闪。
横向扩缩容主要指副本数或节点数的调整，得益于 Kubernetes 的声明式 API，可以通过更改声明的资源规模对集群进行无损弹性扩容和缩容。
Redis Server扩容操作时，主从版本中Operator将获取新节点ip, 新启动节点将在下一轮调和时触发slaveof 主节点操作，且同步过程中，哨兵不会将该节点选为主节点。集群版本中Operator将在同步节点信息后进行分片迁移，保证所有节点上的Slots尽可能均匀分布。
Redis Server缩容操作时，主从版本中Operator将逆序销毁Pod，销毁时会先询问哨兵，自己是否为主节点，若为主节点则进行先failover操作再退出。集群版本中Operator中会先进行分片迁移，再对该节点做删除操作。
代理的扩缩容，更易实现，根据流量波峰波谷规律，可手动定期在波峰到来时对 Proxy 进行扩容，波峰过后对 Proxy 进行缩容；也可根据HPA实现动态扩缩容，HPA也是Kubernetes的一种资源，可以依据Kubernetes 的Metrics API的数据，实现基于CPU使用率、内存使用率、流量的动态扩缩容。
本次以 Redis 为范例，阐述了有道基础架构团队在基础设施容器化道路上的实践，Redis上云后将大幅缩短集群部署时间，支持秒级部署、分钟级启动、启动后的集群支持秒级自愈，集群依托于哨兵和代理的特性，故障切换对用户无感知。
有道架构团队最终以云平台的形式提供中间件能力，用户无需关注基础设施的资源调度与运维，重点关注具体业务场景，助力业务增长。未来，将进一步围绕Redis实例动态扩缩容、故障分析诊断、在线迁移、混合部署等内容展开探索。
Kubernetes 是一个容器编排系统，可以自动化容器应用的部署、扩展和管理。Kubernetes 提供了一些基础特性：
部署：部署更快，集群建立无需人工干预。容器部署后可保证每个的Redis节点服务正常，节点启动后将由Operator持续监测调和Redis集群状态，包括主从关系、集群关系、哨兵监控、故障转移等。
资源隔离：如果所有服务都用同一个集群，修改了Redis集群配置的话，很可能会影响到其他的服务。但如果你是每个系立用一个Redis群的话，彼此之间互不影响，也不会出现某一个应用不小心把集群给打挂了，然后造成连锁反应的情况。
(2) 网络故障：因宿主机网络故障带来的实例延迟高，哨兵可进行主从切换，而为了保证集群的健康，将由Operator负责同步集群信息。
扩缩容：容器部署可根据limit和request限制实例的cpu和内存，也可以进行扩缩容操作，扩容后的故障恢复由Operator处理。
节点调整：基于Operator对CRD资源的持续调和，可在Operator的Controller中为每个Redis实例进行状态维护，因此，节点调整后带来的主副关系建立、集群Slots迁移等均可自动完成。
自 2017 年 10 月推出有道翻译蛋开始，网易有道已先后推出了二十余款智能学习硬件产品，包括有道翻译王、有道口袋打印机、有道超级词典、有道词典笔、有道听力宝等。
在近期有道词典笔的全新软件升级中（关联阅读：全新软件升级！真的很有料），有两个重要的优化，分别是：
为了给用户带来更好的体验，有道 AI 团队选取了多种真人发音素材，从来自公司内部、真实用户和 native speakers 等人群中选取足够大的样本发放调查问卷，从发音准确度、音色喜爱度等方面进行打分，并和专业的发音进行比较，最终选取了目前版本中的音色。
在语言学习场景中，机械式的发音不仅让人觉得枯燥乏味，而且会影响口语学习的效果。最自然、最理想的交互莫过于通过人的声音进行交流。如何让智能学习硬件的发音接近真人，是一个重要的课题。
同时，通过有道 AI 团队对语言模型的不断训练，有道词典笔的发音准确度再一次得到突破，在扫描句子的过程中，有道词典笔可以快速预判语义，轻松读对一些英语学习者和 AI 都非常容易读错的单词，比如「多音词」。
这些能力的背后，是有道 TTS 语音合成技术的加持。本文将会详细介绍有道 TTS 技术的相关思考和实践。
文本分析前端的主要作用是将语句转换为语言学特征，主要是音素序列和韵律特征, 其中音素序列决定 TTS 是否正确读对了文本；韵律特征决定 TTS 的停顿位置、自然度等，这也是有道 TTS 技术能够实现接近真人发音和正确朗读多音词的关键所在。
传统的文本分析模块会单独建模每个任务，并且串行处理效率较低，这种做法在嵌入式场景中难以实现性能和质量的平衡，多个任务分离也会提高系统的维护成本。
相比于传统方案，有道 AI 团队基于 BERT 预训练模型进行了多任务建模，将多个任务进行统一建模，大大提高了效率。
这些优化能够支持 TTS 前端的文本正则化、多音字判别、韵律预测等任务，使有道系统能够在设备端合成低发音错误、韵律自然和感情丰富的高质量语音。
结合词性、词义等细化多音字模型标签，使得建模更高效；在中文古诗词、文言文发音上，通过 ssml 技术将词典笔海量权威发音词典资源应用到TTS 发音中；
通过构建bert多任务模型，联合预测多音字、韵律、分词、词性任务，多个任务之互相促进不仅了提升多音字模型和韵律模型的准确率，同时也节省了参数量；最后通过蒸馏技术，小参数量多任务模型在保证质量的同时，也达到嵌入式性能要求；
系统集成:在系统集成阶段，工程化团队通过自研bert pipeline技术，更进一步优化了内存和推理时间；
通过这些方面的工作，最终推出了基于预训练模型的多任务架构 TTS 中英混前端，保证了 TTS 合成的发音正确性和韵律停顿。
声学模型的主要作用是将语言学特征转换为对应的声学特征。常见的神经网络声学模型大致可以分成两大类：
一是自回归声学模型：比如 Tacotron、Tacotron2，优点是高自然度，缺点是性能较差；基于 attention 的自回归声学模型难以建模长语音，更容易出现丢字、重复的现象。
二是非自回归声学模型：比如Fastspeech、Fastspeech2，优点是并行生成声学特征，性能好，对长句建模足够鲁棒；缺点是韵律建模略差于自回归声学模型。
综合质量和性能，有道 AI 团队最终选择了基于 VAE 的非自回归声学模型。原因在于它有以下优势：
同时，我们针对一部分算子的计算耗时占总时长比例较大的问题进行了工程上的优化，进一步改善了系统整体的实时率。
声码器的作用是将声学模型输出的声学特征转换成语音时域信号。它直接影响着合成语音的音质，因此对于用户体验来说至关重要。
一是音质问题。声码器模型的建模能力不足，会直接导致合成语音产生底噪或者电音。但如果仅仅只是单纯地加大模型的参数，则会影响系统的推理速度。
二是性能问题。声码器的计算量在语音合成的整个框架中占比较大。要在嵌入式场景中合成高质量的语音，需要一个足够大、建模能力足够强的声码器模型。
但由于设备芯片的算力弱、内存小，大的声码器会导致体验延时明显上升。从用户的角度出发，延时过长，用户等待时间过久，自然不会有好的体验效果。
为了解决以上难题，通过大量实验和综合比对，最终有道 AI 团队选择了基于 GAN 方案的声码器。
首先是针对不同场景使用不同的模型配置，有道 AI 团队对 GAN 声码器中的生成器模块进行了参数的细致调整，让它能够成功应用在嵌入式场景下，不同于传统参数声码器的机械感与模糊感，基于 GAN 的神经网络声码器可以合成高自然度、高清晰度的音频，缩短了离线 TTS 和在线 TTS 质量上的差距。
此外，我们还在模型的量化、压缩方面做了大量的工作，大大提升了语音合成的速度，明显降低了系统的资源占用。
在智能硬件产品人机交互中，语音合成技术扮演着非常重要的角色，但在落地中面临着很多挑战，其核心是硬件计算资源与合成语音质量之间的矛盾。
如何更快地、更稳定地在有限资源下提供高质量的语音合成技术是有道 AI 团队的目标和关注的重点。
目前，有道 TTS 语音合成技术已应用在许多内部和外部的在线场景和嵌入式场景，并表现出了相对传统方案更加稳定、更加鲁棒的合成效果。
相信了解算法同学经常会说动态规划太难了，看到题目完全不知从何下手，或者是说“一看题解就会，一看题目就废”这样的一个状态。本质上是由于学习动态规划的时候，学习方法不对，最终导致南辕北辙，没有掌握其中精髓。而动态规划与递推算法又有着暧昧不清的关系，我们选择先从递推算法入手，一步一步揭开动态规划的神秘面纱。
随着前端项目的规模不断变大，多人协同开发已经成为了前端开发的标配，随之而来的就是 TypeScript 被越来越多的项目所使用，这种变化并不是对技术的盲目追求，而是业务驱动下的技术进步，TypeScript 通过对原生 JavaScript 提供强类型加持，在很大程度上提升了代码质量，大大降低了多人协同场景下不同模块接口相互调用可能出现的隐性 bug。本系列分享来源于常开发中对 TypeScript 工具类型的一些学习和使用体会，本系列文章分为上中下三篇，通过本系列分享，希望可以达到如下几个目的：
发表评论