Curve 是网易主导自研的现代化存储系统, 目前支持文件存储(CurveFS)和块存储(CurveBS)。
CurveBS 的核心应用场景主要包括：
CurveFS 的核心应用场景主要包括：
Gateway API 作为新一代的流量管理标准，对原有 Ingress 的扩展不规范、移植性差等问题做出了改进。从兼容K8s生态和优化网关体验出发，Rainbond 支持以插件的形式扩展平台网关能力，目前已经有多家社区提供了 Gateway API 的实现，将其制作成平台插件后，一键部署后即可在平台中使用拓展网关能力。我们可以制作不同的网关实现插件来应对不同的场景和需求，同时可以将自己制作的插件发布到应用商店供大家使用。
本篇文章将以 Envoy Gateway 为例详细介绍如何制作并发布你的 Kubernetes Gateway API 插件。最后发布到开源应用商店的 Gateway API 插件将可以被其他用户使用，同时积极参与贡献也有机会获得由我们提供的小礼品。
流水线插件 是基于 Rainbond 插件体系 扩展实现，通过插件化的方式，可以实现对 Rainbond 构建体系的扩展。该插件由社区合作伙伴 拓维信息 参与开发并贡献，底层是基于 GitLab CI/CD 实现。
流水线构建与 Rainbond 源码构建的区别是：
本文将介绍使用流水线插件部署 RuoYi SpringBoot 项目，并实现提交代码后自动构建、自动部署。
随着云计算的普及，越来越多的企业开始将业务应用迁移到云上。然而，如何构建一套完整的云原生 Serverless 平台，依然是一个需要考虑的问题。
Rainbond 本身具有基于源码构建组件的能力，可以将多种编程语言的代码编译成 Docker 镜像，但是在持续集成的过程中，往往会需要对提交的代码进行静态检查、构建打包以及单元测试。之前由于 Rainbond 并没有 Pipeline 这种可编排的机制，所以用户往往只能通过集成外部的 CI ，如 Jenkins、Gitlab CI 等。这给开发者的使用增加了门槛。
所以为了更有效的帮助开发人员做代码测试，编译缓存，甚至代码质量分析等，结合 Rainbond 的插件体系，拓维信息基于 GitLab CI 能力实现了更加灵活，更加多样化的源码构建的功能。
Loki 是一个由Grafana Labs 开发的开源日志聚合系统，旨在为云原生架构提供高效的日志处理解决方案。
Loki 通过使用类似 Prometheus 的标签索引机制来存储和查询日志数据，这使得它能够快速地进行分布式查询和聚合，而不需要将所有数据都从存储中加载到内存中。Loki还使用了压缩和切割日志数据的方法来减少存储空间的占用，从而更好地适应云原生环境下的高速增长的日志数据量。
Loki的架构 由以下几个主要组件组成：
Promtail: 负责采集应用程序和系统的日志数据，并将其发送到 Loki 的集群中。
Loki: 负责存储日志数据，提供 HTTP API 的日志查询，以及数据过滤和筛选。
Grafana: 负责 UI 展示日志数据。
微服务后端开发的最大痛点之一就是调试困难，非常影响我们的开发效率。
如果我们想与其他微服务进行联动调试，则需要在本地环境中启动对应的微服务模块，这可能需要大量的配置和构建时间，同时也会占用我们本地很多资源，可能还会出现”带不动“的情况。
虽然说我们可以在测试服务器上进行调试，但整个流程也是比较漫长，提交代码 -> 触发CI/CD -> 等待构建成功，可能简单的 BUG 我们提交代码打个日志就能解决问题，当遇到复杂的 BUG 时通过这个方式在服务器上调试就非常难受了，太浪费时间了，提交 -> 等待，反反复复，始终没有本地开发工具直接调试的方便。
下面介绍的工具将远程和本地融为一体，让本地开发更加流畅。
很多小伙伴在学习 mall 电商项目时，都会在部署上折腾许久，虽然目前已经提供了很多种部署方式，比如 在 Linux 上部署 mall 、使用 Docker 或 DockerCompose 部署 mall ，但对于正在学习的我们都显得比较复杂，需要理解并学习这些容器技术。而本文将使用 Rainbond 部署 mall 电商项目，通过 Rainbond 部署 mall 商城项目非常方便、简单，让我们专注于代码，Rainbond 是一个云原生应用管理平台，使用简单，不需要懂容器、Kubernetes和底层复杂技术，轻松的在 Kubernetes 上部署应用并体验 Kubernetes 带来的能力。
本文介绍在 Rainbond 上的两种部署 mall 电商项目的方式：
龙蜥云原生套件 OpenAnolis Cloud Native Suite（ACNS）是由龙蜥社区云原生 SIG 推出的基于 Kubernetes 发行版本为基础而集成的套件能力，可以提供一键式部署，开箱即用，以及丰富的云原生基础能力，主要包括：
软件产品只有交付到用户手中才有价值，本人在面向政府等 ToG 场景的软件交付领域具有数年的工作经验，深知其中痛点。今天借助这篇文章，分享这些痛点以及我的解决之道。
在现有的监控告警体系中 Prometheus + AlertManger + Grafana 一直是主流，但对于中小团队或个人来说，这种体系显的较为复杂。而 HertzBeat 能让中小团队或个人很快速的搭建监控告警系统，并通过简单的配置实现应用、数据库、操作系统的监控与告警等。
在开发之前，你需要在本地安装各种开发工具和服务，比如：Mysql、Redis、Nacos 等等，我们都知道在个人电脑上安装这些服务相当的繁琐，可能会遇到很多问题，环境问题、依赖问题等等。
在需要团队协作业务联调的时候，由于同事们的操作系统不统一，有 Mac、Win、Linux，可能还会遇到操作系统依赖、字符集等问题。
在上线之前，你在本地开发调试都完全没问题，部署到服务器就不能用了。经典再现：我本地好好的，咋到你部署就不能用了。
在应用的发布过程中数据库的结构变更一直是最复杂也是风险最大的环节，而 Bytebase 可以对这一过程进行全生命周期的管理。在 Rainbond 中安装 Bytebase，轻松管理部署在 Rainbond 上的所有数据库。
由于数据隐私和网络安全的考虑，大多数toB场景的客户需要私有化应用交付，也就是需要交付到客户的环境里，这样的客户有政府、金融、军工、公安、大型企业、特色行业等，这些私有化场景限制很多，如何提高私有化应用交付的效率是个难题，本文将介绍，私有化应用交付有哪些技术？他 们都各自有什么特点？私有化应用交付的发展历程。
开发人员与运维人员是 IT 领域很重要的两大人群，他们都会参与到各种业务系统的建设过程中去。DevOps 是近年间火爆起来的一种新理念，这种理念被很多人错误的解读为“由开发人员（Dev）学习一大堆新的技能，从而掌握运维人员（Ops）该处理的事情”。然而能力越大，责任越大，当维持生产环境稳定为要位的运维责任落到开发人员的肩头时，多数程序员发出了 扯淡的DevOps，我们开发者根本不想做运维! 的呼喊。那么在云原生时代，到底应该怎样达成 DevOps 的体验呢？我的观点是由平台工程来衔接这两大人群，各自做好各自领域的事情。
Kubernetes 作为基础平台，提供了强大的容器编排能 力。但是在其上部署业务和服务治理上，仍然会面对一些复杂性和局限性。在服务治理上，已经有许多成熟的 ServiceMesh 框架用于扩充其能力，如 Istio、Linkerd、Dapr 等。本文将主要介绍如何使用 Istio 扩充 Kubernetes 灰度发布的能力。
而在部署上，则会利用开源项目 Rainbond 作为基础平台来进行实践。Rainbond 是一个云原生应用管理平台，它使用以应用为中心的设计模式。基于这一设计模式抽象出了标准化的应用模型。从使用的体验上不需要学习和编写YAML，即可实现业务应用的全生命周期管理。因此使用它简化业务的部署和管理。同时 Rainbond 支持 ServiceMesh 框架的替换，使我们可以按需选择与业务最匹配的 ServiceMesh 框架进行服务治理。
要明白什么是云原生，就要先弄明白云计算是什么有什么问题，云计算将计算资源、网络、存储等基础设施统一管理，通过资源规模化和自动化管理，实现 降低资源的成本和提高资源的管理效率，云计算本质上解决的是资源的自动化管理问题，但数字化和信息化的关键在应用，云计算没有解决应用的管理问题，应用的管理和运维是难题，对人依赖度很高，云原生的出现就是为了解决应用的管理问题，应用管理比资源管理复杂很多，涉及到应用开发、应用架构、应用交付和应用运维等应用层的管理，还要配合应用解决资源自动化管理问题，云原生本质就是解决应用的自动化管理问题。
从效果来看，云原生的最终目标是让开发者聚焦自己的业务，业务之外（基础设施、应用架构、应用运维）的事情不用关心，只需要懂业务就能创造出自己想要的应用，并能按需交付客户。
别再担心线上 Java 业务出问题怎么办了，Arthas 帮助你解决以下常见问题：
Arthas（阿尔萨斯）是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。
Arthas 采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，进一步方便进行问题的定位和诊断。
同时 Arthas 也支持通过 Web Console 进入命令行交互模式，这适用于开发人员没有服务器权限时通过 Arthas Web Console 诊断业务。