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

  • A+
所属分类:云计算

文/阿里云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任务来支持如此庞大的数据传输体系。

admin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: