【51CTO.com快譯】Hydra是一個(gè)輕量級(jí)NodeJS庫，用于構(gòu)建微服務(wù)之類的分布式計(jì)算應(yīng)用程序。我們對(duì)輕量級(jí)的定義是：外部復(fù)雜性低、基礎(chǔ)設(shè)施依賴項(xiàng)少。Hydra之所以基礎(chǔ)設(shè)施依賴項(xiàng)少，是由于唯一的外部依賴項(xiàng)是Redis。

要是你讀到本文，卻從未聽說過Redis（這種可能性極小），不妨先了解一下redis.io。稍后再回到此文。

Hydra使用Redis豐富的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)重要的微服務(wù)所需要的功能，比如存在、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、消息傳送和隊(duì)列等功能。

Hydra也很輕巧。實(shí)際上，輕巧得足以在售價(jià)5美元的Raspberry Pi Zero上運(yùn)行。想了解更多信息，請(qǐng)參閱：https://medium.com/flywheel-tech/embracing-microservices-11750470ba31。

除了輕巧外，Hydra還是構(gòu)建微服務(wù)的最簡單方法之一。雖然本文不會(huì)介紹Hydra，外面已有好多介紹它的資源，但會(huì)深入介紹Hydra如何利用Redis構(gòu)建輕量級(jí)微服務(wù)。

先聲明一下。首先，本文介紹的方法可能不是很適合你的項(xiàng)目。你可能需要較笨重的微服務(wù)。那沒關(guān)系。我介紹的方法已在Flywheel Sports及另外眾多公司得到了證實(shí)。我之前寫過一篇文章，詳細(xì)敘述了為什么我們構(gòu)建Hydra、它在構(gòu)建全國性直播視頻流服務(wù)中起到的作用。

Hydra簡介

Hydra是一個(gè)NodeJS模塊，可以導(dǎo)入到JavaScript Node應(yīng)用程序，從而為它們賦予微服務(wù)功能。Hydra通過使用Redis做到這一點(diǎn)。

下面我們看到三個(gè)微服務(wù)，每個(gè)都有連接到Redis的Hydra模塊。在此模型中，大多數(shù)服務(wù)不直接與Redis聯(lián)系，而是底層的Hydra模塊充當(dāng)Redis的代理。 

圖1

該圖的另一個(gè)要點(diǎn)是，Hydra只是另一個(gè)導(dǎo)入的模塊，就像圖中所示的綠色框。Hydra僅在底部以藍(lán)色顯示，表明其存在和與Redis的連接。

Hydra模塊公開了一個(gè)JS類接口，共有36個(gè)成員函數(shù)。 

圖2

上圖讓人大致了解我們所用抽象機(jī)制的簡易性。findService比sendMessage等成員函數(shù)相當(dāng)簡單。

Hydra如何使用Redis？

這張幻燈片顯示了許多重要的微服務(wù)問題。每個(gè)都是重要的微服務(wù)所必需的。我們會(huì)詳細(xì)研究Hydra如何使用Redis實(shí)現(xiàn)這每項(xiàng)功能。 

圖3

請(qǐng)記住，此處的目的是表明如何可以執(zhí)行這項(xiàng)任務(wù)，不是說每種方法都要你搞清楚如何在自己的服務(wù)中實(shí)現(xiàn)該功能。一個(gè)典型例子是，雖然可以將微服務(wù)配置數(shù)據(jù)存儲(chǔ)在Redis中或使用Redis作為日志記錄器，但這并不意味著你應(yīng)該這么做。除非你確切知道自己在做什么、由此帶來的缺點(diǎn)，否則別這么做。

另外請(qǐng)記住，你不需要Hydra。Redis使這每一項(xiàng)功能成為可能，你當(dāng)然可以在自己的應(yīng)用程序中這么做。

我要表明的另一個(gè)要點(diǎn)是，其中一些功能只有結(jié)合起來，才有可能實(shí)現(xiàn)。比如說，請(qǐng)求和消息路由依賴狀態(tài)、運(yùn)行狀況、服務(wù)發(fā)現(xiàn)和負(fù)載均衡。

如你所知，可以使用各種基礎(chǔ)設(shè)施工具來滿足這每一項(xiàng)功能。然而，Hydra的一大目標(biāo)是簡化微服務(wù)的構(gòu)建，同時(shí)盡量減少對(duì)外部基礎(chǔ)設(shè)施的需求。你在構(gòu)建生產(chǎn)就緒服務(wù)時(shí)，要決定需要哪些Hydra功能、可以從其他工具獲得哪些功能。這不是非此即彼的選擇，而是兼顧你想要實(shí)現(xiàn)什么功能、多快可以入手。

話雖如此，看看如何僅使用Redis和你青睞的編程語言實(shí)現(xiàn)所有這些功能還是饒有趣味。

鍵空間組織

想了解Hydra如何使用Redis，第一步是分析它如何組織管理Redis鑰空間的使用。

Hydra使用的鍵由2到4個(gè)由冒號(hào)字符分隔的段標(biāo)簽組成。段標(biāo)簽名為：Prefix（前綴）、Service name（服務(wù)名）、Instance ID（實(shí)例ID）和Type（類型）。 

圖4

Prefix段允許過濾Hydra鍵與非Hydra鍵。所以如果你頻繁使用Redis，能夠過濾特定的鍵很重要。

Service Name段幫助過濾特定服務(wù)類型的鍵。比如授權(quán)、用戶或圖像處理等服務(wù)類型。

Instance ID段允許過濾獨(dú)特服務(wù)實(shí)例的鍵。運(yùn)行微服務(wù)時(shí)，你通常需要某個(gè)服務(wù)類型的多個(gè)實(shí)例在運(yùn)行。為每個(gè)服務(wù)實(shí)例分配獨(dú)特的ID，能夠區(qū)別它們很有用。

最后還有Type段，用于對(duì)鍵的用途進(jìn)行分類。并非每個(gè)鍵都有全部的段。比如說，一些鍵不需要Service Name和Instance ID。

下面這個(gè)例子顯示了用戶服務(wù)的鍵。我們看到前綴是hydra:service，后面跟著服務(wù)名（這里是“user-svcs”）。接下來，我們看到獨(dú)特的實(shí)例ID。最后，我們看到這個(gè)鍵的類型是存在。所以，我們說存在信息存儲(chǔ)在這個(gè)鍵地址中。 

圖5

前面一個(gè)令人困惑的地方是，鍵由名稱組成，2到4個(gè)段標(biāo)簽由冒號(hào)字符分隔。然而，這里我們看到hydra:service也被冒號(hào)字符分隔。其想法是，可能還有另外的hydra:other類型，service只是其中之一。還有另一個(gè)涉及消息傳送的不一致，稍后會(huì)討論。我們打算在Hydra 2.0中解決這些問題，那將是突破性的變化，但內(nèi)部更整潔。

我們可以輸入redis-cli并輸入Redis命令來查看各種鍵。我們將會(huì)在該演示文稿的其余部分介紹這方面的示例。 

圖6

簡要說一下我們將使用的redis-cli示例：你會(huì)看到鍵命令的使用，Hydra內(nèi)部使用Redis scan命令。

所以回顧一下，Hydra使用鍵是按段組織的，這使得查詢來得更容易。此外，一致的組織使它們更容易擴(kuò)展和維護(hù)。我們會(huì)在下面看到鍵在組織每個(gè)微服務(wù)功能中起到的作用。不妨先從存在說起。

存在

在微服務(wù)世界，能夠發(fā)現(xiàn)服務(wù)，并了解服務(wù)是否健康、可以路由至關(guān)重要。那些功能取決于知道特定服務(wù)實(shí)例確實(shí)存在并可供使用。服務(wù)發(fā)現(xiàn)、路由和負(fù)載均衡等功能也需要這種功能。

每隔一秒，Hydra更新服務(wù)鍵的生存時(shí)間（TTL）。如果在3秒鐘內(nèi)沒有更新將導(dǎo)致鍵到期失效、主機(jī)應(yīng)用程序被視為不可用。 

圖7

我們在這里可以看到所用的Redis命令是“get”和“setex”，用于設(shè)置鍵和失效日期。

我們可以使用帶模式匹配的“keys”命令來查詢存在鍵。請(qǐng)注意有三個(gè)鍵。這告訴我們“asset-svcs”的三個(gè)實(shí)例在運(yùn)行。

如果我們嘗試檢索其中一個(gè)鍵的內(nèi)容，可以看到它包含實(shí)例ID。

而針對(duì)該鍵使用TTL命令可顯示，它還有2秒就到期失效。 

圖8

所以回顧一下，可以使用自動(dòng)到期失效的鍵來管理微服務(wù)存在。Hydra代表主機(jī)服務(wù)自動(dòng)更新鍵。這意味著這不是開發(fā)人員做的事情。未能在3秒內(nèi)更新鍵導(dǎo)致服務(wù)被視為不可用。這可能意味著服務(wù)不健康。

這引出了下一個(gè)話題......

健康

能夠監(jiān)控微服務(wù)的健康狀況是另一項(xiàng)重要功能。Hydra每隔5秒就收集并寫入健康信息快照。

你可以查看快照，瀏覽一下各個(gè)服務(wù)實(shí)例的健康狀況。另外，HydraRouter儀表板之類的監(jiān)控工具可以使用快照。

所以這是健康的鍵的樣子。注意，唯一的新內(nèi)容是“type”段，它識(shí)別鍵處于健康狀況。 

圖9

我們查看鍵的內(nèi)容時(shí)，看到它含有字符串化的JSON對(duì)象。在這種情況下，它代表“project-svcs”。 

圖10

對(duì)JSON進(jìn)行非字符串化可以更容易查看存儲(chǔ)的內(nèi)容。它含有許多有用的信息。 

圖11

所以，可以存儲(chǔ)每個(gè)服務(wù)實(shí)例的健康信息。它使用包含字符串化的JSON文本的字符串鍵來加以管理。監(jiān)控應(yīng)用程序可以使用該信息。

服務(wù)發(fā)現(xiàn)

接下來不妨考慮服務(wù)發(fā)現(xiàn)，這是任何微服務(wù)架構(gòu)的另一項(xiàng)必備功能。

能夠按名稱發(fā)現(xiàn)某服務(wù)的IP和PORT位置，這大大簡化了通信。其他優(yōu)點(diǎn)包括沒必要管理DNS條目或創(chuàng)建固定的路由規(guī)則。

服務(wù)發(fā)現(xiàn)信息存儲(chǔ)在類型是“nodes”的Redis Hash中。使用Hash可以實(shí)現(xiàn)快速查詢。我們使用Redis“hget”、“hset”和“hgetall”等命令來處理節(jié)點(diǎn)哈希。 

圖12

下列Redis操作可用于實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)功能。第一個(gè)操作是查詢特定的服務(wù)類型。第二個(gè)操作是查詢可用實(shí)例。第三個(gè)操作讓Hydra得以檢索關(guān)于特定服務(wù)實(shí)例的信息。

我們可以看到有用的信息，比如服務(wù)版本、Instance ID、IP地址和端口，最后還有主機(jī)名。在這個(gè)示例中，主機(jī)名也恰好是Docker Container ID。 

圖13

我們可以使用Redis“hgetall”命令檢索關(guān)于所有可用實(shí)例的信息。這是Hydra Router檢索服務(wù)列表以便在儀表板上顯示的方式。 

圖14

回顧一下。Hydra使用servicename鍵段進(jìn)行查詢，以便發(fā)現(xiàn)關(guān)于服務(wù)的各種信息。服務(wù)細(xì)節(jié)可使用Redis Hash來加以管理，Redis Hash提供了極快的服務(wù)發(fā)現(xiàn)。

接下來討論路由。

路由

路由HTTP和消息（比如Web Socket或PubSub）需要路由得到驗(yàn)證。微服務(wù)可以向Redis發(fā)布路由。比如說，HydraRouter使用已發(fā)布的路由來實(shí)現(xiàn)可感知服務(wù)的動(dòng)態(tài)路由。

每個(gè)服務(wù)都在類型“service:routes”的鍵中發(fā)布路由。這里我們看到“asset-svcs”路由的鍵。 

圖15

服務(wù)路由存儲(chǔ)在Set結(jié)構(gòu)中。這很適合，因?yàn)槟悴恍枰貜?fù)的路由條目。使用SADD命令和SMEMBERS命令。

順便說一句，Redis豐富的數(shù)據(jù)結(jié)構(gòu)集合是我與諸位得以分享的原因之一。

回到路由。我們可以使用鍵模式來獲取路由列表。這里我們看到許多服務(wù)的路由。 

圖16

我們可以使用“smembers”命令來查看特定路由集的內(nèi)容。順便說一下，括號(hào)內(nèi)的[get]、[post]和[put]部分代表HTTP REST端點(diǎn)。如果是其他消息傳送技術(shù)，可忽略使用括號(hào)方法。

回顧一下。每個(gè)服務(wù)向Redis Set發(fā)布其路由。訪問單個(gè)路由可顯示該服務(wù)的路由條目集合。

使用Set數(shù)據(jù)結(jié)構(gòu)將路由存儲(chǔ)在Redis中，這避免了重復(fù)路由。已發(fā)布的路由可用于實(shí)現(xiàn)可感知服務(wù)的動(dòng)態(tài)路由。接下來討論負(fù)載均衡。

負(fù)載均衡

隨著應(yīng)用程序日益龐大，你需要在可用的服務(wù)實(shí)例之間對(duì)請(qǐng)求進(jìn)行負(fù)載均衡。這通過Redis、使用上述的服務(wù)存在和路由功能來實(shí)現(xiàn)。在應(yīng)用程序?qū)用妫褂肏ydra，這跟使用“makeAPIRequest”或“sendMessage”調(diào)用一樣簡單。負(fù)載均衡在那些調(diào)用里面進(jìn)行，因?yàn)镠ydra使用路由和狀態(tài)信息來選擇可用的目標(biāo)實(shí)例。

一個(gè)好處是，在路由期間，如果請(qǐng)求在特定實(shí)例上失效，Hydra能夠在最終出現(xiàn)HTTP 503服務(wù)器不可用錯(cuò)誤之前重試其他可用實(shí)例。

如你所見，負(fù)載均衡依賴其他功能，比如狀態(tài)、服務(wù)發(fā)現(xiàn)和路由。 

圖17

回顧一下，對(duì)服務(wù)之間的請(qǐng)求進(jìn)行負(fù)載均衡可使用我們見過的存在、服務(wù)發(fā)現(xiàn)和路由等功能來完成。Redis Strings、Hashes和Sets使這成為可能。整體大于各部分之和。

消息傳送

分布式服務(wù)被迫通過底層網(wǎng)絡(luò)相互聯(lián)系。HTTP Rest調(diào)用可能最常見，但套接字消息傳送可能高效得多。Hydra中的消息傳送使用Redis Pub/Sub頻道來完成，Redis通過套接字連接實(shí)現(xiàn)Pub/Sub。

這是一個(gè)示例鍵。Hydra使用Redis“subscribe”、“unsubscribe”和“publish”等命令。 

圖18

另外，Hydra路由工具能夠通過HTTP和WebSockets接受消息，并將它們轉(zhuǎn)換成pub/sub消息。

想了解這是如何工作的，不妨考慮兩個(gè)服務(wù)：“asset-svcs”和“project-svcs”。每個(gè)服務(wù)都創(chuàng)建兩個(gè)鍵，一個(gè)鍵使用服務(wù)名，另一個(gè)鍵使用服務(wù)名和實(shí)例ID。每個(gè)服務(wù)都監(jiān)聽兩個(gè)頻道。 

圖19

在大多數(shù)情況下，你不關(guān)心服務(wù)的哪個(gè)實(shí)例處理請(qǐng)求。這種情況下，使用的是沒有特定實(shí)例ID的那個(gè)頻道。

現(xiàn)在，你需要向特定實(shí)例發(fā)送消息時(shí)，可以使用有實(shí)例ID的那個(gè)頻道。值得注意的是，進(jìn)行負(fù)載均衡時(shí)，hydra將針對(duì)服務(wù)名的請(qǐng)求轉(zhuǎn)換成帶特定實(shí)例ID的請(qǐng)求。這確保只有一個(gè)實(shí)例處理特定的消息或請(qǐng)求。

我們可以使用Redis pub / sub channels命令查看頻道鍵列表。注意，我們這里有四個(gè)鍵。第一個(gè)鍵是“asset-svcs”的名稱，由資產(chǎn)服務(wù)的所有實(shí)例共享。接下來，我們看到另外三個(gè)有獨(dú)特實(shí)例ID的鍵。三個(gè)服務(wù)實(shí)例各一個(gè)。 

圖20

繼續(xù)關(guān)注消息傳送。為了確保微服務(wù)之間互操作，統(tǒng)一共同的通信格式至關(guān)重要。通用消息格式是一種基于JSON的文檔格式，它包括支持消息傳送、路由和隊(duì)列。這些消息以JSON字符串化文本的形式存儲(chǔ)在Redis中。

這是UMF消息示例。 

圖21

“to”、“frm”和“bdy”等字段是必需的，服務(wù)可以在“bdy”對(duì)象中隨意包含各自的自定義字段。

看看這實(shí)際上如何使用。

在左邊，“client-svcs”向“project-svcs”發(fā)送消息。注意，這只需要UMF創(chuàng)建調(diào)用和發(fā)送消息調(diào)用，此處以黃色顯示。

在右邊，“project-svcs”監(jiān)聽消息，必要的話處理消息。這使用事件消息監(jiān)聽器來完成。 

圖22

注意，Hydra將服務(wù)發(fā)現(xiàn)、負(fù)載均衡、路由和pub/sub細(xì)節(jié)抽取出來。收發(fā)消息只涉及三個(gè)成員函數(shù)。這里有必要暫停一下。花點(diǎn)時(shí)間考慮使用你最喜歡的架構(gòu)，這個(gè)示例將會(huì)是什么樣子。

更仔細(xì)地分析一下。發(fā)送消息的機(jī)理是，解析消息中的“to”字段，以確定目標(biāo)服務(wù)名。有了服務(wù)名，下一步是檢查可用實(shí)例。有了目標(biāo)實(shí)例，消息隨后字符串化，并通過Redis“publish”命令發(fā)送出去。 

圖23

我們再次列出Redis中的所有Pub/Sub頻道。消息可以通過這些頻道發(fā)送，并由監(jiān)聽器檢索。所以編寫一點(diǎn)代碼，我們就可以使用Redis，借助一堆井然有序的頻道來路由消息。 

圖24

總之，值得注意的是，消息傳送最終必不可少，因?yàn)榉?wù)是物理分布的。Redis使用其pub/sub功能來實(shí)現(xiàn)消息傳送。

標(biāo)準(zhǔn)化通信讓服務(wù)之間能夠互操作。我們還看到了將底層的服務(wù)發(fā)現(xiàn)、負(fù)載均衡、路由和pub/sub等細(xì)節(jié)抽取出來后，應(yīng)用程序?qū)用娴耐ㄐ攀嵌嗝慈菀住?/p>

下面討論消息隊(duì)列。

隊(duì)列

作業(yè)和消息隊(duì)列是許多重要應(yīng)用程序的另一個(gè)重要部分。Hydra使用Redis為每種服務(wù)類型維護(hù)動(dòng)態(tài)隊(duì)列。

然后，服務(wù)實(shí)例可以讀取其隊(duì)列和進(jìn)程項(xiàng)。

隊(duì)列消息的內(nèi)容是UMF消息，它遵循用于消息傳送的同一種格式。互操作性同樣最重要！

Hydra按照服務(wù)類型自動(dòng)創(chuàng)建三個(gè)隊(duì)列。

*“收到”的隊(duì)列

*“處理中”的隊(duì)列

*“未完成”的隊(duì)列

因?yàn)檫@些是列表，我們使用Redis“lpush”、“rpush”、“rpoplpush”和“lrem”命令。

該圖顯示了隊(duì)列之間的消息流。各項(xiàng)在隊(duì)列之間的移動(dòng)是Redis中的原子操作。因此，無論你有多少微服務(wù)，它都很安全。

圖25

在左邊的下一個(gè)示例中，對(duì)消息進(jìn)行排隊(duì)就像創(chuàng)建UMF消息并調(diào)用“queueMessage”來發(fā)送一樣簡單。右下方的代碼顯示圖像處理服務(wù)通過調(diào)用“getQueuedMessage”使消息出列，然后處理消息完畢后調(diào)用“markQueueMessage”。這有多容易？ 

圖26

回顧一下，有時(shí)，期待立即響應(yīng)是不現(xiàn)實(shí)的。在這種情況下，我們只需要將以后處理的工作排入隊(duì)列。Redis List數(shù)據(jù)結(jié)構(gòu)可用作消息隊(duì)列。像“lpush”和“rpoplpush”這些原子操作的命令讓這成為可行。這里我們再次看到使用較高級(jí)的抽象實(shí)現(xiàn)基本的隊(duì)列操作有多容易。

日志

分布式日志是任何微服務(wù)架構(gòu)的另一項(xiàng)重要特性。然而，如果你了解Redis，可能會(huì)驚訝于將它用作分布式日志記錄器的想法。你可能很擔(dān)心，這很正常。然而，你可以將它用作飛行記錄器。你只存儲(chǔ)最嚴(yán)重的錯(cuò)誤，并使用“lpush”和“ltrim”限制條目數(shù)量。此后，至少你可以快速檢查微服務(wù)出了什么問題。

這是鍵的樣子。注意鍵類型是health:log。 

圖27

這里我們看到health:log鍵類型實(shí)際上是“List”數(shù)據(jù)結(jié)構(gòu)。因此，我們可以使用Redis“lrange”命令查看“imageproc-svcs”的飛行記錄器日志。 

圖28

回顧一下：對(duì)于微服務(wù)而言，數(shù)十個(gè)乃至數(shù)百臺(tái)機(jī)器上有日志是不可行的。分布式日志記錄絕對(duì)是出路。使用Redis，你可以構(gòu)建一個(gè)輕量級(jí)日志記錄器，用作飛行記錄器。使用Redis List數(shù)據(jù)結(jié)構(gòu)以及方便的“lpush”和“ltrim”命令使這成為可能。

最后說說配置管理。

配置管理

管理分布式微服務(wù)的配置文件具有挑戰(zhàn)性。然而，你甚至可以使用Redis來存儲(chǔ)服務(wù)的配置文件。我們就是這么做的，當(dāng)時(shí)看來似乎是個(gè)好主意。然而，我們開始拋棄這種做法。由于主要的缺點(diǎn)是在Redis中存儲(chǔ)配置使Redis有狀態(tài)（stateful），而這不太理想。不過這是可行的，所以我想告訴諸位。

不妨看看它如何工作。有一個(gè)configs鍵類型是個(gè)哈希值。該哈希值有一個(gè)鍵由服務(wù)版本以及針對(duì)該版本的配置數(shù)據(jù)所設(shè)的值組成。 

圖29

這是示例配置。以本文為例，我們使用一個(gè)名為“hydra-cli”的命令行工具，它讓我們得以將配置文件推送到特定的服務(wù)版本。這一切是為了用鍵創(chuàng)建一個(gè)哈希值條目，而這個(gè)鍵由服務(wù)名和版本以及作為字符串化值的文件內(nèi)容組成。記住，你還可以使用shell腳本來驅(qū)動(dòng)redis cli。

我們可以使用“hget”命令和配置版本來提取特定版本。 

圖30

簡單回顧一下，我們看到了Redis如何用于存儲(chǔ)應(yīng)用程序配置文件。Redis Hash數(shù)據(jù)結(jié)構(gòu)讓我們得以為每種服務(wù)類型存儲(chǔ)配置。每個(gè)配置條目都由服務(wù)版本標(biāo)簽來索引，內(nèi)容只是指向字符串化的JSON配置。

總結(jié)

不知不覺篇幅寫了這么多。但總的來說，我在這里分享的是一種使用JavaScript和NodeJS高度依賴Redis的方法。然而，沒有什么能阻止大家使用其他語言做同樣的事情。又由于Hydra是開源的（https://www.npmjs.com/package/hydra），它可以充當(dāng)這類工作的參考平臺(tái)。

我很高興地宣布，我們在開發(fā)一款受Hydra啟發(fā)的Golang版本，我們希望盡快開源。我們還在考慮開發(fā)Java版本。

原文標(biāo)題：Building Light-weight Microservices using Redis，作者：Carlos Justiniano

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】