使用日志服务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的版本。

从用户角度考虑哪些问题

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

使用成本

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

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

稳定性

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

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

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

安全性

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

• 在不做网络限制情况下，任何用户可以直接订阅Topic数据

• 无用户相关的隔离功能，例如业务系统有：操作日志、服务端请求日志、程序日志。无法限制每种日志只对某些用户可用

• 在日志收集过程中，会被sniffer

• 日志收集过程中，可以伪造日志写入

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

使用便捷性

使用起来是否方便，快速与现有系统集成，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（上海），及海外节点。