PageSpy 是货拉拉开发的一款可以远程调试前端页面、小程序的工具。在调试端，你可以像操作 chrome 控制台一样很方便的查看 console 输出、网络请求、本地存储、SEESION/COOKIE。基本上 PageSpy 的调试端相当于一个 chrome 控制台，只不过他可以让你本地调试任何远程的客户端。 关于 PageSpy 在前端远程调试利器 PageSpy 更详细的介绍。 理论上 PageSpy 能力还是很强大的，为了保证方案更好的落地，我们希望在解决我们主要痛点的同时，接入成本要尽可能的简单。 我们准备用 PageSpy 做线上偶发性异常调试,在前端开发中经常会遇到自己测试没问题，但是客户那边有问题。这种问题调试起来往往都会比较繁琐。 通过 PageSpy 可以轻松的看到客户那边的报错信息，可以更方便有效的进行问题的定位。 为了方便管理和排查，我们做了如下参数约定： # title 作为调试端房间列表显示的标识 # project 为所接入项目的标识 new PageSpy({title: 'user01', project: 'test'}) 此外 PageSpy 的引入也是动态加载的，我们在页面的某个位置加入触发机制，当客户出现问题时，我们会告知客户触发加载 PageSpy 复现 Bug， 这时我们的前端工程师就可以在房间列表中查看客户那边的具体报错，辅助前端工程师解决问题。 我们可以看到 PageSpy 还有日志回放的功能。如果引入这个能力，客户只需要加载出 PageSpy ，并触发 Bug 点击上传日志即可。前端工程师可以根据客户上传的日志，通过日志回放看到具体的报错。这样就把问题的反馈变成了异步的形式，无需前端工程师和客户都在线。 PageSpy 日志回放，目前只支持 WEB 端，我们业务主要以小程序为主，且可以比较方便的找到客户帮忙排查问题，因此并没有使用这个功能。

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 ....

最近再开展整合系统的工作，将原有系统中的共用逻辑抽离出来形成一个中台系统，根据业务开展形式的不同，划分出各个子系统。 在开展的过程中，遇到一种情况，在一些场景下子系统需要根据中台系统的一些操作去初始化自身的业务数据。 我们准备用事件（ 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 或其他不可知情况）下意外退出，我们需要保证能够重新拉起消费者协程，从而保证整个事件逻辑的闭环。...

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 环境里执行的呀，为什么会跟服务器证书有关系呢？ 于是我继续追问，它给出了自己的解释，让我开始质疑自己了。 好的，它让我按照它的方案解决，我就试试吧，不出所料的失败了。到此我决定放弃对 GPT 的依赖，再次尝试用引擎来解决问题。...