藏书馆 App 基于 Rainbond 实现云原生 DevOps 的实际

咱们须要的不是精通 Kubernetes 的工程师，咱们须要一款小白都能用好的管理工具。

​ —— 厦门正观易知科技有限公司运维负责人 郭传壕

大家好，我是厦门正观易知科技有限公司运维负责人郭传壕。

藏书馆是一个专一用户自我成长的云端私人图书馆，集电子书的读、荐、借、购、存和常识治理性能于一体，致力于用户的认知赋能，通过读书习惯的养成，达成自我成长。目前累计注册用户已达 1500W，平台图书资源超过 200W 册。

咱们应用 Rainbond 曾经有 2 年，我把咱们的应用教训分享给大家。

1. 以前的困局

处于云原生时代中的藏书馆的终点很高，咱们一开始就选定了微服务架构、Kubernetes、容器化等合乎时代潮流的技术体系。然而原生的 kubernetes 治理平台提供的性能并不完全符合咱们的预期，二次开发的微小技术老本也是咱们累赘不起的。

在理解到 Rainbond 之前，处于守业初期的咱们始终受困于产品迭代变更频繁所带来的琐事之中。我所说的琐事蕴含微服务架构下 50 个服务的版本治理、构建产物的更替、线上环境的公布以及围绕着利用从开发到上线再到运维的种种繁琐工作。

咱们心愿能够从这些琐事中跳脱进去，专一于业务自身，摸索出一条适宜 kubernetes 环境下继续开发、继续交付的简捷之路。

鉴于此，咱们开始踊跃的寻找一款开源且易用的利用治理平台。

2. 初识 Rainbond

在 Rainbond 之前，咱们曾经尝试过了 Rancher 等产品，但产品性能和咱们的预期有很大差距。

2 年前，咱们通过 Github 第一次理解到了 Rainbond 这款产品，惊喜于性能十分符合藏书馆的需要。列举几个令人印象粗浅的能力：

• 利用架构的整体拓扑图

以上帝视角，和盘托出的观测到所有服务组件的运行状态与依赖关系。强迫症会逼着咱们的工程师毁灭红色的异样状态，而体现运行状态的绿色真的令人感到安心。

• 可视化的资源占用状况

资源占用状况是体现可观测性很重要的指标。对于初创公司而言，理解资源分配是否正当，杜绝资源节约是很重要的。Rainbond 从团队到服务组件的每个维度都提供了良好的可观测性。团队级别的资源限额能力十分实用，解决了运维团队无奈无效掌控资源分配的难题。

• 主动伸缩

藏书馆是一个典型的 2C 场景，如何利用好云计算提供的弹性，灵便的应答流量顶峰呢？答案就是应用主动伸缩性能。Rainbond 提供的主动伸缩性能，突出了简略易配置的特点。主动伸缩能力极大的解放了运维团队的工作压力，从此远离调兵遣将和壁垒森严。要害业务会随着咱们的情意，主动扩张，直到可能吞吐所有流量。

• 集中式的网关策略管理

2C 场景下的服务公布，是无论如何也绕不过来的坎儿。无论是蓝绿公布、灰度公布抑或是 A / B 测试，这服务公布相干的十八般武艺多少都会碰到。原生的 Kubernetes Ingress 确实能够实现这些公布策略，然而咱们更心愿失去一个产品化的集中式治理页面来解决这些问题，而不是去麻烦运维工程师们去碰那些格局严苛的 Yaml 文件。Rainbond 网关策略管理完满的实现了咱们的需要。

• 利用复制疾速生成环境

在藏书馆的开发流程中，咱们时常须要搭建各种环境，来辨别开发、测试、预公布场景，别离对应不同版本的微服务组件，比方 Dev、Prod 之类的。但如果每次生成环境都要手动创立服务组件，那真的太低效了。利用复制性能在这个场景下十分有用，它帮忙我疾速复制出一套环境进去。复制过程中自助抉择构建源的版本，对我而言是镜像的 Tag。复制后的新环境，保留了所有的服务组件元信息以及依赖关系。

在逐渐的摸索过程中，和官网团队在社区中进行的互动，让咱们少走了很多弯路。一款开源产品如果随同着有生命力的社区，将会是十分令人安心的。

3. 开发测试环境部署

第一步，部署微服务

上手 Rainbond，是从部署单个微服务开始的，这个过程非常简单，不须要学习 Kubernetes 的 Yaml。开发环境中的组件是基于镜像构建实现的，只须要按界面的疏导填写好镜像地址及相干信息就能够了。

咱们用的是 Spring Cloud 微服务框架，在 Rainbond 体系下能够很好的运行，我在部署过程中受到了一系列文档的影响，这里分享给大家:

• Spring Cloud 微服务部署在 Rainbond 的劣势
• Spring Cloud 微服务与 Service Mesh 的交融
• Spring Cloud 微服务部署在 Rainbond 的案例

第二步，通过可视化的形式服务编排

在编排微服务的过程中，基于图形化编辑组件依赖关系这个性能，着实惊艳了我。这种编排形式和其余平台基于简单 Yaml 文件进行编排的形式有极大的不同。感兴趣的小伙伴们能够浏览下服务编排相干的形容，这确实是一种小白都能够掌控的微服务编排形式。

第三步，对接内部的服务

对于咱们这样一个初创公司而言，将数据库等服务托管给云服务商，间接应用 RDS 服务是个既经济又持重的抉择。在 Rainbond 体系中，我通过增加第三方组件的形式将位于云端的 RDS 服务纳入治理之中。这种纳入让第三方服务也像部署在平台之中一样，能够被其余微服务组件所依赖。

至此，我的开发环境就曾经部署实现了。

第四步，复制出了测试环境、预公布环境和生产环境

在以往的开发过程中，搭建环境是一个很繁琐的事件。对一个处于疾速迭代过程中的产品而言，咱们至多须要开发环境、测试环境、生产环境，在咱们本人的理论场景中，还引入了预公布环境。对于代码而言，我仅须要 Fork 出多个分支，来辨别不同环境即可。通过定义流水线，咱们也曾经实现了不同代码分支打包镜像的不同 tag。然而到了搭建环境这一步，难道就只能依据不同的镜像 tag，手动一点点的创立组件？想到藏书馆业务的近 50 个微服务组件，和彼此间的依赖关系，我的头就很大，IT 从业者最不能忍耐的就是反复工作。

在摸索 Rainbond 应用办法的过程中，疾速复制这个性能一下子抓住了我的眼球。疾速复制性能能够检出所有组件的构建源信息，对于源码构建的组件，构建源就是它的代码仓库地址、编程语言、代码分支；而对于镜像构建的组件，构建源则对应了镜像地址和 tag。在这样一个界面下，我能够抉择须要被复制的组件，批改其 tag 版本。这样的复制能力能够实现环境在不同集群、不同团队下的复制。新的环境继承了原环境中除镜像 tag 以外的所有设定：依赖关系、组件名称、环境变量配置、长久化设置等等。

利用这个能力，我基于开发环境，像 Fork 一份代码一样，通过批改 tag 的形式复制出了测试环境、预公布环境和生产环境。

这一能力极大的节约了咱们应用 Rainbond 时，部署各种环境的工夫老本。目前，咱们也把这一性能用于新人的开发环境搭建，以前手把手教新人如何搭建本人的开发环境是很费神费劲的事件。

4. 串通继续交付流程

早前，咱们曾经借助 Jenkins，自定义了一套残缺的流水线，来实现所有微服务组件的构建。最终的构建产物会被定制为镜像推送到镜像仓库中去。咱们对这一部分的工作是比较满意的，咱们心愿 Rainbond 可能在镜像仓库之后集成进来，实现微服务组件的继续构建与部署。

Rainbond 在这一部分是十分凋谢的，提供了接口来实现与第三方 CI 工具的对接。咱们只须要在 Jenkins 的流水线实现镜像推送后，增加一个步骤简略的调用下 Rainbond 提供的接口，对应的微服务组件就会主动拉取最新的镜像，实现上线操作。到目前为止，整个技术团队都曾经适应了这种应用形式。

实际上这是一个很通用的接口调用形式，无论对接哪一种第三方 CI 工具，都能够很不便的调用。

每一个运行在 Rainbond 上的微服务组件，在构建源处都能够关上主动构建的设置。主动构建设置有两种实现：

• 基于 Git-Webhook，针对基于源代码构建的微服务组件，能够借助代码仓库的 Webhook 能力，实现代码一推送，就触发该服务组件主动构建并上线的成果。反对的代码仓库类型比拟宽泛，GItlab、Github、Gitee、Gitea 等代码仓库都反对。
• 基于镜像仓库 Webhook，针对基于镜像构建的微服务组件，能够借助镜像仓库的 Webhook 能力，实现镜像一推送，就触发该服务组件主动构建并上线的成果。Harbor、Dockerhub 等镜像仓库都反对 Webhook 性能。
• 自定义 API，这是最通用的接口调用形式，用户只须要基于 Http 协定调用，即可触发该服务组件的主动构建并上线。

触发上图中的主动构建 API，最简略的形式是在命令行中执行一条命令：

curl -d '{"secret_key":"6GvowlHX"}' -H "Content-type: application/json" -X POST https://<Rainbond 控制台地址 >/console/custom/deploy/c4e7b60bd800986df940d8103f22d271

目前，咱们曾经能够做到以很简略的形式，准确触发到指定的流水线，实现对应微服务组件的更新上线。

5. 其余通过 Rainbond 解决的问题

随着对 Rainbond 这款产品意识的一直加深，咱们开始一直抛却一些琐事，一些传统部署模式下难以躲避的问题，借助 Rainbond 的能力都得以很好的解决：

• 外部依赖配置无奈查问

传统部署模式下，所有组件之间的相干依赖，都是写在配置文件中的一系列配置。对产品整体没有足够理解的工程师很难把握所有依赖项的援用地址，写错 IP 导致调用不通的失误时有发生。借助利用拓扑图的展示，当初每一个老手工程师，在看到拓扑图之后，都会立即对产品的整体构造产生直观意识。

• 多实例部署异样后排查不便

传统部署模式下，每个微服务组件如果须要多实例部署，都须要工程师们手动操作服务器上传 jar 包进行配置。如果遇到降级调整，偶然还会错漏。一旦呈现问题须要排查，如何定位正确的实例就曾经很麻烦了。Rainbond 环境下，每个微服务组件的多实例版本一致性不须要关怀，而出问题排查时，实时日志推送和 Web 控制台都帮了大忙。

• 服务器资源不能共享

传统部署模式下，咱们通过划分虚拟机来防止计算资源的节约，然而这还不够。咱们心愿计算资源可能齐全池化，面向每个微服务组件来划分。这一点所有基于 Kubernetes 实现的利用治理平台都能够实现。而 Rainbond 的伸缩设置，是我见过产品化做的最好，最易用的。Rainbond 平台上线后缩减了三分之二的服务器资源。

• 雷同监听端口不能同台部署

端口其实也是一种重要的资源，同个操作系统下，端口的占用是不能够抵触的。这个问题在大规模微服务组件部署时显得尤为突出。Rainbond 这一点做的很好，每个微服务不会间接占用服务器端口，咱们的开发人员能够更自在的定义组件监听了。

• 开发人员权限治理

实在的业务场景下，软件系统自身的问题并非都由运维人员解决，更多的状况下须要开发者自己排查和解决。而权限治理则要求开发人员尽可能不具备登录生产服务器的权限。这就导致了一个两难的问题，疾速解决问题还是严格管控权限？这是开发人员和运维人员容易产生抵触的点。引入 Rainbond 之后，这个问题失去了很好的解决，开发人员的所有操作都是在 Rainbond 治理界面进行的，即便须要通过命令行排查问题，也能够通过 Web 控制台登录容器环境，而不是宿主机服务器。目前，咱们曾经造成了利用开发人员基于 Rainbond 运维本人开发微服务组件的模式。

• 利用版本回滚

传统模式下，微服务组件的部署有多简单，那么回滚到上一个版本就只会更简单。Rainbond 这款产品十分贴心的提供了服务组件级别的一键回滚，管理人员能够在版本列表之中随便抉择须要的版本，进行一键回滚，这真的太不便了。

6. 写在最初

和应用其余产品一样，深刻应用 Rainbond 也是须要一些磨合过程的。令我印象粗浅的一个状况，是 Rainbond 应用的 Glusterfs 分布式文件系统，在通过很长一段时间的应用之后，存储容量被用尽，导致了一系列问题。咱们的运维人员短少对 Glusterfs 的理解，对 Rainbond 如何与 Glusterfs 相互作用更是只知其一; 不知其二。无奈之下求助官网，出其不意的是官网的工程师非常热心的反对咱们解决了问题，并贴心的留下了操作文档。

我对 Rainbond 最大的感触是其易用性做的很好。心愿 Rainbond 团队能够将这一点贯彻到底，提供更多可能解决理论问题的实用个性。咱们理解到 Rainbond 的 Service Mesh 下一步能够反对 istio，下一阶段咱们打算尝试一下。