1.微服务架构优缺点
1）单体应用
开发的效率比较低，由于代码量大，项目启动缓慢，部署麻烦，后期难以维护。
2）服务拆分
分为多个小应用，提高了开发效率，降低了代码的耦合程度，不同的服务可以采用不同的语言，提高了灵活性；小的改动进行快捷部署，方便维护。
3）拆分的依据
原则就是高内聚低耦合，每个服务实现单一的功能，如订单服务，商品服务。
2.Spring Cloud Netflix和Spring Cloud Alibaba包括哪些组件，作用是什么？
| Spring Cloud Netflix | 组件名称 | 组件作用 |
| Eureka | 服务注册，已停止维护 | |
| Consul | 服务注册 | |
| OpenFiegn | 服务发现(Ribbon) | |
| Config | 服务配置 | |
| Hystrix | 服务熔断与降级 | |
| Zuul | 服务网关 | |
| GateWay | 服务网关 | |
| Spring Cloud Alibaba | nacos | 服务注册 |
| nacos | 服务配置 | |
| Sentinel | 服务熔断与降级 | |
| Seata | 分布式事务 |
3.Nacos是CP还是AP?
nacos默认是AP，也可支持CP。CAP定义
4.Ribbon服务调用的原理？
Ribbon主要功能是服务调用和负载均衡，那么对于服务调用是如何实现的？在代码中使用的是RestTemplate，需要调用时指定请求路径和参数，其中请求路径中包含服务名。实际上在底层，它有一个拦截器，在发送请求时，会把url中的域名（也就是服务名）取出来，根据服务名在注册中心查找相应的实例列表，包括ip和端口信息，将这些数据缓存到本地，然后使用负载均衡的策略去调用服务，默认是轮询。
5.nacos注册中心原理
当服务启动时需要去注册服务时，就把自己的信息注册到注册中心，包括服务名，ip，端口等信息。
当其他服务需要调用服务时(默认自己已注册)，会根据服务名在注册中心查询实例列表，并将此列表缓存到本地，然后通过ribbon进行服务的调用。
在注册和发现的过程中，nacos有心跳检测机制，nacos客户端（自己的应用）通过不断的向注册中心发送心跳，注册中心根据心跳情况来判断服务是否正常，当服务下线后，注册中心会把注册表中的这个实例删除，同时也会即使通知客户端。客户端也会定时根据服务名向注册中心拉取最新的实例列表到本地并覆盖本地缓存（底层是ribbon实现）。也就是说对于服务的感知是动态的，也是双向的。
但对于nacos，不同版本其底层实现原理是不一样的，主要区别在于1.4.x和2.x：
1.4.x
服务端是一个基于SpringBoot开发的web应用，提供了许多htpp接口。当系统启动需要去注册服务时，其内部就是去调用内部的接口。
2.x
优化了请求的方式，将http协议换为高性能的grpc远程调用，也就是说客户端和服务端会保持长连接。