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