Blog

会议和参考链接 会议参考文档：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的集群化部署提供有力的参考和指导。...

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

why? 故事是从这个 proposal 开始idea~ 🤖 OpenIM cicd robot machine proposal Prow是基于Kubernetes的CI/CD系统。作业可以由各种类型的事件触发，并将其状态报告给许多不同的服务。除了作业执行，Prow还以策略执行、通过 /foo 风格命令的聊天操作和自动PR合并的形式提供GitHub自动化。 有关 Golang 文档，请参阅 GoDoc。请注意，这些库仅供prow使用，我们不会尝试保留向后兼容性。 Kubernetes 专门为 Prow 提供了网页命令查询： https://prow.k8s.io/command-help 关于Prow如何运行作业的简要概述，请参阅 Prow作业的生命周期。 要查看Prow的常用用法和交互流，请参见拉取请求交互序列图。 hello world 最简单的一个上手案例莫过于 pull request 。 提出一个拉取请求（以下简称PR）。在PR正文中，可以随意添加区域标签（如果合适），例如 /area <AREA> 。标签列表在这里。也可以随意推荐一位评论者 /assign @theirname 。 一旦您的审阅者满意，他们会说 /lgtm ，这将应用 lgtm 标签，如果他们是OWNER，将应用 approved 标签。 approved 标签也将自动应用于所有者打开的PR。如果您和您的审阅者都不是OWNER，请 /assign 某个所有者。如果您的PR有 lgtm 和 approved 标签，没有任何 do-not-merge/* 标签，并且所有测试均通过，则PR将自动合并。 查看测试结果 Kubernetes TestGrid 显示历史测试结果 在 testgrid/config.yaml 配置自己的 testgrid 仪表盘 Gubernator 格式化每次运行的输出 PR Dashboard 查找需要注意的 PR Prow 安排测试并更新问题 Prow 响应 GitHub 事件、定时器和在 GitHub 评论中给出的手动命令。 prow dashboard 显示当前正在测试什么 在 config/jobs 配置 prow 运行新测试 Triage Dashboard 汇总故障 将故障集群在一起 搜索跨作业的测试失败 在特定的测试和/或作业的 regex 中过滤失败 Velodrome 指标跟踪作业和测试健康状况。 Kettle 进行收集，metrics 进行报告，velodrome 是前端。 功能和特性 prow 的功能很强大，甚至是比 actions 更加出众。可以测试、批处理、工件发布的作业执行。...

任务分配 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 源码架构。 资源🗓️ 参考资料：...

社区不规范怎么办 作为 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 来签证，这是一个很好的习惯。...

GoReleaser 的目标是自动化发布软件时的大部分繁琐工作，通过使用合理的默认值并使最常见的用例变得简单。 准备工作： .goreleaser.yaml 文件：包含所有配置信息。（有关更多信息，请参阅 自定义） 干净的工作树：确保代码是最新的，并且已经提交了所有改动。 符合 SemVer 的版本号（例如 10.21.34-prerelease+buildmeta） GoReleaser 的运行步骤： GoReleaser 的运行主要分为以下四个步骤： defaulting：为每个步骤配置合理的默认值 building：构建二进制文件、档案、包、Docker 镜像等 releasing：将版本发布到配置的 SCM、Docker 注册表、blob 存储等 announcing：向配置的频道宣布您的发布 使用 -like 标志可能会跳过某些步骤，如 --skip-foo 快速开始 首先，运行 init 命令来创建示例的 .goreleaser.yaml 文件： goreleaser init 然后，我们运行一个“仅限本地”版本，看看它是否可以使用 release 命令运行： goreleaser release --snapshot --rm-dist 此时，您可以 自定义 生成的 .goreleaser.yaml 文件，或保持原样，这取决于您。最佳做法是将 .goreleaser.yaml 文件放入版本控制系统中。 您还可以使用 GoReleaser 为给定的 GOOS/GOARCH 构建二进制文件，这对于本地开发非常有用： goreleaser build --single-target 准备 GitHub 的 Token： export GITHUB_TOKEN="YOUR_GH_TOKEN" GoReleaser 将使用您存储库的最新 Git 标签。...

你好，我是熊鑫伟 在光阴的长河中，我如此荣幸地踏入大四的这个重要时刻。不仅仅是一位学生，我热衷于编写那些跳动的代码，于是，我成为了开源的狂热追随者。欢迎您探索我的数字天地——我的GitHub。这里，您将看到我对技术的热爱，我的第三代博客，我期待它能成为我与这个世界对话的终极纽带。 在无数社区中，OpenIM 如同闪耀的北极星，引领我前行，灌溉我的技术之心，让我真实地行动起来。 然而，我的生命并非仅停留在屏幕前。从此，世界不再是书本，而是展开在我脚下的广阔天地。 户外的召唤使我欣喜，无论是我独自的冒险还是与朋友的欢聚，每一个步伐都是对自然的敬意和生命的探索。 我寻找开源的深意，并在阅读中不断地得到启示： 《开源的成功之路》：它让我明白，每一个成功都不是偶然，而是走过的那些布满荆棘的道路的回报。 《大教堂与集市》：开源并不仅仅是代码的分享，它更是心与心的交流，是一种对自由与创新的追求。 《黑客与画家》：这部作品是我至今的最爱，它提醒我，真正的价值不在于你拥有了什么，而在于你创造了什么。 > “你的价值取决于你创造了什么，而不是你拥有什么。" 这句话是我每日的座右铭，激励我持续前行，创造属于自己的美好。 开源，于我，是一个旅程，充满了未知与挑战。但我渴望在这条路上遇到更多的同路人，与您共同分享，共同创造。 我真心邀请您，与我一起，探索这个充满可能的世界。

重新搭建我的博客（静态） 冤大头回来了 … 太难了这次，准备简历的时候，发现我的博客没了，我最亲爱的，陪伴了一年的，备受好评的博客 nsddd.top 牺牲了 呜呜呜呜 别急别急，吸取教训，第一件事是什么，坚决不用动态博客了，从大一的第一代博客使用 workpress， 那时候用的服务器管理工具是 著名顶顶的 宝塔 ， 虽然现在我还在用，哈哈哈，不过以后绝对绝对不会再用了 。第二代博客还记得吗 ，第二代博客就是我刚刚牺牲掉的博客，使用 docker 搭建，存活了两年（大二到大三），服务器中途都换了一次，不过得益于 Docker 优雅的移植性haha，所以我的博客得以存活。 那这次为啥挂了？？？ 挂的时间是 2023 年 9 月 1 日。原因是 Java 出现故障，发现 swtich 空间不足，然后，准备移植的，修复的，实在是觉得无力维护，我希望我的博客可以长久生存几年，十几年，甚至是几十年上百年。 所以，从头开始 !!! 选择合适的博客模板 之前用过 vuepress 做笔记，vuepress 相对来说不是特别合适我现在做的，因为已经有视觉疲惫了哈哈哈，看着很不舒服，所以用我很喜欢的一个开源项目，大家很多人也耳熟能详的顶级开源项目：hugo , GitHub 地址是：https://github.com/gohugoio/hugo 接下来就是选择合适的主题了，我参考了几个热门的 theme 选择了 https://github.com/adityatelange/hugo-PaperMod 安装 Hugo 我热衷于源码，可以随时改代码，提 PR ，于是用源码构建： ❯ git clone https://github.com/cubxxw/hugo.git ❯ cd hugo ❯ go build ❯ mv hugo /usr/bin 部署主题 选择我们使用的主题： ❯ git clone https://github....

准备 这篇文章等的太久了，大致 四个月了把，也是自己经历 docker 跨越到 Kubernetes 以及 CloudNative 生态的过程。 反过来再去理解开源、理解 sealos、 理解 Kubernetes，有种豁然开朗的视角。 这篇文章和其他文章不一样的是，这篇是按照自己现在的思路来写的，具体为什么，在以前的文章中能找到答案~ 从 CMD 角度上对接源码，从最开始出发： 不管是 sealer 还是 sealctl，都离不开 镜像的构建核心》 buildah： package main import ( "github.com/containers/buildah" "github.com/labring/sealos/cmd/sealctl/cmd" ) func main() { if buildah.InitReexec() { return } cmd.Execute() } 从 InitReexec 调用 buildah 初始化开始，进行走进 sealos 的大门：Execute 在 cobra 中，Execute 只会执行一次，不管是正确的还是失败的~ 在调用的时候，会先执行 init 初始化函数，它 定义了一些初始化工作以及标志： func init() { cobra.OnInitialize(func() { logger.CfgConsoleLogger(debug, showPath) }) rootCmd.PersistentFlags().BoolVar(&debug, "debug", false, "enable debug logger") rootCmd.PersistentFlags().BoolVar(&showPath, "show-path", false, "enable show code path") } 哈哈，sealos 对于日志包的封装，还是很让我惊喜的，使用了 zap 进行二次开发和封装，用于适合自己的业务需要，这对我是有参考意义的，包括 horizon，未来可能需要在 日志包和 错误码设计上进行改进，这是成就一个优秀的开源项目的必要条件~...

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