6大資料庫挖掘7種業務場景的儲存更優解九曲黃河萬里沙

雲服務快速入門指南

介紹

6大資料庫挖掘7種業務場景的儲存更優解九曲黃河萬里沙

download：

https：//www。51xuebc。com/thread-516-1-1。html

微產品團隊將繼續為您提供微服務快速入雲的指導文件，以便開發者和朋友們更好地使用騰訊雲微服務產品。內容通俗易懂，使用方便。這是本系列的第一篇文章。歡迎觀看。

微服務架構

下圖顯示了一個典型的微服務架構。從圖中可以看出，請求從前端進來後，通常會有一個閘道器接受所有的請求。該閘道器通常具有負載均衡功能和一些與流量路由相關的功能。然後閘道器會把請求轉發給後端微服務，然後服務之間的呼叫會涉及到服務的註冊和發現。需要一個註冊中心來管理所有的註冊和發現，並且需要以一種統一的方式來管理服務的所有配置。此時，還需要一個配置中心來管理所有服務的配置。在服務的過程中，可能需要做熔絲限流、動態路由等操作，這些操作可能會用到服務治理相關的框架或工具來幫助我們完成。同時，在整個過程中，我們需要完善的監測資料來幫助我們排除故障。最後，這些服務呼叫底層資料庫，如MongoDB、MySQL或其他中介軟體訊息佇列等。、和上述內容組合成如下所示的典型微服務架構。

應用場景

上述微服務架構下可以使用哪些應用場景？

微服務場景1：搭建一個安全、可靠、強大的業務閘道器。

典型的Web架構：Nginx閘道器

典型的基於Nginx的web架構是什麼樣的？如上圖所示，你可以看到網頁、小程式、app的請求進來後，會經過一個負載均衡的過程，然後把請求轉發給Nginx，Nginx負責把請求轉發給後端的web服務，可能是PHP、Tomcat等。這個過程是典型的web架構。

典型的微服務架構：服務閘道器

典型的微服務架構是什麼樣的？除了上圖所示的Nginx和負載均衡，通常還會有一個服務閘道器。如圖所示，Spring Cloud Gateway將作為服務閘道器來訪問後端服務。服務閘道器通常會配合服務註冊中心做閘道器直達服務的自動發現，從而實現閘道器直達服務的需求。

微服務Nginx入口

在另一個場景中，微服務入口模式與K8s合作，在閘道器級別建立入口控制器，負責從閘道器直接服務底層服務和K8s控制檯的場景。

以上三個是閘道器級微服務架構下的典型應用場景。除了閘道器，微服務場景還涉及註冊和配置中心。

微服務場景2：構建輕量級、高可用、可擴充套件的微服務架構。

微服務核心元件=閘道器+註冊中心+配置中心

如上圖所示，除了閘道器之外，我們還將與註冊和配置中心合作管理所有的服務例項，並且在此過程中還將涉及監控和鏈路跟蹤的使用，以幫助我們更好地檢查業務操作和故障排除。最後，我們將訪問底層資料庫和一些中介軟體。這個過程中用到的註冊中心的使用場景是怎樣的？

註冊中心：使用場景

服務和發現

提供者向服務註冊後，消費者可以發現服務，服務消費者透過服務註冊中心呼叫提供者。

客戶端健康檢查

第二個場景是客戶端健康檢查。如果有100個服務，如何確認這100個服務都正常執行？這時，我們可以使用登錄檔來實現客戶端健康檢查。註冊中心提供健康檢查的能力，並基於心跳報告保持其活動。如果伺服器在x秒內沒有收到客戶端的心跳請求，它會將例項設定為不健康，如果在x秒內沒有收到心跳，它會刪除臨時例項。確保服務的可用性。

內部網DNS訪問

最後一種場景是透過註冊中心提供DNS訪問能力，支援以域名的形式公開註冊中心的資料。客戶端可以透過域名定址直接呼叫直連服務，無需使用CLB轉發。

以上是註冊中心的幾種使用場景。我們來看看配置中心。

配置中心：使用場景

配置中心的使用場景大致可以分為兩類。

業務配置

1。第一種情況：在啟動新功能時，如果要根據區域使用者等資訊進行灰度，可以透過配置中心動態管理想要的灰度條件。

2。第二種情況：促銷活動的時候，一般會有抽獎，中獎機率，引數控制。我們期望是實時動態控制，這個時候可以透過配置中心來實現。

3。第三種情況：可以透過配置中心動態顯示公告。

基本元件配置

例如，在開發過程中，將使用資料庫訪問鍵、日誌設定或其他元件設定引數。這些引數可以透過配置中心統一管理，不需要修改每個服務，減少工作量。

生產階段：保證多活動和容災。

在典型的微服務架構中，它涉及網關注冊和配置中心以及服務本身。如何保證整體架構的多產品容災？然後就會有下面的部署架構。雲原生閘道器和註冊與配置中心可以幫助業務架構實現多活動和災難恢復：

雲原生閘道器的伺服器和註冊配置中心部署在同一個城市的三個可用區域。

業務應用程式可以部署在同一城市的多個可用區域。一個應用程式的多個節點被部署在不同的可用區域，並在同一服務下注冊。

圖中紅線是可用區域的分界線，上圖顯示了三個可用區域。為了實現架構的高可用性，有必要確保所使用的每個元件都部署在可用區域中。比如我們的閘道器會在這三個可用區域部署一個節點，然後我們的服務本身也會跨可用區域部署，在多個可用區域部署不同的節點，所以在註冊和配置中心也是一樣的。每個註冊和配置中心將部署三個節點，然後所有節點將同時跨可用區域部署，以便在實際業務場景中任何一個都可用。

微服務應用場景三：實現全鏈路的流量和服務治理。

測試階段：解決多測試環境下的流量路由問題。

如何解決測試環境下的流量路由問題？

從上圖我們想解決什麼問題？開發者開發微服務時，可能會有多個服務。如果他們想進行聯合除錯，他們通常會將所有服務部署在一個環境中，然後進行端到端測試。但是，如果有更多的服務，並且開發團隊並行工作，就很難協調。

理想的情況是多個測試環境能否以一種方式共存，同時只需要按需部署。那麼，不同的團隊可以透過使用不同的環境來滿足這樣的測試需求嗎？答案是肯定的，就是用TSE雲原生閘道器加服務治理來實現這種多環境的流量路由。那麼做法是怎樣的呢？

首先，該示例透過服務治理標記了環境標籤。如上圖所示，測試環境分為三個環境。第一個是基線環境，這是通常為測試而部署的服務，還有兩個特性環境。第一組使用左側特徵環境，第二組使用右側特徵環境。當一個團隊想要測試時，只需要將需要測試的服務部署到左邊的特性環境中。然後將這些部署的例項標記為feature1，然後在雲原生閘道器觸發請求時，將請求標記為feature1，這樣這個請求就可以自動路由到我們標記的例項上，實現流量的路由。同時，在路由的過程中，也可以實現跨環境的標籤路由。比如我從左邊特徵環境訪問基線環境，然後機器線環境可以根據標籤路由返回到這個特徵環境，從而實現多測試環境的流量路由問題。

應用場景：微服務應用開發測試時，不需要部署所有服務，只部署本次發生變化的服務，其他服務透過流量動態路由複用基線環境服務資源。

優勢：

節約資源成本，按需申請開發/測試，用完後扔掉。

提高R&D效率，擺脫域名本地繫結主機等大量配置工作。

實施方案

1。示例標記

K8s註冊場景：向工作負載新增pod標籤，以標記環境。

微框架註冊場景：服務下的所有例項都是分組的，可以透過標籤區分部署環境。

2。流動染色

雲原生閘道器可以染流量特徵。例如，染色特定uin的請求。

3。從閘道器到後端服務的流量路由

透過標籤路由，根據請求中的測試環境資訊動態路由。

4。後端服務和服務之間的路由

鏈路上的每個服務可以根據請求流量特徵在不同的測試環境中動態地路由服務。

釋放階段：金絲雀，滾動或藍綠色釋放。

在另一種微服務架構下，涉及的問題是釋出。

目前比較流行的出版方式有三種，一種是金絲雀出版，一種是滾動出版，一種是藍綠出版。這三種常見的出版策略都基於相同的原則。他們都期望所有要釋出的新版本在釋出的過程中都經過絕對的測試，讓所有使用者避免說我的新版本有任何問題都會影響到所有使用者。但是在釋出的過程中，這三種釋出方式的策略會有些不同。

金絲雀釋放

Canary release是按比例升級這個版本，有一定的例子。如果沒有問題，那麼逐步釋放這個比例，直到所有的流量最終達到V2版，從而實現金絲雀。

滾動出版

對於此次釋出的服務，首先升級一個/batch例項，然後批次升級其餘例項，直到所有例項都升級到V2版本。

藍色版本

綠色釋出就是把例項分成兩個陣營，一個綠營，一個藍營。執行例項的版本是V-1。放在綠營。此時，一個新的例項V2版本被部署到藍營。然後，對V2版本進行全面測試。測試沒問題後，透過負載均衡把流量從V1切到V2，實現了無縫釋出，保證了新版本上線環境的全面測試。

釋出階段：全連結灰度

透過以上釋出策略，我們可以達到另一個想要的效果，那就是全連結灰度。

全連結灰度是什麼意思？比如我們在使用微信的時候，可能會遇到這樣的情況，我有一些新功能，別人沒有。其實你已經被選為灰度使用者，正在測試新功能。只有在灰度環境下測試新功能時，所有使用者才會使用該功能。

如何在微服務的框架下達到這種效果？首先，我們需要將部署的例項在生產環境中分為兩個環境，一個是正式環境，一個是灰色環境。如果要升級，需要測試要升級的服務的灰度。以前面提到的方式部署新例項後，透過例項標記的方式將其標記為灰度環境中的例項。例如，標記版本是V2。這時候你只需要在請求進來的時候，把閘道器級別想要灰度的使用者的流量染了。例如，將上海的使用者標記為V2。那麼上海使用者的所有流量都會進入灰度環境進行灰度測試。灰度環境測試沒有問題。然後所有的業務都會被部署，然後所有的流量都會被切到灰階環境，這樣整個灰階就實現了。這可以幫助我們實現端到端的環境測試，隔離流量隧道，一鍵切斷流量。

優越性

全鏈路隔離車道

端到端的穩定環境

一鍵流切割

可觀察性

實施方案

1。示例標記

K8s註冊場景：向工作負載新增pod標籤來標記版本。

微框架註冊場景：服務下的所有例項都是分組的，可以透過標籤區分版本。

2。流動染色

用灰度顯示閘道器流量特徵。有兩種方式：動態染色和靜態染色。

3。從閘道器到後端服務的流量路由

透過標籤路由，流量根據請求中的服務版本資訊進行轉發。

4。後端服務和服務之間的路由

在鏈路上，每個服務可以根據請求流量特徵動態路由。

生產階段：走訪附近，劫後餘生。

在生產階段，微服務的架構有兩個重要的場景。第一個是就近參觀，第二個是居住和容災。

最近的訪問是什麼？一般微服務專案會部署在不同的區域。比如在上海和廣州部署一個微服務專案。一個上海的使用者想訪問這個服務，但是請求被轉發到廣州，由於地理原因會造成一定的網路延遲。那麼我們肯定希望上海的使用者訪問上海的服務例項，廣州的使用者訪問廣州。此時，我們需要使用最近的訪問，這有助於我們在地理上標記部署的例項。在例項上標註地理資訊，這樣當有請求進來的時候，就可以根據這個地理資訊找到最近的例項來提供這種就近訪問的能力。

多活動容災分為兩個層面，第一個是做入口層面的多活動容災，第二個是做應用層面的多活動容災。先說入口層，如下圖。我們在閘道器級別的後端連線不同的可用區域。一旦任何可用區域掛起，閘道器可以在可用區域之間交換流量，以確保我們的請求不會在閘道器級別掛起。如果那個城市，比如說廣州整個區域掛了，閘道器可以把這個流量跨城市切換容災，全部切到上海，這樣就保證了請求可以在閘道器層面無縫切換，保證了我們入口層的多活動容災。

到了應用層，如下圖所示，如果在點中心訪問活動中心時，廣州1區的活動中心掛機，那麼我們可以利用這個服務級別的動態路由能力，將點中心切換到廣州2區的活動中心。如果整個廣州地區掛機，可以直接把這個請求跨城切換到上海地區，讓上海的服務例項響應這樣的請求，從而實現應用層的多活和容災。

優越性

透過雲原生閘道器和北極星服務管理中心，為接入層和應用層提供主動容災和就近接入。實現故障快速恢復和擴容。

自動獲取服務例項的區域資訊。

根據區域資訊自動進行本地路由

跨區域和跨區域災難恢復切換

生產階段：限流場景

限流級：

1。接入層流量限制

2。服務之間的呼叫電流限制

電流限制尺寸：

1。服務/介面/標籤的電流限制

2。微服務的當前限制，單位為秒、分、小時、天等。

限流型別：

1。單機電流限制：單個排程例項級別的電流限制。流量限制僅對當前排程的例項有效，不共享。

2。分散式限流：對於服務下的所有例項級限流，多個服務例項共享同一個全域性流量限制。

下圖是一個關於如何限制入口層和服務之間的流量的簡單架構圖。

摘要

上面演示中涉及的騰訊雲的產品名為微服務引擎TSE，提供開源和增強的雲原生閘道器、註冊和配置中心以及服務治理平臺，幫助使用者快速構建輕量級、高可用、可擴充套件的微服務架構。微服務引擎完全相容開源版本，在功能、易用性、可操作性等多方面都有所增強。

上述演示中使用的TSE cloud native gateway將流量閘道器、安全閘道器和服務閘道器結合在一起，實現了統一的閘道器。具有安全認證、流量保護、流量路由、自定義外掛等功能。

彈性微服務的應用場景主要是這些微服務的架構。購物、php應用等容器部署可以放在彈性微服務上，或者為了解決流量峰谷，需要守住流量峰以提高資源利用率，也非常適合使用彈性微服務。