镜像的传统构建

我们随便找个Golang代码项目作为案例，来开始构建一个镜像。下面我们以我的一个实战项目开始讲解：https://gitee.com/damon_one/uranus。

第一步：我们把项目代码克隆到本地：

1

git clone https://gitee.com/damon_one/uranus

第二步，书写其编译的Dockerfile：

1
2
3
4
5

FROM golang:1.20
WORKDIR /opt/app
COPY . .
go build -o hz-zeus ./zeus
CMD ["/opt/app/hz-zeus"]

这个 Dockerfile 描述的构建过程非常简单，我们首选 Golang:1.20 版本的镜像作为编译环境，将源码拷贝到镜像中，然后运行 go build 编译源码生成二进制可执行文件，最后配置启动命令。

第三步，构建镜像：

1

docker build -t hz-zeus -f Dockerfile .

这样编译构建的镜像会很大，这里就不展示最后的镜像信息了。

Dockerfile 优化

从上面的 Dockerfile 可以看出，我们在容器内运行了 go build -o hz-zeus ./zeus，这条命令将会编译生成二进制的可执行文件，由于编译的过程中需要 Golang 编译工具的支持，所以我们必须要使用 Golang 镜像作为基础镜像，这是导致镜像体积过大的直接原因。

既然依赖基础镜像比较大，那么我们是否可以替换为轻量级的镜像呢？发现可以将 Golang:1.20 基础镜像替换为 golang:1.20-alpine 版本。

但，这样的构建之后，发现镜像还是很大。毕竟是在镜像内镜像编译二进制文件后构建镜像。那是否可以在外部进行构建后再同步到镜像内部呢？

1
2
3

$ CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o hz-zeus ./zeus
$ ls -lh
...

最简单的办法就是在本地先编译出可执行文件，再将它复制到一个更小体积的 ubuntu 镜像内。具体做法是，首先在本地使用交叉编译生成 Linux 平台的二进制可执行文件。接下来，使用 Dockerfile 文件构建镜像。

1
2
3
4
5

FROM ubuntu:latest
WORKDIR /opt/app
COPY hz-zeus ./

CMD ["/opt/app/hz-zeus"]

因为不再需要在容器里进行编译，所以我们直接引入了不包含 Golang 编译工具的 ubuntu 镜像作为基础运行环境，接下来使用 docker build 命令构建镜像。

这种构建方式生成的镜像在体积上比最初的缩小了几乎 90% 。镜像的最终大小就相当于 ubuntu:latest 的大小加上 Golang 二进制可执行文件的大小。不过，这种方式将应用的编译过程拆分到了宿主机上，这会让 Dockerfile 失去描述应用编译和打包的作用，不是一个好的实践。

多阶段构建

多阶段构建的本质其实就是将镜像构建过程拆分成编译过程和运行过程。第一个阶段对应编译的过程，负责生成可执行文件；第二个阶段对应运行过程，也就是拷贝第一阶段的二进制可执行文件，并为程序提供运行环境，最终镜像也就是第二阶段生成的镜像。

1
2
3
4
5
6
7
8
9
10
11

FROM golang:1.20 as builder
WORKDIR /opt/app
COPY . .
RUN go build -o hz-zeus ./zeus


FROM ubuntu:latest
WORKDIR /opt/app
COPY --from=builder /opt/app/hz-zeus ./hz-zeus

CMD ["/opt/app/hz-zeus"]

这段内容里有两个 FROM 语句，所以这是一个包含两个阶段的构建过程。

第二阶段，它的作用是将第一阶段生成的二进制可执行文件复制到当前阶段，把 ubuntu:latest 作为运行环境，并设置 CMD 启动命令。

最后，我们执行docker build后会发现镜像大小与上面的先编译后copy到镜像种的操作生成的镜像一样大小。

到这里，对镜像大小的优化已经基本上完成了，镜像大小也在可接受的范围内。在实际的项目中，我也推荐你使用 ubuntu:latest 作为第二阶段的程序运行镜像。

如何复用构建缓存

在第一阶段的构建过程中，我们先是用 COPY . . 的方式拷贝了源码，又进行了编译，这会产生一个缺点，那就是如果只是源码变了，但依赖并没有变，Docker 将无法复用依赖的镜像层缓存。在实际构建过程中，你会发现 Docker 每次都会重新下载 Golang 依赖。

这就引出了另外一个构建镜像的小技巧：尽量使用 Docker 构建缓存。

要使用 Golang 依赖的缓存，最简单的办法是：先复制依赖文件，再下载依赖，最后再复制源码进行编译。基于这种思路，我们可以将第一阶段的构建修改如下：

1
2
3
4
5
6

FROM golang:1.20 as builder
WORKDIR /opt/app
COPY go.* ./
RUN go mod download
COPY . .
RUN go build -o hz-zeus ./zeus

这样，在每次代码变更而依赖不变的情况下，Docker 都会复用之前产生的构建缓存，这可以加速镜像构建过程。

Java 案例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# First stage: complete build environment
FROM maven:3.5.0-jdk-8-alpine AS builder

# To resolve dependencies in a safe way (no re-download when the source code changes)
ADD ./pom.xml pom.xml
RUN  mvn install -Dmaven.repo.local=./.m2

ADD ./src src/
# package jar
RUN mvn -Dmaven.repo.local=./.m2 install -Dmaven.test.skip=true

From openjdk:8

# copy jar from the first stage
COPY --from=builder target/my-app-1.0-SNAPSHOT.jar my-app-1.0-SNAPSHOT.jar
EXPOSE 8080
CMD ["java", "-jar", "my-app-1.0-SNAPSHOT.jar"]

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

背景

随着业务的复杂程度越来越大，所启动的实例或函数越来越多，Spring cloud 应用的启动越来越慢，那么如何发现 Spring 容器启动慢的原因或位置，有没有一款工具，帮助我们用户发现 Spring 应用启动慢的位置呢？同时，还可以提供 Spring Bean 异步初始化的工具。那么答案是有的。

实战操作

下面，我们可以通过下面的方法尝试分析一下自己的应用吧，Let us go~

安装工具组件

第一步：在 gitlab 网站下面其最新 tag：https://github.com/linyimin0812/spring-startup-analyzer/releases/tag/v2.0.5，下载tar.gz包。

第二步：解压下载的安装包，记住解压后的路径，下面一步要用：

• win 下直接工具解压
• linux 或 mac 通过 tar -zxvf 压缩文件名.tar.gz 解压

项目参数设置

第一步：编辑 Spring Boot 的启动参数，包括：

• 该工具采用 agent 的方式启动，所以要添加参数-javaagent:$HOME/spring-startup-analyzer/lib/spring-profiler-agent.jar，这里 $HOME 代表以前的解压路径，记得根据上面解压后的路径编辑这个参数，我的是：-javaagent:G:/Downloads/spring-startup-analyzer/lib/spring-profiler-agent.jar

• 配置分析工具的参数，这里根据自己需要添加即可，比如可以配置超时时间 10 分钟：-Dspring-startup-analyzer.app.health.check.timeout=10，其他可配置项如下表，你可以工具自己应用的情况去修改：

英文版：

中文版：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

spring-startup-analyzer:
  admin:
    http:
      server:
        port: 8065
  app:
    health:
      check:
        endpoints: "http://127.0.0.1:7002/actuator/health"
        timeout: 10
  async:
    profiler:
      interval:
        millis: 5
      sample:
        thread:
          names: main

最后一步：查看该工具的日志，可以通过 $HOME/spring-startup-analyzer/logs路径，这里 $HOME 代表以前的解压路径，日志文件的类别为：

• startup.log: 启动过程中的日志
• transform.log: 被 re-transform 的类/方法信息

应用启动完成后会在 console 和 startup.log 文件中输出======= spring-startup-analyzer finished, click http://localhost:8065 to visit details. ======，可以通过此输出来判断采集是否完成。

当然，该组件还支持自定义扩展，更多详情请看：https://github.com/linyimin0812/spring-startup-analyzer/tree/v2.0.5#configuration。

接入异步 Bean 优化

这里提到了一个启动加速的优化思路，就是把一些耗时的 Bean 初始化改成异步就能实现。该项目提供了 Bean 的异步初始化工具，也非常好用，只需要下面几步就能完成。提供一个 Spring Bean 异步初始化 jar 包，针对初始化耗时比较长的 bean，异步执行 init 和@PostConstruct 方法提高应用启动速度。

第一步：引入依赖

1
2
3
4
5

<dependency>
    <groupId>io.github.linyimin0812</groupId>
    <artifactId>spring-async-bean-starter</artifactId>
    <version>2.0.5</version>
</dependency>

第二步：配置参数

1
2
3
4
5
6
7
8
9
10
11
12

spring-startup-analyzer:
  boost:
    spring:
      async:
        ## 指定异步的Bean名称
        bean-names: restTemplate,testBean,testComponent
        #异步化的Bean可能在Spring Bean初始化顺序的末尾，导致异步优化效果不佳，打开配置优先加载异步化的Bean
        bean-priority-load-enable: true
        # 执行异步化Bean初始化方法线程池的核心线程数
        init-bean-thread-pool-core-size: 8
        # 执行异步化Bean初始化方法线程池的最大线程数
        init-bean-thread-pool-max-size: 8

第三步：检查 Bean 是否异步初始化。查看日志$HOME/spring-startup-analyzer/logs/startup.log 文件，对于异步执行初始化的方法，会按照以下格式写一条日志:

1

async-init-bean, beanName: ${beanName}, async init method: ${initMethodName}

但是，异步并不是万能的，你还需要注意以下这几点：

• 应该优先从代码层面优化初始化时间长的 Bean，从根本上解决 Bean 初始化耗时长问题
• 对于二方包/三方包中初始化耗时长的 Bean(无法进行代码优化)再考虑 Bean 的异步化
• 对于不被依赖的 Bean 可以放心进行异步化，可以通过各个 Bean 加载耗时中的 Root Bean 判断 Bean 是否被其他 Bean 依赖
• 对于被依赖的 Bean 需要小心分析，在应用启动过程中不能其他 Bean 被调用，否则可能会存在问题

支持异步化的 Bean 类型

支持@Bean, @PostConstruct 及@ImportResource 方式初始化 bean

@Bean(initMethod = “init”)标识的 Bean

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Bean(initMethod = "init")
public TestBean testBean() {
    return new TestBean();
}


@Bean(initMethod = "init")
public RestTemplate restTemplate() {
  SimpleClientHttpRequestFactory requestFactory = new SimpleClientHttpRequestFactory();
  requestFactory.setReadTimeout(env.getProperty("client.http.request.readTimeout", Integer.class, 15000));
  requestFactory.setConnectTimeout(env.getProperty("client.http.request.connectTimeout", Integer.class, 3000));
  RestTemplate rt = new RestTemplate(requestFactory);
  return rt;
}

@PostConstruct 标识的 Bean

1
2
3
4
5
6
7

@Component
public class TestComponent {
    @PostConstruct
    public void init() throws InterruptedException {
        Thread.sleep(20 * 1000);
    }
}

更多详情请看：https://github.com/linyimin0812/spring-startup-analyzer/blob/v2.0.5/README_ZH.md。

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

背景

在这个以k8s为云os的时代，程序员在日常的开发过程中，肯定会遇到各种问题，比如：本地开发完，需要部署到远程k8s集群，本地如何直接操作呢？又如：提测到测试环境发现有问题，或者nightly环境本身没过，这时候，可能需要一些调试。下面介绍一款开源已久的产品来体验秒级体验下本地操作远程k8s、直接在调试远程代码。

借助 Nocalhost 实现 k8s 应用秒级的本地开发体验

直入主题，Nocalhost 是腾讯云 CODING 在 2020 年开源的项目，同时它也是云原生开发领域下第一个由国人主导并进入 CNCF Sandbox 的项目。

Nocalhost 开发实战

安装 Nocalhost 插件

首先，需要先安装 Nocalhost IDE 插件。Nocalhost 支持 VS Code 和 Jetbrains 全系列的 IDE，你可以在市场中搜索。

接下来，我以 Jetbrains Goland 插件为例简单介绍如何安装 Nocalhost 插件。

首先，在 IDEA Goland 插件市场中搜索 Nocalhost，然后点击“安装”按钮进行安装，如下图所示。

在安装 IDE 插件之后，Nocalhost 会自动下载 nhctl 工具，你可以在 Jetbrains Goland 的右下角查看下载进度，nhctl 是 Nocalhost 的核心组件，它为插件提供 Kubernetes API 调用能力。

集成远程 k8s 集群

接下来，添加 Kubernetes 集群，在右侧菜单栏中打开 Nocalhost 插件，如果你已经提前准备好了 K8s 集群，Nocalhost 就会自动识别，点击“Add”即可添加集群。

在上面的第二步，选择k8s的kubeconfig，选择完后，会自动检测是否存在该集群：

如果不存在该集群，会提示：

最后，在 Add 完成功后，会在该菜单下看到集群相关的信息以及资源：

部署应用

接着，我们就可以部署应用了，先来看看部署官方给的示例应用，首先鼠标移到default命名空间位置右击，然后可以看到Deploy App：

点击部署 app后，出现图：

我们点击第四个按钮Deploy Demo，此时，Nocalhost 将自动从 GitHub 克隆示例应用仓库，并将它部署到集群的 default 命名空间下。同时，此时，控制台就会打印如下日志：

此时，表示应用部署成功，Nocalhost 将自动进行端口转发，并打开浏览器访问http://127.0.0.1:39080/productpage示例应用页面，如下图所示：

简单介绍一下这个示例应用，这是一个图书管理系统，展示了书籍的详情信息、评价、作者信息、评分。每部分信息都是由不同的微服务输出的，示例应用一共有 5 个微服务组成，它们分别是 Productpage 服务、Reviews 服务、Details 服务、Rattings 服务和 Authors 服务。其中，Productpage 服务负责输出首页以及请求其他的微服务，也是应用的入口，其他服务根据字面意思分别输出了其他的内容。

秒级开发循环反馈

接下来我们来看一下如何使用 Nocalhost 打破传统的开发循环反馈，并获得秒级的 Kubernetes 应用开发体验。

我们在 Nocalhost 插件中点击 default 展开命名空间，然后点击 bookinfo 展开应用，点击 Workload 展开工作负载，最后，点击 Deployment 查看工作负载列表：

此时，将鼠标移动到 authors 服务，点击右侧的“绿色锤子”按钮进入该服务的开发模式。

然后，在弹出的对话框中选择“Clone from Git Repo”，并选择一个本地目录用来存储源码。

首次打开会出现是否信任，直接点击信任：

点击确认后， Nocalhost 将自动克隆 authors 服务的源码到所选择的目录下，并将源码通过新的 UI 窗口打开。

此时，在新的窗口的右下角你会看到 Nocalhost 进入开发模式的提示，等待片刻后，将获得一个远端容器的终端。

注意，这个终端并不是本地的终端，而是 authors 服务在开发模式下的终端。也就是说，在此终端下执行的所有命令实际上都是在 authors 服务的容器里执行的。此时，你可以在终端内执行 ls 命令来查看容器的文件目录。

由于这个容器启动的逻辑是直接通过运行源码，所以这里有源码，并且执行go run app.go：

此时，我们可以任意改代码进行调试了吧~

容器热加载

其实，可以看出 Nocalhost 是通过文件同步的技术来实现本地和远端代码一致的，在实际编码过程中，每次在本地修改源码后，我们往往需要手动重启容器内的业务进程才能看到编码效果。

那么，能不能更进一步，实现修改代码后自动重载呢？Nocalhost 同样也为我们提供了和语言无关的容器热加载，也就是说，当本地有任何代码变更时，Nocalhost 都会自动帮助我们重启容器内的业务进程，达到容器热加载的目的。接下来，我们一起来体验这个功能。首先，在当前 VS Code 窗口中重新打开 Nocalhost 插件，找到 authors 服务。此时，你将看到该服务左侧有一个“绿色锤子”图标，这表示这个服务正在开发模式当中，如下图所示。

接下来，右击 authors 服务，选择一个选项 Remote Run：

注意，在点击 Remote Run 之前，一定要先确保已经通过 Ctrl+C 的方式手动停止了容器内的业务进程，这可以避免重复运行业务进程导致的端口冲突。

现在，Nocalhost 将自动开启一个新的终端，并自动启动业务进程：

到这里，可能有疑惑，Nocalhost 怎么知道我的业务的启动命令呢？答案是通过为 Nocalhost 配置启动命令。你可以通过点击 authors 服务右侧的“设置”按钮，在弹出的对话框中选择“取消”来查看配置文件中的 command.run 字段。实际上，Nocalhost 是通过运行配置的 run.sh 脚本来启动业务的。

最后，你可以在终端窗口中通过 Ctrl+C 的方式来中断容器热加载。到这里，Nocalhost 容器热加载的全过程就已经体验完了。

一键调试

除了容器热加载以外，Nocalhost 还为我们提供了便利的一键远程调试功能。同样地，找到 authors 服务，右击选择“Remote Debug”来进入远程调试。

接下来，Nocalhost 就会以调试模式启动业务进程，然后通过 Kubernetes 端口转发的方式将远端的调试端口转发到本地，并控制调试器连接到调试端口。需要注意的是，由于 authors 服务是 Golang 编写的，所以调试依赖于本地的 Golang 开发工具，如果你的电脑里没有 Golang 开发环境，Nocalhost 将提示你安装相关工具和插件。进入调试后，你将看到窗口右下角出现准备连接调试器，如下图所示：

后面就可以打断点进行Debug模式调试了。

在这个调试例子中，如果你用的是 M1 芯片的 Mac，那么你可能会发现在调试过程中 IDE 的调试器一直无法连接到远端容器，这时候，你还需要进行下面的操作。在 Nocalhost 插件中点击 authors 服务的“设置”按钮进入服务的开发配置页，并将 image 字段修改为 okteto/golang:1.19，然后，点击“红色锤子”退出 authors 服务的开发模式，退出完成后，再点击“Remote Debug”来进入调试模式即可。最后，要退出调试模式，你可以切换到 VS Code 终端菜单，并通过 Ctrl+C 的方式来终止调试进程。

到此，就完整的带大家走一圈秒级体验本地远程调试k8s集群的应用服务了。谢谢大家关注~

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

前因

随着业务的扩充，微服务项目越来越多，对于分布式架构设计来讲，如何更好的监控每个服务的上下游成为了重点问题， 因为一旦中间某个调用链发生问题，就会导致整个链路连接失败。为了更好、更快的找到链路所在，我们就需要一个完整的链路跟踪系统，本节主要分享的是基于OpenTelemetry的一个链路跟踪库，可以很方便的无缝插拔式接入各种微服务系统中，当然，推荐使用字节开源的微服务分布式框架：Hertz、Kitex，该套框架已经很好的接入很多插件，并且本身提供高性能的功能特性，如果对于微服务有性能要求的，推荐尝试。

基于高性能RPC框架Kitex

前面讲过我们的IDL，并且目前使用idl的两种方式以及使用的场景，接下来，我们直接通过thrift的idl文件来生成一个RPC微服务。

首先第一步，写出这个底层RPC服务的idl逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

namespace go test

struct Request {
1: required string data
2: i64 type
}

struct Msg {
1: i32 code
2: string msg
}

struct Response {
1: Msg msg
2: string data
}

service TestService {
    Response Test1(1: Request req)
    Response Test2(1: Request req)
}

上面写了一个简单的基于thrift的idl，接下来，我们生成一个基于该idl的微服务，执行如下命令：

1

kitex -module "hz-kitex-examples" -thrift frugal_tag,template=slim -service test idl/test.thrift

执行上面的命令后，我们会看到在kitex_gen目录下生成一堆文件，这里就是RPC协议通信时，需要建立的一个桥梁，提供调用者与被调用者的连接：

同时，我们还会看到生成对应的被调用者的逻辑：

这里是启动类中对于网络、编解码、连接的设置：

这样，一个简单的RPC底层微服务就写完了。接下来，我们需要写一个对应的客户端进行彼此之间的通信、调用：

在这个rpc client的逻辑里，我们需要定义与server端一样的编解码、网络连接、通信协议方式。那么到目前为止，对于一个完整的基于Kitex的RPC微服务就开发完成了，下面环节，我们就基于该框架进行插拔式服务的链路跟踪。

插拔式链路跟踪

插拔式链路跟踪，为什么叫插拔式呢？顾名思义，其接入链路跟踪很简单，无需太多的逻辑，即可接入整个服务的连接的链路。本节介绍的链路跟踪技术，主要是基于Opentelemetry协议的Optl，对于该协议技术，大家感兴趣可以参考github的相关资料。

我们先看看RPC server端如何插拔式接入的，很简单，我们直接在server的启动main里加入：

1
2
3
4
5
6

p := provider.NewOpenTelemetryProvider(
provider.WithServiceName(constants.UserServiceName),
provider.WithExportEndpoint("121.37.173.206:4317"),
provider.WithInsecure(),
)
defer p.Shutdown(context.Background())

同时，在初始化new服务端的时候，只要加上：

1
2

server.WithSuite(tracing.NewServerSuite()),
server.WithServerBasicInfo(&rpcinfo.EndpointBasicInfo{ServiceName: constants.UserServiceName}),

这样，对于RPC server端就可以接入Opentelemetry了。

然后，对于调用server的client端，我们看如何接入，也很简单：

1
2

client.WithSuite(tracing.NewClientSuite()),
client.WithClientBasicInfo(&rpcinfo.EndpointBasicInfo{ServiceName: constants.ApiServiceName}),

看到代码是不是感觉很简单，两行code即可搞定，对得起我这文章标题吧。

同时，对于RPC client，也是一个Http server服务，所以可以接入open telemetry：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

p := provider.NewOpenTelemetryProvider(
provider.WithServiceName(constants.ApiServiceName),
provider.WithExportEndpoint("121.37.173.206:4317"), //("localhost:4317"),
provider.WithInsecure(),
)
defer func(ctx context.Context, p provider.OtelProvider) {
  _ = p.Shutdown(ctx)
}(context.Background(), p)

tracer, cfg := hertztracing.NewServerTracer()

r := server.New(
tracer,
)
r.Use(hertztracing.ServerMiddleware(cfg))

看着是不是也很简单，代码逻辑都是一样的，没啥复杂的业务逻辑，新手都能入门。

测试

最后，我们来看看这个接入微服务链路跟踪后的整个系统的连接链路是啥样的，我们需要简单的展示下，这里是直接使用Jaeger进行UI展示，在调用数次请求之后，我们可以看到如下结果，先来看下我们调用的关系链：

然后经过几次调用后，我们可以看到这样的关系图：

最后，我们可以看到每次调用的链路以及日志信息：

最后，以上就是今天分享的几行代码，就可以轻松的无缝接入链路跟踪，帮助我们很好的看到调用链路关系，以及问题定位。

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

Hertz 是什么

Hertz[həːts] 是字节 CloudWeGo 团队一个 Golang 微服务 HTTP 框架，在设计之初参考了其他开源框架 fasthttp、gin、echo 的优势， 并结合字节跳动内部的需求，使其具有高易用性、高性能、高扩展性等特点，目前在字节跳动内部已广泛使用。 如今越来越多的微服务选择使用 Golang，如果对微服务性能有要求，又希望框架能够充分满足内部的可定制化需求，Hertz 会是一个不错的选择。

环境

基础依赖

在开发、部署运行该项目之前，需要有一定的基础环境：

• go v1.16+

• hz 脚手架工具 v0.6.3

• 支持 win、mac、linux

安装 go

直接参考官方文档：https://go.dev/doc/install

安装命令行脚手架工具 hz

hz 是 Hertz 框架提供的一个用于生成代码的命令行工具。目前，hz 可以基于 thrift 和 protobuf 的 IDL 生成 Hertz 项目的脚手架。

注意：

• 确保 GOPATH 环境变量已经被正确地定义（例如 export GOPATH=~/go）并且将 $GOPATH/bin 添加到 PATH 环境变量之中(例如 export PATH=$GOPATH/bin:$PATH)；请勿将 GOPATH 设置为当前用户没有读写权限的目录

• 安装 hz：go install github.com/cloudwego/hertz/cmd/hz@latest

安装完成后执行命令：

1

hz -version

出现如下结果，即为安装成功：

1

hz version v0.6.4

生成代码与运行代码

代码目录确定位置

1. 若将代码放置于 $GOPATH/src 下，需在 $GOPATH/src 下创建代码目录，进入该目录后再进行操作

2. 直接新建一个项目目录

生成代码

我们选择方式二：在任一目录新建一个项目uranus，如下图：

由于我们是做一个大的项目工程，类似 Java 的父子工程，所以我们需要先建立一个依赖，新建一个go.mod文件:

1

go 1.20

由于这边用的是最新的 go 版本，所以直接用 v1.20。

然后我们新建今天的第一个项目:kronos，由于我们后面的编解码都是通过 idl 文件进行生成，所以这里需要用到idl目录，然后我们再创建一个 pkg 目录，来专门存放工具库，综合目录情况如下：

参考 go 项目基本布局：https://github.com/golang-standards/project-layout/blob/master/README_zh.md

最后，我们需要对当前项目进行环境配置：

设置 go 环境

注：在配置代理时，选择国内的域名进行配置。

插曲

在使用 hz 工具生成代码之前，我们需要先了解下编解码序列化工具：thrift、protobuf

• protocol buffers,谷歌开发的数据序列号格式。以二进制形式有效而紧凑地存储结构化数据，允许在网络连接上更快传输。

• thrift 不仅仅提供全套 rpc 解决方案，包括序列化机制、传输层、并发处理框架等的 rpc 服务框架。利用 idl 文件来定义接口和数据类型。通过 thrift 提供的编译器编译成不同语言代码，以此实现跨语言调用。

protobuf 和 json 的区别

• 速度：在序列化和反序列化数据方面，Protobuf 比 JSON 快得多。由于格式是二进制的，json 是文本格式，Protobuf 中读写结构化数据所需的时间比在 JSON 中要短。
• 大小：Protobuf 比 JSON 小得多，在网络带宽有限的情况下，由于二进制数据流的紧凑性，存储和传输 Protobuf 信息所占用的空间比 JSON 信息要少。
• 数据类型：Protobuf 支持更复杂的数据类型，如枚举和 map
• 平台兼容性：由于 Protobuf 是一种开源格式，语言和平台独立的，它可以在多个平台上使用而没有困难或兼容性问题。

手写一个 IDL 文件

在前面，我们了解到 thrift、protobuf 是什么之后，我们先来手写一个 IDL 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

namespace go hello

struct Request {
1: string name
2: string age
}

struct Response {
1: i8 code
    2: string msg
3: map<string,string> data
}

service HelloApi {
    Response echo(1: Request req)
}

上面写的是一个基于 thrift 的 IDL，同样，我们也可以基于：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

syntax = "proto3";
package elena;
option go_package = "elena";

message BaseResp {
    int16 code = 1;
    string msg = 2;
}

message Elena {
    int64 id = 1;
    string name = 2;
    string pthone = 3;
    string password = 4;
}

message CreateRequest {
    string name = 1;
    string password = 2;
    string pthone = 3;
}

message CreateResponse {
    BaseResp result = 1;
    string data = 2;
}

service ElenaService {
    rpc CreateElena (CreateRequest) returns (CreateResponse) {}
}

当然，由于 thrift、protobuf 在不同场景下具有不同的特性与性能，一般：

• 基于 Streaming 场景下，基于 Protobuf 编码，有两种：Kitex Protobuf 和 gRPC。性能较快
• 其它场景基本基于 thrift 进行序列化编解码即可

代码生成

我们按照前面写的 thrift 模板文件 idl，来依赖 hz 工具生成，在生成代码之前，需要安装相应的编译器 thriftgo、protoc：

1

go install github.com/cloudwego/thriftgo@latest

对于 protoc，可以参考：

1
2
3
4
5
6
7
8
9

// brew 安装
$ brew install protobuf

// 官方镜像安装，以 macos 为例
$ wget https://github.com/protocolbuffers/protobuf/releases/download/v3.19.4/protoc-3.19.4-osx-x86_64.zip
$ unzip protoc-3.19.4-osx-x86_64.zip
$ cp bin/protoc /usr/local/bin/protoc
// 确保 include/google 放入 /usr/local/include下
$ cp -r include/google /usr/local/include/google

也可以参考官方：https://github.com/protocolbuffers/protobuf

安装完成编译器后，我们进入目录kronos，执行：

1
2
3
4
5

hz new -module kronos --idl ../idl/hello.thrift -t=template=slim

hz update ../idl/hello.thrift -t=template=slim

go mod tidy

注意，在生成代码后，需要进行微调，目录结构、go.mod 等不同，会出现一些小问题，同时需要执行：go mod tidy进行整理。

运行项目

执行文件：main.go

启动之后，看控制台：

可以看到有几个接口，同时当前服务默认监听端口：8888。

打开一个web ui，访问API接口:

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

查系统空间：
df -h
查时间：
kubectl get events
redis监听：
ps -ef | grep 6379
netstat -lntp | grep 6379
sudo netstat -apn | grep 6379
redis目录：/usr/local/redis/bin
/usr/local/redis/etc：配置conf
进入redis：redis-cli -h localhost -p 6379 -a 密码

CONFIG GET maxclients
CONFIG set maxclients 10000

测试时间：
curl -o /dev/null -s -w ‘%{time_connect}:%{time_starttransfer}:%{time_total}\n’ ‘http://10.10.1.8:9086/v1/Frameworks'

一、文件和目录

1. cd命令
   （它用于切换当前目录，它的参数是要切换到的目录的路径，可以是绝对路径，也可以是相对路径）
   cd /home    进入 ‘/ home’ 目录
   cd ..            返回上一级目录 
   cd ../..         返回上两级目录 
   cd               进入个人的主目录 
   cd ~user1   进入个人的主目录 
   cd -             返回上次所在的目录

2. pwd命令
   pwd 显示工作路径

3. ls命令
   查看文件与目录的命令，list之意）
   ls 查看目录中的文件 
   ls -l 显示文件和目录的详细资料 
   ls -a 列出全部文件，包含隐藏文件
   ls -R 连同子目录的内容一起列出（递归列出），等于该目录下的所有文件都会显示出来  
   ls [0-9] 显示包含数字的文件名和目录名

4. cp命令
   （用于复制文件，copy之意，它还可以把多个文件一次性地复制到一个目录下）

-a ：将文件的特性一起复制
-p ：连同文件的属性一起复制，而非使用默认方式，与-a相似，常用于备份
-i ：若目标文件已经存在时，在覆盖时会先询问操作的进行
-r ：递归持续复制，用于目录的复制行为
-u ：目标文件与源文件有差异时才会复制
5. mv命令
（用于移动文件、目录或更名，move之意）
-f ：force强制的意思，如果目标文件已经存在，不会询问而直接覆盖
-i ：若目标文件已经存在，就会询问是否覆盖
-u ：若目标文件已经存在，且比目标文件新，才会更新
6. rm命令
（用于删除文件或目录，remove之意）
-f ：就是force的意思，忽略不存在的文件，不会出现警告消息
-i ：互动模式，在删除前会询问用户是否操作
-r ：递归删除，最常用于目录删除，它是一个非常危险的参数

二、查看文件内容

7. cat命令
   （用于查看文本文件的内容，后接要查看的文件名，通常可用管道与more和less一起使用）
   cat file1 从第一个字节开始正向查看文件的内容 
   tac file1 从最后一行开始反向查看一个文件的内容 
   cat -n file1 标示文件的行数 
   more file1 查看一个长文件的内容 
   head -n 2 file1 查看一个文件的前两行 
   tail -n 2 file1 查看一个文件的最后两行 
   tail -n +1000 file1  从1000行开始显示，显示1000行以后的
   cat filename | head -n 3000 | tail -n +1000  显示1000行到3000行
   cat filename | tail -n +3000 | head -n 1000  从第3000行开始，显示1000(即显示3000~3999行)

三、文件搜索

8. find命令
   find / -name file1 从 ‘/‘ 开始进入根文件系统搜索文件和目录 
   find / -user user1 搜索属于用户 ‘user1’ 的文件和目录 
   find /usr/bin -type f -atime +100 搜索在过去100天内未被使用过的执行文件 
   find /usr/bin -type f -mtime -10 搜索在10天内被创建或者修改过的文件 
   whereis halt 显示一个二进制文件、源码或man的位置 
   which halt 显示一个二进制文件或可执行文件的完整路径
   删除大于50M的文件：
   find /var/mail/ -size +50M -exec rm {} ＼;

四、文件的权限 - 使用 “+” 设置权限，使用 “-“ 用于取消

9. chmod命令
   ls -lh 显示权限 
   chmod ugo+rwx directory1 设置目录的所有人(u)、群组(g)以及其他人(o)以读（r，4 ）、写(w，2)和执行(x，1)的权限 
   chmod go-rwx directory1  删除群组(g)与其他人(o)对目录的读写执行权限
10. chown命令
    （改变文件的所有者）
    chown user1 file1 改变一个文件的所有人属性 
    chown -R user1 directory1 改变一个目录的所有人属性并同时改变改目录下所有文件的属性 
    chown user1:group1 file1 改变一个文件的所有人和群组属性

11.chgrp命令
（改变文件所属用户组）
chgrp group1 file1 改变文件的群组

五、文本处理

12. grep命令
    （分析一行的信息，若当中有我们所需要的信息，就将该行显示出来，该命令通常与管道命令一起使用，用于对一些命令的输出进行筛选加工等等）
    grep Aug /var/log/messages  在文件 ‘/var/log/messages’中查找关键词”Aug” 
    grep ^Aug /var/log/messages 在文件 ‘/var/log/messages’中查找以”Aug”开始的词汇 
    grep [0-9]  /var/log/messages 选择 ‘/var/log/messages’ 文件中所有包含数字的行 
    grep Aug -R /var/log/* 在目录 ‘/var/log’ 及随后的目录中搜索字符串”Aug” 
    sed ‘s/stringa1/stringa2/g’ example.txt 将example.txt文件中的 “string1” 替换成 “string2” 
    sed ‘/^$/d’ example.txt 从example.txt文件中删除所有空白行
13. paste命令
    paste file1 file2 合并两个文件或两栏的内容 
    paste -d ‘+’ file1 file2 合并两个文件或两栏的内容，中间用”+”区分
14. sort命令
    sort file1 file2 排序两个文件的内容 
    sort file1 file2 | uniq 取出两个文件的并集(重复的行只保留一份) 
    sort file1 file2 | uniq -u 删除交集，留下其他的行 
    sort file1 file2 | uniq -d 取出两个文件的交集(只留下同时存在于两个文件中的文件)
15. comm命令
    comm -1 file1 file2 比较两个文件的内容只删除 ‘file1’ 所包含的内容 
    comm -2 file1 file2 比较两个文件的内容只删除 ‘file2’ 所包含的内容 
    comm -3 file1 file2 比较两个文件的内容只删除两个文件共有的部分
    六、打包和压缩文件
16. tar命令
    （对文件进行打包，默认情况并不会压缩，如果指定了相应的参数，它还会调用相应的压缩程序（如gzip和bzip等）进行压缩和解压）

-c ：新建打包文件
-t ：查看打包文件的内容含有哪些文件名
-x ：解打包或解压缩的功能，可以搭配-C（大写）指定解压的目录，注意-c,-t,-x不能同时出现在同一条命令中
-j ：通过bzip2的支持进行压缩/解压缩
-z ：通过gzip的支持进行压缩/解压缩
-v ：在压缩/解压缩过程中，将正在处理的文件名显示出来
-f filename ：filename为要处理的文件
-C dir ：指定压缩/解压缩的目录dir
压缩：tar -jcv -f filename.tar.bz2 要被处理的文件或目录名称
查询：tar -jtv -f filename.tar.bz2
解压：tar -jxv -f filename.tar.bz2 -C 欲解压缩的目录
bunzip2 file1.bz2 解压一个叫做 ‘file1.bz2’的文件 
bzip2 file1 压缩一个叫做 ‘file1’ 的文件 
gunzip file1.gz 解压一个叫做 ‘file1.gz’的文件 
gzip file1 压缩一个叫做 ‘file1’的文件 
gzip -9 file1 最大程度压缩 
rar a file1.rar test_file 创建一个叫做 ‘file1.rar’ 的包 
rar a file1.rar file1 file2 dir1 同时压缩 ‘file1’, ‘file2’ 以及目录 ‘dir1’ 
rar x file1.rar 解压rar包
zip file1.zip file1 创建一个zip格式的压缩包 
unzip file1.zip 解压一个zip格式压缩包 
zip -r file1.zip file1 file2 dir1 将几个文件和目录同时压缩成一个zip格式的压缩包
七、系统和关机（关机、重启和登出）

shutdown -h now 关闭系统(1) 
init 0 关闭系统(2) 
telinit 0 关闭系统(3) 
shutdown -h hours:minutes & 按预定时间关闭系统 
shutdown -c 取消按预定时间关闭系统 
shutdown -r now 重启(1) 
reboot 重启(2) 
logout 注销 
time 测算一个命令（即程序）的执行时间
八、进程相关的命令
17. jps命令
（显示当前系统的java进程情况，及其id号）
jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一个显示当前所有java进程pid的命令，简单实用，非常适合在linux/unix平台上简单察看当前java进程的一些简单情况。
18. ps命令
（用于将某个时间点的进程运行情况选取下来并输出，process之意）
-A ：所有的进程均显示出来
-a ：不与terminal有关的所有进程
-u ：有效用户的相关进程
-x ：一般与a参数一起使用，可列出较完整的信息
-l ：较长，较详细地将PID的信息列出
ps aux # 查看系统所有的进程数据
ps ax # 查看不与terminal有关的所有进程
ps -lA # 查看系统所有的进程数据
ps axjf # 查看连同一部分进程树状态
19. kill命令
（用于向某个工作（%jobnumber）或者是某个PID（数字）传送一个信号，它通常与ps和jobs命令一起使用）
20. killall命令
（向一个命令启动的进程发送一个信号）
21. top命令
是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。
如何杀死进程：
（1）图形化界面的方式
（2）kill -9 pid  （-9表示强制关闭）
（3）killall -9 程序的名字
（4）pkill 程序的名字
查看进程端口号：
netstat -tunlp|grep 端口号

泛化调用

泛化调用是不需要依赖生成代码即可对 RPC 服务发起调用的一种特性。通常用于不需要生成代码的中台服务，场景如流量中转、API 网关等。

调用方式

Kitex 泛化调用目前仅支持 Thrift 协议，调用方式如下：

• 1. 二进制泛化调用
• 2. HTTP 映射泛化调用
• 3. Map 映射泛化调用
• 4. JSON 映射泛化调用

其中 HTTP 映射泛化对 IDL 编写规范有专门文章介绍《Thrift-HTTP 映射的 IDL 规范》，里面详细介绍了泛化调用解析 Thrift IDL 文件整体规范、约定和已支持的注解。

IDLProvider

HTTP/Map/JSON 映射的泛化调用虽然不需要生成代码，但需要使用者提供 IDL，来定义入参位置和映射关系。

目前 Kitex 有两种 IDLProvider 实现，使用者可以选择指定 IDL 路径，也可以选择传入 IDL 内容。当然也可以根据需求自行扩展 generci.DescriptorProvider。如果有 IDL 管理平台，最好与平台打通，可以及时更新 IDL。

支付开放平台

支付开放平台通常是开放给服务商或商户提供收款记账等能力的服务入口，常见于支付宝、微信、银联等第三方或第四方支付渠道商，特别是前几年发展起来的聚合支付方向。

该演示项目规划要点如下：

1. 对外暴露的是 HTTP 接口，可以用 Hertz 来做网关入口，根据 HTTP 请求使用 Kitex 泛化调用对请求分发到具体的 RPC 服务；
2. 需要加签、验签，可以演示 Hertz 自定义 middleware；
3. 业务服务通常有商户、支付、对账、安全等模块，业务边界清晰，为了演示仅做支付服务；
4. 关注工程化，如 ORM、分包、代码分层、错误的统一定义及优雅处理等；

工程目录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

├── Makefile
├── README.md
├── cmd
│   └── payment
│       ├── main.go
│       ├── wire.go
│       └── wire_gen.go
├── configs
│   └── sql
│       └── payment.sql
├── docker-compose.yaml
├── docs
│   └── open-payment-platform.png
├── go.mod
├── go.sum
├── hertz-gateway
│   ├── README.md
│   ├── biz
│   │   ├── errors
│   │   │   └── errors.go
│   │   ├── handler
│   │   │   └── gateway.go
│   │   ├── middleware
│   │   │   └── gateway_auth.go
│   │   ├── router
│   │   │   └── register.go
│   │   └── types
│   │       └── response.go
│   ├── main.go
│   ├── router.go
│   └── router_gen.go
├── idl
│   ├── common.thrift
│   └── payment.thrift
├── internal
│   ├── README.md
│   └── payment
├── kitex_gen
└── pkg
    └── auth
        └── auth.go

泛化调用的最简单实现

解析IDL

1

provider, err := generic.NewThriftFileProvider(entry.Name(), idlPath)

构建泛化策略

1
2

//将上面解析到的 IDL 内容，根据场景需要构建 HTTP 的泛化策略
g, err := generic.HTTPThriftGeneric(provider)

生成泛化调用客户端

1
2
3
4
5
6
7
8
9
10
11
12
13

cli, err := genericclient.NewClient(
  svcName,
  g,
  client.WithResolver(nacosResolver),
  client.WithTransportProtocol(transport.TTHeader),
  client.WithMetaHandler(transmeta.ClientTTHeaderHandler),
)
if err != nil {
  hlog.Fatal(err)
}

// 保存映射关系
handler.SvcMap[svcName] = cli

具体实现

网关参数

1
2
3
4
5
6
7
8

{
    "sign":"xxx", // 必填，签名
    "sign_type":"RSA", // 必填，加签方法
    "nonce_str":"J84FJIUH93NFSUH894NJOF", // 必填，随机字符串
    "merchant_id":"xxxx", // 必填，用于签名验证
    "method":"svc-function-name", // 必填，RPC 调用的具体方法
    "biz_params":"{'key':'value'}" // 必填，RPC 业务参数
}

路由规则

将上述的三步构建泛化调用客户端的代码放在了 Hertz 启动服务注册路由时的实现，服务的路由规则是 /gateway/:svc，即构建 gateway 的路由组，使用参数路由知道要泛化调用 RPC 服务的具体服务名。

这部分实现可参看 route.go 文件中 registerGateway 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

func registerGateway(r *server.Hertz) {
group := r.Group("/gateway").Use(middleware.GatewayAuth()...)

if handler.SvcMap == nil {
handler.SvcMap = make(map[string]genericclient.Client)
}
idlPath := "./idl/"
c, err := os.ReadDir(idlPath)
if err != nil {
hlog.Fatalf("new thrift file provider failed: %v", err)
}
nacosResolver, err := resolver.NewDefaultNacosResolver()
if err != nil {
hlog.Fatalf("err:%v", err)
}

for _, entry := range c {
if entry.IsDir() || entry.Name() == "common.thrift" {
continue
}
svcName := strings.ReplaceAll(entry.Name(), ".thrift", "")

provider, err := generic.NewThriftFileProvider(entry.Name(), idlPath)
if err != nil {
hlog.Fatalf("new thrift file provider failed: %v", err)
break
}
//generic.JSONThriftGeneric()
//将上面解析到的 IDL 内容，根据场景需要构建 HTTP 的泛化策略
g, err := generic.HTTPThriftGeneric(provider)
if err != nil {
hlog.Fatal(err)
}
cli, err := genericclient.NewClient(
svcName,
g,
client.WithResolver(nacosResolver),
client.WithTransportProtocol(transport.TTHeader),
client.WithMetaHandler(transmeta.ClientTTHeaderHandler),
)
if err != nil {
hlog.Fatal(err)
}

// 保存映射关系
handler.SvcMap[svcName] = cli

    //路由到处理函数
group.POST("/:svc", handler.Gateway)
}
}

发起泛化调用

路由匹配成功之后，走到绑定的 handler.Gateway 处理函数即是发起泛化调用的关键点。

首先根据 handler.SvcMap，获取泛化调用客户端 genericclient.Client，然后根据路由参数 :svc 和 POST 参数 biz_params 、method 拼凑相关参数，进行泛化调用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

svcName := c.Param("svc")
cli, ok := SvcMap[svcName]
if !ok {
c.JSON(http.StatusOK, errors.New(common.Err_BadRequest))
return
}
var params requiredParams
if err := c.BindAndValidate(&params); err != nil {
hlog.Error(err)
c.JSON(http.StatusOK, errors.New(common.Err_ServerMethodNotFound))
return
}

req, err := http.NewRequest(http.MethodPost, "", bytes.NewBuffer([]byte(params.BizParams)))
if err != nil {
hlog.Warnf("new http request failed: %v", err)
c.JSON(http.StatusOK, errors.New(common.Err_RequestServerFail))
return
}
// 这里要留意 IDL 相关注解
req.URL.Path = fmt.Sprintf("/%s/%s", svcName, params.Method)

customReq, err := generic.FromHTTPRequest(req)
if err != nil {
hlog.Errorf("convert request failed: %v", err)
c.JSON(http.StatusOK, errors.New(common.Err_ServerHandleFail))
return
}
resp, err := cli.GenericCall(ctx, "", customReq)
respMap := make(map[string]interface{})
if err != nil {
hlog.Errorf("GenericCall err:%v", err)
bizErr, ok := kerrors.FromBizStatusError(err)
if !ok {
c.JSON(http.StatusOK, errors.New(common.Err_ServerHandleFail))
return
}
respMap[types.ResponseErrCode] = bizErr.BizStatusCode()
respMap[types.ResponseErrMessage] = bizErr.BizMessage()
c.JSON(http.StatusOK, respMap)
return
}
realResp, ok := resp.(*generic.HTTPResponse)
if !ok {
c.JSON(http.StatusOK, errors.New(common.Err_ServerHandleFail))
return
}
realResp.Body[types.ResponseErrCode] = 0
realResp.Body[types.ResponseErrMessage] = "ok"
c.JSON(http.StatusOK, realResp.Body)

为了更好的演示支付网关，这里做了签名验证和返回参数加签的代码。

签名

首先在路由组注册时，给 /gateway 路由组注册了一个 GatewayAuth 的中间件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

func registerGateway(r *server.Hertz) {
   group := r.Group("/gateway").Use(middleware.GatewayAuth()...)
}

type AuthParam struct {
   Sign       string `form:"sign,required" json:"sign"`
   SignType   string `form:"sign_type,required" json:"sign_type"`
   MerchantId string `form:"merchant_id,required" json:"merchant_id"`
   NonceStr   string `form:"nonce_str,required" json:"nonce_str"`
}

func GatewayAuth() []app.HandlerFunc {
   return []app.HandlerFunc{func(ctx context.Context, c *app.RequestContext) {
      var authParam AuthParam

// TODO 签名相关的 key 或私钥应该根据商户号正确获取，这里仅做展示，没有做商户相关逻辑
      key := "123"
      p, err := auth.NewSignProvider(authParam.SignType, key)
      if err != nil {
         hlog.Error(err)
         c.JSON(http.StatusOK, errors.New(common.Err_Unauthorized))
         c.Abort()
         return
      }
      // 验签关键点
      if !p.Verify(authParam.Sign, authParam) {
         hlog.Error(err)
         c.JSON(http.StatusOK, errors.New(common.Err_Unauthorized))
         c.Abort()
         return
      }

      c.Next(ctx)

      // 响应之后加签回去
      data := make(utils.H)
      if err = json.Unmarshal(c.Response.Body(), &data); err != nil {
         dataJson, _ := json.Marshal(errors.New(common.Err_RequestServerFail))
         c.Response.SetBody(dataJson)
         return
      }
      data[types.ResponseNonceStr] = authParam.NonceStr
      data[types.ResponseSignType] = authParam.SignType
      data[types.ResponseSign] = p.Sign(data)
      dataJson, _ := json.Marshal(data)
      c.Response.SetBody(dataJson)
   }}
}

项目优化

错误处理

在网关和 RPC 服务都要演示错误处理，可能数量比较多。为了规范实现，把错误定义收拢到 IDL 公共协议中去，根据生成的代码返回特定的错误，便于判断和管理。

错误定义

在 idl 目录中新增了 common.thrift 文件，把错误码都枚举出来，并约定不同的服务或地方使用不同的错误码段。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

namespace go common

enum Err
{
   // gateway 10001- 19999
   BadRequest            = 10001,
   Unauthorized          = 10002,
   ServerNotFound        = 10003,
   ServerMethodNotFound  = 10004,
   RequestServerFail     = 10005,
   ServerHandleFail      = 10006,
   ResponseUnableParse   = 10007,

   // payment 20001- 29999
   DuplicateOutOrderNo = 20001,

   // other 30001- 93999
   Errxxx = 30001,
}

在网关处的错误进行了简单的封装，方便使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

type Err struct {
ErrCode int64  `json:"err_code"`
ErrMsg  string `json:"err_msg"`
}

// New Error, the error_code must be defined in IDL.
func New(errCode common.Err) Err {
return Err{
ErrCode: int64(errCode),
ErrMsg:  errCode.String(),
}
}

func (e Err) Error() string {
return e.ErrMsg
}

用例：

1
2
3
4
5
6

import (
    "github.com/cloudwego/biz-demo/open-payment-platform/hertz-gateway/biz/errors"
    "github.com/cloudwego/biz-demo/open-payment-platform/kitex_gen/common"
)

c.JSON(http.StatusOK, errors.New(common.Err_RequestServerFail))

RPC 服务使用 Kitex 业务异常 的特性支持，只需要在泛化调用客户端和 RPC 服务端制定好相关配置即可。

具体用法如：

1
2
3
4
5
6

import (
   "github.com/cloudwego/biz-demo/open-payment-platform/kitex_gen/common"
)
// 这里类型转换较为繁琐，亦可考虑如何简化优化封装
// 比如一个思路是如果想业务异常也想不依赖某个框架用法，如何做
return nil, kerrors.NewBizStatusError(int32(common.Err_DuplicateOutOrderNo), common.Err_DuplicateOutOrderNo.String())

遗留问题

1. 该项目没有演示配置相关的使用，所以注册中心和数据库配置仅是硬编码；
2. 签名处理如何获取商户私钥或 key ，需要实际业务考虑；
3. 错误处理可继续优化；
4. 泛化调用注解示例较为简单，可根据实际入参和映射关系进行灵活配置；
5. 整洁架构在业务膨胀之后是否会遇到新的问题；

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

概览

在很久之前的文章中说过，K8s 作为云原生时代的创造者，下一代云原生的中间利器，从云原生 1.0 到 2.0，作为基石，成就无数服务畅游每一台机器。前面的文章 KiteX 入门篇 介绍了如何简单的开发一个高性能 RPC 微服务，并且我们看到其性能与吞吐还是不错的。但需要中间件 Nacos 来连接服务端与客户端。今天，我们主要从 K8s 角度来看 Kitex 如何接入云原生，甚至后面的 Istio。

实践

服务端

前面文章 KiteX 入门篇，我们介绍了如何创建一个服务端，那我们这次改造下，让其接入 K8s。

这里主要现需要去掉关于 Nacos 的逻辑，然后我们再看下面的代码：

1

server.WithServiceAddr(&net.TCPAddr{Port: 9000}),

这段代码的含义是通过 Nacos 注册时候，我们把服务注册的端口为 9000，但如果服务是以 K8s 部署的 Pod 形式，则代表的是 Pod 的端口，同时，由于 K8s 这种开源注册中心默认使用 TCP 协议，所以这里支持的是 TCP 协议。
这样简单的配置，即可让服务注册到 K8s，被 k8s-api 发现。

完整代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

svr := note.NewServer(
new(api.NoteApi),
//基于svc进行服务注册，9000为svc的port
server.WithServiceAddr(&net.TCPAddr{Port: 9000}),
server.WithMuxTransport(),
server.WithLimit(&limit.Option{MaxConnections: 10000, MaxQPS: 5000}),

server.WithPayloadCodec(thrift.NewThriftCodecWithConfig(thrift.FastRead | thrift.FastWrite)),

//server.WithTracer(prometheus.NewServerTracer(":9092", "/kitexNoteserver")),

server.WithErrorHandler(func(err error) error {
error := errno.ConvertErr(err)
return error
}),
server.WithCodec(codec.NewDefaultCodecWithSizeLimit(1024 * 1024 * 10)),//10M

server.WithMetaHandler(transmeta.ServerTTHeaderHandler),                                            // registry
)
err := svr.Run()
if err != nil {
klog.Fatal(err)
}

部署脚本

由于我们需要通过镜像部署服务，所以需要 dockerfile：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

FROM ubuntu:16.04 as build

RUN apt-get update && apt-get install -y --no-install-recommends \
        g++ \
        ca-certificates \
        wget && \
    rm -rf /var/lib/apt/lists/*


ENV GOLANG_VERSION 1.18.1
RUN wget -nv -O - https://studygolang.com/dl/golang/go1.18.1.linux-amd64.tar.gz \
     | tar -C /usr/local -xz

ENV GOPROXY=https://goproxy.cn,direct
ENV GO111MODULE=on
ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH

RUN apt-get update && apt-get install -y git

WORKDIR /go/src

COPY . .
#RUN go env -w GOPROXY=https://goproxy.cn,direct
#RUN go env -w GO111MODULE=on

RUN go build -o hello-server  ./server/hello
RUN chmod +x ./hello-server

RUN rm -rf cache && rm -rf kitex_gen && rm -rf README.md\
&& rm -rf build && rm -rf codec && rm -rf client \
&& rm -rf images && rm -rf idl && rm -rf go.mod  && rm -rf go.sum \
&& rm -rf pkg && rm -rf script && rm -rf retry \
&& rm -rf server && rm -rf streaming && rm -rf LICENSE

CMD ["./hello-server"]

然后我们需要 K8s 的 yaml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-service-deployment
  namespace: default
  labels:
    app: hello-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-service
  template:
    metadata:
      labels:
        app: hello-service
    spec:
      nodeSelector:
        hello-service: "true"
      containers:
        - name: node-service
          image: node-service
          imagePullPolicy: IfNotPresent
          ports:
            - name: hello01
              containerPort: 9000

              ......

最后需要对这个服务进行创建 svc，以便进行负载均衡被其它服务所访问。

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: Service
metadata:
  name: hello-service-svc
  namespace: default
spec:
  ports:
    - name: hello01
      port: 9000
      targetPort: hello01
  selector:
    app: hello-service

此时，一个完整的服务端的代码以及部署脚本就完结了。

客户端

同样的，客户端我们来看看看，也是很简单，同样先需去掉 Nacos 的配置，然后我们引入利用 K8s svc 进行服务的请求：

1

client.WithHostPorts("hello-service-svc.default.svc.cluster.local:9000"),

在创建客户端的时候，客户端的 host 要写实际集群中的内网地址：hello-service-svc.default.svc.cluster.local，这样就不用再搭配第三方的服务注册中心了。

这样就可以通过该 host 进行访问服务端的服务了。。。

部署脚本

客户端的部署脚本类似服务端的，同样需要部署的构建镜像脚本、部署 deployment 脚本、部署 svc。此处客户端由于是通过容器部署，所以我们需要把其服务的 port 进行映射到主机，这样方便来进行浏览器访问服务：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apiVersion: v1
kind: Service
metadata:
  name: customer-service-svc
  namespace: default
spec:
  type: NodePort
  ports:
    - name: customer01
      nodePort: 30230
      port: 3000
      targetPort: customer01
  selector:
    app: customer-service

测试

我们先通过命令进行部署:

1

kubectl create -f ...

创建完服务相关资源后，我们看看 pod：

资源 svc 情况：

我们把 port 映射到主机上，然后我们通过浏览器进行访问客户端，此处我们访问的是存在 10000 条数据入库的服务：

我们可以看到，数据大概是 9634 条总数，我们取 500 条，耗时 40ms，接下来，我们换作取 5000 条：

数据大小 624kb，发现大概耗时：159ms，还是可以的。

最后，我们看看拿全部数据大概耗时：

发现全部数据大小：1.2M，耗时 300 多毫秒，还是不错的。

特性

我们的服务为什么能如此之快呢，这里我们引入了一种高性能网络库：netpoll，以及在编解码方面，我们利用 Thrift 的 IDL 进行生成代码，同时，利用其提供的 FastRead、FastWrite 来进行快速传输。

如有想要源码的，可以关注后，后台联系博主获取哟~

结束福利

开源实战利用 k8s 作微服务的架构设计代码:

https://gitee.com/damon_one/spring-cloud-k8s

欢迎大家 star，多多指教。

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

概览

KiteX 是 bytedance 开源的高性能 RPC 框架，实现了高吞吐、高负载、高性能等居多特性，具体请看 KiteX 的实践，文章介绍多传输协议、消息协议时，说到 KiteX 支持的协议类型：Thrift、Protobuf 等，今天我们主要来实践如何利用 KiteX 基于对应的 IDL 生成对应协议的代码。

Thrift 简介

Thrift 本身是一软件框架（远程过程调用框架），用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引 擎，以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。同时，作为 IDL（接口定义语言 Interface Definition Language），允许你定义一个简单的定义文件中的数据类型和服务接口，以作为输入文件，编译器生成代码用来方便地生成 RPC 客户端和服务器通信的无缝跨编程语言。

Protobuf 简介

Protobuf 全称是 Google Protocol Buffer，是一种高效轻便的结构化数据存储方式，用于数据的通信协议、数据存储等。相对比 XML 来说，其特点：

• 语言无关，平台无关
• 高效
• 扩展性、兼容性更强

基于 IDL 的 KiteX 实践

在 RPC 框架中，我们知道，服务端与客户端通信的前提是远程通信，但这种通信又存在一种关联，那就是通过一套相关的协议（消息、通信、传输等）来规范，但客户端又不用关心底层的技术实现，只要定义好了这种通信方式即可。

在 KiteX 中，也提供了一种生成代码的命令行工具：kitex，目前支持 thrift、protobuf 等 IDL，并且支持生成一个服务端项目的骨架。

安装命令行工具

环境

• 如果您之前未搭建 Golang 开发环境， 可以参考 Golang 安装
• 推荐使用最新版本的 Golang，我们保证最新三个正式版本的兼容性(现在 >= v1.16)。
• 确保打开 go mod 支持 (Golang >= 1.15 时，默认开启)
• kitex 暂时没有针对 Windows 做支持，如果本地开发环境是 Windows 建议使用 WSL2

安装

• 确保 GOPATH 环境变量已经被正确地定义（例如 export GOPATH=~/go）并且将 $GOPATH/bin添加到 PATH 环境变量之中（例如 export PATH=$GOPATH/bin:$PATH）；请勿将 GOPATH 设置为当前用户没有读写权限的目录
• 安装 kitex：go install github.com/cloudwego/kitex/tool/cmd/kitex@latest
• 安装 thriftgo：go install github.com/cloudwego/thriftgo@latest

安装成功后，执行 kitex --version 可以看到如下信息：

1
2

$ kitex --version
v0.4.2

如果在安装阶段发生问题，可能主要是由于对 Golang 的不当使用造成的，需要逐一排查。

编写一个 IDL

我们先新建一个项目：hz-kitex-examples，新建完之后，我们在该项目下新建一个目录：idl，然后我们编写一个 thrift IDL：

接下来，我们编写这个 IDL:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

namespace go hello

struct ReqBody {
    1: string name
    2: i32 type
    3: string email
}

struct Request {
1: string data
2: string message
3: ReqBody reqBody
}

struct Msg {
1: i64 status
2: i64 code
3: string msg
}

struct Response {
1: Msg msg
2: string data
}

service HelloService {
    Response echo(1: Request req)
    Response testHello4Get(1: Request req)
    Response testHello4Post(1: Request req)
}

这里我们定义了一个命名空间：hello，这个是代表生成的代码中有一个目录：hello，然后我们编写一个请求对象：ReqBody，接着定义一个泛对象，包括了那个请求对象，这块没要求，自己定义好就行，同时我们定义了响应对象Response，此外，我们还定义了一个类，类中存在三个函数方法。

生成代码

在定义完 IDL 后，我们来看如何生成代码呢？直接执行如下命令：

1

kitex -module "hz-kitex-examples" -thrift frugal_tag -service helloserver idl/hello.thrift

这里有几个参数 tag:

-module module_name

• 该参数用于指定生成代码所属的 Go 模块，会影响生成代码里的 import path。

• 如果当前目录是在 $GOPATH/src 下的一个目录，那么可以不指定该参数；kitex 会使用 $GOPATH/src 开始的相对路径作为 import path 前缀。例如，在 $GOPATH/src/example.com/hello/world 下执行 kitex，那么 kitex_gen/example_package/example_package.go 在其他代码代码里的 import path 会是 example.com/hello/world/kitex_gen/example_package。

• 如果当前目录不在 $GOPATH/src 下，那么必须指定该参数。

• 如果指定了 -module 参数，那么 kitex 会从当前目录开始往上层搜索 go.mod 文件

  • 如果不存在 go.mod 文件，那么 kitex 会调用 go mod init 生成 go.mod；
  • 如果存在 go.mod 文件，那么 kitex 会检查 -module 的参数和 go.mod 里的模块名字是否一致，如果不一致则会报错退出；
  • 最后，go.mod 的位置及其模块名字会决定生成代码里的 import path。

-service service_name

• 使用该选项时，kitex 会生成构建一个服务的脚手架代码，参数 service_name 给出启动时服务自身的名字，通常其值取决于使用 Kitex 框架时搭配的服务注册和服务发现功能。

对于当前项目，我们执行如下：

1

kitex -module "hz-kitex-examples" -thrift frugal_tag -service helloserver idl/hello.thrift

由于当前项目不在环境路径下，需要指定 go.mod 所在的目录模块的名称，同时，我们指定一个服务名。

这样在执行后，我们会发现生成的目录结构如下图：

在生成的目录中根目录是kitex_gen，代表是 kitex 工具生成的，其次其目录下有一个 hello 目录，这是代表 IDL 文件中的 ns，在其下面有一个文件：定义了请求对象与响应对象的序列化、传输信息的读写等操作。

在其下面还存在一个 service 目录，用来生成跟客户端与服务端相关的 service 处理逻辑。其中也定义了 service 中处理的方法信息。

同时，我们可以看到生成了服务端的基础框架：

服务端

新建一个server 目录，然后在里面新建一个项目hello，此时把生成服务端的骨架代码拷贝到里面：

拷贝完之后，我们可以丰满服务端的函数的逻辑，以 Echo 函数为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

func (s *HelloApi) Echo(ctx context.Context, req *api.Request) (resp *api.Response, err error) {
klog.Info("hello service enter: " + GetIpAddr2())

resp = &api.Response {
Msg:  &api.Msg {
Status: 200,
Code:   10000,
Msg:    req.Message,
},
Data: req.Message,
}
return resp, nil
}

func GetIpAddr2() string {
conn, err := net.Dial("udp", "8.8.8.8:53")
if err != nil {
klog.Error(err)
return ""
}
localAddr := conn.LocalAddr().(*net.UDPAddr)
// 192.168.1.20:61085
ip := strings.Split(localAddr.String(), ":")[0]

return ip
}

然后再定义启动函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

svr := hello.NewServer(new(api.HelloApi),
    server.WithServiceAddr(&net.TCPAddr{Port: 2008}),
server.WithServerBasicInfo(&rpcinfo.EndpointBasicInfo{ServiceName: constants.HelloServiceName}),
    server.WithPayloadCodec(thrift.NewThriftCodecWithConfig(thrift.FastRead | thrift.FastWrite)),
server.WithErrorHandler(func(err error) error {
error := errno.ConvertErr(err)
return error
}),
//指定默认 Codec 的包大小限制，默认无限制 option: codec.NewDefaultCodecWithSizeLimit
server.WithCodec(codec.NewDefaultCodecWithSizeLimit(1024 * 1024 * 10)),//10M
server.WithLimit(&limit.Option{MaxConnections: 10000, MaxQPS: 5000}),
//连接多路复用(mux)
server.WithMuxTransport(),
server.WithMetaHandler(transmeta.ServerTTHeaderHandler),
server.WithRegistry(registry.NewNacosRegistry(r1)),
)

在这里，我们定义了服务端的端口：2008，同时被注册到 Nacos。启动之后：

可以看到被注册到 Nacos：

这里注册 Nacos 的代码前面已经讲过了，具体可以看：KiteX 的实践。

客户端

关于客户端，也是一样，新建一个 client 目录，里面新建一个项目customer-service，新建启动 main 函数，这里与服务端类似不再赘述了。主要注意一点：这里由于需要提供 Http 协议接口，需要结合 Hertz 来进行：

至于 Hertz，它是一个高性能的 Http 微服务框架在后面的文章中会进一步讲解，此处不再赘述。

启动函数新建完后，我们需要初始化一个 RPC 连接的客户端：

此处客户端的初始化，也是基于之前生成的代码：

在这个函数初始化客户端时，需要定义请求的服务名、网络库、负载均衡策略、出错误处理机制等。同时，我们还需要复写需要调用的函数，去调用相关的接口：

写完 RPC 的部分，一个简单的 RPC 协议调用就能串联起来了，此时，我们来简单写下客户端的接口调用：

1
2
3
4
5
6
7
8
9
10
11

func HelloDemo(ctx context.Context, c *app.RequestContext) {
req := &api.Request{Message: "my request"}
  // TODO
resp, err := rpc.Echo(context.Background(), req)
if err != nil {
log.Fatal(err)
}
klog.Info(resp)
  // TODO
c.JSON(consts.StatusOK, (resp))
}

上面定义的是客户端的接口入口，进入后，会调用 rpc 的部分。同时在调用 RPC 前后，可以有自己的逻辑处理以及响应数据的处理，在 TODO 部分。

启动客户端进行服务注册：

测试

在启动完服务端、客户端后，我们访问客户端的 http 接口：

1

http://192.168.6.51:3000/v1/hello/test

我们再多几次进行访问：

发现其访问的性能以及速度还是不错的，这得益于 KiteX 框架中使用了自研的 Netpoll 网络库以及实现了高效的吞吐编解码性能提升。

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

概览

Kitex 字节跳动内部的 Golang 微服务 RPC 框架，具有高性能、强可扩展的特点，在字节内部已广泛使用。如果对微服务性能有要求，又希望定制扩展融入自己的治理体系，Kitex 会是一个不错的选择。

架构设计

框架特点

• 高性能

使用自研的高性能网络库 Netpoll，性能相较 go net 具有显著优势。

• 扩展性

提供了较多的扩展接口以及默认扩展实现，使用者也可以根据需要自行定制扩展，具体见下面的框架扩展。

• 多消息协议

RPC 消息协议默认支持 Thrift、Kitex Protobuf、gRPC。Thrift 支持 Buffered 和 Framed 二进制协议；Kitex Protobuf 是 Kitex 自定义的 Protobuf 消息协议，协议格式类似 Thrift；gRPC 是对 gRPC 消息协议的支持，可以与 gRPC 互通。除此之外，使用者也可以扩展自己的消息协议。

• 多传输协议

传输协议封装消息协议进行 RPC 互通，传输协议可以额外透传元信息，用于服务治理，Kitex 支持的传输协议有 TTHeader、HTTP2。TTHeader 可以和 Thrift、Kitex Protobuf 结合使用；HTTP2 目前主要是结合 gRPC 协议使用，后续也会支持 Thrift。

• 多种消息类型

支持 PingPong、Oneway、双向 Streaming。其中 Oneway 目前只对 Thrift 协议支持，双向 Streaming 只对 gRPC 支持，后续会考虑支持 Thrift 的双向 Streaming。

• 服务治理

支持服务注册/发现、负载均衡、熔断、限流、重试、监控、链路跟踪、日志、诊断等服务治理模块，大部分均已提供默认扩展，使用者可选择集成。

• 代码生成

Kitex 内置代码生成工具，可支持生成 Thrift、Protobuf 以及脚手架代码。

实战

基于 Etcd 实现服务注册与发现

1. 首先基于 Windows 环境，搭建 Go 开发环境，安装需要的开发工具。
2. 安装需要的软件工具：Etcd、Nacos。

新建 RPC 微服务项目

服务提供者

新建一工程项目，引入依赖:

1
2
3
4

github.com/cloudwego/hertz v0.3.2
github.com/cloudwego/kitex v0.4.2
github.com/kitex-contrib/registry-etcd v0.0.0-20220110034026-b1c94979cea3
github.com/kitex-contrib/registry-nacos v0.0.1

这里除了引入基于 Http 协议的框架 Hertz，还需要引入 Kitex 依赖，同时，需要引入注册中心服务:etcd、nacos 等。

引入完之后，我们需要新建基于 Hertz 的项目，因为此项目是基于 Hertz（此框架后续会进行相关的开发延伸），实际是基于 Http 协议，新建完成后，我们来看 main 函数：

1
2
3
4
5
6
7
8
9
10
11
12
13

r, err := etcd.NewEtcdRegistry([]string{"127.0.0.1:2379"})

svr := user.NewServer(new(UserServiceImpl),
server.WithServerBasicInfo(&rpcinfo.EndpointBasicInfo{ServiceName: constants.UserServiceName}), // server name
server.WithMiddleware(middleware.CommonMiddleware),                                             // middleware
server.WithMiddleware(middleware.ServerMiddleware),
server.WithServiceAddr(addr),                                       // address
server.WithLimit(&limit.Option{MaxConnections: 1000, MaxQPS: 100}), // limit
server.WithMuxTransport(),                                          // Multiplex
server.WithSuite(trace.NewDefaultServerSuite()),                    // tracer
server.WithBoundHandler(bound.NewCpuLimitHandler()),                // BoundHandler
server.WithRegistry(r),
)

由于此处使用的是 Etcd 作为服务注册中心，故 Kitex 提供了此模块etcd "github.com/kitex-contrib/registry-etcd"，etcd.NewEtcdRegistry即可配置基于 Etcd 的注册，同时，此服务作为服务提供者，通过server.WithRegistry(r)即可实现注册于 etcd。

此处的完整代码如下：

服务消费者

同样，消费者采用的 Hertz 框架进行，此处不再赘述：

但在请求生产者之前，都是需要进行服务的发现：这里基于 RPC:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

r, err := etcd.NewEtcdResolver([]string{constants.EtcdAddress})

c, err := noteservice.NewClient(
constants.NoteServiceName,
client.WithMiddleware(middleware.CommonMiddleware),
client.WithInstanceMW(middleware.ClientMiddleware),
client.WithMuxConnection(1),                       // mux
client.WithRPCTimeout(3*time.Second),              // rpc timeout
client.WithConnectTimeout(50*time.Millisecond),    // conn timeout
client.WithFailureRetry(retry.NewFailurePolicy()), // retry
client.WithSuite(trace.NewDefaultClientSuite()),   // tracer
client.WithResolver(r),                            // resolver
)
if err != nil {
panic(err)
}
noteClient = c

此时，我们在消费者端，新增请求生产者的客户端时，我们需要把请求对象constants.NoteServiceName告诉其客户端。

这样就实现了服务的发现，同时，服务发现后需要进行相关的接口调用，此处：

这些需要在 RPC 中实现，此处不再赘述，后续会加入基于 Kitex 的完整开发示例。

此时，一个完整的服务注册与发现就实现完毕了。此处基于 Etcd，接下来，基于 Nacos 就简单多了。

基于 Nacos 实现服务注册与发现

前面我们实现了基于 Etcd 的服务注册与发现，接下来，我们基于 Nacos 来实现，简单点，就是把所有基于 Etcd 的地方改成基于 Nacos：

1
2

//r, err := etcd.NewEtcdResolver([]string{constants.EtcdAddress})
r1,err := resolver.NewDefaultNacosResolver()

但此处需要主要，Nacos 的函数不是以 nacos 进行命名，而是registry.NewDefaultNacosRegistry()或resolver.NewDefaultNacosResolver()。

最后，可以启动相关服务：

注册的服务：

关于作者

  笔名：Damon，技术爱好者，微服务架构设计，云原生、容器化技术，现从事Go相关，涉及云原生、边缘计算、AI人工智能、云产品Devops落地实践等云原生技术。拿过专利。公众号 交个朋友之猿天地 发起人。个人微信 DamonStatham，星球：《交个朋友之猿田地》，个人网站：交个朋友之猿天地 | 微服务 | 容器化 | 自动化，欢迎來撩。

欢迎关注

AI绘画扫我

星球

CPU 密集型操作，顾名思义就是需要持续依赖 CPU 资源来执行的操作，比如各种逻辑计算、解析、判断等等。在这种情况下，我们的优化方向是尽可能地利用多核 CPU 资源，并且避免让 CPU 做无效的切换，因为 CPU 已经在不停地工作了，谁来干都一样，同时切换 CPU 还浪费资源。所以这个时候，我们最好让任务线程数和 CPU 核数保持一致，从而最大限度地利用 CPU 资源。

和 CPU 密集型操作相对的，就是 IO 密集型操作了，比如磁盘 IO 或者网络 IO，这个过程操作系统会挂起任务线程，让出 CPU 资源。此时如果任务线程较少，同时 IO 时间相对较长，那可能会出现所有线程都被挂起，然后 CPU 资源都在闲着的情况，所以此时我们需要适当地增加任务线程数量，来提高吞吐量，同时将 CPU 资源利用起来。

那为什么要说这个呢？因为这是做程序优化的基本原则。通过前面课程的学习，我们知道，秒杀系统里有提供两种类型的服务，一个是 Web 服务，一个是 RPC 服务，前者一般提供 HTTP 接口，后者提供 RPC 接口。当然这两种服务我们一般都是通过 Tomcat 来启动发布，但它们两者之间还是有些不同的。Web 服务接受和处理请求走的是 Tomcat 那套线程模型，而 RPC 服务则是根据选择的 RPC 框架的不同而有所变化，所以这节课我们首先来了解一下 Tomcat 相关的知识。

Tomcat

根据我们以往“知己知彼”的学习方式，先看下 Tomcat 在 NIO 线程模型下是怎么工作的，简图如下所示：

简单来说就是：

• Tomcat 启动时，会创建一个 Server 端的 Socket，来监控我们配置的端口号；
• 之后使用一个 Acceptor 来接受请求，然后将请求放到一个 Poller 下的事件队列中；
• Poller 会轮询取出事件队列中的 Channel，并将其注册到自身下的 Selector；
• 而 Selector 也会不停轮询检查就绪的 Channel，然后将其交给 Tomcat 线程池；
• Tomcat 线程池会拿出一个线程来进行处理，包括解析请求头、请求体等，并将其封装进 HttpServletRequest；
• 最后执行自定义的 Servlet 业务逻辑，执行完毕将响应结果返回。

所以从上图可以看出，所谓的非阻塞，其实就是相对以前的 BIO，Tomcat 不再是用一个线程将一个请求从头处理到尾，而是分阶段来执行了。好处显然易见，那就是提高了系统吞吐量。

在了解了 Tomcat 基本原理之后，我们再回过头来看下有什么地方是我们可以入手优化的。先看下 Tomcat 给我们开放了哪些可配置项：

1

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

上面是 Tomcat 的 Connector 默认配置，首先是端口号，其次是 protocol，也就是上面说到的线程模型。Tomcat 8 之后默认使用的都是 NIO 模式，这个也可以通过我们服务的启动来查看：

如上图所示，就代表分别使用的是 NIO 模式和 NIO2(AIO) 模式，当然还可以选择 BIO 模式以及 APR 模式。具体对比可参考下表：

那说完线程模型的选择，从上图中我们可以看到有个 Tomcat 线程池的概念，它是通过哪些配置来控制的呢？这里我们只摘几个重要的配置说一下，详细信息如下表所示：

说完了 Tomcat 的配置，这里再简单说说 Servlet 的部分知识。我们都知道 Servlet 从 3.0 开始加入了异步，从 3.1 开始又新增了对 IO 非阻塞的支持，那么这个和 Tomcat 线程模型中提到的异步非阻塞是一个概念吗？这里我们就来捋一捋。

首先从上面的 Tomcat 线程模型图中，我们可以清晰地看到，NIO 或 AIO 的概念是针对请求的接收来说，而 Servlet 的异步非阻塞主要是针对请求的处理，已经是到了 Tomcat 线程池那里了。

我们先来看下 Servlet3.0 前后的变化对比，如下图所示：

概述一下就是，Servlet3.0 之前，Tomcat 线程在执行自定义 Servlet 时，如果过程中发生了 IO，那么 Tomcat 线程只能在那等着结果，这时线程是被挂起的，如果被挂起的多了，自然会影响对其他请求的处理。

所以在 Servlet3.0 之后，支持在这种情况下将这种等待的任务交给一个自定义的业务线程池去做，这样 Tomcat 线程可以很快地回到线程池，处理其他请求。而业务线程在执行完业务逻辑以后，通过调用指定的方法，告诉 Tomcat 线程池接下来可以将业务线程执行的结果返回给调用方，这样就实现了同步转异步的效果。

这样做的好处，可能对提高系统的吞吐量有一定帮助，但从 JVM 层面来说，并没有减少工作量。业务线程在执行任务遇到 IO 时，依然会阻塞，现在只是由业务线程池代替了 Tomcat 线程池做了最耗时的那部分工作，这样也许可以将原来的 200 个 Tomcat 线程，拆分成 20 个 Tomcat 线程、180 个业务线程来配合工作。这里原生 Servlet 以及 SpringMVC 对异步功能支持的测试代码，你可以看 GitHub 代码库中的 AsyncServlet 类和 TestAsyncController 类，相信你一看就明白了。

接着我们再聊一下 Servlet3.1 的非阻塞，这块简单来说，就是针对请求消息体的读取，这是个 IO 过程，以前是阻塞式读取，现在支持非阻塞读取了。实现的大致原理就是在读取数据时，新增一个监听事件，在读取完成后由 Tomcat 线程执行回调。

在了解了 Tomcat 线程模型之后，我们接着再说下 RPC 框架相关的知识。

RPC 框架

虽然 RPC 服务处理请求的过程，会依据选用的 RPC 框架而有所不同，但绝大部分 RPC 框架底层使用的都是 Netty，而 Netty 则是基于 NIO 开发的一种网络通信框架，支持多种通信协议，其服务端线程模型简略图如下所示：

简单描述就是：

• 在服务启动时，会创建一个 Server 端 Socket，监控我们配置的端口号；
• 然后将 NioServerSocketChannel 注册到 Boss Pool 中的一个 Selector 上；
• 再之后对 Selector 做轮询，将就绪状态的连接封装成 NioSocketChannel 并注册到 Worker Pool 下的一个 Selector 上；
• 而 Worker Pool 下的 Selector 也是同样轮询，找出可读和可写状态的分别执行不同操作。
• 同时两个 Pool 中都有任务队列，是不同场景下用户自定义或外部通过特定方式提交过去的任务，都会被依次执行。

所以当我们的应用只提供 RPC 服务时，我们可以将 Tomcat 的核心线程池配置，也就是 minSpareThreads 配置成 1，因为用不到。而我们主要需要调整的是 RPC 框架的相关配置，以 Dubbo 为例，我们看下 dubbo:protocol 的主要配置项：

在 Netty 中，虽然只有一个 Worker Pool，但会做两种类型的事情，一个是做 IO 处理，包括请求消息的读写，另一个是做业务逻辑处理。

而 Dubbo 将其分成了两个线程池，也就是上面表格中的两个线程池配置。这两个线程池做的事情，会根据 Dispatcher 的配置而有所不同。Netty 是以事件驱动的形式来工作的，像请求、响应、连接、断开、异常等操作都是事件；而 Dubbo 中的 Dispatcher 就是将不同的事件类型分给不同的线程池来处理，如果你感兴趣的话可以去看下 Dubbo 中 WrappedChannelHandler 类的 5 个实现类，分别对应 Dispatcher 的 5 个选项。

最后一个配置项 Queues，这个默认值是 0，也就是不接受等待，如果没有空闲线程处理任务，将会直接返回。这个得和客户端配置配合使用，如果这里配置了 0，那客户端最好配置重试。

讲完了两种服务的底层线程模型之后，我们再来介绍一下静态资源相关的优化。

静态资源

我们知道在秒杀系统中，客户端与服务端既有动态数据交互，也有静态数据交互，而我们做系统优化有个基本的原则，即前后端交互越少，数据越小，链路越短，数据离用户越近，响应就越快。

基于这个原则，针对以上的静态数据，我们就可以把静态文件 CDN 化，资源前移到全国各地的 CDN 节点上，用户秒杀的时候就近进行下载，就不需要都挤到中心的 Tomcat 服务器上了。

静态资源前移，大家平常也会做，感受比较深的是不是就是客户端的页面加载更快了，但除了性能的提升外，其实它对系统稳定也至关重要。

试想一下，当几百万人同时来拉取这些较大的资源文件时，对中心的 Tomcat 服务器以及公司的网络带宽都是巨大的压力。京东当初在进行口罩抢购的时候，这些静态资源就差点把公司的出口带宽打满，影响交易大盘，后来紧急扩容才避免了危机。

另外，这些静态资源对 Tomcat 所在物理机的网卡挑战也很大，京东在资源 CDN 化前，物理机的万兆网卡曾被打满，后来经过优化之后，网卡的流量只有原来的 10% 了。

在最后，我们再说下 Java 运行的基础环境，JVM 相关的知识以及优化。

JVM

这里如果你对一些基本概念，比如 JVM 内存结构、GC 原理、垃圾收集器类型等还不了解，那建议你先了解一下，会有事半功倍的效果。这块的内容比较多，又比较重要，但我们没办法一一展开，只说最核心的优化点。

先看个 JVM 内存模型以及常用配置，如下图所示：

其实针对 JVM 的优化，我们最关心的无非就两个问题，一个是垃圾回收器怎么选择，另一个就是对选择的垃圾回收器如何做优化。这里我们分别讲一下。

对于垃圾回收器的选择，是需要分业务场景的。如果我们提供的服务对响应时间敏感，并且堆内存能够给到 8G 以上的，那建议选择 G1；堆内存较小或 JDK 版本较低的，可以选择 CMS。相反如果对响应时间不敏感，追求一定的吞吐量的，则建议选择 ParallelGC，同时这也是 JDK8 的默认垃圾回收器。

选择完垃圾回收器之后，接下来就针对不同的垃圾回收器，分别做不同的参数优化。

首先是 ParallelGC，其主要配置参数如下：

然后是 CMS，在 ParallelGC 配置参数的基础上增加以下配置：

再说下 G1 的优化配置（在使用了 G1 的情况下，就不要设置 -Xmn 和 XX:NewRatio 了），同样是在 ParallelGC 配置参数的基础上增加以下配置：

因为我们秒杀的业务场景更适合选择 G1 来做垃圾回收器，那这里也给一个在 8 核 16G 容器下的 JVM 配置，具体如下：

1

-Xms8192m -Xmx8192m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:ParallelGCThreads=8 -XX:ConcGCThreads=4 -XX:G1HeapRegionSize=8m

总结

对于 Tomcat 的优化，在秒杀的特定业务场景下针对线程模型的选择，从理论和实际压测上看，NIO2 比 NIO 是有吐吞量的提升，但不是很大，如果为了省事，选择默认的 NIO 即可。而 APR 的话，因为我们静态资源都上到 CDN 了，并且 Web 服务并不直接对外（请求由 Nginx 转发过来），也不要求是 HTTPS 方式，所以这里也不考虑了，和线程池相关的配置，最好按照这节课中的建议做适当的调整。

同时我们也提到了 Servlet 在 3.0 和 3.1 版本提供的异步非阻塞功能，由于秒杀的接口入参不涉及文件之类的较大消息体，所以 IO 非阻塞可以不用。而异步功能这块，其实可以有更好的选择，那就是 Vertx 技术，这也是我们在下节课中，将会单独介绍的一种异步化编程思想技术。

而对于 RPC 框架，我们主要介绍了基于 NIO 开发的一种网络通信框架 Netty，了解了 Netty 主要使用两个池子，即使用 Boss Pool 和 Worker Pool 来实现 Reactor 模式。同时选择了一个具体的 RPC 框架 Dubbo，来做了详细的配置优化讲解。

在聊完了两种服务的底层线程模型与优化后，我们介绍了静态资源的优化方案，即将静态资源上到 CDN，以减轻对秒杀域名流量的压力，同时可以依靠 CDN 的全国部署，快速加载到对应的静态资源。

另外，我们还提到了 Java 运行的环境 JVM，包括垃圾回收器的选择与优化，即如果我们提供的服务对响应时间敏感，并且堆内存能够给到 8G 以上的，那就选择 G1；而堆内存较小或 JDK 版本较低的，可以选择 CMS。相反如果对响应时间不敏感，追求一定的吞吐量的，则建议选择 ParallelGC。同时针对不同的垃圾回收器，也给出了对应的优化配置。

通过优化数据类型、合理增加冗余字段、拆分表和使用非空约束等方法，来改进表的设计，从而提高查询性能。

数据类型优化

在改进表的设计时，首先可以考虑优化字段的数据类型。下面我就来讲解 2 种方法，一种是针对整数类型数据，尽量使用小的整数类型来定义；另外一种是，如果字段既可以用文本类型，也可以用整数类型，尽量使用整数类型。

先说第一种方法，对整数类型数据进行优化。

遇到整数类型的字段可以用 INT 型。这样做的理由是，INT 型数据有足够大的取值范围，不用担心数据超出取值范围的问题。刚开始做项目的时候，首先要保证系统的稳定性，这样设计字段类型是可以的。

但是，随着你的经验越来越丰富，参与的项目越来越大，数据量也越来越多的时候，你就不能只从系统稳定性的角度来思考问题了，还要考虑到系统整体的效率。

这是因为，在数据量很大的时候，数据类型的定义，在很大程度上会影响到系统整体的执行效率。这个时候，你就必须同时考虑稳定性和效率。

第 2 种优化方法，就是既可以使用文本类型也可以使用整数类型的字段，要使用整数类型，而不要用文本类型。

跟文本类型数据相比，大整数往往占用更少的存储空间，因此，在存取和比对的时候，可以占用更少的内存。所以，遇到既可以使用文本类型，又可以使用整数类型来定义的字段，尽量使用整数类型，这样可以提高查询的效率。

在 demo.test1 中，我给商品编号设定的数据类型是 MEDIUMINT，给流水唯一编号设定的数据类型是 BIGINT。

这样设定的原因是，MEDIUMINT 类型的取值范围是“无符号数 0 – 16777215”。对于商品编号来说，其实够用了。我的 400 万条数据中没有超过这个范围的值。而流水唯一编号是一个长度为 18 位的数字，用字符串数据类型 TEXT 肯定是可以的，大整数类型 BIGINT 的取值范围是“无符号数 0 – 18446744083709551616”，有 20 位，所以，用大整数类型数据来定义流水唯一编号，也是可以的。

原来，INT 类型占用 4 个字节存储空间，而 MEDIUMINT 类型只占用 3 个字节的存储空间，比 INT 类型节省了 25% 的存储空间。demo.test1 的第一个字段的数据类型是 MEDIUMINT，demo.test 的第一个字段的数据类型是 INT。因此，我们来对比下两个表的第一个字段 ，demo.test1 占用的存储空间就比 demo.test 节省了 25%。

再来看看这两个表的第二个字段：流水唯一编号 transuniqueid。在 demo.test 中，这个字段的类型是 TEXT，而 TEXT 类型占用的字节数等于“实际字符串长度 + 2”，在咱们的这个场景中，流水唯一编号的长度是 18，所占用的存储空间就是 20 个字节。在 demo.test1 中，流水唯一编号的数据类型是 BIGINT，占用的存储空间就是 8 个字节。这样一来，demo.test1 在第二个字段上面占用的存储空间就比 demo.test 节省了（20-8）÷20=60%。很明显，对于流水唯一编号字段，demo.test1 比 demo.test 更加节省空间。

因此，我建议你，遇到数据量大的项目时，一定要在充分了解业务需求的前提下，合理优化数据类型，这样才能充分发挥资源的效率，使系统达到最优。

合理增加冗余字段以提高效率

在数据量大，而且需要频繁进行连接的时候，为了提升效率，我们也可以考虑增加冗余字段来减少连接。

不过，你要注意的一点是，这样一来，商品流水表中包含了一个冗余字段“商品名称”，不但存储空间变大了，而且，如果某个商品名称做了修改，一定要对应修改流水表里的商品名称。否则，就会出现两个表里的商品名称不一致的情况。

所以，在实际的工作场景中，你需要权衡增加冗余字段的利与弊。这里给你一个建议：增加冗余字段一定要符合 2 个条件，第一个是，这个冗余字段不需要经常进行修改；第二个是，这个冗余字段查询的时候不可或缺。只有满足这两个条件，才可以考虑增加冗余字段，否则就不值得增加这个冗余字段了。

拆分表

跟刚刚的在表中增加冗余字段的方法相反，拆分表的思路是，把 1 个包含很多字段的表拆分成 2 个或者多个相对较小的表。

这样做的原因是，这些表中某些字段的操作频率很高，经常要进行查询或者更新操作，而另外一些字段的使用频率却很低，如果放在一个表里面，每次查询都要读取大记录，会消耗较多的资源。

这个时候，如果把这个大表拆分开，把使用频率高的字段放在一起形成一个表，把剩下的使用频率低的字段放在一起形成一个表，这样查询操作每次读取的记录比较小，查询效率自然也就提高了。

使用非空约束

在设计字段的时候，如果业务允许，我建议你尽量使用非空约束。这样做的好处是，可以省去判断是否为空的开销，提高存储效率。而且，非空字段也容易创建索引。使用非空约束，甚至可以节省存储空间（每个字段 1 个比特）。

这样一来，我们就省去了判断空值的开销，还能够节省一些存储空间。

总结

• 修改数据类型以节省存储空间；
• 在利大于弊的情况下增加冗余字段；
• 把大表中查询频率高的字段和查询频率低的字段拆分成不同的表；
• 尽量使用非空约束。

但是，我要提醒你的是，这些方法都是有利有弊的，比如，修改数据类型，节省存储空间的同时，你要考虑到数据不能超过取值范围；增加冗余字段的时候，不要忘了确保数据一致性；把大表拆分，也意味着你的查询会增加新的连接，从而增加额外的开销和运维的成本。因此，你一定要结合实际的业务需求进行权衡。

kubernetes默认调度器的调度过程

调度过程如下：

• 预选（Predicates）
• 优选（Priorities）
• 选定（Select）

节点亲和性和pod亲和性的区别

举个例子，假设给小明分配班级（小明是pod，班级是节点）

• 节点亲和性：直接告诉小明，你去一年级
• pod亲和性：从小朋友中找出和小明同年的，找到了小张，发现小张是一年级的，于是让小明去一年级

节点亲和性：硬亲和性

• requiredDuringSchedulinglgnoredDuringExecution：用于定义节点硬亲和性
• nodeSelectorTerm：节点选择器，可以有多个，之间的关系是逻辑或，即一个nodeSelectorTerm满足即可
• matchExpressions：匹配规则定义，多个之间的关系是逻辑与，即同一个nodeSelectorTerm下所有matchExpressions定义的规则都匹配，才算匹配成功

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apiVersion: v1
kind: Pod
metadata:
  name: with-required-nodeaffinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - {key: zone, operator: In, values: ["foo"]}
  containers:
  - name: nginx
    image: nginx

• 功能与nodeSelector类似，用的是匹配表达式，可以被理解为新一代节点选择器
• 不满足硬亲和性条件时，pod为Pending状态
• 在预选阶段，节点硬亲和性被用于预选策略MatchNodeSelector

节点亲和性：软亲和性

特点：条件不满足时也能被调度

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy-with-node-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 60
            preference:
              matchExpressions:
              - {key: zone, operator: In, values: ["foo"]}
          - weight: 30
            preference:
              matchExpressions:
              - {key: ssd, operator: Exists, values: []}
      containers:
      - name: nginx
        image: nginx

• 集群中的节点，由于标签不同，导致的优先级结果如下：

• 在优选阶段，节点软亲和性被用于优选函数NodeAffinityPriority
• 注意：NodeAffinityPriority并非决定性因素，因为优选阶段还会调用其他优选函数，例如SelectorSpreadPriority（将pod分散到不同节点以分散节点故障导致的风险）
• pod副本数增加时，分布的比率会参考节点亲和性的权重

Pod亲和性（podAffinity）

• 如果需求是：新增的pod要和已经存在pod(假设是A)在同一node上，此时用节点亲和性是无法完成的，因为A可能和节点没啥关系(可能是随机调度的)，此时只能用pod亲和性来实现

• pod亲和性：一个pod与已经存在的某个pod的亲和关系，需要通过举例来说明

创建一个deployment，这个pod有标签app=tomcat：

1

kubectl run tomcat -l app=tomcat --image tomcat:alpine

创建pod，需求是和前面的pod在一起，使用pod亲和性来实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity-1
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - {key: app, operator: In, values: ["tomcat"]}
        topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx

调度逻辑:

1
2
3

A[1. 用matchExpressions的规则app=tomcat搜索] -->B(2. 找到tomcat的pod,也就确定了该pod的节点,假设是A节点)
B --> C(3. topologyKey是kubernetes.io/hostname,所以去找A节点kubernetes.io/hostname标签的值,假设是xxx)
C --> D(4. 将新的pod调度到kubernetes.io/hostname=xxx的节点)

硬亲和：requiredDuringSchedulingIgnoredDuringExecution
软亲和：preferredDuringSchedulingIgnoredDuringExecution

Pod反亲和（podAntiAffinity）

• 与亲和性相反，将当前pod调度到满足匹配条件之外的节点上

• 适用场景：

  • 分散同一类应用
  • 将不同安全级别的pod调度至不同节点

• 示例如下，匹配表达式和自身标签一致，作用是分散同一类应用，让相同pod不要调度到同一个节点：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

  apiVersion: apps/v1 kind: Deployment metadata: name: myapp-with-pod-anti-affinity spec: replicas: 4 selector: matchLabels: app: myapp template: metadata: name: myapp labels: app: myapp spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - {key: app, operator: In, values: ["myapp"]} topologyKey: kubernetes.io/hostname containers: - name: nginx image: nginx

• 如果集群中只有三个节点，那么执行上述yaml的结果就是最多创建三个pod，另一个始终处于pending状态

参考

本篇笔记参考了以下文章，两张图片也来自该文章，致敬作者

1

https://mp.weixin.qq.com/s/AaiX_7j97_V-TeIiUBU73Q

JVM

类加载

类加载过程

加载->验证(符合jvm规范)->准备(分配内存空间)->解析(符号引用替换为直接引用)->初始化(赋值的代码初始化时执行)->使用->卸载

1. 啥时候去加载一个类？当代码中使用到这个类的时候
2. JVM进程启动后被加载
3. 双亲委派机制：先找父亲去加载，没找到的话，就下推到给儿子，在其负责的目录中的类中找。启动类加载器-扩展类加载器-应用程序类加载器-自定义类加载器

双亲委派机制

双亲委派机制定义：当一个类加载器收到了类加载的请求的时候，他不会直接去加载指定的类，而是把这个请求委托给自己的父加载器去加载。只有父加载器无法加载这个类的时候，才会由当前这个加载器来负责类的加载。

简单说下实现流程：

1
2
3
4
5
6
7

1. 首先判断该类是否已经被加载

2.该类未被加载，如果父类不为空，交给父类加载

3.如果父类为空，交给bootstrap classloader 加载

4.如果类还是无法被加载到，则触发findclass,抛出classNotFoundException(findclass这个方法当前只有一个语句，就是抛出classNotFoundException），如果想自己实现类加载器的话，可以继承classLoader后重写findclass方法，加载对应的类）

启动JVM进程后，自带一个垃圾回收的后台线程

Tomcat

Tomcat自定义了Common、Catalina、Shared等类加载器，其实为了加载其自身的核心基础类库。然后tomcat为每个部署在里面的Web应用都用一个对应的WebApp类加载器，负责加载我们部署的应用的类。

每个WebApp负责加载自己对应的那个web应用的class文件，不会传导给上层类加载器去加载。

String

String类型

String 是引用类型，最为显著的一个特点就是它具有恒定不变性，但是值传递，传递的是地址的值，所有的变量都可以说是值传递，就看是什么类型，引用类型，传递的值是地址的值，值类型传递的是变量的赋值。string是引用类型，只是编译器对其做了特殊处理。

字符串拼接

即使使用 + 号作为字符串的拼接，也一样可以被编译器优化成 StringBuilder 的方式。但再细致些，你会发现在编译器优化的代码中，每次循环都会生成一个新的 StringBuilder 实例，同样也会降低系统的性能。

所以平时做字符串拼接的时候，我建议你还是要显示地使用 String Builder 来提升系统性能。

如果在多线程编程中，String 对象的拼接涉及到线程安全，你可以使用 StringBuffer。但是要注意，由于 StringBuffer 是线程安全的，涉及到锁竞争，所以从性能上来说，要比 StringBuilder 差一些。

如何使用 String.intern 节省内存

使用 String.intern 来节省内存空间，从而优化 String 对象的存储。

具体做法就是，在每次赋值的时候使用 String 的 intern 方法，如果常量池中有相同值，就会重复使用该对象，返回对象引用，这样一开始的对象就可以被回收掉。这种方式可以使重复性非常高的地址信息存储大小从 20G 降到几百兆。

1
2
3
4
5
6
7
8
9
10

SharedLocation sharedLocation = new SharedLocation();

sharedLocation.setCity(messageInfo.getCity().intern());    sharedLocation.setCountryCode(messageInfo.getRegion().intern());
sharedLocation.setRegion(messageInfo.getCountryCode().intern());

Location location = new Location();
location.set(sharedLocation);
location.set(messageInfo.getLongitude());
location.set(messageInfo.getLatitude());

在字符串常量中，默认会将对象放入常量池；在字符串变量中，对象是会创建在堆内存中，同时也会在常量池中创建一个字符串对象，String 对象中的 char 数组将会引用常量池中的 char 数组，并返回堆内存对象引用。

如果调用 intern 方法，会去查看字符串常量池中是否有等于该对象的字符串的引用，如果没有，在 JDK1.6 版本中会复制堆中的字符串到常量池中，并返回该字符串引用，堆内存中原有的字符串由于没有引用指向它，将会通过垃圾回收器回收。

在 JDK1.7 版本以后，由于常量池已经合并到了堆中，所以不会再复制具体字符串了，只是会把首次遇到的字符串的引用添加到常量池中；如果有，就返回常量池中的字符串引用。

在一开始字符串”abc”会在加载类时，在常量池中创建一个字符串对象。

1
2
3
4
5
6
7

String a =new String("abc").intern();
String b = new String("abc").intern();

if(a==b) {//true
    System.out.print("a==b");
}

创建 a 变量时，调用 new Sting() 会在堆内存中创建一个 String 对象，String 对象中的 char 数组将会引用常量池中字符串。在调用 intern 方法之后，会去常量池中查找是否有等于该字符串对象的引用，有就返回引用。

创建 b 变量时，调用 new Sting() 会在堆内存中创建一个 String 对象，String 对象中的 char 数组将会引用常量池中字符串。在调用 intern 方法之后，会去常量池中查找是否有等于该字符串对象的引用，有就返回引用。

而在堆内存中的两个对象，由于没有引用指向它，将会被垃圾回收。所以 a 和 b 引用的是同一个对象。

而在堆内存中的两个对象，由于没有引用指向它，将会被垃圾回收。所以 a 和 b 引用的是同一个对象。

如果在运行时，创建字符串对象，将会直接在堆内存中创建，不会在常量池中创建。所以动态创建的字符串对象，调用 intern 方法，在 JDK1.6 版本中会去常量池中创建运行时常量以及返回字符串引用，在 JDK1.7 版本之后，会将堆中的字符串常量的引用放入到常量池中，当其它堆中的字符串对象通过 intern 方法获取字符串对象引用时，则会去常量池中判断是否有相同值的字符串的引用，此时有，则返回该常量池中字符串引用，跟之前的字符串指向同一地址的字符串对象。

使用 intern 方法需要注意的一点是，一定要结合实际场景。因为常量池的实现是类似于一个 HashTable 的实现方式，HashTable 存储的数据越大，遍历的时间复杂度就会增加。如果数据过大，会增加整个字符串常量池的负担。

如何使用字符串的分割方法

最后我想跟你聊聊字符串的分割，这种方法在编码中也很最常见。Split() 方法使用了正则表达式实现了其强大的分割功能，而正则表达式的性能是非常不稳定的，使用不恰当会引起回溯问题，很可能导致 CPU 居高不下。

所以我们应该慎重使用 Split() 方法，我们可以用 String.indexOf() 方法代替 Split() 方法完成字符串的分割。如果实在无法满足需求，你就在使用 Split() 方法时，对回溯问题加以重视就可以了。

Stream如何提高遍历集合效率

List 集合类，那我想你一定也知道集合的顶端接口 Collection。在 Java8 中，Collection 新增了两个流方法，分别是 Stream() 和 parallelStream()

Stream

在 Java8 之前，我们通常是通过 for 循环或者 Iterator 迭代来重新排序合并数据，又或者通过重新定义 Collections.sorts 的 Comparator 方法来实现，这两种方式对于大数据量系统来说，效率并不是很理想。

Java8 中添加了一个新的接口类 Stream，他和我们之前接触的字节流概念不太一样，Java8 集合中的 Stream 相当于高级版的 Iterator，他可以通过 Lambda 表达式对集合进行各种非常便利、高效的聚合操作（Aggregate Operation），或者大批量数据操作 (Bulk Data Operation)。

Stream 的聚合操作与数据库 SQL 的聚合操作 sorted、filter、map 等类似。我们在应用层就可以高效地实现类似数据库 SQL 的聚合操作了，而在数据操作方面，Stream 不仅可以通过串行的方式实现数据操作，还可以通过并行的方式处理大批量数据，提高数据的处理效率。

替换for循环或迭代循环的实现，Stream API 进行实现：

串行实现:

1

Map<String, List<Student>> stuMap = stuList.stream().filter((Student s) -> s.getHeight() > 160) .collect(Collectors.groupingBy(Student ::getSex));

并行实现：

1

Map<String, List<Student>> stuMap = stuList.parallelStream().filter((Student s) -> s.getHeight() > 160) .collect(Collectors.groupingBy(Student ::getSex));

通过上面两个简单的例子，我们可以发现，Stream 结合 Lambda 表达式实现遍历筛选功能非常得简洁和便捷。

Stream 是如何优化遍历的

我们通常还会将中间操作称为懒操作，也正是由这种懒操作结合终结操作、数据源构成的处理管道（Pipeline），实现了 Stream 的高效。

深入浅出HashMap的设计与优化

常用的数据结构

• 数组：采用一段连续的存储单元来存储数据。对于指定下标的查找，时间复杂度为 O(1)，但在数组中间以及头部插入数据时，需要复制移动后面的元素。
• 链表：一种在物理存储单元上非连续、非顺序的存储结构，数据元素的逻辑顺序是通过链表中的指针链接次序实现的。链表由一系列结点（链表中每一个元素）组成，结点可以在运行时动态生成。每个结点都包含“存储数据单元的数据域”和“存储下一个结点地址的指针域”这两个部分。由于链表不用必须按顺序存储，所以链表在插入的时候可以达到 O(1) 的复杂度，但查找一个结点或者访问特定编号的结点需要 O(n) 的时间。
• 哈希表：根据关键码值（Key value）直接进行访问的数据结构。通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做哈希函数，存放记录的数组就叫做哈希表。
• 树：由 n（n≥1）个有限结点组成的一个具有层次关系的集合，就像是一棵倒挂的树。

HashMap 的实现结构

作为最常用的 Map 类，它是基于哈希表实现的，继承了 AbstractMap 并且实现了 Map 接口。

哈希表将键的 Hash 值映射到内存地址，即根据键获取对应的值，并将其存储到内存地址。也就是说 HashMap 是根据键的 Hash 值来决定对应值的存储位置。通过这种索引方式，HashMap 获取数据的速度会非常快。

但也会有新的问题。如果再来一个 (y，“bb”)，哈希函数 f(y) 的哈希值跟之前 f(x) 是一样的，这样两个对象的存储地址就冲突了，这种现象就被称为哈希冲突。那么哈希表是怎么解决的呢？方式有很多，比如，开放定址法、再哈希函数法和链地址法。

开放定址法很简单，当发生哈希冲突时，如果哈希表未被装满，说明在哈希表中必然还有空位置，那么可以把 key 存放到冲突位置后面的空位置上去。这种方法存在着很多缺点，例如，查找、扩容等，所以我不建议你作为解决哈希冲突的首选。

再哈希法顾名思义就是在同义词产生地址冲突时再计算另一个哈希函数地址，直到冲突不再发生，这种方法不易产生“聚集”，但却增加了计算时间。如果我们不考虑添加元素的时间成本，且对查询元素的要求极高，就可以考虑使用这种算法设计。

HashMap 则是综合考虑了所有因素，采用链地址法解决哈希冲突问题。这种方法是采用了数组（哈希表）+ 链表的数据结构，当发生哈希冲突时，就用一个链表结构存储相同 Hash 值的数据。

HashMap 添加元素优化

在 JDK1.8 中，HashMap 引入了红黑树数据结构来提升链表的查询效率。

这是因为链表的长度超过 8 后，红黑树的查询效率要比链表高，所以当链表超过 8 时，HashMap 就会将链表转换为红黑树，这里值得注意的一点是，这时的新增由于存在左旋、右旋效率会降低。讲到这里，我前面我提到的“因链表过长而导致的查询时间复杂度高”的问题，也就迎刃而解了。

HashMap 获取元素优化

当 HashMap 中只存在数组，而数组中没有 Node 链表时，是 HashMap 查询数据性能最好的时候。一旦发生大量的哈希冲突，就会产生 Node 链表，这个时候每次查询元素都可能遍历 Node 链表，从而降低查询数据的性能。

特别是在链表长度过长的情况下，性能将明显降低，红黑树的使用很好地解决了这个问题，使得查询的平均复杂度降低到了 O(log(n))，链表越长，使用黑红树替换后的查询效率提升就越明显。

我们在编码中也可以优化 HashMap 的性能，例如，重写 key 值的 hashCode() 方法，降低哈希冲突，从而减少链表的产生，高效利用哈希表，达到提高性能的效果。

HashMap 扩容优化

HashMap 也是数组类型的数据结构，所以一样存在扩容的情况。

在 JDK1.7 中，HashMap 整个扩容过程就是分别取出数组元素，一般该元素是最后一个放入链表中的元素，然后遍历以该元素为头的单向链表元素，依据每个被遍历元素的 hash 值计算其在新数组中的下标，然后进行交换。这样的扩容方式会将原来哈希冲突的单向链表尾部变成扩容后单向链表的头部。

而在 JDK 1.8 中，HashMap 对扩容操作做了优化。由于扩容数组的长度是 2 倍关系，所以对于假设初始 tableSize = 4 要扩容到 8 来说就是 0100 到 1000 的变化（左移一位就是 2 倍），在扩容中只用判断原来的 hash 值和左移动的一位（newtable 的值）按位与操作是 0 或 1 就行，0 的话索引不变，1 的话索引变成原索引加上扩容前数组。

之所以能通过这种“与运算“来重新分配索引，是因为 hash 值本来就是随机的，而 hash 按位与上 newTable 得到的 0（扩容前的索引位置）和 1（扩容前索引位置加上扩容前数组长度的数值索引处）就是随机的，所以扩容的过程就能把之前哈希冲突的元素再随机分布到不同的索引中去。

总结

HashMap 通过哈希表数据结构的形式来存储键值对，这种设计的好处就是查询键值对的效率高。

我们在使用 HashMap 时，可以结合自己的场景来设置初始容量和加载因子两个参数。当查询操作较为频繁时，我们可以适当地减少加载因子；如果对内存利用率要求比较高，我可以适当的增加加载因子。

我们还可以在预知存储数据量的情况下，提前设置初始容量（初始容量 = 预知数据量 / 加载因子）。这样做的好处是可以减少 resize() 操作，提高 HashMap 的效率。

HashMap 还使用了数组 + 链表这两种数据结构相结合的方式实现了链地址法，当有哈希值冲突时，就可以将冲突的键值对链成一个链表。

但这种方式又存在一个性能问题，如果链表过长，查询数据的时间复杂度就会增加。HashMap 就在 Java8 中使用了红黑树来解决链表过长导致的查询性能下降问题。以下是 HashMap 的数据结构图：

实际应用中，我们设置初始容量，一般得是 2 的整数次幂。你知道原因吗？

2的幂次方减1后每一位都是1，让数组每一个位置都能添加到元素。
例如十进制8，对应二进制1000，减1是0111，这样在&hash值使数组每个位置都是可以添加到元素的，如果有一个位置为0，那么无论hash值是多少那一位总是0，例如0101，&hash后第二位总是0，也就是说数组中下标为2的位置总是空的。
如果初始化大小设置的不是2的幂次方，hashmap也会调整到比初始化值大且最近的一个2的幂作为capacity。

• 1）通过将 Key 的 hash 值与 length-1 进行 & 运算，实现了当前 Key 的定位，2 的幂次方可以减少冲突（碰撞）的次数，提高 HashMap 查询效率；

• 2）如果 length 为 2 的次幂，则 length-1 转化为二进制必定是 11111…… 的形式，在于 h 的二进制与操作效率会非常的快，而且空间不浪费；如果 length 不是 2 的次幂，比如 length 为 15，则 length-1 为 14，对应的二进制为 1110，在于 h 与操作，最后一位都为 0，而 0001，0011，0101，1001，1011，0111，1101 这几个位置永远都不能存放元素了，空间浪费相当大，更糟的是这种情况中，数组可以使用的位置比数组长度小了很多，这意味着进一步增加了碰撞的几率，减慢了查询的效率！这样就会造成空间的浪费。

网络通信优化之I/O模型：如何解决高并发下I/O瓶颈

在计算机中，流是一种信息的转换。流是有序的，因此相对于某一机器或者应用程序而言，我们通常把机器或者应用程序接收外界的信息称为输入流（InputStream），从机器或者应用程序向外输出的信息称为输出流（OutputStream），合称为输入 / 输出流（I/O Streams）。

不管是文件读写还是网络发送接收，信息的最小存储单元都是字节，那为什么 I/O 流操作要分为字节流操作和字符流操作呢？

我们知道字符到字节必须经过转码，这个过程非常耗时，如果我们不知道编码类型就很容易出现乱码问题。所以 I/O 流提供了一个直接操作字符的接口，方便我们平时对字符进行流操作。

传统 I/O 的性能问题

1. 多次内存复制

在传统 I/O 中，我们可以通过 InputStream 从源数据中读取数据流输入到缓冲区里，通过 OutputStream 将数据输出到外部设备（包括磁盘、网络）。

• JVM 会发出 read() 系统调用，并通过 read 系统调用向内核发起读请求；
• 内核向硬件发送读指令，并等待读就绪；
• 内核把将要读取的数据复制到指向的内核缓存中；
• 操作系统内核将数据复制到用户空间缓冲区，然后 read 系统调用返回。

在这个过程中，数据先从外部设备复制到内核空间，再从内核空间复制到用户空间，这就发生了两次内存复制操作。这种操作会导致不必要的数据拷贝和上下文切换，从而降低 I/O 的性能。

2. 阻塞

在传统 I/O 中，InputStream 的 read() 是一个 while 循环操作，它会一直等待数据读取，直到数据就绪才会返回。这就意味着如果没有数据就绪，这个读取操作将会一直被挂起，用户线程将会处于阻塞状态。

在少量连接请求的情况下，使用这种方式没有问题，响应速度也很高。但在发生大量连接请求时，就需要创建大量监听线程，这时如果线程没有数据就绪就会被挂起，然后进入阻塞状态。一旦发生线程阻塞，这些线程将会不断地抢夺 CPU 资源，从而导致大量的 CPU 上下文切换，增加系统的性能开销。

如何优化 I/O 操作

1. 使用缓冲区优化读写流操作

NIO 与传统 I/O 不同，它是基于块（Block）的，它以块为基本单位处理数据。在 NIO 中，最为重要的两个组件是缓冲区（Buffer）和通道（Channel）。Buffer 是一块连续的内存块，是 NIO 读写数据的中转地。Channel 表示缓冲数据的源头或者目的地，它用于读取缓冲或者写入数据，是访问缓冲的接口。

传统 I/O 和 NIO 的最大区别就是传统 I/O 是面向流，NIO 是面向 Buffer。Buffer 可以将文件一次性读入内存再做后续处理，而传统的方式是边读文件边处理数据。虽然传统 I/O 后面也使用了缓冲块，例如 BufferedInputStream，但仍然不能和 NIO 相媲美。使用 NIO 替代传统 I/O 操作，可以提升系统的整体性能，效果立竿见影。

2. 使用 DirectBuffer 减少内存复制

NIO 的 Buffer 除了做了缓冲块优化之外，还提供了一个可以直接访问物理内存的类 DirectBuffer。普通的 Buffer 分配的是 JVM 堆内存，而 DirectBuffer 是直接分配物理内存 (非堆内存)。

DirectBuffer 则是直接将步骤简化为数据直接保存到非堆内存，从而减少了一次数据拷贝。

由于 DirectBuffer 申请的是非 JVM 的物理内存，所以创建和销毁的代价很高。DirectBuffer 申请的内存并不是直接由 JVM 负责垃圾回收，但在 DirectBuffer 包装类被回收时，会通过 Java Reference 机制来释放该内存块。

DirectBuffer 只优化了用户空间内部的拷贝，而之前我们是说优化用户空间和内核空间的拷贝，那 Java 的 NIO 中是否能做到减少用户空间和内核空间的拷贝优化呢？
答案是可以的，DirectBuffer 是通过 unsafe.allocateMemory(size) 方法分配内存，也就是基于本地类 Unsafe 类调用 native 方法进行内存分配的。而在 NIO 中，还存在另外一个 Buffer 类：MappedByteBuffer，跟 DirectBuffer 不同的是，MappedByteBuffer 是通过本地类调用 mmap 进行文件内存映射的，map() 系统调用方法会直接将文件从硬盘拷贝到用户空间，只进行一次数据拷贝，从而减少了传统的 read() 方法从硬盘拷贝到内核空间这一步。

3. 避免阻塞，优化 I/O 操作

NIO 发布后，通道和多路复用器这两个基本组件实现了 NIO 的非阻塞。

• 通道（Channel）：Channel 有自己的处理器，可以完成内核空间和磁盘之间的 I/O 操作。在 NIO 中，我们读取和写入数据都要通过 Channel，由于 Channel 是双向的，所以读、写可以同时进行。

• 多路复用器（Selector）：Selector 是 Java NIO 编程的基础。用于检查一个或多个 NIO Channel 的状态是否处于可读、可写。

Selector 是基于事件驱动实现的，我们可以在 Selector 中注册 accpet、read 监听事件，Selector 会不断轮询注册在其上的 Channel，如果某个 Channel 上面发生监听事件，这个 Channel 就处于就绪状态，然后进行 I/O 操作。

一个线程使用一个 Selector，通过轮询的方式，可以监听多个 Channel 上的事件。我们可以在注册 Channel 时设置该通道为非阻塞，当 Channel 上没有 I/O 操作时，该线程就不会一直等待了，而是会不断轮询所有 Channel，从而避免发生阻塞。

目前操作系统的 I/O 多路复用机制都使用了 epoll，相比传统的 select 机制，epoll 没有最大连接句柄 1024 的限制。所以 Selector 在理论上可以轮询成千上万的客户端。

索引节点和目录项

文件系统，本身是对存储设备上的文件，进行组织管理的机制。组织方式不同，就会形成不同的文件系统。

在 Linux 中一切皆文件。不仅普通的文件和目录，就连块设备、套接字、管道等，也都要通过统一的文件系统来管理。

为了方便管理，Linux 文件系统为每个文件都分配两个数据结构，索引节点（index node）和目录项（directory entry）。它们主要用来记录文件的元信息和目录结构。

• 索引节点，简称为 inode，用来记录文件的元数据，比如 inode 编号、文件大小、访问权限、修改日期、数据的位置等。索引节点和文件一一对应，它跟文件内容一样，都会被持久化存储到磁盘中。所以记住，索引节点同样占用磁盘空间。

• 目录项，简称为 dentry，用来记录文件的名字、索引节点指针以及与其他目录项的关联关系。多个关联的目录项，就构成了文件系统的目录结构。不过，不同于索引节点，目录项是由内核维护的一个内存数据结构，所以通常也被叫做目录项缓存。

换句话说，索引节点是每个文件的唯一标志，而目录项维护的正是文件系统的树状结构。目录项和索引节点的关系是多对一，你可以简单理解为，一个文件可以有多个别名。

• 第一，目录项本身就是一个内存缓存，而索引节点则是存储在磁盘中的数据。在前面的 Buffer 和 Cache 原理中，我曾经提到过，为了协调慢速磁盘与快速 CPU 的性能差异，文件内容会缓存到页缓存 Cache 中。
• 第二，磁盘在执行文件系统格式化时，会被分成三个存储区域，超级块、索引节点区和数据块区。其中，
  • 超级块，存储整个文件系统的状态。
  • 索引节点区，用来存储索引节点。
  • 数据块区，则用来存储文件数据。

虚拟文件系统

目录项、索引节点、逻辑块以及超级块，构成了 Linux 文件系统的四大基本要素。不过，为了支持各种不同的文件系统，Linux 内核在用户进程和文件系统的中间，又引入了一个抽象层，也就是虚拟文件系统 VFS（Virtual File System）。

VFS 定义了一组所有文件系统都支持的数据结构和标准接口。这样，用户进程和内核中的其他子系统，只需要跟 VFS 提供的统一接口进行交互就可以了，而不需要再关心底层各种文件系统的实现细节。

这里，我画了一张 Linux 文件系统的架构图，帮你更好地理解系统调用、VFS、缓存、文件系统以及块存储之间的关系。

通过这张图，你可以看到，在 VFS 的下方，Linux 支持各种各样的文件系统，如 Ext4、XFS、NFS 等等。按照存储位置的不同，这些文件系统可以分为三类。

• 第一类是基于磁盘的文件系统，也就是把数据直接存储在计算机本地挂载的磁盘中。常见的 Ext4、XFS、OverlayFS 等，都是这类文件系统。

• 第二类是基于内存的文件系统，也就是我们常说的虚拟文件系统。这类文件系统，不需要任何磁盘分配存储空间，但会占用内存。我们经常用到的 /proc 文件系统，其实就是一种最常见的虚拟文件系统。此外，/sys 文件系统也属于这一类，主要向用户空间导出层次化的内核对象。

• 第三类是网络文件系统，也就是用来访问其他计算机数据的文件系统，比如 NFS、SMB、iSCSI 等。

这些文件系统，要先挂载到 VFS 目录树中的某个子目录（称为挂载点），然后才能访问其中的文件。拿第一类，也就是基于磁盘的文件系统为例，在安装系统时，要先挂载一个根目录（/），在根目录下再把其他文件系统（比如其他的磁盘分区、/proc 文件系统、/sys 文件系统、NFS 等）挂载进来。

文件系统I/O

把文件系统挂载到挂载点后，你就能通过挂载点，再去访问它管理的文件了。VFS 提供了一组标准的文件访问接口。这些接口以系统调用的方式，提供给应用程序使用。

就拿 cat 命令来说，它首先调用 open() ，打开一个文件；然后调用 read() ，读取文件的内容；最后再调用 write() ，把文件内容输出到控制台的标准输出中：

1
2
3

int open(const char *pathname, int flags, mode_t mode);
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);

文件读写方式的各种差异，导致 I/O 的分类多种多样。最常见的有，缓冲与非缓冲 I/O、直接与非直接 I/O、阻塞与非阻塞 I/O、同步与异步 I/O 等。 接下来，我们就详细看这四种分类。

第一种，根据是否利用标准库缓存，可以把文件 I/O 分为缓冲 I/O 与非缓冲 I/O。

• 缓冲 I/O，是指利用标准库缓存来加速文件的访问，而标准库内部再通过系统调度访问文件。
• 非缓冲 I/O，是指直接通过系统调用来访问文件，不再经过标准库缓存。

注意，这里所说的“缓冲”，是指标准库内部实现的缓存。比方说，你可能见到过，很多程序遇到换行时才真正输出，而换行前的内容，其实就是被标准库暂时缓存了起来。

无论缓冲 I/O 还是非缓冲 I/O，它们最终还是要经过系统调用来访问文件。而根据上一节内容，我们知道，系统调用后，还会通过页缓存，来减少磁盘的 I/O 操作。

第二，根据是否利用操作系统的页缓存，可以把文件 I/O 分为直接 I/O 与非直接 I/O。

• 直接 I/O，是指跳过操作系统的页缓存，直接跟文件系统交互来访问文件。
• 非直接 I/O 正好相反，文件读写时，先要经过系统的页缓存，然后再由内核或额外的系统调用，真正写入磁盘。

想要实现直接 I/O，需要你在系统调用中，指定 O_DIRECT 标志。如果没有设置过，默认的是非直接 I/O。

不过要注意，直接 I/O、非直接 I/O，本质上还是和文件系统交互。如果是在数据库等场景中，你还会看到，跳过文件系统读写磁盘的情况，也就是我们通常所说的裸 I/O。

第三，根据应用程序是否阻塞自身运行，可以把文件 I/O 分为阻塞 I/O 和非阻塞 I/O：

• 所谓阻塞 I/O，是指应用程序执行 I/O 操作后，如果没有获得响应，就会阻塞当前线程，自然就不能执行其他任务。
• 所谓非阻塞 I/O，是指应用程序执行 I/O 操作后，不会阻塞当前的线程，可以继续执行其他的任务，随后再通过轮询或者事件通知的形式，获取调用的结果。

比方说，访问管道或者网络套接字时，设置 O_NONBLOCK 标志，就表示用非阻塞方式访问；而如果不做任何设置，默认的就是阻塞访问。

第四，根据是否等待响应结果，可以把文件 I/O 分为同步和异步 I/O：

• 所谓同步 I/O，是指应用程序执行 I/O 操作后，要一直等到整个 I/O 完成后，才能获得 I/O 响应。
• 所谓异步 I/O，是指应用程序执行 I/O 操作后，不用等待完成和完成后的响应，而是继续执行就可以。等到这次 I/O 完成后，响应会用事件通知的方式，告诉应用程序。

举个例子，在操作文件时，如果你设置了 O_SYNC 或者 O_DSYNC 标志，就代表同步 I/O。如果设置了 O_DSYNC，就要等文件数据写入磁盘后，才能返回；而 O_SYNC，则是在 O_DSYNC 基础上，要求文件元数据也要写入磁盘后，才能返回。

再比如，在访问管道或者网络套接字时，设置了 O_ASYNC 选项后，相应的 I/O 就是异步 I/O。这样，内核会再通过 SIGIO 或者 SIGPOLL，来通知进程文件是否可读写。

你可能发现了，这里的好多概念也经常出现在网络编程中。比如非阻塞 I/O，通常会跟 select/poll 配合，用在网络套接字的 I/O 中。

1
2
3
4

查看索引节点信息
$ df -i /dev/sda1
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      3870720 157460 3713260    5% /

索引节点的容量，（也就是 Inode 个数）是在格式化磁盘时设定好的，一般由格式化工具自动生成。当你发现索引节点空间不足，但磁盘空间充足时，很可能就是过多小文件导致的。

所以，一般来说，删除这些小文件，或者把它们移动到索引节点充足的其他磁盘中，就可以解决这个问题。

缓存

在前面 Cache 案例中，我已经介绍过，可以用 free 或 vmstat，来观察页缓存的大小。复习一下，free 输出的 Cache，是页缓存和可回收 Slab 缓存的和，你可以从 /proc/meminfo ，直接得到它们的大小：

1
2
3
4

$ cat /proc/meminfo | grep -E "SReclaimable|Cached"
Cached:           748316 kB
SwapCached:            0 kB
SReclaimable:     179508 kB

话说回来，文件系统中的目录项和索引节点缓存，又该如何观察呢？

实际上，内核使用 Slab 机制，管理目录项和索引节点的缓存。/proc/meminfo 只给出了 Slab 的整体大小，具体到每一种 Slab 缓存，还要查看 /proc/slabinfo 这个文件。

比如，运行下面的命令，你就可以得到，所有目录项和各种文件系统索引节点的缓存情况：

1
2
3
4
5
6
7
8
9
10
11

$ cat /proc/slabinfo | grep -E '^#|dentry|inode'
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
xfs_inode              0      0    960   17    4 : tunables    0    0    0 : slabdata      0      0      0
...
ext4_inode_cache   32104  34590   1088   15    4 : tunables    0    0    0 : slabdata   2306   2306      0hugetlbfs_inode_cache     13     13    624   13    2 : tunables    0    0    0 : slabdata      1      1      0
sock_inode_cache    1190   1242    704   23    4 : tunables    0    0    0 : slabdata     54     54      0
shmem_inode_cache   1622   2139    712   23    4 : tunables    0    0    0 : slabdata     93     93      0
proc_inode_cache    3560   4080    680   12    2 : tunables    0    0    0 : slabdata    340    340      0
inode_cache        25172  25818    608   13    2 : tunables    0    0    0 : slabdata   1986   1986      0
dentry             76050 121296    192   21    1 : tunables    0    0    0 : slabdata   5776   5776      0

这个界面中，dentry 行表示目录项缓存，inode_cache 行，表示 VFS 索引节点缓存，其余的则是各种文件系统的索引节点缓存。

/proc/slabinfo 的列比较多，具体含义你可以查询 man slabinfo。在实际性能分析中，我们更常使用 slabtop ，来找到占用内存最多的缓存类型。

比如，下面就是我运行 slabtop 得到的结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 按下c按照缓存大小排序，按下a按照活跃对象数排序
$ slabtop
Active / Total Objects (% used)    : 277970 / 358914 (77.4%)
Active / Total Slabs (% used)      : 12414 / 12414 (100.0%)
Active / Total Caches (% used)     : 83 / 135 (61.5%)
Active / Total Size (% used)       : 57816.88K / 73307.70K (78.9%)
Minimum / Average / Maximum Object : 0.01K / 0.20K / 22.88K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
69804  23094   0%    0.19K   3324       21     13296K dentry
16380  15854   0%    0.59K   1260       13     10080K inode_cache
58260  55397   0%    0.13K   1942       30      7768K kernfs_node_cache
   485    413   0%    5.69K     97        5      3104K task_struct
  1472   1397   0%    2.00K     92       16      2944K kmalloc-2048

从这个结果你可以看到，在我的系统中，目录项和索引节点占用了最多的 Slab 缓存。不过它们占用的内存其实并不大，加起来也只有 23MB 左右。

进程状态

当 iowait 升高时，进程很可能因为得不到硬件的响应，而长时间处于不可中断状态。从 ps 或者 top 命令的输出中，你可以发现它们都处于 D 状态，也就是不可中断状态（Uninterruptible Sleep）。既然说到了进程的状态，进程有哪些状态你还记得吗？我们先来回顾一下。

top 和 ps 是最常用的查看进程状态的工具，我们就从 top 的输出开始。下面是一个 top 命令输出的示例，S 列（也就是 Status 列）表示进程的状态。从这个示例里，你可以看到 R、D、Z、S、I 等几个状态，它们分别是什么意思呢？

• R 是 Running 或 Runnable 的缩写，表示进程在 CPU 的就绪队列中，正在运行或者正在等待运行。

• D 是 Disk Sleep 的缩写，也就是不可中断状态睡眠（Uninterruptible Sleep），一般表示进程正在跟硬件交互，并且交互过程不允许被其他进程或中断打断。

• Z 是 Zombie 的缩写，如果你玩过“植物大战僵尸”这款游戏，应该知道它的意思。它表示僵尸进程，也就是进程实际上已经结束了，但是父进程还没有回收它的资源（比如进程的描述符、PID 等）。

• S 是 Interruptible Sleep 的缩写，也就是可中断状态睡眠，表示进程因为等待某个事件而被系统挂起。当进程等待的事件发生时，它会被唤醒并进入 R 状态。

• I 是 Idle 的缩写，也就是空闲状态，用在不可中断睡眠的内核线程上。前面说了，硬件交互导致的不可中断进程用 D 表示，但对某些内核线程来说，它们有可能实际上并没有任何负载，用 Idle 正是为了区分这种情况。要注意，D 状态的进程会导致平均负载升高， I 状态的进程却不会。

当然了，上面的示例并没有包括进程的所有状态。除了以上 5 个状态，进程还包括下面这 2 个状态。

第一个是 T 或者 t，也就是 Stopped 或 Traced 的缩写，表示进程处于暂停或者跟踪状态。

向一个进程发送 SIGSTOP 信号，它就会因响应这个信号变成暂停状态（Stopped）；再向它发送 SIGCONT 信号，进程又会恢复运行（如果进程是终端里直接启动的，则需要你用 fg 命令，恢复到前台运行）。

而当你用调试器（如 gdb）调试一个进程时，在使用断点中断进程后，进程就会变成跟踪状态，这其实也是一种特殊的暂停状态，只不过你可以用调试器来跟踪并按需要控制进程的运行。

另一个是 X，也就是 Dead 的缩写，表示进程已经消亡，所以你不会在 top 或者 ps 命令中看到它。

但如果系统或硬件发生了故障，进程可能会在不可中断状态保持很久，甚至导致系统中出现大量不可中断进程。这时，你就得注意下，系统是不是出现了 I/O 等性能问题。

再看僵尸进程，这是多进程应用很容易碰到的问题。正常情况下，当一个进程创建了子进程后，它应该通过系统调用 wait() 或者 waitpid() 等待子进程结束，回收子进程的资源；而子进程在结束时，会向它的父进程发送 SIGCHLD 信号，所以，父进程还可以注册 SIGCHLD 信号的处理函数，异步回收资源。

如果父进程没这么做，或是子进程执行太快，父进程还没来得及处理子进程状态，子进程就已经提前退出，那这时的子进程就会变成僵尸进程。换句话说，父亲应该一直对儿子负责，善始善终，如果不作为或者跟不上，都会导致“问题少年”的出现。

通常，僵尸进程持续的时间都比较短，在父进程回收它的资源后就会消亡；或者在父进程退出后，由 init 进程回收后也会消亡。

一旦父进程没有处理子进程的终止，还一直保持运行状态，那么子进程就会一直处于僵尸状态。大量的僵尸进程会用尽 PID 进程号，导致新进程不能创建，所以这种情况一定要避免。

• 第一点，iowait 太高了，导致系统的平均负载升高，甚至达到了系统 CPU 的个数。
• 第二点，僵尸进程在不断增多，说明有程序没能正确清理子进程的资源。

不可中断状态，表示进程正在跟硬件交互，为了保护进程数据和硬件的一致性，系统不允许其他进程或中断打断这个进程。进程长时间处于不可中断状态，通常表示系统有 I/O 性能问题。

僵尸进程表示进程已经退出，但它的父进程还没有回收子进程占用的资源。短暂的僵尸状态我们通常不必理会，但进程长时间处于僵尸状态，就应该注意了，可能有应用程序没有正常处理子进程的退出。

iowait 分析

推荐安装的 dstat ，它的好处是，可以同时查看 CPU 和 I/O 这两种资源的使用情况，便于对比分析。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 间隔1秒输出10组数据
$ dstat 1 10
You did not select any stats, using -cdngy by default.
--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw
  0   0  96   4   0|1219k  408k|   0     0 |   0     0 |  42   885
  0   0   2  98   0|  34M    0 | 198B  790B|   0     0 |  42   138
  0   0   0 100   0|  34M    0 |  66B  342B|   0     0 |  42   135
  0   0  84  16   0|5633k    0 |  66B  342B|   0     0 |  52   177
  0   3  39  58   0|  22M    0 |  66B  342B|   0     0 |  43   144
  0   0   0 100   0|  34M    0 | 200B  450B|   0     0 |  46   147
  0   0   2  98   0|  34M    0 |  66B  342B|   0     0 |  45   134
  0   0   0 100   0|  34M    0 |  66B  342B|   0     0 |  39   131
  0   0  83  17   0|5633k    0 |  66B  342B|   0     0 |  46   168
  0   3  39  59   0|  22M    0 |  66B  342B|   0     0 |  37   134

从 dstat 的输出，我们可以看到，每当 iowait 升高（wai）时，磁盘的读请求（read）都会很大。这说明 iowait 的升高跟磁盘的读请求有关，很可能就是磁盘读导致的。

1
2
3
4
5
6
7

# -d 展示 I/O 统计数据，-p 指定进程号，间隔 1 秒输出 3 组数据
$ pidstat -d -p 4344 1 3
06:38:50      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
06:38:51        0      4344      0.00      0.00      0.00       0  app
06:38:52        0      4344      0.00      0.00      0.00       0  app
06:38:53        0      4344      0.00      0.00      0.00       0  app

在这个输出中， kB_rd 表示每秒读的 KB 数， kB_wr 表示每秒写的 KB 数，iodelay 表示 I/O 的延迟（单位是时钟周期）。它们都是 0，那就表示此时没有任何的读写，说明问题不是 4344 进程导致的。

看所有的进程的情况:

1
2
3
4
5
6
7
8
9

# 间隔 1 秒输出多组数据 (这里是 20 组)
$ pidstat -d 1 20




perf record -g

perf report

直接读写磁盘，对 I/O 敏感型应用（比如数据库系统）是很友好的，因为你可以在应用中，直接控制磁盘的读写。但在大部分情况下，我们最好还是通过系统缓存来优化磁盘 I/O，换句话说，删除 O_DIRECT 这个选项就是了。

僵尸进程

接下来，我们就来处理僵尸进程的问题。既然僵尸进程是因为父进程没有回收子进程的资源而出现的，那么，要解决掉它们，就要找到它们的根儿，也就是找出父进程，然后在父进程里解决。

父进程的找法我们前面讲过，最简单的就是运行 pstree 命令：

1
2
3
4
5
6
7
8
9
10
11

# -a 表示输出命令行选项
# p表PID
# s表示指定进程的父进程
$ pstree -aps 3084
systemd,1
  └─dockerd,15006 -H fd://
      └─docker-containe,15024 --config /var/run/docker/containerd/containerd.toml
          └─docker-containe,3991 -namespace moby -workdir...
              └─app,4009
                  └─(app,3084)

小结

今天我用一个多进程的案例，带你分析系统等待 I/O 的 CPU 使用率（也就是 iowait%）升高的情况。

虽然这个案例是磁盘 I/O 导致了 iowait 升高，不过， iowait 高不一定代表 I/O 有性能瓶颈。当系统中只有 I/O 类型的进程在运行时，iowait 也会很高，但实际上，磁盘的读写远没有达到性能瓶颈的程度。

因此，碰到 iowait 升高时，需要先用 dstat、pidstat 等工具，确认是不是磁盘 I/O 的问题，然后再找是哪些进程导致了 I/O。

等待 I/O 的进程一般是不可中断状态，所以用 ps 命令找到的 D 状态（即不可中断状态）的进程，多为可疑进程。但这个案例中，在 I/O 操作后，进程又变成了僵尸进程，所以不能用 strace 直接分析这个进程的系统调用。

这种情况下，我们用了 perf 工具，来分析系统的 CPU 时钟事件，最终发现是直接 I/O 导致的问题。这时，再检查源码中对应位置的问题，就很轻松了。

而僵尸进程的问题相对容易排查，使用 pstree 找出父进程后，去查看父进程的代码，检查 wait() / waitpid() 的调用，或是 SIGCHLD 信号处理函数的注册就行了。

java系统优化参数查看

jps

jstat -gcutil pid 100（滚动时间）

jstack -l pid

#堆信息
jmap -histo:live pid

jmap -heap pid

jcmd pid help

jcmd pid VM.version

jcmd pid GC.run

Arthas jvm调优工具

Linux系统资源

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

ps aux --sort -%mem | head -n 7

ps aux --sort -%cpu | head -n 7

df -h

du -h

查看每个目录大小
sudo du -sh *

统计目录多少
du -sm * | sort -n

free -h

free -m

free -g

进程实时情况：

1

watch -n 1 free -h

堆栈信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

sudo vi gstack



#!/bin/sh
if test $# -ne 1; then
    echo "Usage: `basename $0 .sh` <process-id>" 1>&2
    exit 1
fi

if test ! -r /proc/$1; then
    echo "Process $1 not found." 1>&2
    exit 1
fi

# GDB doesn't allow "thread apply all bt" when the process isn't
# threaded; need to peek at the process to determine if that or the
# simpler "bt" should be used.

backtrace="bt"
if test -d /proc/$1/task ; then
    # Newer kernel; has a task/ directory.
    if test `/bin/ls /proc/$1/task | /usr/bin/wc -l` -gt 1 2>/dev/null ; then
backtrace="thread apply all bt"
    fi
elif test -f /proc/$1/maps ; then
    # Older kernel; go by it loading libpthread.
    if /bin/grep -e libpthread /proc/$1/maps > /dev/null 2>&1 ; then
backtrace="thread apply all bt"
    fi
fi

GDB=${GDB:-/usr/bin/gdb}

if $GDB -nx --quiet --batch --readnever > /dev/null 2>&1; then
    readnever=--readnever
else
    readnever=
fi

# Run GDB, strip out unwanted noise.
$GDB --quiet $readnever -nx /proc/$1/exe $1 <<EOF 2>&1 |
set width 0
set height 0
set pagination no
$backtrace
EOF
/bin/sed -n \
    -e 's/^\((gdb) \)*//' \
    -e '/^#/p' \
    -e '/^Thread/p'
#end


sudo chmod 777 gstack
sudo cp gstack  /usr/bin/


堆栈信息：sudo gstack pid

线程：top -Hp pid

内核

1

https://www.kernel.org/doc/html/v4.10/dev-tools/kmemleak.html

查看内存占用最多的进程：

1

ps -aux | sort -k4nr | head -n 5

内存使用

1
2
3
4

sudo su
cat /proc/meminfo
cat /proc/zoneinfo

树状以及块存储结构

1
2
3

pstree -h
sudo dumpe2fs /dev/sda1
dumpe2fs /dev/sda1 | grep -i "block size"

句柄查看

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

sudo su

总文件句柄数
cat /proc/sys/fs/file-max

修改总：sysctl -w fs.file-max=（成倍增加）
当前文件句柄数
cat /proc/sys/fs/file-nr

pmap ${pid}

ulimit -n

ulimit -HSn 2048

lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more

lsof |grep -i deleted

sudo lsof -p 9268

cd /proc/9268/fd

ls | wc -l

ls -al /proc/9689/fd/ | wc -l

更新本地软件库

1
2
3

更新本地软件列表
sudo apt update
sudo apt search 名称

查看IO、CPU利用率

1
2

top -Hp pid
vmstat 2 10000

1
2
3
4
5

虽然同是写数据，写磁盘跟写文件的现象还是不同的。写磁盘时（也就是 bo 大于  0 时），Buffer 和 Cache 都在增长，但显然 Buffer 的增长快得多。

这说明，写磁盘用到了大量的Buffer，这跟我们在文档中查到的定义是一样的。

对比两个案例，我们发现，写文件时会用到 Cache 缓存数据，而写磁盘则会用到 Buffer来缓存数据。所以，回到刚刚的问题，虽然文档上只提到，Cache是文件读的缓存，但实际上，Cache 也会缓存写文件时的数据。

swap

Swap分区（也称交换分区）是硬盘上的一个区域，被指定为操作系统可以临时存储数据的地方，这些数据不能再保存在RAM中。 基本上，这使您能够增加服务器在工作“内存”中保留的信息量，但有一些注意事项，主要是当RAM中没有足够的空间容纳正在使用的应用程序数据时，将使用硬盘驱动器上的交换空间。 写入磁盘的信息将比保存在RAM中的信息慢得多，但是操作系统更愿意将应用程序数据保存在内存中，并使用交换旧数据。 总的来说，当系统的RAM耗尽时，将交换空间作为回落空间可能是一个很好的安全网，可防止非SSD存储系统出现内存不足的情况。

内存不够用？在Linux上使用swapfile配置交换空间

查看系统是否有交换分区：

1

sudo swapon --show

临时修改方法如下：

1
2
3
4

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap -f /swapfile
sudo swapon /swapfile

经过测试，OpenSuSE系统要使用以下命令才能成功创建swapfile

1

sudo dd if=/dev/zero of=/swapfile count=4096 bs=1MiB

使用以下命令查看是否正确创建。

1

ls -lh /swapfile

结果应该类似下面这样：

1

-rw-r--r-- 1 root root 4.0G Apr 26 17:04 /swapfile

修改swapfile权限

1

sudo chmod 600 /swapfile

查看效果

1

ls -lh /swapfile

结果应该类似下面这样：

1

-rw------- 1 root root 8.0G Apr 26 17:04 /swapfile

激活交换空间

1
2

sudo mkswap /swapfile
sudo swapon /swapfile

之后使用以下命令查看使用成功开启交换空间：

1

sudo swapon --show

结果类似下面这样：

1
2

NAME      TYPE SIZE USED PRIO
/swapfile file   8G   0B   -1

添加到fstab

这样每次开机系统就会自动吧swapfile挂载为交换空间。 首先请自行备份fstab文件。 然后把以下配置添加到fstab文件末尾。

1

/swapfile none swap sw 0 0

或者直接使用以下命令：

1
2
3
4
5
6
7
8
9
10

sudo cp /etc/fstab /etc/fstab.bak

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

#关闭swapfile区
sudo swapoff /swapfile

sudo rm /swapfile

缓存释放

如果你使用过 drop_cache 来释放 inode 的话，应该会清楚它有几个控制选项，我们可以通过写入不同的数值来释放不同类型的 cache（用户数据 Page Cache，内核数据 Slab，或者二者都释放），这些选项你可以去看Kernel Documentation(https://www.kernel.org/doc/Documentation/sysctl/vm.txt) 的描述。

于是这样就引入了一个容易被我们忽略的问题：当我们执行 echo 2 来 drop slab 的时候，它也会把 Page Cache 给 drop 掉，很多运维人员都会忽视掉这一点。

在系统内存紧张的时候，运维人员或者开发人员会想要通过 drop_caches 的方式来释放一些内存，但是由于他们清楚 Page Cache 被释放掉会影响业务性能，所以就期望只去 drop slab 而不去 drop pagecache。于是很多人这个时候就运行 echo 2 > /proc/sys/vm/drop_caches，但是结果却出乎了他们的意料：Page Cache 也被释放掉了，业务性能产生了明显的下降。

由于 drop_caches 是一种内存事件，内核会在 /proc/vmstat 中来记录这一事件，所以我们可以通过 /proc/vmstat 来判断是否有执行过 drop_caches。

1
2
3

$ grep drop /proc/vmstat
drop_pagecache 3
drop_slab 2

如上所示，它们分别意味着 pagecache 被 drop 了 3 次（通过 echo 1 或者 echo 3），slab 被 drop 了 2 次（通过 echo 2 或者 echo 3）。如果这两个值在问题发生前后没有变化，那就可以排除是有人执行了 drop_caches；否则可以认为是因为 drop_caches 引起的 Page Cache 被回收。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#清理文件页、目录项、Inodes等各种缓存
echo 3 > /proc/sys/vm/drop_caches

#然后运行dd命令随机读取设备，向磁盘分区/dev/sdb1写入2G数据
dd if=/dev/urandom of=/dev/sdb1 bs=1M count=2048


sudo su

vi /root/cache.sh


#! /bin/bash
#v1.0
sync
echo 3 > /proc/sys/vm/drop_caches
swapoff -a && swapon -a



crontab -e
*/2 * * * * /root/cache.sh

内存泄露排查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

占用线程的内存文件
cat /proc/31108/smaps
sudo su
cat /proc/meminfo

其中 vmalloc 申请的内存会体现在 VmallocUsed 这一项中，即已使用的 Vmalloc 区大小；而 kmalloc 申请的内存则是体现在 Slab 这一项中，它又分为两部分，其中 SReclaimable 是指在内存紧张的时候可以被回收的内存，而 SUnreclaim 则是不可以被回收只能主动释放的内存。

如果 /proc/meminfo 中内核内存（比如 VmallocUsed 和 SUnreclaim）太大，那很有可能发生了内核内存泄漏；

另外，你也可以周期性地观察 VmallocUsed 和 SUnreclaim 的变化，如果它们持续增长而不下降，也可能是发生了内核内存泄漏。

这也可以通过 /proc 来查看，所以再次强调一遍，当你不清楚该如何去分析时，你可以试着去查看 /proc 目录下的文件。以上面的程序为例，安装 kmem_test 这个内核模块后，我们可以通过 /proc/vmallocinfo 来看到该模块的内存使用情况：


$ cat /proc/vmallocinfo | grep appName

vmstat 2 10000中看free的变化速度(迅速下降，但buffer、cache没发生变化，存在泄露)

strace -t -f -p 31108 -o 31108.strace

cat 31108.strace | grep 10489856

内存回收

（1）代码区——–主要存储程序代码指令，define定义的常量。

（2）全局数据区——主要存储全局变量（常量），静态变量（常量），常量字符串。

（3）栈区——–主要存储局部变量，栈区上的内容只在函数范围内存在，当函数运行结束，这些内容也会自动被销毁。其特点是效率高，但内存大小有限。

（4）堆区——–由malloc,calloc分配的内存区域，其生命周期由free决定。堆的内存大小是由程序员分配的，理论上可以占据系统中的所有内存。

当发生了内存泄漏时，或者运行了大内存的应用程序，导致系统的内存资源紧张时，系统又会如何应对呢？

这其实会导致两种可能结果，内存回收和OOM杀死进程。我们先来看后一个可能结果，内存资源紧张导致的 OOM（Out OfMemory），相对容易理解，指的是系统杀死占用大量内存的进程，释放这些内存，再分配给其他更需要的进程。

这一点我们前面详细讲过，这里就不再重复了。接下来再看第一个可能的结果，内存回收，也就是系统释放掉可以回收的内存，比如我前面讲过的缓存和缓冲区，就属于可回收内存。它们在内存管理中，通常被叫做文件页（File-backed Page）。

大部分文件页，都可以直接回收，以后有需要时，再从磁盘重新读取就可以了。而那些被应用程序修改过，并且暂时还没写入磁盘的数据（也就是脏页），就得先写入磁盘，然后才能进行内存释放。

这些脏页，一般可以通过两种方式写入磁盘。

• 可以在应用程序中，通过系统调用 fsync ，把脏页同步到磁盘中；
• 也可以交给系统，由内核线程 pdflush 负责这些脏页的刷新。（内核使用pdflush线程刷新脏页到磁盘，pdflush线程个数在2和8之间，可以通过/proc/sys/vm/nr_pdflush_threads文件直接查看，具体策略机制参看源码函数__pdflush。）

kbdirty 就是系统中的脏页大小，它同样也是对 /proc/vmstat 中 nr_dirty 的解析。你可以通过调小如下设置来将系统脏页个数控制在一个合理范围:

1
2
3
4
5

vm.dirty_background_bytes=0
vm.dirty_background_ratio=10
vm.dirty_bytes=0
vm.dirty_expire_centisecs=3000
vm.dirty_ratio=20

调整这些配置项有利有弊，调大这些值会导致脏页的积压，但是同时也可能减少了 I/O 的次数，从而提升单次刷盘的效率；调小这些值可以减少脏页的积压，但是同时也增加了 I/O 的次数，降低了 I/O 的效率。

至于这些值调整大多少比较合适，也是因系统和业务的不同而异，我的建议也是一边调整一边观察，将这些值调整到业务可以容忍的程度就可以了，即在调整后需要观察业务的服务质量 (SLA)，要确保 SLA 在可接受范围内。调整的效果你可以通过 /proc/vmstat 来查看：

1
2
3

grep "nr_dirty_" /proc/vmstat
nr_dirty_threshold 366998
nr_dirty_background_threshold 183275

你可以观察一下调整前后这两项的变化。这里我要给你一个避免踩坑的提示，解决该方案中的设置项如果设置不妥会触发一个内核 Bug，这是我在 2017 年进行性能调优时发现的一个内核 Bug，我给社区提交了一个 patch 将它 fix 掉了，具体的 commit 见 writeback: schedule periodic writeback with sysctl , commit log 清晰地描述了该问题，我建议你有时间看一看。

Page Cache是怎样产生和释放的

Page Cache 的产生有两种不同的方式：

• Buffered I/O（标准 I/O）；
• Memory-Mapped I/O（存储映射 I/O）。

标准 I/O 是写的 (write(2)) 用户缓冲区 (Userpace Page 对应的内存)，然后再将用户缓冲区里的数据拷贝到内核缓冲区 (Pagecache Page 对应的内存)；如果是读的 (read(2)) 话则是先从内核缓冲区拷贝到用户缓冲区，再从用户缓冲区读数据，也就是 buffer 和文件内容不存在任何映射关系。

对于存储映射 I/O 而言，则是直接将 Pagecache Page 给映射到用户地址空间，用户直接读写 Pagecache Page 中内容。

1
2
3
4

cat /proc/vmstat | egrep "dirty|writeback"

nr_dirty 40
nr_writeback 2

如上所示，nr_dirty 表示当前系统中积压了多少脏页，nr_writeback 则表示有多少脏页正在回写到磁盘中，他们两个的单位都是 Page(4KB)。

释放

free 命令中的 buff/cache 中的这些就是“活着”的 Page Cache，那它们什么时候会“死亡”（被回收）呢？我们来看一张图：

应用在申请内存的时候，即使没有 free 内存，只要还有足够可回收的 Page Cache，就可以通过回收 Page Cache 的方式来申请到内存，回收的方式主要是两种：直接回收和后台回收。

那它是具体怎么回收的呢？你要怎么观察呢？其实在我看来，观察 Page Cache 直接回收和后台回收最简单方便的方式是使用 sar：

1
2
3
4
5
6
7
8
9
10
11
12

$ sar -r 1

$ sar -B 1
02:14:01 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff


02:14:01 PM      0.14    841.53 106745.40      0.00  41936.13      0.00      0.00      0.00      0.00
02:15:01 PM      5.84    840.97  86713.56      0.00  43612.15    717.81      0.00    717.66     99.98
02:16:01 PM     95.02    816.53 100707.84      0.13  46525.81   3557.90      0.00   3556.14     99.95
02:17:01 PM     10.56    901.38 122726.31      0.27  54936.13   8791.40      0.00   8790.17     99.99
02:18:01 PM    108.14    306.69  96519.75      1.15  67410.50  14315.98     31.48  14319.38     99.80
02:19:01 PM      5.97    489.67  88026.03      0.18  48526.07   1061.53      0.00   1061.42     99.99

借助上面这些指标，你可以更加明确地观察内存回收行为，下面是这些指标的具体含义：

• pgscank/s : kswapd(后台回收线程) 每秒扫描的 page 个数。
• pgscand/s: Application 在内存申请过程中每秒直接扫描的 page 个数。
• pgsteal/s: 扫描的 page 中每秒被回收的个数。
• %vmeff: pgsteal/(pgscank+pgscand), 回收效率，越接近 100 说明系统越安全，越接近 0 说明系统内存压力越大。

**
进程运行所需要的内存类型有很多种，总的来说，这些内存类型可以从是不是文件映射，以及是不是私有内存这两个不同的维度来做区分，也就是可以划分为四类内存。**

• 私有匿名内存。进程的堆、栈，以及 mmap(MAP_ANON | MAP_PRIVATE) 这种方式申请的内存都属于这种类型的内存。其中栈是由操作系统来进行管理的，应用程序无需关注它的申请和释放；堆和私有匿名映射则是由应用程序（程序员）来进行管理的，它们的申请和释放都是由应用程序来负责的，所以它们是容易产生内存泄漏的地方。

• 共享匿名内存。进程通过 mmap(MAP_ANON | MAP_SHARED) 这种方式来申请的内存，比如说 tmpfs 和 shm。这个类型的内存也是由应用程序来进行管理的，所以也可能会发生内存泄漏。

• 私有文件映射。进程通过 mmap(MAP_FILE | MAP_PRIVATE) 这种方式来申请的内存，比如进程将共享库（Shared libraries）和可执行文件的代码段（Text Segment）映射到自己的地址空间就是通过这种方式。对于共享库和可执行文件的代码段的映射，这是通过操作系统来进行管理的，应用程序无需关注它们的申请和释放。而应用程序直接通过 mmap(MAP_FILE | MAP_PRIVATE) 来申请的内存则是需要应用程序自己来进行管理，这也是可能会发生内存泄漏的地方。

• 共享文件映射。进程通过 mmap(MAP_FILE | MAP_SHARED) 这种方式来申请的内存，我们在上一个模块课程中讲到的 File Page Cache 就属于这类内存。这部分内存也需要应用程序来申请和释放，所以也存在内存泄漏的可能性。

总结

• 进程直接读写的都是虚拟地址，虚拟地址最终会通过 Paging（分页）来转换为物理内存的地址，Paging 这个过程是由内核来完成的。
• 进程的内存类型可以从 anon（匿名）与 file（文件）、private（私有）与 shared（共享）这四项来区分为 4 种不同的类型，进程相关的所有内存都是这几种方式的不同组合。
• 查看进程内存时，可以先使用 top 来看系统中各个进程的内存使用概况，再使用 pmap 去观察某个进程的内存细节。

直接内存回收是指在进程上下文同步进行内存回收，那么它具体是怎么引起 load 飙高的呢？

因为直接内存回收是在进程申请内存的过程中同步进行的回收，而这个回收过程可能会消耗很多时间，进而导致进程的后续行为都被迫等待，这样就会造成很长时间的延迟，以及系统的 CPU 利用率会升高，最终引起 load 飙高。

那么，针对直接内存回收引起 load 飙高或者业务 RT 抖动的问题，一个解决方案就是及早地触发后台回收来避免应用程序进行直接内存回收，那具体要怎么做呢？那么，我们可以增大 min_free_kbytes 这个配置选项来及早地触发后台回收，该选项最终控制的是内存回收水位

系统中脏页过多引起 load 飙高

那如何解决这类问题呢？一个比较省事的解决方案是控制好系统中积压的脏页数据。很多人知道需要控制脏页，但是往往并不清楚如何来控制好这个度，脏页控制的少了可能会影响系统整体的效率，脏页控制的多了还是会触发问题，所以我们接下来看下如何来衡量好这个“度”。

kbdirty 就是系统中的脏页大小，它同样也是对 /proc/vmstat 中 nr_dirty 的解析。你可以通过调小如下设置来将系统脏页个数控制在一个合理范围:

1
2
3
4
5

vm.dirty_background_bytes=0
vm.dirty_background_ratio=10
vm.dirty_bytes=0
vm.dirty_expire_centisecs=3000
vm.dirty_ratio=20

调整这些配置项有利有弊，调大这些值会导致脏页的积压，但是同时也可能减少了 I/O 的次数，从而提升单次刷盘的效率；调小这些值可以减少脏页的积压，但是同时也增加了 I/O 的次数，降低了 I/O 的效率。

至于这些值调整大多少比较合适，也是因系统和业务的不同而异，我的建议也是一边调整一边观察，将这些值调整到业务可以容忍的程度就可以了，即在调整后需要观察业务的服务质量 (SLA)，要确保 SLA 在可接受范围内。调整的效果你可以通过 /proc/vmstat 来查看：

1
2
3

grep "nr_dirty_" /proc/vmstat
nr_dirty_threshold 366998
nr_dirty_background_threshold 183275

你可以观察一下调整前后这两项的变化。这里我要给你一个避免踩坑的提示，解决该方案中的设置项如果设置不妥会触发一个内核 Bug，这是我在 2017 年进行性能调优时发现的一个内核 Bug，我给社区提交了一个 patch 将它 fix 掉了，具体的 commit 见 writeback: schedule periodic writeback with sysctl , commit log 清晰地描述了该问题，我建议你有时间看一看。

系统 NUMA 策略配置不当引起的 load 飙高

除了我前面提到的这两种引起系统 load 飙高或者业务延迟抖动的场景之外，还有另外一种场景也会引起 load 飙高，那就是系统 NUMA 策略配置不当引起的 load 飙高。

比如说，我们在生产环境上就曾经遇到这样的问题：系统中还有一半左右的 free 内存，但还是频频触发 direct reclaim，导致业务抖动得比较厉害。后来经过排查发现是由于设置了 zone_reclaim_mode，这是 NUMA 策略的一种。

设置 zone_reclaim_mode 的目的是为了增加业务的 NUMA 亲和性，但是在实际生产环境中很少会有对 NUMA 特别敏感的业务，这也是为什么内核将该配置从默认配置 1 修改为了默认配置 0: mm: disable zone_reclaim_mode by default ，配置为 0 之后，就避免了在其他 node 有空闲内存时，不去使用这些空闲内存而是去回收当前 node 的 Page Cache，也就是说，通过减少内存回收发生的可能性从而避免它引发的业务延迟。

那么如何来有效地衡量业务延迟问题是否由 zone reclaim 引起的呢？它引起的延迟究竟有多大呢？这个衡量和观察方法也是我贡献给 Linux Kernel 的：mm/vmscan: add tracepoints for node reclaim ，大致的思路就是利用 linux 的 tracepoint 来做这种量化分析，这是性能开销相对较小的一个方案。

推荐将 zone_reclaim_mode 配置为 0。vm.zone_reclaim_mode = 0因为相比内存回收的危害而言，NUMA 带来的性能提升几乎可以忽略，所以配置为 0，利远大于弊。

好了，对于 Page Cache 管理不当引起的系统 load 飙高和业务时延抖动问题，我们就分析到这里，希望通过这篇的学习，在下次你遇到直接内存回收引起的 load 飙高问题时不再束手无策。

总的来说，这些问题都是 Page Cache 难以释放而产生的问题，那你是否想过，是不是 Page Cache 很容易释放就不会产生问题了？这个答案可能会让你有些意料不到：Page Cache 容易释放也有容易释放的问题。这到底是怎么回事呢，我们下节课来分析下这方面的案例。

内核机制引起 Page Cache 被回收而产生的业务性能下降

我简单来解释一下这个图。Reclaimer 是指回收者，它可以是内核线程（包括 kswapd）也可以是用户线程。回收的时候，它会依次来扫描 pagecache page 和 slab page 中有哪些可以被回收的，如果有的话就会尝试去回收，如果没有的话就跳过。在扫描可回收 page 的过程中回收者一开始扫描的较少，然后逐渐增加扫描比例直至全部都被扫描完。这就是内存回收的大致过程。

接下来我所要讲述的案例就发生在“relcaim slab”中，我们从前一个案例已然知道，如果 inode 被回收的话，那么它对应的 Page Cache 也都会被回收掉，所以如果业务进程读取的文件对应的 inode 被回收了，那么该文件所有的 Page Cache 都会被释放掉，这也是容易引起性能问题的地方。

那这个行为是否有办法观察？这同样也是可以通过 /proc/vmstat 来观察的，/proc/vmstat 简直无所不能（这也是为什么我会在之前说内核开发者更习惯去观察 /proc/vmstat）。

1
2
3

$ grep inodesteal /proc/vmstat
pginodesteal 114341
kswapd_inodesteal 1291853

这个行为对应的事件是 inodesteal，就是上面这两个事件，其中 kswapd_inodesteal 是指在 kswapd 回收的过程中，因为回收 inode 而释放的 pagecache page 个数；pginodesteal 是指 kswapd 之外其他线程在回收过程中，因为回收 inode 而释放的 pagecache page 个数。所以在你发现业务的 Page Cache 被释放掉后，你可以通过观察来发现是否因为该事件导致的。

如何避免 Page Cache 被回收而引起的性能问题？

我们在分析一些问题时，往往都会想这个问题是我的模块有问题呢，还是别人的模块有问题。也就是说，是需要修改我的模块来解决问题还是需要修改其他模块来解决问题。与此类似，避免 Page Cache 里相对比较重要的数据被回收掉的思路也是有两种：

• 从应用代码层面来优化；
• 从系统层面来调整。

从应用程序代码层面来解决是相对比较彻底的方案，因为应用更清楚哪些 Page Cache 是重要的，哪些是不重要的，所以就可以明确地来对读写文件过程中产生的 Page Cache 区别对待。比如说，对于重要的数据，可以通过 mlock(2) 来保护它，防止被回收以及被 drop；对于不重要的数据（比如日志），那可以通过 madvise(2) 告诉内核来立即释放这些 Page Cache。

在有些情况下，对应用程序而言，修改源码是件比较麻烦的事，如果可以不修改源码来达到目的那就最好不过了。Linux 内核同样实现了这种不改应用程序的源码而从系统层面调整来保护重要数据的机制，这个机制就是 memory cgroup protection。

它大致的思路是，将需要保护的应用程序使用 memory cgroup 来保护起来，这样该应用程序读写文件过程中所产生的 Page Cache 就会被保护起来不被回收或者最后被回收。memory cgroup protection 大致的原理如下图所示：

如上图所示，memory cgroup 提供了几个内存水位控制线 memory.{min, low, high, max} 。

• memory.max这是指 memory cgroup 内的进程最多能够分配的内存，如果不设置的话，就默认不做内存大小的限制。
• memory.high如果设置了这一项，当 memory cgroup 内进程的内存使用量超过了该值后就会立即被回收掉，所以这一项的目的是为了尽快的回收掉不活跃的 Page Cache。
• memory.low这一项是用来保护重要数据的，当 memory cgroup 内进程的内存使用量低于了该值后，在内存紧张触发回收后就会先去回收不属于该 memory cgroup 的 Page Cache，等到其他的 Page Cache 都被回收掉后再来回收这些 Page Cache。
• memory.min这一项同样是用来保护重要数据的，只不过与 memoy.low 有所不同的是，当 memory cgroup 内进程的内存使用量低于该值后，即使其他不在该 memory cgroup 内的 Page Cache 都被回收完了也不会去回收这些 Page Cache，可以理解为这是用来保护最高优先级的数据的。

那么，如果你想要保护你的 Page Cache 不被回收，你就可以考虑将你的业务进程放在一个 memory cgroup 中，然后设置 memory.{min,low} 来进行保护；与之相反，如果你想要尽快释放你的 Page Cache，那你可以考虑设置 memory.high 来及时的释放掉不活跃的 Page Cache。

除了缓存和缓冲区，通过内存映射获取的文件映射页，也是一种常见的文件页。它也可以被释放掉，下次再访问的时候，从文件重新读取。

除了文件页外，还有没有其他的内存可以回收呢？比如，应用程序动态分配的堆内存，也就是我们在内存管理中说到的匿名页（Anonymous Page），是不是也可以回收呢？

我想，你肯定会说，它们很可能还要再次被访问啊，当然不能直接回收了。非常正确，这些内存自然不能直接释放。

但是，如果这些内存在分配后很少被访问，似乎也是一种资源浪费。是不是可以把它们暂时先存在磁盘里，释放内存给其他更需要的进程？

其实，这正是 Linux 的Swap机制。Swap把这些不常访问的内存先写到磁盘中，然后释放这些内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入内存就可以了。

在前几节的案例中，我们已经分别学过缓存和 OOM 的原理和分析。那 Swap 又是怎么工作的呢？因为内容比较多，接下来，我将用两节课的内容，带你探索 Swap 的工作原理，以及 Swap 升高后的分析方法。

今天我们先来看看，Swap 究竟是怎么工作的。

Swap 原理

Swap 说白了就是把一块磁盘空间或者一个本地文件（以下讲解以磁盘为例），当成内存来使用。它包括换出和换入两个过程。

• 所谓换出，就是把进程暂时不用的内存(swap)数据存储到磁盘中，并释放这些数据占用的内存。

• 而换入，则是在进程再次访问这些内存的时候，把它们从磁盘读到内存(swap)中来。

所以你看，Swap 其实是把系统的可用内存变大了。这样，即使服务器的内存不足，也可以运行大内存的应用程序。

还记得我最早学习 Linux操作系统时，内存实在太贵了，一个普通学生根本就用不起大的内存，那会儿我就是开启了Swap来运行Linux桌面。当然，现在的内存便宜多了，服务器一般也会配置很大的内存，那是不是说Swap就没有用武之地了呢？

当然不是。事实上，内存再大，对应用程序来说，也有不够用的时候。

一个很典型的场景就是，即使内存不足时，有些应用程序也并不想被 OOM 杀死，而是希望能缓一段时间，等待人工介入，或者等系统自动释放其他进程的内存，再分配给它。

除此之外，我们常见的笔记本电脑的休眠和快速开机的功能，也基于 Swap 。休眠时，把系统的内存存入磁盘，这样等到再次开机时，只要从磁盘中加载内存就可以。这样就省去了很多应用程序的初始化过程，加快了开机速度。

话说回来，既然 Swap 是为了回收内存，那么Linux到底在什么时候需要回收内存呢？前面一直在说内存资源紧张，又该怎么来衡量内存是不是紧张呢？

一个最容易想到的场景就是，有新的大块内存分配请求，但是剩余内存不足。这个时候系统就需要回收一部分内存（比如前面提到的缓存），进而尽可能地满足新内存请求。这个过程通常被称为直接内存回收。

除了直接内存回收，还有一个专门的内核线程用来定期回收内存，也就是 kswapd0。为了衡量内存的使用情况，kswapd0 定义了三个内存阈值（watermark，也称为水位），分别是

页最小阈值（pages_min）、页低阈值（pages_low）和页高阈值（pages_high）。剩余内存，则使用 pages_free 表示。

kswapd0 定期扫描内存的使用情况，并根据剩余内存落在这三个阈值的空间位置，进行内存的回收操作。

• 剩余内存小于页最小阈值，说明进程可用内存都耗尽了，只有内核才可以分配内存。
• 剩余内存落在页最小阈值和页低阈值中间，说明内存压力比较大，剩余内存不多了。这时 kswapd0 会执行内存回收，直到剩余内存大于高阈值为止。
• 剩余内存落在页低阈值和页高阈值中间，说明内存有一定压力，但还可以满足新内存请求。
• 剩余内存大于页高阈值，说明剩余内存比较多，没有内存压力。

我们可以看到，一旦剩余内存小于页低阈值，就会触发内存的回收。这个页低阈值，其实可以通过内核选项 /proc/sys/vm/min_free_kbytes 来间接设置。min_free_kbytes 设置了页最小阈值，而其他两个阈值，都是根据页最小阈值计算生成的，计算方法如下 ：

1
2

pages_low = pages_min*5/4
pages_high = pages_min*3/2

NUMA 与 Swap

很多情况下，你明明发现了Swap升高，可是在分析系统的内存使用时，却很可能发现，系统剩余内存还多着呢。为什么剩余内存很多的情况下，也会发生 Swap 呢？

看到上面的标题，你应该已经想到了，这正是处理器的 NUMA （Non-Uniform Memory Access）架构导致的。

关于 NUMA，我在 CPU 模块中曾简单提到过。在 NUMA 架构下，多个处理器被划分到不同 Node 上，且每个 Node 都拥有自己的本地内存空间。

而同一个 Node 内部的内存空间，实际上又可以进一步分为不同的内存域（Zone），比如直接内存访问区（DMA）、普通内存区（NORMAL）、伪内存区（MOVABLE）等，如下图所示：

先不用特别关注这些内存域的具体含义，我们只要会查看阈值的配置，以及缓存、匿名页的实际使用情况就够了。

既然 NUMA 架构下的每个 Node 都有自己的本地内存空间，那么，在分析内存的使用时，我们也应该针对每个 Node 单独分析。

你可以通过 numactl 命令，来查看处理器在 Node 的分布情况，以及每个 Node 的内存使用情况。比如，下面就是一个 numactl 输出的示例：

1
2
3
4
5
6

$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1
node 0 size: 7977 MB
node 0 free: 4416 MB
...

这个界面显示，我的系统中只有一个 Node，也就是 Node 0 ，而且编号为 0 和 1 的两个 CPU， 都位于 Node 0 上。另外，Node 0 的内存大小为 7977 MB，剩余内存为 4416 MB。

了解了 NUNA 的架构和 NUMA 内存的查看方法后，你可能就要问了这跟 Swap 有什么关系呢？

实际上，前面提到的三个内存阈值（页最小阈值、页低阈值和页高阈值），都可以通过内存域在 proc 文件系统中的接口 /proc/zoneinfo 来查看。

比如，下面就是一个 /proc/zoneinfo 文件的内容示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ cat /proc/zoneinfo
...
Node 0, zone   Normal
 pages free     227894
       min      14896
       low      18620
       high     22344
...
     nr_free_pages 227894
     nr_zone_inactive_anon 11082
     nr_zone_active_anon 14024
     nr_zone_inactive_file 539024
     nr_zone_active_file 923986
...

这个输出中有大量指标，我来解释一下比较重要的几个。

• pages 处的 min、low、high，就是上面提到的三个内存阈值，而 free 是剩余内存页数，它跟后面的 nr_free_pages 相同。

• nr_zone_active_anon 和 nr_zone_inactive_anon，分别是活跃和非活跃的匿名页数。

• nr_zone_active_file 和 nr_zone_inactive_file，分别是活跃和非活跃的文件页数。

从这个输出结果可以发现，剩余内存远大于页高阈值，所以此时的 kswapd0 不会回收内存。

当然，某个 Node 内存不足时，系统可以从其他 Node 寻找空闲内存，也可以从本地内存中回收内存。具体选哪种模式，你可以通过 /proc/sys/vm/zone_reclaim_mode 来调整。它支持以下几个选项：

• 默认的 0 ，也就是刚刚提到的模式，表示既可以从其他 Node 寻找空闲内存，也可以从本地回收内存。
• 1、2、4 都表示只回收本地内存，2 表示可以回写脏数据回收内存，4 表示可以用 Swap 方式回收内存。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

vm.zone_reclaim_mode

设置方法：

echo 0 > /proc/sys/vm/zone_reclaim_mode，或

sysctl -w vm.zone_reclaim_mode=0，或

编辑/etc/sysctl.conf文件，加入vm.zone_reclaim_mode=0

# echo 0 > /proc/sys/vm/zone_reclaim_mode
# # 意味着关闭zone_reclaim模式，可以从其他zone或NUMA节点回收内存
# echo 1 > /proc/sys/vm/zone_reclaim_mode
# # 表示打开zone_reclaim模式，这样内存回收只会发生在本地节点内
# echo 2 > /proc/sys/vm/zone_reclaim_mode
# # 在本地回收内存时，可以将cache中的脏数据写回硬盘，以回收内存。
# echo 4 > /proc/sys/vm/zone_reclaim_mode
# # 可以用swap方式回收内存。

swappiness

到这里，我们就可以理解内存回收的机制了。这些回收的内存既包括了文件页，又包括了匿名页。

• 对文件页的回收，当然就是直接回收缓存，或者把脏页写回磁盘后再回收。
• 而对匿名页的回收，其实就是通过 Swap 机制，把它们写入磁盘后再释放内存。

不过，你可能还有一个问题。既然有两种不同的内存回收机制，那么在实际回收内存时，到底该先回收哪一种呢？

其实，Linux 提供了一个 /proc/sys/vm/swappiness 选项，用来调整使用 Swap 的积极程度。

swappiness 的范围是 0-100，数值越大，越积极使用 Swap，也就是更倾向于回收匿名页；数值越小，越消极使用 Swap，也就是更倾向于回收文件页。

虽然 swappiness 的范围是 0-100，不过要注意，这并不是内存的百分比，而是调整 Swap 积极程度的权重，即使你把它设置成 0，当剩余内存 + 文件页小于页高阈值(https://www.kernel.org/doc/Documentation/sysctl/vm.txt)时，还是会发生 Swap。

清楚了 Swap 原理后，当遇到 Swap 使用变高时，又该怎么定位、分析呢？别急，下一节，我们将用一个案例来探索实践。

小结

在内存资源紧张时，Linux 通过直接内存回收和定期扫描的方式，来释放文件页和匿名页，以便把内存分配给更需要的进程使用。

• 文件页的回收比较容易理解，直接清空，或者把脏数据写回磁盘后再释放。
• 而对匿名页的回收，需要通过 Swap 换出到磁盘中，下次访问时，再从磁盘换入到内存中。

你可以设置 /proc/sys/vm/min_free_kbytes，来调整系统定期回收内存的阈值（也就是页低阈值），还可以设置 /proc/sys/vm/swappiness，来调整文件页和匿名页的回收倾向。

在 NUMA 架构下，每个 Node都有自己的本地内存空间，而当本地内存不足时，默认既可以从其他 Node 寻找空闲内存，也可以从本地内存回收。

你可以设置 /proc/sys/vm/zone_reclaim_mode 来调整 NUMA 本地内存的回收策略。

程序被oom-kill

很快系统内存就会被耗尽，进而触发 OOM killer 去杀进程。这个信息可以通过 dmesg（该命令是用来查看内核日志的）这个命令来查看：

1
2
3
4
5
6
7

dmesg

oom_adj 的范围是 [-17, 15]，数值越大，表示进程越容易被 OOM 杀死；数值越小，表示进程越不容易被 OOM 杀死，其中 -17 表示禁止 OOM。

echo -17 > /proc/$(pidof ele-vue)/oom_adj

$ sudo sh -c "echo -17 > /proc/$(pidof ele-vue)/oom_adj"

开启 Swap 后，你可以设置 /proc/sys/vm/min_free_kbytes来调整系统定期回收内存的阈值，也可以设置 /proc/sys/vm/swappiness ，来调整文件页和匿名页的回收倾向。

1

echo 0 >/proc/sys/vm/swappiness

永久修改：

在 /etc/sysctl.conf 文件添加 ”vm.swappiness=0” 行

脏页(应用程序修改过但暂时未写入磁盘的数据)的数据处理（启用内核线程 pdflush 负责这些脏页的刷新）/proc/sys/vm/nr_pdflush_threads

1

vm.nr_pdflush_threads=2

kbdirty 就是系统中的脏页大小，它同样也是对 /proc/vmstat 中 nr_dirty 的解析。你可以通过调小如下设置来将系统脏页个数控制在一个合理范围:

1
2
3
4
5

vm.dirty_background_bytes=0
vm.dirty_background_ratio=10
vm.dirty_bytes=0
vm.dirty_expire_centisecs=3000
vm.dirty_ratio=20

调整这些配置项有利有弊，调大这些值会导致脏页的积压，但是同时也可能减少了 I/O 的次数，从而提升单次刷盘的效率；调小这些值可以减少脏页的积压，但是同时也增加了 I/O 的次数，降低了 I/O 的效率。

1
2
3
4
5
6
7
8
9
10

vm.min_free_kbytes=409600（来调整系统定期回收内存的阈值）

vm.vfs_cache_pressure=200
#加大这个参数设置了虚拟内存回收directory和i-node缓冲的倾向，这个值越大，回收的倾向越严重。调整这3个参数的目的就是让操作系统在平时就尽快回收缓冲，释放物理内存，这样就可以避免突发性的大规模换页。

vm.overcommit_memory=1(表示即使内存耗尽也不杀死任何进程)


#查看
sysctl -a

Lock 同步锁是基于 Java 实现的，而 Synchronized 是基于底层操作系统的 Mutex Lock 实现的，每次获取和释放锁操作都会带来用户态和内核态的切换，从而增加系统性能开销。因此，在锁竞争激烈的情况下，Synchronized 同步锁在性能上就表现得非常糟糕，它也常被大家称为重量级锁。

特别是在单个线程重复申请锁的情况下，JDK1.5 版本的 Synchronized 锁性能要比 Lock 的性能差很多。例如，在 Dubbo 基于 Netty 实现的通信中，消费端向服务端通信之后，由于接收返回消息是异步，所以需要一个线程轮询监听返回信息。而在接收消息时，就需要用到锁来确保 request session 的原子性。如果我们这里使用 Synchronized 同步锁，那么每当同一个线程请求锁资源时，都会发生一次用户态和内核态的切换。

到了 JDK1.6 版本之后，Java 对 Synchronized 同步锁做了充分的优化，甚至在某些场景下，它的性能已经超越了 Lock 同步锁。这一讲我们就来看看 Synchronized 同步锁究竟是通过了哪些优化，实现了性能地提升。

同步锁实现原理

通常 Synchronized 实现同步锁的方式有两种，一种是修饰方法，一种是修饰方法块。以下就是通过 Synchronized 实现的两种同步方法加锁的方式：

1
2
3
4
5
6
7
8
9
10
11
12
13

// 关键字在实例方法上，锁为当前实例
  public synchronized void method1() {
      // code
  }

  // 关键字在代码块上，锁为括号里面的对象
  public void method2() {
      Object o = new Object();
      synchronized (o) {
          // code
      }
  }