前言

说是最佳实践，其实这只是数据库开发的基础规范，事实上在很多团队的实践上，还是会根据具体的团队开发而有些调整或者优化。

但是因为大部分都是比较基础的数据库开发规范，所以要先知其然，再知其所以然。因此这一份用来打基础还算可以。

因为我们的项目实践大部分都是 Mysql， 因此里面有很多是 Mysql 相关的，不过都是大同小异

1. 命名规范

1.1. 命名总规则

1. 所有名称的字符范围为：A-Z,a-z,0-9和_(下划线)。不允许使用其他字符作为名称。
2. 采用英文单词或英文短语（包括缩写）作为名称，不能使用无意义的字符或汉语拼音。
3. 名称应该清晰明了，能够准确表达事物的含义，最好可读，遵循“见名知义”的原则。
4. 命名不得超过30个字符的系统限制。
5. 所有数据库设计要写成文档

前言

之前讲过的两种方式:

• prometheus + grafana 实战篇(2) - nginx
• prometheus + grafana 实战篇(3) - 使用 mtail 采集程序日志

其实已经可以很好的覆盖了生产环境中产生的临时故障情况，并有助于分析流量和错误情况。 但是仅仅这样子还不够。要做到更全面的预警可观测。除了要第一时间处理生产环境中当前产生的错误信息之外。

还需要对业务数据的表现情况也要造成可观测，比如常见的:

1. 登录情况，10 分钟成功率预警， 一小时成功率预警，每天成功率预警
2. 支付情况，10 分钟支付成功率和数量，每天支付总数
3. 核心功能的使用情况监控，比如用于短信验证码的成功率，Google验证码的成功率，两步验证的成功率，远程连接的成功率，用户核心模块的使用成功率等等

这些业务数据，一般服务端都会将使用记录写入数据库，后面再用相关平台来进行预警，比如 cacti，zabbix 等运维平台就是通过写 python 脚本去定时查下数据库对应的数据然后来建立预警值。比如之前常用的在 zabbix 写的预警脚本就是

前言

上一节我们已经可以通过采集 nginx 的 access log 来得到程序的流量情况，以及针对异常状态码来设置预警

• prometheus + grafana 实战篇(2) - nginx

已经可以解决突发性的故障问题了，但是要达到更好的日志可观测性，还是不够，至少有以下两种场景没办法满足:

1. 程序框架的异常状态码和 nginx 的状态码解耦。 有些程序框架为了保证返回值的友好和错误码的统一，是会在框架底层将抛出来的错误 catch 掉的，而不是直接扔到 nginx 上层返回。 举个例子，比如我们的 golang 框架就是这样子的，我们有自己定制了一整套的错误码标准，包含 数组越界，空指针异常 等异常都会在程序底层 catch，并在返回的 json 串填充错误码 code，并返回 200 状态码。 因此在 nginx 层，基本上只能看到 200 的正常码， 是看不到异常的 500 错误码的(nginx 本身的 499, 502, 504 还是有的)。要看程序错误，只能去查程序的输出 log。

   大部分的对外提供的 API 接口，也是会将程序的错误码和 http 的异常码解耦掉

2. 针对某些外接第三方的 webhook 的错误处理也没办法返回异常状态码。 比如以支付项目为例，我们会接 Google 和 Apple 的 webhook 通知来处理订单状态，这时候有些处理逻辑是本身程序有 bug，你是不能直接针对 webhook 的返回响应返回异常状态码的，比如 500 错误码，不然这些第三方的 webhook 可能就会再重发。因此哪怕是程序异常，也最好是返回 200 正常码。那么对于这种情况，如果要检测的话，也是只能通过采集程序日志来进行发现和预警。

综上所述，我们还是需要一种可以采集程序日志来生成 Prometheus 指标的服务。

前言

随着内部应用的微服务的增多，一定会涉及到频繁的微服务之间的互相调用，这时候要有一种验证方式来保证两个微服务的调用是合法的(这边只是网关级别的请求校验，该有的业务校验一样要有), 如果你的微服务相互调用是通过 http(s) 的方式，那么采用签名算法来做请求的安全性校验是业务比较常用的方式。

当然还有其他的方式，比如 ip 白名单，但是对于有负载均衡，横向扩展的服务来说，就没那么灵活

签名算法大家其实不陌生，很多第三方的 sdk，权限校验走的就是签名算法的校验方式，原理都大同小异，其中我接触最多的就是 aws 的签名算法: AWS Signature Version 4

最基础的原理

最核心的原理就这几步，对于客户端来说:

1. 生成一对安全凭证，包括一个 AccessKey 和 SecretKey, 前者可以参与加密也可以不参与，主要是用来匹配对应的 SecretKey， 后者就是用来进行加密生成签名的
2. 将整个 http 请求对象进行聚合操作，生成一个待签名串 StringToSign
3. 用 SecretKey 加密待签名串 StringToSign，生成最后的签名 Signature
4. 将签名 Signature 和 AccessKey 放在 header 标头，连同整个 http 请求对象发送过去

前言

之前通过 记一次 php-fpm 的配置调优 有针对 php-fpm 的配置进行了调优，有起了一些效果，比如随着处理的进程加大，响应时间会快一点。 但是对于一些并发比较高的场景，还是会有 499 的情况，尤其是负载比较高的情况下，CPU 很容易跑满，php 子进程的响应速度也会越来越慢

当然最粗暴的就是加大服务器硬件配置，然后增大 pm.max_children 的值，硬抗，不过还有一种更合适的方式，就是开启 opcache 来降低服务器负载并提高抗并发能力。

OpCode

opcache 其实就是 OpCode + cache，因此要先了解一下什么是 OpCode。

php 是一种解释型语言，它的执行可分为以下几个流程:

1. Scanning(Lexing) ,将PHP代码转换为语言片段(Tokens)
2. Parsing, 将Tokens转换成简单而有意义的表达式
3. Compilation, 将表达式编译成字节码 (OpCode)
4. Execution, 顺次执行 OpCode，每次一条，从而实现PHP脚本的功能。

前言

前段时间有一个很老的 php 服务发生了一个并发情况，产生大量的 499 状态码，刚开始以为是高并发导致的服务器负载不行。结果去 grafana 后台一看，服务器负载是正常的，然后查了一下同台的 golang 服务，他的返回状态码是非常正常的。

所以怀疑应该是 php 服务有问题，因为我们用的是 nginx + php-fpm 的部署方式， 所以应该是 php-fpm 的配置有问题。

然后抓了一下这一台的 php-fpm 的配置，果然有问题:

前言

前前后后使用了 aws 的 ses 服务也用了好几年了，在很多使用上也踩了很多坑，打算从最佳实践角度去聊聊，怎么更好的使用邮件服务。

主要分为几大块

1. 邮件质量相关
2. 邮件安全相关
3. 邮件统计相关
4. 减少退信和投诉

以下很多内容虽然是从 aws 的 ses 服务来说明的，但是本质上邮件服务都是大同小异的，完全可以应用到其他的邮件服务上

邮件质量相关

1. 关注邮件质量

电子邮件接收方使用内容筛选器来检测邮件中的特定属性，以识别当前收到的邮件是否合法。这些内容筛选器会自动审核邮件的内容，以识别常见的不受欢迎的邮件特征乃至恶意邮件。

同时很多邮件服务厂商，比如 Amazon SES 也会使用内容筛选技术，协助在邮件发送之前检测和拦截包含恶意软件的邮件。

如果电子邮件接收方的内容筛选器认定我们的邮件包含垃圾邮件或恶意电子邮件的特性，邮件很可能被标记出来，并从收件人的收件箱中移出。

前言

通过 使用 verdaccio 搭建前端内部私有 npm 仓库 已经建立了团队内部的私有 npm，并且也知道怎么去进行私有包的发布。

那这一节讲一下怎么规范的进行包的开发，以及要发布的一些规范，当然不同的团队有自己的规范，仅供参考。

开发规范

主要包含以下几个环节:

1. 编写 README.md 文件，描述包的使用方法和注意事项
2. 提供类型声明文件 (.d.ts)
3. 提供 demo，方便使用者快速上手
4. 提供单元测试，确保包的正确性
5. 在导出的模块的函数中添加JSDoc注释

1. 编写 README.md 文件

README.md 文件无疑是安装者了解这个包的第一途径，因此是非常重要的。 通常README文件应该至少包含以下内容：

1. 项目名称和描述：在文件的开头，应该清楚地标明项目的名称和描述，让读者了解这个项目是做什么的；注意: 描述会显示在npm包页面的概览中，所以请确保它是有意义的。
2. 安装指南：提供详细的步骤，说明如何安装和设置这个包。这可能包括需要的依赖、环境变量等。
3. 使用示例：提供一些基本的代码示例，让用户知道如何在他们的项目中使用你的包。
4. API 文档：如果你的包提供了API，你应该在readme中详细说明每个公开的函数或方法，包括它们的参数、返回值和可能抛出的错误。
5. Changelog: 应该提供版本 change log 记录或者跳转到 CHANGE_LOG.md 文件的外链

前言

随着前端项目越来越多，尤其是内部的 js lib 库越来越多，怎么有效的管理 lib 库的发布，就变成一个很重要的问题了。

以之前做的 air-ui 来说，其实在进行版本发布的时候，为了保证不污染 gitlab 上的 master 分支，所以就专门写了脚本在版本发布的时候，进行分支切换来处理，具体步骤多又繁琐:

1
2
3
4
5
6
7
8

1. 检查当前分支是否是远程的 master 分支，如果不是，返回错误
2. 执行 yarn dist， 生成 lib 目录
3. 将 lib 目录保存到一个 gitignore 的一个目录 lib_tmp
4. commit and push master 分支 （如果 status 有改变的话）
5. 切换到 master-release 分支，将 lib_tmp 的文件覆盖 lib 目录
6. commit and push master-release 分支
7. master-release 打 tag
8. 把临时文件 lib_tmp 删掉

具体细节查看 自建vue组件 air-ui (16) -- 打包构建 pub 任务

这种流程是有一些缺点和问题的:

1. 发布流程复杂化： 需要编写专门的脚本来确定哪些构建产物的代码需要发布，同时还需手动删除不必要的代码。
2. 容易产生混淆： 使用 git tag 来发布代码可能会引起混淆，因为它通常用于标记版本，而不是发布代码。
3. 无法利用语义化版本控制的范围（例如：^1.0.0 或 ~1.0.0）来精确指定依赖的版本

但是如果我们有自己的 npm 库的话，其实对于库的发布就变得非常简单，只需要简单的 3 步:

1. 更新package.json中的版本号
2. 代码构建
3. 最后执行npm publish命令，即发布成功

原因

前段时间有发生过一个事情，就是 测试人员在他的 windows 或者 mac 中有出现连接 mqtt VerneMQ 失败的情况, 而且比较神奇的地方在于:

1. 如果搭梯子的话，是可以连接成功的
2. 不搭梯子，将 chrome 浏览器换成 Firefox， 也是可以连接的
3. 在一些机器上，通过修改 DNS 解析，比如改成 8.8.8.8, 也可以正常

经过排查之后，发现确实在连接失败的时候，VerneMQ 服务器会出现部分证书相关的错误提示:

1

[info] <0.20467.939> TLS server: In state certify received CLIENT ALERT: Fatal - Certificat Unknown

排查

首先排查证书问题，确定我们的证书是对的，nginx 都可以正常使用。而且我们的 crt 证书文件是有包含整个验证环节的 fullchain 的聚合证书(包含多个证书链内容的合成证书)。

然后对比一下 chrome 和 Firefox 的证书校验机制，Firefox 带了自己的 CA 证书链， chrome 的 CA 走的是系统的， 因此怀疑是 VerneMQ 证书链对合成证书的验证环节有问题??

分析浏览器该站点的证书链路发现，我们用的证书有属于二级证书签发，中间有一个 Go Daddy Secure CA 校验节点

前言

随着 AI 浪潮的兴起，人工智能将席卷一切，基本上所有的行业都要发生变革。 而在使用 AI 提高工作效率的过程中，prompt 变得越来越重要。

毫不夸张的说，一个好的 prompt 和一个普通的 prompt 对 chatgpt 的内容的准确性，可用性的输出将会产生巨大的差别。如果把 AI 比作 拉力赛的赛车手， 那么 prompt 就相当于坐在副驾驶坐的引导员。 没有 prompt 去指导方向，再牛逼的车，再牛逼的驾驶员都有可能迷失方向。

所以我针对我日常在 chatgpt 的使用中，一些常用的 prompt 有记录下来，以作备忘

这边的 prompt 并不是指 role 中的 system 的那个 prompt，而是指 role 为 user 提的问题的一部分内容

1. 角色扮演

这个是 prompt 最常用的方式，就是让 chatgpt 来扮演一个角色，然后来问答

比如可以这样子写:

1
2

你是一个呼吸内科的医生，你需要通过向我提出一些问题，并获得我的回答来判断我大概得的是什么类型的感冒，
如果我回答的信息不够，请继续向我询问，直到你得到充分的信息。你在最好还需要对我的病情给出专业的建议

前言

前段时间有个 researcher 回报说，他可以通过使用 X-Frame-Bypass 来绕过我们站点的 X-Frame-Options 机制，从而将我们的站点内嵌在他的网页上，从而造成 Clickjacking

对于 Clickjacking 来说，我们一般是使用设置 X-Frame-Options header 来防止站点被第三方内嵌，具体可以看我之前的文章:

• web 页面防iframe嵌入（防止点击劫持Clickjacking）

通过 X-Frame-Options 我们可以很好的防止我们的站点被第三方内嵌。

那么 X-Frame-Bypass 是怎么绕过 X-Frame-Options 这个限制的呢?

分析

我后面看了一下他的代码，他的方式其实很简单，既然 X-Frame-Options 是在 response 的 header 返回的，那么我只要在请求的时候，先去通过第三方服务将我想要的站点的内容取出来，然后只转发这个 body 体，不转发 header，就可以绕过了。

举个例子，比如我内嵌别人站点的代码是这样子的:

1

<iframe src="https://api.codetabs.com/v1/proxy/?quest=https://test-example.com/my_test.html"></iframe>

这个逻辑很简单，就是这个 第三方 api.codetabs.com, 会去请求 https://test-example.com/my_test.html，并且将源代码返回，其实就是转发

前言

前段时间在项目的安全审计中，有发现了一个关于后端开发中，使用 aws sdk 的一个安全隐患，就是后端的一些项目中，有用到了 aws 的一些功能，包含 s3，ses，dynamodb 等，而这些功能用的 key 都是同一个 key， 都是属于在 aws 后台创建的 develop 用户。

这个 develop 用户在 aws 后台具有以下的策略权限(policy):

• dynamodb 功能的所有权限 –> AmazonDynamoDBFullAccess
• s3 功能的所有权限 –> AmazonS3FullAccess
• ses 功能的所有权限 – AmazonSESFullAccess

因为这个 develop 用户拥有的权限太大了， 一旦 key+secret 泄露了， 黑客就可以通过类似于 aws-cli 的命令行工具来做一些不好的事情，比如:

• 往 s3 上的 bucket 随意上传某些木马文件
• 修改 s3 bucket 的 acl 权限，将所有的 bucket 都改成公开桶，直接暴露在外网，或者给自己插入一个另一个账号的登录后门
• 直接使用 ses 发送垃圾邮件，然后受到投诉过多之后，就会可能导致这个 aws 账号被封禁
• 删除 dynamodb 的记录或者表

因此我们必须在后端开发中，根据具体项目所使用到的 aws 的功能，尽可能做最小化的权限分配，并且要设置请求的 ip 白名单，这样子一来，哪怕不小心这个用户的 key+secret 泄露了，我们也不用担心会造成太大的影响。

前言

经过上一节我们初步定义了一些标签的规范: prometheus + grafana 实战篇(1) - 定义标签组和规范, 本节我们来讲一下怎么监控 nginx

nginx

nginx 作为最受欢迎的 web server 之一，我的不少文章都有涉及到 nginx， 这边不再赘述。

我们假设在使用 prometheus 采集 nginx 之前，我们线上环境已经有 nginx 服务来跑了。

关于 nginx 的安装，可以看我的这一篇文章: CentOS 7 安装 Nginx

1
2
3
4

[root@VM-16-223-centos sbin]# netstat -anlp | grep 80
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      29841/nginx: master
tcp        0      0 172.26.16.223:37134     169.254.0.4:80          TIME_WAIT   -                   
udp6       0      0 fe80::5054:ff:fe23::123 :::*                                656/ntpd

nginx-vts-export

prometheus 常用的 nginx 的导出器，目前比较常用的是 nginx-vts-exporter

nginx_vts_exporter 依赖 nginx 的这个 nginx-module-vts 模块, 因此我们要先在 nginx 上重新编译安装 nginx-module-vts 模块

前言

经过前面的学习，我们已经能够很好的掌握 prometheus 并建立监控后台了，但是那个毕竟是学习篇，用于循循渐进的学习和掌握。

• 基于 prometheus 打造监控报警后台

但是真正涉及到线上的实战，其实复杂度还是跟学习的情况差很多的， 因此我这边结合在实际项目上的一些实战，也捋了个实战篇。

prometheus 推荐的最佳实践

在仪表板(dashboard)上显示尽可能多的数据虽然很爽，尤其是当像 Prometheus 这样的系统提供了对应用程序进行如此丰富的检测的能力时。这可能会导致控制台由于包含太多信息而变得难以理解，即使是系统专家也难以从中获得意义。

所以千万不要将所有的数据都往 dashboard 上面搬，请考虑你建这个 dashboard 的初衷是什么，想要解决什么问题，如果你想要解决的问题是一个很复杂的问题的话，请把他进行拆解，并且分成多个 dashboard 来分批解决。

prometheus 官方推荐的 dashboard 指南:

1. dashboard 上面的图表最好不要超过 5 个
2. 每张图的图(线) 也不超过 5
3. 如果使用的是 dashboard 的第三方模板，请避免右侧表格中的条目超过 20-30 个

前言

经过前面的 prometheus 系列的学习，我们知道 prometheus 要监控和抓取的端点都要写在 prometheus.yml 这个配置文件，这种方式对于要监控实例较少的情况还行，但是不适合大规模的的集群。

尤其不适合用于使用容器和基于云的实例的动态集群，这些实例经常会出现变化，有可能新创建，有可能是下架。

而 prometheus 通过使用 服务发现 来通过自动化的机制来检测，分类新的变更实例情况。

服务发现的几种类别

prometheus 提供的服务发现其实种类很多，有很多是跟第三方集成，从配置文件所支持的 参数 来看，分别有:

具体集成的服务列表，官方文档也有: Service Discovery

前言

之前我们的所有的场景，都是通过 prometheus server 定期去实例(instance)拉取(pull)数据, 但是有以下两种情况会有问题:

1. 由于子网络或者防火墙的关系， prometheus server 不能直接拉取各个 instance 的指标数据
2. 监控程序不是在线服务系统，而是批处理作业，批处理作业的特点是它们不会连续运行，这使得抓取它们变得困难。所以 prometheus 如果是定期拉取的话，就会出现 instance 没有运行的情况

基于以上的情况，所以 prometheus server 提供了另一种让实例(instance) 主动 push 指标数据的能力， 那就是借助另一个程序: Pushgateway 来进行代理， 让其他的程序先把数据抛送到 Pushgateway， 然后再让 prometheus server 定期去 Pushgateway 拉取数据

Pushgateway 使用场景

使用 Pushgateway 会有几个问题:

1. 当通过单个 Pushgateway 监控多个实例时，Pushgateway 会有单点故障的潜在问题
2. 没有实例的自动健康监控指标 up
3. 只要是通过 Pushgateway 代理推送给 prometheus server 的实例的指标，会一直存在，哪怕这个实例后面不再抛送指标给 Pushgateway，但是 prometheus 依然会保留这个实例的指标

前言

我们都知道 prometheus 是一个监控程序， 并且可以采集指标，但是之前我们的测试都是用的官方的 exporter ，比如 node_exporter 这种监控主机的。

其实 prometheus 采集的指标一样可以用于我们的自己写的程序, 关于 prometheus 的 客户端的 sdk lib 可以看: prometheus client libraries

里面很多主流语言都有包含，比如 Golang, Python, Java, Node.js, PHP 等，有一些是 prometheus 官方自己维护的，有一些是第三方贡献者写的。

当然如果你自己使用的语言不在上面，也可以按照 prometheus 标准实现一个该语言的 客户端 sdk 库: 编写客户端库的指南

所以本节我们就自己用一个程序来实现 prometheus 的 客户端功能，然后自定义一些抛送的指标。

指标和数据模型

在实现 prometheus 的 客户端功能，那么就要了解 prometheus 的指标和数据模型，这一块直接看 基于 prometheus 打造监控报警后台 (2) - 指标类型和数据模型, 文章已经讲的很详细了。

我们只需要在我们程序中通过实现这四种类型(Counter, Gauge, Histogram, Summary)之一的指标，那么就是符合 prometheus 客户端的抛送指标了。

前言

之前我们已经尝试了在 prometheus 上创建警报，并且使用 alertmanager 来发送通知了: 基于 prometheus 打造监控报警后台 (4) - 使用 alertmanager 发送警报

但是正常情况下，我们都是在 grafana 后台查看我们所创建的 dashboard 仪表盘。 同时 grafana 后台也可以显示我们在 prometheus 上创建的规则 (包含警报规则和记录规则)

不同版本的 grafana 可能界面会有差，甚至操作也会有区别，本节演示的 grafana 的版本是 v9.2.5 (042e4d216b)

grafana 显示 prometheus 创建的规则

继续延伸上一节的规则配置 (配置了两个 rule 文件，一个是警报规则，一个是记录规则)，当我们查看 grafana 后台的 alerting 的时候，可以看到他也有把我们创建的规则一起显示出来

前言

通过 基于 prometheus 打造监控报警后台 (4) - 使用 alertmanager 发送警报 我们知道 prometheus 可以创建 警报规则 来触发警报，然后再把报警信息发送给 alertmanager ，然后 alertmanager 来发送报警通知。

但是其实 prometheus 还有一种规则，就是 记录规则

记录规则(recording rule)

记录规则允许您预先计算经常需要或计算量大的表达式，并将其结果保存为一组新的时间序列。查询预先计算的结果通常比每次需要时都执行原始表达式要快得多。这对于每次刷新时都需要重复查询相同表达式的仪表板特别有用。

也就是每一条记录规则，其实都会作为时间序列存入时序数据库，有点类似于 mysql 的 索引，这些都是有开销，所以也不能无止境的建记录规则，因为会有额外的开销。

关于记录规则的语法，其实跟警报规则一样，他们的配置差别仅仅在于 rules 小节下的第一个配置的 key 是 record 还是 alert。 其他都一样

所以语法这一块，之前在讲警报规则的时候，就讲解过了， 可以看之前讲警报规则的文章: 基于 prometheus 打造监控报警后台 (4) - 使用 alertmanager 发送警报