電商平台 高并發 微服務 方案_微服務平台建設方案

好久沒有發表文章了，前兩天剛好寫一個微服務的方案，在這裡與大家分享一下。

這篇文章隻是一些概念的介紹，後續我會根據這個設計方案，将實作過程一步一步記錄下來，與大家分享。

1 系統設計

1.1 總體架構

1.1.1 功能架構

微服務平台主要由服務支撐層、基礎服務層、通用服務及業務服務層組成，系統總體功能架構圖如下：

1) 基礎設施

微服務平台的基礎設施包括網絡、存儲、計算等硬體基礎設施，為平台的運作提供基礎保障。

2) 服務支撐層

服務支撐層為保證整個服務平台健康、高效運作提供支撐服務，包括服務注冊與發現中心、配置中心、日志中心、監控中心、服務限流降級與熔斷、微服務網關等支撐服務功能。

3) 基礎服務層

基礎服務層将平台通用的功能以服務的形式進行封裝，為其他業務服務的實施提供基礎服務，包括分布式緩存服務、分布式存儲服務、搜尋服務、消息隊列服務、分布式事務服務、任務排程服務、統一認證中心、使用者中心、組織機構管理、代辦任務中心、流程管理中心等基礎服務功能。

4) 通用服務層

通用服務層，是将一般業務功能開發都需要使用的功能進行封裝，形成通用服務，提高開發效率，控制開發品質的一種方式。

5) 業務服務層

通過通用服務實作的業務邏輯部署在業務服務層，為前端應用提供服務。

1.1.2 邏輯架構

平台架構以Spring Cloud 微服務架構為核心進行建構，內建了Spring Cloud Alibaba Nacos 實作服務注冊、發現與配置管理，內建Skywalking、 Elastic Logstash、Elastic Search、Elastic Kibana 實作日志中心功能、內建Prometheus、Grafana 實作監控預警功能、內建Spring Cloud Admin 實作微服務監控功能、內建Alibaba Sentiel 實作服務限流、降級與熔斷功能，內建Spring Cloud Gateway 實作了微服務網關功能。

1.2 詳細功能說明

1.2.1 服務支撐層

服務支撐層為保證整個服務平台健康、高效運作提供支撐服務，包括服務注冊與發現中心、配置中心、日志中心、監控中心、服務限流降級與熔斷、微服務網關等支撐服務功能。

1.2.1.1 服務注冊、發現與配置

Spring Cloud Alibaba Nacos 是阿裡巴巴公司的開源元件，Nacos 提供了一組簡單易用的特性集，能夠快速實作動态服務注冊、發現、服務配置、服務中繼資料及流量管理功能，幫助企業更靈活和容易地建構、傳遞和管理微服務平台，是建構以“服務”為中心的現代應用架構服務的基礎設施。

• 服務發現和服務健康監測

Nacos支援基于DNS和基于RPC的服務發現。服務提供者使用原生SDK、OpenAPI或一個獨立的Agent TODO注冊服務後，服務消費者可以使用DNS TODO 或HTTP&API查找和發現服務。

Nacos提供對服務的實時的健康檢查，阻止向不健康的主機或服務執行個體發送請求。Nacos支援傳輸層 (PING或TCP)和應用層 (如 HTTP、MySQL、使用者自定義)的健康檢查。對于複雜的雲環境和網絡拓撲環境中(如 VPC、邊緣網絡等)服務的健康檢查，Nacos提供了Agent上報模式和服務端主動檢測2種健康檢查模式。Nacos 還提供了統一的健康檢查儀表盤，幫助根據健康狀态管理服務的可用性及流量。

• 動态配置服務

動态配置服務可以平台以中心化、外部化和動态化的方式管理所有環境的應用配置和服務配置。

動态配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和靈活。

配置中心化管理讓實作無狀态服務變得更簡單，讓服務按需彈性擴充變得更容易。

• 動态 DNS 服務

動态 DNS 服務支援權重路由，讓平台更容易地實作中間層負載均衡、更靈活的路由政策、流量控制以及資料中心内網的簡單DNS解析服務。動态DNS服務使平台更容易地實作以 DNS 協定為基礎的服務發現，以幫助消除耦合到第三方應用私有服務發現API上的風險。

1.2.1.2 服務監控中心

整個平台分布着大量的伺服器、中間件、資料庫、微服務元件，對他們的性能、運作名額、健康狀況的監控就顯得尤為重要。方案通過多種元件內建的方式提供了整個平台的可視化監控中心功能。

• 分布式鍊路追蹤

随着業務的發展，平台中提供的服務會越來越多，服務之間的調用也會越來越錯綜複雜，一個請求可能會涉及多個服務，而服務本身可能也會依賴其他服務，整個請求路徑就構成了一個網狀的調用鍊，而在整個調用鍊中一旦某個節點發生異常，整個調用鍊的穩定性就會受到影響，為此方案中通過內建Apache SkyWalking元件，來幫助我們快速定位和解決問題。

Apache SkyWalking包括了分布式追蹤、性能名額分析、應用和服務依賴分析功能。SkyWalking 核心包括探針Probo、背景服務Backend、存儲Storage、可視化UI 四部分元件，其中存儲我們選用Elastic Search 企業級搜尋服務來來存儲監控日志資訊。

SkyWalking 的探針隻需要部署到要監測服務的伺服器上，即可實作代碼無侵入的方式收集服務相關日志資訊。

探針收集到資料并進行格式轉換後，将資料推送到背景服務，背景服務對收集的資料進行分析和聚和後存儲到本方案選取的存儲Elastic Search 上，以便可視化展示給最終使用者。

• 伺服器與元件監控

為了及時了解平台的健康情況，我們需要建包括伺服器的CPU空閑率、CPU 使用率、CPU負載率、可用記憶體、記憶體使用率、檔案系統空閑空間、網絡上傳、下載下傳速率、磁盤IO情況，資料庫吞吐量、連接配接情況、緩沖池使用情況、查詢性能，Elastic Search 的查詢索引性能、記憶體配置設定、垃圾回收情況、叢集健康及節點可用性等多種名額。為此，本方案采用Prometheus元件實作平台的監控與報警功能。Prometheus 是一套開源的系統監控報警架構，他包含了多個獨立的元件，其中有些元件是可選的，我們方案主要選擇如下元件:

1. Prometheus Server: 用于收集和存儲時間序列資料;
2. Exporters: 用于暴露已有的第三方服務metrics給Prometheus，本方案中主要用到了Node-Exporter、Oracle Exporter、 Mysqld-Exporter、ElasticSearch-Exporter、Redis-Exporter;
3. Alertmanager: 從Prometheus server 端接收到報警後，會進行去除重複資料級分組操作，并通過郵件、短信等方式發出報警;

主要工作流程：

1. Prometheus serve定期從配置好的exporters中拉取metrics;
2. Prometheus server 在本地存儲收集到的 metrics，并運作已定義好的 alert.rules，記錄新的時間序列或者向Alertmanager推送報警資訊;
3. Alertmanager根據配置檔案，對接收到的警報進行處理，發出告警;
4. 在圖形界面中，可視化顯示采集資料;

1.2.1.3 日志中心

在各個微服務開發實作過程中，根據業務需要我們會設定一些埋點記錄應用日志，比如用Log4j記錄應用日志資訊，以便我們對應用進行分析排查問題或做統計分析。為了能夠實時、可視化的方式對日志進行統計、分析、檢視，方案選用ELK開源元件實作日志中心功能。ELK核心元件包括：

• Elasticsearch：分布式搜尋和分析引擎，具有高可伸縮、高可靠和易管理等特點。能對大容量的資料進行接近實時的存儲、搜尋和分析操作；

• Logstash：資料收集引擎。它支援動态的從各種資料源搜集資料，并對資料進行過濾、分析、豐富、統一格式等操作，然後存儲到使用者指定的位置；

• Kibana：資料分析和可視化平台。通常與Elasticsearch配合使用，對其中資料進行搜尋、分析和以統計圖表的方式展示；

• Filebeat：一個輕量級開源日志檔案資料搜集器。在需要采集日志資料的服務上安裝Filebeat，并指定日志目錄或日志檔案後，Filebeat 就能讀取資料，實時發送到Logstash進行解析，也可以直接發送到Elasticsearch進行集中式存儲和分析。

另外，我們經常遇到一些需要将資料庫中的資料同步到Elasticsearch中，以便提高查詢效率、降低資料庫伺服器壓力的情況，為了實作這樣的功能通常有幾個方案：

• 代碼實作(雙寫)，針對代碼中進行資料庫的增删改操作時，同時進行elasticsearch的增删改操作；

• mybatis實作，通過mybatis plugin截取sql語句進行分析， 針對insert、update、delete的語句進行處理；

• AOP實作，根據制定的規則，如規範方法名，注解等進行切面處理；

• Logstash，利用Logstash支援動态的從各種資料源搜集資料的特性，可以進行資料的同步，隻需要簡單的配置就能将Mysql、Oracle等資料庫的資料同步到Elasticsearch，但是Logstash的原理是每分鐘進行一次增量資料查詢，将結果同步到Elasticsearch，如果實時性要求不是特别高的情況建議使用此方案；另外，如果是隻針對Mysql資料庫的情況，可以利用阿裡巴巴的Canal元件與Logstash相結合的方式實作實時資料同步到Elasticsearch。

1.2.1.4 服務限流、熔斷降級

随着平台中微服務元件的不斷增加，如何在其中一個或幾個服務出現流量異常的情況下，保障其他服務能夠正常運轉，而不至于整個平台陷入癱瘓顯得越來越重要。

阿裡巴巴Sentinel 是面向微服務架構的輕量級流量控制元件，主要以流量為切入點，從限流、流量整形、熔斷降級、系統負載保護等多個次元來幫助您保障微服務的穩定性。

• 流量控制，流量控制在網絡傳輸中是一個常用的概念，它用于調整網絡包的發送資料。然而，從系統穩定性角度考慮，在處理請求的速度上，也有非常多的講究。任意時間到來的請求往往是随機不可控的，而系統的處理能力是有限的。是以需要根據系統的處理能力對流量進行控制。Sentinel讓我們從 控制資源的調用關系(例如資源的調用鍊路，資源和資源之間的關系)、運作名額(例如 QPS、線程池、系統負載等)、控制的效果(例如直接限流、冷啟動、排隊)等角度，進行靈活組合，進而達到想要的效果。

• 熔斷降級，除了流量控制以外，及時對調用鍊路中的不穩定因素進行熔斷也是 Sentinel 的使命之一。由于調用關系的複雜性，如果調用鍊路中的某個資源出現了不穩定，可能會導緻請求發生堆積，進而導緻級聯錯誤。是以當檢測到調用鍊路中某個資源出現不穩定的表現(例如請求響應時間長或異常比例升高)的時候，則對這個資源的調用進行限制，讓請求快速失敗，避免影響到其它的資源而導緻級聯故障。

• 系統負載保護，Sentinel同時提供系統次元的自适應保護能力。防止雪崩，是系統防護中重要的一環。當系統負載較高的時候，如果還持續讓請求進入，可能會導緻系統崩潰，無法響應。在叢集環境下，網絡負載均衡會把本應這台機器承載的流量轉發到其它的機器上去。如果這個時候其它的機器也處在一個邊緣狀态，這個增加的流量就會導緻這台機器也崩潰，最後導緻整個叢集不可用。針對這個情況，Sentinel 提供了對應的保護機制，讓系統的入口流量和系統的負載達到一個平衡，保證系統在能力範圍之内處理最多的請求。

1.2.1.5 微服務網關

平台中部署了很多微服務，這些微服務對外提供API接口以便用戶端調用，每個微服務都有各自的位址、端口等資訊，一個用戶端可能需要通路很多不同的微服務去實作業務功能。這就需要用戶端動态維護微服務的資訊并與多個微服務之間進行身份驗證工作，為了解決這些問題，就需要一個能夠統一管理API 的網絡關口，作為整個微服務平台請求的唯一入口，在網關層處理所有非業務功能(比如對調用微服務的用戶端進行身份驗證、記錄日志、動态路由等)，本方案采用Spring 官方推出的 Spring Cloud Gateway 網關元件，具有如下特性：

• 是基于Spring Framework 5和 Spring Boot 2.x 的響應式、非阻塞式的 API；

• 動态路由：能夠比對任何請求屬性；

• 可以對路由指定 Predicate(斷言)和 Filter(過濾器)；

• 內建Hystrix的斷路器功能；

• 內建 Spring Cloud 服務發現功能；

• 易于編寫的 Predicate(斷言)和 Filter(過濾器)；

• 請求限流功能；

• 支援路徑重寫。

用戶端向Spring Cloud Gateway送出請求。如果Gateway Handler Mapping确定請求與路由比對，則将其發送到Gateway Web Handler。此handler通過特定于該請求的過濾器鍊處理請求。而這些比對是由路由斷言Factory完成的，Spring Cloud Gataway包含了很多内置的路由斷言Factories，這些斷言都比對HTTP請求的不同屬性。多個路由斷言Factories可以通過 and 進行組合使用。

主要内置斷言Factory包括：

• After 路由斷言Factory，After Route Predicate Factory采用一個參數—日期時間。在該日期時間之後發生的請求都将被比對；

• Before 路由斷言Factory，Before Route Predicate Factory采用一個參數—日期時間。在該日期時間之前發生的請求都将被比對；

• Between 路由斷言 Factory，Between 路由斷言 Factory有兩個參數，datetime1和datetime2。在datetime1和datetime2之間的請求将被比對。datetime2參數的實際時間必須在datetime1之後；

• Cookie 路由斷言Factory, Cookie 路由斷言 Factory有兩個參數，cookie名稱和正規表達式。請求包含次cookie名稱且正規表達式為真的将會被比對；

• Header 路由斷言Factory,Header 路由斷言 Factory有兩個參數，header名稱和正規表達式。請求包含次header名稱且正規表達式為真的将會被比對；

• Host 路由斷言Factory, Host 路由斷言 Factory包括一個參數：host name清單。使用Ant路徑比對規則，.作為分隔符;

• Method 路由斷言 Factory,Method 路由斷言 Factory隻包含一個參數: 需要比對的HTTP請求方式;

• Path 路由斷言 Factory,Path 路由斷言 Factory 有2個參數: 一個Spring PathMatcher表達式清單和可選;

• Query 路由斷言 Factory,Query 路由斷言 Factory 有2個參數: 必選項 param 和可選項 regexp;

• RemoteAddr 路由斷言 Factory,RemoteAddr 路由斷言 Factory的參數為 一個CIDR符号(IPv4或IPv6)字元串的清單，最小值為1，例如192.168.0.1/16(其中192.168.0.1是IP位址并且16是子網路遮罩)

另外，Spring Cloud Gateway 可以與Oauth2、JWT內建實作在網關進行請求的身份驗證與授權功能。

1.2.2 基礎服務層

基礎服務層将平台通用的功能以服務的形式進行封裝，為其他業務服務的實施提供基礎服務，包括分布式緩存服務、分布式存儲服務、搜尋服務、消息隊列服務、分布式事務服務、任務排程服務等基礎服務功能

1.2.2.1 分布式緩存服務

分布式緩存服務可将高頻通路的資料，放入緩存中，可以大大提高微服務平台整體的承載能力，解決資料庫伺服器和web伺服器之間的效率瓶頸。分布式緩存服務應支援高性能的Key-Value存儲方式，支援string、list、hash、set、zset、hypeloglog等多種資料結構，支援主動過期和惰性過期的資料過期處理，支援volatile-lru、volatile-ttl等LRU政策，及記憶體管理、内容存儲+磁盤持久化、主從複制等功能；在性能上應滿足百萬級QPS的資源調用，99.99%的可用性，毫秒級的核心請求響應時間，彈性擴充、易用等名額。

方案采用Redis來提供分布式緩存服務，可以完全滿足上述要求：

Redis，是REmote DIctionary Server的縮寫。是一個開源、基于C語言、基于記憶體亦可持久化的高性能NoSQL資料庫，同時，它還提供了多種語言的API。它是一款由意大利人由Salvatore Sanfilippo所寫的，依據BSD開源協定發行的高性能Key-Value存儲系統(cache and store)。它通常被稱為資料結構伺服器，提供了一些豐富的資料結構，包括 字元串(String), 哈希(Map), 清單(list), 集合(sets) 和 有序集合(sorted sets)等類型。Redis當然還包括了對這些資料結構的豐富操作。

1.2.2.2 分布式存儲服務

分布式網絡存儲服務采用可擴充的系統結構，利用多台存儲伺服器分擔存儲負荷，利用位置伺服器定位存儲資訊，它不但提高了系統的可靠性、可用性和存取效率，還易于擴充。分布式存儲服務應支援檔案存儲、檔案傳輸、跨機房架構、檔案中繼資料管理、檔案搜尋、檔案處理、檔案版本管理、檔案日志消息、大資料對接等功能，對外提供RESTfulAPI。

針對以上的需求我們采用MongoDB來應對。

MongoDB是一個基于分布式檔案存儲的資料庫。由C++語言編寫。旨在為WEB應用提供可擴充的高性能資料存儲解決方案。是介于關系資料庫和非關系資料庫之間的産品，是非關系資料庫當中功能最豐富，最像關系資料庫的。他支援的資料結構非常松散，是類似json的bson格式，是以可以存儲比較複雜的資料類型。Mongo最大的特點是他支援的查詢語言非常強大，其文法有點類似于面向對象的查詢語言，幾乎可以實作類似關系資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。

1.2.2.3 消息隊列服務

消息隊列服務可以為平台提供消息釋出訂閱、消息軌迹查詢、定時(延時)消息、資源統計、監控報警等一系列消息服務，為平台提供異步解耦、削峰填谷的能力，同時具備海量消息堆積、高吞吐、可靠重試等網際網路應用所需的特性。

我們采用Apache Alibaba RocketMQ做為消息隊列服務實作方案，Apache Alibaba RocketMQ 是一款分布式、隊列模型的消息中間件，具有以下特點：

• 支援嚴格的消息順序

• 支援 Topic 與 Queue 兩種模式

• 億級消息堆積能力

• 比較友好的分布式特性

• 同時支援 Push 與 Pull 方式消費消息

• 曆經多次天貓雙十一海量消息考驗

對比其他主流消息隊列元件主要優勢有：

• 支援事務型消息(消息發送和 DB 操作保持兩方的最終一緻性，RabbitMQ 和 Kafka 不支援)

• 支援結合 RocketMQ 的多個系統之間資料最終一緻性(多方事務，二方事務是前提)

• 支援 18 個級别的延遲消息(RabbitMQ 和 Kafka 不支援)

• 支援指定次數和時間間隔的失敗消息重發(Kafka 不支援，RabbitMQ 需要手動确認)

• 支援 Consumer 端 Tag 過濾，減少不必要的網絡傳輸(RabbitMQ 和 Kafka 不支援)

• 支援重複消費(RabbitMQ 不支援，Kafka 支援)

1.2.2.8 搜尋引擎服務

通過搜尋引擎服務将搜尋引擎複雜的索引結構概念簡單化、可視化和自助定制化。平台的上層業務應用可以通過控制台建立搜尋應用，定制文檔字段的結構和屬性，包括字段名稱、類型、分詞方式、搜尋屬性等。搜尋應用在運作過程中可以自由修改，滿足業務快速變化的需求，縮短需求變更到上線的過程。

本方案中，我們基于Elastic Search實作搜尋引擎服務，Elasticsearch 是一個實時的分布式搜尋和分析引擎。它可以幫助使用者用前所未有的速度去處理大規模資料、它可以用于全文搜尋，結構化搜尋以及分析。實作分布式實時檔案存儲，并将每一個字段都編入索引，使其可以被搜尋，他是一個能夠實作實時分析的分布式搜尋引擎，并可以擴充到上百台伺服器，處理PB級别的結構化或非結構化資料。

1.2.2.9 分布式事務

在微服務架構下，雖然我們會盡量避免分布式事務，但是隻要業務複雜的情況下這是一個繞不開的問題，為了保證業務資料原子性、一緻性，本方案采用阿裡巴巴開源的一站式分布式事務解決方案中間件Seata, Seata能夠幫助使用者以高效并且對業務 零侵入的方式解決微服務場景下面臨的分布式事務問題。

Seata整體事務邏輯是基于兩階段送出 的模型，核心概念包括以下3個角色：

• TM：事務的發起者。用來告訴TC，全局事務的開始，送出，復原。

• RM：具體的事務資源，每一個 RM 都會作為一個分支事務注冊在TC。

• TC：事務的協調者Seata-Server，用于接收我們的事務的注冊，送出和復原。

Seata有兩種模式可使用分别對應不同業務場景:

• AT模式, 該模式适合的場景：

基于支援本地 ACID 事務的關系型資料庫。

Java 應用，通過 JDBC 通路資料庫。

• 一個典型的分布式事務過程：

①　TM 向 TC 申請開啟一個全局事務，全局事務建立成功并生成一個全局唯一的 XID。

②　XID 在微服務調用鍊路的上下文中傳播。

③　RM 向 TC 注冊分支事務，将其納入 XID 對應全局事務的管轄。

④　TM 向 TC 發起針對 XID 的全局送出或復原決議。

⑤　TC 排程 XID 下管轄的全部分支事務完成送出或復原請求。

• MT模式, 該模式邏輯類似TCC，需要 自定義實作prepare、commit和rollback的邏輯，适合 非關系型資料庫 的場景

本方案參考了zlt的microservices-platform，在此表示感謝！！

未完待續......