专业术语简介【一】：没有银弹、加盐、毛刺、冒烟测试、热备

文章专业术语简介【一】：没有银弹、加盐、毛刺、冒烟测试、热备分享给大家，欢迎收藏极客之家，专注分享技术知识

〇、前言

了解行业术语是一个程序猿的基本素养，只有更深入的了解才能与其他人畅快沟通，下面来简单汇总下，会持续更新。

欢迎评论区补充，博主会逐个加入后续文章。

一、“没有银弹”

从字面意思来看就是，没有银色的子弹。当然不可能这么简单。

其实，它出自计算机科学家布鲁克斯《没有银弹》一书，意思是：“没有一种单纯的技术或管理上的进步，能够独立地承诺在 10 年内大幅度地提高软件的生产率、可靠性和简洁性”。

但为什么说不能大幅度的提高软件的生产力为”没有银弹“呢？

布鲁克斯用形象的比喻来论述软件工程中存在的“陷阱”：

  在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。

  而大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个拖住进度、超出预算、存在大量缺陷的怪物。

  惊悚故事里，人们只有用银弹（银质子弹）才能消灭人狼，而布鲁克斯认为，在软件工程中“没有银弹”，没有一种能够遏制软件向“怪物”变异、同时还可大幅提升开发效率和产品质量的武器。

软件开发的本质问题——复杂性、一致性、可变性和不可见性——是固有的，而非偶然的。这些问题如同软件世界中的狼人，无法被单一的银弹所消灭。

软件开发是一个复杂的过程，需要持续的努力和创新，而不是依赖于所谓的“奇迹”解决方案。软件工程师和项目管理者应该采取多种方法和工具，结合实际情况，逐步改进开发流程，提高软件质量。

现实中，银弹的概念被用来警示那些寻求快速解决方案的冲动。它告诉我们，软件开发没有捷径，只有通过不断的学习和实践，才能逐步提升我们的技能和项目的质量。银弹的使用方式，更多的是作为一种思考工具，帮助我们识别那些看似诱人，但实际上可能带来更多问题的“神奇”解决方案。

参考：https://blog.csdn.net/weixin_33724046/article/details/86266963

二、“加盐”

盐（Salt）：在密码学中是指：通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为“加盐”。

密码的存储大致可以分为三代。如下：

第一代，就是直接将明文的密码直接存储在数据库中。

当然这是十分危险的，不法分子一旦攻击数据库，全部的账户信息将泄露，后果很严重。

第二代，通过不可逆加密算法，将密码加密后的密文存入数据库。

为了弥补第一代的明文存储缺陷，后来人开始将明文的密码进行加密后存入数据库，典型的加密算法是 MD5 和 SHA1 等。当用户登录时，根据用户输入的内容，进行指定的 MD5 或 SHA1 加密后，再与数据库中存储的密文进行比较，进行登录验证。

类似于 MD5 这种不可逆的加密算法，不可能被破解，某种程度上满足的密码保密的需求，即使数据库用户信息泄露，也无关紧要。但是其中有个致命的缺点就是，同样的明文，加密后的密文结果相同。当然设置一个足够复杂的密码可以保证密文更加安全，但是设置一个简单的密码，就会很容易通过常用密码库被破解。

第三代，在对密码进行不可逆加密算法的基础上，添加一串随机字符和密码拼接后进行加密。

为了解决第二代的缺点，第三代密码设计诞生了。

用户信息表，除了用户名和密码之外，新增了一个名为 Slat 的字段。Salt 可以是任意字母、数字、或是字母或数字的组合，但必须是随机产生的，每个用户的 Salt 都不一样。用户注册的时候，数据库中存入的不是明文密码，也不是简单的对明文密码进行散列，而是MD5(pwd + Salt)，当用户登陆的时候，同样用这种算法就行验证。

虽然加盐可以大大增加密码的强度，但是理论上讲还是可以配暴力破译的，但是这个破译的代价当然也是非常大的。

实际项目中，Salt 不一定要加在最前面或最后面，也可以插在中间嘛，也可以分开插入，也可以倒序，程序设计时可以灵活调整，都可以使破解的难度指数级增长。

详情参考：https://zhuanlan.zhihu.com/p/22860282?from_voters_page=true

三、毛刺

3.1 CPU 毛刺

CPU 毛刺通常是某时间段（相对较短）内，CPU 消耗激增导致的。

CPU 毛刺会导致诸多异常发生，比如：

• 平响毛刺：平响”通常指的是系统响应时间的平均值，而“毛刺”是指在这个平均值附近出现的短暂且剧烈的波动。这种波动可能是由于某些突发的任务或事件导致的 CPU 使用率瞬间升高，从而影响了系统的响应时间。例如：大量消耗 CPU 的定时任务、垃圾回收（GC）的影响、所依赖的下游服务的延迟、网络抖动等等。
• 任务挤压：是指由于系统资源不足或任务调度不合理，导致部分任务无法及时得到处理，从而在系统中积压的现象。这可能会导致系统的响应时间变长，甚至出现任务丢失或系统崩溃的情况。例如：CPU 资源不足、内存不足、I/O 瓶颈、任务优先级设置不合理等等。
• 缓存更新不及时：是指系统中的缓存数据与实际数据不一致，或者缓存数据过期，导致系统在访问缓存时无法获取到最新的数据。这可能会影响系统的性能和数据的准确性。例如：缓存策略不合理、系统负载过高、数据变更频繁、缓存失效机制不完善等等。

这些异常会大大降低服务的可用性，其实问题本质就是时延问题。

以下是几个关于 CPU 毛刺的诱因：

• 大量消耗 CPU 的定时任务

一般情况下系统中会有一些定时任务，例如：代码中经常起几个线程定时刷一下本地缓存、CT“关键任务（Critical Task）”定时检查服务状态或者其他事项、LogStream 基础设施（日志系统中用于管理和处理日志流的关键组件）等等。

这类定时任务难免会占用 CPU，如果这些操作中涉及大量 RSA 操作（基于 RSA 算法的加密和解密过程）、正则过滤、I/O 操作等等，CPU 瞬间升高是不可避免的。

如果压测过程中没有碰到这部分任务，但是线上峰值来了恰好定时任务也执行了，服务可能就部分不可用了，所以在评估真实容量时一定要把所有的 CPU 消耗全部考虑进来。

如果涉及到极端场景下的性能优化，就要考虑把这些操作给停掉保证服务器的纯粹，只干一件事，互不影响。

• 人为操作

一般情况下，系统的线上环境中，宿主机的权限是严格控制的，能够限制在操作系统上操作的命令。

但是也存在部分场景权限限制不到位，或者即使限制了常见的会导致异常的命令，但可能有人在“正则&awk”（在文本处理和数据分析领域，正则表达式常与文本搜索工具如 awk 结合使用，以实现更强大的数据处理能力）查一个 1 个 G 的日志文件。

所以最好的方式就是进一步限制，日志、脚本等操作可以统一入口脚本或启动程序。添加统一的日志记录功能，记录脚本的执行过程、参数、返回值等信息。入口脚本可以对输入参数进行验证和解析，确保传递给业务脚本的参数是正确的。

• 硬件问题

实际上谁都无法保证服务器等硬件设备是完全没有问题的，虽然这应该是 OP（Operations 运营人员或运维工程师）干的活，但是作为 RD（Research & Development 研发工程师 从事研究与开发工作的专业人员）还是需要保持对于服务各种强依赖的不信任。

就比如服务器，很多快过保的服务器可能提前发生性能衰退，如果用容器的话，每次可能宿主机都不相同，这样的情况更要谨慎。

• 可预知但是没在意的程序逻辑

例如 Redis，导致 Redis 的 CPU 使用率飙升的高负载请求、HGETALL 获取哈希表中的全部值、大键值操作、Lua 脚本处理大量数据等，我们知道会导致 CPU 飙升，但是觉着就偶尔几次所以没在意。

再例如 Java，代码中相对耗性能的操作，比如说 I/O、RSA 计算等，一般都会有针对性的处理，却时常忽略了进程中 GC 对于性能影响的占比，在常规流量情况下 GC 的占比可能也就 1% 以下，但是如果流量升高之后我们代码的“垃圾特性”就开始凸显了，动辄几个 Full GC，整个 GC 过程的 CPU 消耗可能都会占到整个进程的 CPU 使用的 50% 以上。

很多时候这些特性会被研发人员忽略，以为程序本身的处理逻辑不可人为干预，实际恰恰相反。应该从一开始写代码时，就得关注到并且深入了解所有相关的工具，向上到服务层面的影响、向下到 CPU、内存的影响，对外到对于其他进程的影响。

3.2 耗时毛刺

耗时毛刺会直接影响到服务的可用性，分析解决问题通常也是从平响毛刺下手，再到代码，再到 CPU、内存、带宽等，最后重回代码来操作的。

对于耗时，出现毛刺通常是因为在某一时间间隔内请求处理受到阻塞（包括连接处理的阻塞、连接内处理逻辑的阻塞），其中的主要的原因大概率是上面提到的 CPU 毛刺。

• 连接处理的阻塞

这种阻塞往往意味着服务处理的极限，因为连接内部整体 CPU 消耗相对平均，由于 CPU 资源受限很多连接虽然建立了，但是部分请求迟迟得不到处理，致使请求处理存在问题（不响应：502 发生）或者处理时间十分长（毛刺产生）。

如果应用已经优化到极致了，可以理解为这种情况就是服务器的处理极限了，这时候解决方式只有扩容。

如果代码还没有优化，那就先针对各种性能分析的 Profile 优化代码，比如：减少单个请求中要消耗的 CPU、请求处理过程的耗时；针对 I/O 处理：尽可能不做、合并 I/O、同步改异步、使用更加高效的 API；针对 CPU 大量消耗：只能尽可能的不做，或者替换成代价小的操作方式，例如大数据量的序列化操作、 RSA 算法操作等。

• 链接内处理逻辑的阻塞

代码中的 GC 操作导致用户线程暂停工作。此时就只能优化代码，尽可能少的 STD，根据应用场景选择垃圾回收器，适合的最好的。STW（Stop-The-World）事件是指在垃圾回收（Garbage Collection, GC）过程中，应用程序的执行被暂停，以便进行内存管理操作。这种暂停通常是短暂的，但在某些情况下可能会对应用程序的性能产生显著影响。

下游响应较慢，但超时时间较长。很多时候平响毛刺并不直接因为当前服务的原因，例如下游耗时时间忽然增加，同时超时时间又设置的很长，那么当前服务就会随着下游的抖动而一起抖动，如果依赖的下游很多，那么随机出现毛刺的概率也会相应的提升。

还有就是操作系统的问题，可能因为某些服务导致当前服务器负载加剧，CPU 爆满，类似上一节的 CPU 毛刺。

对于如何排查，主要就是要看下资源消耗的排名，找到进程和下级线程，再进一步查下代码找具体原因，本文就不再介绍了。

详情参考：https://cloud.tencent.com/developer/article/1769570

四、冒烟测试

• 概念和目的

Smoke Testing 的概念最早源于制造业，用于测试管道。测试时，用鼓风机往管道里灌烟，看管壁外面是否有烟冒出来，以便检验管道是否有缝隙。这一测试显然比较初级，更深层一点的测试至少要进行渗油测试、带压测试等等。Smoke Testing 只是一种初级、直观的测试。

软件测试中的 Smoke Testing 实际上用的是其引申含义，而且是引申了不止一道的含义。在这里，Smoke Testing 其实是个俚语就跟很多其他源于美国软件行业的名词一样。Smoke Testing 在软件测试中的意义，应该说取的是其原始概念中的目的而非手段。

冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。因此可以说，Smoke Testing 是预测试。这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。

冒烟测试可以由开发人员执行，也可以由测试人员来执行。即，在版本编译后正式提交测试之前由开发人员执行；或开发发布版本后，测试人员在接受这个版本作为正式版本进一步测试前执行。

如果不通过，则打回开发那边重新开发；如果通过测试，才会进行下一步的详细测试（功能测试，集成测试，系统测试等等）。

• 大概的步骤

明确测试目标：确定需要测试的主要功能和范围。根据软件的变更，包括新需求的实现、Bug修复，设计出更改满足预期的功能级 CheckList。

准备好测试环境。如：软件的运行环境是嵌入式产品，如手机，数码相机，医疗仪器等，需准备好用户使用的真实运行环境。如果是windows平台运行环境，请准备干净的操作系统。

确定好测试方法。例如手动执行、自动化执行（编写自动化测试脚本）、每日构建测试（通常由开发人员在提交代码后自动触发）、回归测试（保证问题解决的同时判断是否对其他功能有影响）等等。

执行 CheckList。开始确认基本功能有效，足以支持更进一步的详细、全面测试。

五、热备

热备（Hot Standby）是一种高可用性解决方案，用于确保在主服务器发生故障时，备用服务器能够立即接管工作，从而最小化系统的停机时间和数据丢失。

• 定义

热备是一种备份机制，其中备用系统始终保持运行状态，并且与主系统同步更新数据，具有一致性。主系统和备用系统可以无缝切换。

• 特点

实时同步：备用服务器与主服务器之间保持数据的实时同步，确保两者的数据一致。

快速切换：由于备用服务器始终处于运行状态，一旦主服务器出现故障，可以迅速切换到备用服务器，几乎不影响系统的正常运行。

高可用性：通过热备机制，系统可以在主服务器发生故障时继续提供服务，从而提高整体的可用性和可靠性。

• 应用场景

热备主要适用于对系统可用性要求较高的场景。例如：

数据库系统：在数据库系统中，热备常用于确保数据的持续可用性。例如，Oracle、MySQL 等数据库管理系统都支持热备功能。

Web 服务器：在 Web 服务中，热备可以用于确保网站的持续访问。当主服务器出现故障时，备用服务器可以立即接管网站的访问请求。

金融交易系统：在金融行业，热备机制被广泛应用于交易系统，以确保交易的连续性和数据的完整性。

• 实现方式

硬件热备：通过专用的硬件设备来实现热备功能，如使用存储区域网络（SAN）或网络附加存储（NAS）设备来同步数据。

软件热备：通过软件解决方案来实现热备功能，如使用数据库复制技术或应用级复制技术来同步数据。

云服务热备：利用云计算平台提供的热备服务，如AWS的多区域部署或Azure的异地多活架构。

热备机制能够显著提高系统的可用性和可靠性，减少因故障导致的停机时间。同时，由于备用服务器始终处于运行状态，可以快速响应故障切换请求。但是，实施热备机制需要额外的硬件和软件资源，增加了系统的复杂性和成本，另外如何实现热备，对技术的要求也是一个巨大的挑战。

版权声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！