架构师的成长之路，第一步该怎么迈？

程序员的学习、成长之路应该怎么规划，才能早日成为一名架构师呢？

还记得面试时，面试官问：“你有职业规划吗？”其实这个问题的目的是问想成长为什么样的人。我记得我当时的回答——架构师。

做过有关银行、物流等行业的项目，每天都在跟业务打交道，一路走来，发现自己的技术水平很多时候其实是随着项目的发展被迫成长的。其实，很多时候，自身水平达不到能顺利完成架构项目的水平，但是，为了挑战，为了技术成长，更是为了高薪资，只能咬牙坚持，熬夜学习，最终让自己能顺利设计和把控项目的架构。

其中，最为艰难的，就是去设计、架构、规划一整套，规模大的分布式系统。

要做到这些，首要做的是能明白分布式系统到底是什么。

1. 什么是分布式系统

分布式系统：学术定义简单来说就是一套由一组计算机协同工作，让用户感觉像是一个统一的整体的系统。

但是，由于这个定义定的过于简练，很多初入门的人会毫无感知的潜意识就会混淆了分布式系统和集群的概念。

我这里问下，当我们做高可用集群的时候，我们是在搞分布式系统吗？当我们并发不够，搞了一堆机器做负载均衡，我们是在搞分布式系统吗？数据库比如 MySQL 的主从，双主什么的是在搞分布式系统吗？

当你心里默默回答是，或者不清楚是不是的时候，你本身对分布式系统这个概念就已经糊涂了。

他们都不是分布式系统，他们就仅仅是个集群而已。因为这些集群少了分布式系统最核心的东西：

应用所在服务器之间的相互协作

• 集群和分布式，用生活中的例子来说明：

小饭店原来只有一个厨师，切菜、洗菜、备料、炒菜、全干。

后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，两个厨师的关系是集群。

为了让厨师专心炒菜，把菜做到极致，再请了个配菜师负责切菜、备菜、备料 ... 厨师和配菜师的关系是分布式。

一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。

一个配菜师因故请假了，但是其余的配菜师还是该啥就干啥，只是没请假的配菜师任务均匀的加量了，但他们的任务和职责是不变的，这是集群。

集群：多个人在一起作同样的事。

分布式：多个人在一起作不同的事。

• 区别联系 （上面的内容应该已经让你理解两者了）

1）在一本讲 tcp/ip 的书上有这样一句话：分布式是指多个系统协同合作完成一个特定任务的系统。

分布式是解决中心化管理的问题，把所有的任务叠加到一个节点处理，太慢了。

所以把一个大的问题拆分为多个小的问题，并分别解决，最终协同合作。分布式的主要工作是分解任务，将职能拆解。

2）集群主要的使用场景是为了分担请求的压力，也就是在几个服务器上部署相同的应用程序，来分担客户端请求。

当压力进一步增大的时候，可能在需要存储的部分，mysql 无法面对很多的写压力。因为在 mysql 做成集群之后，主要的写压力还是在 master 的机器上面，其他 slave 机器无法分担写压力，从而这个时候，也就引出来分布式。

分布式的主要应用场景是单台机器已经无法满足这种性能的要求，必须要融合多个节点，并且节点之间是相关之间有交互的。相当于在写 mysql 的时候，每个节点存储部分数据，也就是分布式存储的由来。存储一些非结构化数据：静态文件、图片、pdf、小视频 ... 这些也就是分布式文件系统的由来。

3）集群主要是简单加机器解决问题，对于问题本身不做任何分解；

分布式处理里必然包含任务分解与答案归并。分布式中的某个子任务节点，可能由一个集群来代替；集群中任一节点，都是做一个完整的任务。

集群和分布式都是由多个节点组成，但是集群之间的通信协调基本不需要；而分布式各个节点的通信协调必不可少。

将一套系统拆分成不同子系统部署在不同服务器上（这叫分布式），然后部署多个相同的子系统在不同的服务器上（这叫集群），部署在不同服务器上的同一个子系统应做负载均衡。

分布式：一个业务拆分为多个子业务，部署在多个服务器上。

集群：同一个业务，部署在多个服务器上。

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

为什么要搞分布式系统？答案很简单：形势所迫！一套分布式系统往往是由于业务发展后采取的终极方案。

分布式系统是由于业务发展后的终极解决方案。最终，业务复杂到拆分的地步，那么分布式系统就是天然的需求了。

我们需要的不是简单的直接把模块分散部署的无意义分布式，不是简单的模块分解。我们需要的是系统在被迫搞成分布式的情况下依然能够：

保持出色的性能

拥有着无比可靠的可用性

以及非常优秀的弹性

而为了保证以上这三个指标，就出现了分布式系统繁杂艰深的技术栈。

3. 分布式系统的技术栈

上面我们说了，分布式系统的出现完全是形式所迫，完全是业务发展导致的最终结果。而由于业务的拆分，我们又被迫会衍生出更多的分布式需求来，以及应对这些需求的技术：

因为业务拆分的多，业务对应的模块之间就需要通信，为了保证通信的快速可靠，我们需要掌握 分布式通信 技术。

业务拆分的过多，每个模块可能还需要搞集群，那么多服务器资源，为了能够保证资源的精准分配，我们还需要考虑 分布式资源管理 和负载调度技术。

业务拆分之后，模块与模块之间又需要对很多共享数据做访问，为了保证安全完整的数据状态，我们也要用到 分布式协调与同步 技术。

到了业务拆分的阶段，数据必然庞大，为了数据存储的可靠，为了保证优秀的数据读写性能，我们需要 分布式存储 技术。

业务如此复杂，为了公司的发展，业务能继续扩大，就需要能更加精准的营销和运营，我们还需要对数据进行实时、离线处理分析，此时，我们又得考虑 分布式计算 技术。

在业务拆分后，整体架构出现了巨变，不可能再用以前集群方式的思维去考虑高可用，那么 分布式的可靠性 技术又要纳入我们的掌握范畴。

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

在分布式技术栈中我们可以看到，其实分布式技术是有分类的，我们可以根据不同的分类去掌握每种类别的分布式技术背后的概念和思想。无论分布式技术有多少实现，这些实现永远都是以其所在分类的分布式技术原理作为核心底层来实现的。

同时，我们在学习当中，还必须理论联系实际，根据我们的实际开发和架构需要学习。

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

4.1 分布式通信

首先，分布式中的根基是什么？我认为是通信，最重要的其实是分布式系统中那些模块中的通信机制。

而通信机制该怎么学习？我认为首先要了解我们可用的各通信机制的区别。其中尤为重要的是了解各通信机制的缺点。

为什么缺点最重要呢？因为架构师在架构的时候，一项尤为重要的工作就是做技术选型。而技术选型的目标很多时候的应用场景往往非常模糊，如果能了解到各选型的缺点，则对选型的结果是否准确就起到了极其重要的作用。

比如，我们现在想搞模块间通信，那么到底是用 RPC 还是用 MQ ？此时，我们知道 RPC 的缺点和 MQ 的缺点的话，就能很容易做出更准确的选型。

RPC 的缺点:

不能搞流量削锋

不能广播给多个模块

消息投递没有保证

模块和模块之间没法解耦

MQ 的缺点：

不能保证延迟时间

不适合搞强一致性的事务

增加了系统的复杂度

降低了系统的可用性

知道了缺点，我们就很容易选型了。如果我们现在有个业务是实时扣费，我们肯定要搞 RPC，因为这是延迟敏感并且是需要强一致性。

如果我们现在有个业务是同时给会计系统和合作方发记账请求的需求，那这时候我们就可能选用 MQ 通信了。

4.2 分布式协调和同步

理解了分布式通信之后，下一步我认为最要学的是分布式协调和同步。

因为在现实里，即使系统搞成分布式了，其实往往没有特别大，分布式资源管理暂时可以先不考虑。分布式存储也可能还在使用数据库的主备或者 Sharding 方式在扛。而分布式计算的需求也可能没有那么紧急。

但是，一旦分布式系统中的全局状态出问题了，那就是事故了。所以，理解分布式协调和同步，一定是很紧急也很重要的。

协调和同步怎么学？

所谓的协调数据访问，同步数据访问到底是在做什么。其实协调数据访问的本质就是去对数据访问的请求做优先级排列，这就是协调数据访问的本质。而如何定义优先级？根据什么定义优先级？就是我们需要学习的东西。

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

然后，如果我们理解了多线程的数据协调和同步，我们通过分布式和多线程的相同和区别，能更容易更快速的去把握好分布式协调的技术本质。

4.3 分布式存储

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

而分布式存储最最重要的是理解什么？不是存储的各种实现，是分布式存储的立身之本： CAP 理论。

我们通过对 CAP 理论的理解，去理解分布式存储实现是如何实现对应的 CP 或者 AP 的，就会非常容易了。并且理解了 CAP，我们就能根据真实的业务需求，理解业务是需要 CP 还是 AP，然后就能根据这些，对分布式存储做合适的选型了。

4.4 分布式计算

当学习了分布式存储，此时，我们应该去学习分布式计算。因为分布式计算很可能会成为一个重要的运营需求。而分布式计算，就整体而言，一共就四种模式。

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

MR 方式（MapReduce）

Stream 方式

从处理过程来看，也只有两种模式：

Actor 模式

流水线模式

4.5 分布式可靠性

到此，在知道了这些知识之后，对于一般公司的架构任务，架构师们做起来就游刃有余了。一个完整的正向分布式学习流程的知识，其实就差不多了。

此时，我们还需要知道一般的分布式可靠性的处理方案。其实大体也不会超过三种：

对量大的模块搞负载均衡的集群；

对某些有资源限制条件的模块可以搞流量控制；

当任何模块对应的服务器出现问题时，想办法不让它影响正常的系统运转，而这个就叫做故障隔离。

而对于以上三种方案，其中两种其实都是很通用的技术，即使大家不搞分布式，也照样需要学习和了解。

唯独对于第三种，故障隔离，是需要深入了解下的。但是故障隔离并不是什么高大上的黑科技，当我们搞分布式的时候，由于天然是不同的模块有不同的机器，并且机器还做了集群，所以，这个故障隔离就是天然就有的。

只是，有的时候，我们想更细粒度的对故障隔离进行阻隔，比如，想在线程级别或者进程级别就把故障隔离开了。此时，我就就可以考虑用下线程或者容器等去执行任务，然后才去一些调度策略，把故障就天然的隔离为线程或者进程级别了。

4.6 分布式资源管理

最后，我们想深造能应对更庞大的分布式系统，毕竟人都是追求进步的。这时候，我们就需要去理解分布式的体系结构相关的知识，需要去理解分布式的资源管理。

但庆幸的是，分布式的资源管理本身技术栈很小。对于分布式体系结构，一共就两种结构：

集中式结构

非集中式结构

对于分布式资源的分配或者说调度，一共就三种方法：

单体调度

两层调度

共享状态调度

上面写的是整理出来一条线，但是很多东西其实也可以并行学习。另外，关于如何学习，这方面是仁者见仁，智者见智，以上只是一家之言。

本文地址：https://blog.csdn.net/Allenzyg/article/details/111036100