前言

之前有用户遇到一个问题，就是在访问一个我们的站点的时候，https 模式下没有问题，但是用 http 模式下(因为某些特殊原因，要保留站点的 http 模式的访问)，就会出现接口报错的情况，导致用不了。

而且都是 chrome 才有， 其他浏览器都正常， 而且 chrome 的版本还是比较新的， 87 或者 88。 我自己本身 86 好像挺正常的。 为了验证一下，也将 chrome 版本也升级到 88， 结果还真重现了。

SameSite 的问题

发现是登录接口的时候，原本要写进去的 cookie 虽然写了，但是再访问其他接口的时候，这些 cookie 根本不会带过去， 这样就导致没办法进行 cookie 校验了。 因为 cookie 在跨域的时候，并不会随着请求过去。

前言

我们知道一般无论是 CDN 还是 服务端的接口(nginx 配置gzip以优化站点资源加载速度)，在响应返回的时候，都会配置 gzip 来压缩响应数据，以达到减少体积，加快网络传输的效能。 但是 gzip 压缩只用于 response 的响应数据，一般来说针对 pc 端的站点来说，足够了。

但是有时候针对手机 app 来说，光是 response 用 gzip 压缩还不够， 因为 request 请求的时候，如果有时候 body 体带上很多数据的话，还是会导致体积很大，从而消耗流量。 手机的流量可比 pc 的流量贵多了。 因此对于有些比较注重流量消耗的 app 来说，最好也要做到 request 请求的时候，也用上 gzip 来压缩数据，然后服务端在 nginx 或者程序的网关那边，再根据请求头 Content-Encoding 是否为 gzip 来判断是否要对请求的数据进行 gzip 解压缩。

前言

之前服务端的 nginx 服务有配置 gzip 压缩: nginx 配置gzip以优化站点资源加载速度, 但是在之前有一次服务优化中， 发现同一个服务的不同接口的请求，有些 response 有 gzip 压缩，有些 response 没有 gzip 压缩 ??

前因

之前有写过一篇 记一次接口受到的基于http请求的DDOS攻击 讲述一次抵御 DDOS 攻击的情况。 但是后面攻击的方式又增加了，最明显的两点就是:

1. user-agent 都是正常的浏览器类型
2. ip 地址都是很分散的，并且每分钟的请求频率都不高，也就 3-5 次， 但是不同 ip 请求非常多

第二点就会导致我们的禁 ip 策略就被废掉了，因为我们不能把限制降的很低，比如同一个 ip 地址请求登录接口一分钟如果超过 3 次，就会被加入黑名单。这样子固然可以抵御， 但是也会造成大面积的误杀。 说白了，就是这些突然爆增的流量跟正常的用户流量没啥两样。 防刷脚本已经没办法去区别了。

前言

之前我们有初步使用了 Jaeger 作为分布式链路追踪: 使用 jaeger 给你的微服务进行分布式链路追踪, 但是用的是仅供测试的 Jaeger All-in-one 一体包, 他的存储中心是直接存放在内存的。 所以用到生产环境肯定是不行的。

所以生产环境我们要单独安装以下组件

• Jaeger-Agent
• Jaeger-Collector
• Backend storage (Elasticsearch)
• Jaeger-Query (UI)

所以结构图就会变成这样子了:

前言

现在的 ssl 证书变成一年一换了， 所以运维人员每年都要在证书过期之前要去换证书，我们的业务涉及到二级域名以及下面的三级域名其实不少 (超过了 50 个), 而且在换证书的过程中，还会存在以下问题:

1. 服务部署在不同的云服务厂商，所以换证书的渠道可能有好几个(以 aws 来说，有些证书是在 EC2 上，有些用到了 cloudfront 加速的，还要去后台换), 更别说有好几个云服务厂商
2. 有时候不是简单的替换证书就完事了，大部分服务还要重启，比如 golang， php 服务一般也要重启 nginx， 所以因为量太大了， 有时候可能会忘掉
3. 验证的时候，https 还比较好验证， 如果是其他协议，比如 wss，那个就比较不好验证了。如果证书过期了，连接 wss 的时候， 浏览器就会报这个错

前言

前段时间有个业务速度变得比较慢，而且有时候会超时，但是开发人员很难跟踪，原因是因为这个业务涉及的到客户端和微服务都比较多，很难去排查到底是哪个环节，因为如果从每一个环节每一个环节看的话，好像有没啥问题，但是确实有时候就是会出现速度慢的情况，而且排查非常的麻烦，因为不同的客户端可能开发人员和开发语言都不太一样，所以就会造成一种情况，就是大家好不容易凑在一起，然后各自看各自端的 log，一直到找到那个时间点的有问题的 log 出来， 偶尔这样子还好，要是经常这样子干，大家都不用干活了，而且很多时候客户端的日志都在用户那边，有时候根本就没法给到。

基于以上这种情况，我们服务端就需要有一种服务来跟踪多个微服务之间的分布式全链路传输情况。

APM 简介

关于什么是 APM, 有一篇文章我觉得讲的挺好的: APM 原理与框架选型，文章讲了很多关于 APM 的基础知识， 以下是部分摘录:

前言

之前在 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 ????