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