写点什么

易仓科技×OceanBase:打造跨境行业全生态链的新零售 SaaS

  • 2022-11-08
    浙江
  • 本文字数:4571 字

    阅读完需:约 15 分钟

“中国跨境电商看华南,华南跨境电商看深圳”。2021 年,中国跨境电商市场规模创 14.2 万亿元新高,年度同比仍然保持两位数的高速增长,达 13.6%。近 5 年来,中国跨境电商已经实现了近 10 倍的增长,在我国跨境电商蓬勃发展的同时,深圳也出现了一匹跨境黑马。


深圳市易仓科技有限公司(以下简称“易仓科技”)于 2013 年成立,一直致力于研发高效可控的跨境管理模式,是跨境行业中第一家拥有完整中台系统的服务商。2021 年 2 月 8 日,易仓科技获得 B 轮 4000 万美元融资,刷新跨境电商 SaaS 领域的最高单笔融资记录。韬光养晦近 10 年,易仓科技目前已和国内外众多跨境卖家、海外仓服务商和国际物流等跨境巨头合作,其海外仓系统 WMS 的市场占有率近 70%,处于行业绝对领先地位。


我们有幸邀请到在易仓科技负责数据库架构、数据库优化的 DBA 程涵,结合易仓科技在跨境行业的领先实践,分享跨境行业面临海量数据时应该如何选型、如何运用数据库,才能在企业侧降低每租户成本、提升运维效率,在客户侧提升产品体验、助力客户成功。


认识易仓科技

 

从 2014 年起跨境电商 SaaS 萌芽,开启一轮浪潮增长至今,跨境电商 SaaS 经历了品牌思维的孕育与起步、疫情下行业的发展,以及黑天鹅事件下的理性调整期。而易仓科技,则在 2013 年成立后就抓住了 SaaS 的发展机遇,经过多年内功修练,迅速成为行业领导者。


很多人认为,易仓科技是跨境行业全生态链软件服务供应商,但我更认可易仓科技是跨境行业全生态链的新零售 SaaS 服务商。



为什么说是新零售 SaaS?因为易仓科技是利用互联网+大数据在重构跨境生态,结合了各平台海外的买家、国内的卖家、国内的物流商、承运商以及国内的工厂供应商等关系。目前,易仓科技主要有跨境电商 ERP、国际物流 TMS、海外仓 WMS 和跨境分销 M2B 等产品,服务的租户(即各产品的客户)有上万家,是跨境行业第一家上下游全链路打通的软件服务商。


SaaS 的架构模式:天生多租户

 

易仓科技是跨境电商 SaaS,说到 SaaS 这个概念,其实就离不开一个很重要的名词——租户。相信跨境行业的同行都会遇到每租户成本太高的挑战,传统架构中,有以下几种方案来解决多租户的问题:



从以上的解决方案中每个解决方案各有利弊,在目前的大环境下,易仓科技要做的就是在保证给每个租户提供好的服务的同时,还要尽可能把成本开销,控制在最低的额度。易仓科技根据不同客户的业务情况,适时地选择 1,3 两种方案。


多租户概念不谋而合

 

我们可以看到 SaaS 中的租户其实是与具体的某个客户业务相关联的,而这恰恰与 OceanBase 中的租户概念及其设计理念不谋而合。易仓科技对租户按规模、费用来划分,头部的客户可能会独享资源,腰部的客户可能是混用的,尾部的客户可能是更大资源的混用,还有一部分免费使用或试用客户,我们会以更大的集群资源去混用。



独享资源是指从 Web 层到应用层到数据库全部独享,混用资源可能会分为 Web 层、应用层和数据库的分开独享。说到租户的独享与共享,在数据库架构层面是如何实现的呢?我们不可能做成手动的一个个根据租户去部署,而是根据租户采购易仓科技的产品,然后整个上下游自动开通服务。例如,一个独享的客户,会直接启动一个独享的数据库,如果是一个共享的客户,会有数据库池直接绑定新进来的客户。


易仓科技原来所有的租户,不管是免费、付费还是小客户、大客户,都是采用物理层面的隔离,也就是说数据库级别的隔离,大的租户有可能在实例上实行隔离。这样的话,拥有大量租户的我们,在面对上千甚至更多的服务器、上万甚至更多的数据库、PB 级的存储,以及流量洪峰等时,会遇到很多问题。


现有数据库架构的特点

 

随着跨境电商行业的整体高速发展,易仓科技的业务增长迅猛,客户数量多、体量大,整体的数据量在 PB 级。面对如此大体量的数据与客户,我们应该如何设计数据库架构?


如下图所示,易仓科技的数据库主要使用主从架构,然后通过 ETL 将全链路打通,大数据可汇总至离线计算或实时计算供业务使用。因为是跨境业务,所以我们的服务器在国内外都有部署。



▋ 痛点一:海量的数据与表,运维效率低下,数据库性能遇瓶颈

 

易仓科技已经有近 10 年的历史,数据库实例非常多,数据存储量也非常大。特别地,易仓科技的表非常多,从最早期一个租户 1000 多张表,到现在一个租户可能近 3000 张表。


海量的数据与表,运维起来非常困难,我们需要一个数据库运维平台去做调度任务分发,所有的实例不仅要做监控、报警,还要做基础运维,还要做服务自愈。如果是云数据库的运维还比较方便,但如果是线下自建的,还在不同美国、俄罗斯、欧洲等不同区域,搭监控做智能化运维并非易事。


为尽可能利用提高资源使用率,我们会在一个数据库实例上通过分等级尽量放更多的租户。比如,腰部客户可能是 10 个左右租户放一个实例内,尾部客户可能是 100 个租户左右放一个实例内,免费客户可能是 500 个甚至 1000 个租户放一个实例内。这样的话,如果我们把 1000 个客户放在一个实例内,一个客户 3000 张表,一个实例需要处理的表就是上百万,这对任何一个数据库来说挑战都非常大。


易仓科技现有数据库面临最大的瓶颈就是表数量太多,不管是物理机房还是云上的所有资源,全部都会被我们打破。因为百万的表结构,对应的物理文件可能就是上千个物理文件,所有的物理机可能都受不了。随着客户使用的时间越长,数据库的性能瓶颈也会越来越显现。


我们选型了市面上的绝大部分数据库都很难去实现,哪怕在功能层面实现了,在很多其他层面也无法实现,如备份会直接对操作系统提出挑战。


▋ 痛点二:大数据同步链路复杂,无法保障 SLA

 

易仓科技的数据源来自海外各平台上的卖家,从平台上来的数据会流到国内,而海外买家可能在北美、在欧洲、在东南亚等地,卖家的工厂在国内,发货的物流可能又分为国内和国外。这就会导致我们的 ETL 链路非常多、非常长,其稳定性,可用性,实时性等在运维管理上也变更复杂。


我们要打通各个平台的数据进行汇总,大数据链路同步的实例太多,对于数据库的时效性要求和稳定性要求都非常高。如果你负责管理过上百台 RDS 实例或者 MySQL 数据库,当需要大数据同步时,你需要搭建和维护上百个同步链路,保障 SLA 就成了非常大的挑战。


如果一个月只出现 1 次链路不稳定或者数据丢失的问题,我们的整个服务其实都是不稳定的。那么当我们有上千台实例,这个问题就更体现在我们面前,如何保证大数据服务是稳定的?如何实时同步数据不丢失?是易仓科技必须要解决的。


▋ 痛点三:客户数据的存储成本逐年递增,资源浪费多

 

易仓科技是替客户保管数据的,客户的数据永远是客户的数据。随着客户使用的时间越来越久,三年、五年,哪怕客户每年的单量平均在 1000 万单,三年就是 3000 万单的累积,理论上来说存储是越来越高,对应的收费也要越来越高。但站在客户的角度,自己每年的单量没有太大变化,比如一年就是 1000 万左右单,存储为什么会越来越高?因为我们是 SaaS 模式,按订阅式的单量来付费,不可能让客户去付每年递增的数据存储费用。


但其实对易仓科技来说,随着客户越来越多,客户的数据积累也越来越多,我们的存储成本、服务器成本是每年都在递增的。


此外,还有资源浪费的问题。相信大家如果用过 MySQL 或者用过数据库都知道,特别是云上的数据库,有很多资源不管你有没有使用都已经付费了,也都会存在一定的浪费。例如,购买一个 8C16G 的 1TB 存储的服务器资源,可能 CPU 内存只用了 70%,存储只用了 80%,这样每一台实例有可能都浪费了 20%-30% 的资源。这些浪费的费用,当你只有 5 台、 10 台时可能还不算多,但当你有上千台时,如果资源浪费严重,那损失的费用就会相当明显。


选择原生分布式数据库

 

我们一直在寻求一款可以尽量满足,可以尽量解决我们这些痛点的数据库。前期,我们也使用过一段时间 TiDB,也考察过很多云原生数据库、分布式数据库等,最终选择了 OceanBase 。因为 OceanBase 对跨境电商 SaaS 中租户的理解是最佳贴切的。


跨境行业的小伙伴应该都知道,当促销活动(国内的双“11”、双“12”,国外的圣诞节、黑色星期五)来临时,可能经常会有一些中小客户在一两天内的单量直接拉爆,也就是俗称的“爆单”。DBA 需要随时人工准备处理这种特殊情况,保障流量洪峰时客户依然能稳定运行。


我们需要一款集合资源,可以在租户上资源隔离、共享实例,且可以弹性伸缩的数据库。举个例子,我们有 100 个租户,每个租户的物理资源是可以随意调度的,正常来讲每个租户都有自己的水位线,当有流量在水位线之上,可以迅速扩展,当有流量在水位线之下,也可以迅速缩下来。OceanBase 就提供了这样的能力。


以前,我们 100 个租户放在一起可能需要 10-20 台 RDS,但现在只需要一个 OceanBase。这样的话,以前我们在 10-20 台 RDS 上浪费的资源,每一台可能浪费 20%-30% 的资源,在 OceanBase 上只需浪费 1 次,可能还不到 20%。OceanBase 的大集群多租户,不仅大幅提升了数据库的资源利用率,也显著提升了我们 DBA 的运维效率。


存储节约。OceanBase 极高的压缩比是我们确实实践过的,例如,易仓科技某数据库 1.2TB 数据迁移至 OceanBase 仅需 140G,数据压缩比高达 88%,大幅降低我们的数据存储成本。



**大数据同步。**因为易仓科技在各地都有服务器,以往,我们有 10-30 个同步任务链路,如果中间出现网络异常,需要全部拉回到国内做分析,所以我们对链路的要求非常高,对数据的实时性要求也非常高。现在,我们都在一个 OceanBase 大集群里面,只需要 1 个同步链路,只需要维护好这 1 个同步链路,其上所有租户的同步链路都可以保障稳定性。


**HTAP 能力。**数据量大了之后,客户有可能会跨季度跨年度查询数据,我们有用一些大数据的方案去解决这一块的需求,但是对于像这类简单的、不是特别复杂的报表,我们希望不仅仅靠大数据,也希望用 HTAP 来解决,因为客户有时候需要实时查询。


目前来看,OceanBase 在 HTAP 这块的能力应该算是做得非常好的。不管是 TiDB 还是 PolarDB,或是我们自建的 Click House,目前都需要做额外的数据同步。如果用 Click House,我们需要将数据实时同步到 Click House,如果用 TiDB,也一样要搭建不一样的组件,而且它的数据行列存储在物理层面是分开的。但 OceanBase 不一样,是行列混存的。我们一张表建好之后,数据放进去,所有数据的列存混存就分开了,这样的话我们就不需要做额外的数据处理,这是非常不一样的全新概念。



架构师后记

 何志勇 OceanBase 解决方案架构师


很荣幸能够为易仓科技提供技术支持与服务,也正是借助这个机会了解到跨境 SaaS 的欣欣向荣。而易仓科技就是其中的翘楚,经过多年的深耕,其服务过的客户不计其数,通过不断的产品迭代,最终成为国内跨境行业全生态链全栈服务提供商。


当下,跨境电商全球化,数字化服务,要求越来越高。为能最大程度帮助客户优化成本,提升应用系统的健壮性、稳定性、高效性、安全性、可靠性,以实现提供持续优质的服务,同时确保在行业内的成本优势。易仓科技基于当前现状,不断探索前沿技术,打破传统架构壁垒。从今年上半年开始便对 OceanBase 开展一系列测试调研,最后经过全面的、充分的业务适配与验证后,OceanBase 最终与易仓科技业务系统相融相生。


我相信,在有了 OceanBase 的加入后,易仓科技跨境生态链将会更加的完备,未来,定有更多的业务与客户,和着春风,踩着祥云,踏歌而来!

用户头像

企业级原生分布式数据库 2020-05-06 加入

github:https://github.com/oceanbase/oceanbase 欢迎大家

评论

发布
暂无评论
易仓科技×OceanBase:打造跨境行业全生态链的新零售SaaS_OceanBase 数据库_InfoQ写作社区