“旧城改造”的背后——银泰新零售阿里云解决方案（上）

摘要： 立足实战 讲透经典案例 助你快速理解新零售

文/阿里云MVP 银泰技术高级经理 贾爽

相关免费课程《银泰新零售上云解决方案精讲》上线中
立足实战 讲透经典案例 助你快速理解新零售

第一节学习地址
第二节学习地址

传统线下商业体上云的案例

与其说银泰上云，倒不如说银泰“旧城改造”，银泰线下商业体拥有一座庞大的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的VPN，一旦专线中断，VPN会自动启动并接管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任务来支持如此庞大的数据传输体系。

“旧城改造”的背后——银泰新零售阿里云解决方案（下）

 

---

本文作者： MVP时间 辰悠

原文链接

本文为云栖社区原创内容，未经允许不得转载。