背景​

大家好，我是北京数立通科技有限公司的李栋。最近几年，我一直负责“智慧巨鹿”这一智慧城市项目的运行与维护工作。这个项目涉及到10多家供应商开发的 30 多套智慧城市应用的运维管理，使用传统方式进行部署与管理肯定会造成混乱。我们在项目开始之初，就试图借助云原生相关的技术来提高部署与管理效率。

初识 Rainbond​

选型的目光，在一开始就落在了基于容器化技术实现的 Kubernetes 和 Docker Swarm 这两个编排工具上。那时候国内应用云原生技术的场景还很少，项目组内的运维工程师们也并不是很擅长容器化等相应技术。为了进一步了解这些编排工具，我发动了工程师们分别去进行调研，当我拿到调研结果时，尴尬的发现光是这些编排工具的安装方式，每个工程师带回来的方案都不一样。云原生的入门门槛之高，出乎我的意料。

退而求其次，我决定引入一款方便工程师们上手的应用管理平台，来代替运维工程师完成和 Kubernetes 等编排工具的复杂交互工作。至此， Rainbond 第一次进入我的视野。

上手 Rainbond​

我算是 Rainbond 的老用户了，从 3.X 版本开始就一直在使用它来管理智慧巨鹿项目的所有智慧城市应用。目前，共计有 30 多套智慧城市应用稳定运行于两个 Rainbond 集群中，我们正致力于将智慧城市应用从较老的 3.X 版本 Rainbond 集群迁移至比较新的 5.X 版本 Rainbond 集群中。

回想最初开始使用 Rainbond 时，其易用性给我留下了深刻的印象。我们的工程师不再需要直接面对学习门槛极高的 Kubernetes ，甚至连将智慧城市应用进行容器化的操作流程也不需要关注，Rainbond 自带的源码构建功能直接接手了容器化工作。

经过两年多的运行，Rainbond 的稳定性也令人满意，目前智慧巨鹿项目团队已经完全掌控了这款应用管理平台。

最有价值的场景​

使用 Rainbond 这几年，我认为给它带来了很多价值点：

• 稳定性保证

真正能够让 Rainbond 在智慧巨鹿项目中扎根的，是它体现出的稳定性，产品本身没有严重的BUG，老版本中的一些小毛病团队也都已经克服。作为一款运行在智慧城市数据中心中的应用管理平台，稳定性的重要程度是要高于其他因素的。在这一点上，Rainbond 表现的很好，即使遭遇了宿主机服务器宕机，应用也可以自动故障迁移、快速恢复。出了问题的宿主机，在问题修复之后，也可以自动重新加入集群。

• 便捷的图形化管理界面

作为智慧城市数据中心的应用管理平台，它辅助我们管理了所有智慧城市应用。借助图形化的界面，运维工程师可以很方便的针对这些应用进行操作，包括启停、编排、伸缩等。由于不必编写复杂的 Yaml 配置文件，也没有命令行交互，智慧巨鹿项目团队的工程师们都得以很快上手。

• 突出的易用性

我认为易用性是 Rainbond 最大的特点。它以应用为核心抽象，围绕应用所设计的诸多功能都十分有用。比如自动伸缩、健康检测等都是非常实用的功能。网关策略的配置也非常友好，操作难度基本为零，绑定域名匹配证书都非常方便。

• 合理的可观测性

Rainbond 提供了全面的监控报警系统，无论是计算资源还是上层的应用系统，一旦出现问题都可以很快暴露出来。结合自动化运维能力，问题应用系统可以做到自愈自恢复。而通过观察应用系统访问量和资源消耗情况，可以更合理的进行资源分配工作。

• 补足供应商管理流程

智慧城市应用来自于很多不同的供应商，在以往使用传统模式部署与运维时，每一家供应商的套路都不一样。这种不同不仅仅体现在开发语言、技术架构上，也体现在具有各自不同的部署方式与运维管理方式。这可苦了我们的运维管理人员，接手的每一套智慧城市应用的运维管理方式都不一样。

这样的境况在引入 Rainbond 之后好了很多。运维管理团队依靠 Rainbond 建立起一套专门针对外部供应商的准入机制，利用统一的规范管理所有智慧城市应用，极大提高了管理效率，也使得运维管理团队可以在脱离供应商支持的情况下，将智慧城市应用管理的很好。目前的管理模式，是将供应商准入环境与最终生产环境按照团队的方式隔离开，供应商开发人员，仅需要关注业务代码的开发过程，智慧巨鹿运维管理团队，会根据代码将业务上线到生产环境中去。真正落地了开发与生产隔离的管理方式。

总结​

我在智慧巨鹿项目中引入 Rainbond 这款产品已经两年多了，作为应用管理平台，它切实助力到智慧城市应用的日常运维管理工作。目前正处于一个将老版本 Rainbond 集群迁移到新版本的过渡阶段，相信以后还会继续携手 Rainbond 同行。

咸阳市大数据管理局负责全市信息共享工作的组织领导，协调解决与政府信息共享有关的重大问题，研究拟订并组织实施全市大数据战略、规划和政策措施，引导和推动大数据研究和应用工作，建立全市统一的数据服务中心和信息共享机制。通过“端-边-网-云-智” 的全新技术架构，实现管理高效、服务便民、产业发展、生态和谐的目标效用，达成新一代信息技术与城市现代化深度融合，迭代演进的新模式、新理念。

智慧城市的建设中，对智慧城市应用的管理是个很基础的问题。传统的情况下，服务于民生的各类应用系统，都是由相应的政府部门各自部署管辖，这造成了一些困扰。各个城市部门往往各自为政，彼此之间形成数据孤岛，很难互通互联。无论是数据还是应用，都很难统一管理起来。

在咸阳智慧城市建设工作中重点建设数据交换共享平台和应用管理平台。数据交换共享平台负责打通城市各个部门的数据孤岛，进行数据清理和规约之后，最后达成所有城市部门的 IT 应用之间互联互通的效果。

在建设咸阳市智慧城市期间，我们在智慧城市应用管理领域遭遇了很多棘手的问题。为了解决这些痛点，我们借助 Rainbond 这款产品，建设起了可以提供自动化运维能力的应用管理平台。我从四个部分分享解决难题的整个过程：

痛点：回顾智慧城市应用，在部署实施以及后期运维上的难点痛点。

定位：我们如何定位智慧城市应用管理平台，以及希望通过它解决什么样的问题。

落地：简要阐述智慧城市应用管理平台的选型过程，以及部署落地的过程。

实战：讲一个真实的案例，来说明引入应用管理平台后，快速开发落地一个智慧城市应用的全过程。

传统模式下的痛点​

我将痛点归纳如下：

• 缺乏统一管理：以往各个城市部门的应用系统的部署是杂乱无章的。每家单位都在建设自己的 IT 系统，没有统一的管理可言。

• 遗留系统多：很多城市部门的应用系统使用的时间都很久了，有的系统甚至已经失去了厂家的支持。而有的系统采用的技术已经过时，无法方便的迁移到可以被集中管理的环境中去，也没有办法很好的将它们监控起来，获得其实时的状态。

• 资源分配不合理：每家单位都在进行 IT 系统的建设，这必然导致做了很多重复性的建设工作，资源浪费随之而来。而且在缺乏资源监控的情况下，没有谁能说清楚各自的应用系统到底应该使用多少资源。访问量不论多少，都分配了同样的资源，缺乏合理性。

• 运维困难：每家单位建设 IT 系统的方式方法五花八门。而这些单位自身往往缺乏相应的技术人才来维护这些系统，一旦出了问题，每套业务系统的维护方式都不一样。

• 缺乏可观测性：以往的 IT 系统建设，往往仅仅关注应用程序本身，而忽略了可观测性的建设。无法做到问题快速发现，往往 IT 系统的失灵，是由用户反馈而来的。

对应用管理平台的定位​

应用管理平台负责承载和管理所有智慧城市下属的应用系统，包括新建设起来的数据交换共享平台。后续所有新开发的智慧城市应用会直接基于应用管理平台部署，以往老旧的遗留系统也会随着迭代更新不断迁移到应用管理平台。这么做的目的就是为了能够逐步整合各个城市部门的数据与应用，统一管理。

建设智慧城市的过程中，必然会不断涌现出大批新的城市部门应用系统，如何在建设过程中不重走老路很重要。智慧城市应用管理平台在这个过程中扮演的角色是 GPaaS 平台，数据交换共享平台是 VPaaS 的一部分。二者相结合，可以将海量城市数据在云端实现汇集融通计算，在提高城市智慧体运行速度的同时也大大降低了运行成本。我将应用管理平台和数据交换共享平台的定位总结如下：

• 应用管理平台向下统一纳管所有计算资源。实现计算资源统一分配调度。这些计算资源以多个机房内托管的虚拟机或者物理机的形式提供。应用管理平台应提供资源监控面板，并在底层计算资源出现问题时发送报警信息。

• 应用管理平台向上承载包括数据交换共享平台在内的所有智慧城市应用系统。提供统一风格的管理面板，以及丰富的自动化运维能力，最大程度降低应用运维管理的难度。智慧城市应用可以以极低的代价迁移到应用管理平台上来，能够实时统计应用的访问流量和资源占用情况，实现计算资源面向应用按需分配，自动调整。

• 应用管理平台横向延伸到各个城市部门。数据交换共享平台需要借助应用管理平台的这一能力，与城市部门现有 IT 系统接驳。

• 应用管理平台可以接纳老旧遗留系统。对于无法直接迁移到应用管理平台的各类老旧遗留系统，比如 Windows 应用等，应可以至少做到逻辑层面的接入，能够以统一风格的面板进行简单管理，以及健康检测等监控能力。

落地过程与价值体现​

我们选型并对比了多款 PaaS 平台类产品，最终选择了 Rainbond 。回顾当时的选型过程，以及系统建成到现在的使用体验，我将其优势总结如下：

• 易用性好：Rainbond 是多家选型产品中，易用性做的最好的一款产品。一站式的产品化体验让我们在智慧城市应用的开发部署，乃至后期的运行维护工作中都大大降低了学习成本。数据交换共享平台这个核心应用，仅用不到一周的时间，就完成了向云端的迁移。

• 强大的自动化运维能力：在运维管理方面，其自动化运维能力非常优秀，节省了大量运维成本，使运维效率成倍提升。

• 可观测性：Rainbond 提供了全面的监控报警系统，无论是计算资源还是上层的应用系统，一旦出现问题都可以很快暴露出来。结合自动化运维能力，问题应用系统可以做到自愈自恢复。而通过观察应用系统访问量和资源消耗情况，可以更合理的进行资源分配工作。

• 开源生态：Rainbond 本身是个开源产品，也拥抱开源社区生态。其内部的应用商店系统，提供了大量我们需要的第三方中间件，这些中间件可以一键部署到应用管理平台上去，这节约了大量的时间和精力。否则基于服务器从零搭建这些中间件系统非常耗时耗力。

基于 Rainbond 建设的应用管理平台于 2019 年 11 月落地交付使用。这套应用管理平台底层对接了 3 个不同的集群，分别是开发测试环境、普通生产环境和涉密生产环境。时至今日，其上部署的各类城市应用已经超过了 100 套，组件数量超过 500 个。

最先被迁移到应用管理平台上的数据交换共享平台。向开发测试环境迁移的过程比较轻松，我们投入了两名开发人员、两名运维人员，在好雨科技交付工程师的配合下，基于源代码就将所有的组件部署到了应用管理平台上。所有的学习和迁移工作只持续了一周左右就完成了。接下来要考虑的，是在生产环境中部署这套应用系统。我们在这里借助了 Rainbond 内部组件库提供的能力，将开发测试环境中的数据交换共享平台，发布到了内部组件库中，在生产环境中就可以一键部署了。后续的升级操作也都借由应用模版配套的版本管理功能完成，这极大的节约了部署升级成本。

数据交换共享平台需要借助平台能力，延伸到各个城市部门接驳其已有的 IT 系统。最开始 Rainbond 并不支持这个特殊的需求，最终定制了特制的网关，使数据交换共享平台可以通过网关和城市部门已有的 IT 系统交互。

数据交换共享平台部署形态：

在应用的运维管理方面，最让我们觉得好用的，是 Rainbond 提供的统一网关配置功能。通过非常简单的配置，就可以将平台上部署的应用系统对外暴露服务地址。而且经过了定制，我们使用的 Rainbond 网关支持了国密证书，使得我们在安可方面的要求也得到了满足。

经过长时间的考验，基于 Rainbond 建设的应用管理平台的稳定性得到了肯定。尤其是在 2020 年新冠疫情爆发时，短时间开发部署的外来人口统计系统，也在应用管理平台的支持下，经受住了大并发考验，完成了统计任务。

实战应对疫情考验​

2020 年 2 月，由于复工返岗高峰的到来，大规模的人口流动重新启动，为遏制疫情蔓延扩散，做好外来返工人员的防控和服务工作，咸阳市需要用最短的时候完成咸阳市外来人口登记系统的开发和上线，并在 3 天内完成整个咸阳市 130 万人信息上报和管控服务。

咸阳市外来人口登记业务是一个前后端分离的业务系统。主要包含了前端页面、后台服务、缓存、数据库、短信业务 5 个服务组件。

此时，应用管理平台已经落地了半年，我们已经能够非常熟练的基于 Rainbond 进行开发和部署，所以业务的开发上线并没有遇到阻碍，我们很快就完成了业务的上线。

Rainbond 提供服务组件的伸缩功能，只需要一键，就可以为当前服务组件快速伸缩出多个实例，并且自动提供负载均衡。为了能够让业务流量过大时，可以自动扩展实例数量，我们还设置了基于内存使用率来触发的自动伸缩功能。在运维层面更加自动化。这将大幅度降低单个实例处理业务的压力。

在咸阳市外来人口登记业务的所有组件中，我们为前端页面、后台服务这两个服务组件都伸缩了最多 5 个实例，这两个服务组件也是经常进行实时更新的组件，基于多个实例，Rainbond 提供滚动更新的功能，使业务的升级不会影响到线上的业务运行。

为了更好的监控“咸阳市外来人口登记业务”各个服务组件的压力情况，我们为前端页面、后台服务、数据库分别安装了 Rainbond 自带的服务实时性能分析插件。业务运行期间，这个插件为我们带来很多的有用信息，多次帮助开发人员发现业务系统的不足之处，使开发人员可以在业务雪崩宕机之前修正代码并上线。

对于前端页面、后台服务这样的基于 Http 协议提供服务的组件，插件将提供平均响应时间、吞吐率、在线人数三项实时数据，以及最近 5 分钟耗时 URL 排行、历史数据等持续性数据。

整个填报期间，4 套业务系统平均在线人数保持在 4000 人以上，峰值达到 5000+，经由统一网关负载的总流量超过 20000。

总结和期待​

Rainbond 满足了咸阳市大数据管理局对应用管理平台的预期，运行至今非常稳定。但是，当管理应用系统上百套后后，我们对应用整体监控提出更高要求，需要从更高维度了解所有应用系统运行情况，我了解到他们有更高维度的大屏产品，希望在二期建设过程中，能解决这个问题。

企业简介​

拓维信息是中国领先的软硬一体化产品及解决方案提供商。

1996年成立，2008年上市（002261.SZ），以湖南为总部，在北京、上海、深圳等地设有分支机构，员工4000余名。业务涵盖政企数字化、智能计算、鸿蒙生态，覆盖全国31个省级行政区、海外10+国家，聚焦数字政府、运营商、考试、交通、制造、教育等重点领域和行业，服务超过1500家政企客户，为其提供全栈国产数字化解决方案和一站式全生命周期的综合服务。

拓维信息立志成为一家不断创新的科技企业，从运营商到数字政府、考试、制造、交通、教育等行业和领域，持续深耕IT软件领域。

PAAS 之前​

在使用一款易用的 PAAS 产品之前，我们各个团队的服务部署方式并不统一：

• A 团队申请云服务器，自搭建 jenkins 将应用直接部署到服务器；
• B 团队申请云服务器，使用 kubeadm 搭建 K8s 集群，开发成员编译镜像，运维成员编写应用声明文件进行部署与维护；
• C 团队...

可以看出，当前的应用运维管理方式存在着很多问题：

1. 云资源管理的混乱：费用统计麻烦，资源利用率低；
2. 团队应用管理的混乱：多制品库，多种配套管理软件；无法对应用生命周期的可视化管理，监控问题，日志问题；
3. 运维重心：以资源为运维重心，耗费人力创造力，重心应该转移到应用本身，更关注业务的创新；

PAAS 需求​

为了解决眼前资源以及应用管理乱象，我们需要一个 PAAS 平台。这个 PAAS 平台我们期待它具有的能力：

• 易用：不需要开发人员，运维人员耗费大量的时间精力学习应用管理，云部署等知识，做到应用的快速交付，持续交付；
• 自动化：对应用全生命周期可管理，从源码到可访问的服务，到日志，监控等都可以在平台呈现；
• 可视化：应用全生命周期可管理，从基本的应用部署，滚动更新，停止等，上升到日志，监控，可伸缩等能力，可以在平台可视且轻松管理；

选型 Rainbond​

为了加快 PAAS 平台建设的步伐，我们决定站在巨人的肩膀上，从社区中对 几款 PAAS 产品进行筛选。对比其优劣势，选择更符合我们团队需求的那款——最终 Rainbond 脱颖而出了。

Rainbond 的优势：

• 以应用为中心的设计理念，做到了真正的易用，屏蔽基础设施概念，让开发团队得以专注业务本身；
• 较完整的自动化能力，完整的可视化管理能力，基本符合需求的日志监控功能；
• 直观的微服务拓扑展示，利用服务网格治理实现本地访问，减少服务上 PAAS 的配置改动（这是一个意外惊喜～）；
• 应用商店提供了常用软件，帮助一键部署。

除此之外，Rainbond 还具有让我们额外惊喜的能力：

• 应用跨集群，跨团队的快速复制能力，使多环境高效部署成为可能；

• 完备的集群端组件，网关，日志，甚至制品库（可替换），使得 Rainbond 本身可以完整提供应用管理的能力；

• 自定义初始化容器以及SideCar容器能力，可插拔的方式为组件提供额外能力；

Rainbond 实践​

我们使用 Rainbond 构建组件呈现：

1. 可视化的组件拓扑以及组件依赖，以及由此带来的相互依赖组件之间本地化的访问方式

2. 组件的全生命周期管理，组件所需基础设置资源轻易配置

3. 高效的网关配置中心，不再需要频繁登录云平台控制台配置负载均衡

Rainbond 足够易用到不需要我们去介绍怎么使用它来构建与管理组件。

我们在其他领域的一些使用经验。

单域名多路由服务​

默认组件开通 http 端口时得到这样的访问 url：

• a组件：http://a.apps.example.com

• b组件： http://a.apps.example.com

而下面才是你期待的 url：

• a 组件：http://apps.example.com/a

• b 组件：http://apps.example.com/b

那么你可以使用 Rainbond 网管的 PathRewrite 功能：

自定义插件​

基于 Rainbond 的插件可插拔设计，我们可以自定义插件服务。

文件管理插件​

你可能会有上传文件到组件容器的需求，得益于 Rainbond 自定义开发插件的功能，你可以通过开发插件来为组件实现文件管理插件，你只需要为你的组件安装具有文件管理能力的插件，然后再为组件创建一个目标目录的共享存储，再通过开通组件端口，即可实现组件容器的文件管理。类似下图

创建插件

配置插件环境变量

开通插件

创建共享存储

开通http网关

数据中间件管理插件

部署了如 MySQL，Redis 的数据中间件，苦于没有现成的管理软件，或者当前无法对外开通 tcp 端口，那么你可以基于 dbgate 这款开源软件来开发一款数据中间件的管理插件。

我相信大家已经会举一反三了，不再示例。

最后​

Rainbond 目前已经迭代到了 V5 大版本了，作为一款易用的 PAAS 云原生应用平台，功能也趋于完备，我们也期待 Rainbond 能发展的越来越好。

得益于 Rainbond 的社区支持，我们在使用 Rainbond 时都比较顺利，Rainbond 确实帮助我们团队内顺利的过渡到了云原生的应用管理阶段，降低了耗费在云资源管理上的精力，转而关注应用本身。

而在使用过程中遇到功能 bug 或有更佳实践时，我们也倡导团队积极向社区提交 issue，或排查解决，这是开源的健康循环的一点。

大家好，我是山西数智时代科技有限公司的赵佳鹏，我们公司成立于2018年，专注于智慧旅游、景区信息化建设。公司目前的主要产品有小悠出行管理系统、景区数字化运行管理系统、鼎云校园摆渡车运营管理系统、行车信息管理及流转系统、觅四方商城系统等，是集智慧旅游规划、设计、建设、运营为一体的旅游全产业链服务商。

智慧景区的整体架构​

最早我们的业务是单体服务，单体服务最大的问题就是业务无法解耦，抗并发能力不高。业务升级为微服务架构之后解决了业务之间的解耦，提升了业务的抗并发能力，升级微服务架构之后也增加了很多新功能，比如实时分账、套票的支持，多种渠道的购票融合，支付安全性、抢购、活动等都带来了一定的复杂度，在检票的时候要保证多个渠道的库存、票状态要实时同步等对技术上有一定的要求。 单体服务到微服务也是一次巨大的挑战，服务器成本、人员成本、单体业务解耦、服务划分、运维等方面都存在很多问题。

存在的技术问题：

• 资源利用率，以前服务器都是每台上边部署几个项目，比如有台服务器 CPU、内存、磁盘等资源很多，但另一台服务器资源又很少，资源多的服务器没法完全利用起来，资源少的服务器满了之后就没办法再部署业务，这会导致大量资源无法有效的完全利用。
• 运维方式不统一，以前部署项目的时候多个项目组都是各自部署各自项目，各自部署方式不一样一会用主机方式，一会用镜像方式，每次需要找日志的时候都要查找半天，服务器上边的文件夹也是创建的乱七八糟的，没有统一的部署方式导致出问题后需要巨大的成本。
• 项目环境重复部署，之前服务器上会部署多个项目，每个项目环境都是各自项目组成员负责，导致环境不统一，有的中间件需要部署好几遍，Nginx 也是部署了很多不同的版本，浪费了大量的时间去做了相同的事情，加大了运维成本。
• 部署成本高，之前用 GitLab CI/CD 部署项目时需要写大量的 YAML 配置，同时还要解决 HTTP、HTTPS 访问，证书每次都需要去手动生成，然后再拷贝到服务器上，出现问题再一遍一遍的去改配置，YAML 语法也需要每个项目组的成员去学习，导致项目的成本提高。

云原生平台选型​

采用微服务架构之后，我们决定全面转向容器化、云原生方向，所以我们需要一个对开发者友好、可视化部署、自动构建、易用的一个云原生 PaaS 平台。

在选择 Rainbond 之前也使用过其他开源 PaaS 平台，由于公司没有专业的运维人员，在使用的时候发现对程序员都不是很友好，还是脱离不了 YAML 的编写，学习成本太高，没有很好的扩展功能，后来了解到 Rainbond 后发现对程序员特别友好，不需要写大量的 YAML 文件，通过界面化配置就能部署项目，而且官方文档很完善，部署例子也很多，操作简单，功能也能满足公司的需求。

使用 Rainbond 承载所有业务场景​

在云原生架构之前，多台服务器的单独运维和部署复杂度高、资源利用率低、重复操作率高，对于线上项目的成本很大，线上服务出问题后无法及时的判断问题出在哪个服务上，需要人工先找服务在哪台服务器，然后在通过一系列命令去查看等等。

在转向使用 Rainbond 云原生架构后，由 Rainbond 统一管理服务器、调度资源，而我们只需要管理业务，降低了运维成本。以及相关运维操作都可以通过界面化实现，比如通过拓扑图就可以看到所有服务运行情况，哪个服务出现异常清晰明了，业务相关日志可以通过日志界面轻松查看，并且有历史日志保存等等。

整体上对于我们来说降低了项目的成本，相应的为公司带来的利益就比之前多了很多。

使用 Rainbond 的最佳实践​

• 项目团队管理，公司不同项目会有不同的小组负责，这个功能就可以完美的解决这个问题，可以单独设置权限、集群资源。

• 代码仓库对接和快速部署，公司用的华为云的代码仓库，在 Rainbond 上可以直接填仓库地址，然后通过源码直接构建部署，同时还支持 Maven多模块的批量构建，公司大部分项目都是多模块项目，用了这个功能之后比之前效率高了很多。
• 测试环境一键复制到其他环境，Rainbond 可以将测试环境的应用快速复制到其他环境中，省去了再次部署的问题，在之前不同环境都需要部署一次，用了这个功能后只需要部署一次，然后就可以快速复制到不同环境中。
• 可视化服务编排，项目部署成功以后可以通过可视化的方式进行服务编排，这个功能是我在其他 PaaS 平台没有看到的，之前服务编排需要写大量的 YAML 文件，现在可以直接使用鼠标一拉一拽就可以完成，而且还是根据组件依赖情况按顺序启动。

使用 Rainbond 总结​

从2022年8月份使用 Rainbond 到现在半年多的时间里，明显感觉到在项目的开发效率上提升了很多，之前每次重复的工作现在只需要干一次，运维上也方便了很多，直接界面化配置，比起之前写大量 YAML 文件省去了很多时间成本，在运维上省去的时间现在都用来开发项目，修改BUG了。

架构转变为云原生架构的这段时间里，发现了它的很多优点:

• 快速迭代，在 Rainbond 上进行开发，使开发团队可以使用自动化能力和编排来快速迭代，让开发人员有更多的精力聚焦于业务开发上。
• 自动部署，云原生方法远优于传统的面向虚拟化的业务流程，传统方法需要投入大量的精力来构建开发环境，以及软件交付过程中的其他不同环境。而云原生架构具备自动化和组合功能，并且依赖于可靠、经过验证和审核的已知良好流程的基础，交付十分敏捷，而不再需要人工干预重复执行。
• 独立高效，云原生带来了微服务化架构，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发、甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。
• 屏蔽底层差异，Rainbond 虽然建立在 K8S 之上，但屏蔽了很多 K8S 的知识以及底层硬件的差异化，而我们的开发人员就不需要考虑应用对于底层硬件的差异，也不需要学习更多的容器知识，只需要专注于业务即可。同时对运维人员也非常友好，不需要再为环境问题而苦恼。

在未来我会更深入的了解云原生和不断地尝试 Rainbond 带来的新功能。

给 Rainbond 的建议​

谈谈自己的感受吧，我在测试环境部署 Rainbond 也是部署了很多遍，每次都会遇到不同的问题，不过还好，Rainbond 社区支持比较给力，每次都能及时帮助解决，不过还是建议部署文档再继续完善下。到了生产环境部署Glusterfs 集群存储的时候也发现了问题走不下去，希望社区也能解决下 Glusterfs 的问题或者引入其他存储的解决方案。还有自动签发证书的功能，只支持 ACME 去签发，由于公司使用的是华为云的域名，Rainbond 社区 的 ACME 服务不支持华为云 DNS 导致无法使用这个功能，希望社区能支持范围更广的 ACME 去做 SSL 证书签发。

最后还是很感谢 Rainbond 这个产品以及社区的帮助，用了这个产品之后实实在在从根本上解决了很多问题。希望 Rainbond 在未来能再接再厉做的更好。

以前的痛点​

• 项目环境管理

我们经常会遇到一个团队负责多个项目，每个项目的开发、测试环境均是由各自的项目成员负责，这样会导致环境不一致引发一些问题。

并且在搭建环境时，一些共用的中间件也需要重新搭建，浪费时间做重复性工作。

• 持续部署

我们以前都是用 Jenkins 去做打包构建的流程，但 Jenkins 每个项目都有一套，也是无法统一，并且在每个环境都需要单独的 Pipeline，也是做重复性的工作。

• 统一运维

我们以往在对应用进行一些运维操作时，比如查看日志、监控指标、服务状态等，都通过在服务器上手动执行查看，或者对接一些工具等

• 高门槛

我们其实没有专职的运维人员，对于 Linux、Jenkins、Tomcat，都需要我们开发人员花时间去学，这样会耽误开发效率。

了解 Rainbond​

在了解Rainbond之前，我们尝试使用容器来提高研发效率，起初我们调研了几家PaaS平台，想解决以上问题，发现实现过程都有一定的门槛，需要时间学习，但这不是我们要容器化的目的，我们的目的是为了提升研发效率。

从领导口中的知道了 Rainbond 这个产品，并且开始了 POC 测试，POC测试过程中我发现完全可以解决我们以前的痛点。

1. 团队、环境管理

Rainbond 的团队管理可以很清晰的分清我们的项目，一个项目为一个团队，管理起来很方便也很直观。同时团队下可以分成多个环境，例如开发、测试环境，都可以很直观的看到。

2. 持续部署/持续集成

测试过程中，我们发现 Rainbond 可以直接对接源代码仓库，然后从源代码直接打包、构建、运行，整个过程无需人为干预，省了不少时间。

3. 统一运维

每个应用或者组件都可以通过点点的方式进行操作，比如看日志、伸缩实例、服务状态等。

4. 入门门槛低

Rainbond 平台几乎屏蔽了所有k8s相关的知识，无需手动编写yaml就能将业务部署上来。

使用过程​

1.对接代码仓库​

通过 GitLab OAuth2 对接 Rainbond，在Rainbond上可以直接通过 GitLab 构建应用，直接从源码进行打包，这一点非常方便，对接过程也非常简单，我是参考的 整合 Git 仓库快速部署组件 。

2. 部署微服务​

部署微服务的整个过程也是比较容易，无需手写yaml，通过对接完代码仓库直接从源代码开始打包，同时也能多模块构建，我们大多数项目都是多模块的。

在进入多模块构建页面后，勾选需要打包的模块，然后会根据模块的数量创建出组件的数量并自动进行构建。

3.使用 Service Mesh 编排​

在部署完成后，通过拓扑图连线的方式就可以完成服务之间的编排，屏蔽了相关技术知识，就算小白也能轻松完成微服务编排。

4. 环境复制​

对于以前的我们来说环境的搭建是个头疼的事情，并且有那么多项目都需要开发、测试环境，并且每个项目的组件基本都在20-50个，还需要修改配置啊啥的，简直不要太麻烦了。以前的搭建真是费时费力，重复性工作太多了，严重影响我们研发效率。

在使用Rainbond的过程中，我发现了快速复制这个功能，简直神器，复制的时候还可以修改构建源地址或者镜像Tag，复制后原环境的组件之间的依赖，组件的环境变量、配置文件、存储等都会复制过来（不包含数据）。

通过快速复制功能，我们所有的项目都是搭建了开发环境后，快速复制出测试环境。

5.配置WebHook​

在基于 GitLab 源代码创建组件的时候，有一键开启Webhook的按钮，也可以手动在构建源中开启Webhook。

配置简单，使用简单，当我们提交代码后，自动触发Rainbond进行构建，无需我们人为干预。

遇到的问题​

我们使用 Rainbond 大概也快一年了，随着使用的越来越深，也遇到些使用不是最佳的情况，比如：

1. 配置文件采用环境变量配置

   以前我们 Java 项目配置文件的配置都是写死的，比如 Mysql、Redis连接地址。经过好雨技术人员给出的最佳实践，我们将这些配置都改成了环境变量的方式，在 Rainbond 上，A服务依赖了B之后，B的环境变量会注入到A服务中，所以我们只需要一次配置，到处使用，非常灵活。

2. 共享配置文件

   我们有些服务没有配置中心，经常配置文件有很多份相同的，以前都是各配一份。现在可以配置一个组件，其他组件都共享这个组件的配置文件，一处改动，所有组件都会生效。

效率提升​

使用一段时间后能感受到 Rainbond 确实给我们带来了明显的研发效率提升，之前我们总会在环境部署这块投入一些人力，我们没有专职的运维，投入的都是研发人员，研发人员也需要学习这些，对于时间和成本来讲，比之前节省了很多，可以让我们的研发人员专注于代码。还有易用性也很关键，我们的前端、后端、测试人员都会在 Rainbond 平台上部署业务，之前开发时前端同学对不同模块需连不同的后端的情况几乎消失，节省了沟通成本以及其他不确定性造成的额外浪费。

总结​

目前还是处于持续开发阶段，应用市场这块还没使用上，后面打算开发完成后的交付工作会使用 Rainbond 的应用市场进行交付，或者通过应用市场实现我们业务模块的服用，目前也是还没抽离出来，这块后面会继续尝试。

最后还是比较期待企业版能够更新一些新的特性。

最后​

Rainbond及好雨提供的企业服务也得到了 鹏海研发团队 的认可：

好雨的服务响应比较快，交付团队特别热情。在整个POC测试阶段到最终大规模使用，遇到问题能保障及时响应、快速修复。令我印象最深刻的是当时我们的研发环境出现了问题，好雨交付团队连夜通宵帮助我们修复问题，丝毫没耽误研发进度。

Rainbond从 POC 测试到现在正式大规模投入已经接近一年了，整体情况很好。

关于柯基数据​

南京柯基数据科技有限公司成立于 2015 年，提供一站式全生命周期知识图谱构建和运维、智能应用服务，致力于“链接海量数据，从大数据中挖掘智慧“。帮助企业运用知识图谱技术打造世界领先的认知工作自动化智能引擎。

目前在药企、医疗机构、军工院所、科技情报及出版等领域服务了数十家大客户，积累了丰富的行业知识图谱运用开发经验。典型客户有国防科技大学、中国航空、中国电科等。

柯基数据的云原生之路​

大家好，我是南京柯基数据的解决方案架构师刘占峰，云原生技术在交付运维上的优势让我获益匪浅。作为项目合作伙伴，Rainbond 持续助力柯基多套业务系统的快速开发和交付部署。在使用 Rainbond 之前，由于业务迭代周期短，涉及组件多，平台版本更新耗时耗力，服务运维难度大。很多项目中，客户的运维能力储备不足，基于传统的交付和管理方式，客户对于业务运维根本接管不起来，只要风吹草动，必须要我们派工程师到现场解决。针对交付运维存在的问题，各个业务平台开始着手云原生改造。

最开始我们尝试自己搭建公司内部的开发测试环境，过程中遇到的两个小坑。

第一个坑是：环境搭建完成后使用体验却不佳，所有涉及到磁盘读写的操作都显得异常卡顿，集群中的 Etcd 集群日志中不断报告处于 “read_only” 状态，随之而来的是服务器负载的不断飙升。

我们带着怀疑的心情求助了 Rainbond 开源社区，经过多方面的排查，我们把目光落在了磁盘的 IO 性能上。替换了高性能的磁盘之后，我们重新安装了整个开发测试环境，磁盘性能的提升的确解决了 Etcd 集群时常不工作的问题。

第二个坑是：使用了共享存储的服务却依然处于读写极慢的状态，这着实令在场的所有工程师又开始头大了。确认了硬件性能之后，开始将目光放在操作系统配置参数上面，操作系统内核在不断报告与共享存储有关的错误：

NFS:__nfs4_reclaim_open_state: Lock reclaim failed!指征 nfs client 和 nfs server 之间存在同步差异，差得多了就会开始报警。经过不断摸索，工程师们终于锁定了与 nfs 性能有关的两个系统参数，Linux nfs 客户端对于同时发起的 NFS 请求数量进行了控制，若该参数配置较小会导致 IO 性能较差。

echo "options sunrpc tcp_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.confecho "options sunrpc tcp_max_slot_table_entries=128" >>  /etc/modprobe.d/sunrpc.conf

修改了这两个参数后，共享存储的性能得到了显著的提升，令人摸不到头脑的内核报警信息也随之消失。开发测试环境终于可以顺畅使用了。

接下来面临新的挑战是如何将我们的多套业务系统顺利迁移到 Rainbond 上去，所幸 Rainbond 的使用很简单，整体学习梯度并不陡峭，我们很轻松把业务系统分批的部署在 Rainbond 上去。然而 Rainbond 工程师组织的云原生应用评估却指出了业务系统有多处不符合云原生特征之处，提出了一些整改意见。在整改过程中，我们对云原生也有了更深入理解。

• Elasticsearch 等有状态组件需要将组件部署类型调整成为有状态单实例或有状态多实例，不可以是无状态

  我们最开始并不了解什么是有\无状态组件，所以并没有注意区分组件的部署类型。Rainbond 工程师提示我们，Elasticsearch 在 Rainbond 平台中应该使用有状态的组件部署类型进行部署。

• 支持横向伸缩

  我们的多套业务系统，在接触云原生改造之前，都是传统的单体架构，部署时也基本不考虑高可用特性。这使我们的业务系统相对而言脆弱许多，没有任何容错能力，一旦服务器宕机，整个业务系统就失去了服务能力。云原生改造的过程中，我们借助于 Rainbond 天然的微服务能力，非常轻松的将我们的业务系统拆分成为更为合理的微服务架构。更令我们惊喜的是，这些拆分出来的微服务组件，大多数直接具备了横向伸缩的能力，借助 Rainbond 的一键伸缩能力，迅速扩展成为多实例的集群，极大的提高了系统的可用性。而针对某几个不可以一键伸缩的组件，Rainbond 工程师们也提供了合理的意见，引导我们对这几个特殊的组件进行修改，使之实现了“无状态化”。现在，经过云原生改造的业务具备了“小强”一般顽强的生命力，再也不怕服务器宕机了。

• 所有配置支持环境变量配置，形如 ${GATEWAY_PORT:8083}

  以往我们都将服务的配置项写成固定的值，这样的做法使得我们每到一个新的部署环境，都要重新更改大量的配置文件。Rainbond 工程师指出，云原生应用应该将配置保存到环境当中，以环境变量加默认值的方式声明出来。而大多数需要修改的配置项，如不同组件之间的连接地址信息，就可以通过 Rainbond 依赖关系中的连接信息来相互注入，省去了大量的配置工作。

• 组件主要端口通过环境变量 ${PORT} 定义

  Rainbond 工程师提供了一个小技巧，将组件监听端口的配置，用一个固定的环境变量来配置，这个变量的值会随着我们在 Rainbond 控制台上手动添加的端口号来自动变更，这样，我们就可以在不更改代码和配置的情况下，随意变更想要监听的端口号，这很方便。

• 所有组件需要统一时区

  统一所有组件的时区配置是非常有必要的，Rainbond 工程师提供了一个技巧，让时区的设置变成了一个很简单的事情。只需要运行环境的镜像中包含 tzdata 软件包，我们就可以基于 TZ=Asia/shanghai 这样一个环境变量的配置，完成时区的配置了。

• 所有业务需要定义健康检查策略

  Rainbond 工程师要求我们为所有的服务组件定义健康检查策略，这样可以在服务组件遭遇问题时，快速识别到运行异常状态，在根据事先的配置，完成下线或重启的操作。对于 http 服务，我们定义了一个检测接口，通过探针请求返回的状态码来判断服务的状态；对于一般中间件，则检测其 TCP 端口的监听状态来判断。

• 组件应支持优雅失败与重试机制

  Rainbond 工程师向我们阐述我们的服务组件在被关闭时，应该做出怎样的反应，来最大化的优化最终用户的体验。进程接收 SIGTERM 时，拒绝新请求，完成已接收请求后关闭端口，退出进程。而对于服务组件突然丢失了数据库连接这样的情况，也应该添加合理的重试机制，在多次重试依然无法重新连接到数据库时，理应结束进程，用显式的组件异常状态来提醒运维人员。

• 前端 web 组件调用后端 api 组件地址需要进行 nginx 代理

  对于前后端分离的项目，合理的利用前端的 web 服务器进行接口层的转发是一种很好的体验。Rainbond 工程师在帮助我们完成前端 VUE 项目的源码构建的同时，也教学了如何通过在代码根目录下添加配置文件，来实现接口请求向后端组件的转发。

• 实现一键交付

  使用 Rainbond 的目的之一，是希望能够借助其能力，实现业务系统的快速交付。通过与好雨科技交付团队的合作，我们只需要提供应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键交付整套业务系统。这极大的降低了我们的交付成本。

• 实现一键升级

  为了适应最终用户的需求，我们需要不断迭代自己的产品，并在生产环境中持续升级我们的业务系统。Rainbond 基于应用模板的版本实现了一键升级的能力，这个功能对我们非常有用，我们只需要提供更高版本的应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键升级整套业务系统。

最终效果​

应用完成改造后，通过 Rainbond 可以查看我们产品的拓扑图和依赖关系。

在实际项目当中，我们产品流转了三个环境：

开发环境：我们在公司内部，使用开源版本的 Rainbond 在公司服务器上搭建了开发测试环境，我们开发团队通过源码构建，很快将业务系统搬上了 Rainbond。通过一段时间的测试和迭代，我们拿出了首个版本的应用模板，并使用离线导出功能导出了离线包。

准入测试环境：利用光盘等介质，仅需一个工程师将离线包导入了最终客户提供的私有云准入测试环境，导入后产品一键安装。对于客户反馈的意见，我们在开发环境中导出新的离线包，并再次导入了准入测试环境，进行了一键升级，经过多次迭代最终达到客户的准入要求。

生产环境：最终生产环境是完全由客户管理，我们仅需要提供经过准入的应用模板离线包以及必要的文档，客户就可以非常快速的将我们的产品完成部署和升级。

相对于以前的交付方式和流程，接入 Rainbond 体系给我们带来了这些更好的交付体验：

• 更便捷的交付方式：交付物只是离线包，不需要关心客户复杂的运行环境。
• 更低的交付成本：无论从时间还是人力的角度，交付成本都极大的降低了。
• 应用运维过程自动化：云原生技术切实的提升了业务系统的各项能力，可用性、容错性以及应对流量陡增时动态的伸缩能力。

最终仅用一个星期，我们就完成了各个业务系统的云原生改造工作，并测试通过云原生应用标准规范认证 L2 级。之前项目交付过程中交付难、维护难的问题，是我们最大的隐形成本，客户只会看最终交付效果，并不会为交付过程而买单。

做了云原生改造后，之前需要派驻交付团队 1 个星期才能交付完的项目，现在一个基础的运维工程师刻盘过去安装，1 小时就可以搞定。并且用户可以通过 Rainbond 的可视化界面快速上手掌握，95%的运维问题都可以自行解决，或者远程指导客户操作。

什么是云原生应用标准规范认证？

「云原生应用标准规范认证」为软件厂商的应用交付过程中的便利性、交付客户后的可维护性、以及必要时的可迁移性等需求，提供可信赖的技术背书。现阶段，「云原生应用标准规范认证」分为 L1、L2、L3 级，在应用交付及交付管理发挥重要作用。

• L1 关注：应用跨环境交付后的一键安装和自动化运维。如高可用、可伸缩性、可观测性等，提升最终客户的可维护性，降低客户的学习成本。
• L2 在 L1 基础之上关注：应用跨环境交付后的一键升级。如全量/增量升级、版本回滚等，满足客户小步快跑的持续迭代交付需求。
• L3 在 L2 基础之上点关注：应用跨环境交付后的一键备份迁移。如包含完整数据的打包备份、可迁移性等，帮助客户实现整体生产环境的迁移、灾备

关于某餐饮企业​

自从1987年第一家餐厅开业以来，截至2021年第二季度，某餐饮企业在中国大陆的足迹遍布所有省市自治区，在 1500+ 城镇经营着 10000+ 餐厅，员工人数超过 40 万。旗下有多个知名连锁品牌。

选择 Rainbond​

某餐饮企业技术团队一直在寻求一款可以简化 Kubernetes 操作的图形化工具，可以摆脱 Kubernetes 复杂的使用方式，并将应用运维和资源运维解耦。这样可以让技术团队专注于应用系统本身，极大降低整个部门的成本投入。通过 infoQ 上的文章，某餐饮企业技术团队了解到了 Rainbond 这款产品，文章中对 Rainbond 的介绍非常契合他们的需求。

在对比过 Rancher、青云等产品后，团队最终选择了 Rainbond 作为企业应用管理平台。最终打动团队的，是 Rainbond 非常易用，容易上手。

Rainbond 和 Rancher 各司其职​

在实践过程中，技术团队将 Rainbond 与 Rancher 两款产品充分融合使用，Rancher 和 Rainbond 本身并不冲突，或者说是相辅相成的，这两个工具共同解决了企业应用团队内部不同纬度的运维需求。Rancher 并不是从应用视角出发的，但从底层运维的角度来看，Rancher非常专业，包含很多角度监控报警。如果资源运维团队想去看一些东西，则使用 Rancher 去管理；而从应用视角，则会用 Rainbond 去管理。

IT流程一体化管理 供应商软件持续交付​

某餐饮企业IT团队借助 Rainbond 搭建一体化管理流程，在这个流程中，外部供应商进场后直接被分配指定的工作租户，供应商可以将经过其它 CI/CD 系统生产出的镜像快速部署到当前租户中去。经过将若干业务组件进行简单的拼装，就生产出了一套基于 ServiceMesh 微服务架构实现的完整业务系统。经过测试后，某餐饮企业企业应用团队就可以将业务系统整体发布到中台组件库中，将软件以应用模板的形式保存下来。在最终的生产租户中，只需要一键，即可将外部供应商的业务系统安装运行起来，供应商有新的版本持续发布到中台组件库，生产系统根据需要滚动升级，自动化运维能力加强了IT团队对生产系统的管理能力，尤其是自动伸缩功能在业务高峰期的表现非常亮眼，最终面向企业内部用户提供 SaaS 化的服务。

应用场景1: 更安全的供应商管理​

某餐饮企业IT团队面对着大量的外部供应商。通过 Rainbond 提供的租户隔离能力，外部供应商可以在属于自己的完全隔离租户内完成应用的迁移部署工作。通过中台组件库，某餐饮企业企业技术团队可以把外部供应商部署完成的完整企业应用以应用模板的形式，流转安装到生产集群的生产租户中去。这样做的好处是阻绝了外包厂商操作最终生产环境，提高了企业IT设施的安全性。

应用场景2: 软件资产化管理​

软件资产现在已经成为企业IT资产的重要组成部分，越来越受到管理人员的重视。然而多数软件系统在厂商维保期过期之后的安装、运维都成为了软件资产管理的极大障碍。Rainbond的组件库存放所有应用系统，保存应用系统的所有历史版本，使用时一键安装和升级，让软件的价值在企业内部流动起来 ，使得某餐饮企业IT团队面对软件资产管理工作时游刃有余。

应用场景3: 敏捷的企业资源管理​

某餐饮企业IT团队日常工作中负责为外部供应商提供计算资源。在以往，从对计算资源需求的提出，直到服务器落地，企业应用的部署，往往需要数月时间。引入 Rainbond 作为企业应用管理平台之后，通过将计算资源池化管理，实现外部供应商可以随时进场部署的同时，极大的节约了计算资源的使用，原计划3个月完成上线的物流订单管理中台，借助 Rainbond 在1个月内就完成了迁移上线。

应用场景4: 以SaaS的方式对内提供服务​

为了适应新的采购和管理模式，某餐饮企业IT团队借助 Rainbond 的能力，将所采购的软件服务化，以 SaaS 的形式提供给公司内部使用。这一改动极大的提升了最终用户的使用体验，也降低了企业应用系统的维护成本。

应用场景5: 供应商应用系统验收​

好雨科技交付团队为某餐饮企业企业应用团队提供了一套完整的云原生应用准入规范，这一规范指引了外部供应商如何将自己的应用系统改造成为更符合云原生时代特征的应用，符合规范才能验收，准入规范不仅降低了对供应商的依赖度，同时也让云原生的价值更好落地。

使用总结​

Rainbond正在某餐饮企业IT团队内部扮演越来越重要的角色，目前已经运行着多套企业应用系统。在好雨科技交付团队的辅助下，某餐饮企业IT团队依托 Rainbond 搭建起完整的企业应用交付落地的全流程。

Rainbond及好雨提供的的企业服务也得到了某餐饮企业的认可：

未来计划​

双方将继续合作，在存储兼容性、容器安全等领域持续打磨企业应用管理平台，企业IT团队也将继续推广 Rainbond 在公司内部的使用范围。双方正在规划下一阶段多数据中心多活的落地方案。这一举措将极大的提升某餐饮企业企业应用的稳定性与可用性。

大家好，我是厦门正观易知科技有限公司运维负责人郭传壕。

藏书馆是一个专注用户自我成长的云端私人图书馆，集电子书的读、荐、借、购、存和知识管理功能于一体，致力于用户的认知赋能，通过读书习惯的养成，达成自我成长。目前累计注册用户已达 1500W ，平台图书资源超过 200W 册。

我们使用 Rainbond 已经有 2 年，我把我们的使用经验分享给大家。

以前的困局​

处于云原生时代中的藏书馆的起点很高，我们一开始就选定了微服务架构、Kubernetes、容器化等符合时代潮流的技术体系。然而原生的 kubernetes 管理平台提供的功能并不完全符合我们的预期，二次开发的巨大技术成本也是我们负担不起的。

在了解到 Rainbond 之前，处于创业初期的我们一直受困于产品迭代变更频繁所带来的琐事之中。我所说的琐事包含微服务架构下 50 个服务的版本管理、构建产物的更替、线上环境的发布以及围绕着应用从开发到上线再到运维的种种繁琐工作。

我们希望可以从这些琐事中跳脱出来，专注于业务本身，探索出一条适合 kubernetes 环境下持续开发、持续交付的简捷之路。

鉴于此，我们开始积极的寻找一款开源且易用的应用管理平台。

初识 Rainbond​

在 Rainbond 之前，我们已经尝试过了 Rancher 等产品，但产品功能和我们的预期有很大差距。

2 年前，我们通过 Github 第一次了解到了 Rainbond 这款产品，惊喜于功能非常契合藏书馆的需求。列举几个令人印象深刻的能力：

1. 应用架构的整体拓扑图

   以上帝视角，一览无余的观测到所有服务组件的运行状态与依赖关系。强迫症会逼着我们的工程师消灭红色的异常状态，而体现运行状态的绿色真的令人感到安心。

2. 可视化的资源占用情况

   资源占用情况是体现可观测性很重要的指标。对于初创公司而言，了解资源分配是否合理，杜绝资源浪费是很重要的。Rainbond 从团队到服务组件的每个维度都提供了良好的可观测性。团队级别的资源限额能力非常实用，解决了运维团队无法有效掌控资源分配的难题。

3. 自动伸缩

   藏书馆是一个典型的 2C 场景，如何利用好云计算提供的弹性，灵活的应对流量高峰呢？答案就是使用自动伸缩功能。Rainbond 提供的自动伸缩功能，突出了简单易配置的特点。自动伸缩能力极大的解放了运维团队的工作压力，从此远离兴师动众和严阵以待。关键业务会随着我们的心意，自动扩张，直到能够吞吐所有流量。

4. 集中式的网关策略管理

   2C 场景下的服务发布，是无论如何也绕不过去的坎儿。无论是蓝绿发布、灰度发布抑或是 A/B 测试，这服务发布相关的十八般武艺多少都会碰到。原生的 Kubernetes Ingress 的确可以实现这些发布策略，但是我们更希望得到一个产品化的集中式管理页面来处理这些问题，而不是去麻烦运维工程师们去碰那些格式严苛的 Yaml 文件。Rainbond 网关策略管理完美的实现了我们的需求。

5. 应用复制快速生成环境

   在藏书馆的开发流程中，我们时常需要搭建各种环境，来区分开发、测试、预发布场景，分别对应不同版本的微服务组件，比如 Dev、Prod 之类的。但如果每次生成环境都要手动创建服务组件，那真的太低效了。应用复制功能在这个场景下非常有用，它帮助我快速复制出一套环境出来。复制过程中自助选择构建源的版本，对我而言是镜像的 Tag。复制后的新环境，保留了所有的服务组件元信息以及依赖关系。

在逐步的探索过程中，和官方团队在社区中进行的互动，让我们少走了很多弯路。一款开源产品如果伴随着有生命力的社区，将会是非常令人安心的。

开发测试环境部署​

第一步，部署微服务​

上手 Rainbond ，是从部署单个微服务开始的，这个过程非常简单，不需要学习 Kubernetes 的 Yaml 。开发环境中的组件是基于镜像构建完成的，只需要按界面的引导填写好镜像地址及相关信息就可以了。

我们用的是 Spring Cloud 微服务框架，在 Rainbond 体系下可以很好的运行，我在部署过程中受到了一系列文档的影响，这里分享给大家:

• Spring Cloud 微服务部署在 Rainbond 的优势

• Spring Cloud 微服务与 Service Mesh 的融合

• Spring Cloud 微服务部署在 Rainbond 的案例

第二步，通过可视化的方式服务编排​

在编排微服务的过程中，基于图形化编辑组件依赖关系这个功能，着实惊艳了我。这种编排方式和其他平台基于复杂 Yaml 文件进行编排的方式有极大的不同。感兴趣的小伙伴们可以阅读下服务编排相关的描述，这的确是一种小白都可以掌控的微服务编排方式。

第三步，对接外部的服务​

对于我们这样一个初创公司而言，将数据库等服务托管给云服务商，直接使用 RDS 服务是个既经济又稳健的选择。在 Rainbond 体系中，我通过添加第三方组件的方式将位于云端的 RDS 服务纳入管理之中。这种纳入让第三方服务也像部署在平台之中一样，可以被其他微服务组件所依赖。

至此，我的开发环境就已经部署完成了。

第四步，复制出了测试环境、预发布环境和生产环境​

在以往的开发过程中，搭建环境是一个很繁琐的事情。对一个处于快速迭代过程中的产品而言，我们至少需要开发环境、测试环境、生产环境，在我们自己的实际场景中，还引入了预发布环境。对于代码而言，我仅需要 Fork 出多个分支，来区分不同环境即可。通过定义流水线，我们也已经完成了不同代码分支打包镜像的不同 tag。但是到了搭建环境这一步，难道就只能根据不同的镜像 tag ，手动一点点的创建组件？想到藏书馆业务的近 50 个微服务组件，和彼此间的依赖关系，我的头就很大，IT 从业者最不能忍受的就是重复工作。

在探索 Rainbond 使用方法的过程中，快速复制这个功能一下子抓住了我的眼球。快速复制功能可以检出所有组件的构建源信息，对于源码构建的组件，构建源就是它的代码仓库地址、编程语言、代码分支；而对于镜像构建的组件，构建源则对应了镜像地址和 tag。在这样一个界面下，我可以选择需要被复制的组件，修改其 tag 版本。这样的复制能力可以实现环境在不同集群、不同团队下的复制。新的环境继承了原环境中除镜像 tag 以外的所有设定：依赖关系、组件名称、环境变量配置、持久化设置等等。

利用这个能力，我基于开发环境，像 Fork 一份代码一样，通过修改 tag 的方式复制出了测试环境、预发布环境和生产环境。

这一能力极大的节约了我们使用 Rainbond 时，部署各种环境的时间成本。目前，我们也把这一功能用于新人的开发环境搭建，以前手把手教新人如何搭建自己的开发环境是很费心费力的事情。

串通持续交付流程​

早前，我们已经借助 Jenkins ，自定义了一套完整的流水线，来实现所有微服务组件的构建。最终的构建产物会被定制为镜像推送到镜像仓库中去。我们对这一部分的工作是比较满意的，我们希望 Rainbond 能够在镜像仓库之后集成进来，完成微服务组件的持续构建与部署。

Rainbond 在这一部分是非常开放的，提供了接口来实现与第三方 CI 工具的对接。我们只需要在 Jenkins 的流水线完成镜像推送后，添加一个步骤简单的调用下 Rainbond 提供的接口，对应的微服务组件就会自动拉取最新的镜像，完成上线操作。到目前为止，整个技术团队都已经适应了这种使用方式。

实际上这是一个很通用的接口调用方式，无论对接哪一种第三方 CI 工具，都可以很方便的调用。

每一个运行在 Rainbond 上的微服务组件，在构建源处都可以打开自动构建的设置。自动构建设置有三种实现：

1. 基于 Git-Webhook ，针对基于源代码构建的微服务组件，可以借助代码仓库的 Webhook 能力，实现代码一推送，就触发该服务组件自动构建并上线的效果。支持的代码仓库类型比较广泛，GItlab、Github、Gitee、Gitea 等代码仓库都支持。
2. 基于镜像仓库 Webhook ，针对基于镜像构建的微服务组件，可以借助镜像仓库的 Webhook 能力，实现镜像一推送，就触发该服务组件自动构建并上线的效果。Harbor、Dockerhub 等镜像仓库都支持 Webhook 功能。
3. 自定义 API，这是最通用的接口调用方式，用户只需要基于 Http 协议调用，即可触发该服务组件的自动构建并上线。

触发上图中的自动构建 API，最简单的方式是在命令行中执行一条命令：

curl -d '{"secret_key":"6GvowlHX"}' -H "Content-type: application/json" -X POST https://<Rainbond控制台地址>/console/custom/deploy/c4e7b60bd800986df940d8103f22d271

目前，我们已经可以做到以很简单的方式，精确触发到指定的流水线，完成对应微服务组件的更新上线。

其他通过 Rainbond 解决的问题​

随着对 Rainbond 这款产品认识的不断加深，我们开始不断抛却一些琐事，一些传统部署模式下难以规避的问题，借助 Rainbond 的能力都得以很好的解决：

1. 内部依赖配置无法查询

   传统部署模式下，所有组件之间的相关依赖，都是写在配置文件中的一系列配置。对产品整体没有足够了解的工程师很难掌握所有依赖项的引用地址，写错 IP 导致调用不通的失误时有发生。借助应用拓扑图的展现，现在每一个新手工程师，在看到拓扑图之后，都会立刻对产品的整体结构产生直观认识。

2. 多实例部署异常后排查不便

   传统部署模式下，每个微服务组件如果需要多实例部署，都需要工程师们手动操作服务器上传 jar 包进行配置。如果遇到升级调整，偶尔还会错漏。一旦出现问题需要排查，如何定位正确的实例就已经很麻烦了。Rainbond 环境下，每个微服务组件的多实例版本一致性不需要关心，而出问题排查时，实时日志推送和 Web 控制台都帮了大忙。

3. 服务器资源不能共享

   传统部署模式下，我们通过划分虚拟机来避免计算资源的浪费，然而这还不够。我们希望计算资源能够完全池化，面向每个微服务组件来划分。这一点所有基于 Kubernetes 实现的应用管理平台都可以实现。而 Rainbond 的伸缩设置，是我见过产品化做的最好，最易用的。Rainbond 平台上线后缩减了三分之二的服务器资源。

4. 相同监听端口不能同台部署

   端口其实也是一种重要的资源，同个操作系统下，端口的占用是不可以冲突的。这个问题在大规模微服务组件部署时显得尤为突出。Rainbond 这一点做的很好，每个微服务不会直接占用服务器端口，我们的开发人员可以更自由的定义组件监听了。

5. 开发人员权限管理

   真实的业务场景下，软件系统本身的问题并非都由运维人员处理，更多的情况下需要开发者本人排查和处理。而权限管理则要求开发人员尽可能不具备登录生产服务器的权限。这就导致了一个两难的问题，快速解决问题还是严格管控权限？这是开发人员和运维人员容易产生冲突的点。引入 Rainbond 之后，这个问题得到了很好的解决，开发人员的所有操作都是在 Rainbond 管理界面进行的，即使需要通过命令行排查问题，也可以通过 Web 控制台登录容器环境，而不是宿主机服务器。目前，我们已经形成了应用开发人员基于 Rainbond 运维自己开发微服务组件的模式。

6. 应用版本回滚

   传统模式下，微服务组件的部署有多复杂，那么回滚到上一个版本就只会更复杂。Rainbond 这款产品非常贴心的提供了服务组件级别的一键回滚，管理人员可以在版本列表之中随意选择需要的版本，进行一键回滚，这真的太方便了。

写在最后​

和使用其他产品一样，深入使用 Rainbond 也是需要一些磨合过程的。令我印象深刻的一个情况，是 Rainbond 使用的 Glusterfs 分布式文件系统，在经过很长一段时间的使用之后，存储容量被用尽，导致了一系列问题。我们的运维人员缺少对 Glusterfs 的了解，对 Rainbond 如何与 Glusterfs 相互作用更是一知半解。无奈之下求助官方，出乎意料的是官方的工程师非常热心的支持我们解决了问题，并贴心的留下了操作文档。

我对 Rainbond 最大的感触是其易用性做的很好。希望 Rainbond 团队可以将这一点贯彻到底，提供更多能够解决实际问题的实用特性。我们了解到 Rainbond 的 Service Mesh 下一步可以支持 istio，下一阶段我们打算尝试一下。

在现代企业的数字化转型过程中，如何高效管理和快速部署业务应用已经成为各行业的核心挑战。尤其是在智慧工地和办公自动化（OA）这样的关键业务场景中，企业不仅需要面对频繁的系统更新，还要确保系统的稳定性与高效运作。然而，传统的运维方式往往繁琐且容易出错，手动操作不仅耗费大量时间，还极大增加了运维成本。

为了应对这些挑战，越来越多的企业开始寻求云原生平台的支持，希望通过自动化的流程来简化应用的部署与管理。**北京城建智控科技股份有限公司（以下简称：城建智控）**便面临着类似的困境，他们发现，传统的手动部署方式已经无法满足业务的需求，尤其是在没有专职运维团队的情况下，开发人员的工作负担不断加重。在这种背景下，城建智控引入了 Rainbond，希望通过其自动化的源码部署能力和友好的操作界面，提升业务的灵活性与运维效率。

痛点​

手动部署流程复杂​

在引入 Rainbond 之前，我们的服务发布流程极其繁琐，每次服务需要打补丁时，开发人员必须手动打包 jar 包，并将其上传至服务器。之后还需手动停启服务，整个过程不仅耗时，且容易因为操作失误导致服务中断，影响业务的正常运作。

原有 PaaS 平台的局限性​

我们曾经使用过一个 PaaS 平台，试图简化服务的交付流程。然而，尽管这个平台在一定程度上解决了 CD 的问题，但它的使用过程依然非常复杂。平台要求我们必须具备对容器和 Kubernetes 的深刻理解才能有效操作，这使得开发人员的学习成本大幅增加。每次部署时，我们不仅要了解容器镜像的构建和管理，还需要手动编写 Kubernetes 的 YAML 文件来定义服务的各个部分。这对没有 Kubernetes 运维经验的开发人员来说是一个巨大的障碍，也因此导致了整个 CI/CD 流程难以打通，效率低下。

采用 Rainbond​

引入 Rainbond 云原生平台后，不仅打通了 CI/CD 流程，还极大地简化了操作流程，特别是对于那些不了解 Kubernetes 的开发人员，他们也能轻松上手使用。

• 自动化 CI/CD 流程：通过 Rainbond 平台，企业实现了从代码提交、自动化构建到发布的全流程自动化。开发人员只需专注于代码开发，Rainbond 平台会自动完成打包、部署、服务的启动和监控。整个过程无需手动干预，极大地提高了发布效率。

• 无 Kubernetes 知识门槛：Rainbond 的界面友好，对于不懂 Kubernetes 的开发人员来说，也能迅速上手操作。平台的可视化界面简化了复杂的 K8s 操作，开发人员只需通过平台提供的图形界面配置应用，轻松完成服务部署、扩展和维护。

• 减少对专职运维的依赖：得益于 Rainbond 的平台能力，企业无需专职的运维团队即可实现应用的高效管理。开发人员或兼职的技术人员通过平台即可完成服务的日常管理工作，大大减少了人力成本的投入。

结语​

通过引入 Rainbond 云原生平台，帮助城建智控解决了此前在应用部署和管理中的诸多痛点，尤其是在智慧工地和办公自动化等业务场景中。Rainbond 不仅帮助城建智控实现了 CI/CD 流程的全面自动化，还简化了 Kubernetes 和容器技术的复杂操作，使得没有容器化和 Kubernetes 经验的开发人员也能快速上手，极大地提升了工作效率。更重要的是，Rainbond 帮助我们摆脱了对专职运维团队的依赖，开发团队通过其直观的界面即可完成日常的应用管理和运维工作。

Rainbond 的引入让我们的服务管理变得更加高效和可靠，平台的灵活性和可扩展性为未来业务的增长和需求变化提供了坚实的技术支持。随着业务的扩展，我们相信 Rainbond 将继续发挥其优势，帮助我们实现更高效、更智能的运营管理，加速企业的数字化转型进程。

关于城建智控​

北京城建智控科技股份有限公司（简称“城建智控”）成立于2014年，是北京城建集团科技产业化的重要组成部分。公司致力于成为国内领先的“数字城市”综合解决方案服务商，聚焦国家“数字经济”战略，提供集“设计、研发、制造、集成、运维”为一体的数字技术服务体系。公司深耕数字交通领域，运用云计算、大数据、物联网和人工智能技术，推动城市轨道交通的数字化转型。

背景介绍​

京东方科技集团股份有限公司（BOE）创立于1993年4月，是一家领先的物联网创新企业。通过物联网、人工智能、大数据以及行业云技术，聚焦软硬融合的产品与服务，为客户提供一站式园区物联解决方案。

北京好雨科技自2019年起，开始与京东方CTO技术团队深入合作，以自身产品 Rainbond、 RainStore 云原生应用商店为基础，打造出京东方物联网生态产品云（ITS云平台）。为京东方物联网解决方案提供一体化的开发、测试、交付能力。基于云原生应用研发和交付解决方案，助力京东方CTO技术团队进行中台模式转型，实现其产品研发 统一管理、产品POC自动化、项目交付标准化。

需求场景​

应用开发平台​

打造低学习成本的开发平台，京东方技术团队可以轻松地集成和管理来自不同开发团队的源代码和容器镜像。平台提供了简化的界面和工具，使开发人员能够快速上手并无缝地整合不同的代码资源。这降低了学习成本，使团队成员能够更专注于业务逻辑的开发，而无需过多关注底层技术细节。应用开发平台的目标是降低学习成本，帮助京东方技术团队顺利完成物联网业务系统从传统架构向微服务架构的进化过程。通过整合来自不同开发团队的源代码和容器镜像，提供简化的开发和管理工具，以及支持微服务架构的部署和协调能力，该平台将为团队提供一个高效、灵活且易于使用的开发环境，加速业务系统的演进和创新。

SaaS应用运维平台​

SaaS应用运维平台为京东方技术团队提供了全面而高效的应用管理能力，为管理应用的运维过程提供了全面而便捷的解决方案。无论是自动部署、运维可视化、自动弹性伸缩、资源计量、升级发布还是备份回滚，平台都致力于简化运维流程，提升工作效率，并为用户提供卓越的用户体验。

ITS云服务平台​

通过构建SaaS平台，ITS云服务平台实现了IoT商店交付模式，为用户提供了多种物联解决方案的交付方式，包括在线和离线两种模式。这种灵活的交付方式有效地解决了复杂软件交付过程中的痛点和挑战。平台提供了在线交付的能力，用户可以直接通过云端访问和获取物联解决方案。无需复杂的安装和配置过程，用户可以快速选择并部署所需的解决方案。这种在线交付方式大大简化了部署流程，减少了用户的学习成本和部署难度。平台还支持离线交付的方式。对于一些特定场景，需要在无网络环境下进行部署和交付物联解决方案。ITS云服务平台提供了离线部署的选项，将解决方案的相关组件和数据打包为离线包，用户可以将其下载到本地环境并进行部署。这种离线交付方式适用于一些安全性要求较高或无网络连接的场景，为用户提供了更大的灵活性和选择权。通过多种交付方式的支持，ITS云服务平台有效地解决了复杂软件交付的痛点。无论是在线交付还是离线交付，平台都致力于简化部署流程，提供便捷的交付体验。用户可以根据实际需求和环境选择最适合的交付方式，从而更快地实现物联解决方案的部署和应用。

物联网生态产品云​

基于 Rainbond 打造的ITS云服务平台为京东方技术团队提供了一个全面的解决方案，帮助他们整合和管理组织人员，并实现物联网生态应用的无缝连接，从业务代码的开发到CI/CD流程、资源管理和运维管理的全生命周期。打造该平台的最终目标，是为了对外提供IT信息能力的输出，将技术团队开发好的物联网生态应用系统以在线商品的形式对外输出。

ITS云服务平台基于Rainbond的强大功能，为京东方技术团队提供了一个统一的开发和交付环境。开发人员可以使用平台提供的工具和功能，快速构建物联网应用的业务代码，并通过CI/CD流程实现自动化的构建、测试和部署。该平台提供了丰富的资源管理功能，可以有效管理和调度云计算资源。团队可以根据应用的需求，灵活分配和管理计算、存储和网络资源，实现资源的高效利用和优化。ITS云服务平台还提供了全面的运维管理功能，包括监控、日志管理、故障排查等。通过对应用和基础设施的实时监控，团队可以及时发现和解决问题，确保系统的稳定运行。

技术架构​

在 ITS 产品云项目中，PaaS 平台基于 Rainbond 进行定制开发。向下对接来自自建机房与阿里云ACK的计算资源，向上承载 SaaS 应用的开发、运维全过程。

ITS 云服务平台是基于云原生应用商店 RainStore 定制开发而来的 SaaS 平台，提供了对行业 SaaS 应用商品化管理的全流程能力。囊括了 SaaS 应用的交易管理、交付管理等领域，打造出行业云应用商店的使用体验。

项目成果​

目前 ITS 产品云已经分别基于本地机房、阿里云ACK环境建设起两套数据中心，所纳管的 30 套行业物联网业务系统，包含了近 200 个服务组件。京东方技术团队依靠 ITS 产品云开发与维护这些行业物联网业务系统，提升了整体开发效率，降低了运行维护成本。

SaaS 平台打通了行业物联网业务系统从前期的产品展示，到后期的软件交付，费用结算的流程，商务团队不需要专业技术人员的支持，即可快速为意向客户展示自家的业务系统，也降低了软件交付的技术难度。