杨原：腾讯云Kafka自动化运营实践

本文首发在腾讯云开发者社区，未经许可，不得转载。

下面我们有请腾讯云基础架构部高级工程师杨原给我们带来主题分享——腾讯云Kafka自动化运营实践。

各位来宾，下午好，我是腾讯技术架构部的工程师杨原，然后今天我给大家分享的题目是腾讯云Kafka自动化运营实践，我今天主要想跟大家分享一下，我们运营整个kafka项目的时候会遇到的一些问题。Kafka运营过程中遇到的一些问题，我们是怎么去解决这个问题的？以及我们怎么样根据解决问题的经验去做自动化运营的系统。

先给大家介绍一下，我们腾讯云的Kafka是基于Apache Kafka的高可扩展以及高吞吐的云端kafka服务。其实我们不需要用户去部署集群，我们封装的集群的细节，无需用户维护。另外，我们的kafka是 按实例售卖，用户只要购买了实例之后，他就可以直接使用我们kafka的所有功能，同时我们也为用户提供了多维度的监控。再者对用户来讲，我们支持动态升降实例配置，用户只要根据自己的需求，按照自己的需求去付费购买就OK了。最后我们腾讯的kafka是与大数据套件无缝打通的，还有打通云存储，使用起来非常方便。

从现在运营现状可以看到，我们日消息量达到了万亿条，总流量也达到了10PB的级别，单集群的峰值每分钟能达到达到十亿条，现在我们运营的Broker节点过千个，集群也达到数百个，我们现在付费实例超过千个，topic也有数千个。

面临哪些挑战

正是因为我们运营一个如此庞大的集群，我们面对的问题就会非常多。我把这些问题概括了为五类。

首先第一个，由于我们是一个云端的产品，我们面对客户肯定是不同的，多种多样的，那么用户使用的kafka版本也是多种多样的，解决用户不同版本的问题是我们需要首先考虑的，第二是由于我们是一个云端的版本，我们是按照一个实例去售卖的，我们的实例怎么样分配在我们云端的所有节点上，才能保证我们一个资源的合理利用率，降低成本。再者我们如何实现用户之间实例升降配的需求？因为用户在使用的过程中，往往初期是买一个测试实例，也就是一个最低的版本，测试成功后，用户会把实例升级成一个生产环境的实例版本规格，最后我们在运营整个节点和整个集群的时候，什么时候需要处理一个节点的加入或移除。最后讲讲我们对于一个分区的创建，新增分区的时候，我们会基于哪些维度去考虑他这几个操作。

用户不同版本的选择

首先讲我们不同版本的选择，这个问题从我们kafka云端运营讲起，起初kafka运营的时候，我们发现这么一个问题，今天可能老王使用，他说他使用了卡夫卡使用的是0.9版本，而第二天老张使用的kafka版本可能就变成0.10了，这时候我们要怎么解决这个问题呢？我们其中一种解决方案，就是我们在后端部署多个版本的集群，这样的话如果老王接入的时候，我们把他的实例分布在0.9的集群，老张接入的时候，我们把他分布在一个0.10的集群。但是这样做有一个问题，用户接入我们云端的kafka的时候，我们就需要知道它是什么版本，这样我们才能将它实力分布到对应的集群上，那么无疑是大大增加了我们客户接入的代价。

其实对于这样的不同版本的集训，因为我们每一个节点有一个版本号特性是这样，我们运维起来也会增加运维成本，因为每个节点不能对所有集群透明，于是我们怎么解决这个问题呢？我们改造了kafka生产的底层，首先我们底层会进入多个版本的消息格式，同时在于不同消息格式之间，我们会支持格式的转换，这样用户接入kafka的时候，我们就无需知道这个用户使用的什么版本，因为对于他来讲，我们集训都是统一透明的。

实例选择合适的Broker

下边讲讲我们在实例创建的时候是如何选择一个合适的Broker。先讲我们现在云中的kafka，我们云端的kafka现在是按照一个磁盘根带宽流量两个维度去进行售卖的。我们每售卖一个资源，就会在相应的机器上扣除需要的服务能力。打个比方说我们现在有一个实例，它服务能力是300兆的带宽跟500GB的磁盘，假设我们现在有候选节点如下，broker1/broker2/broker3，可以看到他们剩余的带宽跟磁盘容量资源都是不一样的。假设我们现在把实例的容量服务能力分配到我们的节点，大家可以发现我们剩余的带宽剩余为0，但是我们还剩下了500GB的磁盘服务能力，这时候会造成什么情况呢？就是说我们剩余这500GB的磁盘服务能力是无法售卖的，因为已经没有带宽，所以我们不能把一个实例的服务能力再分配到这之上，于是我们采用了一个方法去解决这一问题。

如何保证最大的资源利用率呢？我们采用一个类似装箱算法的方式，把这些实例全按照权值计算出合理的方案分配到上面。首先带宽售卖和磁盘售卖，我们希望尽力保持在在1：1的比例，比方说这个节点上，我们带宽卖了50%，我们也希望磁盘售卖50%。这样这样就可以尽可能的避免带宽跟磁盘的售卖不均。

我们还有一个奖惩机制，当一个实例分配到该节点上之后，它剩余的资源如果不足以满足我们下一个最小实例的售卖的时候，我们会进行计算并进行降权处理，尽力不让这个分配发生。如果说我们一个分配完成之后，剩余的资源恰好满足一个最好实例的话，我们可能会进行一个尝试，因为这属于一种理想情况，其余时候我们就会按照它的带宽跟磁盘的售卖比去计算，计算权值越大，我们就其更倾向于分配到这个节点上。通过这种算法之后，我们发现整个技术群里面的资源利用率是有百分之十几的提高的。

实例的升配

接下来讲讲在用户使用的过程中出现的情况。用户开始会买一个比较小的实例，因为用户一般会先做一个功能性测试，当满足它功能性测试之后，用户可能会升级实例，做一个满足生产环境测试的规格。做这种实例升级的时候，我们又会遇到了两种情况。第一种是他所在的节点也就是实例所分配的节点，剩余的资源满足这一次实例变更需要的服务能力，比如他现在需要升级100G和100M的带宽，这个节点上有足够资源，那么直接升级就好了，这个是最简单的。第二种情况是当broker资源不够的时候，我们怎么样将实例的服务能力扩展到其他机器上，以满足这个升级的要求。大家可以看到，假设我们现在有一个实力占据了三个节点，分别是300M和1.5T的服务实例。假设我们现在需要升级，我们发现节点一节点二剩余的资源都满足这一次升级的要求，但是节点三不够了，这时候我们要怎么办呢？实例服务能力的迁移我们有多种方式，我们可能会考虑把3T换一个新的节点，没有用这么多的节点完成一个实例升级和扩展，或者我们会把这三个节点的服务能力扩展到更多的机器上，比如说扩展了四个，这时候可能每个机器上的需要的能力就相对减少了，可以看到它只需要75M带宽跟375GB的磁盘服务能力。当有多种的变更方法之后，我们需要知道我们把它扩展到哪些节点上，这就使用到刚刚提到的资源售卖的公式，我们会选择一个合适的机器去保证实例升级，不会影响后续的资源利用率。

那么计算完我们所有的变更方案中，我们需要计算一下它迁移代价，大家可以看到不同的迁移方案迁移代价是不一样的，我们现在迁移代价基本考虑的是一个partition磁盘的占有量，也就是迁移的时候，它会将实例所占据的broker上的partition进行迁移，那么迁移的时候最致命的是什么？如果它数据量非常大的话，迁移时间又非常长，可能会不可控，所以我们会选择迁移量最小的一个方案去进行迁移。迁移完毕之后，我们就可以满足刚刚所说的它实力升降配的需求了。

接下来讲讲我们运营这么大集群之后，什么时候进行节点的加入跟移除？先讲讲我们新增节点，当我们一个资源池里面资源不足以售卖，或者不足以一个实例进行升降的时候，我们会增加节点进行实例迁移，或者增加准数增加资源，为了实例后续的售卖，这种情况下，我们必须需要新增几点。第二点就是说我们节点资源碎片整理，即使我们采用了一个像类似创伤算法的方式去分配实例，资源的浪费是不可避免的。当我们节点资源有碎片的时候，我们可能会加入节点，然后把这些小碎片节点空闲出来进行下一次的售卖。

最后一点是当我们需要机器负载均衡的时候，我们可能也会添加节点，当你发现一个集群里面每个机器都处于比较高负载的状态，高负载是大家自己定义的，比如CPU利用到60%这种情况下，你认为它是一个高负载状态，这时候也可以考虑通过添加一个节点这种方式，将现有的服务迁移到这些空闲的节点上，来达到整个集群处于一个相对负载均衡的状态，一个比较健康比较理想的状态。

那么当节点增加之后，我们什么时候会移除节点呢？首先第一点是当一个实例收缩的时候，我们可能会移除我们的节点实例。刚刚讲到了一个实例扩容，可能某些用户扩容之后，发现生产环境的需要的实例又不需要很大，而我们刚刚也讲了，我们扩容的时候有些方案是需要给他扩容机器的，这时候可能在占用的节点方面做的比较多，它缩容之后我们可能只需要在部分节点上满足他这个服务需求，也就是同样也会将部分空闲机器进行一个下降。第二点是当节点故障的时候我们也会移除。节点故障的时候我们做的会更多，我们需要将故障节点上的时候，partition进行迁移为后续的服务。

分区的创建、新增和迁移

再讲讲我们的分区的创建，前面讲的所有情况下都离不开这一步，就是说分创建、新增和迁移是所有一切我们刚刚讲的迁移的基础。对我们来讲，我们会从整个partition的生命周期开始去管理partition，我们会首先选择partition应该创建在哪里，才能达到我们开始预设的负载均衡。第二点是当发生迁移的时候，我们应该把哪些partition迁移？为什么要迁移它？第三点是我们迁移的时候需要迁移多大的量，迁移多少partition才是合适的，才能达到我们的均衡或迁移的目的。最后我们知道这些partition从哪里来之后，我们需要知道他是去哪里。第二点就是说刚刚说到了一个实力的扩容，这种情况也是必须迁移的，因为我们需要满足用户的需求，最后这个负载均衡就不一定是属于要完成迁移的情况。因为即使机器处于一个比较高复杂状态下，它也能继续维持服务的状态。负载均衡对于我们每个用户和每个开发者理解来说是不一样的，高负载也是不一样的，考虑的维度也是不一样的，所以我们认为负载均衡的迁移不一定必须满足。然后讲讲刚刚说到了迁移分为两种方式，一种是leader的迁移，一种是replica迁移。它有两个特点，第一是迁移属于角色的转换，特点是无需进行数据迁移，没有数据迁移的代价，他只需要增加CP的负载以及网卡的出流量。因为迁移决策节点可能需要处理压缩，所以它会增加网卡输出流量。

最后我们讲讲迁移对象的和目的迁移对象是怎么选择的？首先迁移对象，我们会根据刚刚说到partition的数据大小，因为partition数据大小直接决定了我们整个迁移过程中消耗的时间，而且不可控除了数据大小之外，还有生产跟消费速率。我们先尽力去选择一些生产跟消费数据，对比较小的进行迁移，这样的话用户的感知相对小一点。同时如果它生产消费速率比较大，迁移的过程中，因为它流量非常大，可能会影响到我们节点上的其他用户，其他用户可能就会感知到这个是我们不希望发生的。最后迁移目的地，就是根据我们刚刚说的资源利用率去选择了，我们会尽力选择资源利用率比较高方案去进行迁移。迁移的时候我们会考虑以下两个因素，一个是实例的分布，我们希望一个集群一个下的实例，平均分布在服务的每一个节点上，这样来讲，从数量上我们能达到均衡。其次我们会考虑网络流量的均衡，比方说我们现在有一个实例，迁移之后我们希望paitition是20M的带宽，我们首先会排序，尽力将大的平台上小的部分组合起来，迁移到某一个节点上，这样的话我们就能尽力的保证在这里整个实例服务后端的这些节点处于流量相对均衡的状态。

讲一下我们replica又是按照哪两个维度去考虑。首先一个是资源利用率，刚刚也讲到了，我们云端的迁移可能会造成资源利用率浪费。首先每每一种迁移方式，我们都会考虑迁移到的新节点是否合理，迁移之后剩余的资源会不会影响后续的售卖？其次我们会考虑数据迁移的代价。我们希望这个迁移之后，每个节点上的replica是平均的，同时我们这个迁移的过程，我们不是一次将所有partition进行迁移，我们会将partition迁移拆分成每个小的任务让他逐步迁移，这样整个迁移过程中也是相对可控的，

未来展望

对于未来的展望，我们认为现在的管控自动调度系统，维度还是相对不足够的。我们刚刚也说了，我们会考虑replica跟leader的数量，同时进行负载均衡，但是其实后续我们希望能够根据更多的资源维度，比如CPU/MEN/IO这些维度去进行我们更多的负载经营决策的资源。

另外，现在我们发现在迁移一些比较大的实例情况下，执行时间是无法衡量的，同时我们也不知道这个任务究竟执行了这么久之后，他是成功还是异常的状态，是不是健康的。我们希望后续根据更多的维度，更好地衡量迁移时候的时间。希望我们后续能做到预测调度的功能，因为我们现在调度是基于已经发生的情况进行调度，也就是肯定已经遇到了问题，我们才会去调度，那么我们后续希望我们能做到根据集群或者节点的负载增长，提前去预判这个节点，这个集群是否需要增加节点，以达到资源后续的健康服务。

最后我们希望能提高资源利用率的使用。即使根据刚刚所说的算法去计算分配方式之后，还是会有不少的资源浪费的情况，后续会根据实际运营数据去更好训练这个模型。

Q/A

Q：你好，请问你们限制时限的时候是怎么做的？怎么保证他只用了这么多？

A：首先购买实例的时候，我们会有一个的流量控制的模块，然后每个broker在生产运营过程中，他会知道他所分配的定额，然后每次我们会有一个流量模块在broker里面，如果我们broker根据每秒钟生产的吞吐率扣除资源，我们有一个单独的流量控制中心，根据它实时的状态，比如说我们现在有三个节点，假设它购买的实例是某一个节点，他可能只占用了20M的资源，然后我们是能统计到每个节点上面的资源使用率，我们可能会将另外的资源分配在更多的节点上，以此来满足用户的流量总需求。如果它实际上吞吐率超过了网卡100M，那怎么办？假设现在超过了这个数值，kafka请求那里面有一个最大延时，我们就会把这个消息挂起来，把他的请求挂在我们的一个资源轮里面，等到延迟回复，这样的话他请求回复这样的账户，如果我们不回复，他即使再发过来，我们后面的服务会直接拒绝。

Q：你好，杨老师。请问售卖的部分是根据有带宽跟硬盘的大小，我没有看到像其他一些资源，比如说CPU内存好像是不受影响，而你说的这两个资源我们是会消耗的，但是首先是不是需要考虑它是一个高吞吐模型呢？

A：首先的带宽他肯定是占据了，比如说一个水管，我们一个网卡在这里，一个用户占据了这么多带宽资源之后，另外一个用户肯定会受损。消息保存时间固定的情况下，带宽越大，它磁盘容量也会变大。其实你想我问的问题就是说我们为什么不基于其他角度去考虑资源的购买，对吧？根据是当前我们一个运营情况来说，首先第一点CPU不是我们的情景，不是我们的瓶颈。第二点就是说我们的带宽和磁盘对于我们机型来讲相对吃紧一些，而且刚刚也说到了，为什么要根据这两个说，因为一个用户占据了这么多带宽，在他没用到的情况下，我们也会把这个带宽给留出来，那么就会直接影响了后续的售卖。也就是说我们现在根据这两个维度去售卖是根据我们实际运营情况决定的。

Q：你好，我想问一个问题，就是说死循环的话要一般多长时间可以发现？传送到大的文件什么时候发现？

A：首先我们每个任务会有初步的估值，比如说它传输的数据量，每个实例有一个宽带，刚刚说到了，我们会将这个数据量除以宽带值做一个初步的分析。同时在我们整个调度过程中，我们会把每个调度细分到小任务，每个partition单独去迁移，这样的话整个时间相对可控，同时我们管控系统在这种数据量迁移的过程中，我们可能会每小时或每一段时间提醒我们开发跟运维人员，如果发现一个任务持续时间很长了，其实常常是我们自己去界定，会自动报警，马上进行处理。报警后我们业务人员可能会介入。

更多分享资料，戳下面的链接：