PS：全套前端課程私信我免費領(lǐng)取

什么是微服務(wù)

微服務(wù)是一種應(yīng)用架構(gòu)，它將每個應(yīng)用功能都放在自己的服務(wù)中，與其他服務(wù)隔離。這些服務(wù)是松散耦合的，可獨立部署。

這種架構(gòu)的出現(xiàn)是為了解決舊的 Web 應(yīng)用開發(fā)的單體方法。在單體軟件中，所有的東西都是作為一個單元構(gòu)建的，所有的業(yè)務(wù)邏輯都被歸入一個廣泛的應(yīng)用。

這種方法使更新代碼庫的過程變得復(fù)雜化，因為它影響到整個系統(tǒng)，即使是最小的代碼改動也需要構(gòu)建和部署整個軟件的新版本。此外，哪怕你只想擴展應(yīng)用的某個特定功能，卻需要擴展整個應(yīng)用來實現(xiàn)它。

微服務(wù)解決了單體系統(tǒng)所面臨的這些挑戰(zhàn)，它將應(yīng)用從一個整體分割成幾個小部分。

什么時候應(yīng)該使用微服務(wù)？

從本質(zhì)上講，微服務(wù)架構(gòu)解決了龐大、復(fù)雜應(yīng)用的快速開發(fā)問題。

對于“哪個更好？”這一問題，目前還沒有通用的答案。答案取決于各種情況，因為每一種情況都有其好處和缺點。

下面是一些微服務(wù)架構(gòu)的優(yōu)點和缺點，你可能對此已經(jīng)有所了解：

優(yōu)點

• 語言不可知性：微服務(wù)并不限于特定的編程語言，每個微服務(wù)都可以用不同的語言來編寫，以支持選定的通信協(xié)議。

• 可擴展性：由于微服務(wù)和它的職責(zé)可以由開發(fā)者共同承擔(dān)，所以如果有一個大的團隊參與到這個項目中，應(yīng)用就會變得更加易于維護。

• 無限迭代：由于開發(fā)者不會被其他組件所束縛，所以在微服務(wù)上迭代會變得更加簡單。

• 單元測試：由于微服務(wù)是獨立的應(yīng)用，它的重點是特定的功能，因此，開發(fā)者可以很輕松地編寫測試腳本，以驗證該特定功能。

缺點

• 要作為一個整體來管理是很困難的：凱撒大帝有一句名言“分而治之”（divide et impera，拉丁語），即使在這里也可以大規(guī)模應(yīng)用，但是要謹慎，因為過多的活動部分會變得難以管理。

• 難以追蹤：如果架構(gòu)變得過于復(fù)雜，微服務(wù)之間的通信渠道會非常多，出現(xiàn)錯誤后會很難追溯并確定故障點。

• 需要大量的專業(yè)知識：構(gòu)建和部署微服務(wù)要求非常高的計劃和協(xié)調(diào)方面的軟技能。

• 具有挑戰(zhàn)性的測試：測試是一把雙刃劍，因為微服務(wù)作為一個整體更難測試。集成和端到端的測試同樣會有挑戰(zhàn)。

• 審計日志：可能更難獲得和調(diào)查。

在架構(gòu)方面，SaaS 微服務(wù)非常適合，因為微服務(wù)是 SaaS 應(yīng)用的一個不錯的選擇。由于這類應(yīng)用想要用戶付錢買單，那么它就需要提供高可用的服務(wù)，因此將軟件分成小塊可以加快恢復(fù)速度。同時，SaaS 應(yīng)用的發(fā)展主要是由其社區(qū)推動，所以，它也會受到很多變化的影響，而通過微服務(wù)和解耦，開發(fā)者可以獲得了靈活性，這是單體架構(gòu)無法提供的。

單體應(yīng)用程序可能難以水平擴展，因為你必須復(fù)制整個應(yīng)用程序，如果它依賴于單個數(shù)據(jù)庫，這個過程將變得更加困難。另一邊，微服務(wù)卻可以根據(jù)單個服務(wù)進行擴展、復(fù)制或負載平衡。比如，如果你需要發(fā)送更多的電子郵件，你只需要擴展負責(zé)電子郵件功能的微服務(wù)。今天你有 10 個用戶，明天你有 1000 個；SaaS 應(yīng)用可以在短時間內(nèi)維持大規(guī)模的增長，這就是為什么他們的架構(gòu)必須要以最經(jīng)濟的方式進行輕松擴展的原因。

這樣還可以減少資源的消耗，因此可以減少賬單。所以，可以肯定地說，微服務(wù)是 SaaS 企業(yè)架構(gòu)的下一個階段。

弄清你是否需要微服務(wù)的最好方法是問自己：我有關(guān)于單體應(yīng)用的問題嗎？如果有的話，或許你應(yīng)該考慮轉(zhuǎn)向微服務(wù)。如果沒有，那就堅持下去——沒有必要把時間花在一個根本不存在的問題上。

微服務(wù)通信是如何工作的？

由于服務(wù)之間彼此獨立，所以與微服務(wù)的通信需要好好選擇。通信協(xié)議的使用不當(dāng)會造成應(yīng)用的性能下降，大家必須根據(jù)自己應(yīng)用的具體需求來選擇通信協(xié)議。

有兩種通信方式可以選擇：同步通信和異步通信，這是請求 - 響應(yīng)和基于事件的模式的基礎(chǔ)。

在第一種情況下，即同步方式，客戶端發(fā)送請求并等待響應(yīng)。這種方法有一個缺陷，那就是它是一個阻塞模式。但是，如果你有一個讀操作非常多的應(yīng)用時，那就不一定了，因為你的應(yīng)用更傾向從外部讀取和接受信息。在這種情況下，使用同步方式可能是一個很好的選擇，特別是當(dāng)它涉及實時數(shù)據(jù)時。

我們的另一個選擇是異步通信，這是一個非阻塞模式。如果你想要一種有彈性的微服務(wù)，那么，與同步通信相比，異步通信是一種更好的選擇。在這種情況下，客戶端會發(fā)送一個請求，收到請求的確認，并將其遺忘。這種方法最適用于大量寫操作、無法承受數(shù)據(jù)記錄丟失的應(yīng)用。

下面是一些涉及微服務(wù)通信的解決方案，你可以從中選擇：

• 基于 HTTP 的 REST

• 基于 HTTP/2 的 REST

• WebSocket

• TCP 套接字

• UDP 數(shù)據(jù)包

好好考慮最適合自身需求的通信協(xié)議，因為這將使應(yīng)用響應(yīng)更快、效率更高。

為什么 NodeJS 用于微服務(wù)？

在構(gòu)建微服務(wù)時，有很多頂級編程語言可供選擇。NodeJS 就是其中之一。那么，為什么 NodeJS 是最佳選擇呢？

• 單線程 & 異步：NodeJS 使用事件循環(huán)來執(zhí)行代碼，允許異步代碼被執(zhí)行，從而使服務(wù)器能夠使用非阻塞機制來響應(yīng)。

• 事件驅(qū)動：NodeJS 使用事件驅(qū)動架構(gòu)，該架構(gòu)建立在軟件開發(fā)的常見模式上，被稱為發(fā)布 - 訂閱或觀察者模式，能夠構(gòu)建強大的應(yīng)用，尤其是實時應(yīng)用。

• 快速和高度的可擴展性：運行環(huán)境建立在最強大的 JavaScript 引擎之一 V8 JavaScript Engine 之上，因此代碼執(zhí)行速度快，使得服務(wù)器能夠同時處理多達 10000 個并發(fā)請求。

• 易于開發(fā)：創(chuàng)建多個微服務(wù)會導(dǎo)致重復(fù)的代碼。Node.js 的微服務(wù)框架很容易創(chuàng)建，因為它抽象了大部分的底層系統(tǒng)。所以用這種編程語言創(chuàng)建一個微服務(wù)可以像寫幾行代碼一樣簡單。

實施微服務(wù)架構(gòu)

我們從創(chuàng)建用于用戶管理的微服務(wù)開始，它將使用 TCP 數(shù)據(jù)包進行通信，并負責(zé)對用戶進行 CRUD 操作。我們將使用 PacketSender 對其進行測試，PacketSender 是一個免費的工具，用于發(fā)送支持 TCP 的網(wǎng)絡(luò)數(shù)據(jù)包。

微服務(wù)的架構(gòu)和作用域被進一步界定。因此，從演示的角度來看，通過 HTTP 實現(xiàn)一個微服務(wù)與實現(xiàn) NodeJS API 沒有什么不同。

同時，通過 HTTP 來使用 REST 也很容易，但如果從這個協(xié)議切換到其他協(xié)議時，會出現(xiàn)一些問題。這也是本文中我們將會使用 TCP 包的異步模式來與微服務(wù)通信的原因。

我們將使用 NestJS 作為應(yīng)用的框架。它并非 NodeJS 微服務(wù)框架，而是一個用于構(gòu)建服務(wù)器端應(yīng)用的框架。但是，由于其內(nèi)置了多個微服務(wù)特性，使得工作變得更加容易。

步驟一：微服務(wù)設(shè)置

用 Node.js 構(gòu)建微服務(wù)相當(dāng)容易，尤其是用 NestJS 框架。開始時，可以使用 CLI 創(chuàng)建一個新的 NestJS 應(yīng)用，使用如下命令：

該命令會創(chuàng)建并初始化一個新項目。要開始構(gòu)建一個微服務(wù)，你需要安裝以下軟件包：

最后，為了讓微服務(wù)啟動和運行，我們需要用以下內(nèi)容更新 main.ts 文件：

NestJS 支持幾個內(nèi)置的傳輸層實現(xiàn)，稱為傳輸器。上面的代碼將創(chuàng)建一個微服務(wù)，通過 TCP 傳輸層綁定到本地機器的 8875 端口進行通信。

步驟 2：微服務(wù)監(jiān)聽消息

我們可以使用消息模式或事件模式來與微服務(wù)通信。

消息模式的作用就像一個請求 - 響應(yīng)方法，它適用于在服務(wù)之間交換消息，而當(dāng)你只想發(fā)布事件而不等待響應(yīng)時，就可以使用事件模式。

在我們的案例中，我們只實現(xiàn)根據(jù)給定的輸入創(chuàng)建一個用戶的功能，并且將獲得創(chuàng)建的用戶。因此，我們將在 app.controller.ts 文件中注冊一個名為 create_user 的消息模式。

我們抽象出創(chuàng)建新用戶的邏輯，因為它可以根據(jù)需求和使用的數(shù)據(jù)庫以各種方式實現(xiàn)，我們將只關(guān)注與微服務(wù)相關(guān)的主題。

我們用來創(chuàng)建一個新用戶的有效負載有以下格式：

一個帶有 email 和 password 的簡單對象

步驟 3：測試微服務(wù)

為了測試這個微服務(wù)，我們將使用 PacketSender 向應(yīng)用發(fā)送一個 TCP 包。為此，將地址和端口設(shè)置為 127.0.0.1:8875，并從右側(cè)的下拉菜單中選擇 TCP。要對我們的信息進行編碼，請使用 ASCII 字段，并用以下值來完成：

pattern：是我們正在尋找的信息，create_user。

data：是我們要發(fā)送的 JSON 對象，一個帶有 email 和 password 的對象。

值 122 代表我們的消息的長度，從第一個大括號開始到最后一個大括號（包括兩個）。

數(shù)據(jù)包發(fā)送器配置

如果我們點擊 Send 按鈕，我們會看到如下日志：

日志活動

第二個是我們發(fā)送給微服務(wù)的內(nèi)容，第一個是我們收到的內(nèi)容。里面的響應(yīng)是由我們的微服務(wù)返回的對象，即被創(chuàng)建的用戶。

步驟 4：API 網(wǎng)關(guān)

現(xiàn)在我們有了微服務(wù)，并進行了快速測試，看它是否能接收請求并返回響應(yīng)，現(xiàn)在是時候創(chuàng)建一個 API 網(wǎng)關(guān)并將其連接到微服務(wù)上了。

為此，我們將使用上面描述的相同步驟創(chuàng)建一個新的 NestJS 應(yīng)用，然后用以下內(nèi)容更新 app.module.ts 文件。

我們將使用 .env 文件，我們將在其中存儲任何與配置有關(guān)的值。這些文件將在一個配置服務(wù)的幫助下被讀取。該微服務(wù)可以在 host 127.0.0.1:8875 處找到，其中 port 為 8875。

通過上面的代碼，我們使用 ClientProxy 注入一個新的對象，代表與我們的用戶 - 微服務(wù)的連接。這個 NestJS 類提供了幾個內(nèi)置的工具來與遠程微服務(wù)交換信息。

為了使用這個鏈接對象，我們可以在 AppController 或 AppService 中注入它，如下所示：

現(xiàn)在，每次 API 在路由 create-user 處受到 POST 請求時，API 網(wǎng)關(guān)將把請求和有效載荷一起轉(zhuǎn)發(fā)給微服務(wù)，然后從微服務(wù)返回響應(yīng)給用戶。