[[416659]]

本文轉載自微信公眾號「安琪拉的博客」，作者安琪拉 。轉載本文請聯系安琪拉的博客公眾號。

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

2010年雙11的支付峰值是2萬筆/分鐘，到2017雙11時變為了25.6萬筆/秒，再到去年的58.3萬筆/秒，是09年第一次雙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、GZone、CZone。

RZone: 上面說的邏輯自包含的，業務系統整體部署的最小單元，能夠按照userId維度拆分服務和庫的都部署在RZone內。

GZone：GZone是Global Zone，聽這個名字，也知道，GZone的服務和庫全局只會部署一份，一定是在某個機房的，異地也會部署，但是只是為了災備，不會啟用。

CZone：CZone比較有意思，為什么會有CZone，是為了解決GZone的弊端而產生的，上一篇《從B站崩了看互聯網公司如何做好高可用》架構文章里面講過，跨城調用，因為距離原因耗時比較高，如果GZone的服務部署在上海，杭州機房的服務需要用到GZone部署的服務，只能跨城跨機房調用，很可能一個服務有很多次rpc調用，這樣耗時一定會很爆炸，那怎么弄?在城市與城市之間架起一座數據同步的橋梁，CZone就是起到了橋梁的作用，負責把GZone的數據在城市之前同步，C是city的意思。

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