[[422565]]

一、前言

現在還依稀記得去年雙11在支付寶作戰室，接近0點的時候，所有人都盯著值班室的秒級監控大盤，當交易峰值曲線慢慢爬升，最后變得無比陡峭，值班室的同學都很激動，歡呼聲伴隨著爬升的曲線達到了頂峰，58.3萬筆/秒，也是新的交易峰值記錄，但相比往年動輒翻一倍，漲30%~40%，增長率還是小了很多。

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

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

二、什么是LDC

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

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

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

三、為什么會出現LDC

1. 架構的演進

LDC是為了解決什么問題？還得從架構的演進說起。我們用具體的應用推演一次。

1)單體應用架構

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

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

2)分布式架構

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

水平拆分應該都很熟悉，就是加服務器，每臺服務器都部署實例，垂直拆分就是把服務按域做拆分，比如一個交易系統，有商戶域、商品域、用戶域、訂單域等，拆分成多個微服務，服務解耦，服務可以獨立發布，應用的復雜度會更高。

這個分布式架構解決了服務單點的問題，某臺服務器宕機，服務還是可用的，但是存儲層還是單點的，而且隨著業務增長，擴容加的機器越多，大家發現查詢寫入效率耗時到一定階段反倒是變慢了，分析發現存儲層出現了性能瓶頸。上面圖只花了2臺服務器連接數據庫，真實分布式系統可能幾十百來臺，甚至上千臺，如果都連一臺DB，連接數、鎖爭用等問題, SQL性能變慢可想而知。

3)讀寫分離架構

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

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

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

4）分庫分表分布式架構

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

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

關于分庫分表，很多人都知道有垂直拆分和水平拆分二種（上面說的垂直和水平是系統的拆分，這里指的是存儲的），垂直拆分就是按照業務維度拆分，把同一個業務類型的表放到一個庫，經常會按領域模型的概念拆分，比如訂單庫、用戶庫、商品庫等，水平拆分就是把大數據量的表（庫）切分成很多個小數據量的表（庫），減小庫和表的訪問壓力，可以和系統的水平垂直切分比一下：

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

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

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

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

5）單元化分布式架構

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

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

網關層的流量可能走到任何一臺服務器，比如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可以分攤流量，流量調撥很方便。

2. 螞蟻Zone