分布式核算是一个杂乱的范畴，面临着很多应战，了解与之相关的错误关于构建强健且牢靠的分布式体系至关重要。以下是分布式核算的八个错误及其含义：

1. 网络牢靠：假定网络连接始终可用且牢靠，当网络中止发生时，即便网络中止是暂时的，也或许会导致体系毛病。规划可以经过冗余和容错机制妥善处理网络毛病的体系至关重要。

2. 推迟为零：高估分布式组件之间的通讯速度或许会导致体系缓慢且无呼应。供认网络推迟并对其进行优化关于供给高效的用户体会至关重要。

3. 带宽是无限的：以为网络带宽是无限的或许会导致网络过载并导致拥塞。高效的数据传输和带宽办理关于防止功能瓶颈至关重要。

4. 网络是安全的：假定网络本质上是安全的，或许会导致缝隙和数据走漏。施行强壮的安全措施（包含加密和身份验证）关于维护分布式体系中的敏感信息是必要的。

5. 拓扑不会改动：网络不断发展，假定静态拓扑或许会导致配置错误和体系不安稳。体系的规划应可以习惯不断变化的网络条件和配置。

6. 只有一个办理员：信任单个办理员控制整个分布式体系或许会导致协调问题和抵触。现实中，分布式体系往往触及多个办理员，需要清晰的管理和协调机制。

7. 传输本钱为零：忽视与数据传输相关的本钱或许会导致资源利用效率低下并添加运营费用。优化数据传输并考虑相关本钱关于经济高效的分布式核算至关重要。

8. 网络是同质的：假定一切网络组件和节点具有相同的特征或许会导致兼容性问题和功能差异。体系的规划应可以处理异构性并习惯各种类型的设备和渠道。

理解这些谬论至关重要，因为它们强调了分布式核算的应战和杂乱性。假如不考虑这些错误，或许会导致体系毛病、安全缝隙和运营本钱添加。构建牢靠、高效和安全的分布式体系需要深化了解这些谬论，并施行适当的软件规划和架构以及 IT 运营战略来处理这些问题。

不牢靠的网络

在这篇博文中，咱们将讨论第一个谬论、它对微服务架构的影响，以及怎么规避这一约束。假定咱们运用 spring-boot 来编写微服务，它运用 MongoDB 作为后端，在 Kubernetes 中布置为 StatefulSet。并在 EKS 上运行它。您或许还会质疑，为咱们供给牢靠的网络是您的云供给商的工作，而咱们却为高可用性而向他们付费。尽管这种期望或许没有错，但不幸的是，当您经过云租用硬件时，它并不总是按预期工作。假定您的云供给商许诺 99.99% 的可用性，这令人形象深刻，对吗？不，不是这样！我会解说怎么做。99.99% 的可用性或许会导致。

• 10,000 个恳求中的每个恳求都失利。
• 1,00,000 个恳求中每 10 个恳求都会失利。

您或许会说您的体系无法取得这种流量！很公平，但这是云供给商的可用性数据，而不是您的服务实例，这意味着假如该云在其网络内收到十亿个网络恳求，则有 1,00,000 个将失利！让事情变得更杂乱的是，您不能指望他们运用其硬件将这些毛病分布到一切帐户；根据您的运气，您或许会遇到许多此类失利。这儿的问题是，您是否只想在这些中止不会影响到您的情况下经营一家企业？我希望不是！这是对分布式核算的第一个（也是最关键的）错误的根本描绘。

网络毛病的影响

咱们以电子商务体系为例；咱们通常会从产品微服务中看到产品目录；可是，在构建产品目录呼应时，或许会从另一个微服务获取 SKU 可用性。不过，有人或许会说，我可以经过 Choreography 将 SKU 信息复制到产品目录中，但就本示例的范围而言，咱们假定这还没有到位。因而，产品服务正在对 SKU 服务进行 REST API 调用。当此调用失利时会发生什么？您怎么向终究用户传达他们正在检查的产品是否可用？

可怕的东西，是吗？嗯，没那么可怕；作为工程师，咱们喜爱在更困难的范畴勇敢地面临，因而咱们有一些技巧。

容错和弹性编码

这个话题自身就值得写一本书，而不是一篇博客文章。但我会极力涵盖一切内容，一起保持简略。我在这儿分享的大部分内容都是 NimbleWork 中 SaaS 事务从全体架构过渡到微服务时搜集的经历。我希望其他人也觉得它有协助。

时刻短中止的形式

以下形式有助于防止咱们通常所说的时刻短中止或突发事情。根本假定是，此类中止的生命周期最多为一到两秒。

重试

最简略的事情之一是将网络调用包装在重试逻辑中，以便在调用服务终究放弃之前进行多次测验。这儿的想法是，来自云供给商的暂时网络妨碍不会继续比获取数据的重试时刻更长的时刻。简直一切常见编程言语中的微服务库和结构都供给了此功能。退休人员自身有必要细致入微或离散；例如，在收到 400 时重试不会更改输出，直到恳求签名发生更改。以下是运用 Spring WebFlux WebClient 进行 REST API 调用时运用重试的示例。

webClient.get().uri(uri)
                .headers(headers -> headers.addAll(httpHeaders))
                .retrieve()
                .bodyToMono(new ParameterizedTypeReference<Map<String, Object>>() {
                })
                .log(this.getClass().getName(), Level.FINE)
                .retryWhen(
                        Retry.backoff(3, Duration.ofSeconds(2))
                                .jitter(0.7)
                                .filter(throwable -> throwable instanceof RuntimeException ||
                                        (throwable instanceof WebClientResponseException &&
                                        (((WebClientResponseException) throwable).getStatusCode() == HttpStatus.GATEWAY_TIMEOUT || ((WebClientResponseException) throwable).getStatusCode() == HttpStatus.SERVICE_UNAVAILABLE || ((WebClientResponseException) throwable).getStatusCode() == HttpStatus.BAD_GATEWAY)))
                                .onRetryExhaustedThrow((retryBackoffSpec, retrySignal) -> {
                                    log.error("Service at {} failed to respond, after max attempts of: {}", uri, retrySignal.totalRetries());
                                    return retrySignal.failure();
                                }))
                .onErrorResume(WebClientResponseException.class, ex -> ex.getStatusCode().is4xxClientError() ? Mono.empty() : Mono.error(ex));

以下是咱们企图经过这段代码完成的目标的摘要：

• 两秒内最多重试 3 次。
• 根据抖动随机距离重试之间的时刻。
• 仅当上游服务供给 HTTP 504、503 或 502 状况时才重试。
• 记录错误并在最大测验次数耗尽时将其传递给下流。
• 为客户端错误包装一个空呼应，或者将上一步中的错误传递到下流。

这些重试可以协助您从预计不会继续很长时刻的突发事情或妨碍中康复过来。假如咱们调用的上游服务由于某种原因重新启动，这也或许是一个很好的机制。

注意：运用翻滚更新战略在 Kubernetes 中运行副本集有助于削减此类事情，然后削减重试。

尽管这是运用 Spring 中的 Reactor 项目完成的示例，但一切首要结构和言语都供给了代替计划。

• 假如您运用 Spring 结构但不运用呼应式编程，请运用Spring Retry 。
• 当您运用 Akka 和 Scala 或 Java 时的主管战略。
• scala.util.{Failure, Try} 假如您在没有任何结构的情况下运用 Scala。
• 在 Python 中重试装修器。
• JavaScript 中的获取重试。

我确信这不是一份翔实的清单。这种形式可以处理时刻短的网络毛病。但假如继续停电怎么办？比本文后面的内容更多。

最终已知的好版别

假如被调用的服务继续溃散而且各个客户端的一切重试都耗尽怎么办？我更喜爱回退到最终一个已知的好版别。有几种战略可以在基础设施和客户端上启用“最终已知的杰出版别”战略。咱们将扼要介绍其中的每一个。

布置： 从基础设施的视点来看，最简略的挑选是重新布置到服务的最终一个已知的安稳版别。这是假定下流应用程序仍然兼容调用这个旧版别。在 Kubernetes 中更容易做到这一点，它保存了之前的布置修订。

在下流缓存：另一种方法是客户端保存最终一个成功的呼应，以便在服务呈现毛病时可以依靠；在浏览器或移动用户界面上向终究用户显现与过期数据相关的提示是一个不错的挑选。

下流缓存

浏览器或任何客户端都会不断地将数据写入内存存储，直到收到来自上游的心跳。该机制为经过 gRPC 或 REST 进行服务调用的 UI 和无头客户端供给了各种完成。不管客户类型怎么，这儿都总结了应该做什么。

• 客户端在其第一个 API 调用上进行注册，以便服务进行盯梢。
• 对客户端的后续更新作为从服务到客户端的推送进行办理。
• 客户端在本地保留状况，浏览器上的 Redux，或无头客户端的 Redis、Memcached（假如您的灵魂答应的话，也可以运用 LinkedHashMap）。
• 假如您的规划不足以承当推送的费用，您可以运用 ReactJS 的 RTK 和 Angular 的 NgRx 存储等东西，并不断拉取状况更新。当您收到任何 5XX 状况错误时，请务必告知终究用户他们或许会看到过期的数据。

继续中止的形式

假如任何分布式架构都是一个只有点的体系，那咱们就很走运了，但事实并非如此。因而，咱们有必要构建咱们的体系来处理长时刻中止。以下是一些在这方面有协助的形式。

阻隔壁

阻隔壁是为了应对由上游服务的缓慢导致的毛病。尽管理想的处理计划是处理上游问题，但这并不总是可行的。设想一个场景，你调用的服务（X）依赖于另一个表现出缓慢呼应时刻的服务（Y）。假如服务（X）遭受很多的流入流量，那么它的很大一部分线程或许会等候较慢的上游服务（Y）呼应。这种等候不只会减慢服务（X）的速度，而且还会添加恳求丢失的速度，导致客户端更多的重试并加重瓶颈现象。

为了减轻这个问题，一个有效的方法是局部化失利的影响。例如，您可以为调用较慢的服务创立一个有限线程数的专用线程池。这样做可以将缓慢和超时的影响局限于特定的API调用，然后提高全体服务的吞吐量。

断路器

可以轻松防止断路器；咱们有必要编写永远不会宕机的服务！然而，现实情况是咱们的应用程序常常依赖于其他人开发的外部服务。在这些情况下，断路器作为一种形式就变得非常有价值。它经过代理在服务之间路由一切流量，一旦到达界说的毛病阈值，代理就会立即开始拒绝恳求。事实证明，这种形式在外部服务长时刻网络中止期间特别有用，否则或许会导致呼叫服务中止。尽管如此，确保在此类场景中供给无缝的用户体会至关重要，咱们发现两种有效的方法：

• 通知用户受影响区域发生中止，一起使他们可以运用体系的其他部分。
• 答应客户端缓存用户事务，供给“202 Accepted”呼应，而不是像往常一样的“200”或“201”，并在上游服务再次可用时康复这些事务。

定论

尽管云供给商致力于高可用性，但由于这些网络的规划巨大且不行预测，网络毛病仍然不行防止，这凸显了对弹性体系的火急需求。这段旅程让咱们沉浸在分布式核算范畴，应战咱们作为工程师，用容错和弹性战略武装自己。采用重试、最终已知的杰出版别战略等技能，以及开发两头都有状况办理的独立客户端-服务器架构，使咱们可以应对网络中止的不行预测性。

当咱们探究错综杂乱的分布式体系时，采用这些战略关于确保流通的用户体会和体系安稳性至关重要。欢迎来到云中微服务的世界，这儿的应战激发立异，而弹性是咱们应对不牢靠网络的柱石。

作者：Anadi Misra

更多技能干货请重视公号【云原生数据库】

squids.cn，云数据库RDS，迁移东西DBMotion，云备份DBTwin等数据库生态东西。

​