背景

网易云信作为市场上领先的音视频/IM PaaS 服务供给商之一。对外供给产品服务首要以 SDK 形状，产品服务触及渠道首要有 Android/iOS/Windows/mac OS/Linux/Web，触及到框架有：小序/RN/Fluttter/Electron/Cocos2d/Unity。

作为以 SDK 作为产品形状的企业研制人员，最首要的使命便是要确保 SDK 质量安稳与牢靠，着重服务高质量与高可用，着重 API 易用性。为此云信根据 toB 丰厚的研制经历，探索出了一套针对 toB 的行之有效的质量确保体系。云信质量确保体系首要涵盖了两个阶段：研制阶段，线上运转阶段。

研制阶段质量确保

为了尽或许有效地确保研制阶段的代码质量，云信的代码质量确保过程可以概括为下图：

重构与计划评定

云信对于下文中契合时刻长短界说的中改变以及重构以上界说的改变，都会安排专家进行计划评定作业。技能维度本质上是衡量立异的维度。因此一般可以从智能化，立异度，基础性，影响度等一级目标打开。

重构的界说： 在不改变软件可调查行为的前提下，调整其结构，进步其可理解性，降低其修正成本。

重构的要害在于运用大量微小且保持软件行为的过程，一步一步完结大规划的修正。即便重构没有完结，也可以随时停下来，确保代码的运作。

对于“可调查行为”的理解：从用户所关心的角度而言，重构前后的软件体现应当共同（SDK API 无改变，调用次序没有产生改变、软件输入输出共同）。但是重构所带来的性能进步、接口改变、调用时序改变乃至潜在 bug 的优化都不放在“可调查”的范围内。

重构的原因：

• 当时架构不足以支撑未来的需求；
• 当时架构性能存在很大的优化空间；

重构的含义：

• 改进软件的规划，软件逻辑更加清晰，消除重复代码；
• 软件可读性更强，更容易理解；
• 处理代码架构不调整就无法根本上修正的 bug；
• 处理代码架构规划导致无法满意事务需求的问题；

重构区分： 重构的区分可以依照规划程度、时刻长短两个维度来界说。

依照规划程度区分：

• 小型重构： 对代码的细节进行重构，首要是针对类、函数、变量等代码等级的重构。比方常见的规范命名（针对言不尽意的变量再命名），消除超大函数，消除重复代码等。一般这类重构修正的地方比较集中，相对简略，影响比较小、时刻较短。所以难度相对要低一些，我们完全可以在日常的随版开发中进行。
• 中大型重构： 是对代码顶层进行重构，包含对体系结构、模块结构、代码结构、类关系的重构，详细体现有体系内部运转逻辑产生了改变，模块调用时序产生了调整，模块处理耗时&内存产生改变，体系内模块依靠方法产生了改变等等。一般采取的手法是进行服务分层、事务模块化、组件化、代码抽象复用等。这类重构或许需求进行准则再界说、模式再界说乃至事务逻辑再界说。触及到的代码调整和修正多，所以影响比较大、耗时较长、带来的危险比较大（项目叫停危险、代码 bug 危险、事务漏洞危险）。

依照时刻长短区分：

• 小改变： 一般对于 1 人日以内作业量的需求为小改变；
• 中改变： 1-4 人日以上称为中改变，但不触及到模块的主流程的改变；
• 重构： 个人作业量超越一周，也便是 5 个作业日的，触及到 pipeline 流程中的多个模块改变。

Code Review

云信采用 Gitlab + 自建辅佐检测服务器的方法确保 Code Review 的流程被执行到位。

一起为了配合 Code Review 合规性检查中的“至少有 2 名评定人评定经过，且其间至少一名为模块的代码评定人”这个经过规范，需求整理和确认各个模块的代码评定人。后续合规性检查中会结合列表中的评定人进行校验。

继续集成

高可用 CI/CD 渠道建造

《重构-改进代码既有的规划》作者 Martin Fowler 大师在《继续集成》一书中的界说，“继续集成是一种软件开发实践。在继续集成中，团队成员频繁集成他们的作业成果，一般每人每天至少集成一次，也可以屡次。每次集成会经过自动构建（包含自动测验）的查验，以赶快发现集成过错。许多团队发现这种办法可以明显削减集成引起的问题，并可以加快团队协作软件开发的速度。

从整个研制阶段的确保流程可以看出，继续集成是要害一环。而对于云信来讲传统的 Jenkins 服务或许 Overmind 相关办理体系根本无法满意使命并发 40 几个上的要求以及单个使命可以输出 4-6 个渠道产品的诉求，所以需求云信自研一套高可用 CI/CD 的渠道。

传统的 Jenkins 服务

原生 Jenkins 是一拖多结构。全局仅有的 Jenkins master 是整个集群的中心节点，担任集群中一切的事务，乃至可以担任构建使命。因此存在 Jenkins master 单点故障, 一旦使命多了之后就会产生严重的 Block 状况，执行一个构建使命或许需求十几个小时。

高可用 CI/CD 服务

为了处理以上 Jenkins master 的单点故障，满意使命的高并发，自研了一套高可用服务。

高可用 CI/CD 办理中心担任保护体系中的一切节点的状况。要加入集群的一切的高可用 CI/CD 后端，Jenkins master 节点， 打包机节点都要向高可用 CI/CD 办理中心注册。需求运用集群中某个子模块节点的时分也要向办理中心请求。一起办理中心会定时检查每个节点的健康状况，确保每次请求返回的都是健康的节点。

办理中心由一个 Leader 和四个 Standby 组成。Leader 是办理中心的中心，担任集群中一切决议计划，一切的 Standby 会同步 Leader 的数据，一旦 Leader 故障，其间一个 Standby 就可以经过推举成为新的 Leader。

效果比照

静态代码检测

代码检查可以有效地进步代码质量，快速定位代码躲藏的过错和缺点，帮助代码规划人员更重视于分析和处理代码规划缺点，明显削减代码逐行检查上花费的时刻，进步软件牢靠性并节约软件开发和测验成本。静态代码检查可以检查出的首要问题有：变量未初始化、数据类型不匹配、返回局部变量、数据越界、内存或许存在泄露点等。

单元测验

单元是人为规则的最小的被测功用模块。单元测验是在软件开发过程中要进行的最低等级的测验活动，软件的独立单元将在与程序的其他部分相阻隔的状况下进行测验。单元测验是为开发代码质量保驾护航的一个重要环节，云信已经在音视频 SDK 开始逐渐落地单元测验，确保复杂音视频 SDK 体系的各个子体系与子功用功用的可用性以及安稳性。

基线对齐

针对不同的场景、不同的手机性能等级，云信都会有自己的性能基线（产品出厂的规范），包含内存占用状况、功耗状况、音频的 MOS 分、QoS（在敞开音视频，不同弱网状况下重视卡顿率、码率改变、分辨率等状况）、视频首帧的传输时刻。

API 接口测验

云信自研了一套 Hermens 自动化渠道体系，用于 API 接口的测验作业。

以上是 Hermens 自动化测验渠道体系的架构，该体系涵盖了以下几种测验范畴。

• API 自动化测验

  研制人员可自主经过脚本写 API 测验用例，集成到 CI 的构建 pipeline 中去，作为研制阶段的一个环节，做到 Daily Build 的自动化测验。

• 用户场景测验

  经过模仿用户的各种运用场景如 1对1 场景、KTV 场景、直播场景等等， 模仿 API 的调用。

• 随机 API 测验

  经过模仿用户随机调用 API, 验证 SDK 体系是否存在溃散的问题或许功用紊乱问题，确保体系的容错性，确保体系的健康。

• API 组合测验

  经过 API 组合测验，验证一些重要的 API 组合调用功用的可用性以及幂等性。

• 竞品 API 测验

  经过写竞品 DEMO，模仿两边体系相同参数输入，获取两边体系的体现差异性，从而优化与改进 SDK，如输入相同的音视频参数，经过录制音视频通话，经过音视频专家和东西，比照两边在用户可感知范围上的差异。

线上运转阶段质量确保

正如德内拉.梅多斯《体系之美》书中所讲，抱负的体系应该有适应性、自安排性、层次性特性。适应性是因为体系内部结构存在许多相互影响的反应回路，正是这些回路相互支撑，即便在体系遭受巨大的扰动时，依然可以以多种不同的方法使体系康复至原有状况。自安排性是指体系具有学习多元化复杂化进化的才能，体系可以经过自主学习可以衍生出新的事物或许技能。层次性是指一个大体系中包含了若干小子体系，体系和子体系的包含和生成关系就被称为层次性，各个子体系内部的联络要多于并强于子体系之间的联络。云信遵从以上抱负体系的三个特性方向考虑与构建体系。

如果把线上质量打磨幻想成是一个体系工程的话，SDK 版别在很多的试验场灰度是体系的输入，体系输出是一个质量安稳与牢靠的 SDK，反应回路有两条：

• 线上客户到 SO 团队，再流转到研制团队的反应回路；
• 反常自动感知体系树立的反应回路。

经过以上版别质量的体系化工程的打造与实施，可以有效地确保交给给大客户的版别是安稳牢靠的，详细质量打磨战略如下：

质量打磨战略

版别质量打磨战略

由上图可知，线上质量打磨战略体系，反应回路首要有以下两条通道：

• 客户经过电话/微信/QQ 等线上服务渠道反应（Bug 、API 调用方法、场景计划等易用性问题反应）；
• 反常感知体系（CRASH/ANR/OOM/内存泄漏反常、接口调用次序反常、性能（内存/CPU）反常、事务反常等等）；

经过对以上两条回路反应的问题进行版别问题修正，然后从头发布，不断体系迭代增强，直到线上场景掩盖、日活、 bug 率到达预期的规范，才被答应能交给给大客户。

反常感知体系（先于用户发现）

为了可以及时发现线上服务反常，先于客户发现问题，在客户服务上争夺自动，进步客户的满意度。云信构建了一整套完整的 SDK 自动反常感知与监控体系以及线上应急响应体系，该体系涵盖了各个 C 端，各个渠道，Android/iOS/macOS/Linux/Windows（Web 端是根据云音乐反常监控渠道&自建了一套反常追寻体系），对于用户的反常（代码运转反常\事务反常）进行了立体式的反常监控。

以下是整个体系的架构图：

代码反常监控模块

支撑 Android/iOS/Windows 的渠道层与 Native 库的 Crash（如反常监控模块支撑Android jvm Crash 反常、也支撑 Native 库的反常）、线程卡顿、OOM 、内存泄漏、ANR 等反常的捕获。

事务反常监控服务

除了以上代码上的反常，云信正在完善一系列的反常传感器（事务反常模型），音视频事务反常建造（无声、音频视频卡顿、首帧耗时、httpdns 高可用反常数据的监控）、用户运用量反常监控、API 调用次序反常。

账号体系

传统的反常捕获体系是根据 App 维度来统计 Crash 等反常信息的，而做 PaaS 的，希望是看到详细的 PaaS 产品及对应的 SDK 维度来统计 Crash 信息，因此规划了三级的账号体系，以支撑每个层级来做聚合统计监控。

三级账号体系说明如下：

• 公司等级。如易盾、云信等 PaaS 服务厂商；
• 公司产品 SKU。如云信有 IM SDK、RTC SDK、播放器 SDK；
• SKU 下的子产品。如 RTC SDK 下有美颜、背景替换、水印等插件化的子产品；

监控体系

当线上产生 Crash 反常、线程卡顿反常、ANR 、OOM 等反常的时分，体系会自动创建 Jira ,一起 Jira 流转到指定的模块担任人。一起可以检查全体的 Crash 率、Crash 详细的仓库信息、仓库信息的反解。

反常解析服务

支撑 Android/iOS Crash 仓库的反解服务，未来将支撑 Windows/Linux/mac/Flutter 渠道的反常反解服务。一切 CI 出的产品的符号文件都将自动上传上传到 NOS 服务，当用户需求进行 Crash 仓库信息的反解的时分，反常解析服务会根据 Crash 对应的公司、产品、子产品号版别号、BuildId 等信息进行精准的解析。

总结

以上内容为云信针对 toB SDK 质量确保体系的考虑与建造实践。质量确保体系涵盖了研制阶段与版别交给阶段，从高可用的 CI/CD 建造、单测、静态代码测验、自动化测验、性能基线测验，再到反常自动感知体系的建造，每一个环节的实施与落地，云信终究希望交给给客户具有优秀的用户体验、牢靠而安稳的产品服务。