[[423669]]

圖片來自 包圖網

當交易峰值曲線慢慢爬升，最后變得無比陡峭，值班室的同學都很激動，歡呼聲伴隨著爬升的曲線達到了頂峰，58.3 萬筆/秒，也是新的交易峰值記錄，但相比往年動輒翻一倍，漲 30%~40%，增長率還是小了很多。

2010 年雙 11 的支付峰值是 2 萬筆/分鐘，到 2017 雙 11 時變為了 25.6 萬筆/秒，再到去年的 58.3 萬筆/秒，是 2009 年第一次雙 11 的一千多倍。

要抗住這么大的支付 TPS，螞蟻做了很多頂層架構的設計和底層實現的優化，其中最為最核心的就是 LDC 架構。

LDC 的全稱為：Logic Data Center，邏輯數據中心，之所以叫 LDC，是跟傳統的 IDC(Internet Data Center)相比而提出來的概念。

IDC 相信大家都很清楚，就是物理的數據中心，說白了就是能夠建站的物理機房。

LDC(邏輯數據中心)，核心架構思想就是不管你物理機房部署是怎樣的，比如你可能有三個 IDC，分別在二個不同城市(常說的兩地三中心)，在邏輯上是統一的，我邏輯上看成一個整體，統一協調調配。

為什么會出現 LDC

LDC 是為了解決什么問題?還得從架構的演進說起。之前講過機房容災設計的架構演進，我們用具體的應用推演一次。

先看如下圖所示的單體應用架構，請求到網關接口，網關接口直接調應用或者服務，服務調存儲層查詢或寫入數據，一竿子捅到底。

這種架構模式最大的風險是服務、存儲都是單點的，訪問容量和性能受限于存儲和應用的容量和性能，容災方面，一旦發生故障只能死等單點應用或存儲的恢復。

后來工程師們開始對應用做水平拆分，對服務做垂直拆分。

水平拆分應該都很熟悉，就是加服務器，每臺服務器都部署實例，垂直拆分就是把服務按域做拆分。

比如一個交易系統，有商戶域、商品域、用戶域、訂單域等，拆分成多個微服務，服務解耦，服務可以獨立發布，應用的復雜度會更高。

這個分布式架構解決了服務單點的問題，某臺服務器宕機，服務還是可用的，但是存儲層還是單點的，而且隨著業務增長，擴容加的機器越多，大家發現查詢寫入效率耗時到一定階段反倒是變慢了，分析發現存儲層出現了性能瓶頸。

上面圖只花了 2 臺服務器連接數據庫，真實分布式系統可能幾十百來臺，甚至上千臺，如果都連一臺 DB，連接數、鎖爭用等問題，SQL 性能變慢可想而知。

后來的事情大家也都知道，互聯網公司開始紛紛做讀寫分離，把讀請求和寫請求分開。

讀寫分離這里面隱含了一個邏輯，那就是數據寫入之后，不會立即被使用。

數據從寫入到被立即使用有個時間差，等從庫同步數據才會被讀取，實際統計發現，常規的應用，90% 的數據確實在寫入之后不會立即被使用，當然我這里說的立即的時間單位是 ms，一般同步延遲也就是幾毫秒，不超過 10 ~20ms。

但是這個架構并沒有解決寫的問題，隨著業務量的增長，寫數據成為了瓶頸。分庫分表應運而生，分庫分表的中間件開始變得流行起來，現在基本成了中大型互聯網公司的標配。

基本思想就是把數據按照指定維度拆分，比較常見的是 userId 維度，例如取 userId 的后 2 位，可以拆分成百庫百表，也有的除以指定模數取余數，例如除以 64 取余，可以按余數范圍 0-63 拆成 64 個庫。

關于分庫分表，很多人都知道有垂直拆分和水平拆分二種(上面說的垂直和水平是系統的拆分，這里指的是存儲的)。

垂直拆分就是按照業務維度拆分，把同一個業務類型的表放到一個庫，經常會按領域模型的概念拆分，比如訂單庫、用戶庫、商品庫等。

水平拆分就是把大數據量的表(庫)切分成很多個小數據量的表(庫)，減小庫和表的訪問壓力，可以和系統的水平垂直切分比一下：

為什么叫水平和垂直呢?其實很好理解，你想象一張用戶表，里面放了很多字段，如下圖：

那垂直拆分，就是垂直從中間劃一刀，把藍色的用戶信息表和右邊綠色的訂單信息表拆分成 2 張表。庫拆分成用戶庫和訂單庫。

水平拆分，就是水平劃一刀，把數據量降低。

大家看到這，是不是以為問題都解決了，上面分庫分表之后，如果應用層面扛得住，數據庫層面的確能做到并發量到萬這個級別。但是容量要再上一個數量級就有點困難了。

為什么呢?因為一個庫實例是被所有應用共享的，也就是你每增加一臺機器，數據庫連接就會相應的增加一些，增量是至少機器設置的最小連接數。

為什么應用需要連接所有的數據庫實例呢?

答：網關層的流量可能走到任何一臺服務器，比如 A 用戶的請求到服務器上了，這時服務器一定要有 A 這個用戶 userId 分片的數據庫連接，否則要么把流量路由走，要么執行失敗。

分庫分表只是解決了單庫單表訪問壓力的問題，但是由于每一臺服務器都同時連接所有的分庫實例，到一定階段是沒發繼續擴容的，因為庫實例的連接數有瓶頸。

那數據庫存在瓶頸怎么弄?

相信聰明的你們其實已經猜到了，那就是按 userId 分片在應用層就做隔離，在網關層流量路由的時候把指定 uid 分片的流量路由到指定應用單元執行，這個應用單元流量內部自消化，如下圖：

比如 uid = 37487834，最后二位是 34 屬于 00-49 范圍，那用戶流量直接路由到 00-49 這個應用分組，在這個單元內的完成所有數據交互的操作。

這樣 uid 00-49 這個分組單元中的應用只用連 userId 00-49 分庫的數據庫，uid 50-99 分組單元的應用也是如此，數據庫的連接數一下直接降一半，而且還可以拆分單元，現在是 2 個單元，最多可以拆分到 100 個單元。

這里我加重了單元這個詞，因為這個是 LDC 中核心概念，下面重點說一下單元這個詞的具體含義。

單元在螞蟻有個名稱叫做 Zone，Zone 內部署的是完整的服務。

例如，一個用戶在一個 Zone 內可以完成一整套業務流程，流量不需要其他 Zone 來提供服務，擁有完成一整套服務的能力，在單個 Zone 就能完成一整套業務，是邏輯自包含的。

這樣有什么好處?某個 Zone 如果出現故障，路由層直接把這個 Zone 流量轉移到其他 Zone，接受這個 Zone 流量的其他幾個 Zone 可以分攤流量，流量調撥很方便。

下面這張圖是螞蟻 Zone 按照地區和 userId 分片的部署架構示意圖，做了一些簡化，實際 Zone 部署單元會稍微復雜一點。

上面介紹的 Zone 是有能力完成 uid 維度的一整套業務流程的，應用互相依賴的服務都由本 Zone 提供，服務之間的調用都在本 Zone 內完成的。

但是聰明的你可以會想到一個問題，有的數據不能按照 userid 維度拆分，全局只有一份怎么搞，比如配置中心的數據，那是集中存儲的，全局只有一份配置，配置后也是全局生效。

其實在螞蟻內部，Zone 一共分為三種：

• RZone：上面說的邏輯自包含的，業務系統整體部署的最小單元，能夠按照userId維度拆分服務和庫的都部署在 RZone 內。
• GZone：是 Global Zone，聽這個名字，也知道，GZone 的服務和庫全局只會部署一份，一定是在某個機房的，異地也會部署，但是只是為了災備，不會啟用。
• CZone：比較有意思，為什么會有 CZone，是為了解決 GZone 的弊端而產生的，跨城調用，因為距離原因耗時比較高，如果 GZone 的服務部署在上海，杭州機房的服務需要用到 GZone 部署的服務，只能跨城跨機房調用。

很可能一個服務有很多次 RPC 調用，這樣耗時一定會很爆炸，那怎么弄?在城市與城市之間架起一座數據同步的橋梁，CZone 就是起到了橋梁的作用，負責把 GZone 的數據在城市之前同步，C 是 city 的意思。

也是因為前面我提到的“寫讀時間差現象”，寫入 GZone 的數據，允許一定的延遲，同步 CZone 同步給其他 CZone。

作者：安琪拉

編輯：陶家龍

出處：轉載自公眾號安琪拉的博客(ID：guofuangela)