千亿级eBay平台的Kafka深度实践(2)

当然不是,其实 Kafka 提供的是单元功能,作为企业应用来讲,你要做企业实时传输平台解决方案,需要基于 Kafka 做很多额外服务,每个企业总归该是有一些自身需求,比如企业对安全考虑,每个企业实现方式不一样,企业数据中心分布也是不一样,对于不同企业自身的需求,我们需要做一些额外服务支持它.

eBay 做了哪些服务呢?举一些很简单的例子,比如我们想让一个用户在集群上创建他自己的 Kafka ?topic,你不是直接让他到一个节点上,这显然是不够安全,同时也不够方便.

这样我们必然要有一个提供管理功能的服务器,我们希望提供一个统一的入口,以及统一的 topic 名称空间,那么我们就需要引入原数据中心的服务.

比如我们在上海、北京都有数据中心.我们怎么把数据从上海迁到北京,这时候就需要有数据镜像服务.

再比如我们刚刚讲到,整个 Kafka 集群是在 openstack 云上面,当我们需要建立一个新集群的时候,或者一片集群需要修复,或者为这个集群需要新增节点,或者废弃节点的时候.

我们需要怎样调用 openstack 功能完成?同时我们还有很多监控功能的服务,系统日志服务.

我们都是把所有服务通过界面形式暴露出来,同时把它的下端用户直接到界面上做一些事情,不用非要找到系统管理员才能做,他们可以自己直接做.

2、eBay平台核心服务

以上是我们这个系统拥有的一些服务,下面我会就这个系统里面的服务做稍微详细一点的介绍.

2.1 元数据服务的目的

首先是元数据服务,为什么要提出元数据服务,因为我们希望给大家逻辑上提供一个统一的 topic 名称空间,比如我希望访问到用户行为数据,如果我们没有这个服务的话,我必须要让用户知道你的用户行为的 Kafka 集群在哪里,还要知道你连到哪一个.

然后 topic 名称是什么?比如我们从服务里面直接查询一个用户行为,你直接找到这个 topic,服务后面会找到真正的 Kafka 集群在哪里,然后再返回给客户端,让它连上来.

除了提供统一名称空间之外,我们还提出了叫做 topic 分装的概念,为什么会有这种东西呢?

因为我们刚才说到自服务,我们希望用户自己创建,如果说让它无限制创建的话,对系统资源肯定是伤害,因为它不知道你有多少资源还在那边,如果他创建太多了,会把 Kafka 集群宕掉.

这时候就需要有配额管理,我们这边引入的单位就是 topic 组,我们创建 topic 的时候需要系统管理员做审批.

一旦审批通过了,我会给 topic 组分配一些配额,比如我在上面创建多少 topic,在上面发生的网络带宽是多少都可以配置.所以这个也是便于后面的运维管理.

2.2 元数据服务

刚才我说了这些,都是要由元数据服务提供,那元数据服务怎么工作的呢?

在 Kafka 集群里,你不可能用这些集群本身所带的管理 topic 去管理元数据,所以我必须要有元数据存储.

2.3 ?Kafka代理

我们引入了逻辑层对三十多个集群看起来就像一个集群,在这种情况下,用户是不是在使用 Kafka API 的时候有问题,因为 API 并不能知道你要用哪一个.

我们看这个 Kafka 代理完全实现了 Kafka 的协议,这个协议定义了很多操作,这些操作是基于 TCP 层的.

我们去这样一个代理,可以完全模拟 Kafka 本身 group 的协议.对于客户端来说,是可以用原本 Kafka 的 API 访问,这个 API 连接代理就像连接到单独的 Kafka 集群一样,这其实不是一个真正的 Kafka 集群,而是后面带了三个 Kafka 集群.

2.4 Tier-Aggregation模式和数据镜像服务

下面讲一下我们镜像服务,其实我们有多个数据中心,Kafka 数据来源本身也是来自数据中心.那么我们大家怎样搭建 Kafka 集群呢?

这里我们有一个模式 Tier—Aggregation,比如上海和北京都有用户行为.我们希望做数据分析的时候,要能够同时分析到上海、北京的数据,我需要把两个地区的数据 run 起来.

比如我们只有两个数据中心,我们创建四个 Kafka 集群,其中有两个 location 的数据.

我们同时也做到跨数据中心的数据冗余,比如北京数据中心烧掉了,我们上海数据中心依然可以把所有数据拿出来.

这个其实最是也是由 LinkedIn 提出的比较推荐的方式,虽然引入了很多数据冗余,但是它保证了它的运行.

因为 Kafka 本身有自己的 location,每个数据来了以后会引起三份网络流量,这个网络流量是为了让 Kafka 集群高可用.

如果 Kafka 集群跨数据中心的话,所谓的网络流量就会是跨数据中心,我们怎么把数据一个数据中心传输到另一个数据中心,这就是需要用到镜像服务.

镜像服务这方面其实我们会有很多管理,比如我多少开多少节点,多少线程,怎么启动,怎么截止,所有管理工作我们都需要有具体服务做这样的事情,也就是我们所说的镜像服务,要实现具体的服务,但是它暴露出一个服务器,让上层应用再去做数据镜像的管理.

3.5 Schema注册服务

除此之外我们还有 Schema 注册服务,对于普通平台来讲,所有经过平台的数据都是可以进行管理的,我要求数据格式所有人都认识,所以我们定义了统一数据模式在平台里.

Kafka 本身提供了 Schema 组件,背后用 Kafka 做存储,而且高可用也做到了,我们是直接把它拿过来用,但是没有百分百拿过来用.

因为它有一定的局限性,比如它不支持健全,所有人都可以来改,所有人都可以进行版本增加.

2.6 用户自服务

刚才所讲的服务,不管是对用户来讲,还是管理员来讲,我们都需要有一个界面操作它,因为不可能所有人都通过 SSH 去连服务器.

所以我们有一个用户自服务 portal,从 consumer 注册,producer 注册,topicgroup 注册,schema 的注册.

刚才说到了要创建一个集群,对集群地面的一些节点进行替换,我们要新增新的节点等等,我们都需要调 openstack 的功能,但是这个地方我们需要一个很迷你的 PaaS 完成这个系统.

我们其实是基于 openstack 搭建了一个小的迷你 PaaS,除了提供功能工作流之外,还提供的运行工作流管理的功能.

（编辑：ASP站长网）