关于云原生-cloud-native:柯基数据通过Rainbond完成云原生改造实现离线持续交付客户

57次阅读

共计 5251 个字符,预计需要花费 14 分钟才能阅读完成。

​1. 对于柯基数据

南京柯基数据科技有限公司成立于 2015 年,提供一站式全生命周期常识图谱构建和运维、智能应用服务,致力于“链接海量数据,从大数据中开掘智慧“。帮忙企业使用常识图谱技术打造世界领先的认知工作自动化智能引擎。

目前在药企、医疗机构、军工院所、科技情报及出版等畛域服务了数十家大客户,积攒了丰盛的行业常识图谱使用开发教训。典型客户有国防科技大学、中国航空、中国电科等。

2. 柯基数据的云原生之路

大家好,我是南京柯基数据的解决方案架构师刘占峰,云原生技术在交付运维上的劣势让我获益匪浅。作为我的项目合作伙伴,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

批改了这两个参数后,共享存储的性能失去了显著的晋升,令人摸不到头脑的内核报警信息也随之隐没。开发测试环境终于能够顺畅应用了。

接下来面临新的挑战是如何将咱们的多套业务零碎顺利迁徙到 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 的利用商店机制反对基于利用模板的版本对已装置的利用进行降级操作。平台的降级机制解决了服务组件版本、配置、依赖关系等绝大部份属性的版本治理问题。尚需利用开发人员关注的问题在于数据的版本治理。

3. 最终成果

利用实现革新后,通过 Rainbond 能够查看咱们产品的拓扑图和依赖关系。

在理论我的项目当中,咱们产品流转了三个环境:

开发环境:咱们在公司外部,应用开源版本的 Rainbond 在公司服务器上搭建了开发测试环境,咱们开发团队通过源码构建,很快将业务零碎搬上了 Rainbond。通过一段时间的测试和迭代,咱们拿出了首个版本的利用模板,并应用离线导出性能导出了离线包。

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

生产环境:最终生产环境是齐全由客户治理,咱们仅须要提供通过准入的利用模板离线包以及必要的文档,客户就能够十分疾速的将咱们的产品实现部署和降级。

绝对于以前的交付形式和流程,接入 Rainbond 体系给咱们带来了这些更好的交付体验:

  • 更便捷的交付形式:交付物只是离线包,不须要关怀客户简单的运行环境。
  • 更低的交付老本:无论从工夫还是人力的角度,交付老本都极大的升高了。
  • 利用运维过程自动化:云原生技术切实的晋升了业务零碎的各项能力,可用性、容错性以及应答流量陡增时动静的伸缩能力。

最终仅用一个星期,咱们就实现了各个业务零碎的云原生革新工作,并测试通过云原生利用标准规范认证 L2 级。之前我的项目交付过程中交付难、保护难的问题,是咱们最大的隐形老本,客户只会看最终交付成果,并不会为交付过程而买单。

做了云原生革新后,之前须要派驻交付团队 1 个星期能力交付完的我的项目,当初一个根底的运维工程师刻盘过来装置,1 小时就能够搞定。并且用户能够通过 Rainbond 的可视化界面疾速上手把握,95% 的运维问题都能够自行解决,或者近程领导客户操作。

4. 什么是云原生利用标准规范认证?

「云原生利用标准规范认证」为软件厂商的利用交付过程中的便利性、交付客户后的可维护性、以及必要时的可迁移性等需要,提供可信赖的技术背书。现阶段,「云原生利用标准规范认证」分为 L1、L2、L3 级,在利用交付及交付治理施展重要作用。

  • L1 关注:利用跨环境交付后的一键装置和自动化运维。如高可用、可伸缩性、可观测性等,晋升最终客户的可维护性,升高客户的学习老本。
  • L2 在 L1 根底之上关注:利用跨环境交付后的一键降级。如全量 / 增量降级、版本回滚等,满足客户小步快跑的继续迭代交付需要。
  • L3 在 L2 根底之上点关注:利用跨环境交付后的一键备份迁徙。如蕴含残缺数据的打包备份、可迁移性等,帮忙客户实现整体生产环境的迁徙、灾备。

5. 对于 Rainbond

Rainbond 作为开源的云原生利用治理平台,是「云原生利用标准规范」落地施行的最佳工具。

https://www.rainbond.com

https://github.com/goodrain/rainbond

正文完
 0