亲宝软件园·资讯

展开

Rainbond部署组件Statefulse官方文档

官方文档 人气:0

前言

对于kubernetes老玩家而言,StatefulSet这种资源类型并不陌生。对于很多有状态服务而言,都可以使用 StatefulSet 这种资源类型来部署。那么问题来了:挖掘机技术哪家强?额,不对。

如何在 Rainbond 使用 StatefulSet 资源类型来部署服务呢?

组件部署类型

通过在服务组件的其他设置中,更改 组件部署类型 即可选择使用 StatefulSet 资源类型部署服务,操作之前要注意以下几点:

Rainbond 默认提供四种组件部署类型:

当你在 Rainbond 中将组件部署类型指定为有状态 (StatefulSet) 之后,服务组件将体现以下特性:

整体来看,利用 StatefulSet 资源类型来部署服务,带来了新的特性的同时,会显得呆板了一些,但接下来的探讨,会发现这些限制是有意义的。

细心如你一定会发现,我们将 StatefulSet 这种资源类型和 “有状态” 绑定在了一起。那么,一个新的问题冒了出来:什么是服务的 “状态”。

服务的“状态”

有状态(Stateful)服务 = 无状态(Stateless)的应用程序 + 有状态的数据

从有状态服务的名字就可以看出, 它和 StatefulSet 这种资源类型是有关联的。

单纯说概念,可能很难理解什么是有状态服务。让我来举几个例子:

对于常见数据库 Mysql 而言,同一份数据,在同一时刻只可以被一个 Mysql 程序使用。Mysql 在启动后,会在自己的数据目录下生成唯一的锁文件,并把这个文件“锁死”。这样一来,其他想要使用这份数据的 Mysql 程序,会因为发现这个锁文件被“锁死”,而中断启动的过程。这样做的好处,是保证了数据的强一致性,因为同一份数据在同一时刻,绝对只会被同一个 Mysql 应用程序所读写。

请回忆下 StatefulSet 资源类型带来的特性之一就是每个实例都会挂载独立的持久化存储,这样可以确保 Mysql 服务可以被扩展成多个实例运行起来,不会因为锁文件的原因被终止启动,但是因为彼此之间数据不共享,所以本质上实例之间没有什么关系。使用有状态单实例的方式运行 Mysql 看起来是最正确的选择。

情况类似的常见数据库中间件还有 Mongo、Postgresql、Redis、Etcd等。

这种粘性 Session 在某些情况下会保存在内存中,用来提供会话保持,本身也是一种数据。一旦将这种服务扩展多个实例,一旦访问到不正确的实例,那么就会因为找不到 Session 而丢失登陆态。在负载均衡中使用 IP Hash 算法进行流量的分发可以在某种程度上解决这个问题,来自同个 IP 的流量会被分发到指定的实例。但是我们更希望流量的分发是轮询的,这样可以确保每个实例的负载都是相近的,不会出现某个实例负载过高,而其他实例无所事事的情况。

这两种有状态服务场景,都向我们指出,对有状态服务而言,不同实例的数据是相互独立的。数据即“状态”。

相比较而言,无状态的服务就灵活很多。它们没有持久化数据,或者持久化数据支持共享。对于客户端而言,请求哪一个实例获得的返回都是一致的。这样的特性意味着可以随意扩展无状态服务的实例数量,灵活的应对流量。

使用云服务最大的好处之一,就是它提供的弹性和灵活性,在业务遭遇流量高峰时,可以快速扩展实例进行应对。从这个角度出发,我们希望服务都是 “无状态” 的。那么,一个新的问题冒了出来:我们可以去掉服务的 “状态”,使之变成无状态服务么?

处理服务的 “状态”

利用粘性 Session 保持登陆态的这类 Web 服务,其状态是可以被去掉的。

原理比较简单,把 Session 和 Web 应用程序剥离,存储到其他中间件中去即可,比如保存到Mysql、 Redis、Memcached等数据库中间件中去。市面上常见的 Web 框架都会支持这种功能,甚至把这种处理方式作为默认选项,因为这实在太棒了!

处理完的 Web 服务,就变成了无状态服务,可以任意扩展实例数量了。来自客户端的请求无论被分配到哪一个实例,其登陆态都到后端数据库中调取,返回正确的登陆态。在部署时,可以选择无状态多实例进行部署,即使用 Deployment 这种资源类型。

但是对于DB类的数据库中间件而言,其状态是不可以被随意去除的。

原因在于这类数据库中间件使用自己的机制来确保数据强一致性,就比如 Mysql 的锁文件机制,指定的实例只能去读写对应自己的那一份数据。对这一类有状态服务而言,每个实例独享一份持久化数据可以算作是必须的条件。并且随意扩展实例数量,会遭遇很多致命的问题:比如数据不一致,或者程序运行失败等等。这一类的有状态服务只能单点部署吗?

这些数据库中间件的出品厂商或者社区,也都很关注如何实现高可用方案,来解决上述的问题。甚至近些年推出的数据库中间件,在设计阶段就会被设计成分布式架构。比如 Etcd 对自己的定义就是:可靠的强一致性分布式键值数据库。其内部使用 Raft 协议进行实例间选举来明确统一的leader。而对于 Mysql 这样比较老牌的数据库中间件,也具备基于 Binlog 复制实现的主从集群方案。

所以针对这一类无法去除状态的服务而言,我们的思路与宗旨,就是遵循其自身支持的集群方案,来实现高可用以及实例数量扩展。

实际部署这些集群方案时,可以总结出,大多数集群方案需要满足以下条件:

回想一下 StatefulSet 资源类型的特性,它可以满足上述的所有条件,就是为了有状态服务而生的。所以这一类有状态服务,其组件部署类型无论如何要使用有状态单/多实例。

加载全部内容

相关教程
猜你喜欢
用户评论