[MICROSERVICES] 訊息佇列和 REST – 採用 Go、NodeJS 和 Clean 架構的方法-Golang-PHP中文網

1.簡要背景
2.技術與整體架構
2.1。微服務架構
2.2。微服務之間的通信
2.2.1。訊息隊列（非同步通訊）
2.2.2。 REST API（同步通訊）
2.3。乾淨的架構
3.專案生態系統
4.挑戰與最終考慮因素
4.1。實施中的挑戰
4.2。下一步
4.3。結論
5.參考
6.免責聲明

1. 簡要背景

近年來，微服務架構已成為建構可擴展、靈活和可維護系統的熱門選擇。透過將應用程式劃分為更小的獨立服務，可以自主維護、測試和升級每個服務，從而促進可擴展性和新技術的融入。

在本文中，我們將探索使用 Go 和 NodeJS 建立微服務架構，這兩種廣泛使用的語言在這種情況下具有互補的特性。此外，我們將應用清潔架構的原則，這是一種旨在保持程式碼清潔、模組化且易於維護和測試的設計方法，確保業務邏輯與基礎設施問題和/或依賴項隔離。

這個計畫的目標是練習Go（我最近在學習的語言），並重新檢視微服務的基本概念。同時，我們將在服務開發中使用 TypeScript，應用 Clean Architecture 的原則來強化良好的軟體設計實務。

基於這些前提，我們將有機會探討這種方法的優點和挑戰。畢竟，並不是每個業務都需要如此複雜的結構，而實際的專案是了解其真正需求和影響的最佳方式。

2. 技術與總體架構

2.1 微服務架構

微服務架構將應用程式分割成較小的、獨立的服務，每個服務負責功能的特定部分。這些服務透過定義明確的 API 進行通信，這有利於維護、可擴展性和新技術的採用。

好處：

模組化：方便各服務的維護與獨立開發。
可擴展性：允許根據需求單獨擴展每個服務。
彈性：隔離故障並減少一項服務中的問題對其他服務的影響。
與整體式架構的比較：

單體應用程式：整合到單一程式碼庫中的應用程式。雖然最初很簡單，但隨著時間的推移，它們可能會變得難以維護和擴展。

微服務：它們提供了更大的靈活性和可擴展性，但可能會增加服務之間的管理和通訊的複雜性。

2.2 微服務之間的通信

在微服務架構中，服務之間的通訊可以透過兩種主要方式完成：非同步通訊（例如使用訊息佇列）和同步通訊（透過 REST API）。值得強調的是，除了排隊和休息之外，還有其他形式的溝通。

2.2.1 訊息佇列（非同步通訊）

訊息佇列用於實現微服務之間的非同步通訊。它們允許服務發送和接收訊息而無需立即回應，這有助於提高系統彈性和可擴展性。

訊息隊列的作用：

非同步通訊：促進服務之間的資訊交換，無需即時回應。
彈性：管理負載尖峰和臨時故障，確保訊息最終得到處理。

實作：

工具：RabbitMQ 和 Kafka 是管理訊息佇列的常用選項。
整合：實作Go和NodeJS編寫的服務之間通訊的訊息佇列，確保高效率且可擴展的資料交換。

2.2.2 REST API（同步通訊）

RESTful API 用於服務之間的同步通訊。它們基於 HTTP 原則，允許服務以標準化、高效的方式互動。

2.3 簡潔的架構

清潔架構是一種設計方法，旨在創建具有易於維護和/或測試的組織良好的程式碼庫的系統。它強調關注點分離和層獨立性。

清潔架構原則：

層分離：將程式碼分割為不同的層（域、應用程式、基礎設施），以將業務邏輯與技術問題隔離。
獨立於框架和函式庫：確保業務邏輯不依賴特定的框架或技術。
微服務中的應用：

程式碼組織：依照清潔架構的原則建構每個微服務，以確保程式碼模組化、可測試且易於維護。
維護和演進：在不損害系統完整性的情況下促進新功能的添加和現有功能的修改。

3. 專案生態系統

在微服務生態系統中，HTTP 端點在編排文件工作流程中發揮著至關重要的作用，在這種情況下，它是一切的開始。此端點負責接收和處理建立新文件的請求。收到請求後，它將文件排隊到 Go 工作線程，後者將負責產生和處理文件。此外，端點透過訊息佇列向文件服務發出通知，通知有新資源（即文件）已進入佇列進行處理。這種方法確保了系統組件之間的高效集成，允許端點以協調和異步的方式管理文檔的創建和跟踪，而Go 工作線程則負責文檔的實際創建，並且文檔服務根據文檔中的新項目進行更新。排隊。

除了 HTTP 端點之外，系統還有兩個具有不同角色的工作人員。第一個是用 Go 實現的，負責產生文件。它使用訊息佇列中的任務，處理數據，並在處理完成後通知特定端點完成。 Go 的效率確保了快速、穩健的處理。第二個工作程序是用 NodeJS 開發的，負責處理文件初始狀態的創建，將它們插入系統時將其定義為「未處理」。 NodeJS 的敏捷性允許從工作流程一開始就快速有效地管理文件狀態。

總之，所描述的系統展示了一個協調良好的文件管理流程。 HTTP 端點與 Go 和 NodeJS Workers 一起提供了一個整合且高效的解決方案，保證文件處理從創建到完成。工作人員和 REST 之間的交互反映在下面的架構圖中，該圖說明了該架構如何促進可擴展性和模組化，從而確保穩健且協調的工作流程。這種方法不僅提高了營運效率，還可以適應不同的使用場景，提供靈活性和未來的成長。

最終圖：

[MICROSERVICES] Message Queues e REST – Uma Abordagem com Go, NodeJS e Clean Architecture

專案儲存庫：https://github.com/williamMDsilva/microservice-poc

4. 挑戰和最終考慮因素

4.1 實施中的挑戰

使用清潔架構實現微服務架構可能會帶來一些挑戰。主要挑戰之一是對業務的深入理解，以創建真正可擴展並保持業務邏輯完整性的程式碼。乾淨的架構要求以明確分離關注點的方式建立程式碼，這需要對領域的詳細了解才能有效地進行抽象和分離。

此外，SOLID 原則的知識也至關重要。這些原則有助於創建更具凝聚力、更少耦合的程式碼，並且對它們的深入理解可以節省大量的研究和故障排除時間。應用SOLID原則不僅可以提高程式碼品質，而且有利於系統維護和可擴充性。

就Go的具體情況而言，紮實的語言基礎可以提高程式碼的可讀性和可維護性。 Go 提供的工具和實踐有助於保持程式碼整潔和高效，更深入的知識可以在實現複雜服務時發揮作用。

最後，使用好的樣板是非常有益的。精心設計的清潔架構樣板不僅可以加快開發的啟動速度，還可以確保在最初提出的標準中添加新功能。它們提供了一種有助於在整個專案中保持程式碼一致性和品質的結構。

4.2 後續步驟

為了推進和改進所描述的架構，建議採取一些後續步驟：

包括監控和可觀察性資源：實施監控和可觀察性工具對於確保系統健康和效能至關重要。納入指標、日誌和追蹤有助於識別問題並分析生產中的系統行為。
增加針對不可用的處理：增加處理故障和不可用的機制（例如重試、熔斷器和回退策略）至關重要，以提高系統的彈性並確保服務的連續性。
執行單元和整合測試：測試對於確保程式碼品質和組件的正確整合至關重要。單元測試驗證程式碼中孤立部分的功能，而整合測試則確保系統的不同組件能夠正確地協同工作。
重構服務和模組：審查和重構現有服務和模組以確保程式碼保持乾淨、可讀並符合清潔架構原則是一項持續的任務，可以提高系統的可維護性和可擴展性。
Kafka 概念驗證：考慮 Kafka 取代 RabbitMQ 的概念驗證可以深入了解不同工具如何影響專案。對服務設計和整體架構的影響分析可以為未來的技術決策提供有價值的見解。

4.3 結論

該專案展示了精心規劃的架構的有效性以及仔細實施清潔架構原則的重要性。 Go 和 NodeJS 的使用，結合 SOLID 等實踐以及訊息佇列和 REST API 的使用，有助於建立一個強大且可擴展的系統。然而，開發和維護微服務架構提出了挑戰，需要深入了解業務和技術。透過充分的規劃和採用良好實踐來應對這些挑戰有助於確保建立高效和永續的系統。前進的道路包括整合持續改進，例如先進的監控和新的概念證明，以使架構與業務的需求和發展保持一致。