[[442746]]

什么是微服務(wù)

如今隨著社交媒體的興起，互聯(lián)網(wǎng)的快速發(fā)展，應(yīng)用程序變得越來越復(fù)雜，需要處理的任務(wù)也越來越多。

過去的單體應(yīng)用程序已經(jīng)無法滿足日益增進的技術(shù)需求。因此人們迫切地需要一種技術(shù)架構(gòu)來解決這些問題，于是，微服務(wù)架構(gòu)誕生了。

通過采用微服務(wù)架構(gòu)，人們可以顯著地提高應(yīng)用程序的靈活性、可擴展性。

微服務(wù)總覽

基于微服務(wù)的架構(gòu)有幾個獨立的單元，它們通過彼此的協(xié)同工作來接收和處理來自各種來源的請求。

這些獨立的單元也叫作插件單元，你可以在需要的時候?qū)λ鼈冞M行替換和修改，而這些操作不會影響程序的整體工作。

如果你決定實現(xiàn)一個微服務(wù)架構(gòu)，你應(yīng)該熟悉應(yīng)用程序生命周期中的各種關(guān)注點，如持久化、日志記錄、監(jiān)控、負載均衡、緩存等，此外你應(yīng)該知道哪些工具或哪些技術(shù)棧更適合您的應(yīng)用程序。

微服務(wù)構(gòu)成

Docker

Docker 是一個開源平臺，用于應(yīng)用程序進行打包分發(fā)，其中包含應(yīng)用程序在各種環(huán)境中運行所需的庫和依賴項。在Docker的幫助下，開發(fā)團隊可以將應(yīng)用程序打包成容器。實際上，Docker是容器化應(yīng)用程序的工具之一，這意味著你也可以不使用Docker來創(chuàng)建容器，Docker的真正好處是使這個過程更輕松、更安全、更簡單。

在你容器化你的應(yīng)用之后，你需要一些工具來管理容器化的應(yīng)用來做一些手動和自動化的操作，比如水平擴展。這些工具為你的應(yīng)用管理提供一些服務(wù)，比如自動負載均衡，保證高服務(wù)可用性。

這種服務(wù)通過定義多個管理器節(jié)點來完成，如果一個節(jié)點管理器出現(xiàn)任何故障，其他管理器可以保持應(yīng)用程序服務(wù)可用。

管理 Docker 環(huán)境、配置管理、提供環(huán)境安全等，這些問題可以通過 docker 容器管理工具集中自動化。

API 網(wǎng)關(guān)

API 網(wǎng)關(guān)可以被視為一種 API 管理工具，它充當(dāng)您的應(yīng)用程序服務(wù)和不同客戶端之間的中間件。

API 網(wǎng)關(guān)可以管理下面這些事情：

• 路由：網(wǎng)關(guān)接收所有 API 請求并將它們轉(zhuǎn)發(fā)到目標(biāo)服務(wù)。
• 日志記錄：統(tǒng)一記錄所有請求。
• 授權(quán)：檢查用戶是否有權(quán)限訪問該服務(wù)。
• 性能分析：估計每個請求的執(zhí)行時間并檢查您的應(yīng)用程序瓶頸。
• 緩存：通過在網(wǎng)關(guān)級別處理緩存，可以消除服務(wù)上的大量流量。

負載均衡

實際上，它是作為反向代理工作的，客戶端只需要知道你的網(wǎng)關(guān)，應(yīng)用服務(wù)就可以實現(xiàn)對外隱藏。例如，如果您想記錄服務(wù)的請求和響應(yīng)。如果您的應(yīng)用程序由多個服務(wù)組成，您的客戶端需要知道每個服務(wù)地址，并且在更改服務(wù)地址的情況下，應(yīng)該更新多個地方。

將能夠通過運行更多的服務(wù)實例來處理更多的請求，但問題是，哪個實例應(yīng)該接收請求或者客戶端如何知道哪個服務(wù)實例應(yīng)該處理請求嗎?這些問題的答案是負載平衡。負載均衡意味著在一個服務(wù)實例之間共享收入流量。為了擴展獨立服務(wù)，需要運行多個服務(wù)實例。

使用負載均衡器，客戶端不需要知道服務(wù)的正確實例。

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

隨著你的應(yīng)用服務(wù)數(shù)量越來越多，服務(wù)需要知道彼此的服務(wù)實例地址，但是這在很多的大型應(yīng)用程序中，這是無法處理的。所以我們需要引入服務(wù)發(fā)現(xiàn)，它負責(zé)提供應(yīng)用中所有組件的實際地址，它們可以輕松地向服務(wù)發(fā)現(xiàn)服務(wù)發(fā)送請求并獲取可用的服務(wù)實例地址。當(dāng)你的應(yīng)用中可以有多個服務(wù)時，服務(wù)發(fā)現(xiàn)是一個您的應(yīng)用程序的必備工具。您的應(yīng)用程序服務(wù)不需要知道每個服務(wù)實例地址，這意味著服務(wù)發(fā)現(xiàn)為您鋪平了道路。

事件總線

在微服務(wù)架構(gòu)模式中，您將使用兩種不同類型的通信，同步和異步通信。

同步通信意味著服務(wù)通過 HTTP 調(diào)用或 GRPC 調(diào)用相互調(diào)用。

異步通信意味著服務(wù)通過消息總線或事件總線相互交互，這意味著服務(wù)之間沒有直接連接。

雖然架構(gòu)可以同時使用兩種通信方式，但同時我們也需要服務(wù)之間使用 GRPC 或 HTTP 調(diào)用來獲取響應(yīng)。這些服務(wù)通過事件總線相互交互。此外，如果您需要創(chuàng)建一個能夠插入新服務(wù)以接收一系列特定消息的應(yīng)用程序，則需要使用事件總線。在事件總線中，常用的工具有 RabbitMQ、Kafka。

日志采集

當(dāng)使用微服務(wù)架構(gòu)模式時，最好集中你的服務(wù)日志。這些日志將用于調(diào)試問題或根據(jù)其類型聚合日志以供分析用途。任何需要調(diào)試請求的情況下，如果您不在一個地方收集服務(wù)日志，您可能會遇到困難。您還可以將與特定請求相關(guān)的日志與唯一的相關(guān) ID 相關(guān)聯(lián)。這意味著與請求相關(guān)的不同服務(wù)中的所有日志都可以通過此關(guān)聯(lián) Id.ToolsElastic Logstash 訪問

監(jiān)控和警報

在微服務(wù)架構(gòu)中，如果你想擁有一個可靠的應(yīng)用程序或服務(wù)，你必須監(jiān)控應(yīng)用程序的功能、性能、通信和任何其他方面，以實現(xiàn)一個負責(zé)任的應(yīng)用程序。為什么你需要監(jiān)控整體功能和服務(wù)健康，還需要監(jiān)控性能瓶頸并準(zhǔn)備解決它們的計劃。通過在關(guān)鍵點定義服務(wù)的早期警報來減少服務(wù)的停機時間，從而優(yōu)化用戶體驗。監(jiān)控服務(wù)的整體資源消耗，當(dāng)負載過重時等。

分布式跟蹤

調(diào)試始終是開發(fā)人員最關(guān)注的問題之一，單體調(diào)試很簡單，但是在微服務(wù)架構(gòu)上，因為一個請求可能會通過不同的服務(wù)，這使得調(diào)試和跟蹤變得困難，因為代碼庫不在一個地方，所以這里使用分布式跟蹤工具會很有幫助。

如果沒有分布式跟蹤工具，通過不同的服務(wù)跟蹤您的請求是幾乎不可能。借助OpenTelemetry、Jeager、Zipkin這些工具，您可以借助豐富的 UI 來演示請求的流程，輕松跟蹤請求和事件。

結(jié)論

微服務(wù)是一個非常龐大的技術(shù)，它要求你懂得很多技術(shù)棧，一開始你可能摸不清頭緒，不過這都不要緊，當(dāng)你完整接觸或者使用過一個微服務(wù)的架構(gòu)之后，你就會對它慢慢有所了解，并且能夠知道為什么微服務(wù)需要那些技術(shù)，因為每一個技術(shù)都是為了解決某個技術(shù)出現(xiàn)的，沒有過多的設(shè)計，一切都是剛剛好。