1.目前主流的微服务
(1)dubbo
高性能，轻量级的Java微服务架构，最初由Alibaba开发且2011年开源。底层是使用RPC的通信模型，具有较高性能和可扩展性，支持多种传输协议，可以按需进行配置。
- dubbo的基础逻辑：
1.消费者会缓存所调用服务的生产者，每个生产者内部都会有一个属性(active)进行标记，初始值为0
2.消费者调用服务时，如果处于负载均衡则使用leastactive策略(返回比较快的主机或者本机调用较少的主机)，延伸：dubbo通过spi默认实现了4种ib策略：random(权重随机-实现类RandomLoadBalance)，roundrobin(权重轮询-实现类RoundRobinLoadBalance)，leastactive(最少活跃负载策略-实现类LeastActiveLoadBalance)，consistenthash(一致性-实现类ConsistentHashLoadBalance)，dubbo负载均衡默认是随机的
3.消费者会排队缓存的所有生产者提供的active，选择最小的，如果都是相同，则随机
4.选择某一个生产者后，dubbo就会对改生产者中的active+1
5.然后真正发出请求调用该服务
6.消费者收到响应结果后对该生产者的active-1，就完成了对生产者当前活跃调用数进行了统计，且不会影响服务调用的性能。
- 服务超时
在生产者和消费者都可以配置服务超时时间，2者有什么区别？
(1)消费者调用服务的流程：发送请求，服务端执行服务，服务器端返回响应，如果在服务端和消费端其中只有一方配置了timeout,那么没有问题，表示消费端调用服务的超时时间，消费端如果超时时间还没有收到响应结果，则消费端会抛出超时异常，但服务端不会抛出异常，服务端在执行服务后，会检查执行该服务的时间，如果超过timeout,则会打印一个超时日志，服务会正常的执行完。 看到这里就会想着那我2边都配置，那不挺好的吗，举例：
此时会发生什么？
结果 ：数据不一致 。
消费者认为"没成功"，所以可能发起重试，导致重复插入；或者认为"失败"而跳过后续流程，但数据库里其实已经有了这条数据。服务端这边则白白执行了完整的业务逻辑，造成了资源浪费（线程、CPU、数据库连接）。
- 超时嵌套导致的"超时雪崩"效应
如果两边都配置超时，且消费者超时时间 < 服务端超时时间（如上例），就会导致大量请求在消费者侧快速失败，但服务端侧线程池依然被占满（因为服务端还在傻傻地执行未完成的请求）。
后果 ：
服务端线程池因为处理这些"消费者已放弃但服务端还在算"的请求而被耗尽。新来的正常请求进不来，导致服务端整体不可用。
- 超时传递与优先级混乱
在很多 RPC 框架（如 Dubbo、Spring Cloud 等）中，消费者端的超时配置通常优先级高于服务端配置。
如果两边都配置了：
总结：两者的职责定位
| 维度 | 消费者超时 | 生产者（服务端）超时 |
|---|---|---|
| 主要目的 | 用户体验、快速失败、防止调用方被拖死 | 自我保护，防止个别慢请求占满工作线程 |
| 触发后果 | 抛出异常，客户端断开连接，可能触发重试 | 中断执行线程（通常靠Future.cancel()或InterruptedException），打印日志，释放资源 |
| 最佳实践 | 根据业务SLA设置，通常较短 | 设置得比消费者超时略长，作为兜底 |
建议
如果要两边都配置，请遵循 "消费者超时 < 服务端超时" 的原则，并且服务端要做好超时中断逻辑的检测。
但在实际生产环境中，更好的做法是：
只配置消费者超时，服务端不配置超时，转而配置"限流"和"隔离" 。
因为一旦服务端超时被触发，往往意味着服务端已经处于过载状态，此时通过线程池隔离和限流来拒绝新请求，比让服务端在超时中断中消耗资源去捕获中断异常要更可控。
如果消费者配置了 1 秒，服务端配置了 10 秒，实际生效的"有效超时"是 1 秒（因为消费者等不到 10 秒就会断连）。服务端那 10 秒的配置在大多数正常情况下形同虚设，反而会在消费者断连后，成为拖垮服务端自身资源的元凶。
说怎么多其实就是超时的起点与计算逻辑不同
-
消费者超时：3秒
-
服务端超时：5秒
-
实际业务耗时：4秒
-
流程推演：
-
0s：消费者发起请求，消费者计时器启动，服务端计时器启动。
-
3s ：消费者等待了3秒，没收到响应。消费者判定超时，抛出超时异常，消费者线程释放，连接断开（或标记为失效）。
-
4s：服务端终于执行完业务（耗时4秒，小于服务端5秒的超时阈值）。
-
4s+ ：服务端准备将结果写回消费者。但它发现连接已经断了（或者消费者已经不在了）。
-
对于服务端 ：它发现自己"成功执行完了业务，但客户端断连了"。服务端通常会打印一个" Broken pipe"或"Connection reset"的异常日志 ，但业务逻辑已经提交（例如：数据库已经 insert 成功了）。
-
对于消费者 ：因为它在3秒时就抛出了超时异常，它会认为调用失败了。它会执行降级逻辑、重试逻辑，或者直接告诉上游"操作失败"。
-
服务端超时 ：更多是作为一种兜底保护（防止恶意慢 SQL 或死循环拖垮整个 JVM）。
-
消费者超时 ：是业务承诺（告诉上游，我最多多久给你答复）。
消费者超时 ：通常是从发出请求的瞬间 开始计时，到收到完整响应结束。它涵盖的是整个网络往返时间 + 服务端处理时间。
生产者（服务端）超时 ：通常是从收到请求开始 计时，到处理完业务逻辑准备发送响应结束。它只涵盖服务端内部的执行时间。
区别在于：如果网络延迟很大，消费者可能因为网络拥堵而超时，但服务端可能才刚刚收到请求，其内部超时计时器才刚刚开始，远未触发。
集群容错：
(2)Spring cloud Netfilx
是spring cloud的子项目，结合了Netflix开源的多个组件(Eureka-服务注册与发现，Ribbon-客户端负载均衡，Hystrix-断路器，Zuul-API网关)。
(3)Spring cloud Alibaba:
另外一个是spring cloud的子项目，一整套与Alibaba生态系统集成的解决方案
2.微服务下面有哪些组件
(1)注册中心：用于服务的注册与发现，管理微服务的地址信息。
- Eureka(Spring cloud Netfilx)
- Consul(Spring cloud Netfilx)
- Nacos(Spring cloud Alibaba)
(2)API网关：统一暴露服务入口，提供路由，负载均衡，安全认证等功能
- Zuul(Spring cloud Netfilx)
- Gateway(Spring cloud Alibaba)
- Apisix(Spring cloud Alibaba)
(3)配置中心：集中管理微服务的配置信息，可以动态配置不需要重启服务
- spring cloud Config(Spring cloud Netfilx)
- Nacos Config (Spring cloud Alibaba)
(4)远程调用: 不同的微服务之间通信和协作
- RESTful API: Fegin,RestTemplate
- RPC(远程过程调用)：Dubbo，gRPC
(5)熔断器: 防止微服务之间的故障扩散，提高系统的容错能力
- Hystrix(Spring cloud Netfilx)
- Sentinel (Spring cloud Alibaba)
- Resilience4j (Spring cloud Alibaba)
(6)限流和降级：防止微服务过载，对请求进行限制和降级处理
- Hystrix(Spring cloud Netfilx)
- Sentinel (Spring cloud Alibaba)
(7)负载均衡：
- Ribbon
(8)链路追踪：用于跟踪和监控微服务的请求流程和性能指标
- Zipkin+spring Cloud Sleuth(Spring cloud Netfilx)
- SkyWallking(Spring cloud Alibaba)
- Sentinel Dashboard(Spring cloud Alibaba)
(9)分布式事务：保证跨多个微服务调用的事务一致性。
- Seata(Spring cloud Alibaba)