计算机的出现是冯诺伊曼参与美国曼哈顿计划而产生的，作为一位数学家，目的是为了更快计算原子弹数据，所以 发展到现在，很多理论基础，底层原理离不开这位被称作计算机之父的人
那么初代计算机的出现是为了计算，但是已初具形态，它包含了作为一个计算机最基本的组件（101页报告）：
cpu（执行指令，处理数据）
存储器（存储）
输入设备（扫描仪/键盘）
输出设备（屏幕/打印机）
控制器（协调前面四个组件）
为什么在了解分布式前需要了解一下计算机的发展初期？任何事物的发展都离不开需求，在分布式概念还没出现之前，我们的系统主要以单体架构决心运行，比如一个网站或者一个app，一个系统对应一个数据库，一个应用部署到单个服务器上：
这种系统的好处非常明显，就是架构简单，维护成本也低，但是缺点也显而易见，如果系统并发访问量较大，那么服务器很容易宕机，如果宕机了，那么会导致整个系统不可用，容灾低。
基于上面这种情况，俄罗斯人开发出了nginx，目的也只是解决他们网站的这种问题，那么nginx很明显的一个用处就是可以进行限流，同时也可以进行反向代理，还可以负载均衡。负载均衡即将用户最初进来的请求进行分发，我们可以对系统做集群，即将该系统部署到不同的服务器上，那么可以将用户的请求分发到不同的服务器上，但是都是同一个系统：
上图的每一个服务器部署的都是同一套系统，而负载均衡器就是nginx，数据库也是同一个，这样很明显既可以通过nginx进行限流也可以进行请求的分发，nginx还可以进行反向代理，从而达到不同用户访问不同的服务器但是感觉访问的都是同一个服务器。那么这种缺点也很明显，在一个系统中，有些业务访问量比较大，有些业务访问量较小，所以就会造成服务器资源的浪费，毕竟对于访问量小的业务，好像没必要做集群，但是因为它是一个整体，又类似做了集群，所以就出现了系统模块划分。
一个系统，可以根据不同业务进行模块的划分，对于一个系统那么就可以拆分为很多业务模块了，这就是系统垂直拆分，系统垂直拆分为不同的业务模块，但是他们好像还是在同一个项目里？很简单，将拆分出来的相关模块当成单独的项目即可，比如一个电商系统，拆分为电商交易系统（支付管理模块，商品管理模块），后台管理系统（用户管理模块，订单管理模块，物流管理模块），然后对拆分出来的系统进行部署，不同系统的访问量不一样，那么对于访问量大的就建议做集群部署，这样就保证了访问量大的就做集群，访问量不大的可以不做集群：
上图是单个系统垂直拆分为不同系统的结果，对于电商交易系统，可能访问量比较大，那么我们就可以做集群，对单个系统做集群，和前面那种总系统做集群一样（负载均衡+部署到不同服务器+数据库用同一个），这种好处也是显而易见的，就是降低了服务器的浪费，这是相比较于前面那种总系统集群部署的情况。那么缺点也是显而易见的，一个系统变成了多个系统，那么对应的管理是不是更困难了，开发人员也要变多了，需求可能根据不同的系统还要做定制化，而且很可能导致业务需求重复，可能两个系统都需要同一个业务功能，而且这种不同系统，只要使用的是不同的数据库，一个系统对应一个数据库，这种不同系统不同数据库，那么不同系统之间的数据是不可交互的，除非使用的是不同系统使用同一个数据库，通过某些定义区分不同系统（比如oracle中的模式名，对于不同系统使用同一个数据库，但是不同系统使用不同的模式名，这样不同系统之间的数据就可以互通，这也是大多数企业级开发的解决方案，oracle年费很贵）。
既然有了缺点，那么系统演化的方向便是解决这种缺点或者避免这种缺点，但是有些缺点是不太可能避免的,只能尽可能去解决。比如上面的这种业务重复的问题，还有不同系统之间数据不互通（系统和系统之间不可访问），那么怎么解决呢？分布式其实是一种思想，springcloud alibaba提供了一套分布式解决方案，配套使用起来也是非常方便。在整个市场上，个体应用的分布式思维整体上都是差不多的，只是在实现上可能选择不一样的组件去实现。那么单体应用到分布式应用大概思维是什么呢？基于上面单体垂直拆分的缺点（系统不互通，业务重复）进行：因为业务重复，所以抽取公共业务变为单独的项目；因为系统不互通，所以出现了rpc，远程过程调用，系统和系统之间可以访问。看上去好像没有改变什么，抽取公共的业务出来变成单独的系统，好像还是没改变啊，但是rpc的这种解决方案才是最大的改变，因为这种可以实现系统之间的互通，所以对于数据库层面的东西，可以基本忽视了（针对数据互通），所以这种技术的出现，我们完全可以将一个系统拆分为不同的模块，每个模块都可能变成一个单独的项目，而这些单独的项目之间可以通过rpc进行访问。
上面我们说的拆分为不同的模块单独成为项目，可以看成一个微服务，所以就导致一个系统最后拆分成很多个微服务，这些微服务代表不同的业务组合，不同的微服务之间可以通过rpc进行数据互通，所以我们从最开始的单体应用直接变成了这种多个微服务的架构，这就是单体应用架构的演化，但是我们好像就只有一个rpc，为什么市面上学一套微服务需要学习那么多组件？这就是微服务的缺点了，不管事物怎么发展，都不可能完美，思维想的可以，但是实际上到具体实施会遇到各种问题，比如：
微服务之间既然要调用，那么肯定需要知道对方存在以及需要知道对方的调用地址吧？
所以就出现了nacos,用来微服务的注册和微服务之间的发现
微服务的注册和微服务之间的发现有了，那么微服务和微服务之间怎么调用（数据互通）？
所以就出现了feign，这是基于http的，http本质是socket，而socket本质上的tcp/ip，
这就是为什么需要学好操作系统和计算机网络，很多东西其实都是底层封装之后的东西，这对
以后阅读源码具有极大帮助。
既然有了feign，那么实现了服务和服务之间的数据互通了，这相当于实现了系统之间的数据互通了，
那还需要学什么吗？我们知道，既然系统都可以进行集群部署，我们拆分出来的微服务肯定是也可以集群
部署的，同时对于有的业务也是必须要进行集群部署的，比如对于访问量较大的业务。我们知道系统集群
部署的负载均衡我们使用的是nginx，那么微服务本质上也是部署到服务器上，那么我们可以使用nginx给
微服务做负载均衡吗？当然可以，但是非常复杂，nginx是手动配置的，你某个微服务要集群，那么全要
配置，如果你后续要增加，你又要手动去增加，所以服务器你换了，你还要去nginx服务器上改，这对于
企业级开发是非常繁琐且浪费时间的一件事。
所以有了ribbon，微服务之间的负载均衡，不管你改服务器还是在集群中增删微服务，ribbon都不
需要改变什么，是不是很方便？就是很方便。
解决了微服务之间的调用负载均衡，那还有一个问题，微服务和微服务之间的调用，总有可能对面服务
挂了的情况吧，如果对面的服务挂了怎么办？
所以就有了sentinel，sentinel的出现不仅仅是用来解决对面服务挂了的问题，还有就是预防对面服
务挂了，可能是访问太多了，所以需要进行限流。 ---限流
可能服务挂了，但是别的服务一直在请求这个挂了的服务，那么怎么办？被请求的服务都挂了，请求服务
因为看不到数据，所以（人）会一直请求，一直请求，那这个请求的服务也会资源耗尽，导致服务雪崩，所以
就有了服务熔断，既然被请求微服务挂了，那我直接fallback一个默认数据给你，这就是大概解决思路。服务
熔断是针对微服务层级的。 -----服务熔断
当整个系统的请求压力很大时，这个时候我们可以关闭非核心功能，从而释放服务器资源，保证微服务核
心功能正常运行。----服务降级
这就是sentinel的作用了。
服务不可用问题解决了，那么还有什么？微服务调用是一种链路调用，比如微服务a调用了b，然后微服务
b调用了微服务c，而微服务c调用了微服务d。这样这种链路调用，可能c这个微服务挂了，那么其实b是执行成
功了，那么是保留这种成功还是说不保留，比如别人冲钱买了vip，发现钱没了，但是vip还没。这种就是充钱
业务和vip业务分别在不同的微服务中，充钱业务所在微服务是正常的，而vip业务所在微服务是挂了的，怎么怎么解决？
所以有了Seata,专门用于处理分布式事务。
当这个系统拆分成很多个微服务之后，前端请求至微服务，每个微服务请求前都需要做权限认证，这是不
是显得异常麻烦？
所以有了gateway，字面意思，网关，我们前面提到的nginx其实也是网关，那为什么还有gateway？
nginx不是解决了吗？确实解决了，但是又不得不和前面的微服务之间的负载均衡ribbon的出现重复了，手动
配置每一个微服务简直要爆了，所以自然就出现了gateway这种，虽然也要配置，但是简单得多，而且还是可
以做统一的鉴权操作以及路由转发，还可以做流量控制。
在网络术语中，api网关一般指的是gateway,即微服务网关，而应用网关一般指的是nginx，一般的企业
架构中，nginx负载均衡gateway，由gateway分发各种请求。
那么回到本文开头，什么是分布式？又为什么需要分布式？ gpt回答什么是分布式是这样回答的：
"分布式"是一个计算机科学中的概念，指的是将计算工作分布在多台计算机上进行，而不是在单一的计算机上
进行。这些计算机可以在同一个网络中，也可以分布在不同的网络中。每台计算机都有自己的内存和处理器。
是不是很容易和集群混淆？将计算工作分布到多台计算机上进行。意思就是将我们拆分得到的微服务部署到不同的计算机（服务器）上，这样就是分布式了。
全一点的概念应该是这样的：
将原本在单台计算机上工作的系统进行模块拆分，部署至不同的服务器上，这些不同服务器上的不同模块
可以进行协调处理，从而达到原先单体应用的效果。
不管架构怎么变化，最后都是用来解决需求的，最开始的单体架构可以解决，那就没必要使用分布式架构，而使用分布式架构的最终结果也是为了得到最开始单体架构的结果，结果是不会变的，只不过中间提高了系统的并发量，或者其它一些东西(运维)。
那为什么需要分布式？
这个问题的结果显而易见，当一个应用一直发展时，那这个系统一定是会变的非常臃肿的，而且我们前面说的并发量高时的问题，所以分布式架构，可以提高应用的可拓展性。
