什么是分布式和微服务？类似点和不同点？
咱们之前写的代码和我的项目都是单体架构：就是将业务的所有性能集中在一个我的项目中开发，打成一个包部署。单体我的项目的构造很简略，而且部署成本低，然而代码都纠缠在一起，所以耦合度很高。
那分布式的特点就是将代码以业务的不同进行拆分成不同的模块，扩散部署在不同的机器上的，一个服务可能负责几个性能。然而总的数据可可能还是同一个数据库，当用户应用的时候，会去调用不同的模块执行工作，不同的模块之间通信须要网络。分布式的长处是升高服务耦合，有利于服务降级和拓展，毛病就是服务调用关系盘根错节
微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互，是一种通过良好架构设计的分布式架构。简略来说微服务就是很小的服务，小到一个服务只对应一个繁多的性能，只做一件事。这个服务能够独自部署运行，服务之间能够通过 RPC 来互相交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。咱们能够应用 SpringCloud 去构建微服务架构。
微服务的长处有：
繁多职责：微服务拆分粒度更小，每一个服务都对应惟一的业务能力，做到繁多职责
服务自治：团队独立、技术独立、数据独立，独立部署和交付
面向服务：服务提供统一标准的接口，与语言和技术无关
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
分布式和微服务的概念比拟类似，分布式属于微服务。然而分布式和微服务在架构、作用和粒度上有所区别。因而，两者的关系是既互相分割又互相区别。
nacous 和 eureka 的区别？
首先是共同点：
首先都反对服务注册和服务拉取：就是说应用 nacous 和 eureka 都能够将我的项目的代码放到注册核心，而后当一个模块须要应用另一个模块的性能时，须要进行导入依赖，配置文件，而后增加 @LoadBalanced 注解进行负载平衡。
再引申一下负载平衡。SpringCloud 底层是利用了 Ribbon 的组件来实现负载平衡性能的。当咱们输出的是服务器的名字的并运行的时候，LoadBalancerIntercepor 这个拦截器会进行拦挡，拦挡后再通过 LoadBalancerClient 的 getLoadBalancer 办法依据服务 id 获取 ILoadBalancer，而 ILoadBalancer 会拿着服务 id 去 eureka 或者 nacos 中获取服务列表并保存起来。在接下来还有一个 getServer 办法，它会利用内置的负载平衡算法，从服务列表中抉择一个。那此时咱们的申请就走到了服务提供者的某一个服务器上了。负载平衡能够使得申请更均匀，不会大量的呈现在某一台服务器上，减缓了服务器的压力。负载平衡的策略有很多，默认的是轮询策略。
都反对服务提供者心跳形式做衰弱检测：衰弱检测是指一个服务定时的向注册核心报告本人的状态，阐明本人还在运行，如果没有发送状态，那注册核心就会认为这个服务除了问题，就会间接将他剔除。
Nacos 与 Eureka 的区别
Nacos 反对服务端被动检测提供者状态：长期实例采纳心跳模式，非长期实例采纳被动检测模式。长期实例心跳不失常会被剔除，非长期实例则不会被剔除
Nacos 反对服务列表变更的音讯推送模式，服务列表更新更及时
Nacos 反对 ap 和 cp 两种形式；Eureka 则只反对 ap
咱们要理解这个区别，首先要先理解什么是 cp 和 ap。
CAP 分为了：C：Consistency（一致性），A：Availability（可用性），P：Partition tolerance（分区容错）
CAP 准则又称 CAP 定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），然而 CAP 准则批示 3 个因素最多只能同时实现两点，不可能三者兼顾，因为网络硬件必定会呈现提早丢包等问题，然而在分布式系统中，咱们必须保障局部网络通信问题不会导致整个服务器集群瘫痪，另外即便分成了多个区，当网络故障打消的时候，咱们仍然能够保证数据一致性，所以咱们必须保障分区容错性；
而对于一致性和可用性，咱们须要二选一，假如咱们抉择一致性，那咱们就不能让用户拜访无奈进行数据同步的机器，因为该机器上的数据和其余失常机器上的不统一，这样咱们就抛弃了可用性；假如咱们抉择可用性，那咱们就能够让用户拜访无奈进行数据同步的服务器，尽管保障了可用性，然而咱们无奈保证数据一致性。
AP：当两个服务之间的通信因为网络起因或其余起因呈现稳定后，会分为两个区，此时的数据通信是不同步的，可能一个会新一点，一个会老一点。为了保证系统的可用性，此时当服务被调用的时候也能够调的通，然而数据并不是最新的，也就是失去了 C 一致性的属性。Eureka 就是一个 AP 架构的例子，当 Eureka 客户端心跳隐没的时候，那 Eureka 服务端就会启动自我爱护机制，不会剔除该 EurekaClient 客户端的服务，仍然能够提供需要；
CP：当网络分区呈现后，为了保障一致性，就必须拒绝请求，否则无奈保障一致性。
CP 构造抉择的是一致性和分区容错性，如果抉择一致性 C(Consistency)，为了保障数据库的一致性，咱们必须期待失去分割的服务恢复过来，在这个过程中，那个服务是不容许对外提供的，这时候零碎处于不可用状态 (失去了 A 属性)。