什么是微服務平臺（自己搭建網站平臺）

什么是微服務

如今隨著社交媒體的興起，互聯網的快速發展，應用程序變得越來越復雜，需要處理的任務也越來越多。

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

通過采用微服務架構，人們可以顯著地提高應用程序的靈活性、可擴展性。

微服務總覽

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

這些獨立的單元也叫作插件單元，你可以在需要的時候對它們進行替換和修改，而這些操作不會影響程序的整體工作。

如果你決定實現一個微服務架構，你應該熟悉應用程序生命周期中的各種關注點，如持久化、日志記錄、監控、負載均衡、緩存等，此外你應該知道哪些工具或哪些技術棧更適合您的應用程序。

微服務構成

Docker

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

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

這種服務通過定義多個管理器節點來完成，如果一個節點管理器出現任何故障，其他管理器可以保持應用程序服務可用。

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

API 網關

API 網關可以被視為一種 API 管理工具，它充當您的應用程序服務和不同客戶端之間的中間件。

API 網關可以管理下面這些事情：

路由：網關接收所有 API 請求并將它們轉發到目標服務。

日志記錄：統一記錄所有請求。

授權：檢查用戶是否有權限訪問該服務。

性能分析：估計每個請求的執行時間并檢查您的應用程序瓶頸。

緩存：通過在網關級別處理緩存，可以消除服務上的大量流量。

負載均衡

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

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

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

服務發現

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

事件總線

在微服務架構模式中，您將使用兩種不同類型的通信，同步和異步通信。

同步通信意味著服務通過 HTTP 調用或 GRPC 調用相互調用。

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

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

日志采集

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

監控和警報

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

分布式跟蹤

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

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

結論

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