原作者：趙鈺瑩
目前，國內某知名運動品牌在全球經營着 12 家鞋服運動品牌，在全國有近萬家線下門店，耐克、阿迪達斯、彪馬、匡威等品牌門店絕大部分都是其代理經營，註冊會員達 6000 多萬，這些業務由旗下科技公司雲盛海宏全面支撐。過去十年間，雲海零售系統是支撐全渠道、全品類運動鞋服的零售服務平臺，支撐了 8000+ 線下門店的零售。
這樣一家零售領域的老牌企業是如何一步步從 MySQL 轉向原生分佈式數據庫的？整體的架構變遷思路是怎樣的？實踐過後又是如何從成本視角評價 Oracle 和國產分佈式數據庫的......近期，InfoQ 有幸採訪到了雲盛海宏首席架構師洪亮，就上述問題逐一進行了探討。
雲盛海宏首席架構師洪亮
背景介紹
在介紹雲盛海宏的數據庫架構設計之前，我們先了解下其整體的業務背景。雲盛海宏的核心業務是零售系統，包括庫存、終端零售以及用於集團內部的財務輔助系統三大模塊。
自 2013 年開始，雲盛海宏就開始搭建整個數據庫架構，中間因爲業務的不斷髮展經歷了多輪迭代。2016 年之前，雲盛海宏基本還處於傳統零售時代，內部各大區自建設信息化系統，維護自己的數據庫架構，每天向總部上傳業務數據，數據庫採用集中式單庫，這種方式的優點是架構簡單，缺點則隨着業務發展越來越明顯，比如沒有辦法及時查看地區彙總數據，也無法跨大區查看全國的實時庫存等。
爲了解決這些問題，雲盛海宏在 2016 年上線了全新的架構——雲海零售系統，開啓了數字化零售時代的架構演進之路。
發展至今，雲海零售系統主要經歷了三個階段的演進。
階段一：應用微服務化，實現數據共享，初步精細化運營，支撐數字化業務發展
在這一階段，雲盛海宏使用的是微服務+ MySQL 分庫分表的方式。立項之初，團隊調研時考慮到數據垂直切分的模式短時間內較穩定，MySQL 集羣的開發難易程度對團隊來說又比較好掌握，所以選定了 MySQL 。
隨着業務的飛速發展，很多問題超出了團隊的原始預期，MySQL 集羣對於複雜報表分析支持不足，團隊嘗試引入 Oracle 分擔這部分需求，再通過 Otter 進行數據的實時同步，保障兩邊的數據完整。對於 TOB 業務來說，內部報表非常關鍵，且對數據精度要求極高，冷熱數據變化頻繁，Oracle 的引入很好解決了實時報表方面的問題。
此後，雲海零售系統支撐了業務高速發展的五年，實現了很多小目標，比如實現了全國各地區、各大區的海量數據的存儲，實現了數據實時共享，也達到了業務可視化的目標。但是隨着業務的擴展和需求難度的增加，慢慢地出現了一些新的挑戰。首先，整個架構基於 MyCAT 做分庫分表，在日常維護中，如果有新的業務，比如要增加表或者調整表，維護層面會增加人力成本，需要人工調整配置，然後再調用配置，需要花費很多精力。
其次，當時的 Otter 同步渠道已經有 110 +，使用起來也沒有那麼理想。比如源端加表，目標端沒有加表，或者是僅僅是字段的調整也可能導致一些同步的中斷，這需要大量人力維護。最主要的是 Oracle 也遇到了一些瓶頸，例如海量數據無法擴展、聚合庫分析時效差等問題。
階段二：解決數據爆發式增長導致聚合庫分析時效性差
2020 年之前，Oracle 的單點性能已經無法橫向擴展，團隊開始積極尋求替代方案。此時，團隊開始接觸到 TiDB ，並於當時 InfoQ 舉辦的 ArchSummit 大會上聽到了時任 PingCAP 聯合創始人兼 CTO 黃東旭的詳細講解，後又經過詳細的對比測試，主要集中在大數據量的查詢以及複雜 SQL 的查詢性能兩方面，發現 TiDB 可以解決 Oracle 存在的問題並且非常便捷。在內部小規模試用取得顯著效果之後，雲盛海宏最終決定快速推進 TiDB 集羣的部署工作。
決定將 TiDB 部署到生產時的壓測方案（利用了 Percona 公司的開源工具 Percona-playback 實施的壓測）
“2020 年，疫情爆發，這對我們的業務帶來了很大沖擊，我們開始發力做線上業務，技術側最直接的壓力來自於庫存管理模塊的變化。原本，從接到需要對接淘寶、京東、唯品會、抖音等平臺的需求到最終落地需要三個月甚至半年的時間，但因爲我們前期已經切換到了 TiDB ，技術棧層面做好了充足的準備，最終只用了兩週時間就完成了單平臺庫存管理模塊的調整”，洪亮如是說道。
2020 年引入 TiDB 之後的架構圖
就內部工程師而言，TiDB 的部署推進得也非常順利。首先，雲盛海宏的主要業務都是在 MySQL 的基礎上構建的，TiDB 完全兼容 MySQL 協議，從 MySQL 遷移到 TiDB 是比較順利的。其次，TiDB 的日常運維、擴容、縮容非常方便，原來 DBA 按月或者季度爲週期需要在凌晨一次性完成十幾個實例的數據遷移，維護工作量巨大，而且數據遷移風險極高，一旦出現問題後果非常嚴重，引入 TiDB 之後基本不需要做遷移動作，更別提 MySQL 日常巡檢、歸檔和備份這些動作耗費的時間。最後，MySQL 分庫分錶帶來的侷限性無法讓團隊快速應對變化，公司組織架構的每一次調整都會對業務帶來一定衝擊，團隊需要快速消化這種衝擊，TiDB 的引入讓整個技術棧更具彈性。
階段三：向全面部署分佈式數據庫邁進，初步探索架構雲化
目前，雲盛海宏內部已經完成了 MySQL 到 TiDB 的遷移，從最初的 4.0 版本到目前線上的 5.4.2 版本，每一次升級 TiDB 都會帶來比較實用的特性和功能。接下來，雲盛海宏會嘗試從 Oracle 到 TiDB 的遷移，逐漸收攏數據庫集羣，更進一步降低運維負擔。在雲盛海宏內部，Oracle 不會承擔太多核心業務和寫操作，遷移基本面向 AP 類的數據和業務，所以這部分相對來說比較容易，團隊重心會放在前端數據遷移，包括數據準確性校驗。
採訪中，洪亮表示目前內部的 TiDB 集羣的機器規模已經達到 100 臺，已經部署了兩個 TiDB 集羣，分別承擔前端和後臺的業務負載，計劃在 2024 年前完成第三個 TiDB 集羣的部署，承擔前文所述的 AP 類業務，也就是目前 Oracle 承擔的財務報表分析負載。屆時，雲盛海宏的所有業務將全部運行至 TiDB 集羣，Oracle 集羣將逐漸停用。
除此之外，整體架構將會逐漸雲化。當前，雲盛海宏部分應用做了私有云化，未來會嘗試將一些環境公有云化，比如開發、測試、培訓、生產等。
數據庫設計核心問題探討
在零售行業，雲盛海宏算得上是對技術投入較大的公司之一，而且結合其業務範圍和體量，技術架構的搭建是存在一定難度的，數據庫選型和架構演進需要考慮因素很多。在這個過程中，團隊也摸索出了一些經驗。
零售業有沒有可能完全捨棄 Oracle ？
在零售領域，有一定歷史的企業內部早期肯定部署着 Oracle 數據庫，尤其是對精度要求極高的財務數據，那時可替代的國產數據庫並不多。如今，國產數據庫越來越成熟，可供選擇的空間也越來越大，很多企業都開始嘗試遷移至其他數據庫。
從雲盛海宏的經驗來看，零售領域未來完全有機會捨棄 Oracle ，即便是要求極高的財務報表數據的處理也可以由國產數據庫來負責。
選型上，企業需要提前根據業務特點做好壓測，遷移之前也需要做好相關預案，雲盛海宏從 MySQL 到 TiDB ，從 Oracle 到 TiDB 都做好了充分的備案。
從成本視角來看，分佈式數據庫值嗎？
現在談到成本，基本涵蓋軟件授權費用、軟件服務費用、硬件採購費用以及日常維護費用等衆多維度，企業內部情況不同也存在差異。
從雲盛海宏的經驗來看，TiDB 相比 Oracle 在軟件授權費用上肯定是具備明顯優勢的；在軟件服務費用方面，TiDB 本身的生態和社區建設（包括文檔）相對比較完善，但不排除一些國產數據庫因爲成熟度不足而尚無法投入人力建設成熟的服務生態，這一點需要根據選型情況具體判斷；在硬件採購費用方面，雲盛海宏使用前後差異不大；在日常維護方面，TiDB 的門檻低、易維護節約了大量人力成本。
如果與管理 MySQL 集羣相比，數據備份、硬件故障處理、主從節點管理等相對都比較麻煩，但 TiDB 基本可以做到輕量級維護，後期雲化之後可能會更進一步降低運維成本。
要不要全面雲化？
如前文言，雲盛海宏其實未來會逐步雲化，其團隊內部對此也有很多考慮。
採訪中，洪亮表示從整個集羣而不是單個數據庫的角度出發，雲化在機房管理、網絡安全、高可用、容災等層面會比本地部署更有優勢。如今，TiDB 和阿里雲也有合作，雲化是比較容易進行的，尤其是針對原有技術棧基於 MySQL 的企業。
智能化運維值不值得初期就考慮？
最近兩年，很多數據庫都在積極整合 AI 能力，以期讓部署、運行、運維等全過程更具智能化。對雲盛海宏而言，企業內部對落地 AI 的訴求相對而言沒那麼迫切。
“智能化運維或者說引入 AI 能力取決於底層的基礎建設是否到位，如果存算分離或者是運維能力沒有提升，AI 就像是空中樓閣。只有底層基礎打好了，智能化運維才能發揮出更大作用。比如，MySQL 的一些指標監控肯定沒有 TiDB 完善，沒有這些指標，AI 監控就無從談起了。”