后端开发黑话大全，进来对齐颗粒度！

👉目录

1 系统开发

2 架构设计

3 网络通信

4 故障异常

5 监控告警

6 服务治理

7 测试方法

8 发布部署

过早指的不是在开发过程的早期，而是在还没弄清楚需求未来的变化的走向的时候。你的优化不仅可能导致你无法很好地实现新的需求，而且你对优化的预期的猜测有可能还是错的，导致实际上你除了把代码变复杂以外什么都没得到。

正确的方法是，先有质量地实现你的需求，写够 testcase，然后做 profile 去找到性能的瓶颈，这个时候才做优化。

持久化是将程序数据在临时状态和持久状态间转换的机制。通俗的讲，就是临时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库或者本地磁盘中，能够长久保存）。

通常同步和异步是指函数/方法调用方面。

同步就是在发出一个函数调用时，在没有得到结果之前，该调用就不返回。异步调用会瞬间返回，但是异步调用瞬间返回并不代表你的任务就完成了，他会在后台起个线程继续进行任务，等任务执行完毕后通过回调 callback 或其他方式通知调用方。

• 并行（parallel）指在同一时刻，有多条指令在多个处理器上同时执行。所以无论从微观还是从宏观来看，二者都是一起执行的。

• 并发（concurrency）指在同一时刻只能有一条指令执行，但多个进程指令被快速的轮换执行，使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行。

• 冷备：两个服务器，一台运行，一台不运行做为备份。这样一旦运行的服务器宕机，就把备份的服务器运行起来。冷备的方案比较容易实现，但冷备的缺点是主机出现故障时备机不会自动接管，需要主动切换服务。

• 热备：即是通常所说的 active/standby 方式，服务器数据包括数据库数据同时往两台或多台服务器写。当 active 服务器出现故障的时候，通过软件诊测（一般是通过心跳诊断）将 standby 机器激活，保证应用在短时间内完全恢复正常使用。当一台服务器宕机后，自动切换到另一台备用机使用。

单台服务器的并发承载能力总是有限的，当单台服务器处理能力达到性能瓶颈的时，将多台服务器组合起来提供服务，这种组合方式称之为集群，集群中每台服务器就叫做这个集群的一个“节点”，每个节点都能提供相同的服务，从而成倍的提升整个系统的并发处理能力。

CAP 理论，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性），不能同时成立。

• 一致性：它要求在同一时刻点，分布式系统中的所有数据备份都相同或者都处于同一状态。

• 可用性：在系统集群的一部分节点宕机后，系统依然能够正确的响应用户的请求。

• 分区容错性：系统能够容忍节点之间的网络通信的故障。

简单的来说，在一个分布式系统中，最多能支持上面的两种属性。但显然既然是分布式注定我们是必然要进行分区，既然分区，我们就无法百分百避免分区的错误。因此，我们只能在一致性和可用性去作出选择。

在分布式系统中，我们往往追求的是可用性，它的重要性比一致性要高，那么如何实现高可用，这里又有一个理论，就是 BASE 理论，它给 CAP 理论做了进一步的扩充。

BASE 理论指出：

• Basically Available（基本可用）；

• Soft state（软状态）；

• Eventually consistent（最终一致性）。

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

• 水平扩展 Scale Out通过增加更多的服务器或者程序实例来分散负载，从而提升存储能力和计算能力。

• 垂直扩展 Scale Up 提升单机处理能力。

垂直扩展的方式又有两种：

1. 增强单机硬件性能，例如：增加 CPU 核数如32核，升级更好的网卡如万兆，升级更好的硬盘如 SSD，扩充硬盘容量如 2T，扩充系统内存如128G;

2. 提升单机软件或者架构性能，例如：使用 Cache 来减少 IO 次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

指对部署的集群进行动态在线扩容。弹性扩容系统可以根据实际业务环境按照一定策略自动地添加更多的节点（包括存储节点、计算节点、网络节点）来增加系统容量、提高系统性能或者增强系统可靠性，或者同时完成这三个目标。

状态同步：状态同步是指服务器负责计算全部的游戏逻辑，并且广播这些计算的结果，客户端仅仅负责发送玩家的操作，以及表现收到的游戏结果。

特征：状态同步安全性高，逻辑更新方便，断线重连快，但是开发效率较低，网络流量随游戏复杂度增加，服务器需要承载更大压力。

帧同步：服务端只转发消息，不做任何逻辑处理，各客户端每秒帧数一致，在每一帧都处理同样的输入数据。

特征：帧同步需要保证系统在相同的输入下，要有相同的输出。帧同步开发效率高，流量消耗低而且稳定，对服务器的压力非常小。但是网络要求高，断线重连时间长，客户端计算压力大。

• 流量控制防止发送方发的太快，耗尽接收方的资源，从而使接收方来不及处理。

• 拥塞控制防止发送方发的太快，使得网络来不及处理产生拥塞，进而引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿。

• 缓存穿透：缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。

• 缓存击穿：缓存击穿是指热点 key 在某个时间点过期的时候，而恰好在这个时间点对这个 Key 有大量的并发请求过来，从而大量的请求打到 db。

• 缓存雪崩：缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至 down 机。

• 与缓存击穿不同的是：存击穿是热点 key 失效，缓存雪崩是大量的 key 同时失效。

• 500 Internal Server Error：内部服务错误，一般是服务器遇到意外情况，而无法完成请求。可能原因:

1. 程序错误，例如：ASP 或者 PHP 语法错误；

2. 高并发导致，系统资源限制不能打开过多的文件所致。

1. Nginx 服务器，php-cgi 进程数不够用；

2. PHP 执行时间过长；

3. php-cgi 进程死掉；

除了500错误可能是程序语言错误，其余的报错，都大概可以理解为服务器或者服务器配置出现问题。

• 内存溢出：内存溢出（Out Of Memory）指程序申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储 int 类型数据的存储空间，但是你却存储 long 类型的数据，那么结果就是内存不够用，此时就会报错 OOM,即所谓的内存溢出。

• 内存泄漏：内存泄漏（Memory Leak）指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

• 硬中断：我们通常所说的中断指的是硬中断（hardirq）。由与系统相连的外设（比如网卡、硬盘）自动产生的。主要是用来通知操作系统系统外设状态的变化。

• 软中断：通常是硬中断服务程序对内核的中断；为了满足实时系统的要求，中断处理应该是越快越好。

对于集群系统，一般缓存是分布式的，即不同节点负责一定范围的缓存数据。我们把缓存数据分散度不够，导致大量的缓存数据集中到了一台或者几台服务节点上，称为数据倾斜。一般来说数据倾斜是由于负载均衡实施的效果不好引起的。

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

• 系统层（CPU、网络状态、IO、机器负载等）；

• 应用层（进程状态、错误日志、吞吐量等）；

• 业务层（服务/接口的错误码、响应时间）；

• 用户层（用户行为、舆情监控、前端埋点）。

• 服务拨测：服务拨测是探测服务（应用）可用性的监控方式，通过拨测节点对目标服务进行周期性探测，主要通过可用性和响应时间来度量，拨测节点通常有异地多个。

• 节点探测：节点探测是用来发现和追踪不同的机房（数据中心）节点之间网络可用性和通畅性的监控方式，主要通过响应时间、丢包率、跳数来度量，探测方法一般是 ping、mtr 或其他私有协议。

• 告警过滤：对某些可预知的告警进行过滤，不进入告警统计的数据，如少量爬虫访问导致的 http 响应500错误，业务系统自定义异常信息等。

• 告警去重：当一个告警通知负责人后，在这个告警恢复之前，不会继续收到相同的告警。

• 告警抑制：为了减少由于系统抖动带来的干扰，还需要实现抑制，例如服务器瞬间高负载，可能是正常的，只有持续一段时间的高负载才需要得到重视。

• 告警恢复：开发/运维人员不仅需要收到告警通知，还需要收到故障消除告警恢复正常的通知。

• 告警合并：对同一时刻产生的多条相同告警进行合并，如某个微服务集群同一时刻出现多个子服务负载过高的告警，需要合并成为一条告警。

• 告警收敛：有时某个告警产生时，往往会伴随着其它告警。这时可以只对根本原因产生告警，其它告警收敛为子告警一并发送通知。如云服务器出现 CPU 负载告警时往往伴随其搭载的所有系统的可用性告警。

• 故障自愈：实时发现告警，预诊断分析，自动恢复故障，并打通周边系统实现整个流程的闭环。

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

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

• 根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。

• 根据服务范围：可以砍掉某个功能，也可以砍掉某些模块。

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

• 相同点：目标一致，都是从可用性和可靠性出发，为了防止系统崩溃；用户体验类似，最终都让用户体验到的是某些功能暂时不可用；

• 不同点：触发原因不同，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑。

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

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

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

• 单元测试：单元测试是对软件中的最小可验证单元进行检查和验证，如一个模块、一个过程、一个方法等。单元测试粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。

• 集成测试：集成测试也叫做组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。

• 系统测试：系统测试时将经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境下进行一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。

• 验收测试：验收测试也称交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

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

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

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

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

• 通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

• 压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

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

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

• DEV（Development environment）：开发环境，用于开发人员调试使用，版本变化较大。

• FAT（Feature Acceptance Test environment）：功能验收测试环境，用于软件测试人员测试使用。

• UAT（User Acceptance Test environment）：用户验收测试环境，用于生产环境下的功能验证，可作为预发布环境。

• PRO（Production environment）：生产环境，正式线上环境。