PageSpy 是由货拉拉一款用来远程调试的工具。可以让你像操作本地 chrome 控制台一样，调试远程页面代码。 PageSpy SDK 支持如下： Repo Type Status page-spy-types Common types Done page-spy-browser Web sdk Done page-spy-wechat Wechat sdk Done page-spy-alipay Alipay sdk Done page-spy-uniapp uniApp sdk Done page-spy-taro Taro sdk WIP page-spy-rn React Native sdk WIP PageSpy 存在两个端: 调试端: 用于开发者查看调试信息 客户端：客户端用于搜集异常数据传输到调试端。 PageSpy 应用场景如下： 远程工作场景下，测试人员反馈程序问题，只需要开启 PageSpy 重现问题步骤，开发者就可以看到具体的报错原因，避免了很多的沟通。 线上一些兼容性问题，可以帮用户开启 PageSpy ，可以快速定位到问题。 PageSpy 模块间的依赖关系和交互示意图： 调试端示意图 控制台： 网络请求： 存储: 调试端安装 Docker docker run -d --restart=always -p 6752:6752 --name="pageSpy" ghcr.io/huolalatech/page-spy-web:latest Node yarn global add @huolala-tech/page-spy-api@latest # if you use npm npm install -g @huolala-tech/page-spy-api@latest 调试端配置 Nginx 配置 将 PageSpy 作为一个完整项目部署： ...

最近用 Go 开发项目，本地发开和调试起来都非常方便，当到了接口对接阶段就出现了问题。 CI/CD 中文为持续集成/持续部署是敏捷开发的重要一环，有了 CI/CD 你可以快速的构建出 Feature/Fix 环境，加快版本的上线节奏。 本次的设计目标是：让开发者只需要提交代码即可，由 Gitlab 去执行代码构建和代码部署的能力，此外我还需要在部署阶段保证服务的正常可用。 我将 Gitlab 流水线 (Pipelines) 设置了两个阶段： 构建：编译出 Go 的可执行文件 部署：完成线上的部署工作 在部署阶段, Runner 会保证原有接口的正常的情况下： 用最新的可执行文件启动一个临时服务，并修改 nignix 反向代理，将所有的新请求代理到临时服务 停掉并升级老服务 把 Nginx 反向代理代理到新的正是服务，关闭掉临时服务。 具体 .gitlab-ci.yml 内容如下： stages: - build - deploy variables: GOMODCACHE: /project-path/mod build: image: golang:1.21 stage: build cache: # 缓存 paths: - mod script: - touch ./config/config.yml # 编译你的 Go 程序 - export GO111MODULE=on - export GOPROXY=https://goproxy.cn - go mod download - go build -ldflags "-linkmode external -extldflags -static -s -w" -o main ./cmd/app/main.go artifacts: expire_in: 1 week paths: - main deploy_test: image: instrumentisto/rsync-ssh:latest # 指定镜像 stage: deploy script: - mkdir -p ~/.ssh - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config - echo "$PREVIEW_SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa # 将 Gitlab 里设置的的私钥环境变量输出到 ～/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - rsync -rav -e "ssh -p 22 -o StrictHostKeyChecking=no" main "root"@"$PREVIEW_SERVER":"$PREVIEW_PROJECT_PATH" - ssh -p 22 -i ~/.ssh/id_rsa root@"$PREVIEW_SERVER" "ln -snf $PREVIEW_PROJECT_PATH/main main_run && supervisorctl restart maintemp && echo 'upstream myserver { server 127.0.0.1:41524 max_fails=3 fail_timeout=30s weight=1; }' > /usr/local/nginx/conf/proxy/main && systemctl reload nginx && supervisorctl restart main" - ssh -p 22 -i ~/.ssh/id_rsa root@"$PREVIEW_SERVER" "echo 'upstream myserver { server 127.0.0.1:8100 max_fails=3 fail_timeout=30s weight=1; }' > /usr/local/nginx/conf/proxy/main && systemctl reload nginx && supervisorctl stop maintemp" retry: 2 only: refs: - master 至此，就完成了 Go 的持续集成和持续部署的目标，开发人员只只需要关注开发本身，提交代码即可，无需关心构建和部署的问题。 ...

最近再开展整合系统的工作，将原有系统中的共用逻辑抽离出来形成一个中台系统，根据业务开展形式的不同，划分出各个子系统。 在开展的过程中，遇到一种情况，在一些场景下子系统需要根据中台系统的一些操作去初始化自身的业务数据。 我们准备用事件（ Event ） 的形式来解决这个问题，子系统监听中台系统发布的一些事件，当中台系统进行相关操作时，触发事件通知监听中的子系统。 我们的中台系统 （ main system ） 是用 go 语言开发的，事件的触发是通过队列的形式发送给 event hadle 然后由它去发送事件通知到各个子系统。 在一些其他语言中，队列的消费一般都是启动一个进程来监听处理。而 go 有协程，可以用更轻量的协程来处理队列消费，这样以来有一个直接的好处就是服务启动了，队列的消费者就跟着启动了，不需要单独维护一个进程的启停。 当然要实现上述能力，有几个问题需要解决： 协程消费者如果崩溃了，不能影响主进程的运行 协程异常要能重新拉起一个新的消费者，保证协程消费者能一直运行。 崩溃隔离 消费者有自己的逻辑，在逻辑处理中有可能会出现 panic，我们需要消费者的 panic 限制在协程里，以避免协程崩溃影响主进程。 Go 有 recover 机制，可以让你捕获 panic 并且限制 panic 不在向上蔓延。代码如下： go (func() { defer func() { if err := recover(); err != nil { fmt.Println("捕获到 panic:", err) return } }() err := EventHandle() if err != nil { Logger.Error("event 处理监听失败", err) } })() 消费者协程保活 消费者业务逻辑在协程里，可能在一些场景（panic 或其他不可知情况）下意外退出，我们需要保证能够重新拉起消费者协程，从而保证整个事件逻辑的闭环。 在这里我们用管道实现一个心跳机制，消费之定时发送心跳到主进程，如果超过一段时间没有发送心跳主进程会认为消费之已经出现异常，会重新拉起一个协程消费者。 主进程监听心跳代码如下: func monitorHeartbeat(heartbeat chan bool) { // 设置心跳包的超时时间 timeoutDuration := 3 * time.Second timer := time.NewTimer(timeoutDuration) for { select { case <-heartbeat: // 接收到心跳包，重置定时器 timer.Reset(timeoutDuration) case <-timer.C: // 超时，重新启动协程 fmt.Println("心跳超时，重新启动协程") go startEvent(heartbeat) timer.Reset(timeoutDuration) } } } 协程发送心跳包代码如下： ...

Laravel 是 PHP 里非常重要的一个框架，对于一个 PHPer 来讲，就算你没有用过 Laravel 也一定听说过它。 同事用 Laravel 开发了一个项目，需要部署一个测试环境，由于服务器的 PHP 环境不满足他项目的要求，所以需要多加一个 PHP 环境。 为了减少对原有系统的影响和更快的安装，我们决定用 Docker 来部署新项目的 PHP 环境。 本以为整个流程会无比的丝滑，但是在推进的过程中遇到了一些问题，也就有了这篇文章记录一下当时的经历，同时也为后续遇到类似问题的同仁提供解决思路。 整个部署方案如下： Dockerfile 很快就编写好了，本地测试能够成功的构建出 Docker Image。到此一切都很顺利，后续只需要把 Dockerfile 上传到服务器在服务器上把镜像构建出来，用 Nginx 解析一下就大功告成了。 当把代码上传到服务器，开始构建 Docker Image 时，问题出现了。在执行 apt update 的时候出现了下面的错误。 The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131 本地构建好好的，怎么上线就出现问题了呢？简单的用搜索引擎搜索了一下，找了几篇带有"亲测"字样的文章进行验证，却都失败了。 后来我想既然这样问问 GPT 吧，看看它有没有什么高见。GPT 告诉我时因为服务器证书问题导致的，这里我就产生了一个疑问，我构建 Dcoker Image 执行 apt update 应该是在 Docker 环境里执行的呀，为什么会跟服务器证书有关系呢？ 于是我继续追问，它给出了自己的解释，让我开始质疑自己了。 ...

在实际的项目部署中，我们有时候会遇到在一个服务器上部署多个 php 环境的情况。遇到这种情况，我们可以在同一物理机上装多个 php-fpm 监听不同端口，Nginx 根据不同的 Vhost 去找不同的 php-fpm 解析。 上述方法虽然可以，但是在项目管理上并不是很友好，比如我需要在某个项目执行 PHP 脚本，那还需要写 /path/php script.php 这样的话就需要每个维护项目的人都十分清楚，哪个项目应该用哪个版本的 PHP 去执行相应的脚本。 其次，如果某天需要把某个项目迁移到其他服务器了，我们还需要在新机器上安装 PHP 环境。 如果用 docker 进行部署，就不会有上面的问题，我们只需要写一次 Dockfile 可以在任何服务器上构建出相同的 php-fpm 环境，从而让迁移更简单，如果需要执行脚本，只需要进入对应的容器，直接执行 php script.php 即可。 php-fpm 官方镜像介绍 在 [php Tags | Docker Hub](https://hub.docker.com/_/php/tags 找到你所需的基础镜像的 tag 扩展安装 Docker PHP 安装有三种方式 Core Extensions： FROM php:8.2-fpm RUN apt-get update && apt-get install -y \ libfreetype-dev \ libjpeg62-turbo-dev \ libpng-dev \ && docker-php-ext-configure gd --with-freetype --with-jpeg \ && docker-php-ext-install -j$(nproc) gd PECL extensions : ...