智慧巨鹿使用 Rainbond 落地实践，一个平台管理所有应用系统

背景

大家好，我是北京数立通科技有限公司的李栋。最近几年，我一直负责“智慧巨鹿”这一智慧城市项目的运行与维护工作。这个项目涉及到 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 同行。