藏书馆App基于 Rainbond 实现云原生DevOps的实践
我们需要的不是精通 Kubernetes 的工程师,我们需要一款小白都能用好的管理工具。 -- 郭传壕
大家好,我是厦门正观易知科技有限公司运维负责人郭传壕。
藏书馆是一个专注用户自我成长的云端私人图书馆,集电子书的读、荐、借、购、存和知识管理功能于一体,致力于用户的认知赋能,通过读书习惯的养成,达成自我成长。目前累计注册用户已达 1500W ,平台图书资源超过 200W 册。
我们使用 Rainbond 已经有 2 年,我把我们的使用经验分享给大家。
以前的困局
处于云原生时代中的藏书馆的起点很高,我们一开始就选定了微服务架构、Kubernetes、容器化等符合时代潮流的技术体系。然而原生的 kubernetes 管理平台提供的功能并不完全符合我们的预期,二次开发的巨大技术成本也是我们负担不起的。
在了解到 Rainbond 之前,处于创业初期的我们一直受困于产品迭代变更频繁所带来的琐事之中。我所说的琐事包含微服务架构下 50 个服务的版本管理、构建产物的更替、线上环境的发布以及围绕着应用从开发到上线再到运维的种种繁琐工作。
我们希望可以从这些琐事中跳脱出来,专注于业务本身,探索出一条适合 kubernetes 环境下持续开发、持续交付的简捷之路。
鉴于此,我们开始积极的寻找一款开源且易用的应用管理平台。
初识 Rainbond
在 Rainbond 之前,我们已经尝试过了 Rancher 等产品,但产品功能和我们的预期有很大差距。
2 年前,我们通过 Github 第一次了解到了 Rainbond 这款产品,惊喜于功能非常契合藏书馆的需求。列举几个令人印象深刻的能力:
-
应用架构的整体拓扑图
以上帝视角,一览无余的观测到所有服务组件的运行状态与依赖关系。强迫症会逼着我们的工程师消灭红色的异常状态,而体现运行状态的绿色真的令人感到安心。
-
可视化的资源占用情况
资源占用情况是体现可观测性很重要的指标。对于初创公司而言,了解资源分配是否合理,杜绝资源浪费是很重要的。Rainbond 从团队到服务组件的每个维度都提供了良好的可观测性。团队级别的资源限额能力非常实用,解决了运维团队无法有效掌控资源分配的难题。
-
自动伸缩
藏书馆是一个典型的 2C 场景,如何利用好云计算提供的弹性,灵活的应对流量高峰呢?答案就是使用自动伸缩功能。Rainbond 提供的自动伸缩功能,突出了简单易配置 的特点。自动伸缩能力极大的解放了运维团队的工作压力,从此远离兴师动众和严阵以待。关键业务会随着我们的心意,自动扩张,直到能够吞吐所有流量。
-
集中式的网关策略管理
2C 场景下的服务发布,是无论如何也绕不过去的坎儿。无论是蓝绿发布、灰度发布抑或是 A/B 测试,这服务发布相关的十八般武艺多少都会碰到。原生的 Kubernetes Ingress 的确可以实现这些发布策略,但是我们更希望得到一个产品化的集中式管理页面来处理这些问题,而不是去麻烦运维工程师们去碰那些格式严苛的 Yaml 文件。Rainbond 网关策略管理完美的实现了我们的需求。
-
应用复制快速生成环境
在藏书馆的开发流程中,我们时常需要搭建各种环境,来区分开发、测试、预发布场景,分别对应不同版本的微服务组件,比如 Dev、Prod 之类的。但如果每次生成环境都要手动创建服务组件,那真的太低效了。应用复制功能在这个场景下非常有用,它帮助我快速复制出一套环境出来。复制过程中自助选择构建源的版本,对我而言是镜像的 Tag。复制后的新环境,保留了所有的服务组件元信息以及依赖关系。
在逐步的探索过程中,和官方团队在社区中进行的互动,让我们少走了很多弯路。一款开源产品如果伴随着有生命力的社区,将会是非常令人安心的。