经常有很多读者问我如何规划程序员的学习和成长路径，才能早日成为架构师。作为曾经的架构师，在走上技术管理的道路后，管理团队越来越庞大。现在我管理着一个100多人的技术团队。最大的体会就是操心的事情太多，会议太多。写代码的时间越来越少。趁着自己还是技术出身，代码也没有完全忘记，我觉得是时候给大家讲讲架构师的成长之路了。接下来，我准备写一系列关于架构师和分布式系统的技术文章。今天的文章相当于复习，相当于我们Java语言学习的开始：HelloWorld，让我们从正文开始。作为一名资深架构师，一路走来，我发现自己的技术水平往往是随着项目的发展而被迫增长的。其实很多时候，自己的水平还达不到能够顺利完成架构项目的水平。但是，为了挑战，为了技术的成长，甚至为了高薪，我只能咬紧牙关，熬夜学习，终于让自己能够顺利的进行设计和把控。项目的架构。其中，最难的是设计、构建和规划一套完整的大型分布式系统。但是，也正是通过这些极其艰难的磨练，我们才不惧怕所谓的技术人员35岁大限。然而，要做到这一点，首先要做的是了解什么是分布式系统。一、什么是分布式系统网上看到的分布式系统的学术定义，简单来说就是一组计算机协同工作，让用户感觉像是一个统一的系统。但是，由于这个定义过于简洁，很多初学者会在没有感知的情况下，下意识地混淆分布式系统的概念。你是什??么意思？请问一下，我们用keepalived做高可用集群的时候，是不是在做分布式系统？当我们没有足够的并发量，有一堆机器做负载均衡的时候，我们是不是在做分布式系统？?当你默默的回答是，或者不知道是不是真的时候，你已经对分布式系统的概念感到困惑了。在这里，有必要给分布式系统划一个界限，告诉大家，它不是多台机器堆砌而成的分布式系统。刚才的两个问题，正确答案是keepalived做的高可用集群，用Nginx或者lvs后面接一堆应用集群做负载均衡。它们不是分布式系统，它们只是一个集群。同样，MySQL的主从、双主等数据库当然也不是分布式系统。因为这些集群缺少分布式系统最核心的东西：应用所在的服务器之间的相互协作，我是公司唯一的程序员，前端、后端、测试工作全部由我来做，一个月可以完成一个项目。后来项目太多，忙不过来。为了赚更多的钱，我应该怎么做？我想了两个办法，然后招了一个和我一样强的全栈工程师。完成了两个项目。我们两个组成了一个小组。招一个前端和一个测试跟我合作，前端、后端、测试分开工作。通过协作，我们可以在半个月内完成一个项目。这时候我们的关系是分布式的。从上面的例子可以看出，集群中的多台服务器都在做同一件事，不能缩短处理一件事情的时间。而分布式，就是把东西拆开，多台服务器分别工作，可以缩短时间。知道什么是分布式系统后，最简单的分布式系统应该是什么样的呢？假设我们做了一个系统，只有两个功能：1.注册，2.登录如果我们要怎么把这个系统变成分布式系统呢？最简单的方法就是把注册功能和登录功能做成两套子服务，然后分别部署在两台服务器上，让它们互相配合，就成了一套最简单的分布式系统。看到这里你可能会很震惊：这是分布式系统？分布式系统的众多技术栈我想学怎么办？那些高大上的算法呢？瞬间闪退的容错机制呢？热升级功能呢？哪里有问题？我们搭建的简单系统真的就是我们天天挂在嘴边的分布式系统吗？2.为什么需要分布式系统？为什么我们需要分布式系统？答案很简单：形势所迫！分布式系统往往是业务发展后的最终解决方案。假设公司上线了一个新的线上业务，我们需要为这个业务搭建和开发一个业务系统。往往这个时候，由于项目前景不明，需要快速上线、入市试错，这个时候，我们可能会优先搭建单体架构，先上线。随着业务的发展和运营，我们经常面临的第一个问题就是系统的崩溃和服务器的宕机。这时候大家就会搭建一个高可用的架构来解决问题。在多台机器上部署同一个项目。如果一台机器出现问题，只需切换到另一台机器提供服务。后来由于业务的进一步发展壮大，这个时候瓶颈往往是系统的响应时间。响应时间的增加直接影响用户体验，这本身就反映了吞吐量的瓶颈。对于这种问题，架构师们会想出集群的方法来解决。这个时候系统架构就开始变得复杂了，因为别忘了在保证负载均衡的同时，我们还需要保证服务的高可用。到目前为止似乎没问题。我们通过高可用性来保证系统的可靠性，通过负载均衡来分散系统的压力。但是，以上解决方案都不是分布式的，系统不是分布式系统。它仍然是像Monoliths一样笨拙的架构，被一些技术狂人嘲笑。我们还需要分布式吗？上图是某大厂支付平台架构的一小部分。从这张图就可以看出未来的业务会有多复杂。面对如此复杂的业务，我们发现之前搭建的那种集群根本站不住脚。这时候就需要拆分业务了。虽然业务已经拆分，但这些业务终究还是要对外合作，提供一个整体的服务。这个时候，就真的需要分布式系统了。我们需要一套在不同服务器上相互协作的系统。所以我们说分布式系统是业务发展之后的最终解决方案。最后，当业务复杂到分裂的时候，那么分布式系统就是自然而然的需求。在这里，我们也可以回答我们在上一节中遇到的问题。我们需要的不是简单的直接分发部署的模块无意义分布，不是简单的模块分解。我们需要的是系统在被迫分布式的情况下仍然能够：保持优秀的性能，具有极其可靠的可用性，以及优秀的弹性。为了保证以上三个指标，一个分布式系统是复杂难懂的技术栈。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方式Pipeline方式4.5分布式可靠性到目前为止，了解了这些知识后，对于一般的公司架构任务，建筑师可以轻松完成。一个完整的前向分布式学习过程的知识其实差不多。此时，我们还需要知道通用的分布式可靠性处理方案。其实一般不超过三种：大量模块的负载均衡集群；一些资源受限的模块的流量控制；当任何一个模块对应的服务器出现问题时，想办法不影响系统的正常运行，这就是故障隔离。至于上面的三种解决方案，其中有两种其实是很常见的技术。即使不搞分布式，也还是需要学习和理解的。只有第三种，故障隔离，需要深入理解。但是故障隔离并不是什么高端黑科技。我们做分布式的时候，不同的模块自然有不同的机器，机器也是集群化的，所以这个故障隔离是很自然的。但是，有些时候，我们希望在更细的粒度上进行故障隔离，例如，我们希望在线程级别或进程级别进行故障隔离。此时，我可以考虑使用线程或者容器来执行任务，然后使用一些调度策略，在线程或者进程层面自然地隔离故障。4.6分布式资源管理最后，我们要进一步研究处理更大的分布式系统。毕竟人都是追求进步的。这时候我们就需要了解分布式架构和分布式资源管理相关的知识。不过好在分布式资源管理本身的技术栈很小。对于分布式架构，有两种结构：集中式结构和非集中式结构对于分布式资源的分配或调度，一共有三种方式：单体式调度双层式调度共享状态式调度最后说一下分布式什么是分布式系统，为什么需要分布式系统，一般应该怎么学习分布式系统。看完是不是觉得有些空虚和迷茫，别着急，以后我会写更多关于分布式的文章，写的通俗易懂，让大家尽可能少花时间和成本去学习更多分布式知识。如果你不能一口吃成胖子，那么乐趣才刚刚开始。上面写的，我只是想出了一整行，但是很多东西其实是可以并行学习的。另外，关于如何学习，仁者见仁，智者见智，不喜勿喷！本文转载自微信公众号“四猪外”，可通过以下二维码关注。转载本文请联系思源外公众号。
