「舊城改造」的背後——銀泰新零售阿里雲解決方案（上）
相關免費課程《銀泰新零售上雲解決方案精講》上線中
立足實戰 講透經典案例 助你快速理解新零售
傳統線下商業體上雲的案例
與其說銀泰上雲，倒不如說銀泰「舊城改造」，銀泰線下商業體擁有一座龐大的IDC，這個十年的「老」IDC已經無法支撐現有銀泰如此龐大的業務規模，目前銀泰IDC最大的痛點在於穩定性和效率都無法得到很好的保障，IDC無API，人工操作場景多，這個從運維角度以及整個研發效能上來看，都是非常低效的。而如果在IDC中構建私有云，這個成本也會非常大，主要是構建和維護私有云的成本，綜合上面的情況，公有云是我們最佳的選擇。銀泰新零售業務全部雲化，銀泰IDC老業務逐步上雲，這就是銀泰整體上雲的思路和節奏。
「舊城改造」是一個從-1到0的階段，銀泰IDC有着支撐商場運行的各種系統，以及Oracle數據庫，今天的IDC已經無法滿足我們整體運維和穩定性的要求，選擇上雲是個明智的抉擇。阿里雲目前支撐着銀泰所有新零售核心業務以及IDC上雲的所有應用，我們可以很好的利用雲上的彈性來面對每一場大促。EDAS提供了很好的靈活性，以及豐富的中間件，對於運維也是非常友好，我們無需觸摸任何一臺服務器，整個Provision階段是非常簡單和高效的，結合雲監控自動監控每一個節點。這一切都是上雲的好處。
目前我們已經將銀泰IDC裏的所有應用全部雲化，整個「舊城改造」最難的不是應用上雲，而是Oracle上雲，我們目前正在將Oracle逐步弱化，將整個數據轉移到雲上的RDS，這個過程主要的難點在於銀泰Oracle有着上萬條的存儲過程，而去除存儲過程是去除Oracle的核心。可能其他行業也會存在去Oracle的難題，銀泰零售行業最早開始的時候選擇的是Oracle，這是一個歷史原因，但是今天的業務量Oracle已經無法再繼續擴展（基於成本和穩定性考慮），雲上的RDS天然支持高可用，我們無需太多關心它的底層架構，然後IDC裏的數據庫我們需要考慮他的高可用，才能達到一定的穩定性級別。銀泰各商場將POS機收到的交易寫到該商場的前置機Oracle數據庫，然後利用DTS將全國所有門店的的交易數據彙總到IDC裏的Oracle數據庫，IDC的Oracle數據庫通過內部大量的存儲過程對交易數據進行各種加工（如交易分攤等），數據加工完成後再通過DTS傳輸到阿里雲的RDS。因爲交易數據量龐大，爲了提升雲上數據庫處理能力，我們在RDS的基礎上使用了DRDS，通過分庫分表的方式，將數據計算的壓力進行分散，大幅度地提高了雲上數據庫的計算能力。如果這部分單純在IDC中進行的話，會給我們帶來相當大的難度和一定的維護成本。
新零售場景下混合雲的使用
銀泰上雲後，門店、IDC（現階段Oracle還在持續上雲）、阿里雲組成了一個混合雲網絡，全國門店互聯銀泰IDC，銀泰IDC互聯阿里雲VPC。IDC和阿里雲之間通過DTS傳輸所有交易數據，銀泰全國各門店端有着我們大量的POS、IoT設備等，這些交易數據完全通過阿里雲的DTS來傳輸數據，將交易數據同步至IDC的Oracle（完全上雲後就是RDS了），Oracle會加工這部分數據，然後同樣通過DTS同步到雲端的RDS。因爲我們的Oracle還沒完全去除完，所以這個架構圖裏還會有IDC的身影存在，阿里雲到IDC的專線主要承載DTS數據，以及部分雲上應用使用Oracle的場景，這部分是通過高速通道實現，雲到IDC建立了兩條專線承載這部分流量。而每家門店同樣存在到IDC的專線，這裏的專線也是承載DTS的數據同步。從而，DTS成爲了銀泰整個中樞神經，貫穿線下和線上。
數據傳輸線上線下數據融合的實操
對於整體的數據流向，剛剛提到各門店將POS機收到的交易寫到該門店的前置機Oracle數據庫，然後利用DTS將全國所有門店的的交易數據彙總到IDC裏的Oracle數據庫，IDC的Oracle數據庫通過內部大量的存儲過程對交易數據進行各種加工（如交易分攤等），數據加工完成後再通過DTS傳輸到阿里雲的RDS。因爲交易數據量龐大，爲了提升雲上數據庫處理能力，我們在RDS的基礎上使用了DRDS，通過分庫分表的方式，將數據計算的壓力進行分散，大幅度地提高了雲上數據庫的計算能力。另外，阿里雲RDS及DRDS裏的數據我們利用阿里雲的API，進行數據處理後存放在阿里巴巴IDC的ODPS、自有Mysql、OSS等處，用來做BI處理、生產業務調用等。下面是新商場的總體數據流向圖：
• 門店前置機。商場POS機收到的最初小票數據直接存到門店的前置機數據庫，之所以目前還保留前置機，是因爲如果商場的所有網絡出口中斷，前置機可以作爲離線兜底方案。
• 門店與IDC之間的DTS傳輸。
o 全國所有門店收到的初始交易數據通過DTS彙總到IDC機房裏的Oralce數據庫，然後通過Oracle數據庫中大量的存儲過程對交易數據進行處理，生成我們想要的對小票數據進行分攤後的交易數據。
o IDC將離線交易所需要的配置及商品數據通過DTS反向下發到全國所有的門店。
o 傳輸鏈路。原來全國所有門店與IDC之間的DTS是通過專線進行傳輸的，但是偶爾會出現專線因各種原因中斷的情況（如市政施工等），而且專線一旦出現中斷，運營商修復專線的時間一般都是按小時來計的。爲了解決這個問題，新商場運維團隊基於開源工具在全國所有門店部署了通過公網傳輸Site to Site的v*n，一旦專線中斷，v*n會自動啓動並接管DTS傳輸鏈路，而且對DTS任務是透明的，DTS不用修改任何配置。
• IDC機房。IDC機房部署了多套Oracle，用來做交易小票的處理、財務結算、OA、報表等業務。由於歷史原因，各個庫需要彼此之間調用相互的數據，原來這些業務調用多通過DBLINK來實現。對於報表來說，如果每次計算都通過DBLINK去讀取別的庫的數據，會消耗大量的網絡帶寬，另外也會降低大量的計算能力。爲了解決這個問題，我們利用DTS將各個庫之間的數據進行同步，這樣既能保證數據一致性，又可以在最小化網絡資源消耗的前提下保證原有的計算能力。
• IDC與阿里雲rds之間的DTS傳輸。這裏要給DTS對異構數據庫之間的數據同步點個贊。
o 我們將線下Oracle處理後的數據通過DTS傳輸到阿里雲的RDS，部署在阿里雲的數據直接調用RDS裏的數據。此外，將Oracle裏的數據同步到RDS，也是我們後期去O的一種手段。
o 阿里雲RDS生成的部分生產數據也通過DTS反向傳輸到IDC的Oracle數據庫，用來做財務結算、報表等業務。此外，這個鏈路也可以作爲我們後期去O的回退方法。
• 阿里雲。數據同步到阿里雲的RDS之後，爲了提高阿里雲上的數據計算能力，我們在RDS的基礎上使用了DRDS，通過分庫分表的方式，將數據計算的壓力進行分散。
• 阿里雲數據同步到阿里巴巴IDC。我們利用阿里雲提供的各種API接口，從接口拿到RDS的數據後，經過一些處理，存放到了阿里巴巴IDC的ODPS、自建Mysql、OSS等處，方便阿里巴巴IDC應用架構的調用。
銀泰通過DTS作爲整個數據同步的中樞神經，我們目前擁有一個線上線下數據同步體系，實現線上線下數據融合。但是這裏會產生一個問題，Oracle到Oracle，以及Oracle到RDS（MySQL），我們爲什麼會選擇DTS來做這部分數據傳輸，而不會採用Oracle的通用解決方案？原因在於DTS在監控方面及頁面展示方面做得很好，我們可以通過界面比較直觀地觀察DTS的延遲情況以及每個時間段的數據抽取量，而且可以通過API或控制檯實現非常快速的配置。而Oracle的通用解決方案多停留在命令行層面，在操作及維護的方便性方面遠不如DTS，且無API，這樣給我們的操作帶來了極大的困難。DTS的配置很簡單，下面就是一個同步任務在控制檯中的實操場景：
• 首先進入到DTS產品頁面
• 在管理界面中點擊右上角的「創建遷移任務」來新建一條遷移任務
• 在接下來的頁面中，填寫目標庫和源庫的信息，然後點擊「測試連接」，連通性測試通過後就可以進入下一步了
• 接下來選擇我們要同步的表
• 最後啓動任務
這樣一來，一個任務就這樣的簡單的建立起來了，無需額外的工作量。整個銀泰將近有500多條DTS任務來支持如此龐大的數據傳輸體系。
原文鏈接 本文爲雲棲社區原創內容，未經允許不得轉載。