微服务 (Microservices)

需求 👀 与其重要的，是对 kubernetes 资源的收集。 ⚠️ 所有资源均是采用外链连接，书本资源或不放连接，其他均为自己感受和总结。如有侵权请联系删除。 CloudNative 学习途径 关于kubernetes： 官网 GitHub 社区维护的 kubernetes 学习资源合集 Kubernetes源码必读的 Google 大规模集群管理器 Borg etcd：从应用场景到实现原理的全方位解读 和 ZooKeeper典型应用场景一览 关于 CNCF 的贡献，你需要签署 CLA Kubernetes CLA 的签署流程 官方开发者向导 markdown 文件 Kubernetes ownes 所有者md介绍 自己写作的一些资源： 云原生学习 golang 学习 都收纳到 awesome 仓库中，覆盖 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 访问 GitHub👀 https://github.com/cubxxw/awesome-cs-cloudnative-blockchain ⏬⏬⏬ GitHub - cubxxw/awesome-cs-cloudnative-blockchain: 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 最好需要什么 如果说第一步的话，那必须要了解 docker 容器底层原理和 Linux 内核基础相关。 先理解理解完架构了，读起来就比较快了。 学会使用它，不会使用，永远无法理解它的设计理念。 读源码还得带着问题去读，不然会很枯燥。一定要带着问题去读，不然就会很枯燥，然后陷入细节中去 读源码还得有一定积累量，比如你已经读过很多基础包的源码比如 net/http grpc-go 等等 要尝试着调试，要尝试着练习，要尝试着理解和分析产品理念，更要学会自己设计。 Kubernetes 工程师的学习顺序推荐 graph LR; 微服务 --> Docker; Docker --> Kubernetes; Kubernetes --> Knative; Knative --> Prometheus; Knative --> Jaeger; Knative --> EFK; Knative --> DevOps; Prometheus --> KVM; Jaeger --> KVM; EFK --> KVM; DevOps --> KVM; KVM --> Istio; Istio --> Kafka; Kafka --> Etcd; Etcd --> Tyk; 推荐的学习资源整理：...

容器运行时 容器运行时(Container Runtime)，运行于Kubernetes (k8s)集群的每个节点中，负责容器的整 个生命周期。其中Docker是目前应用最广的。随着容器云的发展,越来越多的容器运行时涌现。为了 解决这些容器运行时和Kubernetes的集成问题，在Kubernetes 1.5版本中，社区推出了CRI ( Container Runtime Interface,容器运行时接口)以支持更多的容器运行时。 什么是 CRI CRI 是 Kubernetes 定义的一组 gRPC 服务。 kubelet 作为客户端，基于 gRPC 框架，通过 Socket 和容器运行时通信。它包括两类服务: 镜像服务(Image Service)：提供下载、检查和删除镜像的远程程序调用； 运行时服务(Runtime Service)：包含用于管理容器生命周期，以及与容器交互的调用(exec/ attach / port-forward)的远程程序调用。 运行时的层级 容器运行时可以分为高层和低层的运行时： Dockershime，containerd 和 CRI-O 都是遵循 CRI 的容器运行时，我们称之为 高级运行时。 OCI 定义了创建容器的格式和运行时的开源行业标准，包括 镜像规范（Image Specification) 和 容器运行时规范 （runtime specification） 镜像规范定义了 OCI 镜像标准，高层级运行时 将会下载一个 OCI 镜像，并且将它解压为 OCI 运行时文件系统包（file system bundle） 运行时规范描述了如何从 OCI 运行时文件系统包运行容器程序。并且定义它的配置，运行环境和生命周期。如何为新的容器设置命名空间（namespace）和控制组（cgroup) ，以及挂载根文件系统（rootfs）等等操作，都是在这里定义的。它的一个参考实现是 runc，我们称其为 低层级运行时（Low-level Runtime) 高层级运行时(High-level Runtime)：主要包括 Docker,containerd 和 CRI-O 低层级运行时(Low-level Runtime)：包含了 runc, kata,以及 gVisor。 低层运行时 kata 和 gVisor 都还处于小规模落地或者实验阶段，其生态成熟度和使用案例都比较欠缺，所以除非有特殊的需求，否则 runc 几乎是必然的选择。因此在对容器运行时的选择上，主要是聚焦于上层运行时的选择。...

介绍 当前模块的执行中，直接传递了众多端口（ws、api、rpc、Prometheus）。 这种方法可能很麻烦，并且不符合 Kubernetes 的最佳实践，即 pod 通常只公开一个端口（80 或 443）。 该提案建议过渡到以配置文件为中心的方法，同时仍然保留在需要时直接传递端口的功能。 目标 简化Kubernetes部署的端口配置。 作为参数传递的端口值优先于配置文件值。 为希望使用传统的基于端口或基于环境变量的部署的用户提供灵活性。 建议的解决方案 1.配置文件 不会直接传递多个端口，而是引入一个配置文件。 默认情况下，该文件将包含预定义的端口。 可以使用 Kubernetes 的“ConfigMap”将该配置文件传递给模块。 配置文件示例： ws_端口：3000 api_端口：3001 rpc_端口：3002 普罗米修斯端口：9090 2. 直接传递端口 虽然 Kubernetes 部署建议使用配置文件方式，但用户仍然可以直接传递端口。 如果端口作为参数传递，这些值将覆盖配置文件中的值。 3.基于环境变量的部署 对于喜欢使用环境变量进行源代码部署的用户，该模块可以设计为读取 Linux 系统上设置为环境变量的端口值。 如果设置了这些环境变量，它们将覆盖配置文件值，但优先级低于直接作为参数传递的端口值。 示例：如果WS_PORT环境变量设置为3005，它将覆盖配置文件中的ws_port值，除非ws_port作为参数传递。 实施步骤 更新模块以读取配置文件：修改模块以从提供的配置文件中读取端口值。 基于参数的覆盖：实现逻辑以覆盖配置文件端口值（如果它们作为参数提供）。 基于环境变量的覆盖：实现逻辑来检查环境变量并使用这些值（如果设置）。 确保直接参数值具有最高优先级。 文档：更新文档以提供有关设置端口值的三种方法的清晰说明：配置文件、直接参数和环境变量。 测试：在不同场景下彻底测试模块： 仅使用配置文件。 将端口作为参数传递。 设置环境变量。 结论 采用配置文件方法可以简化部署过程，尤其是在 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的集群化部署提供有力的参考和指导。...

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