前几天有客户问到,云上有什么服务可以替换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
[tr][td]采购服务器[/td][td]以3份Copy计算,2核2G 100GB硬盘机器3台部署Zookeeper与Kafka, 大约500元/月[/td][td]0[/td][/tr][tr][td]部署软件、配置参数(Logstash, Kafka, Fluentd)[/td][td]软件工程师、运维工程师[/td][td]0[/td][/tr][tr][td]线上当机运维[/td][td]运维工程师[/td][td]0[/td][/tr][tr][td]线上扩容、收缩[/td][td]运维工程师[/td][td]0[/td][/tr][tr][td]磁盘、机器上下线[/td][td]运维工程师[/td][td]0[/td][/tr][tr][td]占用机器资源成本[/td][td]采集Agent是否会对主机带来影响,对比fluentd、logstash两个Agent[/td][td]同样流量,CPU/MEM占用是logstash 1/10[/td][/tr][tr][td]线上Agent扩容[/td][td]运维工程师调用脚本触发[/td][td]API/ Web Console 10 秒搞定[/td][/tr][tr][td]线上Agent新增一种日志[/td][td]运维工程师重新更新配置文件,灰度环境,线上所有Agent升级[/td][td]API/ Web Console 10秒搞定[/td][/tr][tr][td]总成本[/td][td]1.6 W/ Year[/td][td]按需付费[/td][/tr]
假设一个工程师的年薪为20W,大约有1/20精力会在系统上。则成本为1W/Year。则一年的耗费为500*12+ 10000= 1.6W,相当于把服务搭起来什么都不做,一天50就花出去了,更不用说业务增长情况下带来的扩容与升级等变更。
稳定性
作为一个流处理系统,要保证Always Writable。因为有一些场景中(例如嵌入式设备)会把程序烧录到硬件中长时间运行,因此要使得收集服务端保障长时间可用。
可用性难点不在于正常状态下的表现,而是软件在各种异常状态下是否能表现依然优秀,我们考虑了如下常见的故障场景做了对比:
故障场景Kafka表现LogHub表现
[tr][td]硬盘损坏[/td][td]可能丢失数据(需要手动复制)[/td][td]正常[/td][/tr][tr][td]机器掉电[/td][td]丢失数据[/td][td]正常[/td][/tr][tr][td]机柜掉电[/td][td]丢失数据[/td][td]正常[/td][/tr][tr][td]机房掉电[/td][td]丢失数据,无法服务[/td][td]无法服务 (计划通过3AZ PAXOS解决)[/td][/tr][tr][td]进程Crash[/td][td]有重复[/td][td]正常[/td][/tr][tr][td]机器Reboot[/td][td]有重复[/td][td]正常[/td][/tr][tr][td]扩容[/td][td]有重复[/td][td]正常[/td][/tr][tr][td]某个用户流量暴增[/td][td]其他用户不可用,日志丢失[/td][td]正常[/td][/tr][tr][td]软件升级[/td][td]可能重复,升级阶段短暂不可用[/td][td]正常[/td][/tr]
从设计上,LogHub在RoundRobin写场景下能保证99.95%可用性,在通过KeyHash写场景下、以及读场景下提供99.9%可用性,最大程度保证服务对用户的稳定、可靠。
安全性
Kafka定位主要是软件,因此不具备安全相关的功能,会有如下风险:
  • 在不做网络限制情况下,任何用户可以直接订阅Topic数据
  • 无用户相关的隔离功能,例如业务系统有:操作日志、服务端请求日志、程序日志。无法限制每种日志只对某些用户可用
  • 在日志收集过程中,会被sniffer
  • 日志收集过程中,可以伪造日志写入

以下这张表是我们在安全相关场景下对两者对比结果:
安全场景KafkaLogHub
[tr][td]防篡改[/td][td]无[/td][td]支持[/td][/tr][tr][td]认证[/td][td]无[/td][td]支持多因子认证[/td][/tr][tr][td]访问控制[/td][td]无[/td][td]支持[/td][/tr][tr][td]临时访问[/td][td]无[/td][td]支持[/td][/tr][tr][td]子账号[/td][td]无[/td][td]支持[/td][/tr][tr][td]支持匿名[/td][td]支持[/td][td]支持[/td][/tr][tr][td]安全传输[/td][td]无[/td][td]支持[/td][/tr]使用便捷性
使用起来是否方便,快速与现有系统集成,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等平台服务器、路由器、交换机等作为数据源也不是少数,几乎所有主流接入手段我们都支持
    • 在下游,我们和阿里云各存储以及计算类云产品无缝联通,即开即用


  4. 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 组合。

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


    https://yq.aliyun.com/articles/35979