CAP定理
分布式系统无法同时满足一致性C，可用性A，分区容错性P
CP：宁愿暂停服务，也不能让大家看到不一样的数据。代表：Zookeeper
AP：先保持系统一直能用，数据晚点再对齐也行。代表：Nacos、Eureka
什么是配置中心
配置中心是一个用于集中化管理配置，并支持配置动态更新和发布的工具或服务，当配置发生变化时自动通知各个服务实例进行更新，并且无需重启即可生效。
为什么需要配置中心
在微服务架构中，服务数量多且配置分散，手动维护成本高，易出错。配置中心解决了配置分散的问题，实现了统一管理，动态更新。多环境隔离等。
为什么需要服务注册与发现
在分布式系统中，服务数量庞大而且频繁变化，通过注册中心自动维护服务的上下线信息，避免人工管理IP和端口带来的高成本和错误风险，解决了微服务框架下服务实例动态变化时服务之间难以追踪和调用的问题，实现了服务的位置的自动查找，负载均衡以及自动化管理
注册和发现过程是怎样的？
注册 ：服务启动时把自己的元信息(服务号，IP地址，端口号，健康状态等)注册到注册中心，注册中心保存这些信息并用于后续服务发现
发现：服务消费者向注册中心查询所需服务的实例列表，注册中心返回可用的服务实例信息，消费者根据负载均衡策略选择一个实例进行调用
服务注册与发现如何支持弹性扩缩容？
新增服务实例时自动注册到注册中心，流量可立即分配；下线时注册中心检测到并剔除，流量不再转发，从而实现无需人工干预的动态扩缩容。
Nacos的提升
Nacos = Eureka 注册中心 + Spring Cloud Config 配置中心
对比Eureka ：即是注册中心又是配置中心，基于长连接推送，服务上下线秒级感知(Eurka感知很慢)，支持Tcp/HTTP/MySQL多种健康探测(Eureka基本只靠心跳)，并且有可视化后台，持久化，历史版本，一键回滚，多人编辑
对比Zookeeper：AP最终一致更适合微服务，单机就能开发用，集群部署简单，功能更多：Nacos多环境，命名空间，配置监听，动态刷新等
微服务项目怎么接入 Nacos 的？
- 引入 Nacos 服务发现、配置中心依赖
- 配置文件配置 Nacos 服务地址
- 启动类加
@EnableDiscoveryClient开启服务注册发现 - 业务代码完全不用改，框架自动完成注册、配置拉取
什么是服务熔断，降级，限流
熔断 ：触发：下游服务故障；目的：防止故障(订单服务调库存服务，库存挂了就熔断)
降级 ：触发：系统压力过大；目的：保核心功能(大促时关闭商品评价功能，保下单链路)
限流：触发：请求量超出系统承载能力;目的：防宕机(QPS限制到一万，超过直接拒绝)
Gateway 网关作用
统一入口，路由转发、请求拦截、跨域处理、限流、鉴权；
所有前端请求先进网关，再转发到对应微服务，对外隐藏服务地址