作为一个资深架构师，一路走来，发现自己的技术水平很多时候其实是随着项目的发展被迫成长的。其实，很多时候，自身水平达不到能顺利完成架构项目的水平，但是，为了挑战，为了技术成长，更是为了高薪资，只能咬牙坚持，熬夜学习，最终让自己能顺利设计和把控项目的架构。
其中，最为艰难的，就是去设计、架构、规划一整套，规模大的分布式系统。但是，正是经历了这些异常艰难的磨炼，我们才能毫不恐惧所谓的技术人员35岁大限。
但是，要做到这些，首要做的是能明白分布式系统到底是个什么东西。
1.什么是分布式系统
分布式系统大家从网络上看到的学术定义简单来说就是一套由一组计算机协同工作，让用户感觉像是一个统一的整体的系统。
但是，由于这个定义定的过于简练，很多初入门的人会毫无感知的潜意识就会混淆了分布式系统的概念。
什么意思？我这里问下，当我们用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分布式存储
当理解了分布式协调和同步之后，我们就应该
转载请注明：http://www.0431gb208.com/sjslczl/1947.html
