后端开发术语大全（下）_语言 & 开发_云加社区

如何提高架构的稳定性、可扩展性和易用性等能力？点击看大咖分享了解详情 



 写点什么

工欲善其事，必先利其器；士欲宣其义，必先读其书。后台开发作为互联网技术领域的掌上明珠，一直都是开发者们的追逐的高峰。本文将从后台开发所涉及到的技术术语出发，基于系统开发、架构设计、网络通信等几个方面让大家对后台来发有一个清晰的了解，讲解全面易懂。

监控告警

1. 服务监控

服务监控主要目的在服务出现问题或者快要出现问题时能够准确快速地发现以减小影响范围。服务监控一般有多种手段，按层次可划分为：

系统层（CPU、网络状态、IO、机器负载等）
应用层（进程状态、错误日志、吞吐量等）
业务层（服务/接口的错误码、响应时间）
用户层（用户行为、舆情监控、前端埋点）

2. 全链路监控

服务拨测：服务拨测是探测服务（应用）可用性的监控方式，通过拨测节点对目标服务进行周期性探测，主要通过可用性和响应时间来度量，拨测节点通常有异地多个。
节点探测：节点探测是用来发现和追踪不同的机房（数据中心）节点之间网络可用性和通畅性的监控方式，主要通过响应时间、丢包率、跳数来度量，探测方法一般是 ping、mtr 或其他私有协议。
告警过滤：对某些可预知的告警进行过滤，不进入告警统计的数据，如少量爬虫访问导致的 http 响应 500 错误，业务系统自定义异常信息等。
告警去重：当一个告警通知负责人后，在这个告警恢复之前，不会继续收到相同的告警。
告警抑制：为了减少由于系统抖动带来的干扰，还需要实现抑制，例如服务器瞬间高负载，可能是正常的，只有持续一段时间的高负载才需要得到重视。
告警恢复：开发/运维人员不仅需要收到告警通知，还需要收到故障消除告警恢复正常的通知。
告警合并：对同一时刻产生的多条相同告警进行合并，如某个微服务集群同一时刻出现多个子服务负载过高的告警，需要合并成为一条告警。
告警收敛：有时某个告警产生时，往往会伴随着其它告警。这时可以只对根本原因产生告警，其它告警收敛为子告警一并发送通知。如云服务器出现 CPU 负载告警时往往伴随其搭载的所有系统的可用性告警。
故障自愈：实时发现告警，预诊断分析，自动恢复故障，并打通周边系统实现整个流程的闭环。

服务治理

1. 微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于 HTTP 的 Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

2. 服务发现

服务发现是指使用一个注册中心来记录分布式系统中的全部服务的信息，以便其他服务能够快速的找到这些已注册的服务。服务发现是支撑大规模 SOA 和微服务架构的核心模块，它应该尽量做到高可用。

3. 流量削峰

如果观看抽奖或秒杀系统的请求监控曲线，你就会发现这类系统在活动开放的时间段内会出现一个波峰，而在活动未开放时，系统的请求量、机器负载一般都是比较平稳的。为了节省机器资源，我们不可能时时都提供最大化的资源能力来支持短时间的高峰请求。所以需要使用一些技术手段，来削弱瞬时的请求高峰，让系统吞吐量在高峰请求下保持可控。削峰也可用于消除毛刺，使服务器资源利用更加均衡和充分。常见的削峰策略有队列，限频，分层过滤，多级缓存等。

4. 版本兼容

在升级版本的过程中，需要考虑升级版本后，新的数据结构是否能够理解和解析旧数据，新修改的协议是否能够理解旧的协议以及做出预期内合适的处理。这就需要在服务设计过程中做好版本兼容。

5. 过载保护

过载是指当前负载已经超过了系统的最大处理能力，过载的出现，会导致部分服务不可用，如果处置不当，极有可能引起服务完全不可用，乃至雪崩。过载保护正是针对这种异常情况做的措施，防止出现服务完全不可用的现象。

6. 服务熔断

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

7. 服务降级

服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。

根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。
根据服务范围：可以砍掉某个功能，也可以砍掉某些模块。

总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。

8. 熔断 VS 降级

相同点：目标一致，都是从可用性和可靠性出发，为了防止系统崩溃；用户体验类似，最终都让用户体验到的是某些功能暂时不可用；
不同点：触发原因不同，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；

9. 服务限流

限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

10. 故障屏蔽

将故障机器从集群剔除，以保证新的请求不会分发到故障机器。

测试方法

1. 黑盒/白盒测试

黑盒测试不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。一般会有一个输入值，一个输入值，和期望值做比较。

白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑结构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖

2. 单元/集成/系统/验收测试

软件测试一般分为 4 个阶段：单元测试、集成测试、系统测试、验收测试。

单元测试：单元测试是对软件中的最小可验证单元进行检查和验证，如一个模块、一个过程、一个方法等。单元测试粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试：集成测试也叫做组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。
系统测试：系统测试时将经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境下进行一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试：验收测试也称交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

3. 回归测试

当发现并修改缺陷后，或在软件中添加新的功能后，重新测试。用来检查被发现的缺陷是否被改正，并且所做的修改没有引发新的问题。

4. 冒烟测试

这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。

冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。

比如：对于一个登录系统的冒烟测试，我们只需测试输入正确的用户名、密码，验证登录这一个核心功能点，至于输入框、特殊字符等，可以在冒烟测试之后进行。

5. 性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。

通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

6. 基准测试

基准测试（Benchmark）也是一种性能测试方式，用来测量机器的硬件最高实际运行性能，以及软件优化的性能提升效果, 同时也可以用来识别某段代码的 CPU 或者内存效率问题. 许多开发人员会用基准测试来测试不同的并发模式, 或者用基准测试来辅助配置工作池的数量, 以保证能最大化系统的吞吐量.

7. A/B 测试

A/B 测试，是用两组及以上随机分配的、数量相似的样本进行对比，如果实验组和对比组的实验结果相比，在目标指标上具有统计显著性，那就可以说明实验组的功能可以导致你想要的结果，从而帮你验证假设或者做出产品决定。

8. 代码覆盖测试

代码覆盖（Code coverage）是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，所得比例称为代码覆盖率。在做单元测试时，代码覆盖率常常被拿来作为衡量测试好坏的指标，甚至，用代码覆盖率来考核测试任务完成情况，比如，代码覆盖率必须达到 80%或 90%。于是乎，测试人员费尽心思设计案例覆盖代码。