前言

我们往往会在不同的网站上使用相同的密码，这样一旦一个网站账户的密码泄露，就会危及到其他使用相同密码的账户的安全。没错, 就是撞库行为, 往往你的站点的安全机制没有问题，但是架不住你的用户使用的密码跟其他被脱库的站点使用的密码一致(现在免费的社工库很多，随便写个简单的暴力碰撞程序(记得挂上代理)，就可以试出一堆可以正常使用的用户名和密码), 导致很容易通过撞库的行为从而知道这个用户在你站点的用户名和密码。 为了解决这个问题，一些网站在登录时要求除了输入账户密码之外，还需要输入另一个一次性密码。

而这个输入的一次性密码，其实就是我们所说的两步验证，这不是什么新奇的技术，国内都使用了N多年了，比如说银行用的动态令牌

再说一个大家比较有情怀的东西，就是早期网易的将军令(爷春回) 也是用的这个技术:

虽然不是什么新技术，不过早期因为手机的不普及，更多的是用硬件的方式来实现 (这玩意儿一旦没有电，就必须重新换一个，因为他没办法联网同步时间，不过这个耗电量极低，一个可以用好几年)。 但是随着手机的普及，以及大家的安全意识的提升。 越来越多的站点都用软件的方式来实现(比如 Evernote， Google， 以及我所在团队的站点)，而且成本很低。

前言

之前有出现过一种情况，就是我们的静态站点是有国内和国外加速的(这个是在 aws 的 router 53 服务配置的)，比如:

• 如果是国内访问的，那么就引导到腾讯云的 COS 存储服务 + CDN 服务
• 如果是国外访问的，那么就引导到 aws 的 S3 存储服务 + Cloudfront CDN 服务

正常的文件当然没问题，但是有时候会出现如果 url 后面不输入 index.html，直接子目录斜杠结尾，比如 https://m.foo.com/cast/ ，这时候腾讯云表现是正常的，因为他会索引到 https://m.foo.com/cast/index.html, 但是 aws 的 cloudfront 就不行，会直接报错， 显示获取 S3 对象失败:

1
2
3

[kbz@VM_16_9_centos ~]$ curl https://m.foo.com/cast/
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>QABCT7FCM4M3T4AR</RequestId><HostId>VnPLeZeR2KQkIMDrFhukmVLUGp+RBWbZO/V8qHeS0dGKLa1N8KOTbWvwNW/J2NKbQWqQXyP5wdw=</HostId></Error>

更有甚者，如果我连子目录的斜杠都没有写全，直接子目录的话，比如 https://m.foo.com/cast， 这时候腾讯云的表现也是对的，他如果找不到 cast 这个文件的话，就会将其当做一个子目录，再去检索这个子目录下的 index.html 文件。所以你用 curl 请求的话，会返回一个 302 跳转，然后 location 头部就会带上 https://m.foo.com/cast/, 这时候就会跳转到正确的页面:

前言

前段时间有遇到比较奇葩的需求，就是正常情况下，我们站点在进行第三方登录的时候，会通过 window.open 的方法，打开一个服务端的接口页面，然后这个服务端的接口去判断当前是否有授权行为，如果有的话，就写入 cookie，然后关闭当前窗体， 如果没有的话，就跳转到第三方的授权页面，然后在授权结束，回调的时候，写入 cookie，然后关闭当前窗体，前端会监听当前的窗体，当发现已经关闭的时候，就会去请求自动登录的接口，这时候，因为 cookie 信息已经让服务端写入了，所以这时候就可以正常登录，这时候前端还会读取服务端的某一个 token cookie， 然后生成当前一次性令牌 token， 以供服务端进行校验。

正常情况下是没有问题的，但是由于 chrome 浏览器在新版本的时候，cookie的默认设置会有 SameSite=Lax，这时候就会导致前端读取不了服务端的 cookie (chrome 默认 cookie 的 SameSite=Lax，导致 http 模式的站点的第三方 cookie 无法进行跨域传输)， 从而无法生成一次性访问 token 令牌， 这时候再去请求自动登录的接口，就会出现校验失败。

所以这边的想法是，服务端在生成 cookie 的时候，能不能在窗口关闭之前，往前端传 当前的一次性令牌的 token。这样子前端就可以带上这个 token 去进行自动登录的校验。

所以这边就会涉及到 window.open() 打开的子页面， 往主页面传参问题。

前言

之前有用户遇到一个问题，就是在访问一个我们的站点的时候，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, 写法也没毛病， 配置也很简单， 甚至源代码都很好理解，也不复杂。