Go 源码里的这些 go: 指令 && go 自动化工具

Go 源码里的这些 go: 指令 && go 自动化工具 开发人员有很强的自动化重复性任务的倾向,这也适用于编写代码。 样板代码可能包括设置基本文件结构、初始化变量、定义函数或导入库或模块等操作。 在某些情况下,包提供样板代码作为开发人员构建的起点,通常是在代码行为配置之后生成。 尽管样板代码对于应用程序功能可能是必要的和有价值的,但它也可能是浪费和冗余的。出于这个原因,有许多工具可以最小化样板代码。 go generate 是Go编程语言的命令行工具,允许自动生成代码。您可以使用 go generate 为您的项目生成易于修改的特定代码,使该工具在减少样板文件方面功能强大。 go generate 这个命令通常用于在编译前自动生成代码。它可以用来创建那些重复性高或者模式化的代码,从而节省时间和减少错误。想想看,这在哪些情况下会特别有用呢?🤔 比如说下面有一个简单的例子,在代码中: //go:generate echo Hello, cubxxw ! 在这个例子中,当我们运行 go generate 命令时,它将执行注释中指定的命令。在这个例子里,它会打印出 “Hello, cubxxw !"。 因此,元编程(metaprogramming)的主题是一个开发和研究的热门领域,可以追溯到 1960 年代的 Lisp。元编程中一个特别有用的领域是代码生成(code-generation)。支持宏的语言内置了此功能;其他语言扩展了现有功能以支持这一点。 go:generate 在我们之前的讨论中,我们已经介绍了 “Go Generate” 命令的基础知识。现在,我们将深入探讨一些更具体的用例和实践技巧。🚀 让我们从一些术语开始。go generate 工作方式主要由三个参与者之间协调进行的: Generator:是由 go generate 调用的程序或脚本。在任何给定的项目中,可以调用多个生成器,可以多次调用单个生成器等。 Magic comments:是 .go 文件中以特殊方式格式化的注释,用于指定调用哪个生成器以及如何调用。任何以文本 //go:generate 行开头的注释都是合法的。 go generate : 是 Go 工具,它读取 Go 源文件、查找和解析 magic comments 并运行指定的生成器。 需要强调的是,以上是 Go 为代码生成提供的自动化的全部范围。对于其他任何事情,开发人员可以自由使用适合他们的任何工作流程。例如,go generate 应该始终由开发人员手动运行; 它永远不会自动调用(比如不会作为 go build 的一部分)。此外,由于我们通常使用 Go 将二进制文件发送给用户或执行环境,因此很容易理解 go generate 仅在开发期间运行(可能就在运行 go build 之前);Go 程序的用户不会知道哪部分代码是生成的以及如何生成的。(实际上,很多时候会在生成的文件开头加上注释,这是生成的,请别手动修改。)...

January 25, 2024 · 5 分钟 · 973 字 · Xinwei Xiong, Me

对开源商业化的思考 & 全球流量大会(GTC)学习以及总结

引言:深圳福田会展中心的全球视野 2023年12月6日,在深圳福田会展中心,GTC 2023 全球流量大会如火如荼地展开。这场盛会汇集了来自全球的技术精英,共同探索互联网行业的前沿动态和未来发展趋势。身为参与者,我有幸深入这场融合科技与商业的交流盛会,特别是“聚焦开源,扩展出海新领航”这一议题,让我收获颇丰,印象深刻。 大会聚焦于全球化的多元话题,包括出海市场的选择、广告推广策略等,与我此前参加的专注于日本市场出海活动的公司非常相似。然而,这次大会让我首次深入接触开源社区,不仅结识了众多开源界的领袖和布道者,也与许多杰出的开发者交流了心得。通过这些交流,我不仅学习到了许多新知识,还在思想上得到了升华。 在这篇博客中,我将对这次独特的经历进行深入的反思和总结,分享我在开源和全球化交汇中的洞见和学习。 对于 OpenIM 来说,我们现阶段正在全力准备奔向海外市场,希望打开国界,将 OpenIM 好用而且免费的开源核心功能贡献给全世界开发者。 开源项目天生就是分布式协作的,这是一种松散的结构。以 OpenIM 的开发者为例,我们现在有很多贡献者,开发者,虽然社区有双周会,但是还是很难和人或者同事有深层次的交流。 但对于开源商业公司而言,并不能简单的使用这种远程工作模式。在商业公司中,协作会更加的密切,而且对时效性的要求更高,当面沟通更能保证信息传递的完整性,这是远程工作难以替代的。当然,远程工作也有自己的优势,那就是吸引全球的人才。 所以,开源商业公司采用远程协作并没有问题,但一定要保证沟通的足够充分,拉平信息: 要视频沟通,文字只作为最终的记录。视频是沟通过程中信息丢失比较少的方式,是远程工作交流的首选方式。千万不要用文字来讨论非技术问题,这会带来巨大的信息差和误解。 保证沟通的尊重和善意。在开源项目中,大家因为没有雇佣关系,都是无偿做贡献,所以在异步沟通时特别强调尊重和善意;而在商业公司的远程办公时,因为缺少同事之间的沟通、吐槽和心理按摩,就更要注意沟通的尊重。 定期线下见面,增加相互之间的了解和信任。 另外一点,长期的远程协作,对于参与的工程师来说,除了需要很高的自律和自我管理的要求外,也要注意工作和生活的隔离,保持正常的社交活动和运动健身,否则很容易与社会脱节。 之前和 Apache APISIX 的某个小姐姐聊天,她说的一句话感触很深。也有很多适应不了远程工作的同事一一离去,这也是一个适者生存的达尔文法则。 关于 OpenIM 的远程工作,以及企业的文化,强烈推荐阅读下面的博客: Englist Version 中文版本 出海挑战:中国互联网企业的全球化之旅 中国互联网企业在全球化道路上的探索充满挑战与机遇。从初涉海外市场的尝试到在竞争激烈的国际环境中求生存,它们不断在新的市场环境中寻找增长点。这一过程中,企业需要超越传统的商业模式,适应多元文化和不同的市场需求。 首先,来到了第一个话题,为什么要去做海外社区? 和很多的开源社区的布道者和专家沟通交流,然后反思,我深信建立一个活跃的海外社区是开源项目成功的关键。在全球化的今天,开源不仅是关于代码的分享,更是一种文化和思想的交流。通过建立海外社区,我们不仅能将技术带到世界的每个角落,还能促进不同文化背景下的思想碰撞和创新。 人性化地讲,建立海外社区意味着建立更广泛的连接和共鸣。每一位开源贡献者,不论身处何地,都希望他们的声音被听见,他们的贡献被认可。海外社区提供了一个平台,让来自世界各地的开发者能够参与到项目中来,分享他们独特的视角和经验。这种多元化的参与不仅丰富了项目本身,还激发了更多创新的火花。 同时,海外社区的建立也是对开源精神的一种致敬。开源精神强调的是开放、协作和共享,而这些价值观在全球范围内都是通用的。当我们向海外扩展时,我们不仅在分享代码,更在传播这种包容和合作的精神。 此外,对于开源项目而言,海外社区的建立还意味着更广阔的市场和使用场景。不同的地区和文化背景下,用户对技术的需求和应用方式可能截然不同。这些多样性的输入是项目发展不可或缺的,它们有助于项目更全面地成长,更好地服务于全球用户。 我从大一开始接触 Github ,这个成功打开我通往未来的钥匙。 从2020年左右我开始接触开源,觉得开源比业务代码更有意义。因为开源不仅有技术积累,而且能把你学到的东西分享给其他人,一起成长,所以开源对程序员来说是一个双赢的事。 最开始的时候,我通过学习做笔记,分享笔记到 GitHub ,到后面做项目,参与到一些顶级的开源项目中来,然后慢慢的追求精益。整个过程,我很清晰的看到自己的成长。 甚至我的代码,就像 Git 或者 区块链的默克尔树结构,一步步的串起来记录,每当一个时间段,看到以前的 PR ,满满的都是回忆和尴尬 … 同样,我也是一个云原生的爱好者。 在如今这个时代,开源已经成为了一个不可逆的潮流,尤其是在云原生的领域。以微软为例,他们在 Github 上的开源项目贡献位居全球前列,这充分体现了他们对开源的全面拥抱。在云原生时代,如果你不拥抱开源,不利用开源组件去构建和优化你的核心系统,很可能会在激烈的市场竞争中落后。云原生技术的迅猛发展要求企业和开发者必须快速适应新技术和方法论,而开源社区正是这种创新和合作的孵化器。在这个时代,开源不仅仅是技术选择,更是一种必要的战略思维。 开源社区国际化选择:第一站,启航 美国:开源发展的领头羊 美国仍然是全球最大的开发者社区,拥有超过2000万的开发者,过去一年增长了21%。美国的开源社区历史悠久且成熟,是全球开源活动的重要推动者。 亚太地区:快速增长的新星 亚太地区,尤其是印度、日本和新加坡,正经历着显著的开源社区增长。印度的开发者社区增长尤为显著,预计到2027年将超过美国,成为全球最大的开源社区。 非洲:充满潜力的新兴市场 非洲各地区,尤其是尼日利亚、加纳和肯尼亚,也在迅速发展成为技术公司的新兴枢纽。这些地区的开发者数量每年都在显著增长。 南美洲:稳健增长的活跃区域 南美洲的开发者社区,特别是在阿根廷和巴西,也在持续增长,与亚太和非洲的增长速度相仿。 欧洲:稳定增长的成熟市场 欧洲的开源社区虽然增长速度较美国慢,但在西班牙、德国和英国等国家仍保持稳定增长。...

December 7, 2023 · 3 分钟 · 477 字 · Xinwei Xiong

OpenIM 使用 Harbor 构建企业镜像仓库

需求 OpenIM 提供了多种公共的镜像注册地址,比如说 aliyun, github, Docker hub ~ 阅读 https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/images.md 获取更多的镜像构建指南。 大部分企业都会选择自己做镜像仓库,使用 Harbor 来搭建企业级的镜像仓库,将它集成 CICD Pipeline 流程中,最终替换 Docker Hub,进一步降低镜像存储的成本。 此外,在生产环境下,Harbor 一般都会开启 TLS,所以你还需要准备一个可用的域名。 中国的服务器使用域名,需要对域名进行备案 安装 Helm Helm,以及 集群的部署参考 https://github.com/openimsdk/open-im-server/tree/main/deployments 安装 Cert-manager 接下来我们安装 Cert-manager,它会为我们自动签发免费的 Let’s Encrypt HTTPS 证书,并在过期前自动续期。 首先,运行 helm repo add 命令添加官方 Helm 仓库。 $ helm repo add jetstack https://charts.jetstack.io 然后,运行 helm repo update 更新本地缓存。 $ helm repo update 接下来,运行 helm install 来安装 Cert-manager。 $ helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version v1....

October 25, 2023 · 2 分钟 · 350 字 · 熊鑫伟, Me

OpenIM 的集群化设计 | Kubernetes 部署 | 方案讨论 | 总结

会议和参考链接 会议参考文档:https://nsddd.notion.site/2899028707604b8090b36677c031cdf8?pvs=4 视频回放:Bilibili: https://www.bilibili.com/video/BV1s8411q7Um/?spm_id_from=333.999.0.0 评论: 那个中间件我觉得可以换成 https://kubeblocks.io 可以帮你管理多个数据库中间件 im 读取配置信息,读取的是 config/ 目录,代码中硬编码补充的 config.yaml,是否可以自动化来对 不同 服务的 rpc 划分,然后统一目录,默认读取的是二进制运行路径的上两层 openim version: https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/version.md 存储可以考虑使用 : https://github.com/openebs/openebs https://github.com/rook/rook 核心目标: 开源项目和非开源项目的最大的区别,就是一套完整的解决方案。 非开源项目的 集群化部署方案的设计,比较在乎稳定,以及高效,快速,最好一键部署。 开源项目的 集群化部署方案的设计,比较在乎通用性,上手的难度,后期的维护难度,基础架构的稳定性。后面的开发者或者是贡献者,使用者,可以基于此创建自己的集群化部署方案,以及解决方案,并且成为 OpenIM 的集群化部署方案的使用案例。 OpenIM 集群化部署讨论会记录 先总结,后详细解读 ~ 关于开源部署环境的演变与变化 新部署方法:一种集二进制和部署于一体的一键操作。 Kubernetes 部署:在 Kubernetes 环境中实现一键部署的新型方案。 现存问题:涉及日志收集、服务重启追踪等,将在后续对这些问题进行改进并寻求解决方案。 CICD的开发与维护策略 CICD 概念:通过CICD实现Code Streaming。 开发阶段:需要编写出镜像文件。GitHub的CSD功能:已实现但尚待深入研究。 版本标记策略:推荐使用local branch而非直接标签。 关于软件开发与测试的实践经验分享 本地开发:推荐使用“auto-compile”工具快速生成稳定版本的镜像。 团队协作:介绍了各团队间如何协同进行开发、测试和发布。 代码重用:提及将库中的函数或方法封装为组件,实现跨项目调用。 Docker Deployment与Service Configuration 配置传递:主要通过如K8S中的配置文件。 部署方式:介绍了二进制部署和可部署两种策略,并讨论了各自的优缺点。 关于容器化部署和代码优化的探讨 容器化:提议将多个进程合并为一个容器进行管理。 部署方式兼容性:讨论了如何实现并进行微调。 技术架构和组件:如Helm chat、OpenM等,及其在系统中的作用和重要性。 关于一键部署的技术问题与解决方案 一键部署问题:可能的问题有无法翻墙、无法安装等。 解决方案:1) 将现有方案通用化;2) 采用第三方服务实现一键部署。 K8S部署与自动化的优化策略 部署工具:如使用Shell实现一键部署、K ks部署等。 组件整合:考虑如何将不同组件组合成完整解决方案,并保持不同环境中的一致性。 微服务架构中的最佳实践 应用程序部署:建议将应用程序划分为不同的容器,每个容器内运行一个业务进程。 代码整合:提议将相关代码整合为一个文件进行管理。 微服务的优化与部署策略 微服务划分:强调避免过于细致的模块分割。 自动化:部署时不增加额外维护工作量,采用自动化策略。 关于存储方式和编排工具的选择 文件存储:如使用NFS作为本地分布式文件存储。 编排工具:推荐使用 rook 进行对象存储编排,数据库使用专用编排器。 NFS与Flexible File System的应用 苹果手机上的MFS:讨论了其使用情况和如何同步全局配置文件到各业务模块。 PV/PVC管理数据:示例讲解如何使用此文件系统进行数据管理。 二进制代码与配置文件的应用 代码适配:通过配置文件进行,涉及传递配置路径、文件映射等细节。 关于软件开发中的优化与改进 项目脚本编写:讨论了性能瓶颈、部署统一处理、服务发现模块的优化建议。 关于Web应用配置文件的编写与优化 IP分配:配置文件用于IP分配和模块间分段处理。 接口应用:如在不同环境使用不同的接口实现心跳等功能。 技术架构改进:优化轻量化、提高开发效率和维护效果等。 结论:本次讨论会涉及了开源部署环境的多个方面,从软件开发、部署、测试到微服务架构和存储方式等多个领域。希望通过此次讨论,可以为OpenIM的集群化部署提供有力的参考和指导。...

September 17, 2023 · 2 分钟 · 342 字 · 熊鑫伟, Me

在开源社区中学会如何提问

author(Github) 在提问之前 在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前,请先做到以下事情: 尝试在你准备提问的论坛的旧文章中搜索答案。 尝试上网搜索以找到答案。 尝试阅读手册以找到答案。 尝试阅读常见问题文件(FAQ)以找到答案。 尝试自己检查或试验以找到答案。 向你身边的强者朋友打听以找到答案。 如果你是程序开发者,请尝试阅读源代码以找到答案。 当你提出问题的时候,请先表明你已经做了上述的努力;这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好,因为我们更乐于回答那些表现出能从答案中学习的人的问题。 运用某些策略,比如先用 Google 搜索你所遇到的各种错误信息(搜索 Google 论坛和网页),这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果,在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事,即使它只是表明了搜索引擎不能提供哪些帮助。这么做(加上搜索过的字串)也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。 别着急,不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前,再阅读一下常见问题文件(FAQ)、放轻松、坐得舒服一些,再花点时间思考一下这个问题。相信我们,他们能从你的提问看出你做了多少阅读与思考,如果你是有备而来,将更有可能得到解答。不要将所有问题一股脑拋出,只因你的第一次搜索没有找到答案(或者找到太多答案)。 准备好你的问题,再将问题仔细的思考过一遍,因为草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力,你越有可能得到实质性的帮助。 小心别问错了问题。如果你的问题基于错误的假设,某个普通黑客(J. Random Hacker)多半会一边在心里想着蠢问题…,一边用无意义的字面解释来答复你,希望着你会从问题的回答(而非你想得到的答案)中汲取教训。 绝不要自以为够格得到答案,你没有;你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案,靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题,而不仅仅是被动的从他人处索取知识。 另一方面,表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示?、我的这个例子里缺了什么?以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向,你就有完成它的能力和决心。 当你提问时 慎选提问的论坛 小心选择你要提问的场合。如果你做了下述的事情,你很可能被忽略掉或者被看作失败者: 在与主题不合的论坛上贴出你的问题。 在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。 在太多的不同新闻群组上重复转贴同样的问题(cross-post)。 向既非熟人也没有义务解决你问题的人发送私人电邮。 黑客会剔除掉那些搞错场合的问题,以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。 因此,第一步是找到对的论坛。再说一次,Google 和其它搜索引擎还是你的朋友,用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题(FAQ)、邮件列表及相关说明文件的链接。如果你的努力(包括阅读 FAQ)都没有结果,网站上也许还有报告 Bug(Bug-reporting)的流程或链接,如果是这样,链过去看看。 向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说,别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定,那就向别处发送,或者压根别发。 在选择论坛、新闻群组或邮件列表时,别太相信它的名字,先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题,这样可以让你感受一下那里的文化。事实上,事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意,也许这样就找到答案了。即使没有,也能帮助你归纳出更好的问题。 别像机关枪似的一次“扫射”所有的帮助渠道,这就像大喊大叫一样会使人不快。要一个一个地来。 搞清楚你的主题!最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错,最好在搞清楚这之间差异之前什么也别问。 一般来说,在仔细挑选的公共论坛中提问,会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点,一是看潜在的回复者有多少,二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。 可以理解的是,老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样,你的加入也有可能使情况走向极端 —— 已经好几次了,一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。 Stack Overflow 搜索,然后在 Stack Exchange 问。...

September 17, 2023 · 4 分钟 · 826 字 · 熊鑫伟, Me

一份完整的开源贡献指南(第一次踏入开源)

任务分配 time:Within a week 完成 first contribute,目的:了解开源项目的贡献流程 完成 sealos 开发环境构建 了解 kuberentes 基本使用,核心概念,核心组件的作用 基本使用: 创建 一个 pod 并理解什么是 pod 创建一个 deployment 理解 deployment 与 pod 的关系 创建一个 configmap, 理解挂载配置文件给 pod 创建一个 service,通过 service 在集群内访问 pod 核心概念,核心组件的作用: kubectl apiserver controller-manager scheduler kubelet kube-proxy etcd 这些组件分别是做什么的 可以用一个 kubectl apply 一个 deployment 这些组件分别做了哪些事来梳理整个流程 🚸 next time:会分配一个具体的任务以及介绍 sealos 源码架构。 资源🗓️ 参考资料:...

September 16, 2023 · 6 分钟 · 1104 字 · 熊鑫伟, Me

开源社区的规范设计思路

社区不规范怎么办 作为 OpenIM 社区首席运营官,对整个社区的 communtiy 以及 GitHub 配置仓库 进行了全面的配置。并且对整个 OpenIM 的 Makefile 和 CICD 流,以及整个 OpenIM 使用的日志包 、错误码、协同流、贡献者文档以及 社区文档 进行架构和设计。 在这个时候总会有一些问题,即使你觉得自己的 贡献者文档 写的很牛逼了,很全面了,但是依旧很少有人愿意花心思去按照你写的规范去学习。这对我打造顶级的开源社区是一个非常大的阻碍,于是就有了今天的这个文档,我会将它记录在 GitHub Gists 上,提供拉取和使用的说明、链接,并且定期的维护它。 首先,我提供克隆的链接: git clone https://gist.github.com/cubxxw/126b72104ac0b0ca484c9db09c3e5694 如何设计 首先是针对基础的功能,那就是我们熟知的 commit 信息和 push 信息。 我们可以对 commit 信息的格式进行设置 我们可以对 push 的大小进行设置 我们提供了 actions 的功能 我们提供了 Makefile 标记和清除 Hook 的能力 我之前在学习 git 的时候写了一篇很全的笔记,并且分享在 GitHub 上面,在这个 🤖 链接 上可以学习到 git 很多高级用法。 这篇文章讲解了 git 有哪些规范,寻找合适的 CICD 流: 统一格式: 统一格式:git commit -m 'type(scope): 描述(#issue)' 我们在提交的时候带上邮箱信息 -s 来签证,这是一个很好的习惯。...

September 16, 2023 · 7 分钟 · 1334 字 · 熊鑫伟, Me

DevOps OpenIM 的标准设计

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论,旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps(Development和Operations的混成词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps? 我想用一句话来概括,DevOps 能解决 OpenIM 当前的团队管理,能高效组织团队,并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的? 找到了之前的一个很古老的版本,链接是:https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失,因为信息不全导致代码无法跟踪问题,导致文档缺失,代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式,再到后面的 devops 为什么说及时到现在,我依旧没有将 OpenIM 转变为 devops,一个很明显的判断标准,每一次运维和交互工作依旧需要我手动去做,无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高,效率变低,更重要的是团队没有了更清晰的定位。 那么我后面的计划如何? 不管是 prow, actions, 等等 CI 工具,以及各种 ops(gitops, aiops, chatops,) 也不管是各种设计的 自动化 以及 自动化管理工具,自动化交互工具。 无疑他们是一套体系: 提供无感知的开发环境,无论交付是否频繁,每一个 feature 的 PR 都能快速的,规范并且经过大量自动化测试,更加快速上线,也能更快地响应客户需求。每一次发布的变更变少,所以风险,以及合并的冲突,工作量就变少。而且代码 code review 更方便,代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支,保证代码的最新以及基本可靠,release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化,和自动化运维。非常鼓励自动化,甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 OpenIM 的团队约束制定:https://traveling-thistle-a0c.notion.site/OpenIM-standardization-ebd0c1529ab54e4fb92840e67a73aac1?pvs=4...

September 2, 2023 · 3 分钟 · 458 字 · 熊鑫伟, Me

OpenIM 多进程管理

111: OpenIM 多进程管理策略 主要模块 这篇文章将会从 OpenIM 最基本的单进程前台运行开始,到 nohup 后台运行,到 system 系统进程,然后再到 Supervisord,容器化管理,kubernetes 健康检测。 目前问题 阅读:https://github.com/cubxxw/Open-IM-Server/blob/refactor/feat-enhance/scripts/install/openim-crontask.sh 源码 目前 OpenIM 之前的进程管理策略是通过 nohup 在后台启动的。 整个项目由多个进程共同运行,现在需要一个可靠的保活机制,以便能够在进程崩溃的时候能够快速把它拉起来。openim 的解决方案无非就是写个保活脚本,在后台一直运行,如果发现某进程被关闭了,那么由脚本拉起来,或者是通过 docker compose 健康检测机制: healthcheck: test: ["CMD-SHELL", "./scripts/check-all.sh"] interval: 30s timeout: 10s retries: 5 但是脚本它自己挂掉怎么办?(总不能使用脚本继续保活保活脚本套娃吧)。此外,另一个办法就是配置出来一个服务,让Linux操作系统帮你守护进程,显然,这种办法完全不需要担心守护进程自己挂掉,毕竟是systemd帮你守护,如果它挂掉了,操作系统应该也没了。 我们适配通用的 Ubuntu 和 CentOS 即可,因为 其他 的操作系统比如说 alpine , Alpine Linux 并不使用 systemd 作为其默认的初始化系统。相反,Alpine Linux 使用 OpenRC 作为其默认的初始化系统。这也是许多人选择 Alpine Linux 的原因,因为它是轻量级的,并且没有引入 systemd。 现在新版的 Ubuntu 和 CentOS 都支持的,旧版的linux使用service httpd start启动服务,新版的linux使用systemctl start httpd来启动服务,此外使用initd作为初始化系统的操作系统添加服务是在/etc/init.d/中添加脚本,而使用systemd作为初始化系统的操作系统只需要在/etc/systemd/system/文件夹中添加配置文件就好了。 前台进程 前台进程:是在终端中运行的命令,那么该终端就为进程的控制终端,一旦这个终端关闭,这个进程也随之消失,这时就把Shell给占据了,我们无法进行其他操作。对于那些没有交互的进程,我们希望将其在后台启动,可以在启动参数的时候加一个’&’实现这个目的。...

August 16, 2023 · 7 分钟 · 1480 字 · 熊鑫伟, Me

Openkf 多架构镜像的构建策略设计

自动化构建openkf的多架构镜像并推送到多个镜像仓库 https://github.com/openimsdk/openkf 描述: 为了满足各种用户的需求,我们的目标是自动化构建用于各种架构的openkf Docker镜像,并无缝地将它们推送到多个镜像仓库。 目标: 自动构建openkf的linux/amd64和linux/arm64架构的Docker镜像。 将镜像推送到Docker Hub、阿里云Docker Hub和GitHub容器仓库。 任务: 设置多架构构建系统 使用GitHub Actions,配合QEMU和Docker Buildx,支持linux/amd64和linux/arm64的多架构构建。 在每次新版本发布、提交到main分支或定期事件时,触发构建过程。 支持多个镜像仓库 Docker Hub:推送到openim/openkf-server。 阿里云Docker Hub:推送到registry.cn-hangzhou.aliyuncs.com/openimsdk/openkf-server。 GitHub容器仓库:推送到ghcr.io/openimsdk/openkf-server。 动态镜像标记 使用Docker Metadata Action,基于事件(如定期触发器、分支提交、拉取请求、语义版本控制和提交SHA)生成动态标签。 确保在拉取请求事件中不推送已构建的镜像。 身份验证和安全性 使用秘密配置Docker Hub、阿里云和GitHub容器仓库的身份验证。 确保每个仓库的推送操作都是安全且无缝的。 通知和日志 通过GitHub Actions,如果有任何构建或推送失败,向开发团队发送通知。 保留每次构建和推送操作的日志以供追踪。 验收标准: openkf镜像应该成功地为linux/amd64和linux/arm64架构构建。 在成功构建后,镜像应该在Docker Hub、阿里云Docker Hub和GitHub容器仓库上可用。 根据定义的事件和属性正确标记镜像。 整个过程中不需要人工干预。 附加说明: 自动化过程在GitHub Actions工作流中定义。确保根据需要查看和更新工作流。 确保在单独的分支或环境中测试此过程,以避免中断。

April 23, 2023 · 1 分钟 · 46 字 · Me