gRPC 的一些想法

开源的 RPC 框架有很多，如果专注于 java，可以尝试 finagle，打造基于 java 的微服务系统可以考虑 dubbo、spring cloud、spring cloud alibaba；如果是 c++ 可以尝试 thrift/pb + brpc；如果服务有跨语言调用的需求，可以考虑 thrift、gRPC。

相信，谷歌的背书 + 多语言 + pb & gRPC，会吸引很多人的注意，但是 gRPC 的一些坑还是要慢慢趟才行。

比如 ManagedChannel 默认的负载均衡是 pick_first。公司用了几年，虽然有了服务发现，但是创建 stub 时还是随机选择一个机器创建连接。如果服务端是 python，还要注意多个服务进程的负载均衡问题（python 服务一般会起多个进程，共用一个端口），因为 gRPC 的负载均衡是连接粒度的，如果客户端复用连接，那么就会出现请求全部集中在一个进程上面，这样至多使用机器的一个核心；这个问题简单一点可以通过创建多个连接，请求时随机选取来解决，比较好的解决方案是自定义 load balance，定义 subchannel 创建规则。

还有就是，gRPC 的文档并没有想象中那么多，就 java 来说，封装了大量的逻辑，有些甚至连代码注释说的都很模糊。

ManagedChannel

ManagedChannel 有很多内置的实现，常用的是 ManagedChannelImpl2，涉及到几个比较重用的概念。

异常报警

• 指标使用 counter，出现异常时 inc 指标值
• 通过 increase 方法，查询某一段时间内指标增加值，如果 > 0 或达到自定义条件，触发报警

运行类

1
2
3
4
5

# 运行不可执行 jar 包内的类
$ java -cp demo.jar com.example.Main

# 运行可执行 jar 包
$ java -jar demo.jar

configuration

1

...

start

1
2

nohup ./prometheus --config.file prometheus.yml &
nohup ./prometheus --config.file prometheus.yml --storage.tsdb.path /path/to/data &  # 指定数据保存路径

LVM

对磁盘创建 lvm。

1
2
3
4
5
6
7
8
9
10
11

# 创建
$ pvcreate /dev/sda
$ vgcreate cinder-volumes /dev/sda

# 删除
## 移除卷
$ lvremove cinder--volumes-cinder--volumes--pool_tmeta
## 删除组
$ vgremove cinder-volumes
## 删除物理卷
$ pvremove /dev/sda

如果出现 pvcreate 时出现 execlude by a filter，检查 /etc/lvm/lvm.conf 下的 filters。

1

filter = [ "a/sda/", "a/nvme/", "r/.*/" ]

如果想要接受一个块设备，使用类似下面的配置。

1

"a|.*|"

如果想要拒绝一个块设备，使用类似下面的配置。

1

"r|/dev/cdrom|"

在添加前，需要对磁盘分区，并创建 lvm。

描述

一台机器，两块存储盘，一个 HDD，一个SSD。HDD 用来做存储，SSD用来做系统盘。

目标

安装系统时可以指定把卷创建在 SSD 盘中，在 HDD 盘上创建存储盘，并挂载到机器。

操作

初始化硬盘

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

# lsblk
...
nvme1n1                                         259:0    0 931.5G  0 disk
└─nvme1n1p1                                     259:1    0 931.5G  0 part /data
...

## 使用 nvme1n1 来创建 lvm 卷，卷组为 cinder-nvme
# umount /dev/nvme1n1p1
# vim /etc/lvm/lvm.conf
## 修改 devices.filter, 包含该设备
filter = ["a|/dev/sda|", "a|/dev/nvme1n1|", "r|.*|"]
## 创建 PV (Physical Volume)
# pvcreate /dev/nvme1n1
## 查看信息
# pvdisplay /dev/nvme1n1
## 创建 volumn group (VG)
# vgcreate cinder-nvme /dev/nvme1n1
## 再次查看信息
# pvdisplay /dev/nvme1n1

配置多存储

openstack cinder 支持一台机器上配置多块存储（multiple backends），编辑 /etc/cinder/cinder.conf。

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

[DEFAULT]
...
enabled_backends = lvm-nvme,lvm-sda

...

[lvm-nvme]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-nvme
target_protocol = iscsi
target_helper = tgtadm
volume_backend_name = LVM_NVME

[lvm-sda]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
target_protocol = iscsi
target_helper = tgtadm
volume_backend_name = LVM_SDA

这里配置了两个 backends，lvm-nvme 和 lvm-sda，前者为固态硬盘，后者为机械硬盘。

创建卷类型

命令行方式

1
2
3
4
5
6
7
8
9
10

# 创建卷类型
$ openstack --os-username admin --os-tenant-name admin volume type create 存储
# 设置扩展参数，将该类型卷绑定到特定的 backends
$ openstack --os-username admin --os-tenant-name admin volume type set 存储 \
  --property volume_backend_name=LVM_SDA
  
# 同样的方式，绑定另一块盘
$ openstack --os-username admin --os-tenant-name admin volume type create 高性能
$ openstack --os-username admin --os-tenant-name admin volume type set 高性能 \
  --property volume_backend_name=LVM_NVME

界面操作

在 管理员 / 卷 / 卷类型 中，创建卷类型 高性能和存储。

点击卷类型的操作菜单，选择「查看扩展规格」。

创建扩展，key 为 volume_backend_name，值为LVM_SDA（存储）和 LVM_NVME（高性能）。

创建卷

在菜单 项目 / 卷 下，创建卷。

指定类型为「高性能」。同理创建其他卷，类型选择「存储」。

效果

最终，在 LVM_SDA 上面创建了 hdd 卷，在 LVM_NVME 上面创建了 ssd 卷。对于卷列表中的 host，其格式为 host@backend-name#pool，比如 srv@lvm-sda#LVM_SDA。

使用 lsblk 查看卷信息。

参考

• https://openstack.by/biblioteka/openstack/admin-guide/docs.openstack.org/admin-guide/blockstorage-multi-backend.html

模块

启停

1
2
3
4
5

# 命令
sudo service <service> restart

# nova-scheduler
sudo service nova-scheduler restart

状态

1

sudo systemctl status <service>

超分

1

sudo vim /etc/nova/nova.conf

openjdk

1

$ sudo yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel

用户管理

1
2
3
4
5
6
7
8
9

# 创建 group
$ groupadd wii
# 添加用户
$ useradd -d /home/wii -m -s /bin/bash -g wii wii
# 添加至 sudoers
$ sudo usermod -aG wheel wii

# sudo 无需密码
$ sudo visudo

metric

Counter

Counter 用于累计指标，表示一个只能递增或置零的单调递增计数器。

Gauge

Gauge 用于数值指标，统计值可以增加也可以减小。

Histogram

Histogram 用于对指标进行采样观察，可以设置需要统计的分位值。在抓取时，Histogram 指标会返回多个时序。

• 观察桶的累计计数，指标名称为 <basename>_bucket{le="<upper inclusive bound>"}
• 所有采样数据值的总和，指标名称为 <basename>_sum
• 所有采样数据的总数，指标名称为 <basename>_count ，和 <basename>_bucket{le="+Inf"} 值一致

Summary

和 Histogram 相似，Summary 对观察指标进行采样，在提供所有采用数据总数和值的总和的同时，在滑动窗口时间内计算可配置的分位数。在抓取时，Summary 指标会返回多个时序。

• 流式传输观察到的事件的 φ-分位数 (0 ≤ φ ≤ 1)，指标名称为 <basename>{quantile="<φ>"}
• 所有采样数据值的总和，指标名称为 <basename>_sum
• 所有采样数据的总数，指标名称为 <basename>_count

对比

Histogram & Summary

Histogram 和 Summary 都是采样观察，常用于请求耗时及响应大小统计。两者会统计样本数量以及样本值的总和，以便计算统计值的平均值。原则上，两者可用于观测有负值的指标，这种情况下观测值的总和可能会上下波动，不再使用 rate() 方法。对于这种场景如果想用 rate() ，可以用两个独立的 Summary 指标，一个统计整数，一个统计负数，然后再使用 PromQL 进行组合。

如果想统计最近五分钟的平均请求耗时，指标是 Summary 或者 Histogram 都可，指标名称为 http_request_duration_seconds，那么表达式如下。

1

rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])

Apdex score

使用 Histogram 而不是用 Summary 的一个直接场景，是计算一个指标落入特定分桶样本数量的值。比如，有一个 SLO 指标，95% 的请求要在 300ms 内返回。配置一个包含 300ms 以上的分桶，可以直接表示 300ms 以内的相对请求数量，并且很容易地在值小于 0.95 时报警。下面的表达式可以计算 5 分钟内请求耗时在 300ms 以内的比例。

1
2
3

  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job)
/
  sum(rate(http_request_duration_seconds_count[5m])) by (job)

可以用同样的方式计算 Apdex score。配置分桶，包含目标耗时（比如，0.3s）和最大容忍耗时（一般 4 倍于目标耗时，比如 1.2s），下面表达式可以计算 Apdex Score。

1
2
3
4
5

(
  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job)
+
  sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m])) by (job)
) / 2 / sum(rate(http_request_duration_seconds_count[5m])) by (job)

分位数（Quantiles）

Histogram 和 Summary 都可以计算 φ 分位数，0 ≤ φ ≤ 1。 φ 分位数是 N 个观察值排序后位于 φ * N 位置的数的值。两者计算分位数最重要的不同是，Summary 在客户端流式计算 φ 分位数并直接上传；Histogram 暴露分桶的观测值数量，在使用 histogram_quantile() 方法获取分位值时计算发生在 server 端。

注意聚合差异的重要性，重新回到 SLO 的问题，这次不再关注 300ms 以内请求的比例是否达到 95%，而是 95 分位本身（95% 的请求可以在多上时间返回）。为了达到这个目的，可以设置一个 Summary 并配置 95 分位，也可以设置一个 Histogram 并在 300ms 附近设置一部分分桶（比如 {le="0.1"}， {le="0.2"}， {le="0.3"}， 和 {le="0.45"}）。如果服务有多个实例，期望将结果聚合并得到一个整体的 95 分位值。那么，如果是 Summary 使用下面表达式计算平均值是没有意义的。

1

avg(http_request_duration_seconds{quantile="0.95"}) // BAD!

如果是 Histogram，可以使用下面的表达式。

1

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) // GOOD.

通过对原始数据进行聚合，再计算分位值，是比较合理的。

文档

• 指标类型
• Histogram 和 Summary