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

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

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

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

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

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

Hydra簡介

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

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

圖1

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

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

圖2

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

Hydra如何使用Redis？

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

圖3

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

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

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

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

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

鍵空間組織

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

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

圖4

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

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

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

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

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

圖5

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

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

圖6

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

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

存在

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

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

圖7

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

我們可以使用帶模式匹配的“keys”命令來查詢存在鍵。請注意有三個鍵。這告訴我們“asset-svcs”的三個實例在運行。

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

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

圖8

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

這引出了下一個話題......

健康

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

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

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

圖9

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

圖10

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

圖11

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

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

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

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

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

圖12

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

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

圖13

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

圖14

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

接下來討論路由。

路由

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

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

圖15

服務(wù)路由存儲在Set結(jié)構(gòu)中。這很適合，因為你不需要重復(fù)的路由條目。使用SADD命令和SMEMBERS命令。

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

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

圖16

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

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

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

負載均衡

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

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

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

圖17

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

消息傳送

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

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

圖18

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

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

圖19

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

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

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

圖20

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

這是UMF消息示例。 

圖21

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

看看這實際上如何使用。

在左邊，“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)、負載均衡、路由和pub/sub細節(jié)抽取出來。收發(fā)消息只涉及三個成員函數(shù)。這里有必要暫停一下?；c時間考慮使用你最喜歡的架構(gòu)，這個示例將會是什么樣子。

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

圖23

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

圖24

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

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

下面討論消息隊列。

隊列

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

然后，服務(wù)實例可以讀取其隊列和進程項。

隊列消息的內(nèi)容是UMF消息，它遵循用于消息傳送的同一種格式?；ゲ僮餍酝瑯幼钪匾?！

Hydra按照服務(wù)類型自動創(chuàng)建三個隊列。

*“收到”的隊列

*“處理中”的隊列

*“未完成”的隊列

因為這些是列表，我們使用Redis“lpush”、“rpush”、“rpoplpush”和“lrem”命令。

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

 

圖25

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

圖26

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

日志

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

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

圖27

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

圖28

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

最后說說配置管理。

配置管理

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

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

圖29

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

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

圖30

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

總結(jié)

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

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

原文標題：Building Light-weight Microservices using Redis，作者：Carlos Justiniano

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