目錄
一張圖看懂微服務架構路線
我為什麼選擇微服務架構？
眾所周知，單體應用程式，由於其種種不足，幾乎不支援敏捷方法。如果你想為一個大型或複雜的業務建立一個軟體專案，最好從微服務架構開始。
微服務架構是一種靈活的架構，可以顯著性地提高應用程式靈活性、可延伸性等。
微服務架構路線
據我瞭解很多開發者，想知道他們應該如何開始微服務架構旅程，雖然有成千上萬的資源可以使用，但是資源到處分散。我決定通過為微服務架構學習定義路線圖，使這段旅程更加清晰。
基本思路
基於微服務的架構通常有幾個獨立的單元，它們協同工作以接收和處理各種請求。這個複雜的某些部分可以是外掛，這意味著在需要的情況下，你可以在不干擾應用程式的整體工作情況下， 新增一個新外掛或刪除一個外掛。
例如，如果你決定實現一個微服務架構，你應該熟悉應用程式生命週期中的各種關注點，如持久化、紀錄檔記錄、監控、負載均衡、快取等，此外你還應該知道哪些哪些工具比較好或哪些堆疊更適合你的應用程式。
本文，我將從以下幾個方面來介紹各種關注點
它是什麼？
我為什麼要使用它？
哪些工具比較好？
請注意，我在哪些工具比較好部分提到了兩三個哪些工具比較好，當然，我們還有很多其他哪些工具比較好，選擇這些哪些工具比較好的標準是業務需求，受歡迎程度、效能、開源以及更新頻率。
再次注意，我們還有基於雲的服務，這不在本文討論的範圍內。
本文，我用上圖作為架構圖範例。這個圖涉及到大部分微服務架構元件，雖然不是也很全面，但是微服務架構的標準模型。
本文將會介紹微服務架構的關注點有：
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
結論
在本文中，我試圖展示一個與微服務架構模式相關的路線圖。如果你想從頭開始實現微服務架構或將單體架構遷移到微服務架構，你將需要了解這些概念。
除了這些概念之外，我們還有其他概念，如服務網格、快取、永續性，它們可能是本路線圖的一部分，但為了簡單起見，我故意沒有提及它們。
譯文連結： Making a Microservice Architecture Roadmap - DZone Microservices
