【51CTO.com原創(chuàng)稿件】從單體程序到微服務(wù)，再到當下流行的服務(wù)網(wǎng)格概念，Spring 連接起了這兩個時代。它曾是單體程序的代名詞，但是卻在微服務(wù)時代浴火重生，給我們帶來了 Spring Cloud。

[[233881]]

借助于 Spring Cloud，蘇寧大數(shù)據(jù)中心完成了微服務(wù)架構(gòu)轉(zhuǎn)型，在實踐中并不是一帆風順，有思索、有迷茫，更有解決問題的樂趣。

為什么要微服務(wù)化？

為什么是 Spring Cloud？

蘇寧數(shù)據(jù)中臺后端是傳統(tǒng)的開發(fā)架構(gòu)， VIP 負載均衡 + Nginx + SpringMVC，代碼以單體程序為主。

正常情況下一個項目使用統(tǒng)一域名，在蘇寧現(xiàn)有開發(fā)架構(gòu)下，統(tǒng)一域名導(dǎo)致后端只能有一個 war 包，程序變成單體程序變成必然。

如下圖所示是典型的舊式項目代碼目錄：

• 項目名稱-web：對外 war 包模塊
• 項目名稱-interface：統(tǒng)一定義接口
• 項目名稱-service：統(tǒng)一定義接口實現(xiàn)

整個項目管理、開發(fā)思路，圍繞單體程序開發(fā)模型設(shè)計，帶來的弊端很明顯：

• 代碼職責不清晰，每個人都在同一模塊下提交代碼
• 違反高內(nèi)聚低耦合
• 服務(wù)擴展不方便

首先微服務(wù)化思路，并不高大上，我們?yōu)槭裁催x擇微服務(wù)化，首要原因是管理問題。

結(jié)合蘇寧現(xiàn)有開發(fā)架構(gòu)，整個微服務(wù)架構(gòu)如圖：域名解析 + VIP 負載均衡 + Nginx + 服務(wù)網(wǎng)關(guān) + 各個服務(wù)。

下圖是某個項目采用微服務(wù)化后的工程代碼目錄：

• 項目名稱-模塊1
• 項目名稱-模塊2

整個代碼目錄更清晰，利于模塊拆分、人員職責安排。

數(shù)據(jù)中臺項目背景介紹

蘇寧數(shù)據(jù)中臺是一個大項目群：

• OLAP 是底層的加速、查詢引擎，底層支持 Druid、ES、PGCitus 集群，類似 Presto，跟 Presto 不同的是 OLAP 會主動對數(shù)據(jù)進行 Cube 預(yù)加速。
• 百川是指標平臺層，讓用戶建模、定義指標，對外提供指標查詢服務(wù)。百川主要支持的建模方式是：星型模型。
• 數(shù)據(jù)建模自然離不開維表維度，UDMS 系統(tǒng)就是來定義、管理所有維度、維表，目前收錄了整個集團近 200 多個維度，對外提供維度、維表信息服務(wù)。
• 天工是類似 Tableau、Superset 的可視化報表設(shè)計平臺，與這些 BI 軟件***的不同點是，天工基于百川的指標、UDMS 的維度來制作報表，數(shù)據(jù)來源已經(jīng)高度標準化、歸一化。

目前商業(yè)報告分析工具：Cognos、阿里 QuickBI 等，是將數(shù)據(jù)建模、可視化設(shè)計能力放到一起，這是天工與它們的***區(qū)別。

• 慧眼，是統(tǒng)一報表門戶，所有的報表統(tǒng)一發(fā)布到慧眼面向業(yè)務(wù)。慧眼***的挑戰(zhàn)在于報表權(quán)限管控與自動匹配，總共 4000 多張報表，用戶 2w 多，一張報表開放給8000+人員是很常見的。

所有這一切靠人工維護，既容易出錯又不利于數(shù)據(jù)安全，也不能及時響應(yīng)用戶需求，這些都是慧眼系統(tǒng)要解決的問題。

微服務(wù)框架選型

Dubbo 架構(gòu)介紹

Dubbo 主要有四個模塊：

• Monitor（監(jiān)控）
• Regsitry（注冊中心）
• Provider（服務(wù)方）
• Consumer(消費方)

Provider 注冊服務(wù)到 Regsitry，Consumer 向 Regsitry 訂閱服務(wù)信息，Monitor服務(wù)監(jiān)控服務(wù)調(diào)用情況。

整個服務(wù)調(diào)用流程如下：

• 消費方在本地發(fā)起服務(wù)調(diào)用
• 動態(tài)代理將調(diào)用交給 Loadbalance 模塊
• Loadbalance 從 Registry 拿到服務(wù)實例信息
• 將請求發(fā)送到一臺服務(wù)實例
• 記錄監(jiān)控日志等信息

Spring Cloud 架構(gòu)介紹

Spring Cloud 整個架構(gòu)與 Dubbo 非常類似：

• Eureka（注冊中心）
• Gateway（服務(wù)網(wǎng)關(guān)）
• Provider（服務(wù)方）
• Consumer(消費方)
• Zipkin（監(jiān)控）

不同的有如下幾點：

• Spring Cloud 是 Http Rest 接口，Dubbo 不是。
• Spring Cloud 注冊中心不使用 Zookeeper，使用自研的 Eureka。

關(guān)于 Zookeeper 是否適合做注冊中心，請參考文章：《Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery》、《阿里巴巴為什么不用 ZooKeeper 做服務(wù)發(fā)現(xiàn)》

• Spring Cloud 提供了 Gateway 網(wǎng)關(guān)組件。
• 與 Spring 生態(tài)兼容，生態(tài)鏈豐富，自定義 Filter、攔截器，來加強功能, 如：權(quán)限校驗、日志打印等；Spring Cloud Netflix 提供了熔斷、限流等組件。

綜合以上幾點，考慮到架構(gòu)統(tǒng)一，未來發(fā)展趨勢，我們選擇了 Spring Cloud。

Spring Cloud 主要幫助我們做系統(tǒng)內(nèi)部服務(wù)化，REST 接口形式，不會破壞現(xiàn)有服務(wù)，前端服務(wù)調(diào)用無需做任何調(diào)整。

選擇 Spring Cloud 還有一個重要原因是 Dubbo 與蘇寧 RSF 服務(wù)框架高度重合，在對外服務(wù)接口上，我們還是以 RSF 接口為主。

基于 Spring Cloud 的服務(wù)化實踐

整體架構(gòu)介紹

整體有幾個組件：注冊中心、服務(wù)網(wǎng)關(guān)、服務(wù)監(jiān)控、負載均衡器。注冊中心使用 Spring Cloud 提供的 Eureka，服務(wù)網(wǎng)關(guān)使用 Spring Cloud 提供的 Zuul 組件，負載均衡器使用 Ribbon 組件。

服務(wù)網(wǎng)關(guān)的負載均衡策略選擇的是：WeightedResponseTimeRule，根據(jù)服務(wù)器響應(yīng)時間來決定路由到哪個節(jié)點。

服務(wù)監(jiān)控組件，用來監(jiān)控服務(wù)性能、調(diào)用情況，最重要的一點，是將整個服務(wù)鏈路能串聯(lián)起來。

服務(wù)監(jiān)控設(shè)計

監(jiān)控是一個系統(tǒng)的眼睛，是斷然不可缺少的一部分，Zipkin 提供了很好的服務(wù)鏈路監(jiān)控，結(jié)合我們自身的使用場景，最終我們沒有選擇 Zipkin，為什么？

首先了解下 Zipkin 整體架構(gòu)：

• 數(shù)據(jù)采集（Brave、Sleuth）
• Tranport 數(shù)據(jù)傳輸（支持 Kafka、直接發(fā)送 Collector）
• Collector（數(shù)據(jù)收集）
• Storage（存儲：ES）
• Search + Webui（監(jiān)控展示）

整體架構(gòu)如下圖所示，Zipkin 監(jiān)控數(shù)據(jù)格式如下：

Zipkin 有如下缺點：

• 我們不止是監(jiān)控 Spring Cloud 服務(wù)調(diào)用，如：蘇寧 RSF 服務(wù)調(diào)用、SQL 的執(zhí)行時間、本地方法執(zhí)行時間等。
• 監(jiān)控數(shù)據(jù)格式不滿足業(yè)務(wù)需要。
• Collector 節(jié)點容易出現(xiàn)性能瓶頸，ES 聚合查詢性能較差。
• 跨線程，鏈路無法串聯(lián)。

基于以上幾點，我們決定自研服務(wù)鏈路監(jiān)控系統(tǒng)，整個系統(tǒng)架構(gòu)如下，我們利用 Kafka、Druid，原則上提供了***擴展性。

Druid 對應(yīng) Zipkin 中的角色：Collector（數(shù)據(jù)收集） + Storage（存儲：ES）。

我們結(jié)合業(yè)務(wù)的需要，設(shè)計了監(jiān)控日志格式，如下圖所示：

一條調(diào)用鏈路，有相同的根 ID，服務(wù)名由三部分組成：

• 系統(tǒng)名
• 一級名稱
• 二級名稱

一級名稱有 7 種值：

• url：http 接口
• url-call：調(diào)用 http 接口
• rs：rsf 接口
• rsf-call：調(diào)用 rsf 接口
• sql：執(zhí)行 sql
• cache：操作緩存
• method：本地方法

你可能會問，沒有存儲父 ID，如何判斷一條鏈路中的父子關(guān)系？這里我們設(shè)計一個特殊的事務(wù) ID 生成規(guī)則，通過事務(wù) ID 本身即能判斷父子關(guān)系，如下圖所示：

下圖監(jiān)控系統(tǒng)的鏈路展示頁面：

基于 Hystrix 的熔斷設(shè)計

Hystrix 對應(yīng)的中文名字是“豪豬”，豪豬周身長滿了刺，能保護自己不受天敵的傷害，代表了一種防御機制，這與 Hystrix 本身的功能不謀而合。

因此 Netflix 團隊將該框架命名為 Hystrix，并使用了對應(yīng)的卡通形象作為 Logo。

在一個分布式系統(tǒng)里，許多依賴會不可避免的調(diào)用失敗，比如超時、異常等。

如何能夠保證在一個依賴出問題的情況下，不會導(dǎo)致整體服務(wù)失敗，這個就是 Hystrix 需要做的事情。

Hystrix 提供了熔斷、隔離、Fallback、Cache、監(jiān)控等功能，它能夠在一個、或多個依賴同時出現(xiàn)問題時保證系統(tǒng)依然可用。

使用 Hystrix 很簡單，只需要添加相應(yīng)依賴即可，最方便的方式是使用注解 HystrixCommand：

• fallbackMethod：指定 Fallback 方法
• threadPoolKey：線程池名稱
• threadPoolProperties：指定線程池參數(shù)（線程池大小、***隊列排隊數(shù)量）
• commandProperties：CIRCUIT_BREAKER 開頭的參數(shù)配置熔斷相關(guān)參數(shù)，METRICS_ROLLING 開頭的參數(shù)設(shè)置指標計算相關(guān)參數(shù)
• 相關(guān)參數(shù)定義，參考類：HystrixPropertiesManager

@RestController 
public class HystrixTest { 
    @RequestMapping(value = "/query/user/name", method = RequestMethod.GET ) 
    @HystrixCommand(fallbackMethod = "getDefaultUserName", threadPoolKey = "query_user", 
            threadPoolProperties = { 
                    @HystrixProperty(name = CORE_SIZE, value = "10"), 
                    @HystrixProperty(name = MAX_QUEUE_SIZE, value = "10") 
            }, 
            commandProperties = { 
                    @HystrixProperty(name = CIRCUIT_BREAKER_ENABLED, value = "true"), 
                    @HystrixProperty(name = CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "1000"), 
                    @HystrixProperty(name = CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "25") 
            } 
    ) 
    static String getUserName(String userID) throws InterruptedException { 
        Thread.sleep(-1); 
        return userID; 
    } 
 
    public String getDefaultUserName(String userID) { 
        return ""; 
    } 
} 

基于服務(wù)網(wǎng)關(guān) Zuul 實現(xiàn)的廣播功能

有些時候我們希望 url 請求被所有服務(wù)實例執(zhí)行，這里我們對 Zuul 做了一個改造，增加了一個 BroadCastFilter，在 url 請求 header 設(shè)置 gate_broadcast 為 true，那么這個請求，將被轉(zhuǎn)發(fā)給所有服務(wù)實例。

邏輯流程如下：

• 判斷 gate_broadcast 參數(shù)為 true
• 從 url 獲取 ServiceId
• 從 Ribbon 獲取服務(wù)所有實例
• 將請求發(fā)送給所有實例
• 將所有實例返回結(jié)果封裝，返回

微服務(wù)帶來的問題

服務(wù)拆分粒度不好把握

Spring Cloud 的微服務(wù)有一個 ServiceId 的概念，通常一個 war 包對應(yīng)一個 ServiceId，這個 ServiceId 下可以有多個服務(wù)。粒度拆分方式主要有：橫向、縱向。

縱向切分主要有如下幾個方式：

• 按功能切，如用戶管理、指標管理、模型管理等。
• 按角色切，如管理員、商家、用戶。

橫向切分，一般用來提取公共的基礎(chǔ)服務(wù)，比如：用戶名密碼校驗服務(wù)、用戶基本信息查詢。

運維、開發(fā)復(fù)雜度增加

單體程序時代只有一個 war 包，微服務(wù)鼓勵服務(wù)拆分，war 數(shù)量、部署節(jié)點大大增加。

此外，一個流程處理往往會由多個分布式服務(wù)協(xié)同完成，帶來了不少棘手的問題：

• 需要通過分布式事務(wù)保障數(shù)據(jù)最終一致性
• 防止單個服務(wù)問題造成雪崩

這些都給開發(fā)者提出了更高的要求。

調(diào)試難度增加

微服務(wù)方式鼓勵服務(wù)拆分，通過服務(wù)間依賴完成功能，給開發(fā)、測試帶來了挑戰(zhàn)，合理選擇微服務(wù)、代碼復(fù)用兩種方案。

后續(xù)架構(gòu)演進

服務(wù)版本控制

沒有版本控制，意味著我們無法做灰度發(fā)布，毀滅性版本發(fā)布后，無法做到對老版本兼容，下圖為服務(wù) A、B、C、D 間的版本依賴關(guān)系：

我們實現(xiàn)思路是對 Zuul 進行改造：

• 打版本標簽，在 Zuul 對訪問來源判斷（比如 App 版本 5.1 對應(yīng)的查詢接口版本為 2.1），打上版本標簽
• 根據(jù)版本信息，路由到對應(yīng)版本服務(wù)實例

基于 Gateway 的服務(wù)熔斷、限流機制

目前有一些開源的框架如 ratelimit，通過在 Ruul 增加 filter 來實現(xiàn)限流熔斷。

但是有幾個問題：

• 不支持動態(tài)配置
• 不能滿足業(yè)務(wù)變化，如配合版本控制

綜上所述，我們已經(jīng)著手一些自研工作，能與我們業(yè)務(wù)場景貼合得更緊密。

總結(jié)

從 2016 年到現(xiàn)在，兩年的時間里，蘇寧大數(shù)據(jù)中心從傳統(tǒng)的單例開發(fā)模式，切換到基于 Spring Cloud 的微服務(wù)開發(fā)模式，并摸索出了一條適合自己的路，這不只是技術(shù)框架的切換，更是開發(fā)思維的升級。

令人欣喜的是，這兩年間 Spring Cloud 飛速發(fā)展，2018 年發(fā)布了革命性的 2.0 版本，這離不開社區(qū)的支持，許多像 Netflix 一樣的公司在筆耕不輟地為 Spring Cloud 生態(tài)添磚加瓦。

我們基于 Spring Cloud 開發(fā)出了一些服務(wù)于自己業(yè)務(wù)的組件，讓我們認識到自己也是有能力有責任去回饋社區(qū)。

路漫漫其修遠兮，好的架構(gòu)一定是適應(yīng)業(yè)務(wù)發(fā)展的架構(gòu)，對于 Spring 這不是終點，對于我們更不是。

作者：王富平

簡介：蘇寧易購大數(shù)據(jù)中心數(shù)據(jù)中臺技術(shù)負責人，歷任百度大數(shù)據(jù)部高級工程師、1  號店搜索與精準化部門架構(gòu)師。多年來，一直從事大數(shù)據(jù)方向的研發(fā)工作，對大數(shù)據(jù)工具、機器學(xué)習有深刻的認知，在實時計算領(lǐng)域經(jīng)驗豐富，對 Storm、Spark Streaming 有深入了解。熱愛分享和技術(shù)傳播，目前關(guān)注數(shù)據(jù)分析平臺的建設(shè)，旨在打通數(shù)據(jù)建模到數(shù)據(jù)分析，基于 Druid、Kylin 等 OLAP 技術(shù)，提供一個平臺級別的數(shù)據(jù)指標服務(wù)，打造"數(shù)據(jù)即服務(wù)"的一站式解決方案。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】