在微服务领域，将外部依赖的 POJO 类或者 API 接口层单独打包是一种通用做法，这样就可以给外部依赖方提供一个“干净”（不包含非必要依赖）的接口包，为远程服务调用（RPC）提供支持。”

Nacos 内部支持两种一致性协议，一种是侧重一致性的 Raft 协议，基于集群中选举出来的 Leader 节点进行数据写入；另一种是针对临时节点的 Distro 协议，它是一个侧重可用性（或最终一致性）的分布式一致性协议”

Gateway 提供了三种方式来加载路由规则，分别是 Java 代码、yaml 文件和动态路由。”

关于降级熔断，我的经验是主链路服务（也就是核心业务链路的重要服务）一定要设置降级预案，防止服务雪崩在核心业务上的传播。除此之外，对于非核心链路的服务，应该设置手动降级开关，在大促等高并发场景下做主动降级，将额外的计算资源通过弹性方案匀给主链路服务。”

简单来说，链路追踪技术会为每次服务调用生成一个全局唯一的 ID（后面我们叫它 Trace ID），从本次服务调用的起点到终点，这个过程中的所有日志信息都会被打上 Trace ID 的烙印。这样一来，根据日志中的 Trace ID，我们就能很清晰地梳理出一次服务请求前后都经过了哪些微服务节点”

为了搭建一条高可用的链路信息传递通道，我将使用 RabbitMQ 作为中转站，让各个应用服务器将服务调用链信息传递给 RabbitMQ，而 Zipkin 服务器则通过监听 RabbitMQ 的队列来获取调用链数据。相比于让微服务通过 Web 接口直连 Zipkin，使用消息队列可以大幅提高信息的送达率和传递效率。”

数据库的标准范式是上一个时代的产物，以那个时代的眼光来看，“存储”是一项很宝贵的资源，在做程序设计的时候应该尽可能节省磁盘空间、内存空间，反倒“性能”和“高并发”并不是需要担心的事情。”

第二种流控效果 Warm Up 则实现了“预热模式的流控效果”，这种方式可以平缓拉高系统水位，避免突发流量对当前处于低水位的系统的可用性造成破坏”

削峰填谷其实是一种平滑利用资源的手段”

早期我们经常会使用 TTL+ 死信队列的方式来实现这种定时事件，通过设置一个正常的消息队列并使用 TTL 指定超时时间，如果队列中的消息超时了，它就会被 DLX（死信交换机）转向死信队列。借助这种曲线救国的方式，你就可以通过 MQ 组件实现“定时消息”。”