共计 2870 个字符，预计需要花费 8 分钟才能阅读完成。
大家好，我是山西数智时代科技有限公司的赵佳鹏，咱们公司成立于 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 在将来能再接再厉做的更好。
