一張圖看懂微服務架構路線
我爲什麼選擇微服務架構？
衆所周知，單體應用程序，由於其種種不足，幾乎不支持敏捷方法。如果你想爲一個大型或複雜的業務創建一個軟件項目，最好從微服務架構開始。
微服務架構是一種靈活的架構，可以顯著性地提高應用程序靈活性、可擴展性等。
微服務架構路線
據我瞭解很多開發者，想知道他們應該如何開始微服務架構旅程，雖然有成千上萬的資源可以使用，但是資源到處分散。我決定通過爲微服務架構學習定義路線圖，使這段旅程更加清晰。
基本思路
基於微服務的架構通常有幾個獨立的單元，它們協同工作以接收和處理各種請求。這個複雜的某些部分可以是插件，這意味着在需要的情況下，你可以在不干擾應用程序的整體工作情況下， 新增一個新插件或刪除一個插件。
例如，如果你決定實現一個微服務架構，你應該熟悉應用程序生命週期中的各種關注點，如持久化、日誌記錄、監控、負載均衡、緩存等，此外你還應該知道哪些哪些工具比較好或哪些堆棧更適合你的應用程序。
本文，我將從以下幾個方面來介紹各種關注點
它是什麼？
我爲什麼要使用它？
哪些工具比較好？
請注意，我在哪些工具比較好部分提到了兩三個哪些工具比較好，當然，我們還有很多其他哪些工具比較好，選擇這些哪些工具比較好的標準是業務需求，受歡迎程度、性能、開源以及更新頻率。
再次注意，我們還有基於雲的服務，這不在本文討論的範圍內。
本文，我用上圖作爲架構圖示例。這個圖涉及到大部分微服務架構組件，雖然不是也很全面，但是微服務架構的標準模型。
本文將會介紹微服務架構的關注點有：
Docker
容器編排
Docker 容器管理
API 網關
負載均衡
服務發現
事件總線
日誌記錄
監控和警報
分佈式追蹤
數據持久化
緩存
雲供應商
Docker
它是什麼：
Docker 是一個開源平臺，用於容器化你的應用程序，其中包含你的應用程序在各種環境中運行所需的類庫和依賴項。在 Docker 的幫助下，開發團隊能夠將應用程序打包到容器中。
我爲什麼要使用它：
實際上，Docker 是容器化應用程序的哪些工具比較好之一，你也可以在不使用 Docker 的情況下創建容器，Docker 的真正好處是使這個過程更容易、更安全、更簡單。
哪些工具比較好：
Docker
容器編排
它是什麼：
在容器化應用程序後，你將需要一些哪些工具比較好來管理容器化應用程序，以執行一些手動和自動操作，例如水平擴展。
我爲什麼要使用它：
這些哪些工具比較好爲你的應用程序管理提供一些服務，例如自動負載均衡，保證服務的高可用性。
這種服務是通過定義多個管理器節點來完成的，如果一個節點管理器出現任何故障，其他管理器可以保持應用程序服務可用。
哪些工具比較好：
Kubernetes or K8s，Docker Swarm
Docker 容器管理
它是什麼：
管理 Docker 環境、配置、安全等。
我爲什麼要使用它：
爲用戶提供了一個基於 GUI 的 Docker 容器管理，可以使他們不必處理不舒服的 CLI。這些工具也爲開發人員提供了豐富的 UI 來構建和發佈他們的鏡像，還可以通過提供簡化的用戶界面來更輕鬆地執行一些操作任務，例如服務水平擴展。
哪些工具比較好：
Portainer , DockStation, Kitematic,Rancher
API 網關
它是什麼：
API 網關可以被視爲一種充當你的應用程序服務和不同客戶端之間的中間件。API 網關可以管理許多事情，例如：
Routing ：網關接收所有 API 請求並將它們轉發到目標服務。
Logging ：你將能夠在一處記錄所有請求。
Authorization: 檢查你作爲用戶是否有資格訪問該服務，如果沒有，可以拒絕該請求
Performance profiling：你可以估計每個請求的執行時間並檢查你的應用程序瓶頸。
Caching：通過在網關級別處理緩存，你將消除服務上的大量流量。
事實上，它是作爲一個反向代理工作的，客戶端只需要知道你的網關，應用服務就可以隱藏起來，不直接向其他系統暴露。
我爲什麼要使用它：
如果沒有 API 網關，你可能需要在每個服務中做一些橫切關注點，例如，如果你想記錄服務的請求和響應。此外，如果你的應用程序由多個服務組成，你的客戶端需要知道每個服務地址，並且在更改服務地址的情況下，應該更新多個地方。
哪些工具比較好：
Kong，Ocelot
負載均衡
它是什麼：
我們選擇微服務架構最重要的原因是可擴展性，這意味着我們將能夠通過運行更多服務實例來處理更多請求，但問題是，哪個實例應該接收請求，或客戶端如何知道哪個服務實例應該處理請求？
這些問題的答案是負載均衡。負載均衡是高可用網絡基礎架構的關鍵組件, 通常用於將工作負載分佈到多個服務器來提高網站、應用、數據庫或其他服務的性能和可靠性。
我爲什麼要使用它：
爲了擴展你的獨立服務，你需要運行多個服務實例。使用負載均衡器，客戶端不需要知道服務的正確實例。
哪些工具比較好：
Traefik , NGINX,Seesaw
服務發現
它是什麼：
隨着你的應用服務的數量越來越多，服務需要知道彼此的服務實例地址，但是在有很多服務的大型應用中，這是無法處理的。因此我們需要服務發現，它負責提供應用程序中所有組件的地址，它們可以輕鬆地向服務發現系統發送請求並獲取可用的服務實例地址。
我爲什麼要使用它：
當你的應用程序中可以有多個服務時，服務發現對於你的應用程序來說是必不可少的。你的應用服務不需要知道每個服務實例地址，這意味着服務發現爲你鋪平了道路。
哪些工具比較好：
Consul，Zookeeper，Eureka，etcd 和 Keepalived
事件總線
它是什麼：
在微服務架構模式中，你將使用兩種不同類型的通信，同步通信以及異步通信。同步通信是指服務之間通過 HTTP 或 GRPC 相互調用。異步通信意味着服務通過消息總線或事件總線相互交互，這意味着服務之間沒有直接連接。
你的架構可以同時使用兩種通信方式，例如在在線商店示例中，你可以在訂單註冊時發送消息，並且訂閱了特定頻道的服務將收到該消息。但有時你可能需要一些實時的查詢，例如，你需要知道一個物品的數量，你可能會在服務之間使用 GRPC 或 HTTP 調用來獲取響應。
我爲什麼要使用它：
如果你想要一個包含多個服務的可擴展應用程序，你將遵循的原則之一是創建鬆散耦合的服務，這些服務通過事件總線相互交互。此外，如果你需要創建一個能夠插入新服務以接收一系列特定消息的應用程序，則需要使用事件總線。
哪些工具比較好：
RabbitMQ，Kafka
日誌記錄
它是什麼：
使用微服務架構模式時，最好將服務日誌集中起來。這些日誌將用於調試問題或根據其類型聚合日誌以供分析使用。
我爲什麼要使用它：
系統調試時，如果沒有提前集中在一個地方收集服務日誌，你可能會遇到困難。你還可以將與特定請求相關的日誌與唯一的相關 ID 關聯。這意味着與請求相關的不同服務中的所有日誌都可以通過此關聯 ID 訪問。
哪些工具比較好：
Elastic Logstash
監控和警報
它是什麼：
在微服務架構中，如果你想要一個可靠的應用程序或服務，你必須監控應用程序的功能、性能、通信和任何其他方面，以實現一個負責任的應用程序。
我爲什麼要使用它：
你需要監控整體功能和服務健康狀況，還需要監控性能瓶頸，並準備解決故障的計劃。通過在關鍵點定義服務的早期警報來減少服務的停機時間，從而優化用戶體驗。當負載較重時等，可以監控服務的整體資源消耗。
哪些工具比較好：
Prometheus , Kibana,Graphana
分佈式追蹤
它是什麼：
調試始終是開發人員最關心的問題之一，因爲你都有跟蹤或調試單體引用程序的經驗。那是非常直接和容易，但是在微服務架構上，因爲一個請求可能會通過不同的服務，這使得調試和跟蹤變得困難，因爲服務不在一個地方，所以分佈式追蹤工具將會有所幫助。
我爲什麼要使用它：
如果沒有分佈式跟蹤哪些工具比較好，通過不同的服務跟蹤你的請求會令人沮喪或不可能。你可以藉助用於演示請求流的豐富 UI 輕鬆跟蹤請求和事件。
哪些工具比較好：
OpenTelemetry , Jeager,Zipkin
數據持久化
它是什麼：
在大多數系統中，我們需要持久化數據，將應用程序的數據寫入具有不同結構的物理文件中，以便數據用於進一步的處理或報告。
我爲什麼要使用它：
在單體應用程序中，我們曾經有一種或兩種不同的持久性類型，大多數單體應用程序使用關係數據庫，如 SQL Server、Oracle、MySQL。但是在微服務架構中，我們應該遵循 “DataBase Per Service” 模式，這意味着保持每個微服務的持久數據對該服務是私有的，並且只能通過其 API 訪問。
對於不同的用途和場景，你將擁有不同的數據庫。例如，數據展示服務可能會使用像 ElasticSearch 或 MongoDB 這樣的 NoSQL 數據庫，因爲它們使用文檔基礎結構，這意味着這些數據庫中持久化數據的結構與關係數據庫不同，更適用於具有讀多寫少的服務。
另一方面，在某些微服務中，你可能需要 Oracle 或 SQL SERVER 等關係數據庫，或者你可能還需要一些支持圖結構或鍵值結構的數據庫。
所以，在微服務架構中，根據服務的使命，你會需要不同類型的數據庫。
哪些工具比較好：
關係數據庫或 RDBMS : PostgreSQL, MySQL, SQL SERVRE, Oracle
NoSQL 數據庫 : MongoDB, Cassandra,Elasticsearch
緩存
它是什麼：
緩存減少了微服務架構的服務到服務通信的延遲。緩存是高速數據存儲層。當從緩存中請求數據時，它的速度比訪問硬盤中的數據要快。
我爲什麼要使用它：
在微服務架構中，有許多策略可以通過這些方式實現緩存。考慮以下：
1：嵌入式緩存（分佈式和非分佈式）
2：客戶端 - 服務器緩存（分佈式）
3：反向代理緩存（Sidecar）
爲了減少延遲，可以在不同的層中實現緩存。此外，你還可以實現分佈式緩存，它可以被多個微服務訪問。它們還有不同的用途，比如限流，限流的目的是通過對併發訪問 / 請求進行限速或者一個時間窗口內的的請求進行限速來保護系統，一旦達到限制速率則可以拒絕服務。。
哪些工具比較好
Redis (Remote Dictionary Server), Apache Ignite,Hazelcast IMDG
雲供應商
它是什麼：
雲服務提供商是一個第三方公司，提供基於雲的平臺，基礎設施，應用程序或存儲服務。就像房主爲電力或天然氣等公用事業付費一樣，公司通常只需根據業務需求爲他們使用的雲服務數量付費。
雲提供商最重要的類別：
軟件即服務 (SaaS)。
平臺即服務 (PaaS)。
基礎設施即服務 (IaaS)。
我爲什麼要使用它
使用雲計算服務的一個好處是，公司可以避免搭建和維護自己的 IT 基礎設施的前期成本和複雜性，而只需在使用時爲所用的東西付費。今天，公司可以租用從應用程序到存儲的任何東西，而不是擁有自己的計算基礎設施或數據中心。
哪些工具比較好
Amazon Web Services (AWS), Microsoft Azure, Google Cloud,Alibaba Cloud
結論
在本文中，我試圖展示一個與微服務架構模式相關的路線圖。如果你想從頭開始實現微服務架構或將單體架構遷移到微服務架構，你將需要了解這些概念。
除了這些概念之外，我們還有其他概念，如服務網格、緩存、持久性，它們可能是本路線圖的一部分，但爲了簡單起見，我故意沒有提及它們。
參考：https://www.kubernetes.org.cn/9711.html
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/NE7sSEa7bvatWmdd8QfZSg