限时!亚马逊云科技云从业者认证考试五折,未过免费补考!更有好礼相送! 了解详情
写点什么

从分销转向零售,TCL 实业是如何考虑中台建设和数据库选型的?

  • 2024-05-29
    北京
  • 本文字数:3872 字

    阅读完需:约 13 分钟

大小:1.94M时长:11:19
从分销转向零售,TCL实业是如何考虑中台建设和数据库选型的?

2019 年,TCL 完成资产重组,集团正式拆分为 TCL 实业和 TCL 科技两部分。其中,TCL 实业聚焦智能终端产品及服务,涉及电视、空调、白家电等多个产品,在业务模式上,逐渐从分销走向零售,和消费者的距离越走越近。


少了渠道商这道“缓冲”,直接面对千人千面的终端消费者提供产品和服务,意味着过去粗放式、千篇一律的模式也就难以为继。TCL 实业内部亟需一个精细化、精准化的业务平台做支撑,数字化转型迫在眉睫。


但是,作为一个覆盖多个行业的综合性企业,TCL 实业几个事业部过去在 IT 建设过程中一直各自为战,步调和标准都不一致。用 TCL 实业企业架构部架构师蔡玖发的话说,“过去其内部的客户管理就连‘一客一码’都没有实现”。无法追踪客户偏好,消费者画像不清晰,更不用提精准营销。这就像是一块“短板”,导致其很多业务变革无法进一步落地。


于是,统一平台的建设成了 TCL 实业数字化转型的“第一战”。

第一步,先建一个营销中台


2020 年底,TCL 实业着手开始数字化转型,第一阶段设定的目标,是用 3 年时间进行业务变革和平台化建设。围绕该目标,TCL 实业结合自身特点制定了“6+1”策略——其中,“6”对应着研发、营销服、生产制造、供应链、大数据、共享 6 大核心业务;“1”指的是一个统一的平台。


在此之前,TCL 实业内部存在大量 IT 重复建设的情况,彼此架构独立、技术陈旧,不但带来极大的成本浪费,而且大大增加了系统集成的难度和数据治理的难度。问题进一步反馈到业务环节,具体又表现为:库存信息无法自动同步,需要人工调拨;商品信息无法自动同步,依赖手工处理;渠道不统一,线下线下定价策略不统一;各事业部财务核算成本高、流程不规范等等。


因此,统一平台和共享能力的建设刻不容缓。而在 6 大业务中台中,TCL 实业选择的第一个中台项目是新方舟营销业务中台(简称“新方舟”)。蔡玖发表示,由于业务变革的急迫性,为了能够更高效地支撑中国营销本部全品类订单的受理与履约,适应业务模式从分销向零售的转型。


2022 年 8 月,新方舟中台正式上线,投入应用一年多以来,给 TCL 实业的营销业务带来了一系列变化:


第一,全品类客户统一,可以从不同产品不同渠道、市场分离、一客多码到统一市场统一客户码;


第二,全品类商流统一,从客户只能单品类对接需求到客户多品类需求一单受理交付;


第三,经营管理上移,定价权由战区上移大区,按战区、大区、总部各层价格权限进行审批和报价;


第四,业财一体化,业务发生立即触达财务,提升经营效果披露的实时性以及业务的标准化;


第五,通过一套平台能力,帮助各事业部快速响应市场与业务需求,加速业务创新;


第六,整个平台具备弹性伸缩的处理能力,帮助业务侧更好地应对 618/ 双 11 的流量峰值冲击。


从业务角度而言,所有营销相关的流程都在同一个平台进行,工作效率大大提升。并且,所有数据报表都能通过同一入口和统一视图进行统筹管控。在蔡玖发看来,这是业务数字化变革的基础,“因为只有这样,业务侧才有干净统一的数据去支撑业务策略决策。”


从技术角度而言,经过统一的 IT 建设不但避免了成本浪费,并且 IT 交付能力也得到极大提升。据蔡玖发介绍,过去内部采用传统瀑布型的交付模式,单个需求响应周期长,交付周期甚至达到以月为单位,平均 2 周内就可以完成,效率显著提高。


“基于此,IT 和业务双方还有了统一的沟通‘语言’。对于业务来说,可以充分了解 IT 的能力建设,对于 IT 来说,也可以清楚知道具体的业务规划。这为双方在日常协作过程中提供了一个平台和基础。”蔡玖发表示。

所有技术和产品的选择不能成为项目瓶颈


“新方舟”项目具体由 TCL 中国营销本部、IFS 财经变革、流程与数字化转型中心联合主导建设,投入 200 多人,项目成员分别从公司商品部、架构部、研发部等不同部门抽调而来。从 2021 年初招投标,到 2021 年 9 月供应商进场,再到 2022 年 8 月正式上线,项目实施周期大约持续了 10 个月时间,经历了三个阶段的建设周期。


据蔡玖发介绍,团队第一阶段的主要工作是把白电、泛智屏等业务的线下部分接入新方舟,由于空调业务与白电等产品特性存在差异,同时前期需求调研和分析不够透彻,因此放在了第二阶段接入。而进入第三阶段,各条业务和产品线的线上部分,包括来自淘宝、天猫等各个电商平台以及自有渠道的线上订单全部都已接入新方舟中台。


虽然线上业务自带数字化属性,但是 TCL 实业选择优先把线下业务与新方舟中台对接,蔡玖发对此解释了背后的原因:“第一,是因为线下业务本身具备一些公共能力,在完成线下部分的同时,线上的大量工作也同步进行了;第二,在公司内部,线下业务的紧迫性比线上高,优先级更靠前;第三,线上业务对系统要求高,需要对性能、高可用、稳定性等方面有了充分论证和实践之后再往前推进。”


可见,不盲目求快一直是 TCL 实业的项目建设原则。另一个例子是,为了确保系统具备足够的稳定性,项目在上线时间上做了一定妥协。据了解,项目原计划在同年 5 月上线,但是由于涉及业务复杂,关联方较多,并且公司内部对项目要求比较高,因此项目组坚持以先紧后松的节奏推进实施,这在一定程度上拉长了系统打磨和测试时间。


蔡玖发表示,在这个过程中,TCL 实业内部花了大量时间对各个技术进行了充分讨论,才形成最终方案——采用微服务架构 + 分布式数据库 +BFS 搜索算法。首先,在最底层是统一的基础架构和开发平台,第二层是基于 K8s 的容器管理平台,第三层是中间件和基于 Spring 的技术开发平台、数据库。


在整个架构设计和技术选型的过程中,TCL 实业的核心的诉求如下:第一,优先选择国产技术方案;第二,所有工具、组件、中间件都做到自主可控;第三,产品在行业内有较丰富的使用案例。


“除此之外,还有一点很重要,就是所有技术产品的选择不能成为项目瓶颈。”蔡玖发强调。


以数据库为例,之前各事业部营销系统种类较多,既有自研也有外采的,使用的数据库种类也非常多,包括 Oracle、MSSQL、MySQL、MongoDB 等在内约 10 多套数据库,数据量累计约 10TB 左右。随着数据量增长、高并发场景增多,不可避免会面临性能问题。所以在新方舟数据库选型时,TCL 实业毫无意外地选择了具有 HTAP 能力的原生分布式架构


“当数据量达到一定规模,如果我们还采用传统的集中式数据库,那就不得不考虑分表分库的问题,这对代码是有侵入性的,扩容也不方便。”在蔡玖发看来,分布式代表了先进性,它的架构更灵活,动态扩容能力能够从容应对峰值冲击,并且具有更好的拓展性,不会随着表数据量增长导致效率下降,整个架构体系更简单、管理运维成本也更低。

完美的技术方案是不存在的


数据库品牌方面,TCL 最终在 GaussDB、OceanBase 和 TiDB 中选择了 TiDB。“总的来说,我们认为 TiDB 在成熟度、稳定性、可拓展性,以及行业实践等方面相较于另外两个产品是有一定优势的。并且,从开源社区排名来看,TiDB 也长期处于前列,这会便于我们根据自身需要更灵活地在商业版和社区版之间切换。”蔡玖发强调。


当然,没有任何一个技术方案最开始就是绝对完美的,蔡玖发坦言,TiDB 在 TCL 的上线过程中也经历了一段磨合期。


比如,虽然 TiDB 和 MySQL 之间可以兼容,但是由于技术架构的差异,内部开发人员对新架构需要一定的适应时间,在这个过程中不免出现一些点状问题和遗漏;


比如,整个中台服务(包括核心和非核心)都在同一套 TiDB 集群上运行。虽然已经做到核心和非核心的资源隔离,但是灵活度方面 TiDB 仍有可优化的空间。


再比如,当单个 SQL 性能出现问题时可能会对整个集群资源产生消耗,如果没有及时发现和处理就会导致整体性能大幅下降,蔡玖发表示,对此,TiDB 的自我保护机制也仍然有待提升,可以在问题暴露时加快响应。


针对这些挑战,蔡玖发认为,一方面需要一定时间的打磨,另一方面这也是一个不断进行策略权衡的过程。“拿自我保护机制来说,矛盾点就在于一旦审核过度,对并发量就会产生影响,所以就要求技术团队进一步对控制点实现精细化管理。”


“完美的技术方案是不存在的。”蔡玖发向 InfoQ 记者表示,“在解决方案制定过程中,企业要分清主次要矛盾。短期来看要充分考虑自身的痛点,当下的技术方案能否解决这些问题;长期来看,还要加入更多变量,比如技术先进性、行业领先性、业务规模增长速度等等,未来的技术路线能否兼顾各方面的需求。”


正是基于这些考虑,大到整个数字化转型,小到新方舟中台的建设和数据库迁移,TCL 实业采用的都是渐进式的策略,分阶段逐步上线,一边迁移旧业务一边开发新业务,而不是一切推翻从零开始。


目前,在 TiDB 集群上,支撑了 TCL 实业订单中心、库存中心、商品中心、结算中心、关联交易中心、客户中心、采购中心、配置中心等将近 20 个业务中心。而整个新方舟具体应用架构涉及 40 个业务触点、13 个业务场景、8 个业务中心、680 个功能,应用架构图如下:


蔡玖发表示,截止 2023 年底,新方舟技术架构搭建已基本完成。“仅从数据库角度来看,这套集群将在至少 3 年内很好地支撑 TCL 实业的业务发展。”而从 2024 年开始,平台建设重心将转向用户体验、数据消费,以用户为中心打造 IT 系统,提升数据消费能力,赋能数字化转型。

活动推荐

6 月 14 日-15 日,ArchSummit 全球架构师峰会将在深圳举办。大会策划了 17+ 专题,将从底层基础到顶层应用深度探索大模型时代软件架构的最佳设计。顺丰集团 CTO 耿艳坤、阿里巴巴丁宇(叔同)、Thoughtworks CTO Scott Shaw、百度飞桨总架构师于佃海等国内外 100+ 顶尖专家齐聚。点击链接可查看更多详情:https://archsummit.infoq.cn/2024/shenzhen/schedule


会议 9 折购票倒计时 3 天,如您感兴趣,可以联系票务经理 17310043226,锁定最新优惠。


2024-05-29 18:018014

评论 2 条评论

发布
用户头像
不错的数字化转型经验分享
2024-06-06 14:01 · 江苏
回复
用户头像
厉害了

统一平台的建设成了 TCL 实业数字化转型的“第一战”。

2024-06-05 13:55 · 上海
回复
没有更多了
发现更多内容

正则表达式 与 XPath 语法领域细解,初学阶段的你,该怎么学?

梦想橡皮擦

11月日更

SpringSecurity+JWT认证流程解析

Java 程序员 后端

SpringSecurity安全控件使用指南

Java 程序员 后端

SpringSecurity详细介绍RememberMe功能

Java 程序员 后端

SpringMVC--文件上传

Java 程序员 后端

SpringMVC之Interceptor拦截器之登录拦截器(1)

Java 程序员 后端

面试官:你说说软件测试WHX模型(图解)

程序员阿沐

程序员 软件测试 自动化测试 测试开发

如何在 CentOS 中下载包含所有依赖项的 RPM 包

DisonTangor

centos

Spring之AOP适配器模式

Java 程序员 后端

Java的jvm与gc概述

小鲍侃java

11月日更

东吴证券张之浩:从理论到落地的 DevOps 体系建设

BoCloud博云

DevOps 云原生 证券

软件测试的策略详解(按开发阶段划分)

程序员阿沐

编程 程序员 软件测试 自动化测试 测试工程师

SpringSecurity入门(一)

Java 程序员 后端

Apache Flink CDC 批流融合技术原理分析

Apache Flink

大数据 flink

springcloud(一)注册中心eureka

Java 程序员 后端

Spring新版本抛弃JVM,可独立部署,网友:要自立门户?

Java 程序员 后端

SpringMVC之Interceptor拦截器之登录拦截器

Java 程序员 后端

未来怎么样的测试工程师最值钱?

程序员阿沐

腾讯 软件测试 自动化测试 测试开发

Spring中的AOP——在Advice方法中获取目标方法的参数

Java 程序员 后端

Spring注解缓存设计原理及实战

Java 程序员 后端

spring的事务隔离级别

Java 程序员 后端

springcloud(三)网关zuul

Java 程序员 后端

SpringData【Spring整合HibernateJPA】(1)

Java 程序员 后端

SpringData【Spring整合HibernateJPA】

Java 程序员 后端

SpringMVC入门第二部分

Java 程序员 后端

软件的生命周期(软件工程各阶段的工作)

程序员阿沐

程序员 软件测试 生命周期 测试开发 测试工程师

SpringCloud—— eureka+feign实现声明式服务治理

Java 程序员 后端

MySQL Operator 02 | 脚手架选型 & 工程创建

RadonDB

MySQL 数据库 Kubernetes RadonDB

springcloud(二)配置中心config

Java 程序员 后端

面试题:软件测试V模型以及软件生命周期

程序员阿沐

编程 程序员 软件测试 自动化测试 教程

Spring框架(五)SpringMVC高级

Java 程序员 后端

从分销转向零售,TCL实业是如何考虑中台建设和数据库选型的?_架构_高玉娴_InfoQ精选文章