4.4　Serverless和消息隊列

在Serverless架構中，涉及消息處理、異步解耦的場景時，消息隊列的打通就變得尤為重要了。本節將介紹消息隊列Kafka的基本概念和特性，并舉例說明消息隊列和Serverless關聯的場景。

4.4.1　基本概念

Apache Kafka是一個分布式的流數據平臺，既可以作為消息引擎，用來對流數據進行發布和訂閱，也可以作為消息的流失存儲，確保存儲的容錯性，還可以作為一個流處理的平臺提供服務，對流數據進行處理。Apache Kafka的架構及特性如圖4-16所示。

由于Apache Kafka是一個開源項目，搭建方式簡單便捷，并且具備高性能的特點，因此許多企業會選擇自建Kafka集群。但是隨著業務消息量增加，自建集群會出現各種各樣的問題，需要開發人員持續運維，針對參數配置進行調優，保證維持高性能運行，并且快速處理突發故障，對集群的健康狀況進行監控和擴縮容，在進階使用Kafka服務及周邊組件的過程中也有一定的門檻。因此，市面上也出現了商業化公司如Confluent，提供消息隊列Kafka的托管服務。公有云廠商也提供了Cloud Kafka的云端解決方案，通過增加下列特性，保證Kafka服務的托管、伸縮和免運維。

• 高可用：提供磁盤高可靠，即使服務器壞盤達到50%，也不會影響業務，保證數據不丟失。
• 高可靠：提供多副本備份，支持跨可用區容災。
• 水平擴展：解決開源版本Kafka長期以來數據水平擴展和遷移的痛點，配置升級無感知。
• 鑒權和安全性：支持云上私有網絡隔離、賬戶權限管理以及SASL等鑒權方式，保證公網訪問的安全性。
• 數據監控告警：針對集群提供默認的指標監控和告警配置（例如消息條數、磁盤容量、峰值帶寬等），及早發現異常問題。
• 云上服務打通：支持和公有云上的對象存儲、MapReduce等服務一鍵打通。
• 開源兼容：完全兼容Kafka 0.9、0.10和1.1.1等社區版本。

消息隊列Kafka在日志轉儲、大數據分析等場景下均有典型的應用。如圖4-17所示，某知名電商在做視頻直播的過程中，利用CDN做數據分發，產生許多日志數據。業務方需要利用日志數據進行實時數據分析，因此客戶選擇將流式數據上傳到Kafka中，并由業務團隊實時拉取進行消費，從而實現了分鐘級別的數據分析能力。

消息隊列在大數據分析方面也有非常廣泛的應用。如圖4-18所示，某知名UGC視頻企業通過自建Kafka和ELK的方案進行數據處理、過濾，但隨著數據量增大，自建運維成本越來越高。因此該企業選擇結合公有云的大數據套件+消息隊列CKafka的方案，劃分數據清洗和計算、數據檢索、數據羅盤等階段，對數據流轉過程進行優化，并且針對業務波峰波谷，支持平滑擴縮容。

4.4.2　消息隊列和FaaS的聯動

接下來我們繼續了解消息隊列和Serverless結合的場景及優勢。如圖4-19所示，在一個較為通用的流數據處理模型中，上游有多種多樣的數據源，如數據庫、應用運行過程中采集的日志、第三方數據源等。通過采集工具將這些數據導入消息隊列Kafka中，之后再通過各種流處理工具對這些數據進行加工，最終對加工后的數據進行存儲落盤或中轉處理。

在這個過程中，FaaS可以在數據采集和數據處理環節提供快速、簡單、水平擴展的處理能力，從而確保數據處理流的完整性。FaaS本身具備以下幾個特點，能夠很好地支持消息隊列上下游的處理能力。

• 使用成本低（提供多語言的支持，包括自定義運行時）。
• 近乎無限的橫向擴容能力。
• 支持多種觸發方式，如事件觸發、定時觸發、API接口調用觸發等。
• 按需付費，空閑時不付費。

在沒有FaaS參與上述架構的情況下，一般流處理工具和采集工具需要客戶自建和運維。例如最典型的ELK集群，消息隊列轉到Elasticsearch（ES）組件的過程中，需要用戶創建ES和Logstash資源，并了解對應的導入配置。而結合FaaS和消息隊列觸發器的方案時，只需要用戶選擇對應的模板，即可默認打通消息隊列到后端的對象存儲/ES等集群，降低了學習門檻，且無須對函數集群進行運維，可以滿足業務波峰波谷的需求。使用FaaS后流式計算的典型數據流示意如圖4-20所示。

最終架構如圖4-21所示，消息隊列Kafka結合FaaS函數的多種配置模板，可以實現一鍵轉儲流數據到多個數據消費者，例如云上Elasticsearch、對象存儲COS、數據庫TencentDB、數據倉庫Data Warehouse等。可以說，Serverless結合消息隊列，實現了更為通用的流數據處理方案，搭建了“云上數據管道”。