xxx 聚合 edi app 模式 比較 交互 架構圖 java

一．了解淘寶Kafka架構
在ActiveMQ、RabbitMQ、RocketMQ、Kafka消息中間件之間，我們為什麽要選擇Kafka?下面詳細介紹一下，2012年9月份我在支付寶做余額寶研發，2013年6月支付寶正式推出余額寶，2013年8月擔任支付寶淘寶×××項目經理帶領兄弟們一起做研發，期間需要與淘寶和500萬對接競彩接口數據，業余時間與淘寶的同事溝通，了解天貓在電商節如何處理這些大數據的？技術架構上采用了哪些策略呢？

一、應用無狀態(淘寶session框架)

二、有效使用緩存(Tair)

三、應用拆分(HSF)

四、數據庫拆分(TDDL)

五、異步通信(Notify)

六、非結構化數據存儲 ( TFS,NOSQL)

七、監控、預警系統

八、配置統一管理

天貓的同事把大致的架構跟我描述了一番，心有感悟。咱們來看一下2018年雙11當天的成交額。

二．kafka實現天貓億萬級數據統計架構

Flume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日誌采集、聚合和傳輸的系統，Flume支持在日誌系統中定制各類數據發送方，用於收集數據；同時，Flume提供對數據進行簡單處理，並寫到各種數據接受方（可定制）的能力

Data Access：數據通道
Computing：計算
Persistence：執行保存方式
spout：表示一個流的源頭，產生tuple
bolt：處理輸入流並產生多個輸出流，可以做簡單的數據轉換計算，復雜的流處理一般需要經過多個bolt進行處理

為什麽不能用分布式文件HDFS集群？

1、實時性：hdfs的實時性沒有kafka高。

2、消費量的記錄：hdfs不會記錄你這個塊文件消費到了哪裏，而基於zookeeper的kafka會記錄你消費的點。

3、並發消費：hdfs不支持並發消費，而kafka支持並發消費，即多個consumer.

4、彈性且有序：當數據量會很大，而且處理完之後就可以刪除時，頻繁的讀寫會對hdfs中NameNode造成很大的壓力。而kafka的消費點是記錄在zookeeper的，並且kafka的每條數據都是有“坐標”的，所以消費的時候只要這個“坐標”向後移動就行了，而且刪除的時候只要把這個“坐標”之前的數據刪掉即可。

三．什麽是Kafka?

通過上圖就可以了解到，生產者Producers(農民和廚師)，消費主題top(魚，骨頭，草，香蕉),消費者Comsumer(貓，狗，老牛，猴子)，生產者根據消費主題獲取自己想要的食物

四．Kafka架構原理

五．Kafka能幫我們解決什麽問題？
請高手指明一下kafka解決了什麽問題，什麽場景下使用？消息訂閱和發布嗎，好像redis也支持，功能是否有重疊？

一．消息隊列

假設你意氣風發，要開發新一代的互聯網應用，以期在互聯網事業中一展宏圖。借助雲計算，很容易開發出如下原型系統：

Web應用：部署在雲服務器上，為個人電腦或者移動用戶提供的訪問體驗。
SQL數據庫：為Web應用提供數據持久化以及數據查詢。

這套架構簡潔而高效，很快能夠部署到百度雲等雲計算平臺，以便快速推向市場。互聯網不就是講究小步快跑嘛！

好景不長。隨著用戶的迅速增長，所有的訪問都直接通過SQL數據庫使得它不堪重負，不得不加上緩存服務以降低SQL數據庫的荷載；為了理解用戶行為，開始收集日誌並保存到Hadoop上離線處理，同時把日誌放在全文檢索系統中以便快速定位問題；由於需要給投資方看業務狀況，也需要把數據匯總到數據倉庫中以便提供交互式報表。此時的系統的架構已經盤根錯節了，考慮將來還會加入實時模塊以及外部數據交互，真是痛並快樂著……

這時候，應該跑慢一些，讓靈魂跟上來。

本質上，這是一個數據集成問題。沒有任何一個系統能夠解決所有的事情，所以業務數據根據不同用途存而放在不同的系統，比如歸檔、分析、搜索、緩存等。數據冗余本身沒有任何問題，但是不同系統之間像意大利面條一樣復雜的數據同步卻是挑戰。

這時候就輪到Kafka出場了。

Kafka可以讓合適的數據以合適的形式出現在合適的地方。Kafka的做法是提供消息隊列，讓生產者單往隊列的末尾添加數據，讓多個消費者從隊列裏面依次讀取數據然後自行處理。之前連接的復雜度是O(N^2)，而現在降低到O(N)，擴展起來方便多了：

在Kafka的幫助下，你的互聯網應用終於能夠支撐飛速增長的業務，成為下一個BAT指日可待。

以上故事說明了Kafka主要用途是數據集成，或者說是流數據集成，以Pub/Sub形式的消息總線形式提供。但是，Kafka不僅僅是一套傳統的消息總線，本質上Kafka是分布式的流數據平臺，因為以下特性而著名：

提供Pub/Sub方式的海量消息處理。
以高容錯的方式存儲海量數據流。
保證數據流的順序。
二．日誌采集

隨著互聯網的不斷發展，用戶所產生的行為數據被越來越多的網站重視，如何對於用戶信息進行采集則越來越受到重視，下面就為大家介紹基於Kafka的服務端用戶行為日誌采集方式。

1. 技術選型

服務端日誌采集主要通過在Controller的接口中進行埋點，然後通過AOP技術、Kafka消息系統以及logback對用戶行為進行采集。

之所以使用AOP技術是因為AOP的以下重要特定：

代碼的侵入性小。對於業務代碼的侵入性小，只需要在Controller的接口上添加註解，然後在其他模塊對用戶行為進行采集。
重用性。對於相同作用的代碼可以進行重用。
擴展性。能夠很好的對系統進行擴展。
由於使用異步方式對用戶行為信息進行收集，因此需要使用消息中間件。目前消息中間件非常多，比較流行的有ActiveMQ、ZeroMQ、RabbitMQ、Kafka等。每個消息中間件都有各種的優勢劣勢，之所以使用Kafka消息中間件，是因為以下幾點因素：

高性能。每秒鐘可以處理數以千計生產者生成的消息。
高擴展性。可以通過簡單的增加服務器橫向擴展Kafka集群的容量。
分布式。消息來自數以千計的服務，使用分布式來解決單機處理海量數據的瓶頸。
持久性。Kafka中的消息可以持久化到硬盤上，這樣可以防止數據的丟失。
因為用戶的行為數據最終是以日誌的形式持久化的，因此使用logback對日誌持久化到日誌服務器中。

2.總體架構

圖1 總體架構圖

服務端日誌采集系統主要由兩個工程組成：陸金所-bi-core和lu-bi-service。由於中國平安陸金所使用dubbo框架，因此有服務提供方和服務消費方。lu-bi-core被web、wap和mainsite服務消費方依賴。此外，lu-bi-service也依賴於lu-bi-core，主要是依賴於其中的一些實體類及工具類。

lu-bi-core工程為Kafka消息的生產者，主要封裝實現切面的具體邏輯，其主要職責如下：

解析用戶請求的Request信息：從Request中提取用戶的基本信息，如設備型號、用戶的供應商、ip、設備的分辨率、設備平臺、設備的操作系統、設備id、app渠道等。
接口對應的參數：通過切面可以提取接口的參數值，從而知道用戶的業務信息。
應用層返回的結果信息：因為切面使用AfterReturning方式，因此可以獲取用層的返回結果，從返回結果中可以提取有用的信息。
用戶的基本信息：用戶的id信息。
信息格式化：將信息轉化成JSON字符串。
發送消息：將最終需要發送的消息放入本地阻塞隊列中，通過另一個線程異步從阻塞隊列中獲取消息並發送到Kafka Broker中。
lu-bi-service工程為Kafka消息的消費者，其主要職責如下：

實時從Kafka中拉取最新的數據。
將JSON字符串轉化成，方便進一步對用信息進行加工。
對用戶的ip進行解析，獲取ip對應的地區以及經緯度信息。
將加工好的最終信息持久化到log文件中。
3.部署圖

圖2 部署圖

上圖為陸金所與日誌系統系統相關的部署圖，App、Wap和Mainsite服務器集群分別對應不同終端的應用。Kafka集群使用杭研的集群，目前有10個Broker。日誌服務器有兩臺，通過Kafka的均衡策略對日誌進行消費。

4.日誌采集的流程

日誌采集流程圖如下所示：

圖3 日誌打點流程圖

上圖為消息生產者和消息消費者共同組成的流程圖。

消息生產者的具體步驟如下：
通過切面攔截用戶的請求。
從切面中提取請求頭的基本信息，如設備信息，cookie信息，ip信息等。
提取請求的接口參數信息。
從接口返回值中提取相關信息，如id，pvid等。
將提取的信息封裝成JSON字符串，放到阻塞隊列中，假如阻塞隊列溢出會有三次重試機制。
異步線程從本地阻塞隊列中獲取數據，並將信息組裝發送到Kafka的Broker中，此時消息生產者結束。
消息消費者的具體步驟如下：

實時從Kafka Broker中批量拉取消息。
將拉取的消息轉化成對象。
解析ip對應的國家、省份、城市、經緯度信息。
對不同業務場景的信息進一步解析。
將日誌信息轉化成JSON字符串，持久化到log文件中。

5. 相關配置

application-XXX.properties：該配置放Kafka的相關屬性，包括topic、groupId、server等信息。
lu-log-msg.xml：該配置放在app-web，mainsite-web，wap-web的src/main/resources目錄下，主要是初始化kafka生產者的信息。
lu-bi-service.xml：該配置放在lu-bi-service工程的src/main/resources目錄下，主要用於加載kafka消費者的配置信息，並且啟動kafka消費者服務。
logback.xml：該配置放在lu-bi-service工程的src/main/resources目錄下，主要用於聲明日誌文件存放的目錄，需要持久化的日誌的package路徑，以及日誌持久化的格式。
ip_conf.txt：該配置放在lu-bi-service工程的src/main/resources目錄下，用於解析ip對應的地域、經緯度等信息。
六．關於面試問題
1.Redis和Kafka區別？

作者跟大家舉個例子：

老板有個好消息要告訴大家，公司要發放年終獎，有兩個辦法:

1.到會議室每個座位上挨個兒告訴每個人。什麽？張三去上廁所了？那張三就只能錯過好消息了！

2.老板把消息寫到會議上的黑板報上，誰想知道就來看一下，什麽？張三請假了？沒關系，我一周之後才擦掉，總會看見的！什麽張三請假兩周？那就算了，我反正只保留一周，不然其他好消息沒地方寫了

redis用第一種辦法，kafka用第二種辦法，知道什麽區別了吧

Redis PUB/SUB使用場景：

1. 消息持久性需求不高

2. 吞吐量要求不高

3. 可以忍受數據丟失

4. 數據量不大

Kafka使用場景：

上面以外的其他場景：）

1. 高可靠性

2. 高吞吐量

3. 持久性高

Kafka、RabbitMQ、RocketMQ等消息中間件的對比
有關測試結論

Kafka的吞吐量高達17.3w/s，不愧是高吞吐量消息中間件的行業老大。這主要取決於它的隊列模式保證了寫磁盤的過程是線性IO。此時broker磁盤IO已達瓶頸。

RocketMQ也表現不俗，吞吐量在11.6w/s，磁盤IO %util已接近100%。RocketMQ的消息寫入內存後即返回ack，由單獨的線程專門做刷盤的操作，所有的消息均是順序寫文件。

RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高。它支持AMQP協議，實現非常重量級，為了保證消息的可靠性在吞吐量上做了取舍。我們還做了RabbitMQ在消息持久化場景下的性能測試，吞吐量在2.6w/s左右。

在服務端處理同步發送的性能上，Kafka>RocketMQ>RabbitMQ

寫在最後
如今都在談論寒冬有多可怕，筆者作為一個過來人，卻有不同的看法：寒冬不可怕，在寒冬裏沒有生存能力，才是最可怕的。

因此小編總結了這幾年在阿裏的工作經驗並結合目前互聯網最主流的Java架構技術，最後錄制了七大Java架構技術專題視頻（源碼閱讀、分布式架構、微服務、性能優化、阿裏項目實戰、Devops、並發編程）分享在我的群：714526711中，並且每晚我都會在群內直播講解這些架構技術的底層實現原理，感興趣的程序員們可以加群找管理員獲取。

Kafka對Java程序員有多重要？連阿裏都再用它處理億萬級數據統計