使用日志服务LogHub替换Kafka

前几天有客户问到，云上有什么服务可以替换Kafka？

怀着程序员的一丝小小的骄傲回复：日志服务（原SLS）下LogHub功能可以完全替代Kafka等产品，并且在性能、易用性和稳定性上更佳。

但客户将信将疑，于是花了一天时间整理一篇文章，简单从各个角度解释下为何建议用户从自搭Kafka换成使用LogHub。

背景信息

Kafka是分布式消息系统，由Linkedin原员工Jay Kreps编写(感兴趣的可以参见这篇文章《The Log: What every software engineer should know about real-time data's unifying abstraction》，阐述了作者的思路)，随后开源到Apache。由于其高吞吐和水平扩展，被广泛使用于数据收集、发布和订阅。

日志服务(简称Log):是基于飞天构建针对日志平台化服务。提供日志实时收集、投递和查询功能。通过Restful API对外提供服务，其中LogHub功能可以完全替代Kafka。

除了这两款产品外，同类还有AWS Kinesis, Azure EventHub，属于两家巨头服务化Kafka的版本。

从用户角度考虑哪些问题

如果我是一个创业公司的工程师，我会关注如下几件事情（如果你爱折腾，那就另当别论了）：

使用成本

日志组件本身不直接创造价值，功能固定。因此要从维护、使用等最小角度考虑，让我们来看下有哪些成本:

阶段	自建Kafka成本	使用LogHub
采购服务器	以3份Copy计算，2核2G 100GB硬盘机器3台部署Zookeeper与Kafka, 大约500元/月	0
部署软件、配置参数(Logstash, Kafka, Fluentd)	软件工程师、运维工程师	0
线上当机运维	运维工程师	0
线上扩容、收缩	运维工程师	0
磁盘、机器上下线	运维工程师	0
占用机器资源成本	采集Agent是否会对主机带来影响，对比fluentd、logstash两个Agent	同样流量，CPU/MEM占用是logstash 1/10
线上Agent扩容	运维工程师调用脚本触发	API/ Web Console 10 秒搞定
线上Agent新增一种日志	运维工程师重新更新配置文件，灰度环境，线上所有Agent升级	API/ Web Console 10秒搞定
总成本	1.6 W/ Year	按需付费

假设一个工程师的年薪为20W，大约有1/20精力会在系统上。则成本为1W/Year。则一年的耗费为500*12+ 10000= 1.6W，相当于把服务搭起来什么都不做，一天50就花出去了，更不用说业务增长情况下带来的扩容与升级等变更。

稳定性

作为一个流处理系统，要保证Always Writable。因为有一些场景中（例如嵌入式设备）会把程序烧录到硬件中长时间运行，因此要使得收集服务端保障长时间可用。

可用性难点不在于正常状态下的表现，而是软件在各种异常状态下是否能表现依然优秀，我们考虑了如下常见的故障场景做了对比：

故障场景	Kafka表现	LogHub表现
硬盘损坏	可能丢失数据(需要手动复制）	正常
机器掉电	丢失数据	正常
机柜掉电	丢失数据	正常
机房掉电	丢失数据，无法服务	无法服务 (计划通过3AZ PAXOS解决）
进程Crash	有重复	正常
机器Reboot	有重复	正常
扩容	有重复	正常
某个用户流量暴增	其他用户不可用，日志丢失	正常
软件升级	可能重复，升级阶段短暂不可用	正常

从设计上，LogHub在RoundRobin写场景下能保证99.95%可用性，在通过KeyHash写场景下、以及读场景下提供99.9%可用性，最大程度保证服务对用户的稳定、可靠。

安全性

Kafka定位主要是软件，因此不具备安全相关的功能，会有如下风险：

• 在不做网络限制情况下，任何用户可以直接订阅Topic数据
• 无用户相关的隔离功能，例如业务系统有：操作日志、服务端请求日志、程序日志。无法限制每种日志只对某些用户可用
• 在日志收集过程中，会被sniffer
• 日志收集过程中，可以伪造日志写入

以下这张表是我们在安全相关场景下对两者对比结果：

安全场景	Kafka	LogHub
防篡改	无	支持
认证	无	支持多因子认证
访问控制	无	支持
临时访问	无	支持
子账号	无	支持
支持匿名	支持	支持
安全传输	无	支持

使用便捷性

使用起来是否方便，快速与现有系统集成，LogHub相关Kafka主要有3点：

1. LogHub所有管控与读写API是公开的，既可以从Web层快速接入，又能在之上包装用户的配管程序，最大程度提供自动化能力。
2. 提供原生Agent，对于不需要特别解析当行日志，1分钟以内完成接入。通过Web控制台及API可以轻松管理百万级别的机器。

3. 上下游与生态：Kafka对接了众多上下游系统，那LogHub呢？也不例外：

   • LogHub提供8种语言SDK，支持Syslog, Tracking Pixel等协议
   • 完美支持ECS各版本Linux、Windows，以及阿里云容器服务Docker等环境，可以通过脚本将OSS等日志打通
   • 除服务器外，今天用户通过SDK，客户端等方式已经在 x86，ARM等平台服务器、路由器、交换机等作为数据源也不是少数，几乎所有主流接入手段我们都支持
   • 在下游，我们和阿里云各存储以及计算类云产品无缝联通，即开即用

LogHub当前已支持上下游可以参见：

LogHub与kafka不同点

除刚才提到的点外，设计上两者有一些不同点：

提供Restful协议API

我们把数据收集与消费定位成服务，而Restful API就是服务最理想的访问方式。除此之外为了保证用户数据安全性，我们在如下层面对安全加强：

1. 提供HTTPS等传输机制，保障公网等恶劣环境下进行数据传输
2. 支持VPC环境，数据不外泄露
3. 与访问控制RAM集成，可以配置不同的策略
4. 传输过程签名，保证完整不被纂改

但HTTP是一种无状态协议，如何提供Kafka中ConsumerGroup高级状态语义？LogHub提供了Client Library以及完整的API，能够支持不同语言客户端实现ConsumerGroup行为，感兴趣可以参考LogHub Client Library这个实现。通过无状态协议实现了消费协同的语义。

半结构化数据模型

Kafka， AWS Kinesis中的管道被设计成无语义的，好处是简单。因为无论是什么对象，只要base64编码后都可以变成一个string，消费的时候只要把String拿出来，反序列化就可以使用。管道不提供语义，由用户维护。但副作用是什么？没办法与结构化的存储打通，需要用户参与进来配置或编程，产品之间打通就变得很艰难。

以AWS产品为例，AWS下和日志类数据（流数据）相关的有三款产品:

• CloudWatch4Logs：CloudWatch对Logs扩展，联通EC2与CloudWatch4Logs，数据格式为Json
• Kinesis: 数据传输中间件，数据模型为blob
• KinesisFirehose:数据收集与归档服务，数据模型为Json

遗憾是Kinesis，Kinesis Firehose两者是不打通的，并且CloudWatch4Logs Agent和Firehose Agent都是两个Agent。这三个产品之间关系如下:

CloudWatch4Logs针对日志解决方案：

Kinesis与Kinesis Firehose针对日志和Blob集成方案：

从上面几幅图中我们可以看到，产品之间打通基本还要靠用户写代码、抽取、解析、发送等数据集成的逻辑。

而LogHub中原生提供的是Json数据模型，在上下游消费时能够理解语义。例如可以设定某个规则，把一些字段映射到数仓的表中，或根据字段进行流计算等。因此LogHub结构非常清晰，可以在上下游之间进行方便的转化，而不会因解析成blob丢失了数据的语义。

参考Google Cloud Logging，Kafka商业化公司Confluent，都是采用带描述数据类型来做通道。

提供弹性伸缩

根据流量大小，实时调整Shard大小与服务能力。这样带来的好处是，可以真正做到服务能力弹性化，例如根据波峰波谷进行资源控制，均匀将各处理单元映射到不同Shard（Kafka Partition）进行保序处理。更多信息可以参考我们的文章弹性伸缩(Merge/Split)。

根据应用特性按需弹性伸缩：

根据数据特性（Hash）进行分区调整：

提供原生Logtail

为什么要自己写一个Agent，不用开源的产品呢（logstash，fluentd）等？

有三个主要原因：

• 节省机器资源：阿里集团一台机器往往会跑很多的应用，而一台前端机上最大日志量会达到20MB/S。Logtail经过集团2年多的磨练，在效率和资源控制方面非常优秀，可以参考Benchmark, 在同样的任务场景下，性能是最受欢迎的开源软件的10倍，资源控制在1/5。
• 安全性高安全性，多租户隔离：怎么能够保证一台机器上日志有权限被收集，如何扩容，如何隔离用户端的权限不被泄露和伪造，我们以互联网产品的要求设计了一整套兼顾使用与安全的机制，保护我们的日志数据不被截取。
• QoS与做租户控制：Logtail在设计时，专门针对阿里集团多租户场景做了深入分析，代码层做了一套公平调度机制。例如一台机器上更有两种不同的日志A，B，但A乱打引起流量爆发时，B收集是不会受到影响的，因为Logtail实现了CPU时间片的调度机制，提供多租户场景下的资源控制与隔离。

（我们会在之后分享Logtail在以上三方面的设计）

提供投递服务Shipper

LogHub提供免费Logshipper功能将要日志数据投递到OSS和ODPS，全量低成本存储数据。

可以这样认为，LogHub+LogShipper就是 AWS Kinesis + CloudWatch4Logs + KinesisFirehose +Logstash/Fluentd 组合。

写在最后

通过这篇文章，大家对构建数据收集、分发服务挑战也有大致的了解了吧，非常欢迎尝试我们的产品。

今天日志服务及LogHub在弹外华北1（北京），华北2（ 青岛），华东1（杭州），华南（深圳）已经部署，今年计划会扩展华东2（上海），及海外节点。