Introduction

欢迎来到我的博客,本博客主要分享 WEB 开发的一些学习经历。以及我个人读书的思考和对生活的感悟。

  • 本博客也会涉及一些对于编程思想的介绍和开发工具的一些好用的插件及进阶用法。

  • 如果博客里的文章引发了你的思考,欢迎你与我交流。

谈谈规范

在多年的开发经历中,我发现不重视编程规范是普遍存在的一个问题。很多开发人员对规范的态度都是很抵触的,认为规范的条条框框是枷锁,会降低开发效率。 不仅仅是普通员工,很多公司的管理人员对于规范的重视程度也是不够的,甚至就没有制定规范的想法。 为什么会出现这种现象呢,我想每个人都会有自己的角度,大多数原因可能是因为项目周期紧张,没有时间制定规范,或是单纯的认为规范会影响开发效率。 上面的原因是客观存在的,所以大家对于不制定规范也没有太大的心智负担。今天我想就这个现象谈谈我对规范的认识。 规范一般有两种,一种是项目规范一种是编程规范。 关于项目规范 我在刚开始入行的时候,公司虽然也没有自己的规范,但是带我的前辈,给了我一份谷歌的开发规范,让我学习,代码的书写格式是怎么样的,什么时候应该换行,应该怎么避免写嵌套 if… 这让我对代码规范有了一个最基本的认识。 代码需要书写的简洁,易读。代码规范有点像写文章时的字体工整程度,越遵守代码规范,字体就越工整。你可以想象就算同样的一篇文章,字体工整和字体潦草给阅读人的感受是完全不同的。 后来我在一家公司做管理,刚到公司时也没有自己的规范,每个人的代码风格,变量命名,项目组织的习惯各有不同,导致项目的风格多样,这给我们带来了一些问题。 维护成本高 当我们维护其他同事写的代码的话,需要从头开始阅读一遍代码,才能了解问题具体出在哪。如果我们有规范就不需要通读所有代码,仅需依据规范出问题代码的大体位置。 代码复用差 当我们有一些通用业务需要封装时,如果没有规范,就需要考虑所有的代码风格,甚至要做一些额外的兼容才能把组件封装完成,有了规范我们完全就可以避免这类问题。 项目对接慢 由于没有规范,每次公司来了新同事,我们并没有很完善的文档给到他。导致新同事上手项目比较困难,中间还要不断地去询问老同事,才能对代码有一个相对比较完善的理解。 这无疑增加了很多的摩擦成本,且团队越大,这种摩擦成本就会越高。就像我们都说中文,又各自有自己的方言,大家需要了解每个人的方言体系,才能更好的深入交流。 我们需要“普通话”这样一个统一的说话规范,来降低我们团队内部的摩擦成本。 建立规范 为了解决上述问题,我们结合自身团队的特点,参考了他人的规范制定出了我们自己规范的初版。 初版规范经过内部评审和修改后,我们形成了自己的规范文档。 后续我们在实践的过程中遇到了一些规范上的不足,也进一步对规范做了补充,使规范在原有的基础上不断的迭代和优化。 这样一套规范建立后,使我们每一步都是在之前的基础之上,而不是每一次都是从 0 开始。这让我们可以不断的阶梯向上。 如何让规范落地 规范的制定后就需要考虑规范落地问题,如何让团队更好的遵守规范。 首先需要让团队认识到规范对我们团队合作是有益的。做好心理建设,消除心理的抵制情绪。 把规范塑造成开发文档,让团队养成经常查阅的习惯,对规范有疑惑就去规范文档找答案。 利用工具降低规范的执行难度,像一些代码风格的问题可以通过 IDE 代码格式化解决,不用团队开发者额外注意。 使用静态代码分析工具检测代码是否符合规范,如果使用 CI/CD 可以把这一步集成到 CI/CD 中,让不符合规范的代码,无法提交到线上环境。 关于编程规范 编程规范包括:设计模式,设计原则,编程范式,最佳实践等等。这类规范一般是行业发展多年,一些经验丰富的前辈总结的一些开发工作的规范。 因为这类规范通常是前辈们在长期实践中总结出来的。遵守这类规范能让我们更容易开发出稳定的程序,少走弯路。 这类规范一般都具有普遍性,对语言没有任何的限制,因此一旦你熟练的掌握,你用任何语言开发的程序都会有更好的稳定性,更少 Bug 、更容易维护和扩展。 我发现有些同学会遇到一些奇奇怪怪的问题,或者一段时间后,程序出现了运行瓶颈。有不少是因为没有遵守某些编程规范引发的问题。 有时他们不遵守编程规范,并非不愿意,而是因为他们不了解某些规范。因此对于编程规范,要像探寻宝藏一般,时常去探索一下。不断地完善和补充自己对编程规范的理解。 总结 规范短期看可能会觉得有点浪费时间,影响开发效率,从长期看,却未必如此,那些减少的 Bug, 复用的代码,以及与同事之间协作效率的提升,足以弥补开发时的损耗。 牛顿说:我之所以比现别人看的远,是因为我站在巨人的肩上。 运用前人的智慧和经验,能让我们做事情更加的顺利。要站在前人的肩膀上,哪怕你觉得这个人不够高,也比自己站在平地上看的更远。

September 20, 2024 · 1 min · 云溪

零停机升级服务

在项目迭代的过程中,我们经常会进行更新线上代码的操作,而更新的操作我们会希望影响的用户越少越好,最好是能做到零停机更新。 在目前云原生的大背景下,K8s 的滚动更新策略会更为人知一些,但是一些中小型项目的部署建立一套 K8s 服务从成本和收益的角度来看是有些得不偿失的。 本文介绍用 Docker 和 Traefik 如何实现零停机升级服务。关于 Traefik 在 更靠近云原生的反向代理神器-Traefik 一文中有更详细的介绍。 整个服务部署流程如下 本方案通过 gitlab CI/CD 来进行部署,开发人员仅需在对应的分支提交代码,服务器会自动完成 构建 -> 部署 -> 通知 等操作。 在 部署 阶段通过蓝绿发布的方式来进行零停机升级的。 蓝绿发布是通 shell 脚本进行操作的,由于 Traefik 的 docker provider 不支持动态的增删服务,本方案采取了 file provider,shell 会启动新服务的时候修改Traefik 的 file provider 来把新服务加入到负载均衡的集群,并在新服务启动完成后,把老服务从负载均衡迁出并停用老服务。 得益于 Traefik 对动态配置的支持,所有对配置文件的修改是无需重启 Traefik,它会自动发现配置文件的变动,把最新的配置加载到程序内部。 整个 部署 流程中始终都会有容器在线提供服务,我们也就实现了零停机升级系统的目标。 本文最后会附上一份完整的 demo 链接,感兴趣的可以下载之后运行一下了解整个操作机制。 本方案还存在一些局限,如蓝绿发布其实是 blue 和 green 交替提供服务,如果你本身是一个服务集群,这个方案并不能很好的适应。 如果你面临上述问题可以考虑 docker swarm 来解决问题,或者部署 K8s,其间的选择主要是看你服务的规模。 本文到此基本结束,如果你更好的想法,欢迎留言讨论。 示例代码:https://github.com/yunxi177/zero-downtime References zero-downtime deploys with Docker Compose and Traefik:https://github....

September 18, 2024 · 1 min · 云溪

更靠近云原生的反向代理神器-Traefik

Traefik 是一个用于反向代理的软件,如果你没有听说过,可以把它看作 Nignx 也是可以的。 Traefik 相比与 Nginx 更适合容器化部署: 只需要配置下容器的标签,Traefik 就可以自动发现新服务的加入,并根据标签绑定对应的域名 支持 TLS 证书自动申请(Let’s Encrypt) 支持 TCP/UDP 协议的转发 支持动态配置,可以在服务运行的状态下进行 Service、Router、Middleware 的增/删/改 Traefik 在项目最初部署阶段,会让整个部署更聚焦。以前用 Nginx 部署,你除了需要把容器启动起来,还需要配置 Nignx 将对应服务的域名反向代理到容器导出的端口上。 Traefik 将这个绑定域名的步骤放在了 docker compose 编写的阶段只需给容器加一个标签即可。项目上线时启动容器,Traefik 根据标签的配置把域名绑定到对应的容器上。 Traefik 可以通过 docker network 容器进行通讯,这意味着容器服务的端口无须再导出到物理机,Traefik 通过 docker network 就可以找到对应的容器处理请求。 Traefik 整个流程如下(中间件非必须,可有可无): 入口点(Entrypoints) -> 路由(Routers) -> [中间件(Middleware)] -> 服务(Service) -> Server Traefik 的配置分为两个:程序配置和路由配置。程序配置通过 traefik.yml 文件进行配置。traefik.yml 提供了路由配置的解析引擎(Providers)。 traefik.yml 配置示例如下: log: level: INFO accessLog: {} api: dashboard: true insecure: true entryPoints: # 入口点配置 web: address: ":80" providers: docker: # 通过 docker label 的方式进行路由配置 endpoint: "unix:///var/run/docker....

September 2, 2024 · 2 min · 云溪

我把本地开发环境全部容器化了

由于本地项目比较多,且对于环境要求各不相同,导致电脑上要装多个环境才能满足项目的运行。以我常用的 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 两个快捷键实现快速的启动和停止项目。...

August 17, 2024 · 1 min · 云溪

Pagespy 落地实践

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 端,我们业务主要以小程序为主,且可以比较方便的找到客户帮忙排查问题,因此并没有使用这个功能。

March 16, 2024 · 1 min · 云溪