突破性能瓶颈：后端接口优化的39个实战策略

为了更好评估后端接口性能，我们需要对不同行为的耗时进行比较。从上图可以看出，一个CPU周期少于1纳秒，而一次从北京到上海的跨地域访问可能需要约30毫秒。怎么计算跨地域耗时呢？

我们已知光在真空中传播，折射率为 1，其光速约为 c=30 万公里/秒，当光在其他介质里来面传播，其介质折射自率为 n,光在其中的速度就降为 v=c/n，光纤的材料是二氧化硅，其折射率 n 为 1.44 左右，计算延迟的时候，可以近似认为 1.5，我们通过计算可以得出光纤中的光传输速度近似为 v=c/1.5= 20 万公里/秒。

以北京和深圳为例，直线距离 1920 公里，接近 2000 公里，传输介质如果使用光纤光缆，那么延迟时间 t=L/v = 0.2 万公里/20 万公里/秒=10ms ，也就是说从北京到深圳拉一根 2000 公里的光缆，单纯的距离延迟就要 10ms ，实际上是没有这么长的光缆的，中间是需要通过基站来进行中继，并且当光功率损耗到一定值以后，需要通过转换器加强功率以后继续传输，这个中转也是要消耗时间的。另外数据包在网络中长距离传输的时候是会经过多次的封包和拆包，这个也会消耗时间。

综合考虑各种情况以后，以北京到深圳为例，总的公网延迟大约在 40ms 左右，北京到上海的公网延迟大约在 30ms，如果数据出国的话，延迟会更大，比如中国到美国，延迟一般在 150ms ~ 200ms 左右，因为要经过太平洋的海底光缆过去的。

如果让你进行后端接口的优化，你是首选优化代码行数？还是首选避免跨地域访问呢？

在评估接口性能时，我们需要首先找出最耗时的部分，并优化它，这样优化效果才会立竿见影。上图提供了一个很好的参考。

需要注意的是，上图中没有显示机房内网络的耗时。一次机房内网络的延迟（Ping）通常在1毫秒以内，相比跨地域网络延迟要少很多。

对于机房内的访问，Redis缓存的访问耗时通常在1-5毫秒之间，而数据库的主键索引访问耗时在5-15毫秒之间。当然，这两者最大的区别不仅仅在于耗时，而更重要的是它们在承受高并发访问方面的能力。Redis单机可以承受10万并发（往往瓶颈在网络带宽和CPU），而MySQL要考虑主从读写分离和分库分表，才能稳定支持5千并发以上的访问。

1. 优化前端接口

1.1 核心数据和非核心数据拆分为多个接口

我曾经对用户（会员）主页接口进行了优化，该接口返回的数据非常庞大。由于各个模块的数据都在同一个接口中，只要其中一部分数据的查询耗时较长，整体性能就会下降，导致接口的失败率增加，前端无法展示核心数据。这主要是因为核心数据和非核心数据没有进行隔离，耗时数据和非耗时数据没有分开。

对于庞大的接口，我们需要先梳理每个模块中数据的获取逻辑和性能情况，明确前端必须展示和重点关注的核心数据，并确保这些数据能够快速、稳定地响应给前端。而非核心的数据和性能较差的数据则可以拆分到另外的接口中，即使这些接口的失败率较高，对用户影响也不大。

这种优化方式除了能保证快速返回核心数据，也能提高稳定性。如果非核心数据故障，可以单独降级，不会影响核心数据展示，大大提高了稳定性。

1.2 前端并行调用多个接口

后端提供给前端的接口应保证能够独立调用，避免出现需要先调用A接口再调用B接口的情况。如果接口设计不合理，前端需要的总耗时将是A接口耗时与B接口耗时之和。相反，如果接口能够独立调用，总耗时将取决于A接口和B接口中耗时较长的那个。显然，后者的性能更优。

在A接口与B接口都依赖相同的公共数据的情况下，会导致重复查询。为了优化总耗时，重复查询是无法避免的，因此应着重优化公共数据的性能。

在代码设计层面，应封装每个模块的取值逻辑，避免A接口与B接口出现重复代码或拷贝代码的情况。

1.3 使用MD5加密，防篡改数据，减少重复校验

在提单接口中，需要校验用户对应商品的可见性、是否符合优惠活动规则以及是否可用对应的优惠券等内容。由于用户可能篡改报文来伪造提单请求，后端必须进行校验。然而，由于提单链路本身耗时较长，多次校验以上数据将大大增加接口的耗时。那么，是否可以不进行以上内容的校验呢？

是可以的。在用户提单页面，商品数据、优惠活动数据以及优惠券等数据都是预览接口校验过的。后端可以生成一个预览Token，并将预览结果存在缓存中，前端在提单接口中指定预览Token。后端将校验提单数据和预览数据是否一致，如果不一致，则说明用户伪造了请求。

为了避免预览数据占用过多的缓存空间，可以设置一个过期时间，例如预览数据在15分钟内不进行下单操作，则会自动失效。另外，还可以对关键数据进行MD5加密处理，加密后的数据只有64位，数据量大大减少。后端在提单接口中对关键数据进行MD5加密，并与缓存中的MD5值进行比对，如果不一致，则说明用户伪造了提单数据。

更详细请参考# 如何防止提单数据被篡改？

1.4 同步写接口改为异步写接口

在写接口耗时较高的情况下，可以采取将接口拆分为两步来优化性能。首先，第一步是接收请求并创建一个异步任务，然后将任务交给后端进行处理。第二步是前端轮训异步任务的执行结果，以获取最终结果。

通过将同步接口异步化，可以避免后端线程资源被长时间占用，并且可以避免浏览器和服务器的socket连接被长时间占用，从而提高系统的并发能力和稳定性。

此外，还可以在前端接口设置更长的轮训时间，以有效提高接口的成功率，降低同步接口超时失败的概率，提升系统的性能和用户体验。

1.5 页面静态化

在电商领域，商品详情页和活动详情页通常会有非常高的流量，特别是在秒杀场景或大促场景下，流量会更高。同时，商品详情页通常包含大量的信息，例如商品介绍、商品参数等，导致每次访问商品详情都需要访问后端接口，给后端接口带来很大的压力。

为了解决这个问题，可以考虑将商品详情页中不会变动的部分（如商品介绍、头图、商品参数等）静态化到html文件中，前端浏览器直接访问这些静态文件，而无需访问后端接口。这样做可以极大地减轻商品详情接口的查询压力。

然而，对于未上架的商品详情页、后台管理等页面，仍然需要查询商品详情接口来获取最新的信息。

页面静态化需要先使用模版工具例如Thymeleaf等，将商品详情数据渲染到Html文件，然后使用运维工具（rsync）将html文件同步到各个nginx机器。前端就可以访问对应的商品详情页。

当商品上下架状态变化时，将对应Html文件重新覆盖或置为失效。

1.6 不变资源访问CDN

CDN（内容分发网络）是一种分布式网络架构，它将网站的静态内容缓存在全球各地的服务器上，使用户能够从最近的服务器获取所需内容，从而加速用户访问。这样，用户不需要从原始服务器请求内容，可以减少因网络延迟导致的等待时间，提高用户的访问速度和体验。

通过注入静态Html文件到CDN，可以避免每次用户的请求都访问原始服务器。相反，这些文件会被缓存在CDN的服务器上，因此用户可以直接从离他们最近的服务器获取内容。这种方式可以大大减少因网络延迟导致的潜在用户流失，因为用户能够更快地获取所需的信息。

此外，CDN的使用还可以提高系统在高并发场景下的稳定性。在高并发情况下，原始服务器可能无法承受大量的请求流量，并可能导致系统崩溃或响应变慢。但是，通过将静态Html文件注入到CDN，让CDN来处理部分请求，分担了原始服务器的负载，从而提高了整个系统的稳定性。

通过将商品详情、活动详情等静态Html文件注入到CDN，可以加速用户访问速度，减少用户因网络延迟而流失的可能性，并提高系统在高并发场景下的稳定性。

2. 调用链路优化

调用链路优化重点减少RPC的调用、减少跨地域调用。

2.1 减少跨地域调用

刚才我提到了北京到上海的跨地域调用需要耗费大约30毫秒的时间，这个耗时是相当高的，所以我们应该特别关注调用链路上是否存在跨地域调用的情况。这些跨地域调用包括Rpc调用、Http调用、数据库调用、缓存调用以及MQ调用等等。在整理调用链路的时候，我们还应该标注出跨地域调用的次数，例如跨地域调用数据库可能会出现多次，在链路上我们需要明确标记。我们可以考虑通过降低调用次数来提高性能，因此在设计优化方案时，我们应该特别关注如何减少跨地域调用的次数。

举个例子，在某种情况下，假设上游服务在上海，而我们的服务在北京和上海都有部署，但是数据库和缓存的主节点都在北京，这时候就无法避免跨地域调用。那么我们该如何进行优化呢？考虑到我们的服务会更频繁地访问数据库和缓存，如果让我们上海节点的服务去访问北京的数据库和缓存，那么跨地域调用的次数就会非常多。因此，我们应该让上游服务去访问我们在北京的节点，这样只会有1次跨地域调用，而我们的服务在访问数据库和缓存时就无需进行跨地域调用。

2.2 单元化架构：不同的用户路由到不同的集群单元

如果主数据库位于北京，那么南方的用户每次写请求就只能通过跨地域访问来完成吗？实际上并非如此。数据库的主库不仅可以存在于一个地域，而是可以在多个地域上部署主数据库。将每个用户归属于最近的地域，该用户的请求都会被路由到所在地域的数据库。这样的部署不仅提升了系统性能，还提高了系统的容灾等级，即使单个机房发生故障也不