云原生落地实践：山西数智时代基于 Rainbond 实现智慧景区

大家好，我是山西数智时代科技有限公司的赵佳鹏，我们公司成立于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 在未来能再接再厉做的更好。