前幾天有客戶問到，雲上有什麼服務可以替換kafka？
懷着程式員的一絲小小的驕傲回複：日志服務（原sls）下loghub功能可以完全替代kafka等産品，并且在性能、易用性和穩定性上更佳。
但客戶将信将疑，于是花了一天時間整理一篇文章，簡單從各個角度解釋下為何建議使用者從自搭kafka換成使用loghub。
除了這兩款産品外，同類還有aws kinesis, azure eventhub，屬于兩家巨頭服務化kafka的版本。
如果我是一個創業公司的工程師，我會關注如下幾件事情（如果你愛折騰，那就另當别論了）：
日志元件本身不直接創造價值，功能固定。是以要從維護、使用等最小角度考慮，讓我們來看下有哪些成本:
階段
自建kafka成本
使用loghub
采購伺服器
以3份copy計算，2核2g 100gb硬碟機器3台部署zookeeper與kafka, 大約500元/月
部署軟體、配置參數(logstash, kafka, fluentd)
軟體工程師、運維工程師
線上當機運維
運維工程師
線上擴容、收縮
磁盤、機器上下線
占用機器資源成本
采集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點：
loghub所有管控與讀寫api是公開的，既可以從web層快速接入，又能在之上包裝使用者的配管程式，最大程度提供自動化能力。
提供原生agent，對于不需要特别解析當行日志，1分鐘以内完成接入。通過web控制台及api可以輕松管理百萬級别的機器。
上下遊與生态：kafka對接了衆多上下遊系統，那loghub呢？也不例外：
loghub提供8種語言sdk，支援syslog, tracking pixel等協定
完美支援ecs各版本linux、windows，以及阿裡雲容器服務docker等環境，可以通過腳本将oss等日志打通
除伺服器外，今天使用者通過sdk，用戶端等方式已經在 x86，arm等平台伺服器、路由器、交換機等作為資料源也不是少數，幾乎所有主流接入手段我們都支援
在下遊，我們和阿裡雲各存儲以及計算類雲産品無縫聯通，即開即用
loghub目前已支援上下遊可以參見：
除剛才提到的點外，設計上兩者有一些不同點：
我們把資料收集與消費定位成服務，而restful api就是服務最理想的通路方式。除此之外為了保證使用者資料安全性，我們在如下層面對安全加強：
提供https等傳輸機制，保障公網等惡劣環境下進行資料傳輸
支援vpc環境，資料不外洩露
與通路控制ram內建，可以配置不同的政策
傳輸過程簽名，保證完整不被纂改
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，都是采用帶描述資料類型來做通道。
根據應用特性按需彈性伸縮：
根據資料特性（hash）進行分區調整：
為什麼要自己寫一個agent，不用開源的産品呢（logstash，fluentd）等？
有三個主要原因：
安全性高安全性，多租戶隔離：怎麼能夠保證一台機器上日志有權限被收集，如何擴容，如何隔離使用者端的權限不被洩露和僞造，我們以網際網路産品的要求設計了一整套兼顧使用與安全的機制，保護我們的日志資料不被截取。
qos與做租戶控制：logtail在設計時，專門針對阿裡集團多租戶場景做了深入分析，代碼層做了一套公平排程機制。例如一台機器上更有兩種不同的日志a，b，但a亂打引起流量爆發時，b收集是不會受到影響的，因為logtail實作了cpu時間片的排程機制，提供多租戶場景下的資源控制與隔離。
（我們會在之後分享logtail在以上三方面的設計）
loghub提供免費logshipper功能将要日志資料投遞到oss和odps，全量低成本存儲資料。
可以這樣認為，loghub+logshipper就是 aws kinesis + cloudwatch4logs + kinesisfirehose +logstash/fluentd 組合。
通過這篇文章，大家對建構資料收集、分發服務挑戰也有大緻的了解了吧，非常歡迎嘗試我們的産品。