[[442746]]

什么是微服務(wù)

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

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

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

微服務(wù)總覽

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

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

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

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

Docker

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

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

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

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

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ù)。
• 性能分析：估計(jì)每個(gè)請求的執(zhí)行時(shí)間并檢查您的應(yīng)用程序瓶頸。
• 緩存：通過在網(wǎng)關(guān)級別處理緩存，可以消除服務(wù)上的大量流量。

負(fù)載均衡

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

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

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

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

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

事件總線

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

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

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

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

日志采集

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

監(jiān)控和警報(bào)

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

分布式跟蹤

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

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

結(jié)論

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