<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://zhengtianbao.com/</id><title>Zhengtianbao's Blog</title><subtitle>Zhengtianbao's Blog</subtitle> <updated>2024-07-25T19:55:17+08:00</updated> <author> <name>zhengtianbao</name> <uri>https://zhengtianbao.com/</uri> </author><link rel="self" type="application/atom+xml" href="https://zhengtianbao.com/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://zhengtianbao.com/"/> <generator uri="https://jekyllrb.com/" version="4.3.3">Jekyll</generator> <rights> © 2024 zhengtianbao </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>通过软考高级「系统架构师」的一些经验总结</title><link href="https://zhengtianbao.com/posts/ruankao/" rel="alternate" type="text/html" title="通过软考高级「系统架构师」的一些经验总结" /><published>2024-07-24T08:56:20+08:00</published> <updated>2024-07-24T08:56:20+08:00</updated> <id>https://zhengtianbao.com/posts/ruankao/</id> <content src="https://zhengtianbao.com/posts/ruankao/" /> <author> <name>zhengtianbao</name> </author> <category term="2024" /> <summary> 在 2023 年下半年的时候，我有了参加软考高级「系统架构师」考试的想法。众所周知，软考的证书其实并没有什么用处，并不会因为你有这个证就认为你是架构师了。那我为什么还要考呢，因为考虑到整体的大环境不行，各个公司降息裁员的消息层出不穷，指不定哪天就要面临「毕业」，对未来的预期实在是不容乐观，现实就是那么令人无奈，不管你是如何轻视这个证书，但它却是官方认可的计算机行业资质证书，多一本证书也许就能在茫茫多的求职者简历中增加一点留存下来的几率。 为此，我参加了 2023 年下半年以及 2024 年上半年两次考试，第一次挂在论文上面，第二次顺利通过，总体感觉这个「系统架构师」考试难度不大，熟悉 Java 生态圈技术栈的有很大优势，当然也存在一定的运气成份。 考试分三个科目：综合知识，案例分析以及论文。在 2023 年的时候上午是综合知识和案例分析联考，下午是论文，而 2024 年的时候时间... </summary> </entry> <entry><title>Tauri 集成 Vue 构建跨平台桌面应用</title><link href="https://zhengtianbao.com/posts/electron-vs-tauri/" rel="alternate" type="text/html" title="Tauri 集成 Vue 构建跨平台桌面应用" /><published>2024-06-20T09:13:49+08:00</published> <updated>2024-06-20T09:13:49+08:00</updated> <id>https://zhengtianbao.com/posts/electron-vs-tauri/</id> <content src="https://zhengtianbao.com/posts/electron-vs-tauri/" /> <author> <name>zhengtianbao</name> </author> <category term="2024" /> <summary> 由于云服务器到期，之前开发的项目很快就要面临下线的危机，鉴于目前使用人数也不多，因此考虑将程序改造为桌面应用。 前端是基于 Vue 框架开发的，在改造过程中有以下两点要求： 首先是能够复用代码，不需要大量修改 其次是能够跨平台构建，需要支持 Linux，Mac，Windows 平台运行 因此我首先想到的就是 Electron：内嵌 Chromium 浏览器和 Node.js 运行时生成的浏览器套壳应用。通过 electron-builder 将现有的 Vue 项目进行配置后，运行构建命令生成了以下文件： $ ls -lh dist total 214M drwxrwxr-x 2 zhengtianbao zhengtianbao 4.0K Jun 18 15:08 assets -rw-rw-r-- 1 zhengtianbao zhengtianbao 803... </summary> </entry> <entry><title>包管理器的依赖管理</title><link href="https://zhengtianbao.com/posts/package-manager/" rel="alternate" type="text/html" title="包管理器的依赖管理" /><published>2024-06-13T14:13:08+08:00</published> <updated>2024-06-13T14:13:08+08:00</updated> <id>https://zhengtianbao.com/posts/package-manager/</id> <content src="https://zhengtianbao.com/posts/package-manager/" /> <author> <name>zhengtianbao</name> </author> <category term="2024" /> <summary> 设计一个包管理器需要考虑很多方面的问题：如何定义软件包的格式（zip，tar），如何定义软件包的元数据（名称，版本，作者信息，依赖包等），如何在安装包的时候解决依赖关系，如何进行版本管理，如何安装或者卸载软件包，如何进行软件包的存储和分发，如何支持多操作系统等问题。 本文主要针对包管理器在安装软件包过程中是如何解决依赖冲突和循环依赖的问题，用 go 语言进行了简单的描述。 依赖关系描述 如何描述依赖关系不同语言有不同的实现，在每个软件包的元数据文件中（如 package.json、setup.py、requirements.txt、POM.xml 等），定义依赖项和版本约束。例如： npm: 使用 package.json 中的 dependencies 字段。 pip: 使用 setup.py 或 requirements.txt 文件。 Maven: 使用 ... </summary> </entry> <entry><title>Prometheus 加载配置部分缺失问题记录</title><link href="https://zhengtianbao.com/posts/prometheus%E5%8A%A0%E8%BD%BD%E9%85%8D%E7%BD%AE%E5%A4%B1%E6%95%88%E9%97%AE%E9%A2%98%E8%AE%B0%E5%BD%95/" rel="alternate" type="text/html" title="Prometheus 加载配置部分缺失问题记录" /><published>2024-05-29T15:05:31+08:00</published> <updated>2024-05-30T17:12:59+08:00</updated> <id>https://zhengtianbao.com/posts/prometheus%E5%8A%A0%E8%BD%BD%E9%85%8D%E7%BD%AE%E5%A4%B1%E6%95%88%E9%97%AE%E9%A2%98%E8%AE%B0%E5%BD%95/</id> <content src="https://zhengtianbao.com/posts/prometheus%E5%8A%A0%E8%BD%BD%E9%85%8D%E7%BD%AE%E5%A4%B1%E6%95%88%E9%97%AE%E9%A2%98%E8%AE%B0%E5%BD%95/" /> <author> <name>zhengtianbao</name> </author> <category term="2024" /> <summary> 问题描述 prometheus 在执行配置文件热加载的时候出现了部分配置没有加载的现象。 主配置文件内容为： global: scrape_interval: 15s evaluation_interval: 15s scrape_timeout: 15s alerting: alertmanagers: - static_configs: - targets: - 12.99.78.69:9093 - 12.99.78.70:9093 rule_files: - '../rules/*rules.yml' scrape_configs: - job_name: '核心业务系统' metrics_path: /actuator/prometheus file_sd_configs... </summary> </entry> <entry><title>Golang HTTP Client 请求 BIG-IP 负载均衡失效问题记录</title><link href="https://zhengtianbao.com/posts/golang-HTTP-%E8%AF%B7%E6%B1%82%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%A4%B1%E6%95%88/" rel="alternate" type="text/html" title="Golang HTTP Client 请求 BIG-IP 负载均衡失效问题记录" /><published>2024-05-28T10:14:57+08:00</published> <updated>2024-05-28T10:14:57+08:00</updated> <id>https://zhengtianbao.com/posts/golang-HTTP-%E8%AF%B7%E6%B1%82%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%A4%B1%E6%95%88/</id> <content src="https://zhengtianbao.com/posts/golang-HTTP-%E8%AF%B7%E6%B1%82%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%A4%B1%E6%95%88/" /> <author> <name>zhengtianbao</name> </author> <category term="2024" /> <summary> 问题发现 事情是这样的，我们的 prometheus 开启了 remote_write 功能，将指标数据推送到 kafka-adapter，然后转发给 kafka 交由后续服务消费处理。随着接入系统指标的增加，发现 kafka-adapter 负载过高，因此进行横向扩容，通过负载均衡将 prometheus 的请求进行转发。 在测试环境通过 nginx 配置功能测试正常后上生产环境，但是最后的验证阶段发现 promethues 的数据只会向一台 kafka-adapter 发送数据，唯一的区别是生产环境是通过 BIG-IP 做负载均衡配置。在我的认知里 BIG-IP 只会更加可靠，为什么会出现这样的现象呢？ 排查步骤 BIG-IP 配置出错？ 我们首先怀疑是 BIG-IP 的配置问题，因此先用 go 编写一个服务，功能很简单，返回给客户端本机的 IP 地址，这样通过客户端不... </summary> </entry> </feed>
