自從我接手公司的時候，公司的數(shù)據(jù)庫基本就是單點，為了省錢，一律低配，那個時候的數(shù)據(jù)庫和現(xiàn)在用的一樣，對于業(yè)務庫，我們還是用的阿里云的RDS（MYSQL）。
我記得當時線上就一個core庫，core庫就是存放一切業(yè)務數(shù)據(jù)，做了讀寫分離。
當時為什么這么做呢，簡單來說就是方便快捷，因為業(yè)務簡單，最多的一張表的數(shù)據(jù)當時也就100多萬吧就是當時的報名單的一個子表，那時候還做了個事兒，報名單有個查詢，就算加了索引速度也提不起來，當時這個表的寬度巨寬，各種字符集都在這張表里；查詢一次基本要在1S以上，當時的解決方案就是把這個表的引擎改成myisam了，查詢立馬降低在120ms的樣子。
后來，隨著業(yè)務的發(fā)展，業(yè)務拆的越來越細，流量也越來越大，core庫已經(jīng)不堪重負了，于是，開始拆分數(shù)據(jù)庫，同時把服務化也做了進一步的拆分，工程也獨立出來了（之前所有的項目都在一個project下，打個包這個酸爽），這樣也做到了各個數(shù)據(jù)庫的隔離，但帶來的問題是，很多級聯(lián)查詢查不到了，運營的很多數(shù)據(jù)統(tǒng)計都做不了，怎么辦嘞？
我們把core庫的核心業(yè)務獨立出來，分離出商戶、用戶、兼職、報名單，并且把dubbo的服務化體系一個個和這幾個庫對齊，做到一個工程對應一個DB，而core庫則是歷史老坑遺留地，沒有人敢碰，一碰就沾包。
但因為成本的問題，2017年的時候，我們還是一分分錢的省下來過日子的，非常節(jié)儉；除了core庫之外，其他的RDS都是單點的，并非高可用，也不支持讀寫分離；可能這時候有些人說，你這么做太危險了，這玩意數(shù)據(jù)庫跪了的話，這段時間業(yè)務就受很大影響了。實際上這事兒還真發(fā)生了，我記得當時我們有一個庫，整整掛了有5分鐘，5分鐘后才恢復的；但5分鐘對于當年的公司來說，影響還沒有到承受不了的程度，因此，單點數(shù)據(jù)庫在很長時間內(nèi)，都是支撐業(yè)務的主要戰(zhàn)力。
隨著公司的發(fā)展，產(chǎn)品運營越來越多，運營后臺的需求與數(shù)據(jù)需求與日俱增，于是我們?yōu)樗麄儗ｉT重構了一個運營后臺（簡稱YY后臺）；那數(shù)據(jù)需求是怎么解決的呢，很簡單，讓運營們直接去生產(chǎn)庫上去查，當然用戶敏感信息我們還是保密的；但如果讓運營去線上去查，如果胡亂執(zhí)行sql，那不是要對線上庫產(chǎn)生較大的影響了嗎？于是我們有了以下的改進
我們通過dts將每個庫合成一個大庫third庫，他自身也是個rds，負責和所有的業(yè)務庫做線上同步，這個庫本身就相當于我們的一個線上的備庫，對他進行查詢操作，不會對線上造成影響。
隨著公司的進一步發(fā)展，數(shù)據(jù)量越來越大，并且也出現(xiàn)了埋點的數(shù)據(jù)，因此，我們建立了另一條埋點鏈路，這套鏈路最終會進入離線計算maxcompute；另外，業(yè)務數(shù)據(jù)也要進入maxcompute里。
上圖的業(yè)務我們大概跑了有一整年，在這一整年了，出現(xiàn)了一個問題，也就是出現(xiàn)在業(yè)務庫向third庫通過DTS這個環(huán)節(jié)的問題；當我們業(yè)務庫出現(xiàn)了表級的操作，比如alter語句的時候，會觸發(fā)大量的binlog產(chǎn)生，dts收到大量binlog后，會向third進行同步；而third庫因為要同時接收所有端的數(shù)據(jù)，他的寫入能力遭遇瓶頸，因此會阻塞在DTS上，導致third庫嚴重延時，maxcompute也出現(xiàn)嚴重超時。我曾經(jīng)為了解決這個問題，去尋找高性能寫的數(shù)據(jù)庫的時候，會發(fā)現(xiàn)市面上大多數(shù)據(jù)庫都不滿足我這個場景及，高性能的rmdb，又要支持海量數(shù)據(jù)；目前我所知道的基本就是oceanbase和tidb這兩者。tidb不考慮，坑太多，oceanbase目前在公測，不支持內(nèi)網(wǎng)，也不考慮；那后來采取的策略是，讓運營遷移到maxcompute上去查詢，雖然時效性不好，但也是一個長期的方案，總不能讓運營一直去在線上數(shù)據(jù)庫是隨便玩耍呀，于是這個方案就變成這樣了，此時mysql的各個實例已經(jīng)進化到了高可用，支持讀寫分離。
我們通過maxcompute來直接從只讀庫拉取數(shù)據(jù)，主要是依賴于maxcompute的高性能寫，并且只讀庫在同步binlog下，比dts的性能要高出一個數(shù)量級，具體為什么可以去看一下dts的實現(xiàn)；另外，這個只讀庫一定不要做讀寫分離，因為在maxcompute去拉取數(shù)據(jù)庫的時候，這個時候mysql的iops可能是很高的，如果這個時候有線上的請求過來，是會造成請求阻塞延時的，因此，只讀庫一定不能作為讀寫分離的實例。
到這里為止，和我們目前的架構就基本一樣了，可能這里面缺少ES、Redis等一些存儲，這些主要是為業(yè)務服務的，我這里主要是側(cè)重講關于數(shù)據(jù)的持久化方案的演進。
——————————華麗的分割線————————————
那么我開始講一下我們后面要做的事情，隨著數(shù)據(jù)量越來越大，公司對數(shù)據(jù)的實時性越來越高，maxcompute的離線處理，已經(jīng)不能滿足我們的需求；線上很多業(yè)務要做流式處理，實時推薦；比如，一個用戶瀏覽了某些兼職，但沒有點擊報名，這說明這個用戶對這類兼職是不感興趣的，同時我們要把用戶行為實時發(fā)送到流式處理里，給用戶推送其他的類目。我們采用行業(yè)標桿FLINK做流式處理，用redis保存一些數(shù)據(jù)統(tǒng)計結(jié)果集；我們也會有一些數(shù)據(jù)UI界面的產(chǎn)品，通過訪問redis來拿到實施的結(jié)果，比如，每天的日活、收入、使用時長等。
網(wǎng)關的加入，我們會把記錄訪問的所有鏈路日志，通過網(wǎng)關做鑒權、限流、輸出日志、黑白名單校驗、灰度等功能，那在這張圖中，網(wǎng)關主要是把訪問的所有日志，上傳到KAFKA中，再轉(zhuǎn)交到FLINK中，通過FLINK來做用戶的數(shù)據(jù)做清洗，再將結(jié)構化數(shù)據(jù)導入到安全中心。而安全中心要做的就是所有的風控判斷，最后把數(shù)據(jù)沉淀到maxcompute里做機器學習，不斷優(yōu)化風控規(guī)則。
