德比軟件：基于云的理基微服務架構
作者：朱攀，德比軟件架構師，服務同濟大學研究生，日億2007 年 2 月加入德比軟件（DerbySoft），處架構擁有 10 年以上的理基軟件架構和開發(fā)經驗。目前主要負責公司數據對接平臺的服務架構、基礎設施建設、日億技術團隊管理及公司技術的處架構布道。作為德比軟件的理基早期員工，從無到有地主導了德比軟件數據對接平臺的服務架構設計和實現(xiàn)，完成了數據對接平臺多個版本的日億架構改進和升級，數據對接平臺每天處理的處架構 API 調用從 0 增長到現(xiàn)在的 10 億多。期間設計實現(xiàn)了很多必要的理基基礎設施和服務，如公司內部的 RPC 框架 DerbySoft-RPC、智能路由服務 Router、分布式數據存儲服務 DStorage、網關服務 DGateway 等。目前主要關注基礎架構、微服務、大數據存儲和技術團隊建設。
?
?
10.1???? 概述
?
?
微服務概念被提出來以后，短時間內就成了互聯(lián)網圈的一個技術熱點，有很多互聯(lián)網公司計劃或正在進行微服務化改造，那么應該怎么開始實施微服務呢？需要哪些基礎設施來支持呢？我所在的公司德比軟件從 2009 年就開始采用面向服務架構（SOA）來重新實現(xiàn)數據對接平臺，我們積累了豐富的面向服務架構的經驗，而微服務架構是面向服務架構思想的一種實現(xiàn)，只是服務職責更單一，粒度更小，過程更自動化。我們在多年的服務化架構實踐過程中，已經不自覺地將服務的粒度細化了。本文想分享德比軟件在實施微服務架構過程中積累的一些基礎設施及這些基礎設施解決的痛點問題，希望對大家有所幫助和啟發(fā)。
?
?
10.2???? 德比軟件數據對接平臺的架構
?
數據對接平臺的架構大體上分三個層次，如圖 10.1 所示，最外面是 API 層，由 API Gateway（網關）和各業(yè)務的 API 服務組成；中間層是服務層（Service），平臺的大部分功能在這一層實現(xiàn)，服務之間可以通過依賴或組合組成功能更強的服務；底層是數據存儲層（Data Storage），由緩存層和存儲層組成。數據對接平臺采用微服務架構，為了支撐這個架構，我們提供了必要的基礎設施來保障上層各個服務和應用的可用性。
?
圖 10.1
?
?
10.3???? 德比軟件微服務架構基礎設施
?
如圖 10.2 所示，將基礎設施分為了八大部分，分別是服務框架、基礎服務、API 網關、自動化、服務降級、監(jiān)控報警（服務健康狀態(tài)）、日志處理和調用鏈追蹤。其中，
服務框架、基礎服務、API 網關和服務降級的作用是提高服務的連續(xù)工作時間；
自動化可以簡化開發(fā)和部署過程；
監(jiān)控報警、日志處理和調用鏈追蹤可以幫助快速發(fā)現(xiàn)問題、定位問題并解決問題。
?
圖 10.2
?
?
基礎設施全景圖如圖 10.3 所示。
?
?
圖 10.3
?
?
10.4???? API 網關
?
API 網關是微服務架構中不可或缺的部分。API 網關是對外提供的服務，是系統(tǒng)的入口，所有的外部系統(tǒng)都需要通過 API 網關來接入。Dgateway 提供安全認證、流控、路由、 API 版本管理等功能。流控維度分為用戶類型、用戶來源、IP、業(yè)務 API 等，保護服務或資源不被濫用或攻擊。DGateway 基于開源軟件 Tyk 做了二次開發(fā)。
?
?
10.5???? 服務框架
?
服務框架分兩部分，高可用的 RPC（DerbySoft-RPC）和服務依賴管理，如圖 10.4 所示。
?
圖?10.4
10.5.1??? 高可用 RPC
?
RPC 是微服務架構中最重要的基礎組件，一個健壯的 RPC 能有效降低實施微服務架構的成本。RPC 封裝了遠程調用的復雜細節(jié)，讓服務使用方感覺像調用本地方法一樣調用遠程方法，服務提供方感覺像實現(xiàn)本地接口一樣來實現(xiàn)服務。DerbySoft-RPC 分為 Client 和Server 兩部分。Client 主要有以下功能。
?
客戶端故障檢測，識別并標示太慢或崩潰了的服務器。
?
熔斷機制，如果發(fā)現(xiàn)服務超時比例過限，則啟動熔斷，客戶端會快速返回失敗，以減輕服務端的壓力，定時允許部分請求通過，根據請求返回的健康程度來決定是否恢復熔斷。
?
負載均衡策略，通過記錄到每個節(jié)點的未完成請求數來決定下一個請求發(fā)到哪里。容錯機制，對某些錯誤自動重試，比如連接的服務節(jié)點不可用時可以自動將請求再次發(fā)送到其他節(jié)點，可定義重試次數。
?
序列化和反序列化，選擇序列化工具最重要的考量點有性能高低、是否多語言支持、序列化后的消息大小、是否向前兼容等。我們嘗試過各種序列化工具，而 Protocol Buffer 在性能和空間占用上都表現(xiàn)優(yōu)異，是我們使用最頻繁的序列化工具。對敏感數據加密，比如信用卡等敏感信息，需要在 Client 端加密傳輸。
?
超時管理，可設定每個請求的超時時間。
Server 部分相對簡單，主要提供超時管理、序列化和反序列化、敏感信息解密、隊列管理、線程管理等功能。
剛才提到選擇序列化工具時需要考慮是否支持多語言，這一點很重要，RPC 最好能在多語言環(huán)境下實現(xiàn)，這樣能讓技術團隊突破編程語言限制，使技術棧更豐富靈活。我們在這方面是有過教訓的。
在公司早期，大概是 2009 年，當時的業(yè)務量不大，在語言上主要使用 Java，為了方便我們在第一個 RPC 版本上采用了 Java 序列化機制，卻導致后面想要更換編程語言時大受限制。因此我們做了第二版 RPC，將序列化機制換掉，采用 Java 的字節(jié)序以兼容第一個版本。DerbySoft-RPC 是第三版 RPC，實現(xiàn)了對 Go、Scala 和 Java 三種語言的兼容。原則上我們不限制服務的實現(xiàn)語言，只要能按要求實現(xiàn)服務接口并滿足性能要求即可。微服務化后的一個好處就是根本不用擔心使用小眾的編程語言，如果每個服務的粒度足夠小，那么最壞的情況就是在沒人能維護這個小眾語言的服務時，需要花點時間用熟悉的語言來重寫。
?
?
10.5.2??? 服務依賴管理
?
?
微服務化之后，系統(tǒng)面臨的一個突出問題是服務雖小，但是數量極多。如果這些服務全部在一個可用區(qū)內，那么服務之間的依賴還比較好管理，可以做服務自動注冊和發(fā)現(xiàn)來實現(xiàn)依賴管理，但是如果服務分布在很多可用區(qū)中，尤其是分布在跨國跨地區(qū)的可用區(qū)之間，則其依賴和調用的管理就會比較麻煩。
?
另外，跨可用區(qū)服務之間的調用還需要考慮通信安全的問題，對每個服務設置不同的特殊端口，如果需要跨區(qū)域調用服務，那么配置訪問權限也是一件麻煩的事情。
?
眾多服務的依賴示例如圖 10.5 所示。
?
?
圖 10.5
圖 10.5 所示的服務依賴是不是很亂？我們的服務節(jié)點分布在全球 14 個可用區(qū)，大部分在亞馬遜云上，小部分在自建的私有云里，可用區(qū)之間的服務有復雜的依賴關系。為了解決這種情況下服務之間的依賴調用問題、API 安全問題和服務的高可用問題，我們設計開發(fā)了路由服務，以解耦服務的調用者和提供者，簡化網絡拓撲及服務器的安全配置。引入路由之后，簡化后的服務之間的依賴關系如圖 10.6 所示。
?
?
圖 10.6
?
所有的服務只和路由通信，服務之間不再相互依賴，每個服務只需要依賴并維護自己所在的可用區(qū)路由節(jié)點，路由會找到調用的服務目的地。絕大部分情況下，它在本區(qū)域內就能找到相應的服務，不需要跨區(qū)，這取決于服務的部署情況。為了提高響應速度，每個可用區(qū)都需要部署關鍵的服務，除非本可用區(qū)的服務崩潰了，否則在這種情況下不會出現(xiàn)跨區(qū)訪問。有些服務不是那么重要，可能只會在某個或某幾個可用區(qū)中部署，這時也可能會出現(xiàn)服務跨可用區(qū)調用的情況。
這樣不僅更好地管理了依賴，解決了服務器可用區(qū)調用問題，還解決了 API 訪問安全問題：每個可用區(qū)建立一個 VPC（虛擬私有云），所有的服務都在 VPC 內，VPC 內的 API 調用可忽略安全驗證，跨 VPC 路由節(jié)點之間用安全組來限制 IP 白名單訪問，只允許路由節(jié)點可以跨可用區(qū)訪問其他 VPC 內的路由節(jié)點，服務訪問路由或者路由訪問服務都必須在同一個 VPC 內使用內網地址訪問。
?
10.6???? 基礎服務
?
?
基礎服務分為四部分，分別是配置中心、安全數據服務、數據存儲服務、訂單服務，如圖 10.7 所示。基礎服務大多和存儲有關，提供高性能、高可用的服務。
?
?
圖 10.7
?
10.6.1??? 配置中心
?
?
配置中心提供高可用的配置數據存儲服務，幾乎所有的應用和服務都依賴配置中心。配置中心主要解決基礎數據和配置數據的單點依賴及節(jié)點之間的數據同步問題，以便更好地支持各個服務的水平伸縮。配置中心可以配置主鍵、索引字段、唯一約束、每個字段的類型約束等，其功能類似于數據庫，開放全量和變量的同步接口，提供多語言的客戶端 SDK，同步全量或變量數據，根據服務端的配置，在內存中建立數據索引，緩存數據，并在本地文件中持久化緩存的備份，如圖 10.8 所示。
圖 10.8
?
一個依賴配置中心的服務，在啟動時會先查找本地文件中有沒有配置數據的緩存，如果有，則從文件中加載配置數據到內存中，啟動服務，接著調用變量接口對比本地數據和配置中心的數據是否是同一版本，如果數據有變化，則更新數據到本地緩存。如果本地文件中沒有配置數據的緩存，則先調用一次全量接口緩存所有配置數據到本地緩存。即使配置中心的所有節(jié)點都無法運行，也不影響各個依賴它服務的現(xiàn)有節(jié)點的正常工作。
?
因為每個服務都會緩存依賴的配置數據，所以對配置中心的性能要求不是太高，我們用 AWS RDS 來解決配置數據存儲的高可用問題。AWS RDS 是一個托管關系數據庫服務。
?
10.6.2??? 安全數據服務
?
?
高可用的安全數據服務提供數據加密和解密服務，定時清理過期的數據，解決敏感數據的安全臨時存儲和傳輸問題，比如銀行卡和信用卡信息的臨時存儲和傳輸。需要傳輸敏感信息時，在數據傳輸方調用數據加密服務的加密接口，并明確信息有效時間，加密服務會將信息加密后存儲，并返回一個全局唯一 ID，數據傳輸方發(fā)送這個唯一 ID 給數據接收方，如果數據接收方收到這個 ID 之后，調用數據解密接口，則加密服務會根據 ID 找到相應的數據，返回解密之后的數據。
?
?
10.6.3??? 數據存儲服務
?
Dstorage 提供高可用的酒店動態(tài)數據存儲服務，可以解決酒店海量動態(tài)數據存儲問題，提供高性能的數據存取接口，提供變量數據的同步接口。根據性能和容量需求，用戶可選的存儲引擎有 Redis、Codis、Ardb、DynamoDB 等。DStorage 支持多可用區(qū)部署，通過變化發(fā)現(xiàn)服務，實現(xiàn)多可用區(qū)的數據同步，保證數據最終一致性。
?
Dcontent 提供高可用的酒店靜態(tài)數據緩存服務可以解決酒店海量靜態(tài)數據的緩存問題。底層支持的存儲引擎有 Ardb、Redis 等。DContent 支持一主多從多可用區(qū)部署，也支持多主多可用區(qū)部署，保證數據最終一致性。
?
AWS S3 提供高可用的文件存儲服務，可以存儲文件數據，如圖片、視頻、日志文件、備份數據等。
?
?
10.6.4??? 訂單服務
?
?
由于訂單數據比較特殊，所以將與訂單相關的功能單獨出來，作為獨立服務。訂單服務聚合所有系統(tǒng)節(jié)點的訂單信息，讓訂單比較容易追溯，提供高可用的訂單存儲和查詢服務，解決訂單數據的單點存儲問題，更好地支持其他依賴訂單數據的系統(tǒng)進行水平擴展和遷移。訂單服務對可用性要求極高，底層存儲依賴 AWS RDS，在全球每個可能用到訂單服務的可用區(qū)部署訂單服務集群。
?
?
10.7???? 服務降級
?
?
根據業(yè)務要求對每個服務及其依賴的資源按重要程度進行分級，限制每個依賴服務的超時時間，定義各級服務的 SLA 指標，對強依賴的基礎服務或資源實行更高的 SLA 標準，根據 SLA 指標制定容錯方案。
?
制定服務自動降級策略，設置服務開關，關鍵時刻“棄車保帥”，對弱依賴的服務進行降級，比如將日志服務降級以保障重要的服務不受影響。
?
對超大數據或流量用戶進行隔離，在隔離的環(huán)境中為這部分用戶提供獨立的服務，避免影響其他正常用戶服務。
?
?
10.8???? 自動化
?
?
微服務化后，服務的數量很多，為了節(jié)約開發(fā)成本，必須盡可能地自動化完成一些有固定步驟的工作，如自動化測試和自動化部署，如圖 10.9 所示。
圖 10.9
?
1．自動化測試。
?
單元測試自動化：我們目前要求單元測試覆蓋率大于 90%，通過 Jenkins 整合 Sonar。每次提交代碼后自動運行單元測試，Sonar 會自動給出代碼評分，如果測試覆蓋率不夠或代碼不達標，則單元測試失敗。
?
性能測試自動化、平臺化：我們開發(fā)了自動化測試平臺 DTesting，關鍵服務的每次變更都需要在平臺上進行性能測試，并生成性能測試報告，對比歷史的性能測試數據。
?
功能測試自動化、平臺化：每個應用都有完整的功能測試用例和腳本，可自動化回歸功能測試。
?
2．自動化部署。
我們引入了 Docker，以減少人為部署時的誤操作。
?
?
10.9???? 日志處理
?
?
日志處理分為兩部分：一部分是實時日志處理，另一部分是冷日志處理。所有的應用日志都需要寫入 Kafka 和文件，Kafka 中所有的實時日志都會被 DLog 系統(tǒng)及時消費處理，但是實時日志的保留時間不長，一般保留一個月。寫入文件的所有日志會被定時備份到 AWS S3 上永久保留，如果需要一個月前甚至更久以前的系統(tǒng)日志，則可以在 DLog 系統(tǒng)中選擇需要的日志范圍，DLog 會將符合條件的日志從 S3 上下載下來并重新建立日志索引。日志主要是為監(jiān)控提供基礎源數據，為定位問題提供依據，如圖 10.10 所示。
圖 10.10
?
?
10.10???? 調用鏈追蹤
?
?
隨著服務的粒度越來越小，系統(tǒng)的服務變得越來越多，不同的服務可能由不同的團隊實現(xiàn)，一個服務的實現(xiàn)可能會依賴幾個甚至十幾個服務。對于出現(xiàn)問題后，如何快速準確地定位故障，如何追蹤業(yè)務的處理順序和結果，業(yè)內已經有了一些實踐和解決方案，Google Dapper 是 Google 研發(fā)的分布式跟蹤系統(tǒng)，Google 也為此發(fā)表論文闡述了分布式跟蹤系統(tǒng)的理論基礎，給分布式跟蹤的實現(xiàn)提供了非常好的參考示范。對于 Java 編寫的服務，我們采用 Zipkin 來做調用鏈跟蹤，Zipkin 是 Google Dapper 系統(tǒng)的開源實現(xiàn)，采用 Scala 編寫；
?
而對于 Go 語言實現(xiàn)的服務，我們目前還沒有好的解決方案。一個好的調用鏈追蹤系統(tǒng)能為定位和排查故障提供強有力的支持。對于微服務架構，調用鏈追蹤是必備的基礎設施。
?
?
10.11??? 服務健康狀態(tài)
?
?
很多情況下，解決故障可能很快，難點在于發(fā)現(xiàn)故障和定位故障，這需要我們的系統(tǒng)有全方位的監(jiān)控和報警能力。基于業(yè)務和技術對可用性的需求，我們開發(fā)了服務健康狀態(tài)監(jiān)控和報警系統(tǒng)，從業(yè)務層、服務層、硬件基礎設施層分別進行監(jiān)控和報警，如圖 10.11 所示。
?
10.11.1??? 報警
?
?
報警系統(tǒng)定義所有報警種類、報警級別、處理流程，并提供報警接入機制，各個層次的監(jiān)控都可以通過自定義報警引擎接入報警系統(tǒng)來觸發(fā)報警。7 × 24 小時服務監(jiān)控團隊會根據各個報警的處理流程，依次聯(lián)系最高優(yōu)先級的處理人來處理故障，如果在規(guī)定時間內沒有處理完畢，則系統(tǒng)會根據報警的種類和級別自動升級報警響應級別，提高處理優(yōu)先級來保障重要的報警能得到及時處理。
?
圖 10.11
?
10.11.2??? 監(jiān)控
?
監(jiān)控分為硬件基礎設施層監(jiān)控、服務層監(jiān)控和業(yè)務層監(jiān)控三大類。
?
硬件基礎設施層監(jiān)控，包括操作系統(tǒng)、內存、CPU、網絡流量和狀態(tài)、連接數等方面的監(jiān)控。我們用 Zabbix 來做基礎設施層的監(jiān)控，通過 Zabbix 的 API 將數據整合進我們的監(jiān)控系統(tǒng) DMonitor。
?
服務層監(jiān)控，包括基礎組件監(jiān)控、基礎服務監(jiān)控、常規(guī)服務監(jiān)控和外部接口調用監(jiān)控。其中，基礎組件監(jiān)控包括對 Etcd、AWS RDS、Redis、Docker、Kafka 等基礎組件使用情況的監(jiān)控；基礎服務監(jiān)控包括對配置中心服務、認證服務、安全存儲服務、路由服務、API Gateway 等關鍵服務的監(jiān)控；常規(guī)服務監(jiān)控則是監(jiān)控所有一般服務的狀態(tài)；而外部接口調用監(jiān)控是監(jiān)控分析系統(tǒng)依賴的外部訪問情況，包括訪問量、錯誤信息、超時狀況等，為快速定位問題提供依據。
?
業(yè)務層監(jiān)控，是指從業(yè)務角度出發(fā)，收集和分析業(yè)務層的訪問量，根據各個業(yè)務的歷史數據和已知的影響因素預測現(xiàn)在和未來的業(yè)務情況，定義監(jiān)控報警目標。比如，在最近半個小時內某個業(yè)務的請求量小于預期值，在最近 1 個小時內對某個客戶的 API 調用次數超過預期值，在最近 3 個小時內某酒店的訂單量顯著下降，等等。由于業(yè)務層的監(jiān)控比較多，因此我們把業(yè)務層的監(jiān)控獨立出了一個子系統(tǒng)。業(yè)務層監(jiān)控報警的決策來源于歷史數據和未來可能影響系統(tǒng)的因子，通過對歷史中的海量數據進行匯總加工和分析，從各個維度給出報警的預期值。
?
服務層監(jiān)控和業(yè)務層監(jiān)控都離不開各個應用的支持，有些監(jiān)控目標會對應用的實現(xiàn)有侵入性，比如需要寫業(yè)務日志，各個應用根據監(jiān)控的目標來設計和實現(xiàn)，為業(yè)務層監(jiān)控提供必要的技術支持，因此從系統(tǒng)架構層面開始就需要考慮業(yè)務的可用性需求。有了服務健
?
康狀態(tài)的監(jiān)控和報警系統(tǒng)，再輔以調用鏈追蹤系統(tǒng)和日志處理系統(tǒng)，發(fā)現(xiàn)和定位故障的時間就比較可控了，可以很快定位絕大部分故障的發(fā)生原因，為修復故障提供有力的保障。整個發(fā)現(xiàn)定位故障的層次如圖 10.12 所示。
?
?
圖 10.12
?
?
10.12???? 發(fā)布管理
?
?
最后我想說說發(fā)布管理。雖然它不屬于基礎設施，但是它太重要了，對服務的高可用影響很大。基礎設施的工作都做到位了就萬事大吉了嗎？不，還差一口氣——還需要確保最后一公里萬無一失，那就是服務的發(fā)布管理。最后一公里主要從以下三點著手規(guī)劃。
?
容量規(guī)劃
通過測試報告評估應用的類型是 I/O 密集型、CPU 密集型還是混合型，根據應用的類型申請合理的硬件資源。單臺節(jié)點最大處理能力是多少？線上有多少容量正在被使用？集群的最大處理能力是多少？這些在發(fā)布前都需要合理地評估和測試。
冗余規(guī)劃
需要考慮異地多可用區(qū)部署，部署服務實例不小于N+2，服務實例硬件配置相同，避免部署實例大小不一。為什么是N+2而不是N+1呢？這是為了防止在服務更新時掛掉一個服務節(jié)點（發(fā)布失敗是高概率事件）。
?
發(fā)布控制
在線下進行充分測試，能在線下做的測試絕不放在線上做。就像上面所說的，發(fā)布失敗是高概率事件，所以發(fā)布必須要支持回滾，必須拒絕一切沒有回滾方案的更新。必須拒絕！
?
?
11.6???? 總結
?
?
在微服務架構下可以按功能和職責充分分解服務，解耦依賴，單個服務易于開發(fā)和維護，解鎖了技術棧，實現(xiàn)了更短的開發(fā)迭代周期，促進敏捷開發(fā)和持續(xù)部署。但我們也要充分認識到微服務有著分布式架構固有特點帶來的復雜性，大量服務之間的通信對應用的集成測試、穩(wěn)定性、運維和監(jiān)控提出了更高的要求，CAP 理論的約束對數據的一致性也帶來了更大的挑戰(zhàn)。微服務架構對基礎設施的投入很大，簡單應用采用單體架構更經濟有效，大型復雜應用采用微服務架構才能體現(xiàn)投入的價值。
特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
