张维鹏的博客

随着系统的复杂度也越来越高，我们软件架构也进入了分布式阶段，一次请求可能横跨多个服务模块、项目，依赖的中间件也越来越多，其中任何一个节点出现异常，都可能导致业务出现波动或者异常。而传统的日志监控等方式无法很好满足调用链路跟踪，排查问题等需求，这就导致定位/诊断服务异常变得异常复杂。因此面对复杂的调用链路，我们需要一款具体如下功能全链路追踪工具，提高我们对业务的掌控度：①请求链路追踪，快速定位故障；②可视化链路各阶段的耗时，进行性能分析；③ 梳理服务依赖关系；④ 系统指标监控，吞吐量、响应时间及错误记录等

在微服务架构中，网关层可以屏蔽外部服务直接对内部服务进行调用，对内部服务起到隔离保护的作用，网关限流，顾名思义，就是通过网关层对服务进行限流，从而达到保护后端服务的作用。如果已经在网关层面做了限流，那么躲在身后的服务是否就安全了呢？答案是否定的，因此最常见的解决方案是：网关层集群限流+内部服务的单机限流兜底，这样才能保证不被流量冲垮

网关作为系统的唯一流量入口，封装内部系统的架构，所有请求都先经过网关，由网关将请求路由到合适的微服务，所以，使用网关的好处在于：（1）简化客户端的工作。网关将微服务封装起来后，客户端只需同网关交互，而不必调用各个不同服务；（2）降低函数间的耦合度。 一旦服务接口修改，只需修改网关的路由策略，不必修改每个调用该函数的客户端，从而减少了程序间的耦合性（3）解放开发人员把精力专注于业务逻辑的实现。由网关统一实现服务路由(灰度与ABTest)、负载均衡、访问控制、流控熔断降级等非业务相关功能

openFeign 作为微服务架构下服务间调用的解决方案，是一种声明式、模板化的 HTTP 的模板，使 HTTP 请求就像调用本地方法一样，通过 openFeign 可以替代基于 RestTemplate 的远程服务调用，并且默认集成了 Ribbon 进行负载均衡。目标是减少 HTTP API 的复杂性，希望能将 HTTP 远程服务调用做到像 RPC 一样易用。

配置中心区别于传统的配置信息分散到系统各个角落的方式，对系统中的配置文件进行集中统一管理，而不需要逐一对单个的服务器进行管理。通过配置中心，可以使得配置标准化、格式统一化；当配置信息发生变动时，修改实时生效，无需要重新重启服务器，就能够自动感知相应的变化，并将新的变化统一发送到相应程序上，快速响应变化；通过审计功能还可以追溯问题

LoadBalancerClient 在初始化时会通过 Eureka Client 向 Eureka 服务端获取所有服务实例的注册信息并缓存在本地，并且每10秒向 EurekaClient 发送 “ping”，来判断服务的可用性。如果服务的可用性发生了改变或者服务数量和之前的不一致，则更新或者重新拉取。最后，在得到服务注册列表信息后，ILoadBalancer 根据 IRule 的策略进行负载均衡（默认策略为轮询）。

注册中心是微服务架构中的纽带，类似于”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址并进行调用。注册中心本质上是为了解耦服务提供者和服务消费者，除此之外还能对服务进行动态管理，降低服务端负载均衡中间件的压力

当系统中微服务数量越来越多时，如果任由这些服务散落在各处，那么最终管理每个项目的接口文档将是一件十分麻烦的事情，单是记住所有微服务的接口文档访问地址就是一件苦差事了。当如果能够将所有微服务项目的接口文档都统一汇总在同一个可视化页面，那么将大大减少我们的接口文档管理维护工作，为此，我们可以基于 Spring Cloud Gateway 网关 + nacos + knife4j 对所有微服务项目的接口文档进行聚合，从而实现我们想要的文档管理功能

在Elasticsearch 的运行过程中，如何合理分配与设置内存是一件十分重要的事情，否则十分容易出现各种问题。一、Elasticsearch为什么吃内存：我们先看下 ES 服务器的总体内存消耗情况：对于Query Cache、Request Cache、FieldData Cache 以及 Segment 的介绍，在前面的文章以及介绍过了，这里就不重复介绍了：Elasticsearch搜索引擎之缓存：Request Cache、Query Cache、Fiel...

（1）ES 客户端选择一个节点 node 发送请求过去，这个节点就是协调节点 coordinating node（2）协调节点对 document 进行路由，通过 hash 算法计算出数据应该落在哪个分片shard 上，然后根据节点上维护的 shard 信息，将请求转发到对应的实际处理节点node上（3）实际的节点上的primary shard 主分片处理请求，然后将数据同步到副本节点（4）coordinating node 等到primary node 和所有 replica node 都执

Sentinel 是一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来保障服务的稳定性，核心思想是：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略，

Sentinel 规则默认是存储在内存中的，只要服务重启之后对应的规则也会消失，实际的生产中肯定是不允许这种操作，因此 Sentinel 官方推荐在生产架构中使用第三方数据源作为永久存储中心，比如 nacos、apollo、zookeeper。因为这几种数据源都是基于 push 模式，也就是由规则中心统一推送，Sentinel Client 只需通过注册监听器的方式时刻监听变化，并负责获取配置中心推送的配置并更新到本地，这种方式能更好的保证实时性和一致性，并且各个微服务的限流、降级规则都可以永久存储。

基于MQ的分布式事务方案，本质上是对本地消息表的一个封装，整体流程与本地消息表一致，唯一不同的就是将本地消息表存在了MQ内部，而不是业务数据库，事务消息解决的是生产端的消息发送与本地事务执行的原子性问题，确保 MQ 生产端正确无误地将消息发送出来，没有多发，也不会漏发，至于发送后消费端有没有正常的消费消息，这种异常场景将由 MQ 消息消费失败重试机制来保证。

在传统的数据 IO 模式中，读取一个磁盘文件，并发送到远程端的服务，就共有四次用户空间与内核空间的上下文切换，四次数据复制，分别是两次 CPU 数据复制，两次 DMA 数据复制。零拷贝指在进行数据 IO 或传输时，数据在用户态下经历了零次拷贝，并非不拷贝数据。通过减少数据传输过程中 内核缓冲区和用户进程缓冲区间不必要的 CPU数据拷贝 与 用户态和内核态的上下文切换次数，降低 CPU 在这两方面的开销，释放 CPU 执行其他任务，更有效的利用系统资源，提高传输效率，同时还减少了内存的占用，提升应用程序的性能

对于线程的停止，通常情况下我们是不会去手动去停止的，而是等待线程自然运行至结束，但在实际开发中，很多情况中需要我们提前去手动来停止线程，比如程序中出现异常错误、使用者关闭程序等情况中。如果不能很好地停止线程那么可能会导致各种问题，所以正确的停止线程是非常的重要的，常见的中断线程的方式有以下几种：① 方式一：使用 Thread 类的 stop() 方法来终止线程；② 方式二：根据 volatile 修饰的标志位判断线程是否需要中断；③ 方式三：通过 interrupt中断机制终止线程；

日常开发中，我们常见的服务器问题主要可以归类为一下几种：CPU过载问题、内存过高问题、磁盘IO问题、网络问题。当服务器出现问题时，我们一般可以按照以下思路进行定位：① 如果最近有版本发布，则先从代码提交记录中分析最新版本代码是否存在问题；② 使用 ps、top等命令分析线程状态；③ 先将出现异常的服务器下线并保留服务器环境，接着使用 jstack 导出线程快照信息以及使用 jmap 导出堆栈内存日志进行分析，该命令会会线上服务器性能造成影响，所以执行前先下线服务器防止对用户造成影响

那什么需要对 Sentinel 进行改造呢？主要是因为所有规则都只能通过 Nacos 或 Apollo 控制台来完成修改才能得到持久化存储，而在 Sentinel Dashboard 中修改限流规则虽然可以生效，但是不会被持久化到配置中心。生产环境下推荐采用 push 模式的数据源，push 推送的操作应该由 Sentinel dashboard 和 Config Center Dashboard 控制台统一进行管理和推送，Sentinel Client 仅负责获取配置中心推送的配置并更新到本地。

Reactor 模式也叫做反应器设计模式，是一种为处理服务请求并发提交到一个或者多个服务处理器的事件设计模式。当请求抵达后，通过服务处理器将这些请求采用多路分离的方式分发给相应的请求处理器。Reactor 模式主要由 Reactor 和处理器 Handler 这两个核心部分组成，它俩负责的事情如下：① Reactor：负责监听和分发事件，事件类型包含连接事件、读写事件；② Handler ：负责处理事件，如 read -> 业务逻辑 （decode + compute + encode）-> send

本文主要介绍下 RocketMQ-docker 镜像的制作与部署，方便在不同环境快速启动RocketMQ，核心操作分为三个：NameServer 镜像的制作与部署、Broker 镜像的制作与部署、console 镜像的制作与部署。

两个服务之间要传输一个数据对象，就需要将对象转换成二进制流，通过网络传输到对方服务，再转换成对象，供服务方法调用。这个编码和解码的过程称之为序列化和反序列化。所以序列化就是把 Java 对象变成二进制形式，本质上就是一个byte[]数组。将对象序列化之后，就可以写入磁盘进行保存或者通过网络中输出给远程服务了。反之，反序列化可以从网络或者磁盘中读取的字节数组，反序列化成对象，在程序中使用。