作为一个资深架构师，一路的技术水平到底是个什么东西？

作为一名资深架构师，一路走来，我发现我的技术水平往往会被迫随着项目的发展而增长。事实上，很多时候，自己的水平达不到成功完成建筑项目的水平。但是，为了挑战，为了技术的成长，为了高薪，只能咬牙坚持，熬夜学习，最终让自己设计和控制的顺利。项目的架构。

其中，最难的是设计、构建和规划一套大型分布式系统。但是，正是通过这些极其艰巨的考验，我们才不惧怕那些所谓的35岁的技术人员。

但是，要做到这一点，首先要做的是了解什么是分布式系统。

1. 什么是分布式系统

大家在网上看到的分布式系统的学术定义，简单来说就是一组系统，由一组计算机协同工作，让用户感觉是一个统一的整体。

但是，由于这个定义过于简洁，很多初学者会在不知不觉中混淆分布式系统的概念。

什么意思？这里问一下，当我们把它作为高可用集群使用的时候，我们是在做分布式系统吗？当我们没有足够的并发性并且我们有一堆机器进行负载平衡时，我们是在做分布式系统吗？

当你在心里默默回答是，或者不知道是不是，你已经对分布式系统的概念感到困惑。

在这里，我们需要给分布式系统划一个边界，告诉大家多台机器堆叠在一起就不是分布式系统。对于刚才的两个问题，正确的答案是创建一个高可用集群，使用 Nginx 或者 lvs 后跟一堆应用集群进行负载均衡。它们不是分布式系统，它们只是一个集群。

同样的，MySQL的主从、双主什么的数据库当然不是分布式系统。因为这些集群缺少分布式系统的核心东西：

应用程序所在服务器之间的互操作性

为了说清楚聚类和分布，我举一个通俗易懂的例子：

假设有一天我开了一家软件公司，我是公司里唯一的程序员。我负责所有的前端、后端和测试任务。我可以在一个月内完成一个项目。

后来项目太多，我太忙了。为了赚更多的钱，我该怎么做？我想到了两种方法。

我们会再招聘一个和我一样强的全栈工程师，我们每个人独立做项目，这样一个月就能完成两个项目。我们组成了一个小组。招一个前端和一个测试跟我合作，前端、后端、测试是分开做的。通过合作，我们可以在半个月内完成一个项目。这时候我们的关系是分布式的。从上面的例子可以看出：

集群中的多台服务器都在做同样的事情架构师，并且不会减少处理一件事情所需的时间。至于分布式，就是把事情分开，多台服务器分开做事情，可以缩短时间。了解了分布式系统是什么之后，最简单的分布式系统应该是什么样子的呢？

假设我们搭建了一个只有两个功能的系统：1.注册，2.登录

如果我们想让这个系统成为分布式系统怎么办？最简单的就是把注册功能和登录功能做成两组子服务，然后部署到两台服务器上让它们相互配合，就成了最简单的分布式系统。

看到这里你可能会感到震惊：这是分布式系统？有这么多我想学习的分布式系统技术栈呢？那些高级算法呢？可以瞬间闪回的容错机制呢？无缝热升级功能呢？哪里有问题？我们构建的这个简单系统真的是我们每天都在谈论的分布式系统吗？

2. 为什么要搞分布式系统

为什么要搞分布式系统？答案很简单：形势逼迫！一套分布式系统往往是业务发展后的最终解决方案。

假设公司推出了一项新的在线业务，我们必须为该业务建立和开发业务系统。往往这个时候，由于项目前景不明，需要快速上线进入市场反复试错，这个时候我们可能会优先搭建单体架构，先上线。

随着业务的发展和运营，我们经常遇到的第一个问题就是系统崩溃和服务器宕机。

这时候大家都会开发高可用架构来解决问题。在多台机器上部署同一个项目。如果一台机器出现故障，您可以直接切换到另一台机器提供服务。

随后，由于业务的进一步发展和扩大，此时的瓶颈往往是系统的响应时间。响应时间的增加直接影响到用户体验，这本身就反映了吞吐量的瓶颈。

对于这类问题，架构师会想出一个集群大法的好主意来解决。这时候系统架构就变得复杂了，因为别忘了，我们需要在保证负载均衡的同时保证服务的高可用。

到目前为止，似乎没有任何问题。我们通过高可用来保证系统的可靠性，通过负载均衡来分散系统的压力。

但是，以上解决方案都不是分布式的，系统也不是分布式系统。被一些技术狂人嘲讽的依然是这种笨重的架构。

我们还需要分发吗？

上图是某大厂支付平台架构图的一小部分。

从这张图中，我们可以看出未来的业务会有多复杂。面对如此复杂的业务，我们发现之前做的那种集群是不合理的。

这时候就需要拆分业务了。

虽然业务已经分拆，但这些业务最终会合作提供整体服务。这个时候，是时候真正需要一个分布式系统了。我们需要一组在不同服务器上协同工作的系统。

所以我们说分布式系统是业务发展的终极解决方案。最后，如果业务复杂到可以拆分，那么分布式系统是一种自然的需求。

在这里，我们也可以回答我们在上一节中遇到的问题。我们需要的不是简单的以去中心化方式部署的模块的无意义分布，也不是简单的模块分解。我们需要的是系统能够：

保持卓越的性能具有极其可靠的可用性和出色的弹性。为了保证以上三个指标，分布式系统的复杂高难度技术栈应运而生。

3. 分布式系统的技术栈

正如我们上面所说，分布式系统的出现完全是形式所迫，是业务发展的最终结果。并且由于业务的拆分，我们被迫衍生出更多的分布式需求和技术来处理这些需求：

由于业务拆分较多，业务对应的模块需要进行通信。为了保证快速可靠的通信，我们需要掌握分布式通信技术。业务拆分太多，每个模块也可能需要集群。这么多的服务器资源，为了保证准确的资源分配，我们还需要考虑分布式资源管理和负载调度技术。业务拆分后，模块需要访问大量的共享数据。为了保证一个安全完整的数据状态，我们还需要使用分布式协调和同步技术。在业务拆分阶段，数据必然是巨大的。为了数据存储的可靠性和保证出色的数据读写性能，我们需要分布式存储技术。业务如此复杂。公司的发展和业务拓展，需要更精准的营销和运营。我们还需要对数据进行实时和离线处理和分析。这时候，我们就不得不考虑分布式计算技术了。业务拆分后，整体架构发生了翻天覆地的变化。以前的集群思维不可能考虑高可用，所以分布式可靠性技术必须包含在我们的掌握之中。整体架构发生了巨大的变化。以前的集群思维不可能考虑高可用，所以分布式可靠性技术必须包含在我们的掌握之中。整体架构发生了巨大的变化。以前的集群思维不可能考虑高可用，所以分布式可靠性技术必须包含在我们的掌握之中。

你看分布式系统的技术栈这么多，这么复杂，对吧？不要恐慌。

我写这篇文章不是为了说服你。我们要循序渐进、循序渐进地学习，把分布式的整体技术栈划分出来，逐步掌握。

4. 如何学习分布式系统的技术栈

在分布式技术栈中，我们可以看到其实分布式技术是分类的，根据不同的分类，我们可以掌握分布式技术每一类背后的概念和思想。不管有多少分布式技术的实现，这些实现总是按照分布式技术的原理来实现的，它们被归类为核心底层。

同时，在我们的学习中，也要理论联系实际，根据自己的实际开发和架构需求进行学习。

而且业务是逐步发展的，项目不会一下子发展得特别大。这给了我们一步一步学习、一步一步掌握的时间和机会。

4.1 分布式通信

那么具体如何呢？

首先，分布式的基础是什么？从我自己的经验来看，我认为是通信，最重要的其实是分布式系统中那些模块中的通信机制。

以及如何学习通信机制？我认为首先要做的是了解我们可用的各种通信机制之间的区别。特别重要的是了解每种沟通机制的缺点。是的，你没看错，这是一个缺点。

为什么缺陷是最重要的？因为架构师在建造的时候，一个特别重要的工作就是做技术选型。在应用场景中，技术选择的目标往往很模糊。如果能了解每一次选拔的不足之处，将对选拔结果的准确性起到极其重要的作用。

例如，如果我们现在想在模块之间进行通信，我们应该使用 RPC 还是 MQ？此时，如果我们知道了RPC的缺点和MQ的缺点，我们就可以轻松做出更准确的选择。

RPC的缺点：

不能搞流量切割，不能广播到多个模块，消息传递不保证模块和模块之间没有解耦MQ的缺点：

无法保证延迟时间不适用于强一致性的事务，增加了系统的复杂度，降低了系统的可用性。好吧，知道了缺点，我们可以轻松选择模型。如果我们有实时扣费的业务，一定要搞RPC，因为它对延迟敏感，需要强一致性。

如果我们现在有一个业务需要同时向记账系统和合作伙伴发送记账请求，那么这个时候我们可能会选择MQ通信。

4.2 分布式协调与同步

在我们了解了分布式通信之后，我认为接下来最重要的学习就是分布式协调和同步了。

因为在现实中，即使系统是分布式的，也往往不是很大架构师，分布式资源管理暂时可以忽略。分布式存储也可能仍然使用数据库的主备或抗性的方式。而且对分布式计算的需求可能没有那么迫切。

但是一旦分布式系统中的全局状态出错，那就是意外。因此，理解分布式协调和同步一定是紧迫而重要的。

如何学习协调和同步？

我们需要知道协调数据访问和同步数据访问是什么意思。实际上，协调数据访问的本质是对数据访问请求进行优先级排序，这就是协调数据访问的本质。以及如何定义优先级？优先级是根据什么定义的？这是我们需要学习的。

至于同步，其实就是对数据访问的保护。如何限制对数据的访问？限制数据访问的政策是什么？这就是同步的本质。

那么，如果我们了解了多线程的数据协调和同步，通过分布式和多线程的异同，我们就可以更加轻松快捷地掌握分布式协调的技术本质。

4.3 分布式存储

在了解了分布式协调和同步之后，我们应该重点关注分布式存储。因为业务的核心是数据，海量数据最终需要分布式存储来解决安全可靠的持久化问题。

了解分布式存储最重要的是什么？不是存储的各种实现，而是分布式存储的基础：CAP 理论。

通过理解CAP理论，就很容易理解分布式存储实现是如何实现相应的CP或AP的。而了解了CAP，我们就可以根据实际的业务需求来了解业务是需要CP还是AP，然后我们就可以根据这些来对分布式存储进行适当的选择。

4.4 分布式计算

在学习分布式存储的时候，这个时候我们应该学习分布式计算。因为分布式计算很可能成为重要的运营需求。而分布式计算，作为一个整体，共有四种模式。不管怎么改，都逃不过这四种模式。

从计算方法上看，一共有两种方法：

MR mode() mode 处理方面只有两种模式：

Actor Mode Mode4.5 分布式可靠性

至此，架构师在了解了这些知识后，就可以轻松完成一般公司的架构任务了。一个完整的前向分布式学习过程的知识几乎是一样的。

此时，我们还需要了解一般的分布式可靠性处理方案。其实一般不超过三个：

大量模块的负载均衡集群；一些有资源限制的模块的流量控制；当任一模块对应的服务器出现问题时，尽量避免影响系统正常运行，这称为故障隔离。至于以上三种解决方案，其中两种其实是非常通用的技术。即使大家不搞分布式，也还是需要学习和理解的。

仅针对第三种，故障隔离，需要深入了解。但是，故障隔离并不是高级别的黑科技。我们在做分布的时候，因为不同的模块有不同的机器，而且机器也是集群的，这种故障隔离是很自然的。

但是，有时，我们希望以更细粒度的方式隔离故障，例如，我们希望在线程级别或进程级别隔离故障。此时，我可以考虑使用线程或容器来执行任务，然后采用一些调度策略，在线程或进程级别自然隔离故障。

4.6 分布式资源管理

最后，我们要进一步研究处理更大的分布式系统，毕竟人是追求进步的。这时候就需要了解分布式架构相关的知识，也需要了解分布式资源管理。

但好在分布式资源管理本身的技术栈很小。对于分布式架构，有两种结构：

集中式结构和非集中式结构 分布式资源的分配或调度有三种方法：

单片调度 两层调度 共享状态调度 最后

上面，我将概述什么是分布式系统，我们为什么要做分布式系统，以及我们应该如何学习分布式系统。

读完是不是觉得有点空虚或迷茫？不用着急，以后我会写更多关于分布式的文章，这样会更容易理解，让大家可以花尽可能少的时间和成本去学习更多的分布式知识。

一口吃不下胖子，好戏才刚刚开始。

上面写的，我只是整体出来了一行，其实很多东西是可以并行学习的。此外，关于如何学习，仁者见仁，智者见智。不喜欢就不要喷了！

学习这些原理和知识的目的，本质是希望我们能够在技术和职场上走的更远，获得更高的工资，让大家的生活更美好。希望分享。

原文链接：

如果你觉得这篇文章对你有帮助，可以转发、关注、支持