組件分享之后端組件——基于Golang實現(xiàn)的高性能和彈性的流處理器benthos

近期正在探索前端、后端、系統(tǒng)端各類常用組件與工具，對其一些常見的組件進(jìn)行再次整理一下，形成標(biāo)準(zhǔn)化組件專題，后續(xù)該專題將包含各類語言中的一些常用組件。歡迎大家進(jìn)行持續(xù)關(guān)注。

創(chuàng)新互聯(lián)公司專注服務(wù)器托管服務(wù)十多年，提供服務(wù)器租用、網(wǎng)頁空間、主機(jī)域名、云服務(wù)器、云主機(jī)租用、雅安服務(wù)器托管、建站等服務(wù)

本節(jié)我們分享的是基于Golang實現(xiàn)的高性能和彈性的流處理器 benthos ，它能夠以各種代理模式連接各種 源 和 接收器，并對有效負(fù)載執(zhí)行 水合、濃縮、轉(zhuǎn)換和過濾 。

它帶有 強大的映射語言 ，易于部署和監(jiān)控，并且可以作為靜態(tài)二進(jìn)制文件、docker 映像或 無服務(wù)器函數(shù) 放入您的管道，使其成為云原生。

Benthos 是完全聲明性的，流管道在單個配置文件中定義，允許您指定連接器和處理階段列表：

Apache Pulsar, AWS (DynamoDB, Kinesis, S3, SQS, SNS), Azure (Blob storage, Queue storage, Table storage), Cassandra, Elasticsearch, File, GCP (Pub/Sub, Cloud storage), HDFS, HTTP (server and client, including websockets), Kafka, Memcached, MQTT, Nanomsg, NATS, NATS JetStream, NATS Streaming, NSQ, AMQP 0.91 (RabbitMQ), AMQP 1, Redis (streams, list, pubsub, hashes), MongoDB, SQL (MySQL, PostgreSQL, Clickhouse, MSSQL), Stdin/Stdout, TCP UDP, sockets and ZMQ4.

1、docker安裝

具體使用方式可以參見該 文檔

有關(guān)如何配置更高級的流處理概念（例如流連接、擴(kuò)充工作流等）的指導(dǎo)，請查看 說明書部分。

有關(guān)在 Go 中構(gòu)建您自己的自定義插件的指導(dǎo)，請查看 公共 API。

【Minio】基于AWS S3協(xié)議搭建個人云存儲服務(wù)

在2007年，GlusterFS演變?yōu)榇笮头植际酱鎯Ψ桨负螅魏闻鋫浜线m硬件的公司，單位都可以利用個做分布式的流媒體，數(shù)據(jù)分析。在2011年，Red Hat收購了GlusterFS.

Minio是GlusterFS創(chuàng)始人之一Anand Babu Periasamy發(fā)布新的開源項目。Minio兼容Amason的S3分布式對象存儲項目，采用Golang實現(xiàn)，客戶端支持Java,Python,Javacript, Golang語言。

Minio 提供對象存儲服務(wù)，兼容了 AWS S3 存儲協(xié)議，用于非結(jié)構(gòu)化的數(shù)據(jù)存。非結(jié)構(gòu)化對象，比如圖像，音、視頻，日志文件，備份鏡像…等等管理不方便，不定長，大小變化大、類型多，云端的訪問復(fù)雜，minio就是來解決這種場景的。非結(jié)構(gòu)化的文件從數(shù)KB到5TB都能很好的支持。開源并且用 Go 語言開發(fā)，有web操作界面，我們可以用它來搭建兼容S3協(xié)議的存儲云服務(wù)。

Minio可以做為云存儲的解決方案用來保存海量的圖片，視頻，文檔。由于采用Golang實現(xiàn)，服務(wù)端可以工作在Windows,Linux, OS X和FreeBSD上。配置簡單，基本是復(fù)制可執(zhí)行程序，單行命令可以運行起來。

官網(wǎng)：

那么，如何自己搭建一個私有的S3存儲云服務(wù)呢？

官方的話是推薦用Docker來搞，我們先用普通的二進(jìn)制文件來直接解決了！

######################################################################################

# mkdir /data/aws_s3

# wget??

# mv??minio /usr/local/bin/

# ?chmod ?755 ?/usr/local/bin/minio?

#?minio server ?/data/aws_s3

#############################################################

Created minio configuration file successfully at /root/.minio

Endpoint: ? ?

AccessKey: U3XLU4IMXY3IDKHU268F?

SecretKey: /6NCL6HGacviaCgRqr2qLbVOjhkkJdRpV7wz0JJD?

Region: ? ?us-east-1

SQS ARNs: ?

Browser Access:

Command-line Access:?

################################################################

$ mc config host add myminio? ?U3XLU4IMXY3IDKHU268F /6NCL6HGacviaCgRqr2qLbVOjhkkJdRpV7wz0JJD

Object API (Amazon S3 compatible):

Go:?

Java:?

Python:?

JavaScript:?

Drive Capacity: 8.3 GiB Free, 9.1 GiB Total

##############################################################

我們就成功啟動了minio的s3服務(wù)，默認(rèn)端口9000，可以通過網(wǎng)頁訪問:

注意 ：第一次打開時候需要填寫AccessKey和SecretKey才能進(jìn)入，我們上面啟動服務(wù)的時候，已經(jīng)看到屏幕有輸出:

AccessKey:?U3XLU4IMXY3IDKHU268F?

SecretKey:6NCL6HGacviaCgRqr2qLbVOjhkkJdRpV7wz0JJD

把這兩個Key填入，就能順利進(jìn)入，進(jìn)入后展開頁面如下:

這就是我們的S3云存儲的管理頁面了，看著是不是和七牛什么的提供云存儲的產(chǎn)品頁面挺像的，大家都是基于S3協(xié)議開發(fā)的！

上傳個文件試試：

點擊右下角的紅色小加號按鈕，彈出的菜單選擇”create bucket”則會創(chuàng)建一個桶，輸入名字”test”

點擊剛才那個紅色小加號按鈕，這次選擇”Upload file”上傳文件，給這個桶上傳了一個叫l(wèi)ogin.txt的文本文檔

此時頁面如下：

至此我們可以看到文件已經(jīng)上傳，要訪問這個文件，可以點擊文件右側(cè)的三個點的按鈕，選擇分享就可以得到一個外鏈，在瀏覽器中訪問這個外鏈就可以直接訪問文件。

那么文件到底被存到哪里去了呢，我們啟動命令中其實指定了工作路徑/data/aws_s3/，所以到服務(wù)器這個目錄下看看：

# ls /data/aws_s3/?

test

# ls /data/aws_s3/test/

login.txt?

桶名稱test是一個目錄，其下就有上傳的login.txt文件。

如果想指定ip和端口，可以這樣寫:

# minio server /data/aws_s3?--address=0.0.0.0:9000

如果想讓服務(wù)在后臺運行：

#?nohup?minio server /data/aws_s3 ? --address=0.0.0.0:443?

[1] 19882

// nohup: 忽略輸入并把輸出追加到啟動命令的當(dāng)前目錄下的 "nohup.out"文件

minio可以用來搭建分布式存儲系統(tǒng) GlusterFS，這樣就成了真正的云存儲了，有時間再研究下把它從現(xiàn)在的單機(jī)測試，變成一朵存儲云！

minio官網(wǎng)：

minio官方文檔：

minio github主頁：

golang使用Nsq

1. 介紹

最近在研究一些消息中間件，常用的MQ如RabbitMQ,ActiveMQ,Kafka等。NSQ是一個基于Go語言的分布式實時消息平臺，它基于MIT開源協(xié)議發(fā)布，由bitly公司開源出來的一款簡單易用的消息中間件。

官方和第三方還為NSQ開發(fā)了眾多客戶端功能庫，如官方提供的基于HTTP的nsqd、Go客戶端go-nsq、Python客戶端pynsq、基于Node.js的JavaScript客戶端nsqjs、異步C客戶端libnsq、Java客戶端nsq-java以及基于各種語言的眾多第三方客戶端功能庫。

1.1 Features

1). Distributed

NSQ提供了分布式的，去中心化，且沒有單點故障的拓?fù)浣Y(jié)構(gòu)，穩(wěn)定的消息傳輸發(fā)布保障，能夠具有高容錯和HA（高可用）特性。

2). Scalable易于擴(kuò)展

NSQ支持水平擴(kuò)展，沒有中心化的brokers。內(nèi)置的發(fā)現(xiàn)服務(wù)簡化了在集群中增加節(jié)點。同時支持pub-sub和load-balanced 的消息分發(fā)。

3). Ops Friendly

NSQ非常容易配置和部署，生來就綁定了一個管理界面。二進(jìn)制包沒有運行時依賴。官方有Docker image。

4.Integrated高度集成

官方的 Go 和 Python庫都有提供。而且為大多數(shù)語言提供了庫。

1.2 組件

1.3 拓?fù)浣Y(jié)構(gòu)

NSQ推薦通過他們相應(yīng)的nsqd實例使用協(xié)同定位發(fā)布者，這意味著即使面對網(wǎng)絡(luò)分區(qū)，消息也會被保存在本地，直到它們被一個消費者讀取。更重要的是，發(fā)布者不必去發(fā)現(xiàn)其他的nsqd節(jié)點，他們總是可以向本地實例發(fā)布消息。

NSQ

首先，一個發(fā)布者向它的本地nsqd發(fā)送消息，要做到這點，首先要先打開一個連接，然后發(fā)送一個包含topic和消息主體的發(fā)布命令，在這種情況下，我們將消息發(fā)布到事件topic上以分散到我們不同的worker中。

事件topic會復(fù)制這些消息并且在每一個連接topic的channel上進(jìn)行排隊，在我們的案例中，有三個channel，它們其中之一作為檔案channel。消費者會獲取這些消息并且上傳到S3。

nsqd

每個channel的消息都會進(jìn)行排隊，直到一個worker把他們消費，如果此隊列超出了內(nèi)存限制，消息將會被寫入到磁盤中。Nsqd節(jié)點首先會向nsqlookup廣播他們的位置信息，一旦它們注冊成功，worker將會從nsqlookup服務(wù)器節(jié)點上發(fā)現(xiàn)所有包含事件topic的nsqd節(jié)點。

nsqlookupd

2. Internals

2.1 消息傳遞擔(dān)保

1）客戶表示已經(jīng)準(zhǔn)備好接收消息

2）NSQ 發(fā)送一條消息，并暫時將數(shù)據(jù)存儲在本地（在 re-queue 或 timeout）

3）客戶端回復(fù) FIN（結(jié)束）或 REQ（重新排隊）分別指示成功或失敗。如果客戶端沒有回復(fù), NSQ 會在設(shè)定的時間超時，自動重新排隊消息

這確保了消息丟失唯一可能的情況是不正常結(jié)束 nsqd 進(jìn)程。在這種情況下，這是在內(nèi)存中的任何信息（或任何緩沖未刷新到磁盤）都將丟失。

如何防止消息丟失是最重要的，即使是這個意外情況可以得到緩解。一種解決方案是構(gòu)成冗余 nsqd對（在不同的主機(jī)上）接收消息的相同部分的副本。因為你實現(xiàn)的消費者是冪等的，以兩倍時間處理這些消息不會對下游造成影響，并使得系統(tǒng)能夠承受任何單一節(jié)點故障而不會丟失信息。

2.2 簡化配置和管理

單個 nsqd 實例被設(shè)計成可以同時處理多個數(shù)據(jù)流。流被稱為“話題”和話題有 1 個或多個“通道”。每個通道都接收到一個話題中所有消息的拷貝。在實踐中，一個通道映射到下行服務(wù)消費一個話題。

在更底的層面，每個 nsqd 有一個與 nsqlookupd 的長期 TCP 連接，定期推動其狀態(tài)。這個數(shù)據(jù)被 nsqlookupd 用于給消費者通知 nsqd 地址。對于消費者來說，一個暴露的 HTTP /lookup 接口用于輪詢。為話題引入一個新的消費者，只需啟動一個配置了 nsqlookup 實例地址的 NSQ 客戶端。無需為添加任何新的消費者或生產(chǎn)者更改配置，大大降低了開銷和復(fù)雜性。

2.3 消除單點故障

NSQ被設(shè)計以分布的方式被使用。nsqd 客戶端（通過 TCP ）連接到指定話題的所有生產(chǎn)者實例。沒有中間人，沒有消息代理，也沒有單點故障。

這種拓?fù)浣Y(jié)構(gòu)消除單鏈，聚合，反饋。相反，你的消費者直接訪問所有生產(chǎn)者。從技術(shù)上講，哪個客戶端連接到哪個 NSQ 不重要，只要有足夠的消費者連接到所有生產(chǎn)者，以滿足大量的消息，保證所有東西最終將被處理。對于 nsqlookupd，高可用性是通過運行多個實例來實現(xiàn)。他們不直接相互通信和數(shù)據(jù)被認(rèn)為是最終一致。消費者輪詢所有的配置的 nsqlookupd 實例和合并 response。失敗的，無法訪問的，或以其他方式故障的節(jié)點不會讓系統(tǒng)陷于停頓。

2.4 效率

對于數(shù)據(jù)的協(xié)議，通過推送數(shù)據(jù)到客戶端最大限度地提高性能和吞吐量的，而不是等待客戶端拉數(shù)據(jù)。這個概念，稱之為 RDY 狀態(tài)，基本上是客戶端流量控制的一種形式。

efficiency

2.5 心跳和超時

組合應(yīng)用級別的心跳和 RDY 狀態(tài)，避免頭阻塞現(xiàn)象，也可能使心跳無用（即，如果消費者是在后面的處理消息流的接收緩沖區(qū)中，操作系統(tǒng)將被填滿，堵心跳）為了保證進(jìn)度，所有的網(wǎng)絡(luò) IO 時間上限勢必與配置的心跳間隔相關(guān)聯(lián)。這意味著，你可以從字面上拔掉之間的網(wǎng)絡(luò)連接 nsqd 和消費者，它會檢測并正確處理錯誤。當(dāng)檢測到一個致命錯誤，客戶端連接被強制關(guān)閉。在傳輸中的消息會超時而重新排隊等待傳遞到另一個消費者。最后，錯誤會被記錄并累計到各種內(nèi)部指標(biāo)。

2.6 分布式

因為NSQ沒有在守護(hù)程序之間共享信息，所以它從一開始就是為了分布式操作而生。個別的機(jī)器可以隨便宕機(jī)隨便啟動而不會影響到系統(tǒng)的其余部分，消息發(fā)布者可以在本地發(fā)布，即使面對網(wǎng)絡(luò)分區(qū)。

這種“分布式優(yōu)先”的設(shè)計理念意味著NSQ基本上可以永遠(yuǎn)不斷地擴(kuò)展，需要更高的吞吐量？那就添加更多的nsqd吧。唯一的共享狀態(tài)就是保存在lookup節(jié)點上，甚至它們不需要全局視圖，配置某些nsqd注冊到某些lookup節(jié)點上這是很簡單的配置，唯一關(guān)鍵的地方就是消費者可以通過lookup節(jié)點獲取所有完整的節(jié)點集。清晰的故障事件——NSQ在組件內(nèi)建立了一套明確關(guān)于可能導(dǎo)致故障的的故障權(quán)衡機(jī)制，這對消息傳遞和恢復(fù)都有意義。雖然它們可能不像Kafka系統(tǒng)那樣提供嚴(yán)格的保證級別，但NSQ簡單的操作使故障情況非常明顯。

2.7 no replication

不像其他的隊列組件，NSQ并沒有提供任何形式的復(fù)制和集群，也正是這點讓它能夠如此簡單地運行，但它確實對于一些高保證性高可靠性的消息發(fā)布沒有足夠的保證。我們可以通過降低文件同步的時間來部分避免，只需通過一個標(biāo)志配置，通過EBS支持我們的隊列。但是這樣仍然存在一個消息被發(fā)布后馬上死亡，丟失了有效的寫入的情況。

2.8 沒有嚴(yán)格的順序

雖然Kafka由一個有序的日志構(gòu)成，但NSQ不是。消息可以在任何時間以任何順序進(jìn)入隊列。在我們使用的案例中，這通常沒有關(guān)系，因為所有的數(shù)據(jù)都被加上了時間戳，但它并不適合需要嚴(yán)格順序的情況。

2.9 無數(shù)據(jù)重復(fù)刪除功能

NSQ對于超時系統(tǒng)，它使用了心跳檢測機(jī)制去測試消費者是否存活還是死亡。很多原因會導(dǎo)致我們的consumer無法完成心跳檢測，所以在consumer中必須有一個單獨的步驟確保冪等性。

3. 實踐安裝過程

本文將nsq集群具體的安裝過程略去，大家可以自行參考官網(wǎng)，比較簡單。這部分介紹下筆者實驗的拓?fù)洌约皀sqadmin的相關(guān)信息。

3.1 拓?fù)浣Y(jié)構(gòu)

topology

實驗采用3臺NSQD服務(wù)，2臺LOOKUPD服務(wù)。

采用官方推薦的拓?fù)洌l(fā)布的服務(wù)和NSQD在一臺主機(jī)。一共5臺機(jī)器。

NSQ基本沒有配置文件，配置通過命令行指定參數(shù)。

主要命令如下:

LOOKUPD命令

NSQD命令

工具類，消費后存儲到本地文件。

發(fā)布一條消息

3.2 nsqadmin

對Streams的詳細(xì)信息進(jìn)行查看，包括NSQD節(jié)點，具體的channel，隊列中的消息數(shù)，連接數(shù)等信息。

nsqadmin

channel

列出所有的NSQD節(jié)點:

nodes

消息的統(tǒng)計:

msgs

lookup主機(jī)的列表:

hosts

4. 總結(jié)

NSQ基本核心就是簡單性，是一個簡單的隊列，這意味著它很容易進(jìn)行故障推理和很容易發(fā)現(xiàn)bug。消費者可以自行處理故障事件而不會影響系統(tǒng)剩下的其余部分。

事實上，簡單性是我們決定使用NSQ的首要因素，這方便與我們的許多其他軟件一起維護(hù)，通過引入隊列使我們得到了堪稱完美的表現(xiàn)，通過隊列甚至讓我們增加了幾個數(shù)量級的吞吐量。越來越多的consumer需要一套嚴(yán)格可靠性和順序性保障，這已經(jīng)超過了NSQ提供的簡單功能。

結(jié)合我們的業(yè)務(wù)系統(tǒng)來看，對于我們所需要傳輸?shù)陌l(fā)票消息，相對比較敏感，無法容忍某個nsqd宕機(jī)，或者磁盤無法使用的情況，該節(jié)點堆積的消息無法找回。這是我們沒有選擇該消息中間件的主要原因。簡單性和可靠性似乎并不能完全滿足。相比Kafka，ops肩負(fù)起更多負(fù)責(zé)的運營。另一方面，它擁有一個可復(fù)制的、有序的日志可以提供給我們更好的服務(wù)。但對于其他適合NSQ的consumer，它為我們服務(wù)的相當(dāng)好，我們期待著繼續(xù)鞏固它的堅實的基礎(chǔ)。

go語言版本的Gossip協(xié)議包（memberlist）的使用

由于工作的契機(jī)，最近學(xué)習(xí)了下Gossip，以及go語言的實現(xiàn)版本HashiCorp/memberlist。網(wǎng)上有個最基本的memberlist使用的example，在下邊的鏈接中，感興趣可以按照文檔運行下感受感受。本文主要講解memberlist v0.1.5 的使用細(xì)節(jié)。

Gossip是最終一致性協(xié)議，是目前性能最好，容錯性最好的分布式協(xié)議。目前Prometheus的告警組件alertmanager、redis、s3、區(qū)塊鏈等項目都有使用Gossip。本文不介紹Gossip原理，大家自行谷歌。

簡單的幾步即可搭建gossip集群

感謝已經(jīng)有網(wǎng)友為我們實現(xiàn)了一個example（

）。

哪里有問題，還請大家多多指正

當(dāng)前名稱：s3go語言 s3gogoing
URL網(wǎng)址：http://www.chinadenli.net/article22/dooiccc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、用戶體驗、響應(yīng)式網(wǎng)站、ChatGPT、網(wǎng)站維護(hù)、建站公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)