1、什么是微服务？?
将传统的单体应用，根据业务划分多个服务，每个服务互相独立，可以单独部署，而服务和服务之间又可以通过rpc、dubbo、http等互相调用
2、优缺点：
优点:
①针对频繁使用的服务可以水平扩展（添加机器）
②方便开发，避免代码版本冲突
③明确业务边界，解耦。
缺点：
①增加运维成本，单体的应用只需要维护一个机器，现在要维护很多机器。
组件nacos 注册中心
服务注册基本流程：服务方通过安装的nacos客服端发生http请求，注册到 nacos服务器上（它把收到的请求放到 BlockingQueue（阻塞）队列里，单线程异步地不断消费该队列，放到set集合里，从而实现注册），消费端从naocs服务器上拉取服务列表，消费端这时候就可以访问服务方了。如果是同一个服务有多个提供方（只有端口号不一样），这些服务方也都会注册到naocs服务器上，只是客服端拉取服务列表后，会通过ribbon进行轮询来选择哪一个服务方。如下图：
?nacos如何支持消费者和服务端的高并发的读和写的“服务列表”？
答：copyOnWriter机制。某服务方拷贝一份“服务列表”并更新后，再替换服务注册中心的“服务列表”。客服端始终读取的是 “服务注册中心”的服务列表。
通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。
如果多个服务方进行服务 会出现并发覆盖“服务列表”吗？
答：不会，因为“注册中心”只有一个线程负责消费BlockingQueue队列，相当于会一个一个更新，所以不会导致并发覆盖服务列表。
nacos客户端发送心跳、服务端收到心跳会怎么做？
?客户端维持一个定时任务，向服务端发送请求，默认间隔5s。服务端接收本次心跳的时间-上次接收心跳的时间>超时时间（默认15s），则会把服务设置为不健康的状态,如果大于剔除时间（默认30s）,就会从服务列表移除。
服务降级、熔断、限流原理
引入这些概念的原因是：因为服务雪崩。
使用组件：Sentinel、Hystrix 组件进行服务熔断和限流
服务雪崩：一个服务失败，导致整个链路服务都失败
解决手段：服务降级。（服务熔断是降级的一种）
服务降级：A服务调用B服务，因某种原因B服务无响应或者响应慢，A为了保证自己的服务整体可用，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。为了保护自己，避免宕机。
可细分为：
????????①服务熔断。调用失败次数达到一定阈值。触发熔断。
????????②开关降级。
????????③限流降级。
降级和熔断的区别：
????????降级是从整体负荷考虑，熔断是具体的某个服务触发。
????????降级一般从外围开始，熔断是某个任意服务出现意外。
? ? ? ? 降级是为了维护重要的业务，损失一些不重要的业务。
高并发下，保护系统的方法：缓存、降级、限流。
服务限流：解决方式：
① 滑动计数器，单位时间内接受过多（比如10个）请求直接拒绝访问。
②漏桶算法：固定速率从通中流出水滴。如果漏斗溢出，就拒绝访问或者服务降级。
? ? ? ? ? ? ? ? ? ? ? ? 缺点：如果瞬时流量很大，那么会溢出（丢到很多请求）。
③令牌桶算法：根据1/QPS生成恒定速率的 生成令牌速度，生成的令牌放入桶中，桶满则丢弃令牌。? 与此同时，每次来个新请求，就消掉一个token，拿到token则处理请求，没拿到token则拒绝请求。
好处：根据 QPS（每秒请求数）来提高或者降低处理请求的速度。
可使用Guava的RateLimiter进行实现
消息队列
我的理解：本质是缓冲
?优点：
解耦：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。
异步：一些非必要的业务逻辑以同步的方式运行，太耗费时间。
消峰：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
使用了消息队列会有什么缺点？
系统可用性降低，系统复杂性增加。
消息队列如何选型？
中小型软件公司，建议选RabbitMQ，因为管理界面用起来十分方便。
大型软件公司，根据具体使用在rocketMq和kafka之间二选一。
kafka多用于日志采集。
如何保证消息队列是高可用的
思想：多个集群同步信息。
1、RabbitMQ在多台服务器启动实例、每台服务器一个实例、当你创建queue时、queue（元数据+具体数据）只会落在一台RabbitMQ实例上、但是集群中每个实例都会同步queue的元数据（元数据：真实数据的描述如具体位置等）。
2、当用户消费时如果连接的是另外一个实例，当前实例会根据同步的元数据找到具体的数据所在的实例从其上把具体数据拉过来消费。
这种方式的缺点很明显，没有做到所谓的分布式、只是一个普通的集群。这种方式在消费数据时要么随机选择一个实例拉去数据、要么固定连接那个queue所在的实例来拉取数据，前者导致一次实例见拉取数据的开销、而后在会导致单实例性能的瓶颈。
镜像模式：
不管是元数据还是里面的具体消息都会存在于所有的实例上。每次写消息时都会把消息同步到每个节点的queue中去。
这种方式的优点在于，你任何一个节点宕机了、都没事儿，别的节点都还可以正常使用。
缺点：开销大。
文章参考：https://segmentfault.com/a/1190000023008259
如何保证消息不被重复消费？（如何保证消息队列的幂等性？）
?正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。
那造成重复消费的原因？，就是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。
如何解决？这个问题针对业务场景来答，分以下三种情况：
（1）比如，你拿到这个消息做数据库的insert操作，那就容易了，给这个消息做一个唯一的主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
（2）再比如，消费者拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
（3）如果上面两种情况还不行，上大招。搞个全局变量，来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis.那消费者开始消费前，先去redis中查询有没有消费记录即可。
如何保证消费的可靠性传输？
其实这个可靠性传输，每种MQ都要从三个角度来分析：
- 生产者弄丢数据。解决方法：transaction机制，开启事务，失败就回滚。
- 消息队列弄丢数据。解决方法：一般是开启持久化磁盘的配置，先保存，再发送。
- 消费者弄丢数据。解决方法：自动确认改手动确认消息
如何保证消息的顺序性?
针对这个问题，通过某种算法，将需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一个消费者去消费该队列。
缺点：降低了吞吐量。