分布式使用场景
集群部署：把我们同样的一个单体应用部署到很多服务器上去，最后在前面加一个负载均衡。
不让厨师做所有的事情，而是根据领域雇佣相对应的人(专业人做专业的事)。
将一个大的服务进行拆分成多个功能，不同的功能只负责自己的事情。未来我们在需要多个商品目录系统的时候，只需要多加几个商品目录的模块，更加不需要将整套服务来进行部署，此时我们完成了将单体应用变为集群升级成了分布式架构！
实际项目：
一开始时候往往不会直接进行分布式，而是一个大而全的项目；
之后业务发展了我们将项目部署到多台服务器上，也就是建立集群通过负载均衡来进行浏览量控制；但是到后期其效率并不高，例如请假系统或者其他系统用的不是很多，建立集群相当于将整个系统复制了多份，对应其请假系统也同样会被复制；
对于此时我们可以将其升级为分布式的，权限只管权限，员工只管员工，请假只管请假，此时这种情况，各个服务之间都是相互独立的，并且对应接口是进行相互调用的。此时就可以只有一个请假系统，多个员工系统，根据自己的实际需要来进行分布式拆分。
分布式作用
实际工作痛点：工程臃肿、 测试上线繁琐、开发效率低。
单体应用问题：①应用代码耦合严重，功能扩展难。②新需求开发交互周期长，测试工作量大。③升级维护困难，改动任何一点地方就要升级整个系统。④系统性能提升艰难，可用性低，不稳定。
分布式好处：①增大系统容量。②加强系统可用。③模块化后，系统模块重用度更高。④软件服务模块被拆分，开发和发布速度可以并行变得更快。⑤系统扩展性更高。⑥团队协作流程将会得到改善。⑦技术升级
CAP定理
CAP重要性：分布式中最基础最关键的理论
CAP理论：分区容错、一致性、可用性
C(Consistency,一致性)：读操作是否总能读到前一个写操作的结果。 A(Avaliability,可用性)：非故障节点应该在合理的时间内作出合理的响应。 P(Partition tolerance，分区容错性)：当出现网络分区现象后，系统能够继续运行。
CAP如何选择？
CAP理论中不存在CAP三个内容重叠的情况，不可兼得，一般都是两个重叠CA、CP、AP 场合： 1、可用性高于一致性(AP)：也就是选择AP而不是CP，有一个网站，有一个cdn，cdn就是指为了给网页加快速度去发布到特别多的集群上去，如你在杭州看到的是一个杭州节点的页面，在其他地域看到的是另一个域的页面，有更新的话会慢慢进行同步，但是这个同步是需要有时间的并不是立即会同步的，对于网页的更新并不是那么注重一致性，但是也会慢慢的会对一致性进行保证。归根结底就是说无论如何一定要能够看得到网页。若是你选择一致性而不是可用性，那么在同步期间就看不到东西，往往来讲看到更重要，是不是最新的往往不是最关键。 2、一致性高于可用性(CP)：支付场合，支付与交易，我可以允许暂时不可用，但是不能不一致，若是不一致会造成很大的问题如转账。宁可说服务不可用指定时间内访问不了，也不会说舍弃我们的一致性。
集群、分布式、微服务的区别
集群与分布式区别： 分布式：一个业务分拆分多个子业务，部署在不同的服务器上 集群：同一个业务，部署在多个服务器上 集群与微服务区别： 集群：分散压力 微服务：分散能力 微服务与分布式区别(一般先做逻辑架构，接着做物理架构) 微服务：架构设计方式，将一个大的服务拆成一(个个小的服务，每个服务对应一个功能只做一件事，能够独立部署，服务之间能够通过通信来进行调用，每个服务能够进行独立开发进行测试。（逻辑角度来对项目进行拆分） 分布式：主要强调的是一种部署的方式。(部署的角度，主要考虑机器与机器之间他们会遇到哪些通信上的问题，时间上的不一致，调用顺序，容错，考虑的实际部署之后机器之间的物理的架构)
