每个程序员，都但愿能成为分布式系统架构师

有不少读者常常问我，程序员的学习、成长之路应该怎么规划，才能早日成为一名架构师。

做为一个曾经的架构师，在我走上技术管理这条路以后，管理的团队愈来愈大，如今我管理的技术团队有一百多人，最大的体会就是操心的事情太多、会议太多，写代码的时间愈来愈少了。

趁我如今还有技术的底子，代码还没彻底忘光，我以为应该给你们说说架构师的成长之路了。接下来我准备写一系列关于架构师、分布式系统的技术文章。今天这篇文章至关因而一个综述，至关于咱们学 Java 语言的开篇：Hello World

好，正文开始。

做为一个资深架构师，一路走来，发现本身的技术水平不少时候实际上是随着项目的发展被迫成长的。其实，不少时候，自身水平达不到能顺利完成架构项目的水平，可是，为了挑战，为了技术成长，更是为了高薪资，只能咬牙坚持，熬夜学习，最终让本身能顺利设计和把控项目的架构。

其中，最为艰难的，就是去设计、架构、规划一整套，规模大的分布式系统。可是，正是经历了这些异常艰难的磨炼，咱们才能绝不恐惧所谓的技术人员 35 岁大限。

可是，要作到这些，首要作的是能明白分布式系统究竟是个什么东西。

1. 什么是分布式系统

分布式系统你们从网络上看到的学术定义简单来讲就是一套由一组计算机协同工做，让用户感受像是一个统一的总体的系统。

可是，因为这个定义定的过于简练，不少初入门的人会毫无感知的潜意识就会混淆了分布式系统的概念。

什么意思？我这里问下，当咱们用 keepalived 作高可用集群的时候，咱们是在搞分布式系统吗？当咱们并发不够，搞了一堆机器作负载均衡，咱们是在搞分布式系统吗？

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

这里，就须要为分布式系统画出一个边界来，并以此告知你们，并非多台机器堆在一块儿了就是分布式系统了。对于刚才那两个问题，正确的答案就是 keepalived 作的高可用集群，用 Nginx 或者 lvs 后面跟着一堆应用集群配合搞的负载均衡，他们都不是分布式系统，他们就仅仅是个集群而已。

相似的，数据库好比 MySQL 的主从，双主什么的固然也不是分布式系统。由于这些集群少了分布式系统最核心的东西：

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

为了说清集群和分布式，我再给你们举一个通俗易懂的例子：

假设有一天我开了个软件公司，公司就我一个程序员，前端、后端、测试的活儿，都是我干，一个月我能作完一个项目。

后来项目多了，我忙不过来了，为了多赚钱，怎么办呢，我想了两条路

1. 再招一个和我同样强的全栈工程师，我俩每一个人独立作项目，这样咱们一个月能作完两个项目。我俩就组成了一个集群。

2. 招一个前端、一个测试配合我，前端、后端、测试分头干。经过协做，咱们半个月能干完一个项目。这时候咱们的关系就是分布式。

从上面例子你就能看出:

• 集群中的多个服务器都在作相同的事情，并不能缩短处理一件事情的时间。

• 而分布式呢，是把事情拆开，多个服务器分头作事，能够缩短期。

知道了什么是分布式系统以后，一个最简单的分布式系统应该是什么样的？

假设咱们作了一套系统，这套系统仅有两个功能：1. 注册、2. 登陆

若是咱们想让这套系统变成分布式系统该怎么作？最简单的是，把注册功能和登陆功能分别作成两套子服务，而后部署到两台服务器上，让他们互相协做，这就变成了一套最简单的分布式系统。

你看到这里可能会很是震惊：
这就是一套分布式系统了？
我想学习的分布式系统的那么多技术栈呢？
那些高大上的算法呢？
能瞬间闪回的容错机制呢？
无缝热升级的功能呢？
问题到底出如今哪里？
咱们搭建的这套简单的系统真的是咱们平常谈论的分布式系统吗？

2. 为何咱们要搞分布式系统

为何要搞分布式系统？答案很简单：形势所迫！一套分布式系统每每是因为业务发展后采起的终极方案。

假如公司新开展了一项在线业务，而咱们所以要为这套业务搭建开发一套业务系统。每每这时候，因为项目前景未知，又因为要快速上线进入市场作试错，此时，咱们可能会优先搞一套单体架构，先上线。

随着业务的开展和运营，咱们每每面临的第一个问题是系统的崩溃和服务器的宕机。

这时候，你们就搞一套高可用架构来解决问题。把相同的项目部署在多台机器上，一台机器出问题了，直接换到另一台提供服务便可。

随后，因为业务进一步的发展和壮大，此时，出现瓶颈的每每就是系统的响应时间了。响应时间的增长直接影响了用户体验，而这自己也反映了吞吐量出现了瓶颈。

对于这种问题，架构师们就会祭出集群大法好的思路来搞定。这时候，系统架构开始复杂了起来，由于别忘了，咱们在保证负载均衡的同时，还须要保证服务的高可用。

到目前为止，貌似没什么问题了。咱们经过高可用保证了系统的可靠性，经过负载均衡，分散了系统的压力。

可是，以上这些方案都不是分布式，系统也不是分布式系统，依然是 Monoliths 这种被一些技术疯子们嘲笑的笨重架构。

咱们还须要分布式吗？

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

从这张图能够看出，业务发展到后面会有多么复杂。面对如此复杂的业务，咱们发现咱们以前搞的那种集群怎么也说不过去了。

这时候，就须要进行业务的拆分。

虽然业务拆分了，可是这些业务终究是要对外合做提供一个总体的服务的，这时候，才是真正须要分布式系统的时候了。咱们须要一组在不一样的服务器上相互协做的系统。

因此咱们说，分布式系统是因为业务发展后的终极解决方案。最终，业务复杂到拆分的地步，那么分布式系统就是自然的需求了。

在这里，咱们也能够解答下上节咱们面临的问题了。咱们须要的不是简单的直接把模块分散部署的无心义分布式，不是简单的模块分解。咱们须要的是系统在被迫搞成分布式的状况下依然可以：

1. 保持出色的性能
2. 拥有着无比可靠的可用性
3. 以及很是优秀的弹性

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

3. 分布式系统的技术栈

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

• 由于业务拆分的多，业务对应的模块之间就须要通讯，为了保证通讯的快速可靠，咱们须要掌握分布式通讯技术。

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

• 业务拆分以后，模块与模块之间又须要对不少共享数据作访问，为了保证安全完整的数据状态，咱们也要用到分布式协调与同步技术。

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

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

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

你看分布式系统的技术栈这么多、这么复杂对吧，别慌。

我写这篇文章不是为了劝退大家的，咱们要学习必须分步骤分主题的学习，对总体的分布式技术栈分而克之，逐步掌握。

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

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

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

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

4.1 分布式通讯

那具体到底如何作呢？

首先，分布式中的根基是什么？就我本身的经历而言，我认为是通讯，最重要的其实分布式系统中那些模块中的通讯机制。

而通讯机制该怎么学习？我认为首先要了解咱们可用的各通讯机制的区别。其中尤其重要的是了解各通讯机制的缺点。对，你没看错，就是缺点。

为何缺点最重要呢？由于架构师在架构的时候，一项尤其重要的工做就是作技术选型。而技术选型的目标不少时候的应用场景每每很是模糊，若是能了解到各选型的缺点，则对选型的结果是否准确就起到了极其重要的做用。

好比，咱们如今想搞模块间通讯，那么究竟是用 RPC 仍是用 MQ ？此时，咱们知道 RPC 的缺点和 MQ 的缺点的话，就能很容易作出更准确的选型。

RPC 的缺点:

1. 不能搞流量削锋
2. 不能广播给多个模块
3. 消息投递没有保证
4. 模块和模块之间无法解耦

MQ 的缺点：

1. 不能保证延迟时间
2. 不适合搞强一致性的事务
3. 增长了系统的复杂度
4. 下降了系统的可用性

好了，知道了缺点，咱们就很容易选型了。若是咱们如今有个业务是实时扣费，咱们确定要搞 RPC，由于这是延迟敏感而且是须要强一致性。

若是咱们如今有个业务是同时给会计系统和合做方发记帐请求的需求，那这时候咱们就可能选用 MQ 通讯了。

4.2 分布式协调和同步

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

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

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

那协调和同步怎么学呢？

咱们要知道，咱们所谓的协调数据访问，同步数据访问究竟是在作什么。其实协调数据访问的本质就是去对数据访问的请求作优先级排列，这就是协调数据访问的本质。而如何定义优先级？根据什么定义优先级？就是咱们须要学习的东西。

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

而后，若是咱们理解了多线程的数据协调和同步，咱们经过分布式和多线程的相同和区别，能更容易更快速的去把握好分布式协调的技术本质。

4.3 分布式存储

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

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

咱们经过对 CAP 理论的理解，去理解分布式存储实现是如何实现对应的 CP 或者 AP 的，就会很是容易了。而且理解了 CAP，咱们就能根据真实的业务需求，理解业务是须要 CP 仍是 AP，而后就能根据这些，对分布式存储作合适的选型了。

4.4 分布式计算

当学习了分布式存储，此时，咱们就应该去学习分布式计算。由于分布式计算极可能会成为一个重要的运营需求。而分布式计算，就总体而言，一共就四种模式。任你变幻无穷，都逃不掉这四种模式。

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

1. MR 方式（MapReduce）
2. Stream 方式

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

1. Actor 模式
2. 流水线模式

4.5 分布式可靠性

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

此时，咱们还须要知道通常的分布式可靠性的处理方案。其实大致也不会超过三种：

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

2. 对某些有资源限制条件的模块能够搞流量控制；

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

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

惟独对于第三种，故障隔离，是须要深刻了解下的。可是故障隔离并非什么高大上的黑科技，当咱们搞分布式的时候，因为自然是不一样的模块有不一样的机器，而且机器还作了集群，因此，这个故障隔离就是自然就有的。

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

4.6 分布式资源管理

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

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

1. 集中式结构
2. 非集中式结构

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

1. 单体调度
2. 两层调度
3. 共享状态调度

最后

以上，我将分布式系统是什么，为何要作分布式系统以及分布式系统咱们到底该怎么学大致说了一下。

是否是看完以后感受有点空，感受有点懵，别着急，后续我会写出更多的关于分布式的文章，写的通俗易懂一些，让你们能尽可能花更少的时间、成本，学到更多的分布式知识。

一口吃不成个胖子，好戏刚刚开始。

上面写的，我只是总体出来了一条线，可是不少东西其实也能够并行学习。另外，关于如何学习，这方面是仁者见仁，智者见智，不喜勿喷！

学习这些原理和知识的目的本质就是但愿咱们能在技术上、在职场上更进一步，能获取更高的薪资，让你们生活更好。望共勉。

最最后

我准备了一些纯手打的高质量PDF：

深刻浅出Java多线程、HTTP超全汇总、Java基础核心总结、程序员必知的硬核知识大全、简历面试谈薪的超全干货。

别看数量很少，但篇篇都是干货，看完的都说很肝。

领取方式：扫码关注后，在公众号后台回复：666