
kafka的应用场景

- 实时日志聚合，支持高容量事件流
- 处理大量的数据积压，支持来自离线系统的周期性数据加载
- 处理低延迟分发，分区，分布式，以及实时处理



### 如何处理大量的数据积压？

熟知的mysql是通过B+树来持久化到磁盘的，查找数据需要从磁盘读取并构建B+树内存数据结构。而Kafka则是：使用linux文件系统和pagecache，放弃内存数据结构

- 即使进程维护了内存数据结构，该数据也可能会被复制到操作系统的 pagecache 中，事实上所有内容都被存储了两份。

- 通过自动访问所有空闲内存将可用缓存的容量至少翻倍，并且通过存储紧凑的字节结构而不是独立的对象，有望将缓存容量再翻一番。 这样使得32GB的机器缓存容量可以达到28-30GB,并且不会有额外的 GC 负担
- 保持 内存cache 和 文件系统之间一致性逻辑，不需要做过多的转化。

- 简单的读写文件，读写操作不会相互影响。数据的大小不在会影响性能。可以无限量的使用物理硬盘，价格便宜，容量充足。可以充分解决大量的数据积压难题



### 如何在1秒内接收并持久化这1亿条数据呢？

存储问题解决了，面临的问题：大量的I/O和字节拷贝

I/O操作主要是 客户端与服务端的消息传递，服务端的数据持久化。

将多个消息打包成一组消息块，一次请求发送一组消息，服务端接收，consumer每次获取多组消息块，大量的I/O操作将不在是主要的性能问题，其实主要矛盾是在服务带宽问题上。producer/broker/consumer 三者使用二进制数据传输，producer 和 consumer 之间使用相同的压缩算法也可以极大的节省带宽问题

sendfile 将数据从 pagecache 直接发送到网络，这样避免重新复制数据。



每秒1亿条数据，保存7天，kafka是如何处理的？


[toc]

# 安装

**zookeeper** 下载地址: [http://zookeeper.apache.org/releases.html#download](http://zookeeper.apache.org/releases.html#download)

解压：`tar -zxvf kafka_2.12-2.6.0.tgz`

运行：`./bin/zkServer.sh --config conf start`

> --config 指的是配置目录



**kafka** 下载地址: [https://kafka.apache.org/downloads](https://kafka.apache.org/downloads)

解压：`tar -zxvf kafka_2.12-2.6.0.tgz`

运行：`./bin/kafka-server-start.sh config/server.properties`

# 配置

**kafka配置：**

`kakfa-configs.sh` 可以对kafka配置查看或修改

别名： 每次敲这么多命令很烦

`alias kconfigs="~/Documents/kafka/kafka/bin/kafka-configs.sh --bootstrap-server localhost:9092"`

查看:  --describe

`kconfigs --describe --entity-type [topics/clients/users/brokers/broker-loggers] --all`

- brokers
  - log.dirs：指定文件存储目录, 多个逗号分隔，建议目录指定不同的磁盘
    - 提升读写性能，多个磁盘同时读写的性能更高
    - 故障转移：Failover 1.1 版本添加
  - listeners：通过什么协议访问kafka服务，内网服务指定
  - advertised.listeners：外网访问kafka服务指定
  - log.retension.hours=168：记录保留时长 默认7天（hours/minutes/ms）
  - log.retension.bytes=1073741824：可用磁盘大小 默认 128G， -1不限制
  - zookeeper.connect=localhost:2181：zookeeper连接地址
  - auto.create.topics.enable: false topic不存在时是否自动创建（建议显示配置false）
  - unclean.leader.election.enblae: false 允许落后的副本参与leader选举（建议显示配置false）
  - auto.leader.rebalance.enable: false 定期leader选举，正常服务的leader到期也会被替换掉（建议显示配置false）
- topics
  - retension.hours 保留时长
  - retension.bytes 为该Topic预留多大的磁盘空间，-1无限使用磁盘空间
- users
- clients
- broker-loggers

修改：--alter

`kconfigs --alter --entity-type topics --entity-name test --add-config max.message.bytes=104858800`

- --alter：代表修改
- --entity-type: 代表上面这5中实例
- --entity-name: 指定那个broker（broker.id）, topic (topic.name)
- --add-config: --help 可以查看支持实时修改的配置

**JVM配置**：

- 堆大小(heap size)配置：建议6G  环境变量
  - `export KAFKA_HEAP_OPTS=--Xms6g  --Xmx6g`
- 垃圾回收：G1收集器 
  - `export  KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true`

**系统配置**:

- 文件描述符限制：`ulimit -n`
  - `/etc/security/limits.conf` 
    - `soft nofile 102400`
    - `hard nofile 104800`
- 文件系统类型： xfs 性能较好
- swap内存：建议配置成1，方便报警
- 脏页刷新时间：默认5秒

- 磁盘大小
  - 新增消息数
  - 消息留存时间
  - 平均消息大小
  - 备份数
  - 是否启用压缩

# 本地集群

本地运行多个实例，需要指定不同的端口，和broker.id, 创建多个server.propertie，指定端口

```
config/server-1.properties:
  broker.id=1
  listeners=PLAINTEXT://:9093
  log.dir="～/Documents/kafka/data1"
```

```
config/server-2.properties:
  broker.id=2
  listeners=PLAINTEXT://:9094
  log.dir="~/Documents/kafka/data2"
```

启动：

```shell
./bin/zookeeper-server-start.sh -daemon config/zookeeper.properties 
./bin/kafka-server-start.sh -daemon config/server.properties
./bin/kafka-server-start.sh -daemon config/server1.properties 
./bin/kafka-server-start.sh -daemon config/server2.properties 
```

创建：3副本/1分区 topic

> alias ktopics="~/Documents/kafka/bin/kafka-topics --bootstrap-server localhost:9092,localhost:9093,localhost:9094"

```shell
ktopics --create --replication-factor 3 --partitions 1 --topic test
```

查看：topic状态

```shell
ktopics --descibe --topic test

Topic: test	PartitionCount: 1	ReplicationFactor: 3	Configs: segment.bytes=1073741824
	Topic: test	Partition: 0	Leader: 3	Replicas: 2,3,1	Isr: 3,1,2
```

# kafka 分区策略 & 压缩算法

分区策略是决定生产者将消息发送到哪个分区的算法

常见的分区策略:

1. 轮询策略，能保证消息尽可能分配到不同的分区上 
2. 随机策略，随机返回小于partition的数，不能保证均匀性，适用及其性能不一的情形
3. hash策略，具有相同key的消息会保证在同一个分区中，这样可以保证消息的前后顺序

go语言包：[github.com/Shopify/sarama](https://pkg.go.dev/github.com/Shopify/sarama)  提供了这3种分区策略的实现

**轮询:** `func NewRoundRobinPartitioner(topic string) Partitioner`

**随机:** `func NewRandomPartitioner(topic string) Partitioner`

**hash:** `func NewHashPartitioner(topic string) Partitioner`

**指定分区** `func NewManualPartitioner(topic string) Partitioner`



压缩：

保证Producer 和 Consumer 压缩算法一致

```go
const (
	//CompressionNone no compression
	CompressionNone CompressionCodec = iota
	//CompressionGZIP compression using GZIP
	CompressionGZIP
	//CompressionSnappy compression using snappy
	CompressionSnappy
	//CompressionLZ4 compression using LZ4
	CompressionLZ4
	//CompressionZSTD compression using ZSTD
	CompressionZSTD
)
```

吞吐量： LZ4 > Snappy > zstd > GZIP

压缩比：zstd > LZ4 > GZIP > Snappy

CPU:  各算法差不多压缩时 Snappy 算法使用的 CPU 较多, 解压缩时 GZIP 算法可能使用更多的 CPU



# FAQs

**如何保证消息不丢失?**

producer: 

1. 消息发送异常处理, [sarama](https://github.com/Shopify/sarama)提供了2种发送消息的方式，sync/async，同步如果发送失败会返回error，异步提供了 `Errors() <-chan *ProducerError` 接口来处理错误
2. 消息发送异常重试, `config.Producer.Retry`, 默认是 3次
3. `config.Producer.RequiredAcks=WaitForAll` 所有副本都接受到消息，该消息才算做提交
   1. `NoResponse RequiredAcks = 0`
   2. `WaitForLocal RequiredAcks = 1`
   3. `WaitForAll RequiredAcks = -1`

broker:

1. `unclean.leader.election.enable=false` 控制落后台太多的broker不参加leader选举
2. `replication.factor >= 3` 副本数量不要少于3份
3. `min.insync.replicas >= 1` 消息最少写入多少个副本才算做已提交，正式环境中建议>=3
4. `replication.factor > min.insync.replicas`  如果2着相等，只要有1个副本挂掉，整个分区就无法工作了

consumer:

1. 先消费，在更新位移, `cfg.Consumer.Offsets.AutoCommit.Enable = false` 默认是自动提交的


kafka生产环境配置


[TOC]

# 	时间格式常量

## 标准

```go
const (
    ANSIC       = "Mon Jan _2 15:04:05 2006"
    UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
    RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
    RFC822      = "02 Jan 06 15:04 MST"
    RFC822Z     = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
    RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
    RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
    RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
    RFC3339     = "2006-01-02T15:04:05Z07:00"
    RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
    Kitchen     = "3:04PM"
    // Handy time stamps.
    Stamp      = "Jan _2 15:04:05"
    StampMilli = "Jan _2 15:04:05.000"
    StampMicro = "Jan _2 15:04:05.000000"
    StampNano  = "Jan _2 15:04:05.000000000"
)
```

## 时/分/秒/毫秒/微妙/纳秒

```go
const (
    Nanosecond  Duration = 1
    Microsecond          = 1000 * Nanosecond
    Millisecond          = 1000 * Microsecond
    Second               = 1000 * Millisecond
    Minute               = 60 * Second
    Hour                 = 60 * Minute
)
```

## 月份

```go
const (
	January Month = 1 + iota
	February
	March
	April
	May
	June
	July
	August
	September
	October
	November
	December
)
```

## 星期几

```go
const (
	Sunday Weekday = iota
	Monday
	Tuesday
	Wednesday
	Thursday
	Friday
	Saturday
)
```

# 超时控制 After

```go
var c chan int

func handle(int) {}

func main() {
	select {
	case m := <-c:
		handle(m)
	case <-time.After(10 * time.Second):
		fmt.Println("timed out")gg
	}
}
```

# 时间间隔 Duration

time.Add(t Duration)传参需要使用Durtaion 

## time.Sub

计算两个时间差，返回duration

```go
func expensiveCall() {}

func main() {
	t0 := time.Now()
	expensiveCall()
	t1 := time.Now()
	fmt.Printf("The call took %v to run.\n", t1.Sub(t0))
}
```

## ParseDuration

有效符号："ns", "us" (or "µs"), "ms", "s", "m", "h".

```go
func main() {
	hours, _ := time.ParseDuration("10h")
	complex, _ := time.ParseDuration("1h10m10s")
	micro, _ := time.ParseDuration("1µs")
	// The package also accepts the incorrect but common prefix u for micro.
	micro2, _ := time.ParseDuration("1us")

	fmt.Println(hours)
	fmt.Println(complex)
	fmt.Printf("There are %.0f seconds in %v.\n", complex.Seconds(), complex)
	fmt.Printf("There are %d nanoseconds in %v.\n", micro.Nanoseconds(), micro)
	fmt.Printf("There are %6.2e seconds in %v.\n", micro2.Seconds(), micro)
}
```

# 时间 Time

基础结构体:

```go
type Time struct {
	wall uint64
	ext  int64
	loc *Location
}
```

## Date

返回指定日期的time

```go
func main() {
	t := time.Date(2009, time.November, 10, 23, 0, 0, 0, time.UTC)
	fmt.Printf("Go launched at %s\n", t.Local())
}
// Go launched at 2009-11-11 07:00:00 +0800 CST
```

## 当前时间 Now

返回当前时间,这个用的最多

## 时间解析 Parse & ParseInLocation

```go
func Parse(layout, value string) (Time, error)
```

Layout 时间格式，value时间值，解析时间返回time

```go
func main() {
	t, _ := time.Parse("2006-01-02", "2020-12-05")
	fmt.Println(t)
  m, _ := time.Parse("2006-01-02 15:04:05", "2020-12-05 11:23:08")
	fmt.Println(m)
}
// 2020-12-05 00:00:00 +0000 UTC
// 2020-12-05 11:23:00 +0000 UTC
```

上面的用法其实是错误的，没有时区，正确的做法是：

```go
func main() {
	t, _ := time.ParseInLocation("2006-01-02", "2020-12-05")
	fmt.Println(t)
  m, _ := time.ParseInLocation("2006-01-02 15:04:05", "2020-12-05 11:23:08")
	fmt.Println(m)
}
// 2020-12-05 00:00:00 +0800 CST
// 2020-12-05 11:23:00 +0800 CST
```

## 时间戳 Unix

解析时间戳为time

```go
func main() {
	t := time.Unix(1576053402, 100000000)
	fmt.Print(t)
}
// 2019-12-11 16:36:42.01 +0800 CST
```

## 格式化 Format

时间格式化

默认输出格式：`2006-01-02 15:04:05.999999999 -0700 MST`

```go
func main() {
	fmt.Printf("当前时间: %s\n", time.Now())
	fmt.Printf("RFC1123Z: %s\n", time.Now().Format(time.RFC1123Z))
	fmt.Printf("RFC3339: %s\n", time.Now().Format(time.RFC3339))
}

// 当前时间: 2019-12-11 16:25:53.987141 +0800 CST m=+0.000513629
// RFC1123Z: Wed, 11 Dec 2019 16:25:53 +0800
// RFC3339: 2019-12-11T16:25:53+08:00
```

## 时间加减 Add

当前时间加上 ？

```go
func main() {
	start := time.Date(2009, 1, 1, 12, 0, 0, 0, time.UTC)
	afterTenSeconds := start.Add(time.Second * 10)
	afterTenMinutes := start.Add(time.Minute * 10)
	afterTenHours := start.Add(time.Hour * 10)
	afterTenDays := start.Add(time.Hour * 24 * 10)

	fmt.Printf("start = %v\n", start)
	fmt.Printf("start.Add(time.Second * 10) = %v\n", afterTenSeconds)
	fmt.Printf("start.Add(time.Minute * 10) = %v\n", afterTenMinutes)
	fmt.Printf("start.Add(time.Hour * 10) = %v\n", afterTenHours)
	fmt.Printf("start.Add(time.Hour * 24 * 10) = %v\n", afterTenDays)
}
```

## 判断时间是否相等 Equal

判断两个时间是否一致

```go
func main() {
	secondsEastOfUTC := int((8 * time.Hour).Seconds())
	beijing := time.FixedZone("Beijing Time", secondsEastOfUTC)

	// Unlike the equal operator, Equal is aware that d1 and d2 are the
	// same instant but in different time zones.
	d1 := time.Date(2000, 2, 1, 12, 30, 0, 0, time.UTC)
	d2 := time.Date(2000, 2, 1, 20, 30, 0, 0, beijing)

	datesEqualUsingEqualOperator := d1 == d2
	datesEqualUsingFunction := d1.Equal(d2)

	fmt.Printf("datesEqualUsingEqualOperator = %v\n", datesEqualUsingEqualOperator)
	fmt.Printf("datesEqualUsingFunction = %v\n", datesEqualUsingFunction)
}
```

## Before/After

判断时间A是否在时间B之前还是之后，返回bool

```go
func main() {
	a := time.Now()
	b := time.Now()

	fmt.Printf("a 在 b 之前: %v\n", a.Before(b))
	fmt.Printf("a 在 b 之后: %v\n", a.After(b))
}

// a 在 b 之前: true
// a 在 b 之后: false
```

## 时间四舍五入 Round

时间4舍5入

```go
func main() {
	t := time.Date(0, 0, 0, 12, 15, 30, 918273645, time.UTC)
	round := []time.Duration{
		time.Nanosecond,
		time.Microsecond,
		time.Millisecond,
		time.Second,
		2 * time.Second,
		time.Minute,
		10 * time.Minute,
		time.Hour,
	}

	for _, d := range round {
		fmt.Printf("t.Round(%6s) = %s\n", d, t.Round(d).Format("15:04:05.999999999"))
	}
}
```

## 舍去 Truncate

```go
func main() {
	t, _ := time.Parse("2006 Jan 02 15:04:05", "2012 Dec 07 12:15:30.918273645")
	trunc := []time.Duration{
		time.Nanosecond,
		time.Microsecond,
		time.Millisecond,
		time.Second,
		2 * time.Second,
		time.Minute,
		10 * time.Minute,
	}

	for _, d := range trunc {
		fmt.Printf("t.Truncate(%5s) = %s\n", d, t.Truncate(d).Format("15:04:05.999999999"))
	}
	// To round to the last midnight in the local timezone, create a new Date.
	midnight := time.Date(t.Year(), t.Month(), t.Day(), 0, 0, 0, 0, time.Local)
	_ = midnight
}
```

# 定时器 Tick 

```go
func statusUpdate() string { return "" }

func main() {
	c := time.Tick(5 * time.Second)
	for now := range c {
		fmt.Printf("%v %s\n", now, statusUpdate())
	}
}
```



go time常用方法


Etcd几个关键特征：

**raft算法**：Leader选举/操作同步，无论访问任意节点，都将获得最终一致性数据，高度可靠。

**mvcc**:  etcd有2级存储结构 [B树内存索引](https://github.com/google/btree)  / [bbolt B+树](https://github.com/etcd-io/bbolt) ，内存中使用btree维护key/value索引，节点中存的是bbolt中键值K，通过这个k在bbolt查找，得到的才是用户传进去的value值

- 每个事务有唯一事务id，就是下面的main id int64
- 一个事务可以包含多个修改操作（put/delete），每一个操作就是一个revision, 共享同一个main id
- 一个事务内多个连续修改操作会从0开始递增，编号 sub id int64

```
type revision struct {
	// main is the main revision of a set of changes that happen atomically.
	main int64

	// sub is the sub revision of a change in a set of changes that happen
	// atomically. Each change has different increasing sub revision in that
	// set.
	sub int64
}

type keyIndex struct {
	key         []byte
	modified    revision // the main rev of the last modification
	generations []generation
}
```

内存索引中，每个原始key会关联一个key_index，里面维护了多版本信息

**事务**: 

- 只读事务
- 读写事务



# 概要

- etcd集群

- 配置UI管理界面

- 监控与维护

- 容灾

#### 应用场景

- 服务发现
- 配置中心
- 分布式锁
- 监控机器活动

#### 基础功能

- 监控 watch
- 租约 lease
- 全局锁 lock
- 选举 elect
- 集群状态 
  - `etcdctl --write-out=table endpoint status`
  - `etcdctl endpoint health`
- 快照 snapshot
  - `etcdctl --endpoints=127.0.0.1:2379 snapshot save my.db`
  - `etcdctl --endpoints=127.0.0.1:2379 --write-out=table snapshot status my.db`
- 迁移 migrate
- 成员管理 member
  - `etcdctl --endpoints=127.0.0.1:2379 member list`

- 授权 auth



# 集群配置

`docker-compose.yml`

```yaml
services:
  etcd1:
    image: 'bitnami/etcd:latest'
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_NAME=etcd1
      - ETCD_INITIAL_ADVERTISE_PEER_URLS=http://etcd1:2380
      - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd1:2379
      - ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster
      - ETCD_INITIAL_CLUSTER=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - ETCD_INITIAL_CLUSTER_STATE=new
    networks:
      - app-tier
  etcd2:
    image: 'bitnami/etcd:latest'
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_NAME=etcd2
      - ETCD_INITIAL_ADVERTISE_PEER_URLS=http://etcd2:2380
      - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd1:2379
      - ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster
      - ETCD_INITIAL_CLUSTER=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - ETCD_INITIAL_CLUSTER_STATE=new
    networks:
      - app-tier
  etcd3:
    image: 'bitnami/etcd:latest'
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_NAME=etcd3
      - ETCD_INITIAL_ADVERTISE_PEER_URLS=http://etcd3:2380
      - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd1:2379
      - ETCD_INITIAL_CLUSTER_TOKEN=etcd-cluster
      - ETCD_INITIAL_CLUSTER=etcd1=http://etcd1:2380,etcd2=http://etcd2:2380,etcd3=http://etcd3:2380
      - ETCD_INITIAL_CLUSTER_STATE=new
    networks:
      - app-tier
  etcdkeeper:
    image: deltaprojects/etcdkeeper:latest
    ports:
      - 8080:8080
    networks:
      - app-tier
```

etcdkeeper 连接etcd: `etcd1:2379` ，它们处在同一个network中直接使用服务名就可以

# 服务注册与服务发现

**服务注册：**

1. 申请lease租约，设置服务生存周期ttl，让key自动过期
2. 服务正常状态下，通过keep-alive定期去租约，避免过期
3. key有统一前缀，比如：`etcdctl --endpoints=127.0.0.1:2379 put /sdmaster-service/192.168.31.110   192.168.31.110`

**服务发现：**

1. 服务`watch /sdmaster-service --prefix`
2. `sdmaster-service` 下发生变化都会发生通知

相关代码已经发到github [discovery](https://github.com/douyacun/discovery)

**版本兼容:**

1. 正常安装`github.com/coreos/etcd/clientv3`会存在 `module declares its path as: go.etcd.io/bbolt`

```
go: discovery/discovery-service-protocol/client imports
        github.com/coreos/etcd/clientv3 tested by
        github.com/coreos/etcd/clientv3.test imports
        github.com/coreos/etcd/auth imports
        github.com/coreos/etcd/mvcc/backend imports
        github.com/coreos/bbolt: github.com/coreos/bbolt@v1.3.5: parsing go.mod:
        module declares its path as: go.etcd.io/bbolt
                but was required as: github.com/coreos/bbolt
```

解决方法：

`replace github.com/coreos/bbolt latest => go.etcd.io/bbolt latest`

2. 如果使用grpc的话，会存在grpc版本和etcd不兼容的问题

使用最先版本grpc, 会报`google.golang.org/grpc/naming`缺失

`module google.golang.org/grpc@latest found (v1.33.1), but does not contain package google.golang.org/grpc/naming`

如果降低到1.29.0可以解决这个问题，如果运行代码会报

`undefined: resolver.BuildOption` 

`undefined: resolver.ResolveNowOption`

这是因为grpc版本和etcd不兼容的问题，需要降低版本到 `1.26.0` 以下

解决方法:

```
replace google.golang.org/grpc latest => google.golang.org/grpc v1.26.0
```

3. 目前 protobuf grpc 生成的go代码, 会报错 `undefined grpc.ClientConnInterface` `undefined: grpc.SupportPackageIsVersion6`

```
go get -d -u github.com/golang/protobuf/protoc-gen-go
git -C "$(go env GOPATH)"/src/github.com/golang/protobuf checkout $GIT_TAG
go install github.com/golang/protobuf/protoc-gen-go
```

# go-grpc 负载均衡

正常http负载均衡策略，client -> proxy gateway load balance -> service

grpc提供负载均衡策略，client  load balance -> service 

grpc关键点是负载均衡在客户端

1. 服务端启动时，首先将服务地址注册到服务注册表，定期keepalive健康检测
2. 客户端访问某个服务，watch订阅服务注册表，然后以某种负载均衡策略选择一个目标地址

![](/images/blog/1/architecture/assert/grpc-load-balancing.png)

相关代码已发到github: [go-grpc 负载均衡](https://github.com/douyacun/discovery)

# etcd 配置中心

- 动态加载配置（watch）
- 历史版本（revision）
- 权限控制
- 命名空间

思路:

1. 加载配置文件 put etcd
2. watch prefix 配置变更可以及时变更配置

相关代码已经发到 github : [etcd配置中心](https://github.com/douyacun/etcd/)

# etcd 分布式锁

原理:

1. 租约创建一个key
2. key不存在，创建key，成功获取到锁
3. key存在，无法创建key，获取锁失败

etcd分布式锁的实现在`go.etcd.io/etcd/clientv3/concurrency`包中

1. 初始化sessions

```go
func NewSession(client *v3.Client, opts ...SessionOption) (*Session, error) {
	ops := &sessionOptions{ttl: defaultSessionTTL, ctx: client.Ctx()}
	for _, opt := range opts {
		opt(ops)
	}
	// 初始化租约
	id := ops.leaseID
	if id == v3.NoLease {
		resp, err := client.Grant(ops.ctx, int64(ops.ttl))
		if err != nil {
			return nil, err
		}
		id = v3.LeaseID(resp.ID)
	}
	// 由上层调用控制是否中断
	ctx, cancel := context.WithCancel(ops.ctx)
	keepAlive, err := client.KeepAlive(ctx, id)
	if err != nil || keepAlive == nil {
		cancel()
		return nil, err
	}
	donec := make(chan struct{})
	s := &Session{client: client, opts: ops, id: id, cancel: cancel, donec: donec}
	go func() {
		defer close(donec)
		for range keepAlive {
			// eat messages until keep alive channel closes
		}
	}()
	return s, nil
}
```

2. `func NewMutex(s *Session, pfx string) *Mutex `

初始化`Mutex`

3. `func (m *Mutex) Lock(ctx context.Context) error`

这里类似redis的分布式锁: `set key value NX EX 60`  如果key存在就返回，否则就设置

```go
func (m *Mutex) Lock(ctx context.Context) error {
	s := m.s
	client := m.s.Client()
  // 伪代码
  // if !m.myKey {
  //	client.Put(m.myKey, value)
  // } else {
  // 	client.Get(m.myKey)
	// }
	m.myKey = fmt.Sprintf("%s%x", m.pfx, s.Lease())
	cmp := v3.Compare(v3.CreateRevision(m.myKey), "=", 0)
	put := v3.OpPut(m.myKey, "", v3.WithLease(s.Lease()))
	get := v3.OpGet(m.myKey)
	getOwner := v3.OpGet(m.pfx, v3.WithFirstCreate()...)
	resp, err := client.Txn(ctx).If(cmp).Then(put, getOwner).Else(get, getOwner).Commit()
	if err != nil {
		return err
	}
 	// 此锁是否为自己获得
	m.myRev = resp.Header.Revision
	if !resp.Succeeded {
		m.myRev = resp.Responses[0].GetResponseRange().Kvs[0].CreateRevision
	}
	ownerKey := resp.Responses[1].GetResponseRange().Kvs
	if len(ownerKey) == 0 || ownerKey[0].CreateRevision == m.myRev {
		m.hdr = resp.Header
		return nil
	}
	// 阻塞直到获取到该锁
	hdr, werr := waitDeletes(ctx, client, m.pfx, m.myRev-1)
	if werr != nil {
		m.Unlock(client.Ctx())
	} else {
		m.hdr = hdr
	}
	return werr
}
```

4. `func (m *Mutex) Unlock(ctx context.Context) error` 删除 key

# 推荐阅读

- [高可用分布式存储 etcd 的实现原理](https://draveness.me/etcd-introduction/)
- [etcd使用经验总结](https://alexstocks.github.io/html/etcd.html)





已实现 grpc负载均衡、服务发现、分布式锁、配置中心、

etcd应用场景


[toc]

# CPU高的原因

负载首先看的是top(htop也可以)，可以定位到是哪个进程（线上服务也不会运行多个服务的）

但是进程是因为什么导致的进程负载高？

- **CPU密集型进程**: 使用大量CPU会导致平均负载高，与平均负载一致
- **I/O密集型**: 等待I/O也会导致平均负载升高，但是CPU使用率不一定很高
- **上下文切换**: 大量的上下文切换也会导致CPU负载变高，此时CPU 使用率也会比较高
  - 进程上下文切换
    - 内核调度（优先级/时间片）
    - 系统资源不足
    - sleep
    - 硬件中断
  - 线程上下文切换
  - 中断上下文切换

# 负载

**单核处理器**

"load average"的值越低，比如等于0.2或0.3，就说明电脑的工作量越小，系统负荷比较轻。

系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的

系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。

CPU的系统负荷，基本上等同于上面的类比。大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。

**经验法则**

当系统负荷持续大于0.7，你必须开始调查了，问题出在哪里，防止情况恶化。

当系统负荷持续大于1.0，你必须动手寻找解决办法，把这个值降下来。

当系统负荷达到5.0，就表明你的系统有很严重的问题，长时间没有响应，或者接近死机了。你不应该让系统达到这个值。

**多处理器**

2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。推广开来，n个CPU的电脑，可接受的系统负荷最大为n.0

## 工具

其他工具用法: [高负载定位的常用工具以及用法分析](./负载高定位工具.md)

### Stress:  (模拟负载高的场景) 

> 详细用法来自： [sparkdev](https://www.cnblogs.com/sparkdev/p/10354947.html)

 - `-v`: verbose 详情

 - `-q`: quiet  程序在运行的过程中不输出信息

 - `-n`: dry-run 演练，并不实际执行

 - `-t`: timeout 超时

 - `-c`: 多少进程计算sqrt(平方根)

 - `-i`: 多少进程调用sync(脏页同步到磁盘)

 - `-m`: 多少进程调用内存malloc/free(内存申请释放)

- `--vm-bytes B`  每个进程总计申请多少字节内存

- `--vm-stride B`  内存赋值时间隔多少字节

  不断的给部分内存赋值，让 COW(Copy On Write)发生。只要指定了内存相关的选项，这个操作就会执行，只是大小为默认的 4096。赋值内存的比例由参数决定：

```
for (i = 0; i < bytes; i += stride)
ptr[i] = 'Z';           /* Ensure that COW happens.  */
```
bytes 为消耗的总内存大小，stride 为间隔。
该参数会影响 CPU 状态 us 和 sy：

- us: 用户空间占用CPU百分比
- sy: 内核空间占用CPU百分比

```
$ stress --vm 2 --vm-bytes 500M --vm-stride 64
$ top
%Cpu(s): 21.3 us, 32.1 sy
```

```
$ stress --vm 2 --vm-bytes 500M --vm-stride 1M
$ top
%Cpu(s):  0.7 us, 36.3 sy
```

- `--vm-stride` 值增大就意味着减少赋值，用户空间占用CPU的比率就小了
- `--vm-hang N`: 每个消耗内存的进程在分配到内存后转入睡眠状态 N 秒，然后释放内存，一直重复执行这个过程, CPU空闲出来了，US就会降低了
- `--vm-keep`: 一直占用内存，区别于不断的释放和重新分配(默认是不断释放并重新分配内存)

```
$ stress --vm 2 --vm-bytes 500M --vm-keep
%Cpu(s): 50.4 us,  0.3 sy

$ stress --vm 2 --vm-bytes 500M --vm-hang 5
%Cpu(s):  1.8 us,  7.8 sy
```

- `-d`: （`--hadd`） 产生 N 个不断执行 write 和 unlink 函数的进程(创建文件，写入内容，删除文件)

  - `--hadd-bytes B`  指定文件大小
  
  ```
  $ stress -d 3 --hdd-bytes 10M
  $ pidstat -d 3
  11时34分30秒   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
  11时34分33秒  1000     20879      0.00      1.33      0.00  java
  11时34分33秒     0     23086      0.00 308237.87 309581.40  stress
  11时34分33秒     0     23087      0.00 346640.53 347003.32  stress
  11时34分33秒     0     23088      0.00 329619.93 326591.36  stress
  ```

## 场景一：CPU密集型

```
$ stress -c 1 time 600
$ watch -d uptime

Every 2.0s: uptime
23:39:14 up 10 days, 15:03,  3 users,  load average: 1.17, 0.82, 0.40

$ mpstat -P ALL 5
23时35分39秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
23时35分44秒  all   26.35    0.00    1.00    0.00    0.00    0.05    0.00    0.00    0.00   72.60
23时35分44秒    0    0.60    0.00    1.00    0.00    0.00    0.00    0.00    0.00    0.00   98.40
23时35分44秒    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
23时35分44秒    2    3.41    0.00    1.41    0.00    0.00    0.00    0.00    0.00    0.00   95.18
23时35分44秒    3    1.21    0.00    1.61    0.00    0.00    0.00    0.00    0.00    0.00   97.18
```

CPU密集型是因为进程进行了大量的运算工作的导致的，通过`mpstat`可以轻松判断出来、

> todo: 如何对代码定位问题

特点:

- `usr` 高，进程一直处于用户态运行
- `sys` 低
- `iowait` 低

## 场景二：I/O 密集型

```
$ stress -i 5 --timeout 600
$ watch -d uptime
Every 2.0s: uptime                                                                                  Sat Aug  8 00:18:56 2020
 00:18:56 up 10 days, 15:43,  3 users,  load average: 0.95, 0.75, 0.43
$ mpstat -P ALL 3
13时42分04秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
13时42分07秒  all    2.04    0.00   43.20    1.02    0.00    0.09    0.00    0.00    0.00   53.66
13时42分07秒    0    4.10    0.00   42.66    0.00    0.00    0.00    0.00    0.00    0.00   53.24
13时42分07秒    1    0.68    0.00   43.69    0.34    0.00    0.00    0.00    0.00    0.00   55.29
13时42分07秒    2    2.03    0.00   42.23    0.34    0.00    0.00    0.00    0.00    0.00   55.41
13时42分07秒    3    1.70    0.00   44.22    3.06    0.00    0.00    0.00    0.00    0.00   51.02
$ top
top - 13:49:30 up 12 days,  5:13,  5 users,  load average: 2.07, 1.08, 1.44
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.9 us, 41.4 sy,  0.0 ni, 55.0 id,  0.5 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  7924044 total,  1278284 free,  5345032 used,  1300728 buff/cache
KiB Swap:  2097148 total,  2095868 free,     1280 used.  2109988 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3092 root      20   0    7308     96      0 D  28.2  0.0   0:09.30 stress
 3094 root      20   0    7308     96      0 D  27.9  0.0   0:09.37 stress
 3091 root      20   0    7308     96      0 D  27.6  0.0   0:09.36 stress
 3093 root      20   0    7308     96      0 D  27.6  0.0   0:09.31 stress
 3095 root      20   0    7308     96      0 D  26.9  0.0   0:09.35 stress
```

I/O密集型是因为进行了大量的磁盘读写导致的负载高，其实磁盘和内存之间是有 [**页缓存**](./页缓存.md) 来缓冲磁盘和内存速度差异的，

- 低频的读写文件是不会引起`iowait`偏高的，`iowait`高的原因是因为调用 `sync` / `fsync` 频繁的刷新脏页导致iowait过高，此时是处于内核态运行的所以 `sys`也会偏高
- 高频的大量读写文件会直接触发 脏页刷新，`iowait`/`sys`会较高

而上面`sys`较高，`iowait`低的原因，只是因为高频的调用了`sync`，没有脏页（没有高频的写文件）

## 场景三：大量进程的场景

```
$ stress -c 8 
$ watch -d uptime
Every 2.0s: uptime                                                                                                                Sun Aug  9 13:19:04 2020

 13:19:05 up 12 days,  4:43,  5 users,  load average: 7.44, 3.23, 1.30
$ mpstat -P ALL 3
14时32分28秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
14时32分31秒  all   99.42    0.00    0.58    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    0   99.67    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    1   98.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    2   99.67    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00    0.00
14时32分31秒    3  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
$ pidstat -u 3
14时32分56秒   UID       PID    %usr %system  %guest    %CPU   CPU  Command
14时32分59秒     0     19290    0.00    0.33    0.00    0.33     3  mpstat
14时32分59秒     0     19450    0.33    1.33    0.00    1.67     0  pidstat
14时32分59秒     0     19491   48.67    0.00    0.00   48.67     3  stress
14时32分59秒     0     19492   49.33    0.00    0.00   49.33     1  stress
14时32分59秒     0     19493   48.67    0.00    0.00   48.67     3  stress
14时32分59秒     0     19494   48.67    0.00    0.00   48.67     0  stress
14时32分59秒     0     19495   50.33    0.00    0.00   50.33     2  stress
14时32分59秒     0     19496   48.67    0.00    0.00   48.67     0  stress
14时32分59秒     0     19497   49.33    0.00    0.00   49.33     2  stress
14时32分59秒     0     19498   49.33    0.33    0.00   49.67     1  stress
$ vmstat 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0   1280 1271004    148 1301392    0    0     0     1    5    1  2  1 97  0  0
 8  0   1280 1271000    148 1301380    0    0     0     3 4414 1760 98  2  0  0  0
 8  0   1280 1267432    148 1301368    0    0     0     0 4370 1636 98  2  0  0  0
```

系统是4H8G

- mpstat的4个CPU `usr` 一直是100%
- pidstat的8个stress进程，各占用每个CPU的50%
- vmstat的 `r` 正在运行的进程队列是 8



## 场景四：大量的上下文切换

使用sysbench模拟大量的线程

```
$ sysbench --threads=10 --time=10 threads run
```

```
top - 09:18:26 up 14 days, 42 min,  2 users,  load average: 2.58, 0.66, 1.30
Tasks: 161 total,   1 running, 160 sleeping,   0 stopped,   0 zombie
%Cpu(s): 16.2 us, 76.0 sy,  0.0 ni,  7.8 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  7924044 total,  1689024 free,  5740484 used,   494536 buff/cache
KiB Swap:  2097148 total,  1800444 free,   296704 used.  1734212 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 7640 root      20   0   95116   3972   2824 S 351.5  0.1   1:41.20 sysbench
```

- 负载高
- sy 内核态CPU高
- sysbench 进程

```
$ vmstat -S M 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0    289   1649      0    482    0    0     1     3    8    1  2  1 97  0  0
 7  0    289   1649      0    482    0    0     0     1 23407 347642 14 76  9  0  0
 7  0    289   1648      0    482    0    0     0     0 21909 339189 16 76  8  0  0
 7  0    289   1649      0    482    0    0     0     0 23330 344468 16 75  9  0  0
```

- r: 运行队列高
- in：中断高
- cs：上下文切换次数高

```
$ pidstat -p 7640 -wt 3
09时21分22秒   UID      TGID       TID   cswch/s nvcswch/s  Command
09时21分25秒     0      7640         -      0.00      0.00  sysbench
09时21分25秒     0         -      7640      0.00      0.00  |__sysbench
09时21分25秒     0         -      7641   8870.00  23660.33  |__sysbench
09时21分25秒     0         -      7642  10428.00  20367.67  |__sysbench
09时21分25秒     0         -      7643  10766.67  19406.67  |__sysbench
09时21分25秒     0         -      7644  10391.67  18603.00  |__sysbench
09时21分25秒     0         -      7645  10480.00  21960.33  |__sysbench
09时21分25秒     0         -      7646  10012.67  18224.00  |__sysbench
09时21分25秒     0         -      7647   9655.00  18724.33  |__sysbench
09时21分25秒     0         -      7648  10216.33  20583.00  |__sysbench
09时21分25秒     0         -      7649  10317.67  20421.00  |__sysbench
09时21分25秒     0         -      7650  10450.67  20246.67  |__sysbench
```

通过top知道负载高的原因

- 内核态的运行导致

vmstat定位负载高的原因：

- 上下文切换高导致
- 中断导致
- 运行队列有等待运行进程

pidstat定位负载高的原因：

- 可以看到sysbench 出来很多的子线程

# 负载与参数

分析

- CPU使用率高，如何定位进程和是进程的哪个函数导致的？

## CPU使用率高，如何定位进程和是进程的哪个函数导致的？

CPU使用率高定位是哪个进程，我们可以使用的工具有：

- top/htop
- pidstat
- ps

如何定位是进程的哪个函数导致的？







借助stress、iostat、mpstat、pidstat定位负载高的进程

服务器CPU高问题排查思路


[toc]

# top(系统正在执行的进程的相关信息)

top是我定位问题的想到的第一个命令，用的最多的命令

```
top - 13:49:30 up 12 days,  5:13,  5 users,  load average: 2.07, 1.08, 1.44
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.9 us, 41.4 sy,  0.0 ni, 55.0 id,  0.5 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  7924044 total,  1278284 free,  5345032 used,  1300728 buff/cache
KiB Swap:  2097148 total,  2095868 free,     1280 used.  2109988 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3092 root      20   0    7308     96      0 D  28.2  0.0   0:09.30 stress
 3094 root      20   0    7308     96      0 D  27.9  0.0   0:09.37 stress
 3091 root      20   0    7308     96      0 D  27.6  0.0   0:09.36 stress
 3093 root      20   0    7308     96      0 D  27.6  0.0   0:09.31 stress
 3095 root      20   0    7308     96      0 D  26.9  0.0   0:09.35 stress
```

第一行：(同uptime显示的信息) 系统时间、当前登录用户数，负载均衡：1分钟 5分钟 15分钟

第二行：进程统计数据

- total: 进程数
- running：运行进程数
- slepping：处于休眠状态的进程数
- stopped：停止的进程数
- zombie：僵尸进程数

第三行: CPU统计数据，百分比

- us：用户态占比
- sy：内核态占比
- ni：改变过优先级的进程占用CPU的百分比
- id：空闲占比
- wa：io等待占比
- hi：软中断
- si：硬中断

> 显示每个CPU的运行情况，按 1

第四行/第五行：内存的统计数据

- total：总内存
- free：空闲内存
- used：使用中的内存
- buff：用作内核缓冲区的内存

表格各字段含义：

| PID    | USER     | PR                 | NI  |VIRT| RES |SHR|
| ------ | -------- | ------------------ | ---- |---| ---|---|
| 进程号 | 运行用户 | 优先级，越小越优先 |      |虚拟内存| 物理内存 |共享内存|

---

| SHR      | S        | %CPU |%MEM|TIME+|COMMAND|
| -------- | -------- | ---- |---|---|---|
| 共享内存 | 进程状态 | CPU使用百分比 |内存使用百分比|占用CPU使用时间的累加值|运行命令|

进程状态:

- R:(Running) 运行状态
- D:(uninterruptible slepp) 不可中断睡眠状态，等待IO资源时会出现
- S:(Sleep) 睡眠状态
- T:(Stop) 终止状态，调试会进入终止状态
- Z:(Zombie) 僵尸进程

top命令操作指令:

- c: 显示完全命令
- P: CPU使用率排序
- M: 内存使用率排序
- T: 按占用CPU的总时间排序
- R: 高亮正在运行的程序
- q: 退出


# mpstat: (单个CPU维度的统计数据)

- `-P`: 指定CPU编号
  - `ALL`: 全部CPU

```
$ mpstat -P ALL 2 5
```

显示所有的进程，每2秒显示一次

# pidstat: (进程线程级别的统计数据)

sysstat工具的一个命令, 监控全部或指定进程的CPU、内存、线程、设备IO等系统资源的占用情况,`pidstat`首次运行时显示自系统启动开始的各项统计信息，之后运行`pidstat`将显示自上次运行该命令以后的统计信息

- `-C`: 正则匹配 启动命令 关键字

- `-l`: 显示 命令详情，包括启动参数

- `-p`: 指定进程号
  - `SELF`: 直显示pidstat的统计数据
  - `ALL`: 显示所有进程的统计数据

- `-r`: 内存统计数据

  ```
  $ pidstat -r -l 3
  平均时间:   UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
  平均时间:     0         1      4.07      0.00  191024   4068   0.05  /usr/lib/systemd/systemd --switched-root --system --deserialize 22
  平均时间:     0       780      1.44      0.00   21656   1224   0.02  /usr/sbin/irqbalance --foreground
  平均时间:     0       913      0.07      0.00  714272  18072   0.23  /data/frp/frp_0.33.0_linux_amd64/frpc -c /data/frp/frp_0.33.0_linux_amd64/frpc.ini
  平均时间:     0      1784      0.00      0.00 1621172  48480   0.61  /usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --default-runtime=docker-runc --exec
  平均时间:  1000     20879      5.96      0.00 8038196 4665088  58.87  /usr/share/elasticsearch/jdk/bin/java -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPre
  平均时间:  1000     21111    111.54      0.00 1735056 361671   4.56  /usr/share/kibana/bin/../node/bin/node /usr/share/kibana/bin/../src/cli --cpu.cgroup.path.override=/ --cpuacct.cgroup.path.over
  平均时间:     0     26952     69.29      0.00  108356   1223   0.02  pidstat -r -l 3
  平均时间:     0     28871      0.04      0.00  160888   5812   0.07  sshd: root@pts/0,pts/1,pts/2,pts/4
  ```

- `-s`: 堆栈利用率

  - `StkSize`: 预留内存，但是未使用
  - `StkRef`: 已经使用的内存

- `-d`:  I/O 的统计数据

  ```
  $ pidstat -d 3
  11时34分30秒   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
  11时34分33秒  1000     20879      0.00      1.33      0.00  java
  11时34分33秒     0     23086      0.00 308237.87 309581.40  stress
  11时34分33秒     0     23087      0.00 346640.53 347003.32  stress
  11时34分33秒     0     23088      0.00 329619.93 326591.36  stress
  ```

  - `kB_rd/s` : 每秒读磁盘
  - `KB_wr/s`:  每秒写磁盘
  - `KB_ccwr/s`: 脏页刷新数

- `-T`: 是否显示子进程/子线程

  - `TASK`: 不显示子进程/子线程
  - `CHILD`: 显示指定进程和其子进程/子线程
  - `ALL`: 显示所有进程和其子进程/子线程

- `-w`: 上下文切换统计数据

  - `cswch/s` : 每秒自愿上下文切换次数
  - `nvcswch/s`: 每秒非自愿上下文切换次数

- `-t`: 显示子线程

  - 显示进程号(TGID)和线程号(TID)

- `-u`: CPU统计数据

- `-U`: 指定用户

# vmstat: (虚拟内存状态)

`-S` :  k, K, m or M 显示单位，默认kb

```
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   1280 1247128    148 1326668    0    0     0     1    1    7  2  1 97  0  0
 0  0   1280 1247440    148 1326664    0    0     0     0  821 1592  2  1 97  0  0
 0  0   1280 1247316    148 1326664    0    0     0     7  342  396  2  0 98  0  0
 0  0   1280 1248076    148 1326660    0    0     0     0  869 1462  3  1 96  0  0
```

procs (进程)

- r：运行队列中进程数量
- b: 等待IO的进程数量

memory(内存)

- swpd: 虚拟内存大小
- free：空闲物理内存大小
- buffer 缓冲区的内存大小
- cache 缓存的内存大小

swap

- si：从磁盘写入内存的大小
- so：从内存到磁盘的大小

io（每块1KB）

- bi：每秒读取的块数
- bo：每秒写入的块数

system

- in：每秒中断次数
- cs：没秒上下文切换的次数

CPU：

- us：用户态百分比
- sy：内核态百分比
- id：空闲百分比
- wa：等待io的百分比

# sysbench 基础测试工具

1. cpu性能
2. 磁盘IO性能
3. 调度程序性能
4. 内存分配及传输速度
5. POSIX线程性能
6. 数据库性能

使用姿势：

```
sysbench [options]... [testname] [command]
```

options：

- --threads: 线程数
- --time： 运行时间 秒
- --thread-stack-size： 每个线程堆栈大小

testname:

- fileio: 磁盘io性能
- cpu： cpu性能
- memory:  内存分配及传输速度
- threads：posix线程性能
- mutex： 互斥锁性能测试

commands:

- prepare: 准备阶段
- run： 运行
- cleanup：清理
- help： 帮助

**线程性能压测**

> 线程无需prepare和cleanup 直接run即可

```shell
$ sysbench --threads=10 threads run
General statistics:
    total time:                          10.0208s
    total number of events:              5342

Latency (ms):
         min:                                    2.36
         avg:                                   18.73
         max:                                  152.47
         95th percentile:                       70.55
         sum:                               100069.68

Threads fairness:
    events (avg/stddev):           534.2000/22.05
    execution time (avg/stddev):   10.0070/0.01
```

**数据库性能压测**

社区提供的脚本：

```
/usr/share/sysbench/bulk_insert.lua
/usr/share/sysbench/oltp_common.lua
/usr/share/sysbench/oltp_delete.lua
/usr/share/sysbench/oltp_insert.lua
/usr/share/sysbench/oltp_point_select.lua
/usr/share/sysbench/oltp_read_only.lua
/usr/share/sysbench/oltp_read_write.lua
/usr/share/sysbench/oltp_update_index.lua
/usr/share/sysbench/oltp_update_non_index.lua
/usr/share/sysbench/oltp_write_only.lua
/usr/share/sysbench/select_random_points.lua
/usr/share/sysbench/select_random_ranges.lua
```

>  On-Line Transaction Processing联机事务处理过程(*OLTP*)

准备数据（prepare）：

```shell
$ sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password='' --mysql-db=sbtest --db-driver=mysql --tables=10 --table-size=1000000 --report-interval=10 --threads=128 --time=120 prepare
```

压测 (run):

```shell
$ sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password='' --mysql-db=sbtest --db-driver=mysql --tables=10 --table-size=1000000 --report-interval=10 --threads=128 --time=120 run
```

```
[ 10s ] thds: 128 tps: 83.61 qps: 1460.28 (r/w/o: 1280.37/0.00/179.91) lat (ms,95%): 3151.62 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 128 tps: 114.82 qps: 1829.74 (r/w/o: 1600.00/0.00/229.74) lat (ms,95%): 3267.19 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 128 tps: 116.70 qps: 1862.06 (r/w/o: 1628.67/0.00/233.40) lat (ms,95%): 3208.88 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 128 tps: 125.20 qps: 2015.85 (r/w/o: 1765.55/0.00/250.29) lat (ms,95%): 1803.47 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 128 tps: 123.80 qps: 1954.32 (r/w/o: 1706.71/0.00/247.60) lat (ms,95%): 1618.78 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 128 tps: 119.30 qps: 1925.28 (r/w/o: 1686.69/0.00/238.60) lat (ms,95%): 1771.29 err/s: 0.00 reconn/s: 0.00
[ 70s ] thds: 128 tps: 119.49 qps: 1922.65 (r/w/o: 1683.77/0.00/238.88) lat (ms,95%): 1739.68 err/s: 0.00 reconn/s: 0.00
[ 80s ] thds: 128 tps: 120.21 qps: 1919.50 (r/w/o: 1679.09/0.00/240.41) lat (ms,95%): 1771.29 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 128 tps: 121.11 qps: 1931.94 (r/w/o: 1689.52/0.00/242.42) lat (ms,95%): 1739.68 err/s: 0.00 reconn/s: 0.00
[ 100s ] thds: 128 tps: 121.90 qps: 1964.95 (r/w/o: 1721.16/0.00/243.79) lat (ms,95%): 1618.78 err/s: 0.00 reconn/s: 0.00
[ 110s ] thds: 128 tps: 122.40 qps: 1943.02 (r/w/o: 1698.23/0.00/244.79) lat (ms,95%): 1803.47 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 128 tps: 120.79 qps: 1928.00 (r/w/o: 1686.71/0.00/241.29) lat (ms,95%): 1648.20 err/s: 0.00 reconn/s: 0.00
SQL statistics:
    queries performed:
        read:                            199108 // 总select数量
        write:                           0
        other:                           28444
        total:                           227552
    transactions:                        14222  (117.57 per sec.) // tps
    queries:                             227552 (1881.20 per sec.) // qps
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          120.9538s
    total number of events:              14222

Latency (ms):
         min:                                   13.84 // 最小响应时间
         avg:                                 1084.70 // 平均响应时间
         max:                                 5281.53 // 最大响应时间
         95th percentile:                     2120.76 // 95分位响应时间
         sum:                             15426627.71 // 总时间

Threads fairness:
    events (avg/stddev):           111.1094/4.84
    execution time (avg/stddev):   120.5205/0.26
```

> 这是早期的联想电脑装的linux，本身不带固态，4H8G配置

清理数据：

```shell
$ sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password='' --mysql-db=sbtest --db-driver=mysql --tables=10 --table-size=1000000 --report-interval=10 --threads=128 --time=120 cleanup
```

**磁盘IO压测**

options：

- --file-num=N  文件数量 128

- --file-block-size=N 写入块的大小 16K

- --file-total-size=SIZE 每个文件的大小 2G

- --file-test-mode=STRING 

  - seqwr（顺序写）
  - seqrewr（顺序读写）
  - seqrd（顺序读）
  - rndrd（随机读）
  - rndwr（随机写）
  - rndrw（随机读写）

- --file-io-mode=STRING 

  - sync 同步 默认
  - async 异步
  - mmap map映射

- --file-fsync-freq=N 调用fysnc同步磁盘的频率 （0不调用）100

- --file-fsync-all=[off|on] 每次写完文件立即 fsync  off

- --file-fsync-end=[off|on] 测试结束执行 fsync on

- --file-fsync-mode=STRING

  - fsync 默认

  - fdatasync 

  - > sync 只是将修改过的块缓冲区加入同步队列，直接返回，不等待写磁盘操作完成
    >
    > fsync 只对单一文件起作用，等待写磁盘完成，fsync会同步文件属性
    >
    > fdatasync 只同步文件数据部分

- --file-merged-requests=N 合并IO请求 0（不合并）
- --file-rw-ratio=N 读写比例 1.5 （2:1）

# lsof(列出系统打开的工具)

主要用途：查看进程打开的mysql连接，文件，网络连接等

1. 普通文件
2. 目录
3. 网络文件系统的文件
4. 字符或设备文件
5. (函数)共享库
6. 管道，命名管道
7. 符号链接
8. 网络文件（例如：NFS file、网络socket，unix域名socket）
9. 还有其它类型的文件，等等

**命令参数**

- `-c <进程名>` 
  - `losf -c mysqld`： 列出mysql进程打开的文件
- `+d <目录>` 列出目录下被打开的文件
  - `lsof +d /data/mysql` 列出 /data/mysql 目录下被打开的文件
- `+D <目录>` 递归列出目录下被打开的文件
- `-i <条件> ` 列出符合条件的进程 
  - `lsof -i 4` / `lsof -i 6`：列出打开ipv4/ipv6网络的进程
  - `lsof -i @<域名>`：列出与域名建立连接的进程
  - `lsof -i :<端口>`：列出占用端口的进程
  - `losf -i tcop -p 1969`: 列出1969进程建立的所有tcp连接
- `-p <进程号>` 
  - `lsof -p 1969` 列出 1969 进程 打开的文件



高负载定位的常用工具以及用法分析


这篇文章目的

-   熟悉kong的配置
-   线上已经在运行openresty，如何无缝接入kong
-   如何配置一个service
-   路由如何匹配，header/path/method/source/destination/SNI 如何配置
-   多个路由同时匹配优先级如何匹配
-   豆瓣是否如何对匿名用户和授权用户进行不同频率限流访问的
-   kong是如何支持蓝绿部署，金丝雀部署
-   kong的健康检测和熔断机制

[toc]

# 配置



## 注入kong nginx指令

`nginx_http_` 会注入到 `http` 块下面

`nginx_proxy_` 注入到kong 代理端口 `server` 块下面

```nginx
server {
    server_name kong;
    listen 0.0.0.0:8000 reuseport backlog=16384;
    listen 0.0.0.0:8443 ssl http2 reuseport backlog=16384;
	# ...
    # injected nginx_proxy_* directives
    real_ip_header X-Real-IP;
    real_ip_recursive off;
    # ...
}
```

`nginx_admin_` 注入到kong 管理端口 `server` 块下面

```nginx
server {
    server_name kong_admin;
    listen 127.0.0.1:8001 reuseport backlog=16384;
    listen 127.0.0.1:8444 ssl http2 reuseport backlog=16384;
	# ...
    # injected nginx_admin_* directives
    location / {
        default_type application/json;
        content_by_lua_block {
            Kong.admin_content()
        }
        header_filter_by_lua_block {
            Kong.admin_header_filter()
        }
    }
    # ...
}
```

### 配置server块

新增配置文件

```nginx
server {
  listen 2112;
  location / {
    # ...more settings...
    return 200;
  }
}
```

`kong.conf`  `nginx_http_include` 引入此配置文件

```nginx
nginx_http_include = /path/to/your/my-server.kong.conf
```

## 自定义kong nginx模版

极少用到

-   kong.conf 配置命令无法满足
-   线上已经在运行openresty实例，可以使用kong生成配置文件并且引入

### 模版

```
/usr/local/kong
├── nginx-kong.conf
└── nginx.conf
```

重启命令

```
kong start -c kong.conf --nginx-conf custom_nginx.template
```

## 嵌入kong到openresty中

kong下的文件，kong是openresty的插件，索引如果线上已经有openresty在运行的话，可以无缝衔接

```shell
[root@ali conf]# ll /usr/local/kong/
total 292
drwxr-xr-x 2 root   root   4096 May 28 14:31 bin
drwx------ 2 nobody root   4096 May 28 15:30 client_body_temp
-rw-r--r-- 1 root   root 234703 Apr 25 00:45 COPYRIGHT
drwx------ 2 nobody root   4096 May 28 15:30 fastcgi_temp
drwxr-xr-x 3 root   root   4096 May 28 14:31 include
drwxr-xr-x 4 root   root   4096 May 28 14:31 lib
drwxr-xr-x 2 root   root   4096 May 28 15:30 logs
-rw-r--r-- 1 root   root    297 Jun  1 19:18 nginx.conf
-rw-r--r-- 1 root   root   7807 Jun  1 19:18 nginx-kong.conf
-rw-r--r-- 1 root   root   1821 Jun  1 19:18 nginx-kong-stream.conf
drwxr-xr-x 2 root   root   4096 Jun  4 15:25 pids
drwx------ 2 nobody root   4096 May 28 15:30 proxy_temp
drwx------ 2 nobody root   4096 May 28 15:30 scgi_temp
drwxr-xr-x 2 root   root   4096 May 28 15:30 ssl
drwx------ 2 nobody root   4096 May 28 15:30 uwsgi_temp
```

启动方式:

```shell
$ /usr/local/openresty/nginx/sbin/nginx -p /usr/local/kong -c /usr/local/kong/nginx.conf
```

# Proxy

service/route/plugins

## service

可以通过rest api创建一个service，url指向服务

```shell
curl -i -X POST http://localhost:8001/services/ \
    -d 'name=foo-service' \
    -d 'url=http://foo-service.com'
```

url会自动解析:

-   Protocol
-   host
-   port
-   path

重试机制:

-   retries 实现方式是nginx的 [**proxy_next_upstream_tries**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_tries) 模块提供的功能，如果service response error，nginx会再次请求upstream

超时时间:

-   Connect timeout
-   Write timeout
-   Read timeout

## route

### 匹配规则

kong支持http/https,tcl/tls,grpc/grpcs协议的代理

-   `http`: `methods`, `hosts`, `headers`, `paths` (and `snis`, if `https`)
-   `tcp`: `sources`, `destinations` (and `snis`, if `tls`)
-   `grpc`: `hosts`, `headers`, `paths` (and `snis`, if `grpcs`)

匹配规则:

-   必须命中所有的字段
-   至少命中字段配置的一个值

```
{
    "hosts": ["example.com", "foo-service.com"],
    "paths": ["/foo", "/bar"],
    "methods": ["GET"]
}
```

以下可以命中路由, host、path、method 均可以匹配到

```
GET /foo/hello/world HTTP/1.1
Host: example.com

GET /bar HTTP/1.1
Host: foo-service.com

GET /foo HTTP/1.1
Host: example.com
```

以下无法命中路由

```
# path没有命中
GET / HTTP/1.1
Host: example.com
# method没有命中
POST /foo HTTP/1.1
Host: example.com
# host没有命中
GET /foo HTTP/1.1
Host: foo.com
```

#### request header

#### host

**指定多个host**

`json`

```shell
curl -i -X POST http://localhost:8001/routes/ \
    -H 'Content-Type: application/json' \
    -d '{"hosts":["example.com", "foo-service.com"]}'
```

`form`

```shell
curl -i -X POST http://localhost:8001/routes/ \
    -d 'hosts[]=example.com' \
    -d 'hosts[]=foo-service.com'
```

**通配符**

只能使用1个*，在左边或最右边

```json
{
    "hosts": ["*.example.com", "service.*"]
}
```

**preserve_host**

kong默认会把请求host替换成upstream的host

upstream target host

```json
{
  "created_at": 1591585408.555,
  "upstream": {
    "id": "6baccef1-2b15-44b8-b1a5-49fce6452487"
  },
  "id": "5b4c2ac4-27c5-42bb-9ec2-41ed6c3c3e75",
  "target": "docker.for.mac.host.internal:9003",
  "weight": 100,
  "health": "HEALTHY"
}
```

打印一下请求头（其他无关请求头忽略）

```json
{
    "code": 0,
    "message": "success",
    "data": {
        "header": {
            "X-Forwarded-For": [
                "172.21.0.1"
            ],
            "X-Forwarded-Host": [
                "douyacun.io"
            ],
            "X-Forwarded-Port": [
                "8000"
            ],
            "X-Forwarded-Proto": [
                "http"
            ],
            "X-Real-Ip": [
                "172.21.0.1"
            ]
        },
        "host": "docker.for.mac.host.internal:9003"
    }
}
```

关闭preserve_host

```json
{
    "code": 0,
    "message": "success",
    "data": {
        "header": {
            "X-Forwarded-For": [
                "172.21.0.1"
            ],
            "X-Forwarded-Host": [
                "douyacun.io"
            ],
            "X-Forwarded-Port": [
                "8000"
            ],
            "X-Forwarded-Proto": [
                "http"
            ],
            "X-Real-Ip": [
                "172.21.0.1"
            ]
        },
        "host": "douyacun.io:8000"
    }
}
```

#### 其他header

kong支持通过header来匹配路由

![](/images/blog/1/architecture/assert/kong-route-header.png)

header中需要添加`version:v1`, 才可以匹配到路由

```shell
GET /api/kong/preserve_host HTTP/1.1
version: v1
```

否则:

```
An invalid response was received from the upstream server
```

#### path

kong url path 匹配必须符合前缀匹配

```json
{
    "paths": ["/api"]
}
```

以下是可以匹配到路由的

```
GET /api/kong/preserve_host HTTP/1.1
Host: douyacun.io
```

默认情况下，kong代理到upstream不会改变url path

**正则路径**

kong支持正则路径和前缀路径匹配

```json
{
    "paths": ["/users/\d+/profile", "/following"]
}
```

```
GET /users/123/profile HTTP/1.1
Host: ...
```

**优先级**

正则匹配可以使用`regex_priority`指定优先级，否则最长前缀路径优先匹配,最多规则有限匹配

```json
[
    {
        "paths": ["/status/\d+"],
        "regex_priority": 0
    },
    {
        "paths": ["/version/\d+/status/\d+"],
        "regex_priority": 6
    },
    {
        "paths": ["/version"],
    },
    {
        "paths": ["/version/any/"],
    }
]
```

1.  `/version/\d+/status/\d+`
2.  `/status/\d+`
3.  `/version/any/`
4.  `/version`

**strip path**

像nginx alias的用法, 去掉前缀路由发送给upstram， 默认是启用状态

`service`

```json
{
  "path": "/",
}
```

path 是 `/api` , 这个path是作为路由前缀的

`route`

```json
{
  "paths": [
    "/api"
  ]
}
```

strip path 开启状态

```
GET /api/articles HTTP/1.1
Host: ...

404 page not found
```

upstream 接收到的请求

```
GET /articles HTTP/1.1
Host: ...
```

**method**

通过请求方法发送过滤路由

`GET`  `POST` `HEAD` `PUT`

**source**

通过请求涞源ip/port过滤路由

`10.1.0.0/16` 



# Authentication

流程：

1. 为service创建一个plugin
2. 创建一个consumer
3. 为consumer创建一个credentials
4. 请求进入时，首先会验证权限

## Consumers

主要用于自定义请求行为，为安卓/iOS创建一个consumer, 或者每个版本、每个平台创建一个consumer。这是一个不透明的概念，所以称为consumer而不是用户

## Anonymous Access

匿名访问和鉴权访问同时存在

对匿名访问进行 低频 限流，对授权用户有 高频限流

流程:

1. 创建service

2. 创建route

3. 创建key-auth plugin

   ```shell
   curl -i -X POST \
      --url http://localhost:8001/services/douyacun/plugins/ \
      --data 'name=key-auth'
   ```

4. 创建anonymous Consumer

   ```shell
   curl -i -X POST \
      --url http://localhost:8001/consumers/ \
      --data "username=anonymous_users"
      
   HTTP/1.1 201 Created
   Content-Type: application/json
   Connection: keep-alive
   
   {
      "username": "anonymous_users",
      "created_at": 1428555626000,
      "id": "bbdf1c48-19dc-4ab7-cae0-ff4f59d87dc9"
   }
   ```

5. 允许anonymous Consumer访问

   ```shell
   curl -i -X PATCH \
      --url http://localhost:8001/plugins/<your-plugin-id> \
      --data "config.anonymous=<上一步anonymous Consumer生成的id>"
   ```

最终结果,原本需要授权的url现在不授权也可以访问了, 授权的consumer也可以正常访问

![](/images/blog/1/architecture/assert/anonymous-consumer.png)

6 . 针对匿名consumer创建rate limit plugin, 针对授权consumer创建rate limit plugin

```shell
curl -i -X POST \
   --url http://localhost:8001/services/douyacun/plugins/ \
   --data 'name=rate-limiting'
   --data 'config.minute=5'
   --data 'consumer.id=<匿名账户id>'
```

7. 验证 如果没有授权访问，每分钟超过5次就会被限流

```shell
{
    "message": "API rate limit exceeded"
}
```

# 负载均衡

DNS-based loadbalancing/ring-balancer

DNS负载均衡，节点不是向kong注册服务，而是向DNS服务器提供注册，kong使用域名就可以了，

DNS各级都有缓存，缓存时间难以把控，不方便做健康检测移除不可用节点 (不推荐使用)

## ring-balancer

使用ring-balancer，需要向kong进行服务注册, 使用http注册以后可以立即获取流量

**upstream**: 虚拟hostname，route可以使用upstream name当作hostname

**target**: ip/port 每个node 都会有weight权重，决定承担多少流量

### upstram

修改target的成本较小，修改upstram的成本较大

slots: 根据最多设置多少个target算出，假设设置10个target，那么slot就是 `10 * 100`,  用于负载均衡算法，(todo:令牌?)

### target

target只支持创建/删除，不支持修改，如果要改权重，删除之前的taget然后新创建一个target

target自动清理，不活跃target比活跃target多10个时会自动清理不活跃target

### 负载算法

`hash_on`

-   **none**： 加权轮询

-   **consumer**: 按照consumer id hash，负载到不同的机器

-   **ip**：按照 ip hash

-   **header**：按照指定header hash
    -   `hash_on_header` 指定header 
    -   `hash_fallback_header` ：`hash_on_header` 缺失时，替补

-   **cookie**: 按cookie hash
    -   `hash_on_cookie`: 指定cookie name
    -   `hash_on_cookie_path`: 指定cookie path

`hash_fallback`

`hash_on` 返回的hash值为空，hash_fallback指定替代品

### 注意事项

-   target尽量不要使用域名，域名解析也是需要一定时间
-   确保hash值有较好的方差平均分布
    -   3个consumer，几十万的用户的 建议按ip hash
    -   如果用户大多集中在统一个地区，使用同一个NAT gateway(因为大家的ip都是同一个)，建议使用cookie hash

## 蓝绿部署

一个是当前运行的生产环境，接收所有的用户流量（称之为蓝）。另一个是它的副本，但是闲置（称之为绿）。两者使用相同的数据库后端和应用配置

应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。

过程：

1.  创建service
2.  创建route
3.  创建green upstream + target
4.  创建blue upstream + target
5.  发布时 切换service hostname 为green hostname

## 金丝雀部署（灰度发布）

和蓝绿部署很像，区别在于可以阶段性进行，不用一次性全切流量

金丝雀部署可以在生产环境中基础设施小范围部署新的应用代码，一旦应用部署发布，只有少数用户被路由到，最大程度降低影响

-   在允许外部用户访问之前，将内部用户暴露给金丝雀部署；
-   基于源 IP 范围的路由；
-   在特定地理区域发布应用；
-   使用应用程序逻辑为特定用户和群体解锁新特性。当应用为其他用户上线后，移除此逻辑。

kong的实现方式使用通过设置target权重来分配流量

```
# first target at 900
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.17:80"
    --data "weight=900"

# second target at 100
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.18:80"
    --data "weight=100"
```

# 健康检测&熔断机制

kong支持2种健康检测，可以单独使用也可以结合使用：

-   主动监测，定期请求提供的http/https接口，根据响应决定target是否健康状态
-   被动检测，分析正在代理的流量请求，根据响应局定target是否健康状态

## 健康/非健康

每一个target都有独自的健康检测

健康检测的规则

-   响应码 200 Success，增加`Success`计数，重置其他计数
-   connect fail，增加`TCP failures`计数，重置`Success`计数
-   timeout,  增加`timeouts`计数，重置`Success`计数
-   响应码非 200 Success，增加`Http Failures`计数，重置`success`计数

如果`TCP failures` / `timeouts` / `Http Failures` 次数达到配置的阀值，target会被标记为unhealthy

如果`Success ` 次数达到配置阀值后，target会被重新标记为healthy

## 健康检查配置

### 主动检测

`healthchecks.active.http_path`： 设置target 健康检测接, 默认`/`，常用`ping`

`healthchecks.active.healthy.interval`:  健康target间隔多少秒进行一次检测，0不检测

`healthchecks.active.unhealthy.interval`：非健康target间隔多少进行一次检测

`healthchecks.active.type`: 指定协议http/https

`healthchecks.active.timeout`: 连接超时时间，默认1s

`healthchecks.active.concurrency`: 一次请求多少个target

`healthchecks.active.healthy.successes`： 健康检测成功多少次认为是健康

`healthchecks.active.unhealthy.tcp_failures`: 连接失败多少次判定target非健康

`healthchecks.active.unhealthy.timeouts`: 请求超时次数判定target非健康

`healthchecks.active.unhealthy.http_failures`： 非 (`healthchecks.active.unhealthy.http_statuses` 定义的状态码) 响应多少次判定target非健康

### 被动检测

`healthchecks.passive.healthy.successes`: 非健康节点检测

`healthchecks.active.unhealthy.tcp_failures`: 连接失败多少次判定target非健康

`healthchecks.active.unhealthy.timeouts`: 请求超时次数判定target非健康

`healthchecks.active.unhealthy.http_failures`： 非 (`healthchecks.active.unhealthy.http_statuses` 定义的状态码) 响应多少次判定target非健康

### 禁用健康检测

设置间隔时间为0就关闭检测`healthchecks.active.healthy.interval`  / `healthchecks.active.unhealthy.interval`

线上已经在运行openresty，如何无缝接入kong

kong进阶

go opentracing 实践与落地


本篇文档目的:

1.  使用docker或centos7部署一套kong的环境
2.  使用kong代理到本地服务
3.  熟悉kong限流和鉴权
4.  负载均衡

# 安装

docker、centos7安装

## docker

[官网](https://docs.konghq.com/install/docker/?_ga=2.181811879.1832554820.1590497490-1678089697.1590497490) 有完整介绍

创建桥接网络，kong和postgres在同一网段中

```shell
$ docker network create kong-net
```

使用postgres存储，这里需要指定密码负责postgres会启动不起来

```shell
$ docker run -d --name kong-database \
--network=kong-net \
-p 5432:5432 \
-e "POSTGRES_USER=kong" \
-e "POSTGRES_DB=kong" \
-e "POSTGRES_PASSWORD=kong" \
postgres:9.6
```

`docker ps -a` 确认一下是否启动了postgres

初始化数据库

```shell
$ docker run --rm \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     kong:latest kong migrations bootstrap
```

启动kong

```shell
$ docker run -d --name kong \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
     -p 8000:8000 \
     -p 8443:8443 \
     -p 127.0.0.1:8001:8001 \
     -p 127.0.0.1:8444:8444 \
     kong:latest
```

查看空是否启动成功:

```shell
$ curl -i http://localhost:8001/
```

安装kong管理界面：

```shell
$ docker run -d -p 1337:1337 \
             --network kong-net \
             --name konga \
             -e "NODE_ENV=production" \
             -e "TOKEN_SECRET=kong" \
             pantsel/konga
```

配置konga，连接kong，因为在同一个网络可以使用容器name做为host连接容器

![](/images/blog/1/architecture/assert/konga-connection.png)

## centos 7

### 安装PostgreSQL

**yum 安装**

安装步骤官网较全

[https://www.postgresql.org/download/linux/redhat/](https://www.postgresql.org/download/linux/redhat/)

```shell
$ yum install -y postgresql10-server  postgresql10  postgresql10-contrib
```

**初始化数据库**

```shell
$ /usr/pgsql-10/bin/postgresql-10-setup initdb
```

**启动数据库**

```shell
$ systemctl enable postgresql-10.service
```

**允许远程连接**

` /var/lib/pgsql/10/data/postgresql.conf`

```shell
$ listen_addresses = '0.0.0.0'
```

**连接验证**

` /var/lib/pgsql/10/data/pg_hba.conf`

```conf
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             127.0.0.1/32            trust
# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            ident
host    replication     all             ::1/128                 ident
host    all             all             0.0.0.0/0               trust
```

注意放在最上面，否则本地连接的话会优先命中

`host    replication     all             127.0.0.1/32            ident`

```shell
Ident authentication failed for user "kong"
```

### 安装kong

**yum安装**

```shell
$ sudo wget -O kong-2.0.4.el7.amd64.rpm https://bintray.com/kong/kong-rpm/download_file?file_path=centos/7/kong-2.0.4.el7.amd64.rpm
$ sudo yum install kong-2.0.4.el7.amd64.rpm
$ kong -h
```

**创建数据库**

```shell
$ sudo -u postgres psql
```

```plsql
 CREATE USER kong; 
 CREATE DATABASE kong OWNER kong;
 \du;
```

常用命令

```
\password           设置密码。
\q                  退出。
\h                  查看SQL命令的解释，比如\h select。
\?                  查看psql命令列表。
\l                  列出所有数据库。
\c [database_name]  连接其他数据库。
\d                  列出当前数据库的所有表格。
\d [table_name]     列出某一张表格的结构。
\du                 列出所有用户。
\e                  打开文本编辑器。
\conninfo           列出当前数据库和连接的信息。
```

**配置文件**

`/etc/kong/kong.conf`

```ini
database = postgres
pg_host = 127.0.0.1
pg_port = 5432
pg_user = kong
pg_database = kong
proxy_listen = 0.0.0.0:80
declarative_config = /etc/kong/kong.yml
```

**迁移数据库**

```
kong migrations bootstrap -c /etc/kong/kong.conf
```

# 概念

架构图

![](/images/blog/1/architecture/assert/Kong-GS-overview.png)

| Concept/Feature | Description                                                  |
| :-------------- | :----------------------------------------------------------- |
| Service         | 多个 Upstream 的集合，是 Route 的转发目标                    |
| Routes          | 求的转发规则，按照 Hostname 和 PATH，将请求转发给 Service    |
| Consumers       | API 的用户，记录用户信息                                     |
| REST API        | 通过 REST API 进行配置管理，从繁琐的配置文件中解放           |
| 插件            | 提供众多开箱即用的插件，且有易于扩展的自定义插件接口，可以使用 Lua 自行开发插件 |
| 限流            | 可以通过插件实现单个服务某些接口的限流，避免服务过载导致不可用 |
| 鉴权            | 权限控制，IP 黑白名单，同样是 OpenResty 的特性               |
| 负载均衡        | Kong Gateway provides two methods for load balancing: straightforward DNS-based or using a ring-balancer. In this guide, you’ll use a ring-balancer, which requires configuring upstream and target entities. With this method, the adding and removing of backend services is handled by Kong Gateway, and no DNS updates are necessary. |

# 为什么用kong?

- 统一入口：服务端微服务框架中，接口权限验证，IP 限制，限流等在各个服务中都单独实现。没有统一入口，不方便统一管理。
- 易用性，扩展性：服务端技术栈主要是LNMP开发，目前在逐步转型到基于golang微服务技术栈上开发。这是一个灰度迁移的过程，我们需要Proxy能操作简单，管理方便。
- 持续集成发布：互联网 2C 产品，用户无时不刻不在使用服务，同时产品还在不断的迭代，服务每时每刻都可以发布，所以必须要热部署能力，并且是自动化的。支持灰度发布，具有故障转移能力

# kong网关提供服务

kong承担的是网关层，可以当作中间件来看待

service: 代表后端api服务

route: 路由到哪个service服务，一个service可以有多个route

![](/images/blog/1/architecture/assert/route-and-service.png)

### 创建service

`rest api`

```shell
$ curl -i -X POST http://localhost:8001/services \
 --data name=douyacun \
 --data url='http://docker.for.mac.host.internal:9003'
```

界面

![](/images/blog/1/architecture/assert/add-service.png)

### 创建route

`rest api`

```shell
$ curl --location --request POST '127.0.0.1:8001/services/douyacun/routes' \
--form 'name=ping' \
--form 'paths[]=/ping'
```

界面

![](/images/blog/1/architecture/assert/add-routes.png)

访问:

```shell
curl --location --request GET '127.0.0.1:8000/ping'
# ok
```

### 限流配置

`rest api` 这样设置，默认是全局配置, 默认是针对consumer,每分钟5次

```shell
$ curl -i -X POST http://localhost:8001/plugins \
--data "name=rate-limiting" \
--data "config.minute=5" \
--data "config.policy=local"
```

界面

![](/images/blog/1/architecture/assert/rate-limit.png)

超过5次以后会返回

```json
{
    "message": "API rate limit exceeded"
}
```

### proxy_cache 缓存请求插件

`rest api`

```shell
$ curl -i -X POST http://127.0.0.1:8001/plugins \
--data name=proxy-cache \
--data config.content_type="application/json" \
--data config.cache_ttl=30 \
--data config.strategy=memory
```

界面

![](/images/blog/1/architecture/assert/proxy-cache.png)

注意： 如果`content-type` 不一致的话，缓存命中状态会是跳过状态`X-Cache-Status: Bypass` ，像我们上面设置的 `config.content_type="application/json"`  但是response content-type是 `application/json; charset=utf-8`

### key-auth 鉴权

添加key-auth插件

```shell
$ curl -X POST http://127.0.0.1:8001/routes/douyacun/plugins \
 --data name=key-auth
```

添加consumer和Credentials

```shell
$ curl -i -X POST -d "username=douyacun&custom_id=douyacun" http://localhost:8001/consumers/
```

为consumer生成apikey

```shell
$ curl -i -X POST http://localhost:8001/consumers/douyacun/key-auth -d 'key=ASF-JIK-0O1'
```

验证

```shell
$ curl -i http://localhost:8000/api/articles -H 'apikey:ASF-JIK-0O1'
```

### 负载均衡

创建Upstream

```shell
curl -X POST http://127.0.0.1:8001/upstreams \
 --data name=upstream
```

修改之前创建的douyacun service

```shell
curl -X PATCH http://127.0.0.1:8001/services/douyacun \
 --data host='upstream'
```

增加两个后端节点

```shell
$ curl -X POST http://127.0.0.1:8001/upstreams/upstream/targets \
 --data target=’docker.for.mac.host.internal:9004’
 
$ curl -X POST http://127.0.0.1:8001/upstreams/upstream/targets \
 --data target=’docker.for.mac.host.internal:9003’
```



kong基础入门


1. `omitempty` 字段为空时( 空指针, 空接口, 空数组, slice, map, or string.)，json encode时不返回该字段

```go
type person struct {
	Name string `json:"name,omitempty"`
	Age  int    `json:"age"`
}

var p = person{
  Name: "",
  Age:  18,
}
if res, err := json.Marshal(&p); err != nil {
  fmt.Println(err)
	return
} else {
  fmt.Println(string(res))
}
// {"age":18}
```

2. `string` 字符串和数字类型转换，对于php和js这类弱类型语言字符串和数字很容易就混

```go
type person struct {
	Name string `json:"name,omitempty"`
	Age  int    `json:"age,string"`
}

var p1 person
str := `{"name":"douyacun", "age": "18"}`
if err := json.Unmarshal([]byte(str), &p1); err != nil {
  fmt.Println(err)
  return
}
fmt.Println(p1)
// {douyacun 18}
```

如果age 没有string tag的话，会报错 `json: cannot unmarshal string into Go struct field person.age of type int`

3. `-` 忽略字段

```go
type person struct {
	Name   string `json:"name,omitempty"`
	Age    int    `json:"age,string"`
	Height int    `json:"-"`
}
var p = person{
  Name: "",
  Age:  18,
  Height: 180,
}
if res, err := json.Marshal(&p); err != nil {
  fmt.Println(err)
  return
} else {
  fmt.Println(string(res))
}
// {"age":"18"}
var p1 person
str := `{"name":"douyacun", "age": "18", "height": 180}`
if err := json.Unmarshal([]byte(str), &p1); err != nil {
  fmt.Println(err)
  return
}
fmt.Println(p1)
// {douyacun 18 0}
```

4. 判断json字符串是否有效

```json
fmt.Println(json.Valid([]byte(`{"name":"douyacun", "age": "18", "height": 180}`)))
// true
```

5. 从数据流读取字符串并解码

```go
var jsonStream = `
	{"Message": "Hello", "Array": [1, 2, 3], "Null": null, "Number": 1.234}
`
des := json.NewDecoder(strings.NewReader(jsonStream))
for{
  t, err := des.Token()
  if err == io.EOF {
    break
  }
  if err != nil {
    fmt.Printf("%v\n", err)
    return
  }
  if _, ok := t.(json.Delim); !ok {
    fmt.Printf("%T: %v\n", t, t)
  }
}
// string: Hello
// string: Array
// float64: 1
// float64: 2
// float64: 3
// string: Null
// <nil>: <nil>
// string: Number
// float64: 1.234
```

6. 对于不确定是int或者float的字段，可以使用json.Number

```go
type person struct {
	Weight json.Number `json:"weight"`
}

var p person
str := `{"weight": 19}`
if err := json.Unmarshal([]byte(str), &p); err != nil {
  fmt.Println(err)
  return
}
fmt.Println(p.Weight.Int64())
// 19 <nil>
```

7. 可以像orm一样写原生sql。像es的查询结果如何定义结构体：

**编码**

```go
type person struct {
	Weight json.Number     `json:"weight"`
	Skill  json.RawMessage `json:"skill"`
}

skill := map[string]interface{}{
  "language": []string{"c", "php", "js", "golang"},
  "js":       []string{"react"},
  "php":      []string{"Laravel", "ThinkPHP"},
  "golang":   []string{"gin"},
}
res, err := json.Marshal(skill)
if err != nil {
  fmt.Println(err)
}
p := person{
  Weight: "89",
  Skill:  json.RawMessage(res),
}
if res, err := json.MarshalIndent(p, "", "\t"); err != nil {
  fmt.Println(err)
  return
} else {
  fmt.Println(string(res))
}
```

输出

```json
{
        "weight": 89,
        "skill": {
                "golang": [
                        "gin"
                ],
                "js": [
                        "react"
                ],
                "language": [
                        "c",
                        "php",
                        "js",
                        "golang"
                ],
                "php": [
                        "Laravel",
                        "ThinkPHP"
                ]
        }
}
```

**解码**

像ES search结果集，外层有公共的数据结构

```json
{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 12,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : []
  }
}
fmt.Println(p1)
// {douyacun 18}
// 如何不加string，会报错: json: cannot unmarshal string into Go struct field person.age of type int
```

结构体

```go
type ESListResponse struct {
	Took    int  `json:"took"`
	Timeout bool `json:"timed_out"`
	Shards  struct {
		Total      int `json:"total"`
		Successful int `json:"successful"`
		Skipped    int `json:"skipped"`
		Failed     int `json:"failed"`
	} `json:"_shards"`
	Hits struct {
		Total struct {
			Value    int    `json:"value"`
			Relation string `json:"relation"`
		} `json:"total"`
		MaxScore float64         `json:"max_score"`
		Hits     []json.RawMessage `json:"hits"`
	} `json:"hits"`
}
type ESItemResponse struct {
	Index  string          `json:"_index"`
	Type   string          `json:"_type"`
	Id     string          `json:"_id"`
	Score  float64         `json:"_score"`
	Source json.RawMessage `json:"_source"`
}
```

这个有点复杂，写个简单的例子：

```go
type person struct {
	Weight json.Number     `json:"weight"`
	Skill  json.RawMessage `json:"skill"`
}


str := `{
	"weight": 180,
	"skill": {
		"language": ["php", "golang", "c", "python"],
		"database": ["elasticsearch", "mysql", "redis"]
	}
}`
var p person
if err := json.Unmarshal([]byte(str), &p); err != nil {
  fmt.Println(err)
  return
}
fmt.Printf("weight: %s\nskill: %s\n", p.Weight, p.Skill)

type _skill struct {
  Language []string `json:"language"`
  Database []string `json:"database"`
}

var skill _skill
if err := json.Unmarshal(p.Skill, &skill); err != nil {
  fmt.Println(err)
  return
}
fmt.Printf("%+v\n", skill)
```

输出：

```
weight: 180
skill: {
                "language": ["php", "golang", "c", "python"],
                "database": ["elasticsearch", "mysql", "redis"]
        }
{Language:[php golang c python] Database:[elasticsearch mysql redis]}
```

其实 p.Skill 还是 []byte,可以再次被 Unmarshal


json包的使用不是像php那样json_encode/json_decode,有更大操作空间