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

语言: CN / TW / HK

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