前言

之前在 windows 环境下使用 SonarQube 来检测工程代码质量 我们已经实现在 windows 7 在使用 SonarQube 针对项目进行代码质量检测了。 接下来我们将结合到项目中原有的构建流程中，在 Jenkins 进行构建的时候，执行构建脚本之前，先通过 SonarQube 进行代码质量检测。 所以之前的流程是这样子的:

1. 用户提交分支或者打tag，触发 Jenkins 设置的 hook 机制
2. Jenkins 收到 hook， 拉取对应分支下来
3. 最后执行构建脚本 (比如如果是go项目就进行打包，然后将二进制分发到对应的服务器， 最后重启服务，如果是php项目就将修改后的代码文件，同步到线上的服务)
4. 如果有其他 hook，比如钉钉通知， 会在开始打包的时候，和打包结束的时候，分别推送一条到对应的群组中

前言

之前做的一个项目，有一个需求是这样子：

站点有一个 websocket 的消息推送机制，并且允许多开页面，但是因为 websocket 当初设计机制的关系，导致就算同一个账号信息开了多个浏览器 tab 页面，也只有最后一个开的 tab 页面的 websocket 通道是 alive 的，其他页面的 websocket 都会被关闭， 这个就导致只有最后一个页面的消息是实时同步的， 其他页面的消息都没有办法更新。 但是产品又要求， 既然允许多开好几个 tab 页面，那么这几个页面的消息同步都应该要一样。

最直接的方式就是改 websocket 通道的机制，允许同一个账号的多个通道存在，但是因为历史包袱以及一些其他原因，一旦改了这个机制，可能会伤筋动骨（好几个项目都是基于这个设计）。 所以退而求其次， 当有一个页面的 websocket 通道收到消息的，要广播到其他的页面， 让其他的页面也知道，并且要把数据传过去。

实操

这个就涉及到多个 tab 页面的信息传递， 之前我在做 chrome extension 扩展的时候， 到是可以做到。 但是这个又不是扩展应用。 另外还有一个 api 是 postMessage 也用于不同页面的消息传递， 不过 postMessage 只能用于内嵌页面，也不适合这种场景。

不过后面还是找到了方法，那就是用 localstorage 的方式来处理。

前言

做过开发的都知道，虽然都是可以 work，但是代码质量的好坏， 直接会导致这个项目的可维护性和可扩展性。 虽然我们的项目的代码在上线之前都会经过测试和 code review。但是随着项目数量越来越多，team leader 在进行 code review 的时候，往往只能注重代码的可用性，很多代码质量上的问题都被忽略了。 所以项目组决定在进行代码 patch 提交之前，在 Jenkins 构建之前，先通过代码质量检测工具 SonarQube 来检查一下代码质量。 这样子可以保证在最后入 master 分支的时候， code review 阶段可以尽可能去看这些格式优雅的代码。

SonarQube 简介

SonarQube 是一款用于代码质量管理的开源工具，它主要用于管理源代码的质量。 通过插件形式，可以支持众多计算机语言，比如 java, C#, go，C/C++, PL/SQL, Cobol, JavaScrip, Groovy 等。sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具来检测你的代码，帮助你发现代码的漏洞，Bug，单元测试覆盖率等信息。

Sonar 不仅提供了对 IDE 的支持，可以在 Eclipse和 IntelliJ IDEA 这些工具里联机查看结果；同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar。

前言

相信做过开发的，都或多或少地被接口文档折磨过。前端经常抱怨后端给的接口文档与实际情况不一致。后端又觉得编写及维护接口文档会耗费不少精力，经常来不及更新。其实无论是前端调用后端，还是后端调用后端，都期望有一个好的接口文档。但是这个接口文档对于程序员来说，就跟注释一样，经常会抱怨别人写的代码没有写注释，然而自己写起代码起来，最讨厌的，也是写注释。所以仅仅只通过强制来规范大家是不够的，随着时间推移，版本迭代，接口文档往往很容易就跟不上代码了。

在 gitlab 私有库上写 wiki 文档

早期我们团队的后端接口文档都是写在我们内部的 gitlab 私有库项目中的 wiki 上， 类似于:

前言

不要问为啥要添加广告，在写博客的同时还有可能有钱赚，何乐为不为？

至于为啥是 google adsence，而不是百度广告联盟之类的，是因为我这个域名并没有在国内备案， 国内广告联盟接不了。

操作

1. 首先要先申请一个 google adsense 账号

2. 粘贴广告代码

注册账号成功之后，进入页面可以看到有广告代码

前言

前面经过 CentOS7 Minikube - Kubernetes 单机安装 和 CentOS7 手动安装 Kubeadm 集群环境 的实操，接下来为了更深刻的理解 kubernetes， 本节我们来用二进制包的方式来安装 kubernetes 集群环境。

事实上，现在 2020 年了， kubeadm 已经可以用于 生产环境部署了。 但是毕竟是集成安装的， 很多细节我都不了解。 为了更好的学习 kubernetes，理解里面错综复杂的关系链， 用二进制包的方式来安装 kubernetes 肯定是要的， 本文主要是根据 Kubernetes The Hard Way 这一篇文章的基础上，一步一步去实践安装的， 本身那一篇的篇幅就很长， 本文再扩展一下，再实践一下，那就更长了。 可以理解为实践篇。

前言

之前有通过 CentOS7 Minikube - Kubernetes 单机安装 我们已经可以在 minikube 学习 kubernetes 了， 但是这个毕竟是单机的，后面又通过 使用 play with kubernetes 搭建 5 个节点的集群 线上练习了一下 kubeadm 的集群操作。 本次就用 CentOS7 手动安装 Kubeadm 集群环境。

本文主要是参照官方文档: 使用 kubeadm 创建集群 进行安装，中间遇到问题的时候，有参考了网上的一些文章来解决。

机器准备

准备两台能够科学上网的机器(选用的是 腾讯云 美西的机器)，一台用作 master 节点， 一台用于集群的 worker 节点。 (集群最低要求就是两台，一台 master，一台 工作节点，如果两台都可以了，那么扩展成 3台， 4台 都是没有问题的)

前言

之前有通过 CentOS7 Minikube - Kubernetes 单机安装 我们已经可以在 minikube 学习 kubernetes 了， 但是这个毕竟是单机的， 最多熟悉一下指令， 没办法搞集群， 所以还得搞个可以玩集群的环境， 刚好线上有一个 Play with Kubernetes 可以允许练习 k8s， 只能说， 好人啊。

而且只需要 github 或者 docker 账号就可以登入使用， session 有 4 个小时，并且最大允许 5 个 node 做集群。 接下来我们就来用这个来搭建 5 个节点的集群， 包括一个 master 和 4 个工作节点。

实操

首先登入进入，点击 ADD NEW INSTANCE, 创建一个 master 实例，这时候就会初始化一个 terminal 控制台

前言

前段时间正在学习 kubernetes， 一般在刚开始学习的时候，都会先本地安装一下，然后逐渐学习。 而安装的话，也分三个过程，由简到难:

1. 本地单机安装 – Minikube
2. 集群安装 – Kubeadm – 请看 CentOS7 手动安装 Kubeadm 集群环境
3. 二进制包安装 – 请看 CentOS7 使用二进制包安装 kubernetes 集群环境

本文主要讲本地单机安装 Minikube 的安装过程和简单的使用过程。

本机环境

线上关于这种的安装教程其实很多，但是因为 kubernetes 的快速迭代，很多早期的安装教程，现在再照着方式再安装，其实很多时候就安装不了，所以在安装之前要先把一些环境先说明一下。

本机环境:

几个细节:

1. 因为我的环境可以科学上网，所以 kubectl 可以直接下载， 如果不能的话，那么就要换成 阿里云的 国内镜像也行的。
2. minikube 只能用于学习 kubernetes 用， 只能单机， 不能用于生产环境。

前言

之前在做组内的知识库的时候，考虑到其轻量化和易编写性(只需要写 markdown 文件), 选用了 docsify 这个基于 vue 的文档生成器。 套用他的概述就是

docsify 可以快速帮你生成文档网站。不同于 GitBook、Hexo 的地方是它不会生成静态的 .html 文件，所有转换工作都是在运行时。
如果你想要开始使用它，只需要创建一个 index.html 就可以开始编写文档并直接部署在 GitHub Pages。

事实上确实非常的轻量和好用，但是有个问题，一直体验没有那么好，就是搜索， 因为随着文档越来越多， 有时候想要根据一个关键字搜索一个文档， 却发现搜索不到。

search 插件的用法

其实 docsify 是有 全文 search 的插件的，具体看: 全文搜索 - Search, 写法也没毛病， 配置也很简单， 甚至源代码都很好理解，也不复杂。

前言

之前在看 Nginx 的 location 匹配规则的时候，参考了一些网上的文章，但是这些文章，要么不全，要么就是有问题的，后面打算结合我自己的实践，自己写一篇算了。

本次实践的环境:

• 系统: CentOS 7
• Nginx 版本: 1.18.0

location 匹配的变量

Nginx 的 location 规则匹配的变量是 $uri, 所以不用管后面的参数 $query_string (或者 $args)

location 匹配的种类

格式主要是这个:

1
2
3

location [空格 | = | ~ | ~* | ^~ | @ ] /uri/ {
  ...
}

其实上面分为三部分:

1. 最前面的字符 (location modifier) 匹配规则
2. 后面 uri 的匹配规则 (location match)
3. 大括号内的路由转发

前言

首先安装 nginx 的教程，网上到处都是，其实真没有为这个写 blog 的必要，当然之所以还是要写的原因无非是当初自己在安装的时候，虽然照着教程安装，但是还是有遇到了一些神奇的情况，当然后面都解决了，不过还是记一下比较好，后面自己要安装的时候，省的再去找网上的文章，自己看自己的 blog 它不香吗 ↖(^ω^)↗

安装 nginx 有两种:

1. 直接系统安装，本文主要讲这种
2. 使用容器安装，比如 docker

使用 docker 安装

这种方式很简单，直接执行一条指令就可以了:

1

docker run -d -p 80:80 --name webserver nginx

这样子就可以了，其中 -p 是端口映射， -d 就是以守护态运行

前言

之前在测试 nginx 的 location 的匹配规则和优先级的时候，有测试了这么一种情况:

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

location /images/test.png {
    return 200  'config1';
}

location ^~ /images/test.png {
    return 200  'config2';
}

location ~ \/images\/test\.png$ {
    return 200  'config3';
}

location ~ /images/ {
    return 200  'config4';
}

然后我每次执行的时候:

1
2
3

[root@VM_156_200_centos conf]# sudo systemctl reload nginx.service
[root@VM_156_200_centos conf]# curl http://127.0.0.1/images/test.png
config4

神奇的情况发生了， 执行结果竟然是 config4, 怎么看都觉得是 config2 才是对的。 因为如果普通匹配和正则匹配都存在的话， ^~ 的匹配如果是最长的话，那么肯定是以 ^~ 为准的。 那么为啥是 config4 ????

前言

前段时间又看到别人家的 blog 有看板娘了， 觉得挺好看的。 所以也打算搞起来。

参照这个第三方库来操作也很简单。 Live2D Widget

操作

1. 下载这个库到对应的目录

1
2
3
4
5
6

$   git clone "https://github.com/stevenjoezhang/live2d-widget" themes/next/source/live2d-widget
Cloning into 'themes/next/source/live2d-widget'...
remote: Enumerating objects: 423, done.
remote: Total 423 (delta 0), reused 0 (delta 0), pack-reused 423
Receiving objects: 100% (423/423), 960.57 KiB | 30.00 KiB/s, done.
Resolving deltas: 100% (263/263), done.

前言

meta 标签是 html 标记 head 区的一个关键标签，它位于HTML文档的 <head> 和 <title> 之间（有些也不是在<head>和<title>之间）。它提供的信息虽然用户不可见，但却是文档的最基本的元信息。meta 标签用来描述一个 HTML 网页文档的属性，例如作者、日期和时间、网页描述、关键词、页面刷新等。

meta 标签结构

从官方文档来看 : The Document-level Metadata element, 这个标签有四个属性:

• charset
• content
• http-equiv
• name

charset

charset 属性规定 HTML 文档的字符编码。 它是 HTML5 中的新属性，且替换了

1

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

虽然仍然允许使用 http-equiv 属性来规定字符集，但是使用新方法可以减少代码量。

常用的值有:

• UTF-8 - Unicode 字符编码
• ISO-8859-1 - 拉丁字母表的字符编码

在理论上，可以使用任何字符编码，但并不是所有浏览器都能够理解它们。某种字符编码使用的范围越广，浏览器就越有可能理解它。 如需查看所有可用的字符编码，请访问 IANA 字符集。

问题

最近在做业务的时候，有遇到了一个问题，就是用户的连接记录在库里面存放的是 UTC 时间，但是在前端显示的时候，却要根据用户的本地时间来显示对应的数据。

举个例子，比如用户在前端选择查询 2020-08-20 和 2020-08-25 这段时间的连接记录。 假设这个用户当前用的是 北京时间， 也就是东八区，那么这时候， 在 mysql 进行查询的，应该就是查询 2020-08-19 16:00:00 和 2020-08-24 16:00:00 这段时间的连接记录, 因为减掉 8 小时，才是库里面真正存的 UTC 时间。

所以具体的连接记录展示是没问题的。 但是还有另一个需求， 就是用户想知道 2020-08-20 和 2020-08-25 这段时间每天连接了多长时间， 这个就不太好处理了，因为涉及到 group by date, 而这个 date 字段在库里面存放其实是 UTC 时间，那么 group by 其实只是按照 UTC 时区来的，而不是按照本地时区的 GMT 时间。 所以我们要先把它转换为 GMT 时区，然后再 group by。

前言

之前有用户反馈我们的服务接口请求速度慢，比如一个请求从请求到响应用了 1.5s， 但是我通过 nginx 日志来看的话，这一条请求处理的时间只有 0.2s， 也就是 http 请求在往返途中其实消耗了 1.3s。 所以如果要优化接口速度的话， 其实就是优化请求线路。

加速线路的几种方式

通常我们经常用的有以下三种:

1. 静态资源的 CDN 加速

这个也是绝大部分网站经常用的，就是通过 CDN 的边缘节点，进行静态资源的缓存，然后优先走最近的节点，从而节省请求时间。 各大云厂商都有提供这种服务，比如 aws 的 cloudfront。

2. 动态 CDN 加速

所谓的动态内容加速，是指用户在请求一些动态内容时，如网站中的 .asp、.jsp、.php和.cgi接口、API接口等，不直接请求源站，而是由基于地理位置的DNS调度，请求最靠近用户的云服务节点，再由云服务节点通过优化过的传输网络（公网，但比普通BGP更优化的链路），转发请求到源站，达到优化和加速的目的。当然这其中有很多其他的传输层面的优化，比如访问链路优化、传输内容压缩合并、智能选路、链路复用等技术。

前言

感觉自己年纪越来越大，记性越来越不好使了， 所以想做个备忘。将自己常用的一些 shell 指令记一下。 一方面是有时候想用的时候，忘记了。 一方面是有些指令略长， 有时候也会忘记了一部分细节。 所谓好记性不如烂笔头。 还是做下备忘比较靠谱。 (天天用就还好，没那么容易忘，问题是有些指令半个月一个月才用一次，每次都会忘记一部分细节，也是蛋疼)

常用指令

1.查看程序重启是不是 oom 导致的

有时候程序会无缘无故重启，这时候就要看 error log，是 panic 还是 fatal， 但是有时候 error log 也是空的，但是这时候就要看是不是因为内存原因被系统杀死了，所以查看指令如下:

前言

自从 用 docker 来部署 mqtt vernemq 之后，后面的指令也会变得很长，比如，如果要进入容器的目录，就要这样子：

1

sudo docker exec -it vernemq-release-cn-1 /bin/bash

每次都要输入这么一大串，很麻烦，所以后面就考虑用添加别名的方式来弄。

编写 alias 命令

Linux操作系统中打开一些应用，有时需要进入对应的文件夹，打开对应的程序，不是很方便。alias命令是一种命令别名命名法，可以将一些复杂的命令简化成一个我们自己命名的相对简单好记的命令。能够极其方便我们的操作。

实操过程

前言

之前看到别人的 blog 上面有一个黑色的 github 的 fork 入口，觉得还挺好的。 打算在自己的 blog 也搞一个。

操作很简单，可以参照这个博文 Hexo博客NexT主题右上角添加fork me on github入口

操作

将这一串代码复制到 themes/next/layout/_layout.swig 文件中<div class="headband"></div>下面一行即可