最全Java程序员须知：分布式微服务为什么很难？，含小米、腾讯、阿里

最后

每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。

如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。

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

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

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

现在时间是几点？

---

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

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

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

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

真相就在那里？

---

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

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

说话快点！

---

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

假设你知道如下背景知识：

1. 在最好的情况下，将消息从一台机器发送到另一台机器比将内部从一个组件传递到另一个组件时要花费大约100倍的时间。

2. 许多服务使用基于文本的RESTful消息进行通信。RESTful消息是跨平台的，易于使用，读取和调试，但传输速度慢。相比之下，与二进制消息协议配对的远程过程调用（RPC）消息不是人类可读的，因此更难调试和使用，但传输和接收速度要快得多。通过RPC方式发送消息的速度快20倍，比如gRPC相对RESTful而言。

在分布式环境中的结果却是：

1. 你应该发送更少的消息。您可以选择在分布式微服务器之间发送的消息数量少于在单件中的组件之间发送的消息量，因为每个消息都会引入延迟（即延迟）。

2. 考虑更有效地发送消息。对于您发送的内容，您可以通过使用RPC而不是REST来传输消息来帮助您的系统运行得更快。或者甚至就使用UDP并手工自己处理不可靠性。（banq注：RPCC通讯属于通讯快但不可靠类型）

状况报告？

---

如果您的系统可以次秒级（时间上短于1秒）速度更改，这是动态管理的分布式架构的目标，那么您需要以这种速度了解问题。许多传统的日志工具并不是为了跟踪这种情况而设计的。你需要确保能使用它们。

测试破坏

---

了解您的分布式系统是否正常工作并从不可预测的错误中恢复的唯一方法是：持续攻克这些错误并持续修复系统。Netflix使用Chaos Monkey(混沌猴)随机造成故意的崩溃测试。您的系统的弹性和完整性是需要测试的，同样重要的是，测试您的日志记录，以确保如果发生错误，您可以追溯地诊断和修复它 - 即使您的系统已经恢复在线运行。

这听起来很困难 我一定需要吗？

---

创建分布式、可扩展的、有弹性的系统是非常困难的，特别是对于有状态的服务（服务需要写数据库保存变动的数据）。现在是决定是否需要它的时候了。你的客户需求是否可以容忍慢一点响应还是小型规模系统？这样，您可以先设计一个更小、更慢、更简单的系统，并在构建专业知识同时逐步增加更多的复杂性。
像AWS，Google和Azure这样的云计算提供商也正在开发和推出这些大部分功能，特别是弹性状态（托管的消息队列和数据库）。这些服务似乎是昂贵的，但构建和维护复杂自己的分布式服务也是昂贵的。
任何虽然可能限制您但是会处理这些复杂性的框架（如Linkerd或Istio或Azure的服务架构）是非常值得考虑的。
关键的挑战是不要低估建立正确的弹性和高度可扩展的服务的难度。如果决定你真的需要它，那么全面教育大家，引入有用的约束，逐渐做好一切，并期待挫折和成功。

更多：Java进阶核心知识集

包含：JVM，JAVA集合，网络，JAVA多线程并发，JAVA基础，Spring原理，微服务，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存等等

高效学习视频

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

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

/4f45ff00ff254613a03fab5e56a57acb)收录**

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