柯基数据通过Rainbond完成云原生改造，实现离线持续交付客户

由于遇到过离线持续交付的场景，也迟迟没有特别好的方案，仍然使用的传统方式的开发交付，看到柯基数据通过Rainbond将服务改造成云原生，受到了一定的启发，这边原本开通了云服务器搭建环境走一遍流程，试试把业务通过改造改成云原生（时间可能不短），由于配置原因还是在本地虚拟机中重新部署了Rainbond用于测试，云原生改造部分正在进行，后续会更新，柯基数据的改造细节希望对你也有所帮助，详情如下：

最开始我们尝试自己搭建公司内部的开发测试环境，过程中遇到的两个小坑。

第一个坑是：环境搭建完成后使用体验却不佳，所有涉及到磁盘读写的操作都显得异常卡顿，集群中的 Etcd 集群日志中不断报告处于 “read_only” 状态，随之而来的是服务器负载的不断飙升。

我们带着怀疑的心情求助了Rainbond开源社区，经过多方面的排查，我们把目光落在了磁盘的IO性能上。替换了高性能的磁盘之后，我们重新安装了整个开发测试环境，磁盘性能的提升的确解决了 Etcd 集群时常不工作的问题。

第二个坑是：使用了共享存储的服务却依然处于读写极慢的状态，这着实令在场的所有工程师又开始头大了。确认了硬件性能之后，开始将目光放在操作系统配置参数上面，操作系统内核在不断报告与共享存储有关的错误：

NFS:__nfs4_reclaim_open_state: Lock reclaim failed!指征 nfs client 和 nfs server 之间存在同步差异，差得多了就会开始报警。经过不断摸索，工程师们终于锁定了与 nfs 性能有关的两个系统参数，Linux nfs 客户端对于同时发起的NFS请求数量进行了控制，若该参数配置较小会导致 IO 性能较差。

echo "options sunrpc tcp_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf
echo "options sunrpc tcp_max_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf

修改了这两个参数后，共享存储的性能得到了显著的提升，令人摸不到头脑的内核报警信息也随之消失。开发测试环境终于可以顺畅使用了。

接下来面临新的挑战是如何将我们的多套业务系统顺利迁移到 Rainbond 上去，所幸Rainbond 的使用很简单，整体学习梯度并不陡峭，我们很轻松把业务系统分批的部署在 Rainbond 上去。然而 Rainbond 工程师组织的云原生应用评估却指出了业务系统有多处不符合云原生特征之处，提出了一些整改意见。在整改过程中，我们对云原生也有了更深入理解。

• Elasticsearch等有状态组件需要将组件部署类型调整成为有状态单实例或有状态多实例，不可以是无状态我们最开始并不了解什么是有\无状态组件，所以并没有注意区分组件的部署类型。Rainbond工程师提示我们，Elasticsearch在Rainbond平台中应该使用有状态的组件部署类型进行部署。
  

  L1级云原生应用特征——可伸缩性

  云原生应用注重部署组件所使用的资源类型，像数据库类型、消息队列类型的服务组件对在Rainbond平台上，应该使用StatefulSet资源类型进行部署。通过对服务组件定义有状态或者无状态的部署类型，来规定使用StatefulSet或Deployment资源类型来部署实例。

• 支持横向伸缩我们的多套业务系统，在接触云原生改造之前，都是传统的单体架构，部署时也基本不考虑高可用特性。这使我们的业务系统相对而言脆弱许多，没有任何容错能力，一旦服务器宕机，整个业务系统就失去了服务能力。云原生改造的过程中，我们借助于Rainbond天然的微服务能力，非常轻松的将我们的业务系统拆分成为更为合理的微服务架构。更令我们惊喜的是，这些拆分出来的微服务组件，大多数直接具备了横向伸缩的能力，借助Rainbond的一键伸缩能力，迅速扩展成为多实例的集群，极大的提高了系统的可用性。而针对某几个不可以一键伸缩的组件，Rainbond工程师们也提供了合理的意见，引导我们对这几个特殊的组件进行修改，使之实现了“无状态化”。现在，经过云原生改造的业务具备了“小强”一般顽强的生命力，再也不怕服务器宕机了。
  

  L1级云原生应用特征——可伸缩性

  通过程序数据分离等手段，实现应用程序的无状态化，就让云原生应用可以随意横向伸缩多个实例。实例数量的伸缩一方面使云原生应用具备了高可用性，也直接影响其抗并发的能力。Rainbond还提供自动伸缩功能，实现削峰填谷。

• 所有配置支持环境变量配置，形如 ${GATEWAY_PORT:8083}以往我们都将服务的配置项写成固定的值，这样的做法使得我们每到一个新的部署环境，都要重新更改大量的配置文件。Rainbond工程师指出，云原生应用应该将配置保存到环境当中，以环境变量加默认值的方式声明出来。而大多数需要修改的配置项，如不同组件之间的连接地址信息，就可以通过Rainbond依赖关系中的连接信息来相互注入，省去了大量的配置工作。
  

  L1级云原生应用特征——可配置性

  云原生应用推崇的一种最佳实践，就是将配置保存在环境之中。在不同的运行环境中，利用环境变量来进行配置，是一种非常好的体验。Rainbond支持为每个服务组件设置环境变量，也可以基于配置组功能，批量配置环境变量。

• 组件主要端口通过环境变量  ${PORT} 定义Rainbond工程师提供了一个小技巧，将组件监听端口的配置，用一个固定的环境变量来配置，这个变量的值会随着我们在Rainbond控制台上手动添加的端口号来自动变更，这样，我们就可以在不更改代码和配置的情况下，随意变更想要监听的端口号，这很方便。
  

  L1级云原生应用特征——可配置性

  作为对环境变量的补充，Rainbond提供了一系列可以自动生成的环境变量，这些特定的环境变量极大方便了用户的使用。

• 所有组件需要统一时区统一所有组件的时区配置是非常有必要的，Rainbond工程师提供了一个技巧，让时区的设置变成了一个很简单的事情。只需要运行环境的镜像中包含 tzdata 软件包，我们就可以基于 TZ=Asia/shanghai 这样一个环境变量的配置，完成时区的配置了。
  

  L1级云原生应用特征——基础可观测性

  统一时间在运维领域十分重要，在云原生领域，时区的配置也可以基于环境变量进行配置。

• 所有业务需要定义健康检查策略Rainbond工程师要求我们为所有的服务组件定义健康检查策略，这样可以在服务组件遭遇问题时，快速识别到运行异常状态，在根据事先的配置，完成下线或重启的操作。对于 http 服务，我们定义了一个检测接口，通过探针请求返回的状态码来判断服务的状态；对于一般中间件，则检测其TCP端口的监听状态来判断。
  

  L1级云原生应用特征——高容错性

  在提高容错性方面，云原生应用需要配置合理的健康检查策略。这有利于快速发现组件的异常状况，并根据事先配置好的策略进行自动化的重启、下线等操作。

• 组件应支持优雅失败与重试机制Rainbond工程师向我们阐述我们的服务组件在被关闭时，应该做出怎样的反应，来最大化的优化最终用户的体验。进程接收SIGTERM时，拒绝新请求，完成已接收请求后关闭端口，退出进程。而对于服务组件突然丢失了数据库连接这样的情况，也应该添加合理的重试机制，在多次重试依然无法重新连接到数据库时，理应结束进程，用显式的组件异常状态来提醒运维人员。
  

  L1级云原生应用特征——高容错性

  云原生应用强调容错性，这不仅仅包含在某些错误被触发时，应用本身和平台是否提供自动的处理手段，也包括在错误无法被处理时，提供更好的可观测性，来提醒运维人员介入。

• 前端web组件调用后端api组件地址需要进行nginx代理对于前后端分离的项目，合理的利用前端的web服务器进行接口层的转发是一种很好的体验。Rainbond工程师在帮助我们完成前端VUE项目的源码构建的同时，也教学了如何通过在代码根目录下添加配置文件，来实现接口请求向后端组件的转发。
  

  L2级云原生应用特征——前后端分离配置

  Rainbond提供了便捷的方式来配置VUE等前端项目运行的Nginx，配置后只需要将前后端组件依赖起来，就可以实现API的转发。而不需要每部署一次，都要根据后端服务的地址变更而重新编译。

   

• 实现一键交付使用Rainbond的目的之一，是希望能够借助其能力，实现业务系统的快速交付。通过与好雨科技交付团队的合作，我们只需要提供应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键交付整套业务系统。这极大的降低了我们的交付成本。
  

  L2级云原生应用特征——一键安装

  借助于 Rainbond 提供的应用发布能力，我们可以将运行在平台上的企业应用一键发布为一个应用模版。我们对应用模版最殷切的期待，是可以将这个应用模版以最简单的操作方式、尽可能少的人为调试即可安装成为一个应用。

• 实现一键升级为了适应最终用户的需求，我们需要不断迭代自己的产品，并在生产环境中持续升级我们的业务系统。Rainbond 基于应用模板的版本实现了一键升级的能力，这个功能对我们非常有用，我们只需要提供更高版本的应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键升级整套业务系统。
  

  L2级云原生应用特征——一键升级

  Rainbond 的应用商店机制支持基于应用模板的版本对已安装的应用进行升级操作。平台的升级机制解决了服务组件版本、配置、依赖关系等绝大部份属性的版本管理问题。尚需应用开发人员关注的问题在于数据的版本管理。

应用完成改造后，通过Rainbond可以查看我们产品的拓扑图和依赖关系。

在实际项目当中，我们产品流转了三个环境：

开发环境：我们在公司内部，使用开源版本的Rainbond在公司服务器上搭建了开发测试环境，我们开发团队通过源码构建，很快将业务系统搬上了Rainbond。通过一段时间的测试和迭代，我们拿出了首个版本的应用模板，并使用离线导出功能导出了离线包。

准入测试环境：利用光盘等介质，仅需一个工程师将离线包导入了最终客户提供的私有云准入测试环境，导入后产品一键安装。对于客户反馈的意见，我们在开发环境中导出新的离线包，并再次导入了准入测试环境，进行了一键升级，经过多次迭代最终达到客户的准入要求。

生产环境：最终生产环境是完全由客户管理，我们仅需要提供经过准入的应用模板离线包以及必要的文档，客户就可以非常快速的将我们的产品完成部署和升级。

相对于以前的交付方式和流程，接入Rainbond体系给我们带来了这些更好的交付体验：

• 更便捷的交付方式：交付物只是离线包，不需要关心客户复杂的运行环境。
• 更低的交付成本：无论从时间还是人力的角度，交付成本都极大的降低了。
• 应用运维过程自动化：云原生技术切实的提升了业务系统的各项能力，可用性、容错性以及应对流量陡增时动态的伸缩能力。