Java最全Java程序员须知：分布式微服务为什么很难？(1)，想学IT的必看

本文链接：https://blog.csdn.net/2401_84692641/article/details/138660657

最后，附一张自己面试前准备的脑图：

面试前一定少不了刷题，为了方便大家复习，我分享一波个人整理的面试大全宝典

Java核心知识整理

Spring全家桶（实战系列）

Step3：刷题

既然是要面试，那么就少不了刷题，实际上春节回家后，哪儿也去不了，我自己是刷了不少面试题的，所以在面试过程中才能够做到心中有数，基本上会清楚面试过程中会问到哪些知识点，高频题又有哪些，所以刷题是面试前期准备过程中非常重要的一点。

以下是我私藏的面试题库：

很多人感叹“学习无用”，实际上之所以产生无用论，是因为自己想要的与自己所学的匹配不上，这也就意味着自己学得远远不够。无论是学习还是工作，都应该有主动性，所以如果拥有大厂梦，那么就要自己努力去实现它。

最后祝愿各位身体健康，顺利拿到心仪的offer！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

有一些在单体架构中的保证在分布式系统中就不再会得到保障。组件（现在的服务）不再以可预测的顺序启动和停止。服务可能意外重新启动，更改其数据库状态或版本。结果是，没有服务可以对另一个服务进行假设 - 系统不依赖于1对1的通信。

许多从故障中恢复的传统机制可能会使分布式环境恶化。强力重试可能会使您的网络被洪水般数据包淹没，备份恢复也并不简单。过去解决所有这些问题的设计模式，都需要重新思考和测试。

如果没有错误，分布式系统会很容易。乐观主义会造成对安全的错觉。分布式系统的设计必须具有弹性，能够容纳接受所有可能的发生错误，而不影响日常业务。

这里通讯会失败

在不可靠（即分布式）系统中，传统应用程序消息传递有两种高级方法：

可靠但缓慢：保存每条消息复制副本，直到您确认职责链中的下一个进程已经为此承担全部责任。
不可靠但快速：将多个复制副本发送给潜在的多个接受人，并允许消息丢失和重复。

我们在这里讨论的可靠和不可靠的应用级通信与网络可靠性（例如TCP与UDP）是不同。想象一下，两个通过TCP直接发送消息(比如RPC通讯)的无状态服务。即使TCP是可靠的网络协议，这也不是可靠的应用级通信。任何服务都可能会丢失并丢失正在处理的消息，因为无状态服务不能安全地保存正在处理的数据。（banq注：这是针对同步的RPC框架，比如国内的Dubbo或谷歌的gRPC）

我们可以通过在每个服务之间放置有状态的队列来使此设置应用程序级别可靠，以保存每个消息，直至其完全处理（banq注：引入消息队列）。这样做的不足之处在于它会慢一点，但是我们可能很乐意与之相处，因为如果它使生活更简单，特别是如果我们使用可管理的有状态的队列服务时，那么我们就不必担心规模和弹性问题。

可靠的方法是可预测的，但会涉及到延迟（延迟）和复杂性：大量确认消息和弹性保存数据（状态），直到您已经从职责链中的下一个服务确认完成了他们已经承担责任。

一个可靠的方法却不能保证快速的传递，但它确保所有的消息将最终至少一次传递。在每个消息至关重要且不能容忍丢失（例如信用卡交易）的环境中，这是一个很好的方法。AWS简单队列服务（Amazon的托管队列服务）是以可靠方式使用状态服务的一个例子。(banq注: Apache kafka提供类似正好一次的有效一次传递也是适用类似信用卡之类的交易)

第二种情况是，使用不可靠的方法可以实现端对端通讯得更快（比如RPC同步方式），但这意味着服务通常不得不期待重复和无序消息，并且一些消息将丢失。当消息是时间敏感的（即，如果他们不迅速采取行动，就不值得采取行动）或稍后的数据只是覆盖早期的数据，这种情况下可能会使用不可靠的通信。对于非常大规模的分布式系统，可以使用不可靠的消息传递，因为它的开销小且要快得多。然而，微服务设计却需要处理应对消息的丢失和重复。

在上述每种情况方法中，存在许多变量（例如，有保证和不保证的顺序性），所有这些变量需要在速度、复杂性和故障率方面进行不同的权衡。

一些系统可以同时使用上述多种方法，这取决于正在发送的消息的类型甚至系统上的当前负载。如果您有很多行为不同的服务，就很难正确恰当使用这些方法。需要在其API中明确定义服务的行为。为您的系统中的服务进行约束或推荐的通信行为的定义通常是有意义的，以获得一定程度的一致性。

现在时间是几点？

在分布式系统中没有这样的常见的所谓全球时钟。例如，在团体聊天中，我的评论和我的朋友在澳大利亚、哥伦比亚和日本发表的评论的出现将不会遵循严格顺序先后出现。没有任何保证机制保证我们看到的都是相同的时间表 - 虽然总有一个顺序，但是前提是我们有段时间先不说话。

基本上，在分布式系统中，每台机器都有自己的时钟，整个系统没有一个正确的时间。机器时钟可能会进行同步，但是即使在同步时传输时间也会不同，物理时钟也会以不同的速率运行，所以一切都会立即失去同步。

在单个机器上，一个时钟可以为所有线程和进程提供通用的时间。在分布式系统中，这在物理上都不可行。

在我们的新世界中，时钟时代不再提供无可置疑的顺序定义。在微服务世界中并不存在“什么时候”的单一概念，所以，我们的设计不应该依赖于服务间消息。

真相就在那里？

在分布式系统中，没有全局共享内存，因此没有单一版本的真相。数据将分散在不同物理机器上。此外，任何指定的数据在机器之间更可能处于相对较慢和无法访问的传输中，而不像在单体架构下的情况。因此，真正运行情况需要基于当前的当地的信息。

这意味着系统的不同部分的运行情况并不总是一致的。在理论上，它们最终应该在整个系统中传播消息时变得一致，但是如果数据不断变化，我们可能永远不会达到完全一致的状态，除非关闭所有新的输入和等待。因此，服务必须处理这样一个事实，即他们相互调用时可能会因为自己的问题而获得“旧”的或者不一致的信息。

说话快点！

在一个单体的应用程序中，大多数重要的通信发生在一个组件和另一个组件之间的单个进程中。流程内部的通信非常快，所以很多内部消息的传递不是问题。但是，一旦将单体组件拆分成单独的服务，通常会在不同的机器上运行，那么事情变得越来越复杂。