前言

之前有针对图片的模板匹配有做了一个优化的版本: 使用 gocv 进行图片的模板匹配优化之 - 批量多模板匹配, 但是还不够，还需要再优化两个点:

1. 直接从 origin 文件夹里面读取原图，从 template 文件夹里面读取模板图，随后如果有匹配的话，将匹配圈出来的原图输出到 output 文件夹
2. 配置是否启用同步缩放匹配 (好处就是匹配速度很快， 坏处就是如果模板图信息太少的话，会出现匹配度太低的情况)

第一点优化很好理解，如果 原图很多， 模板图也很多的话， 肯定要变成直接读取，然后遍历文件夹的方式， 匹配结束之后，如果有匹配上，然后统一输出到另一个文件夹中

第二点是考虑到如果原图 size 很大，匹配的过程就会很耗费 cpu，而且时间会比较长。 所以可以设置缩放因子，将原图和模板图按照固定的比例进行缩放， 然后再匹配。 这样子做的好处就是因为双方的像素点变少了，所以匹配的速度就会很快， 坏处就是如果模板图的可识别区域比较少，再加上压缩之后，就会出现匹配度太低，导致我们认为无法 match 的情况。

所以最好模板图的尺寸不能低于 30px。 而且缩放的比例也不能高于 0.5， 这样子速度才会快。

前言

之前有针对图片的模板匹配有做了一个简单的版本: 使用 gocv 进行图片的模板匹配, 接下来针对做一下优化:

1. 之前代码写在一起， 现在当然要抽象出来
2. 允许多个原图进行多个模板来匹配
3. 最后输出的效果图，如果有多个模板匹配的话，都要全部圈出来

实操

首先 原图就两个 (1.jpg 和 2.jpg)， 然后模板图有3个 (分别是从 1.jpg 扣下一块， 从 2.jpg 扣下两块)。 最后奉上代码:

前言

之前成功安装了 gocv: CentOS 7 安装 GoCV, 今天就写个 demo 来测试一下。

demo 逻辑

逻辑如下， 在一张原图中， 从中截一个小片段出来，然后去匹配， 看看匹配度是多少， 然后在原图中圈出要匹配的模板的位置。

比如我从这一张原图中，截取艾斯右手燃烧的部分出来。

前言

前段时间， 业务上有需要用到图像识别的功能， 用的是开源的 OpenCV, 刚好我们的服务端语言 golang 有支持 OpenCV 这个开源库的库: GoCV

所以就在服务器上进行安装, 服务器环境就是 CentOS 7

操作之前

既然是 golang 的库，当前要先安装 golang:

1

yum install golang

安装后的版本是:

1
2

[root@VM-16-29-centos ~]# go version
go version go1.15.5 linux/amd64

开始安装

官方有 linux 的安装教程的: linux install

首先安装 GoCV 的包:

1

go get -u -d gocv.io/x/gocv

然后到目标目录:

1

cd $GOPATH/src/gocv.io/x/gocv

然后在该目录下执行安装就行了:

1

make install

如果一切顺利的话，最后打印应该是版本号:

1
2

gocv version: 0.26.0
opencv lib version: 4.5.1

所以就完啦 ??? 那写个毛线 blog， 没见过这么水字数的。 所以不出意外， make install 应该是报错了:

前言

前段时间有一个 php 的业务接口，响应时间很长， 超过了 10s， 然后 php-fpm 就显示超时了，然后 nginx 就返回 502 了。

虽然后面通过配置 php-fpm.conf 的这个设置，将其改为 20s (之前是设置为 10s)

1
2

[kbz@ip-10-1-2-146 ~]$  cat /usr/local/php/etc/php-fpm.conf | grep te_timeout
request_terminate_timeout = 20s

然后让前端的超时时间也改成 30s。 这样子接口是可以跑了， 但是还是慢。

后面发现是这个接口会去执行一些很复杂的运算逻辑，而且涉及到一些库操作。 但是在这之前需要返回给前端的数据都已经有了。

所以这一块执行时间比较长的运算逻辑其实是可以做成异步。 而我们目前项目的异步都是通过抛消息队列去处理的。 但是因为这一块逻辑涉及的相关联的函数比较多， 所以在消息队列那边再写一套也不现实。 如果是抛送 curl 单独执行这一部分逻辑的话，一旦响应时间超过了 20s， 也会 502。

前言

前段时间我们的官网上了新版本， 有将一些对 seo 不友好的旧页面的路由变成了新页面的路由。 比如将 bizHome.html 换成 business/, 但是其实内容是一样的。

刚开始为了保证旧页面不失效，在构建的时候，是将新页面和旧页面的内容都构建成一样的。 但是这样子一来， seo 的权重就被割裂了。

所以为了保证新页面的 seo 权重能够继承旧页面的权重。就要换成将旧页面的访问全部变成 301 的永久跳转到新页面上。

nginx 进行 301 跳转

如果要进行 301 永久性跳转的话，是没办法在前端层面上进行的。 只能在服务端上进行， 而我们用的是 webserver 是 nginx， 所以要在 nginx 上面配置。

假设我们这次要调整的页面有以下:

前言

之前有发生过一个比较奇葩的问题， 就是我们的测试人员有发生过， 移动端的 chrome 点击下载链接失效的情况。 但是 pc 端的 chrome 是正常的。 并且移动端的非chrome 浏览器， 比如 Firefox 或者 Safari 也是正常的。

排查

后面调试了一下，发现这个跳转用的是 window.open 语法:

1

window.open(url)

我们知道 window.open 的触发必须得有用户点击触发才行(具体可以看: 部分浏览器事件如果不是用户手动触发的话，会被浏览器block), 所以我们也是绑定到 click 事件中的。 所以应该不是这个问题， 因为如果是这个问题，其他浏览器也是不行的。

而且通过调试，我发现窗口是有弹出来的，但是一直卡在一个空的页面，并没有完整的跳转过去。 所以应该是 chrome 检测到这次的跳转不安全，所以禁止了。

而关于 window.open 还真有一个安全隐患，那就是子窗口可以得到父窗口 opener 句柄, 从而在用户不知道的情况下， 对父窗口的导航栏进行重定向， 这个其实对用户来说是一个安全隐患的， 我之前有写过这方面的安全和应用方法，具体可以看:

• web 安全之 - A 标签target=”_blank”的安全问题及解决办法
• window.open() 打开的子页面往跨域的主页面传参问题

他虽然是一个安全隐患，但是他并不是毫无用处的， 还是有其他用处的， 但是对于本例来说， 可能确实有这种问题，所以我就改成

1
2
3

var newWnd = window.open();
newWnd.opener = null;
newWnd.location = url;

改成这样子，果然 移动端的 chrome 浏览器就可以正常了。

当然如果只是点击下载的问题，那么可以不使用 window.open， 改成 a 标签跳转 或者 iframe 下载也是可以的。

前言

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

而这个输入的一次性密码，其实就是我们所说的两步验证，这不是什么新奇的技术，国内都使用了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。