白瑜庆：知乎基于Kubernetes的kafka平台的设计和实现

欢迎你们前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

  本文首发在云+社区，未经许可，不得转载。

自我介绍

我是知乎的技术中台工程师，如今是负责知乎的存储相关组件。个人分享主要基于三个，一个是简单介绍一下Kafka在知乎是的应用，另一个是为何作基于Kubernetes的Kafka平台，还有咱们如何去实现了基于Kubernetes平台

Kafka在知乎的应用

Kafka一个是很是优秀的，消息或者是数据流的组件，在知乎承载了日志，数据收集，消息队列的服务日志，显而易见就包括业务，包括运行的DEBUG日志关键性日志。

数据传输，好比咱们在浏览知乎的时候，有些用户行为或者内容特征，经过咱们这个平台作数据的流失处理。

另一个是Kafka实现对消息服务。简单地，就是我关注的A用户，我是否是应该基于关注用户行为上作不少事情，这是一个消息队列的服务。咱们那个平台如今是部署超过有40个Kafka集群，这些集群都是独立的。另外上面有超过一千个topic，咱们的Broker数有超过有两千个Kafka。平台从上线到如今已经运行有两年了，承载的数据量都是百TB级的，咱们如今这个设计是Kafka集群，咱们要实现多集群。由于是对于公司内部的平台，咱们要保证高可用，平台架构底层实际上是广大Broker管理员，上层是抽象出来的。Kafka的集群对业务其实也无感，。另外就是一个管理平台管理，我建立topic，去建立分区，或者作故障处理。第一，上层只可能有管理平台和客户端是对R业务有感，客户端咱们要对客户端进行收敛，有一个客户端是原生支持的——Java。不一样客端会有不一样的表现，如今咱们须要去收敛这个词，

为何采用Kubernetes？

由于咱们遇到的问题在早期的时候，知乎的Kafka是一个单集群，在你们使用率不高，或者在数据量增加不爆炸的时候，单集群你们用得还OK时有天发现有一个Broker挂了，等到你们都挂了，这时候才发现实际上是一条路是不能够常走的。所以咱们以为咱们认为集群和大型社科系统单点，你们会依赖集权，无论任何的业务，我写日志也好，发消息也好，或者我去作数据传输也好，这是不能够的。对于Kafka来，咱们有一个开发，有各国的Top的概念，其实发生到业务来，每一个topic都表明了不一样的一个业务的场景，咱们以为对业务场景在内部要作分级，好比我重要的数据，我要作分析，咱们的业务与Kafka的深耦合。当我先作了规划，去梳理一下发现为何我会这么多，它topic为何集中挂掉以后有人还没事，还很是的愤怒，以为简单就是天灾。

那时候咱们发现，其实咱们的日志里面topic有不少类型，抽样出来，一种是日志，一种是数据和消息。数据，好比在作一个离线计算的时候，收集了用户数据或者我在APP里有埋点，这些数据能够经过开发管道或者spa或者咱们的计算任务。另一个是消息刚才也提到，好比我用户去作了一次关注或者点赞，触发后面一系列处理流程，很显然看出他们实际上是有分级的。咱们要把Kafka集群在内部要作成多集群的方式，然而根据咱们套配合作出划分。

同类型的topic作不一样集群的管理和配置。其实最简单的法是Kafka有分片，咱们是作高可用，日志的分片能够少。消息容量是小的，对于数据你们都作，好比用Kafka作数据分析，确定知道在离线技术，在数据分析时候看一下数据量是跟在线的时候应该是千倍万倍的这种关系，那就会出现一个问题——咱们去规划一个设计就去实施的，最后结果咱们的需求会变的很是多，好比一个A业务，我认为很是的重要，去作一个可是承载了一个，我天天有几百几十T的数据，那我是否是能够申请一个新的Broker。新的集群，别人不要跟我掺到一块儿，我提供的是基础数据，这样的话咱们遇到问题是集群会愈来愈多，事实上如今不少已是超过四十亿四十个了。服务器资源怎么去使用？由于早期部署的时候确定单机部署，但又不是，好比我有一个普通的，好比我作了一个G，承载的数量有四个T，这样的话我部署一个消息任务是否是有点浪费？那不数数任务它是有点就太过小，其实咱们提供一个提升资源利用率，但愿从单机上部署更多的Broker，而且可以作到它们之间的相互的影响降到最低。实际上在咱们实验实践中，磁盘实际上是Kafka一个绕不开的问题。

首先磁盘不能够作数据持久化，可是咱们遇到了不少的问题，有量突增的或者流量大的时候，磁盘首先容量会有问题，好比我有申请了1T的磁盘，那可能我如今写一天给我写两天就已经写到了3T。

另一个问题就是磁盘的LUTOC其实IOPS太高这种问题出现的话，开发的性能是有很大的降低的。既然Broker能够作到多部署，那咱们就在磁盘层面上作隔离，先在保证这种不要互相影响，就是好比数据和消息，Broker在磁盘这个层面要作好，作到互相不影响，所以咱们想到的方法就是磁盘是否是能够分开，在物理层面就分开，而且开它自己又有副本。

这种物理存在分开是能够接受的，并且若是出现故障，彻底是在可控范围以内的，而是可期的。所以我以为把分开，咱们当时选服务器，正好黑石这边也提供了一种叫高性能的服务器，其实很是知足咱们需求，它有12个高性能的磁盘，是单盘的，他不作瑞的，每一个盘就是容量还不小。它的CPU和内存上面其实有优点的，由于Kafka是对内存是有要求的，好比走的文件缓存，内存是知足我需求的CPU，如今英特尔的CPU性能还蛮。咱们就采用了黑色这款高性能服务器，如今咱们的平台都主要部署在这种服务器。底层的服务器想好了，资源划分想好了，就是怎么去管理它？

咱们先讲一个有意思的，咱们平台以前有一个开发的管理平台是自写自演的，实现了部署Broker，包括渲染配置，去作迁移的，这个平台比较私有，并且在运维上面或者管理上面不是很方便，并且观众很高兴来同事都要从代码层面学习，从那一套咱们的平台学习影响，或者是有一个更好的方案来去解决。若是激情数增长到了保证的不可数增长，而且是服务器若是坏掉了，你看咱们如何感染管理他，调度的时候咱们如何去考虑到按照磁盘这个维度作调度。所以咱们想到QQ那铁丝，由于以前咱们有不少的一个在容器化方面的实践，早期在开发上QQ来此以前其实知乎在ks上部署了不少计算任务，在这上面有不少积累，因此咱们想利用它的管理功能和容器的技术进行资源管理。另一个是应用程序管理。

Kafka on Kubernetes

首先解决问题设计Kafka容器，无非就是四个问题——内存，CPU，网络和存储。另一个问题是咱们怎么实现具体调度Kafka容器。

首先是内存和CPU。其实CPU是比较难以预估的，由于根据咨询类型不一样，对于内存和CPU消耗是不一样的，Kafka自己是不强，依赖于CPU。可是在实际使用中仍是有些问题的，好比我们Kafka不是作批量，但不少时候有时候你们对它比较理解得透的时候，会把批量会得很小，好比我下降延迟，要保证每一条消息都确切的投放过去，把Brokers收得很小，这时候会形成一个什么问题？CPU会高，可是很这种问题咱们能够经过调高CPU来解决。若是不出现这种大流量的话，通常内存是不会超过八个G的，并且通常使用会更低，因此咱们的基准的容器会设置成8G根据实际使用时间长，常常会作调整，这个调整能够在IT市场很容易改。

另外网络方面就是咱们对外服务，采用的是一种独立的内网ip方式，好比我每个Broker都有一个独立的ip，实际上由于咱们的单机上会部署不少容器，因此每一个都有IP，而且将这个ip注册在内网DNS上面，这样照好处是对于使用者来讲，不须要知道具体容器的ip。这个是网络又有一个很好的方式——能够作单机的多ip网络设计，至少能够知足咱们的需求，这是容器方面的设计。默认支持的磁盘的挂载方式是HostParh Volume，这种方式是最优的，由于Kafka在本地磁盘性能最好的，并且可以充分利用到本地的这种高效的文件缓存，咱们自己的磁盘性能也是很是棒的，至少我能够知足个人需求。

所以咱们就应该是本地的目录一个cosplay，也就到K2起来以后是给他的，请求的配置挂载到服务器的磁盘，黑色框是咱们的一个容器，开发目录指向的蓝色框是服务器上的一个磁盘或者服务器上的目录。虽然咱们的集群看来就是这个样子的，每个方块表明网上有不少的部署的Broker。业务上面能够反过来看，每一个蓝色的地方表明Broker。

第一，CPU和内存并非问题，网络其实已过测试过的，服务器网络是二世纪的20G带宽，每一个盘咱们通过测试，是有一点几个G性能，即使把每一个盘全部人都跑满，其实这是灾难状况，他只有不会超过20个G，所以咱们不在考虑范围以内，咱们考虑的是磁盘的高可用目标，让单个集群的Broker在节点要尽可能作到分散。

第二是节点上的存储使用尽可能均匀。

算法是根据服务器磁盘状态计算分数，分数高者被调度。另外就是磁盘的使用状况，若是有更多的可用盘，咱们倾向于把Broker挂在了上面。其实它用了一个简单的方式，假设建立一个红色集群，实际上A和C均可以，但C是最优的，由于C上面的Broker数比较少。若是要建立一个蓝色集群，那显然是A是最优的。另外，在实际使用状况下要更复杂，由于得考虑到分片的高可用。按照算法去实现会遇到了一个实际性的问题——用HostPat是有很大局限性，一致性很差，好比须要去管理要调度的节点，由于若是用class的话须要去注册一个自己选择的word，或者其实我是不知道被调到哪一个节点上。另外主机上要去挂载的目录实际上是没有人管理的。这是咱们遇到的问题，当时咱们但愿是既要利用到HostPath，只有挂在本地的磁盘这种特性来提升咱们的性能管理。

并且我要可以选出合理节点，而且可以管理到这个存储。所以咱们在当时对Kubernetes作改造，实现磁盘和调度器的算法，能够实现实时更新磁盘信息。可是实现方式是经过假设建立实例.

本地磁盘管理

若是Broker已经在设备上创建起来，磁盘也被用了，那如何去管理它？事实上磁盘管理只能进入第三方的Agent。

故障处理和提高资源利用时会预留空间，好比为了快速处理故障不作签署，首先就是成本过高，如今作的是快速恢复，所以咱们会预留1到2个盘，即快速处理盘，所以只要把软件指向这个容器，就能够立刻启用，而且不会有太大的网络开销。另外就是在主机层面，即把分片在主机层面是作分开，作到高可用。

但咱们遇到一个问题——须要把客户端统一，由于技术平台化。那如何把客户端作到统一？咱们的看这里，客户端能够去读Consul信息，检查topic是否是有用。还有个好处是，若是作迁移的时候，由于事情使了不少方，生产和消费方式是不少的，并且通常流程是先于生产方，消费方就过来，你们可能有业务，可能你们若是按照这种注册方式的话，其实迁移过程是能够同步的。在这个地方更改信息，整个这个生产所生产的消费，均可以感觉到，就是另外就是易用性会提升。且用这种方式有好处是有一个集群好比我整个集群所有断掉了，虽然事没发生过，可是做为一个备用的方式的话，咱们会有一个灾备集群把全部的客户端均可以直接迁移过去。

Q/A

Q: 你好，麻烦问一下,一个集群里面可能有不少topic，不一样的用户消费topic的时候，用户之间是怎么隔离的？会不会消费到其余的topic数据？想问一下有没有什么隔离的好的办法？你一个集群里有多少套？集群里有多个topic，数据我就不想让别人看到吗？固然我若是提供一个客户端给他，他就能把全部的数据看获得，有没有什么好的办法？

A：实际上是这样的，就是在咱们的一个状况称，若是这个进群它有多少Broker，假如在这个会相互影响，咱们仍是建议把它不是相互影响，由于集群面不可能只给一个用户只提供一个集群，就是咱们一个大的集群，会有不少用户在使用他的数据，都是不一样的topic进来的吗？他消费的时候若是我没有隔离的话，我只要给他客户端，它全部的数据都看获得吗？只能经过我在前面去作提供什么API服务来这种方式，有没有？Kafka自己有没有什么好的办法去自己应该是有认证。 

了解更多详情，请戳下面的连接：

知乎基于Kubernetes的Kafka平台的设计和实现.pdf

问答
apache kafka vs apache storm如何使用？
相关阅读
陈新宇：CKafka在人脸识别PASS中的应用
杨原：腾讯云Kafka自动化运营实践
饶军：Apache Kafka的过去，如今，和将来

此文已由做者受权腾讯云+社区发布，原文连接：https://cloud.tencent.com/developer/article/1114620?fromSource=waitui