日10億級處理，基于云的微服務(wù)架構(gòu)

德比軟件：基于云的微服務(wù)架構(gòu)

作者：朱攀，德比軟件架構(gòu)師，同濟大學(xué)研究生，2007 年 2 月加入德比軟件（DerbySoft），擁有 10 年以上的軟件架構(gòu)和開發(fā)經(jīng)驗。目前主要負(fù)責(zé)公司數(shù)據(jù)對接平臺的架構(gòu)、基礎(chǔ)設(shè)施建設(shè)、技術(shù)團隊管理及公司技術(shù)的布道。作為德比軟件的早期員工，從無到有地主導(dǎo)了德比軟件數(shù)據(jù)對接平臺的架構(gòu)設(shè)計和實現(xiàn)，完成了數(shù)據(jù)對接平臺多個版本的架構(gòu)改進和升級，數(shù)據(jù)對接平臺每天處理的 API 調(diào)用從 0 增長到現(xiàn)在的 10 億多。期間設(shè)計實現(xiàn)了很多必要的基礎(chǔ)設(shè)施和服務(wù)，如公司內(nèi)部的 RPC 框架 DerbySoft-RPC、智能路由服務(wù) Router、分布式數(shù)據(jù)存儲服務(wù) DStorage、網(wǎng)關(guān)服務(wù) DGateway 等。目前主要關(guān)注基礎(chǔ)架構(gòu)、微服務(wù)、大數(shù)據(jù)存儲和技術(shù)團隊建設(shè)。

?

?

10.1???? 概述

?

?

微服務(wù)概念被提出來以后，短時間內(nèi)就成了互聯(lián)網(wǎng)圈的一個技術(shù)熱點，有很多互聯(lián)網(wǎng)公司計劃或正在進行微服務(wù)化改造，那么應(yīng)該怎么開始實施微服務(wù)呢？需要哪些基礎(chǔ)設(shè)施來支持呢？我所在的公司德比軟件從 2009 年就開始采用面向服務(wù)架構(gòu)（SOA）來重新實現(xiàn)數(shù)據(jù)對接平臺，我們積累了豐富的面向服務(wù)架構(gòu)的經(jīng)驗，而微服務(wù)架構(gòu)是面向服務(wù)架構(gòu)思想的一種實現(xiàn)，只是服務(wù)職責(zé)更單一，粒度更小，過程更自動化。我們在多年的服務(wù)化架構(gòu)實踐過程中，已經(jīng)不自覺地將服務(wù)的粒度細(xì)化了。本文想分享德比軟件在實施微服務(wù)架構(gòu)過程中積累的一些基礎(chǔ)設(shè)施及這些基礎(chǔ)設(shè)施解決的痛點問題，希望對大家有所幫助和啟發(fā)。

?

?

10.2???? 德比軟件數(shù)據(jù)對接平臺的架構(gòu)

?

數(shù)據(jù)對接平臺的架構(gòu)大體上分三個層次，如圖 10.1 所示，最外面是 API 層，由 API Gateway（網(wǎng)關(guān)）和各業(yè)務(wù)的 API 服務(wù)組成；中間層是服務(wù)層（Service），平臺的大部分功能在這一層實現(xiàn)，服務(wù)之間可以通過依賴或組合組成功能更強的服務(wù)；底層是數(shù)據(jù)存儲層（Data Storage），由緩存層和存儲層組成。數(shù)據(jù)對接平臺采用微服務(wù)架構(gòu)，為了支撐這個架構(gòu)，我們提供了必要的基礎(chǔ)設(shè)施來保障上層各個服務(wù)和應(yīng)用的可用性。

?

圖 10.1

?

?

10.3???? 德比軟件微服務(wù)架構(gòu)基礎(chǔ)設(shè)施

?

如圖 10.2 所示，將基礎(chǔ)設(shè)施分為了八大部分，分別是服務(wù)框架、基礎(chǔ)服務(wù)、API 網(wǎng)關(guān)、自動化、服務(wù)降級、監(jiān)控報警（服務(wù)健康狀態(tài)）、日志處理和調(diào)用鏈追蹤。其中，

• 服務(wù)框架、基礎(chǔ)服務(wù)、API 網(wǎng)關(guān)和服務(wù)降級的作用是提高服務(wù)的連續(xù)工作時間；

• 自動化可以簡化開發(fā)和部署過程；

• 監(jiān)控報警、日志處理和調(diào)用鏈追蹤可以幫助快速發(fā)現(xiàn)問題、定位問題并解決問題。

?

圖 10.2

?

?

基礎(chǔ)設(shè)施全景圖如圖 10.3 所示。

?

?

圖 10.3

?

?

10.4???? API 網(wǎng)關(guān)

?

API 網(wǎng)關(guān)是微服務(wù)架構(gòu)中不可或缺的部分。API 網(wǎng)關(guān)是對外提供的服務(wù)，是系統(tǒng)的入口，所有的外部系統(tǒng)都需要通過 API 網(wǎng)關(guān)來接入。Dgateway 提供安全認(rèn)證、流控、路由、 API 版本管理等功能。流控維度分為用戶類型、用戶來源、IP、業(yè)務(wù) API 等，保護服務(wù)或資源不被濫用或攻擊。DGateway 基于開源軟件 Tyk 做了二次開發(fā)。

?

?

10.5???? 服務(wù)框架

?

服務(wù)框架分兩部分，高可用的 RPC（DerbySoft-RPC）和服務(wù)依賴管理，如圖 10.4 所示。

?

圖?10.4

10.5.1??? 高可用 RPC

?

RPC 是微服務(wù)架構(gòu)中最重要的基礎(chǔ)組件，一個健壯的 RPC 能有效降低實施微服務(wù)架構(gòu)的成本。RPC 封裝了遠(yuǎn)程調(diào)用的復(fù)雜細(xì)節(jié)，讓服務(wù)使用方感覺像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，服務(wù)提供方感覺像實現(xiàn)本地接口一樣來實現(xiàn)服務(wù)。DerbySoft-RPC 分為 Client 和Server 兩部分。Client 主要有以下功能。

?

客戶端故障檢測，識別并標(biāo)示太慢或崩潰了的服務(wù)器。

?

熔斷機制，如果發(fā)現(xiàn)服務(wù)超時比例過限，則啟動熔斷，客戶端會快速返回失敗，以減輕服務(wù)端的壓力，定時允許部分請求通過，根據(jù)請求返回的健康程度來決定是否恢復(fù)熔斷。

?

負(fù)載均衡策略，通過記錄到每個節(jié)點的未完成請求數(shù)來決定下一個請求發(fā)到哪里。容錯機制，對某些錯誤自動重試，比如連接的服務(wù)節(jié)點不可用時可以自動將請求再次發(fā)送到其他節(jié)點，可定義重試次數(shù)。

?

序列化和反序列化，選擇序列化工具最重要的考量點有性能高低、是否多語言支持、序列化后的消息大小、是否向前兼容等。我們嘗試過各種序列化工具，而 Protocol Buffer 在性能和空間占用上都表現(xiàn)優(yōu)異，是我們使用最頻繁的序列化工具。對敏感數(shù)據(jù)加密，比如信用卡等敏感信息，需要在 Client 端加密傳輸。

?

超時管理，可設(shè)定每個請求的超時時間。

Server 部分相對簡單，主要提供超時管理、序列化和反序列化、敏感信息解密、隊列管理、線程管理等功能。

剛才提到選擇序列化工具時需要考慮是否支持多語言，這一點很重要，RPC 最好能在多語言環(huán)境下實現(xiàn)，這樣能讓技術(shù)團隊突破編程語言限制，使技術(shù)棧更豐富靈活。我們在這方面是有過教訓(xùn)的。

在公司早期，大概是 2009 年，當(dāng)時的業(yè)務(wù)量不大，在語言上主要使用 Java，為了方便我們在第一個 RPC 版本上采用了 Java 序列化機制，卻導(dǎo)致后面想要更換編程語言時大受限制。因此我們做了第二版 RPC，將序列化機制換掉，采用 Java 的字節(jié)序以兼容第一個版本。DerbySoft-RPC 是第三版 RPC，實現(xiàn)了對 Go、Scala 和 Java 三種語言的兼容。原則上我們不限制服務(wù)的實現(xiàn)語言，只要能按要求實現(xiàn)服務(wù)接口并滿足性能要求即可。微服務(wù)化后的一個好處就是根本不用擔(dān)心使用小眾的編程語言，如果每個服務(wù)的粒度足夠小，那么最壞的情況就是在沒人能維護這個小眾語言的服務(wù)時，需要花點時間用熟悉的語言來重寫。

?

?

10.5.2??? 服務(wù)依賴管理

?

?

微服務(wù)化之后，系統(tǒng)面臨的一個突出問題是服務(wù)雖小，但是數(shù)量極多。如果這些服務(wù)全部在一個可用區(qū)內(nèi)，那么服務(wù)之間的依賴還比較好管理，可以做服務(wù)自動注冊和發(fā)現(xiàn)來實現(xiàn)依賴管理，但是如果服務(wù)分布在很多可用區(qū)中，尤其是分布在跨國跨地區(qū)的可用區(qū)之間，則其依賴和調(diào)用的管理就會比較麻煩。

?

另外，跨可用區(qū)服務(wù)之間的調(diào)用還需要考慮通信安全的問題，對每個服務(wù)設(shè)置不同的特殊端口，如果需要跨區(qū)域調(diào)用服務(wù)，那么配置訪問權(quán)限也是一件麻煩的事情。

?

眾多服務(wù)的依賴示例如圖 10.5 所示。

?

?

圖 10.5

圖 10.5 所示的服務(wù)依賴是不是很亂？我們的服務(wù)節(jié)點分布在全球 14 個可用區(qū)，大部分在亞馬遜云上，小部分在自建的私有云里，可用區(qū)之間的服務(wù)有復(fù)雜的依賴關(guān)系。為了解決這種情況下服務(wù)之間的依賴調(diào)用問題、API 安全問題和服務(wù)的高可用問題，我們設(shè)計開發(fā)了路由服務(wù)，以解耦服務(wù)的調(diào)用者和提供者，簡化網(wǎng)絡(luò)拓?fù)浼胺?wù)器的安全配置。引入路由之后，簡化后的服務(wù)之間的依賴關(guān)系如圖 10.6 所示。

?

?

圖 10.6

?

所有的服務(wù)只和路由通信，服務(wù)之間不再相互依賴，每個服務(wù)只需要依賴并維護自己所在的可用區(qū)路由節(jié)點，路由會找到調(diào)用的服務(wù)目的地。絕大部分情況下，它在本區(qū)域內(nèi)就能找到相應(yīng)的服務(wù)，不需要跨區(qū)，這取決于服務(wù)的部署情況。為了提高響應(yīng)速度，每個可用區(qū)都需要部署關(guān)鍵的服務(wù)，除非本可用區(qū)的服務(wù)崩潰了，否則在這種情況下不會出現(xiàn)跨區(qū)訪問。有些服務(wù)不是那么重要，可能只會在某個或某幾個可用區(qū)中部署，這時也可能會出現(xiàn)服務(wù)跨可用區(qū)調(diào)用的情況。

這樣不僅更好地管理了依賴，解決了服務(wù)器可用區(qū)調(diào)用問題，還解決了 API 訪問安全問題：每個可用區(qū)建立一個 VPC（虛擬私有云），所有的服務(wù)都在 VPC 內(nèi)，VPC 內(nèi)的 API 調(diào)用可忽略安全驗證，跨 VPC 路由節(jié)點之間用安全組來限制 IP 白名單訪問，只允許路由節(jié)點可以跨可用區(qū)訪問其他 VPC 內(nèi)的路由節(jié)點，服務(wù)訪問路由或者路由訪問服務(wù)都必須在同一個 VPC 內(nèi)使用內(nèi)網(wǎng)地址訪問。

?

10.6???? 基礎(chǔ)服務(wù)

?

?

基礎(chǔ)服務(wù)分為四部分，分別是配置中心、安全數(shù)據(jù)服務(wù)、數(shù)據(jù)存儲服務(wù)、訂單服務(wù)，如圖 10.7 所示。基礎(chǔ)服務(wù)大多和存儲有關(guān)，提供高性能、高可用的服務(wù)。

?

?

圖 10.7

?

10.6.1??? 配置中心

?

?

配置中心提供高可用的配置數(shù)據(jù)存儲服務(wù)，幾乎所有的應(yīng)用和服務(wù)都依賴配置中心。配置中心主要解決基礎(chǔ)數(shù)據(jù)和配置數(shù)據(jù)的單點依賴及節(jié)點之間的數(shù)據(jù)同步問題，以便更好地支持各個服務(wù)的水平伸縮。配置中心可以配置主鍵、索引字段、唯一約束、每個字段的類型約束等，其功能類似于數(shù)據(jù)庫，開放全量和變量的同步接口，提供多語言的客戶端 SDK，同步全量或變量數(shù)據(jù)，根據(jù)服務(wù)端的配置，在內(nèi)存中建立數(shù)據(jù)索引，緩存數(shù)據(jù)，并在本地文件中持久化緩存的備份，如圖 10.8 所示。

圖 10.8

?

一個依賴配置中心的服務(wù)，在啟動時會先查找本地文件中有沒有配置數(shù)據(jù)的緩存，如果有，則從文件中加載配置數(shù)據(jù)到內(nèi)存中，啟動服務(wù)，接著調(diào)用變量接口對比本地數(shù)據(jù)和配置中心的數(shù)據(jù)是否是同一版本，如果數(shù)據(jù)有變化，則更新數(shù)據(jù)到本地緩存。如果本地文件中沒有配置數(shù)據(jù)的緩存，則先調(diào)用一次全量接口緩存所有配置數(shù)據(jù)到本地緩存。即使配置中心的所有節(jié)點都無法運行，也不影響各個依賴它服務(wù)的現(xiàn)有節(jié)點的正常工作。

?

因為每個服務(wù)都會緩存依賴的配置數(shù)據(jù)，所以對配置中心的性能要求不是太高，我們用 AWS RDS 來解決配置數(shù)據(jù)存儲的高可用問題。AWS RDS 是一個托管關(guān)系數(shù)據(jù)庫服務(wù)。

?

10.6.2??? 安全數(shù)據(jù)服務(wù)

?

?

高可用的安全數(shù)據(jù)服務(wù)提供數(shù)據(jù)加密和解密服務(wù)，定時清理過期的數(shù)據(jù)，解決敏感數(shù)據(jù)的安全臨時存儲和傳輸問題，比如銀行卡和信用卡信息的臨時存儲和傳輸。需要傳輸敏感信息時，在數(shù)據(jù)傳輸方調(diào)用數(shù)據(jù)加密服務(wù)的加密接口，并明確信息有效時間，加密服務(wù)會將信息加密后存儲，并返回一個全局唯一 ID，數(shù)據(jù)傳輸方發(fā)送這個唯一 ID 給數(shù)據(jù)接收方，如果數(shù)據(jù)接收方收到這個 ID 之后，調(diào)用數(shù)據(jù)解密接口，則加密服務(wù)會根據(jù) ID 找到相應(yīng)的數(shù)據(jù)，返回解密之后的數(shù)據(jù)。

?

?

10.6.3??? 數(shù)據(jù)存儲服務(wù)

?

Dstorage 提供高可用的酒店動態(tài)數(shù)據(jù)存儲服務(wù)，可以解決酒店海量動態(tài)數(shù)據(jù)存儲問題，提供高性能的數(shù)據(jù)存取接口，提供變量數(shù)據(jù)的同步接口。根據(jù)性能和容量需求，用戶可選的存儲引擎有 Redis、Codis、Ardb、DynamoDB 等。DStorage 支持多可用區(qū)部署，通過變化發(fā)現(xiàn)服務(wù)，實現(xiàn)多可用區(qū)的數(shù)據(jù)同步，保證數(shù)據(jù)最終一致性。

?

Dcontent 提供高可用的酒店靜態(tài)數(shù)據(jù)緩存服務(wù)可以解決酒店海量靜態(tài)數(shù)據(jù)的緩存問題。底層支持的存儲引擎有 Ardb、Redis 等。DContent 支持一主多從多可用區(qū)部署，也支持多主多可用區(qū)部署，保證數(shù)據(jù)最終一致性。

?

AWS S3 提供高可用的文件存儲服務(wù)，可以存儲文件數(shù)據(jù)，如圖片、視頻、日志文件、備份數(shù)據(jù)等。

?

?

10.6.4??? 訂單服務(wù)

?

?

由于訂單數(shù)據(jù)比較特殊，所以將與訂單相關(guān)的功能單獨出來，作為獨立服務(wù)。訂單服務(wù)聚合所有系統(tǒng)節(jié)點的訂單信息，讓訂單比較容易追溯，提供高可用的訂單存儲和查詢服務(wù)，解決訂單數(shù)據(jù)的單點存儲問題，更好地支持其他依賴訂單數(shù)據(jù)的系統(tǒng)進行水平擴展和遷移。訂單服務(wù)對可用性要求極高，底層存儲依賴 AWS RDS，在全球每個可能用到訂單服務(wù)的可用區(qū)部署訂單服務(wù)集群。

?

?

10.7???? 服務(wù)降級

?

?

根據(jù)業(yè)務(wù)要求對每個服務(wù)及其依賴的資源按重要程度進行分級，限制每個依賴服務(wù)的超時時間，定義各級服務(wù)的 SLA 指標(biāo)，對強依賴的基礎(chǔ)服務(wù)或資源實行更高的 SLA 標(biāo)準(zhǔn)，根據(jù) SLA 指標(biāo)制定容錯方案。

?

制定服務(wù)自動降級策略，設(shè)置服務(wù)開關(guān)，關(guān)鍵時刻“棄車保帥”，對弱依賴的服務(wù)進行降級，比如將日志服務(wù)降級以保障重要的服務(wù)不受影響。

?

對超大數(shù)據(jù)或流量用戶進行隔離，在隔離的環(huán)境中為這部分用戶提供獨立的服務(wù)，避免影響其他正常用戶服務(wù)。

?

?

10.8???? 自動化

?

?

微服務(wù)化后，服務(wù)的數(shù)量很多，為了節(jié)約開發(fā)成本，必須盡可能地自動化完成一些有固定步驟的工作，如自動化測試和自動化部署，如圖 10.9 所示。

圖 10.9

?

1．自動化測試。

?

單元測試自動化：我們目前要求單元測試覆蓋率大于 90%，通過 Jenkins 整合 Sonar。每次提交代碼后自動運行單元測試，Sonar 會自動給出代碼評分，如果測試覆蓋率不夠或代碼不達(dá)標(biāo)，則單元測試失敗。

?

性能測試自動化、平臺化：我們開發(fā)了自動化測試平臺 DTesting，關(guān)鍵服務(wù)的每次變更都需要在平臺上進行性能測試，并生成性能測試報告，對比歷史的性能測試數(shù)據(jù)。

?

功能測試自動化、平臺化：每個應(yīng)用都有完整的功能測試用例和腳本，可自動化回歸功能測試。

?

2．自動化部署。

我們引入了 Docker，以減少人為部署時的誤操作。

?

?

10.9???? 日志處理

?

?

日志處理分為兩部分：一部分是實時日志處理，另一部分是冷日志處理。所有的應(yīng)用日志都需要寫入 Kafka 和文件，Kafka 中所有的實時日志都會被 DLog 系統(tǒng)及時消費處理，但是實時日志的保留時間不長，一般保留一個月。寫入文件的所有日志會被定時備份到 AWS S3 上永久保留，如果需要一個月前甚至更久以前的系統(tǒng)日志，則可以在 DLog 系統(tǒng)中選擇需要的日志范圍，DLog 會將符合條件的日志從 S3 上下載下來并重新建立日志索引。日志主要是為監(jiān)控提供基礎(chǔ)源數(shù)據(jù)，為定位問題提供依據(jù)，如圖 10.10 所示。

圖 10.10

?

?

10.10???? 調(diào)用鏈追蹤

?

?

隨著服務(wù)的粒度越來越小，系統(tǒng)的服務(wù)變得越來越多，不同的服務(wù)可能由不同的團隊實現(xiàn)，一個服務(wù)的實現(xiàn)可能會依賴幾個甚至十幾個服務(wù)。對于出現(xiàn)問題后，如何快速準(zhǔn)確地定位故障，如何追蹤業(yè)務(wù)的處理順序和結(jié)果，業(yè)內(nèi)已經(jīng)有了一些實踐和解決方案，Google Dapper 是 Google 研發(fā)的分布式跟蹤系統(tǒng)，Google 也為此發(fā)表論文闡述了分布式跟蹤系統(tǒng)的理論基礎(chǔ)，給分布式跟蹤的實現(xiàn)提供了非常好的參考示范。對于 Java 編寫的服務(wù)，我們采用 Zipkin 來做調(diào)用鏈跟蹤，Zipkin 是 Google Dapper 系統(tǒng)的開源實現(xiàn)，采用 Scala 編寫；

?

而對于 Go 語言實現(xiàn)的服務(wù)，我們目前還沒有好的解決方案。一個好的調(diào)用鏈追蹤系統(tǒng)能為定位和排查故障提供強有力的支持。對于微服務(wù)架構(gòu)，調(diào)用鏈追蹤是必備的基礎(chǔ)設(shè)施。

?

?

10.11??? 服務(wù)健康狀態(tài)

?

?

很多情況下，解決故障可能很快，難點在于發(fā)現(xiàn)故障和定位故障，這需要我們的系統(tǒng)有全方位的監(jiān)控和報警能力?；跇I(yè)務(wù)和技術(shù)對可用性的需求，我們開發(fā)了服務(wù)健康狀態(tài)監(jiān)控和報警系統(tǒng)，從業(yè)務(wù)層、服務(wù)層、硬件基礎(chǔ)設(shè)施層分別進行監(jiān)控和報警，如圖 10.11 所示。

?

10.11.1??? 報警

?

?

報警系統(tǒng)定義所有報警種類、報警級別、處理流程，并提供報警接入機制，各個層次的監(jiān)控都可以通過自定義報警引擎接入報警系統(tǒng)來觸發(fā)報警。7 × 24 小時服務(wù)監(jiān)控團隊會根據(jù)各個報警的處理流程，依次聯(lián)系最高優(yōu)先級的處理人來處理故障，如果在規(guī)定時間內(nèi)沒有處理完畢，則系統(tǒng)會根據(jù)報警的種類和級別自動升級報警響應(yīng)級別，提高處理優(yōu)先級來保障重要的報警能得到及時處理。

?

圖 10.11

?

10.11.2??? 監(jiān)控

?

監(jiān)控分為硬件基礎(chǔ)設(shè)施層監(jiān)控、服務(wù)層監(jiān)控和業(yè)務(wù)層監(jiān)控三大類。

?

硬件基礎(chǔ)設(shè)施層監(jiān)控，包括操作系統(tǒng)、內(nèi)存、CPU、網(wǎng)絡(luò)流量和狀態(tài)、連接數(shù)等方面的監(jiān)控。我們用 Zabbix 來做基礎(chǔ)設(shè)施層的監(jiān)控，通過 Zabbix 的 API 將數(shù)據(jù)整合進我們的監(jiān)控系統(tǒng) DMonitor。

?

服務(wù)層監(jiān)控，包括基礎(chǔ)組件監(jiān)控、基礎(chǔ)服務(wù)監(jiān)控、常規(guī)服務(wù)監(jiān)控和外部接口調(diào)用監(jiān)控。其中，基礎(chǔ)組件監(jiān)控包括對 Etcd、AWS RDS、Redis、Docker、Kafka 等基礎(chǔ)組件使用情況的監(jiān)控；基礎(chǔ)服務(wù)監(jiān)控包括對配置中心服務(wù)、認(rèn)證服務(wù)、安全存儲服務(wù)、路由服務(wù)、API Gateway 等關(guān)鍵服務(wù)的監(jiān)控；常規(guī)服務(wù)監(jiān)控則是監(jiān)控所有一般服務(wù)的狀態(tài)；而外部接口調(diào)用監(jiān)控是監(jiān)控分析系統(tǒng)依賴的外部訪問情況，包括訪問量、錯誤信息、超時狀況等，為快速定位問題提供依據(jù)。

?

業(yè)務(wù)層監(jiān)控，是指從業(yè)務(wù)角度出發(fā)，收集和分析業(yè)務(wù)層的訪問量，根據(jù)各個業(yè)務(wù)的歷史數(shù)據(jù)和已知的影響因素預(yù)測現(xiàn)在和未來的業(yè)務(wù)情況，定義監(jiān)控報警目標(biāo)。比如，在最近半個小時內(nèi)某個業(yè)務(wù)的請求量小于預(yù)期值，在最近 1 個小時內(nèi)對某個客戶的 API 調(diào)用次數(shù)超過預(yù)期值，在最近 3 個小時內(nèi)某酒店的訂單量顯著下降，等等。由于業(yè)務(wù)層的監(jiān)控比較多，因此我們把業(yè)務(wù)層的監(jiān)控獨立出了一個子系統(tǒng)。業(yè)務(wù)層監(jiān)控報警的決策來源于歷史數(shù)據(jù)和未來可能影響系統(tǒng)的因子，通過對歷史中的海量數(shù)據(jù)進行匯總加工和分析，從各個維度給出報警的預(yù)期值。

?

服務(wù)層監(jiān)控和業(yè)務(wù)層監(jiān)控都離不開各個應(yīng)用的支持，有些監(jiān)控目標(biāo)會對應(yīng)用的實現(xiàn)有侵入性，比如需要寫業(yè)務(wù)日志，各個應(yīng)用根據(jù)監(jiān)控的目標(biāo)來設(shè)計和實現(xiàn)，為業(yè)務(wù)層監(jiān)控提供必要的技術(shù)支持，因此從系統(tǒng)架構(gòu)層面開始就需要考慮業(yè)務(wù)的可用性需求。有了服務(wù)健

?

康狀態(tài)的監(jiān)控和報警系統(tǒng)，再輔以調(diào)用鏈追蹤系統(tǒng)和日志處理系統(tǒng)，發(fā)現(xiàn)和定位故障的時間就比較可控了，可以很快定位絕大部分故障的發(fā)生原因，為修復(fù)故障提供有力的保障。整個發(fā)現(xiàn)定位故障的層次如圖 10.12 所示。

?

?

圖 10.12

?

?

10.12???? 發(fā)布管理

?

?

最后我想說說發(fā)布管理。雖然它不屬于基礎(chǔ)設(shè)施，但是它太重要了，對服務(wù)的高可用影響很大?；A(chǔ)設(shè)施的工作都做到位了就萬事大吉了嗎？不，還差一口氣——還需要確保最后一公里萬無一失，那就是服務(wù)的發(fā)布管理。最后一公里主要從以下三點著手規(guī)劃。

?

容量規(guī)劃

通過測試報告評估應(yīng)用的類型是 I/O 密集型、CPU 密集型還是混合型，根據(jù)應(yīng)用的類型申請合理的硬件資源。單臺節(jié)點最大處理能力是多少？線上有多少容量正在被使用？集群的最大處理能力是多少？這些在發(fā)布前都需要合理地評估和測試。

冗余規(guī)劃

需要考慮異地多可用區(qū)部署，部署服務(wù)實例不小于 N+2，服務(wù)實例硬件配置相同，避免部署實例大小不一。為什么是 N+2 而不是 N+1 呢？這是為了防止在服務(wù)更新時掛掉一個服務(wù)節(jié)點（發(fā)布失敗是高概率事件）。

?

發(fā)布控制

在線下進行充分測試，能在線下做的測試絕不放在線上做。就像上面所說的，發(fā)布失敗是高概率事件，所以發(fā)布必須要支持回滾，必須拒絕一切沒有回滾方案的更新。必須拒絕！

?

?

11.6???? 總結(jié)

?

?

在微服務(wù)架構(gòu)下可以按功能和職責(zé)充分分解服務(wù)，解耦依賴，單個服務(wù)易于開發(fā)和維護，解鎖了技術(shù)棧，實現(xiàn)了更短的開發(fā)迭代周期，促進敏捷開發(fā)和持續(xù)部署。但我們也要充分認(rèn)識到微服務(wù)有著分布式架構(gòu)固有特點帶來的復(fù)雜性，大量服務(wù)之間的通信對應(yīng)用的集成測試、穩(wěn)定性、運維和監(jiān)控提出了更高的要求，CAP 理論的約束對數(shù)據(jù)的一致性也帶來了更大的挑戰(zhàn)。微服務(wù)架構(gòu)對基礎(chǔ)設(shè)施的投入很大，簡單應(yīng)用采用單體架構(gòu)更經(jīng)濟有效，大型復(fù)雜應(yīng)用采用微服務(wù)架構(gòu)才能體現(xiàn)投入的價值。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝