Posts

由于本地项目比较多，且对于环境要求各不相同，导致电脑上要装多个环境才能满足项目的运行。以我常用的 PHP 开发为例，需要 PHP 7.1 、PHP 7.3、PHP 8.1 、PHP 8.3，在这些项目中 compose 如何寻找到正确的 PHP 版本来安装依赖也是一个比较难以解决的问题。 为了不再受此困扰，我决定用容器来解决我面临的问题。开发环境容器化还有一个考虑就是容器本身对 CI/CD 比较友好，我们在测试和线上环境已经开始转向容器化部署，如果本地也进行容器化，编写好的 Dockfile 可以复用到后面的部署流程。 我的方案是为每个项目编写一个 docker-compose.yml 当我开始进入某个项目的开发工作时。只要打开对应的项目通过 docker-compose.yml 启动容器就可以启动对应项目的开发环境进行开发了。 容器化给我带来了哪些好处： 纯净的物理机：我不需要在物理机上安装各种各样的环境 低负载开发： 只有运行开发的相关环境，其他不相关的服务都不会在后台运行 部署和开发一致： 由于都是 Docker 部署，不会因为环境问题导致本地开发没问题线上出错的情况 专注于开发本身 ：免去了多种环境下互相兼容下的管理工作，专注于开发本身。 在容器话的过程中，我也遇到了一些问题，在这里记录一下，供诸君参考。 一些问题 首先遇到的问题就是依赖缓存的问题，比如一个 GO 的项目，因为 GO 的环境是在容器里，这样每次启动项目都要重新下载一次依赖，浪费时间也没有必要，于是我就将 mod 依赖下载目录通过挂载卷映射到我本机上。 如此依赖就解决了每次启动容器，都要重新安装依赖的问题，这样做还有一个额外的好处就是我其他的 GO 项目也也可以把 mod 依赖下载路径映射到相同的位置，这样就能实现下载依赖的复用，也能避免过多的磁盘占用。 如果你是前端项目使用 pnpm 管理工具，也可以参考上述思路解决 npm 包的依赖复用问题。 遇到的另一个问题就是 Windows 环境下，文件读写性能不足的问题。Windows 用户在开发环境容器化是需要注意一下，如果你的项目运行需要大量的文件读取，会导致项目启动异常慢，这个是 Windows 下面使用容器的硬伤，目前无解。Linux 和 MacOS 并不会出现此类问题。 工具推荐 如果你用 Visual Studio Code 进行开发，可以安装一个 Docker 的扩展，通过设置 Docker: Compose Down 和 Docker: Compose Up 两个快捷键实现快速的启动和停止项目。 ...

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 ./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) } } } 协程发送心跳包代码如下： ...