mod

极客时间专栏/分布式技术原理与算法解析/课前必读/01 | 分布式缘何而起：从单兵，到游击队，到集团军.md

@@ -0,0 +1,107 @@
+<audio id="audio" title="01 | 分布式缘何而起：从单兵，到游击队，到集团军" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a2/45/a2e4b3afc12cabe1e9d9098495137b45.mp3"></audio>
+
+你好，我是聂鹏程。这是专栏的第一篇文章，我们先来聊聊什么是分布式。
+
+与其直接用些抽象、晦涩的技术名词去给分布式下一个定义，还不如从理解分布式的发展驱动因素开始，我们一起去探寻它的本质，自然而然地也就清楚它的定义了。
+
+在今天这篇文章中，我将带你了解分布式的起源，是如何从单台计算机发展到分布式的，进而帮助你深入理解什么是分布式。为了方便你更好地理解这个演进过程，我将不考虑多核、多处理器的情况，假定每台计算机都是单核、单处理器的。
+
+## 分布式起源
+
+### 单兵模式：单机模式
+
+1946年情人节发布的ENIAC是世界上的第一台通用计算机，它占地170平米重达30吨，每秒可进行5000次加法或者400次乘法运算，标志着单机模式的开始。
+
+所谓**单机模式**是指，所有应用程序和数据均部署在一台电脑或服务器上，由一台计算机完成所有的处理。
+
+以铁路售票系统为例，铁路售票系统包括用户管理、火车票管理和订单管理等模块，数据包括用户数据、火车票数据和订单数据等，如果使用单机模式，那么所有的模块和数据均会部署在同一台计算机上，也就是说数据存储、请求处理均由该计算机完成。这种模式的好处是功能、代码和数据集中，便于维护、管理和执行。
+
+单机模式的示意图，如下所示：
+
+<img src="https://static001.geekbang.org/resource/image/9b/33/9b57d43a105675d931d43cbf03576d33.jpg" alt="">
+
+这里需要注意的是，**本文的所有示意图中，紫色虚线表示在一台计算机内。**
+
+事物均有两面性，我们再来看看单机模式的缺点。单个计算机的处理能力取决于CPU和内存等，但硬件的发展速度和性能是有限的，而且升级硬件的性价比也是我们要考虑的，由此决定了CPU和内存等硬件的性能将成为单机模式的瓶颈。
+
+你有没有发现，单机模式和单兵作战模式非常相似，单台计算机能力再强，就好比特种兵以一敌百，但终归能力有限。此外，将所有任务都交给一台计算机，也会存在将所有鸡蛋放到一个篮子里的风险，也就是单点失效问题。
+
+归纳一下，单机模式的主要问题是：**性能受限、存在单点失效问题。**
+
+### 游击队模式：数据并行或数据分布式
+
+既然单机模式存在性能和可用性的问题。那么，有没有什么更好的计算模式呢？答案是肯定的。
+
+为解决单机模式的问题，并行计算得到了发展，进而出现了数据并行（也叫作数据分布式）模式。**并行计算**采用消息共享模式使用多台计算机并行运行或执行多项任务，核心原理是每台计算机上执行相同的程序，将数据进行拆分放到不同的计算机上进行计算。
+
+请注意，并行计算强调的是对数据进行拆分，任务程序在每台机器上运行。要达到这个目的，我们必须首先把单机模式中的应用和数据分离，才可能实现对数据的拆分。这里的应用就是执行任务的程序，任务就是提交的请求。以铁路售票系统为例，运行在服务器上的用户管理、火车票管理和订单管理等程序就是应用，用户提交的查询火车票、购买火车票的请求就是任务。
+
+在单机模式中，应用和数据均在一台计算机或服务器上，要实现数据的并行，首先必须将应用和数据分离以便将应用部署到不同的计算机或服务器上；然后，对同类型的数据进行拆分，比方说，不同计算机或服务器上的应用可以到不同的数据库上获取数据执行任务。
+
+以铁路售票系统的数据并行为例，主要包括两个步骤，如下所示：
+
+**第一步**，将应用与数据分离，分别部署到不同的服务器上：
+
+<img src="https://static001.geekbang.org/resource/image/22/ac/22f41598926f58bb47533e30007c8cac.jpg" alt="">
+
+**第二步**，对数据进行拆分，比如把同一类型的数据拆分到两个甚至更多的数据库中，这样应用服务器上的任务就可以针对不同数据并行执行了。
+
+对于铁路售票系统来说，根据线路将用户、火车票和订单数据拆分到不同的数据库中，部署到不同的服务器上，比如京藏线的数据放在数据库服务器1上的数据库中，沪深线的数据放在数据库服务器2上的数据库中。
+
+<img src="https://static001.geekbang.org/resource/image/56/a0/568c3fba1bac04aa320db2f1cf0258a0.jpg" alt="">
+
+需要注意的是，为了更好地帮助你理解这个数据拆分的过程，我在这里选择拆分数据库的方式进行讲解。由于数据库服务器本身的并发特性，因此你也可以根据你的业务情况进行选择，比方说所有业务服务器共用一个数据库服务器，而不一定真的需要去进行数据库拆分。
+
+可以看出，在数据并行或数据分布式模式中，每台计算机都是全量地从头到尾一条龙地执行一个程序，就像一个全能的铁道游击队战士。所以，你也可以将这种模式形象地理解成游击队模式，就和铁道游击队插曲的歌词有点类似：“我们扒飞车那个搞机枪，撞火车那个炸桥梁……”
+
+这种模式的好处是，可以利用多台计算机并行处理多个请求，使得我们可以在相同的时间内完成更多的请求处理，解决了单机模式的计算效率瓶颈问题。但这种模式仍然存在如下几个问题，在实际应用中，我们需要对其进行相应的优化：
+
+- 相同的应用部署到不同的服务器上，当大量用户请求过来时，如何能比较均衡地转发到不同的应用服务器上呢？解决这个问题的方法是设计一个负载均衡器，我会在“分布式高可靠”模块与你讲述负载均衡的相关原理。
+- 当请求量较大时，对数据库的频繁读写操作，使得数据库的IO访问成为瓶颈。解决这个问题的方式是读写分离，读数据库只接收读请求，写数据库只接收写请求，当然读写数据库之间要进行数据同步，以保证数据一致性。
+- 当有些数据成为热点数据时，会导致数据库访问频繁，压力增大。解决这个问题的方法是引入缓存机制，将热点数据加载到缓存中，一方面可以减轻数据库的压力，另一方面也可以提升查询效率。
+
+从上面介绍可以看出，数据并行模式实现了多请求并行处理，但如果单个请求特别复杂，比方说需要几天甚至一周时间的时候，数据并行模式的整体计算效率还是不够高。
+
+由此可见，数据并行模式的主要问题是：**对提升单个任务的执行性能及降低时延无效。**
+
+### 集团军模式：任务并行或任务分布式
+
+那么，有没有办法可以提高单个任务的执行性能，或者缩短单个任务的执行时间呢？答案是肯定的。任务并行（也叫作任务分布式）就是为解决这个问题而生的。那什么是任务并行呢？
+
+任务并行指的是，将单个复杂的任务拆分为多个子任务，从而使得多个子任务可以在不同的计算机上并行执行。
+
+我们仍以铁路售票系统为例，任务并行首先是对应用进行拆分，比如按照领域模型将用户管理、火车票管理、订单管理拆分成多个子系统分别运行在不同的计算机或服务器上。换句话说，原本包括用户管理、火车票管理和订单管理的一个复杂任务，被拆分成了多个子任务在不同计算机或服务器上执行，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/59/f2/59f6e43fcd6a6d28741841fc312c10f2.jpg" alt="">
+
+可以看出，任务并行模式完成一项复杂任务主要有两个核心步骤：首先将单任务拆分成多个子任务，然后让多个子任务并行执行。这种模式和集团军模式很像，任务拆分者对应领导者，不同子系统对应不同兵种，不同子程序执行不同任务就像不同的兵种执行不同的命令一样，并且运行相同子系统或子任务的计算机又可以组成一个兵团。
+
+在集团军模式中，由于多个子任务可以在多台计算机上运行，因此通过将同一任务待处理的数据分散到多个计算机上，在这些计算机上同时进行处理，就可以加快任务执行的速度。因为，只要一个复杂任务拆分出的任意子任务执行时间变短了，那么这个任务的整体执行时间就变短了。
+
+当然，nothing is perfect。**集团军模式在提供了更好的性能、扩展性、可维护性的同时，也带来了设计上的复杂性问题**，毕竟对一个大型业务的拆分也是一个难题。不过，对于大型业务来讲，从长远收益来看，这个短期的设计阵痛是值得的。这也是许多大型互联网公司、高性能计算机构等竞相对业务进行拆分以及重构的一个重要原因。
+
+## 分布式是什么？
+
+讲了半天，那到底什么是分布式呢？
+
+**总结一下，分布式其实就是将相同或相关的程序运行在多台计算机上，从而实现特定目标的一种计算方式。**
+
+从这个定义来看，数据并行、任务并行其实都可以算作是分布式的一种形态。从这些计算方式的演变中不难看出，**产生分布式的最主要驱动力量，是我们对于性能、可用性及可扩展性的不懈追求。**
+
+## 总结
+
+在今天这篇文章中，我和你分享了分布式的起源，即从单机模式到数据并行（也叫作数据分布式）模式，再到任务并行（也叫作任务分布式）模式。
+
+单机模式指的是，所有业务和数据均部署到同一台机器上。这种模式的好处是功能、代码和数据集中，便于维护、管理和执行，但计算效率是瓶颈。也就是说单机模式性能受限，也存在单点失效的问题。
+
+数据并行（也叫作数据分布式）模式指的是，对数据进行拆分，利用多台计算机并行执行多个相同任务，通过在相同的时间内完成多个相同任务，从而缩短所有任务的总体执行时间，但对提升单个任务的执行性能及降低时延无效。
+
+任务并行（也叫作任务分布式）模式指的是，单任务按照执行流程，拆分成多个子任务，多个子任务分别并行执行，只要一个复杂任务中的任意子任务的执行时间变短了，那么这个业务的整体执行时间也就变短了。该模式在提高性能、扩展性、可维护性等的同时，也带来了设计上的复杂性问题，比如复杂任务的拆分。
+
+在数据并行和任务并行这两个模式的使用上，用户通常会比较疑惑，到底是采用数据并行还是任务并行呢？一个简单的原则就是：任务执行时间短，数据规模大、类型相同且无依赖，则可采用数据并行；如果任务复杂、执行时间长，且任务可拆分为多个子任务，则考虑任务并行。在实际业务中，通常是这两种模式并用。赶紧行动起来，去分析一下你的业务到底应该采用哪种分布式模式吧，加油！
+
+## 课后思考
+
+你觉得分布式与传统的并行计算的区别是什么？你可以结合多核、多处理器的情况进行思考。
+
+我是聂鹏程，感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！

极客时间专栏/分布式技术原理与算法解析/课前必读/02 | 分布式系统的指标：啥是分布式的三围.md

@@ -0,0 +1,92 @@
+<audio id="audio" title="02 | 分布式系统的指标：啥是分布式的三围" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9f/91/9f3d3ee4aabf5d8259f57eb741ba2291.mp3"></audio>
+
+你好，我是聂鹏程。
+
+在上一篇文章中，通过对分布式发展历程的学习，我们对分布式技术有了一个整体印象。接下来，我们就再来看看可以用哪些指标去具体地衡量一个分布式系统。如果你已经对分布式系统的指标了解得很清楚了，可以直接跳过这篇文章，学习下一讲的内容。
+
+## 分布式系统的指标
+
+从分布式技术的起源可以看出，分布式系统的出现就是为了用廉价的、普通的机器解决单个计算机处理复杂、大规模数据和任务时存在的性能问题、资源瓶颈问题，以及可用性和可扩展性问题。换句话说，分布式的目的是**用更多的机器，处理更多的数据和更复杂的任务。**
+
+由此可以看出，**性能、资源、可用性和可扩展性**是分布式系统的重要指标。没错，它们就是分布式系统的“三围”。接下来，我们一起来看看这几个指标吧。
+
+### 性能（Performance）
+
+性能指标，主要用于衡量一个系统处理各种任务的能力。无论是分布式系统还是单机系统，都会对性能有所要求。
+
+不同的系统、服务要达成的目的不同，关注的性能自然也不尽相同，甚至是相互矛盾。常见的性能指标，包括吞吐量（Throughput）、响应时间（Response Time）和完成时间（Turnaround Time）。
+
+**吞吐量**指的是，系统在一定时间内可以处理的任务数。这个指标可以非常直接地体现一个系统的性能，就好比在客户非常多的情况下，要评判一个银行柜台职员的办事效率，你可以统计一下他在1个小时内接待了多少客户。常见的吞吐量指标有QPS（Queries Per Second）、TPS（Transactions Per Second）和BPS（Bits Per Second）。
+
+- QPS，即查询数每秒，用于衡量一个系统每秒处理的查询数。这个指标通常用于读操作，越高说明对读操作的支持越好。所以，我们在设计一个分布式系统的时候，如果应用主要是读操作，那么需要重点考虑如何提高QPS，来支持高频的读操作。
+- TPS，即事务数每秒，用于衡量一个系统每秒处理的事务数。这个指标通常对应于写操作，越高说明对写操作的支持越好。我们在设计一个分布式系统的时候，如果应用主要是写操作，那么需要重点考虑如何提高TPS，来支持高频写操作。
+- BPS，即比特数每秒，用于衡量一个系统每秒处理的数据量。对于一些网络系统、数据管理系统，我们不能简单地按照请求数或事务数来衡量其性能。因为请求与请求、事务与事务之间也存在着很大的差异，比方说，有的事务大需要写入更多的数据。那么在这种情况下，BPS更能客观地反映系统的吞吐量。
+
+**响应时间**指的是，系统响应一个请求或输入需要花费的时间。响应时间直接影响到用户体验，对于时延敏感的业务非常重要。比如用户搜索导航，特别是用户边开车边搜索的时候，如果响应时间很长，就会直接导致用户走错路。
+
+**完成时间**指的是，系统真正完成一个请求或处理需要花费的时间。任务并行（也叫作任务分布式）模式出现的其中一个目的，就是缩短整个任务的完成时间。特别是需要计算海量数据或处理大规模任务时，用户对完成时间的感受非常明显。
+
+### 资源占用（Resource Usage）
+
+资源占用指的是，一个系统提供正常能力需要占用的硬件资源，比如CPU、内存、硬盘等。
+
+一个系统在没有任何负载时的资源占用，叫做**空载资源占用**，体现了这个系统自身的资源占用情况。比如，你在手机上安装一个App，安装的时候通常会提示你有多少KB，这就是该App的空载硬盘资源占用。对于同样的功能，空载资源占用越少，说明系统设计越优秀，越容易被用户接受。
+
+一个系统满额负载时的资源占用，叫做**满载资源占用**，体现了这个系统全力运行时占用资源的情况，也体现了系统的处理能力。同样的硬件配置上，运行的业务越多，资源占用越少，说明这个系统设计得越好。
+
+### 可用性（Availability）
+
+可用性，通常指的是系统在面对各种异常时可以正确提供服务的能力。可用性是分布式系统的一项重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。
+
+系统的可用性可以用**系统停止服务的时间与总的时间之比衡量。**假设一个网站总的运行时间是24小时，在24小时内，如果网站故障导致不可用的时间是4个小时，那么系统的可用性就是4/24=0.167，也就是0.167的比例不可用，或者说0.833的比例可用。
+
+除此之外，系统的可用性还可以用**某功能的失败次数与总的请求次数之比来衡量**，比如对网站请求1000次，其中有10次请求失败，那么可用性就是99%。
+
+你可能经常在一个系统的宣传语中见到或听到3个9（或3N，3 Nines）、5个9（或9N，9 Nines）。这些宣传语中所说的3个9、5个9，实际上就是系统厂商对可用性的一种标榜，表明该系统可以在99.9%或99.999%的时间里能对外无故障地提供服务。
+
+讲到了可用性，你可能还会想到一个非常近似的术语：可靠性（Reliability）。那**可靠性和可用性有什么区别呢？**
+
+**可靠性**通常用来表示一个系统完全不出故障的概率，更多地用在硬件领域。而**可用性**则更多的是指在允许部分组件失效的情况下，一个系统对外仍能正常提供服务的概率。
+
+杰夫 · 迪恩（Jeff Dean）曾在Google I/O大会上透露：谷歌一个基于1000台通用计算机的集群，一年之内就有1000+硬盘会出现故障。由于现在比较常见的分布式系统基本上都是基于通用计算机的，这就意味着在这些系统中无法实现真正的可靠，所以我们也会在一些场合见到可靠性和可用性交换使用的情况。
+
+### 可扩展性（Scalability）
+
+可扩展性，指的是分布式系统通过扩展集群机器规模提高系统性能(吞吐量、响应时间、 完成时间)、存储容量、计算能力的特性，是分布式系统的特有性质。
+
+分布式系统的设计初衷，就是利用集群多机的能力处理单机无法解决的问题。然而，完成某一具体任务所需要的机器数目，即集群规模，取决于单个机器的性能和任务的要求。
+
+**当任务的需求随着具体业务不断提高时，除了升级系统的性能做垂直/纵向扩展外，另一个做法就是通过增加机器的方式去水平/横向扩展系统规模。**
+
+这里垂直/纵向扩展指的是，增加单机的硬件能力，比如CPU增强、内存增大等；水平/横向扩展指的就是，增加计算机数量。好的分布式系统总是在追求“线性扩展性”，也就是说系统的某一指标可以随着集群中的机器数量呈线性增长。
+
+衡量系统可扩展性的常见指标是加速比（Speedup），也就是一个系统进行扩展后相对扩展前的性能提升。
+
+- 如果你的扩展目标是为了提高系统吞吐量，则可以用扩展后和扩展前的系统吞吐量之比进行衡量。
+- 如果你的目标是为了缩短完成时间，则可以用扩展前和扩展后的完成时间之比进行衡量。
+
+## 不同场景下分布式系统的指标
+
+我们都希望自己的分布式系统是高性能、高可用、高扩展和低资源占用的。但出于硬件成本、开发效率等因素的约束，我们无法在性能、可用性、可靠性和资源占用做到面面俱到。因此，在不同的业务场景中，设计者们需要有所取舍。
+
+接下来，我带你一起看一下典型的电商、IoT、电信、HPC（高性能计算）、大数据、云计算、区块链等业务或系统对不同指标的诉求。
+
+- **电商系统。**对于一个电商系统而言，系统设计者最看重的是吞吐量，为了处理更多的用户访问或订单业务，甚至不惜牺牲一些硬件成本。
+- **IoT。**对于一个IoT系统而言，设计者最看重的是资源占用指标，因为在一些功能极简的IoT设备上RAM、ROM的可用资源通常都是KB级的。
+- **电信业务。**对于电信业务而言，最重要的无疑是响应时间、完成时间，以及可用性。因为，你在打电话时不希望你的声音半天才被对方听到，也不希望半天才听到对方的回应，更不希望你的电话无法拨出。
+- **HPC。**HPC系统最显著的特点是任务执行时间极长，一个天体物理任务的分析和计算通常耗时数周甚至数月。因此，通过水平扩展来提高系统的加速比，是HPC系统设计者需要关注的。
+- **大数据。**大数据任务的处理时间可能相对HPC系统来讲比较短，但常见的完成时间也达到了小时级，所以扩展性也是大数据系统首先要考虑的。
+- **云计算。**对于一个云计算系统而言，常见任务是虚拟主机或容器的创建、资源调整、销毁等操作，如何减少这些操作的完成时间，从而提升用户体验是设计者们要重点关注的。另外，云计算系统本质上卖的是资源，那么降低系统本身的资源开销，也是系统设计的重中之重。
+- **区块链。**区块链的吞吐量比较低，比特币的TPS只有7次每秒，单平均一次交易的确认就需要10分钟左右，因此吞吐量和完成时间通常是区块链系统设计者的首要目标。
+
+<img src="https://static001.geekbang.org/resource/image/24/6a/24e536a1903c871b3ffd9e70eb7f836a.jpg" alt="">
+
+## 总结与思考
+
+按照不同维度，分布式系统的指标可以分为性能、资源占用、可用性、可扩展性这四大类。我们自然希望自己的系统，是高性能、高可用、高扩展和低资源占用的，但考虑到硬件成本、开发效率等因素，必须要在设计不同的系统、业务时有所取舍。
+
+所以，我又和你分析了典型的电商、IoT、电信、HPC（高性能计算）、大数据、云计算、区块链等业务或系统的不同诉求，进而得出了系统设计者需要关注哪些指标。你在设计其他类型的系统时，可以按照这个思路进行取舍。
+
+我在文中提到了，分布式系统的指标之间会存在一些冲突或约束。那你不妨思考一下：我们今天讲解的指标中，哪些指标之间是相互制约、相互冲突的，它们又是如何制约的呢？
+
+我是聂鹏程，感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再会！

极客时间专栏/分布式技术原理与算法解析/课前必读/开篇词 | 四纵四横，带你透彻理解分布式技术.md

@@ -0,0 +1,58 @@
+<audio id="audio" title="开篇词 | 四纵四横，带你透彻理解分布式技术" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/23/1d/23a3eca405b2639db14c7be49ef8601d.mp3"></audio>
+
+你好，我是聂鹏程，智载云帆的CTO。在接下来的三个月时间里，我将带你打卡分布式技术。
+
+在众多计算机技术当中，分布式技术无疑是最璀璨的明珠之一。毫不夸张地说，没有分布式技术就没有互联网，也就没有现在的阿里巴巴、腾讯、亚马逊、Facebook、谷歌等科技巨头，更不会有以信息技术为核心的、对人类历史产生巨大变革的第三次工业革命。万维网、Email、DNS等，都是分布式系统的典型代表。
+
+随着分布式技术的不断发展，它也早已不再局限于传统的互联网等应用场景。在今年的两会期间，全国政协委员、360董事长周鸿祎更是大唱I’M ABCDE字母歌。**IMABCDE这7个字母所代表的IoT物联网、Mobile移动计算、AI人工智能、Blockchain区块链、Cloud云计算、Data大数据、Edge边缘计算，也无不都是以分布式技术为基石。**
+
+无疑，**谁更好地掌握了分布式技术，谁就更容易在新一轮技术浪潮中获得主动。**在全球经济增速趋缓的大背景下，与许多应用业务大量裁人形成鲜明对比的是，各大巨头的中间件团队、实验室等基础部门，依然在大规模地招兵买马。随着业务扩展，以及IMABCDE等新兴技术领域的布局，分布式技术人才已然成为巨头们争夺的焦点。
+
+**一方面是各大厂商的求贤若渴，一方面是分布式专业技术人才的一将难求。**在多年的面试中，我经常能体会到，有些面试者确实非常积极主动，但他们表现出来的水平却无法通过面试。分布式技术人才市场的供应与需求，俨然一首冰与火之歌。
+
+2007年，我在西安电子科技大学攻读博士期间，就开始研究并行与分布式计算；毕业后，在IBM做过HPC大规模负载管理系统LSF相关的设计和研发工作，在华为负责过分布式IoT相关项目的架构设计，以及电信级业务微服务框架、函数服务框架的设计工作，也从事过区块链相关的研究工作。现在，我在智载云帆负责技术体系的构建，专注于无服务器Serverless的架构实践。
+
+从我深入研究分布式技术这十多年的经验来看，分布式技术概念繁多、知识庞杂、新兴技术层出不穷，令许多新手望而却步，而许多有一定年限工作经验的老手，虽然也能对一些概念滔滔不绝，但追问到实质性问题就变得磕磕巴巴，顾左右而言它。比如：
+
+- 各种分布式概念、名词学了一大堆，但经常张冠李戴，傻傻分不清楚；
+- 做了多年技术，也参与了很多分布式技术实践，却无法回答工作中各种分布式技术、组件、框架选型背后的根源；
+- 在一个分布式技术配套的典型场景往往能驾轻就熟，但一旦稍微变更考察业务场景、业务目标后，就变得毫无头绪。
+
+究其原因，主要是**知识碎片化、不成体系、见树不见林。**如果再追究更深层次的原因，那无外乎就是两点：
+
+- **在计算机学科课程设置中，分布式技术尴尬如同中小学中的性教育，重要但不受重视。**鲜有高校在计算机本科专业中设置分布式课程，即便是有些高校在研究生教育中设置了相关课程，也是如同高手过招点到为止。
+- **信息碎片化与信息孤立。**在信息泛滥的信息时代，各种经典教材、最新文章自然是唾手可得。但，教材固然经典但严谨有余浅出不够，最重要的是没有与时下最新的场景相结合，一方面是因为教材“年久失修”，另一方面确实是因为分布式领域新技术推出的速度令人叹为观止；而网上的各种技术文章虽然多，却鲜有体系化的说明，一个个概念如同一座座信息孤岛。**如果不能体系化地理解这些概念，何谈掌握，更谈不上真正地去综合运用这些知识了。**
+
+因为工作太忙，这些年我整体而系统的输出比较少。偶然一次听到任正非的讲话，他提到了基础教育、孩子是一个社会的未来，这让我感触良多。我想，如果说一个社会的未来，离不开朝气蓬勃的孩子们，那么**一个行业的兴盛，同样也离不开一个广泛的从业者基础。**而我如果能做好分布式通识课这样的一个专栏，既可以对自己这些年的经验做一次系统梳理，温故而知新，又能帮助更多的人系统理解并掌握分布式核心技术，为整个行业的兴盛略尽绵薄之力，何乐而不为呢？
+
+其实，在工作、面试、演讲等多种场合，也经常会有人问我：“聂博士，分布式领域的新概念繁多、各种框架五花八门、各种组件层出不穷，应该如何应对啊？”我回答说：“其实你已经有答案了。”
+
+看着他们满脸疑惑，我笑着问：“RISC芯片，程序设计中的封装、继承，还有现在提倡的中台战略，它们都在做一件什么事情呢？”他们答道：“莫非是重用？”
+
+我说：“是的，**既然指令可以重用，代码可以重用，技术、业务、数据等都可以重用，为什么知识体系不可以呢？学好分布式通识课，掌握了分布式的核心技术、体系，你就会发现很多新技术、新框架、新组件只不过是‘新瓶装旧酒’，将分布式核心技术进行了再包装、再组合，至多也就是做了一点延伸而已。”**
+
+那么，分布式通识课究竟该如何学呢？在接下来的三个月时间里，我会遵循以下4个思路带着你一起学习。
+
+第一，分布式技术错综复杂，各种技术相互耦合，确实无法简单地像网络等技术一样划分层次，所以我会结合自己多年的积累和思考，首先为你梳理出一个脉络清晰、**四纵四横**的分布式核心技术知识体系，然后从这个纵横的技术体系中抽取最核心、最普适的技术思想以及概念，结合各种适用场景一一解析。这样的设计，旨在帮助你找到核心知识点，并将这些知识点联系起来，快速形成分布式核心技术的知识网络，从而形成自己的技术判断力，进而规划出自己的技术路线。
+
+第二，从一个熟知的事物出发，进行浅出的讲解，帮助你从已有知识体系扩展到新的知识体系，从而迅速、牢固地掌握分布式技术的核心知识点。
+
+第三，透过表象深入讲解技术本质，而不是case by case地讲解，帮助你知其然并知其所以然，真正做到理解与运用时的举一反三。
+
+第四，针对同一分布式问题的不同方法，从多维度、多角度进行对比、分析，方便你在工作中灵活选型，避免重复“造轮子”。你甚至可以综合权衡各种方法的优缺点，提炼发明出新的方法，最终做到活学活用。
+
+讲到这里，你是不是也有点摩拳擦掌、跃跃欲试了呢？“分布式世界这么大，我要去看看！”别慌，请先看完这份技术地图。
+
+<img src="https://static001.geekbang.org/resource/image/62/e9/62b5acf80f49fe8d1a8b229df36f00e9.jpg" alt="">
+
+首先，按照业务的架构层次栈，我自底向上按照资源、通信、数据与计算的维度，梳理出了4个技术层次：分布式资源池化、分布式通信、分布式数据存储与管理、分布式计算。这样的划分符合业务架构设计的一般规律，即**“在一定资源上，进行一定通信，通过一定计算，完成一定数据的加工和处理，从而对外提供特定的服务”。**另一方面，这样的划分也整合了零散的知识点，具有完备性。
+
+既然横向的4个层次都已经完备了，那为什么又多出了4个纵向的技术呢？如果我们把横向的4个层次比作派生类的话，那么纵向的4条技术线应该是它们的基类。因为，在分布式环境下，无论是资源、通信、数据还是计算，都需要去解决协同、调度、追踪高可用，还有部署的问题。因此，我从横向的技术层次中，提炼出分布式协同、分布式调度、分布式追踪与高可用、分布式部署4个纵向技术线。由于分布式追踪、分布式部署虽属于支撑技术，但并不会影响业务的构成，因此我不会在本专栏中进行讲解。
+
+最后，如果说现在分布式领域里各种包装出来的、五花八门的新技术，像是令人高不可攀的女神、男神的话，那么这个分布式通识课程中所提炼出来的体系和核心知识点无疑就是女神、男神素颜的样子。我想说，等你**看尽素颜，无论是女神、男神也好，还是各种高大上的技术也好，也就不会觉得那么高不可攀了。**
+
+既然你已经看到了这里，相信你也看到了学习分布式技术知识的迫切需求，那么不妨请你在留言区做个自我介绍，给我说说你的困惑，也说说你想通过这个专栏收获些什么，这样我后续也可以根据你的情况进行有针对性的讲解。
+
+我是聂鹏程，今天的内容就到这里了，我们下一讲再会。
+
+