柯基数据通过 Rainbond 完成云原生改造，实现离线持续交付客户
info
"云原生让我们在客户的离线环境里交付更自动化了" --柯基数据 刘占峰
关于柯基数据
南京柯基数据科技有限公司成立于 2015 年，提供一站式全生命周期知识图谱构建和运维、智能应用服务，致力于“链接海量数据，从大数据中挖掘智慧“。帮助企业运用知识图谱技术打造世界领先的认知工作自动化智能引擎。
目前在药企、医疗机构、军工院所、科技情报及出版等领域服务了数十家大客户，积累了丰富的行业知识图谱运用开发经验。典型客户有国防科技大学、中国航空、中国电科等。
柯基数据的云原生之路
大家好，我是南京柯基数据的解决方案架构师刘占峰，云原生技术在交付运维上的优势让我获益匪浅。作为项目合作伙伴，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.confecho "options sunrpc tcp_max_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf
修改了这两个参数后，共享存储的性能得到了显著的提升，令人摸不到头脑的内核报警信息也随之消失。开发测试环境终于可以顺畅使用了。
接下来面临新的挑战是如何将我们的多套业务系统顺利迁移到 Rainbond 上去，所幸 Rainbond 的使用很简单，整体学习梯度并不陡峭，我们很轻松把业务系统分批的部署在 Rainbond 上去。然而 Rainbond 工程师组织的云原生应用评估却指出了业务系统有多处不符合云原生特征之处，提出了一些整改意见。在整改过程中，我们对云原生也有了更深入理解。
Elasticsearch 等有状态组件需要将组件部署类型调整成为有状态单实例或有状态多实例，不可以是无状态
我们最开始并不了解什么是有\无状态组件，所以并没有注意区分组件的部署类型。Rainbond 工程师提示我们，Elasticsearch 在 Rainbond 平台中应该使用有状态的组件部署类型进行部署。
tip
L1 级云原生应用特征——可伸缩性
云原生应用注重部署组件所使用的资源类型，像数据库类型、消息队列类型的服务组件对在 Rainbond 平台上，应该使用 StatefulSet 资源类型进行部署。通过对服务组件定义有状态或者无状态的部署类型，来规定使用 StatefulSet 或 Deployment 资源类型来部署实例。
支持横向伸缩
我们的多套业务系统，在接触云原生改造之前，都是传统的单体架构，部署时也基本不考虑高可用特性。这使我们的业务系统相对而言脆弱许多，没有任何容错能力，一旦服务器宕机，整个业务系统就失去了服务能力。云原生改造的过程中，我们借助于 Rainbond 天然的微服务能力，非常轻松的将我们的业务系统拆分成为更为合理的微服务架构。更令我们惊喜的是，这些拆分出来的微服务组件，大多数直接具备了横向伸缩的能力，借助 Rainbond 的一键伸缩能力，迅速扩展成为多实例的集群，极大的提高了系统的可用性。而针对某几个不可以一键伸缩的组件，Rainbond 工程师们也提供了合理的意见，引导我们对这几个特殊的组件进行修改，使之实现了“无状态化”。现在，经过云原生改造的业务具备了“小强”一般顽强的生命力，再也不怕服务器宕机了。
tip
L1 级云原生应用特征——可伸缩性
通过程序数据分离等手段，实现应用程序的无状态化，就让云原生应用可以随意横向伸缩多个实例。实例数量的伸缩一方面使云原生应用具备了高可用性，也直接影响其抗并发的能力。Rainbond 还提供自动伸缩功能，实现削峰填谷。
所有配置支持环境变量配置，形如
${GATEWAY_PORT:8083}以往我们都将服务的配置项写成固定的值，这样的做法使得我们每到一个新的部署环境，都要重新更改大量的配置文件。Rainbond 工程师指出，云原生应用应该将配置保存到环境当中，以环境变量加默认值的方式声明出来。而大多数需要修改的配置项，如不同组件之间的连接地址信息，就可以通过 Rainbond 依赖关系中的连接信息来相互注入，省去了大量的配置工作。
tip
L1 级云原生应用特征——可配置性
云原生应用推崇的一种最佳实践，就是将配置保存在环境之中。在不同的运行环境中，利用环境变量来进行配置，是一种非常好的体验。Rainbond 支持为每个服务组件设置环境变量，也可以基于配置组功能，批量配置环境变量。
组件主要端口通过环境变量 ${PORT} 定义
Rainbond 工程师提供了一个小技巧，将组件监听端口的配置，用一个固定的环境变量来配置，这个变量的值会随着我们在 Rainbond 控制台上手动添加的端口号来自动变更，这样，我们就可以在不更改代码和配置的情况下，随意变更想要监听的端口号，这很方便。
tip
L1 级云原生应用特征——可配置性
作为对环境变量的补充，Rainbond 提供了一系列可以自动生成的环境变量，这些特定的环境变量极大方便了用户的使用。
所有组件需要统一时区
统一所有组件的时区配置是非常有必要的，Rainbond 工程师提供了一个技巧，让时区的设置变成了一个很简单的事情。只需要运行环境的镜像中包含
tzdata软件包，我们就可以基于TZ=Asia/shanghai这样一个环境变量的配置，完成时区的配置了。
tip
L1 级云原生应用特征——基础可观测性
统一时间在运维领域十分重要，在云原生领域，时区的配置也可以基于环境变量进行配置。
所有业务需要定义健康检查策略
Rainbond 工程师要求我们为所有的服务组件定义健康检查策略，这样可以在服务组件遭遇问题时，快速识别到运行异常状态，在根据事先的配置，完成下线或重启的操作。对于 http 服务，我们定义了一个检测接口，通过探针请求返回的状态码来判断服务的状态；对于一般中间件，则检测其 TCP 端口的监听状态来判断。
tip
L1 级云原生应用特征——高容错性
在提高容错性方面，云原生应用需要配置合理的健康检查策略。这有利于快速发现组件的异常状况，并根据事先配置好的策略进行自动化的重启、下线等操作。
组件应支持优雅失败与重试机制
Rainbond 工程师向我们阐述我们的服务组件在被关闭时，应该做出怎样的反应，来最大化的优化最终用户的体验。进程接收 SIGTERM 时，拒绝新请求，完成已接收请求后关闭端口，退出进程。而对于服务组件突然丢失了数据库连接这样的情况，也应该添加合理的重试机制，在多次重试依然无法重新连接到数据库时，理应结束进程，用显式的组件异常状态来提醒运维人员。
tip
L1 级云原生应用特征——高容错性
云原生应用强调容错性，这不仅仅包含在某些错误被触发时，应用本身和平台是否提供自动的处理手段，也包括在错误无法被处理时，提供更好的可观测性，来提醒运维人员介入。
前端 web 组件调用后端 api 组件地址需要进行 nginx 代理
对于前后端分离的项目，合理的利用前端的 web 服务器进行接口层的转发是一种很好的体验。Rainbond 工程师在帮助我们完成前端 VUE 项目的源码构建的同时，也教学了如何通过在代码根目录下添加配置文件，来实现接口请求向后端组件的转发。
tip
L2 级云原生应用特征——前后端分离配置
Rainbond 提供了便捷的方式来配置 VUE 等前端项目运行的 Nginx，配置后只需要将前后端组件依赖起来，就可以实现 API 的转发。而不需要每部署一次，都要根据后端服务的地址变更而重新编译。
实现一键交付
使用 Rainbond 的目的之一，是希望能够借助其能力，实现业务系统的快速交付。通过与好雨科技交付团队的合作，我们只需要提供应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键交付整套业务系统。这极大的降低了我们的交付成本。
tip
L2 级云原生应用特征——一键安装
借助于 Rainbond 提供的应用发布能力，我们可以将运行在平台上的企业应用一键发布为一个应用模版。我们对应用模版最殷切的期待，是可以将这个应用模版以最简单的操作方式、尽可能少的人为调试即可安装成为一个应用。
实现一键升级
为了适应最终用户的需求，我们需要不断迭代自己的产品，并在生产环境中持续升级我们的业务系统。Rainbond 基于应用模板的版本实现了一键升级的能力，这个功能对我们非常有用，我们只需要提供更高版本的应用模板离线包，好雨科技交付团队就可以帮我们在最终生产环境中一键升级整套业务系统。
tip
L2 级云原生应用特征——一键升级
Rainbond 的应用商店机制支持基于应用模板的版本对已安装的应用进行升级操作。平台的升级机制解决了服务组件版本、配置、依赖关系等绝大部份属性的版本管理问题。尚需应用开发人员关注的问题在于数据的版本管理。
最终效果
应用完成改造后，通过 Rainbond 可以查看我们产品的拓扑图和依赖关系。
在实际项目当中，我们产品流转了三个环境：
开发环境：我们在公司内部，使用开源版本的 Rainbond 在公司服务器上搭建了开发测试环境，我们开发团队通过源码构建，很快将业务系统搬上了 Rainbond。通过一段时间的测试和迭代，我们拿出了首个版本的应用模板，并使用离线导出功能导出了离线包。
准入测试环境：利用光盘等介质，仅需一个工程师将离线包导入了最终客户提供的私有云准入测试环境，导入后产品一键安装。对于客户反馈的意见，我们在开发环境中导出新的离线包，并再次导入了准入测试环境，进行了一键升级，经过多次迭代最终达到客户的准入要求。
生产环境：最终生产环境是完全由客户管理，我们仅需要提供经过准入的应用模板离线包以及必要的文档，客户就可以非常快速的将我们的产品完成部署和升级。
相对于以前的交付方式和流程，接入 Rainbond 体系给我们带来了这些更好的交付体验：
- 更便捷的交付方式：交付物只是离线包，不需要关心客户复杂的运行环境。
- 更低的交付成本：无论从时间还是人力的角度，交付成本都极大的降低了。
- 应用运维过程自动化：云原生技术切实的提升了业务系统的各项能力，可用性、容错性以及应对流量陡增时动态的伸缩能力。
最终仅用一个星期，我们就完成了各个业务系统的云原生改造工作，并测试通过云原生应用标准规范认证 L2 级。之前项目交付过程中交付难、维护难的问题，是我们最大的隐形成本，客户只会看最终交付效果，并不会为交付过程而买单。
做了云原生改造后，之前需要派驻交付团队 1 个星期才能交付完的项目，现在一个基础的运维工程师刻盘过去安装，1 小时就可以搞定。并且用户可以通过 Rainbond 的可视化界面快速上手掌握，95%的运维问题都可以自行解决，或者远程指导客户操作。
什么是云原生应用标准规范认证？
「云原生应用标准规范认证」为软件厂商的应用交付过程中的便利性、交付客户后的可维护性、以及必要时的可迁移性等需求，提供可信赖的技术背书。现阶段，「云原生应用标准规范认证」分为 L1、L2、L3 级，在应用交付及交付管理发挥重要作用。
- L1 关注：应用跨环境交付后的一键安装和自动化运维。如高可用、可伸缩性、可观测性等，提升最终客户的可维护性，降低客户的学习成本。
- L2 在 L1 基础之上关注：应用跨环境交付后的一键升级。如全量/增量升级、版本回滚等，满足客户小步快跑的持续迭代交付需求。
- L3 在 L2 基础之上点关注：应用跨环境交付后的一键备份迁移。如包含完整数据的打包备份、可迁移性等，帮助客户实现整体生产环境的迁移、灾备