新零售SaaS业务的中台架构实践
新零售下企业架构演进实践课件
ZUE
GZ00A
CZ00A
ZTG
GZ00B
CZ00B
ZTH
CZ00C
ZUI
CZ00D
GTJ
CZ10A
SU18
CZ10B
ET15
MASTER
LDR: SLAVE1
M[40~59]
CZ-HZ
CZ-SZ
缩写：LDR：同城容灾（Local Disaster Recovery）；RDR：异地容灾（Remote Disaster Recovery）。
用户
全局路由
Logical Data Center
弹性
机房
城市
单元单元Biblioteka 应用DB机房
应用
DB
城市2
单元
云机房
应用
DB
城市N
单元
单元
应用
DB
应用
DB
应用
DB
应用
DB
应用
DB
互联网应用架构演进-LDC弹性部署
Gzone
店铺修改
db
缓存消息
datasla
db
drc同步
msgbroker
缓存消息
刷新策略
data sla
互联网应用架构演进
单体架构（烟囱型架构）
SOA&微服务架构（去IOE）
LDC架构（单元化部署）
服务范围: 交易@互联网交易笔数: <50万/天代码量: 百万级以内技术团队: 百人以内
服务范围: 多资金渠道、多支付工具、多应用场景交易笔数: 千万级/天代码量: 千万级技术人员: 1000人+
服务范围: 支付宝@everywhere业务量: 亿级+代码量: 千万级+技术人员: 异地/开放多地多机房部署，异地容灾。
新零售企业IT应用架构演进
新零售企业IT应用架构演进新零售企业IT应用架构演进目录一、前言 (3)二、零售企业IT应用的缘起：古生代时期 (4)三、中生代时期 (8)四、新生代时期：电商多渠道 (12)五、全渠道零售 (16)六、智慧零售 (21)一、前言上周遇到一位多年前服务过，很久没有交流的零售业CIO。
他告诉我，他把5年前的给他所在企业实施的某大品牌ERP软件给拆掉了，自己开发了一套信息系统，还把自己做的开发平台打包，准备商业化。
他说换掉ERP软件的原因是不能适应业务的快速变化，不过他也承认大型ERP对体系化思考零售管理的作用。
CIO问我两个问题：一、对未来零售企业信息技术应用架构的看法，二、零售业究竟应不应该用ERP？我想有必要用这篇小文谈谈我对零售企业IT应用架构演进的看法。
零售应用的发展道路，就是所谓“新零售”的前世今身。
苏宁，从苏宁电器一路发展为“苏宁云商”、“苏宁易购”，实则经过了完整的传统零售向智慧零售转型的道路，也经历了中国零售企业IT架构演进的各个阶段，实为良好借鉴。
上图是五代演化路径。
需要强调：尽管有些模式在发展阶段上落后了，但是对中国信息基础薄弱的零售企业来说，仍有指导意义，不是每个零售企业都会直接跳到最新的模式之上。
二、零售企业IT应用的缘起：古生代时期80年代末、90年代初兴起的《管理信息系统》课程里对企业信息系统确定了几个基本原理，指导了企业信息系统的形成：企业内的跨组织、跨职能的信息整合物流、信息流、资金流的三流合一操作执行系统、管理信息系统、决策支持系统的三级系统分离太古时期的零售企业应用系统，甚至没有系统分层（ERP和POS 系统的区分）以及多组织实时信息（例如实时的多组织库存信息同步）的概念，90年代中期国内零售企业刚开展信息化时，自行开发的软件或者早期零售软件大多是这种架构，今天富基、长益等著名国内零售软件都是从那个阶段发展过来。
2000年左右，随着所谓C/S、B/S技术架构普及，企业逐渐形成了下图这样的应用框架：这个架构的特点是实现了完整的物流和信息流覆盖、衔接，其抽象的业务模型如下图所示（来自于Levy& Weitz《零售管理》教材，我最推崇的零售管理教科书），包括最主要的两个运作核心，物流中心和门店。
业务中台架构方案
业务中台架构方案随着企业业务规模的不断扩大和业务需求的不断增加，传统的单一业务系统已经无法满足企业的需求。
为了提高业务的效率和灵活性，许多企业开始采用业务中台架构方案。
业务中台架构是一种将企业的业务功能进行整合和重组的架构模式。
它将企业的业务划分为不同的模块，每个模块都具有独立的功能和服务。
这些模块可以根据业务需求进行灵活组合，形成不同的业务场景，从而提供更加个性化和定制化的服务。
在业务中台架构中，核心的组成部分是业务中台。
业务中台是一个独立的业务服务平台，它负责整合和管理企业的各个业务模块。
业务中台提供了一系列的通用功能和服务，如用户管理、权限管理、数据管理等，这些功能和服务可以被不同的业务模块共享和复用，从而减少了系统的重复开发和维护成本。
业务中台架构的核心思想是将业务功能进行解耦和模块化。
通过将业务功能拆分为独立的模块，不仅可以提高系统的可维护性和扩展性，还能够实现业务功能的快速迭代和升级。
当一个业务模块发生变化时，只需要对该模块进行修改和升级，而不会影响其他模块的正常运行。
业务中台架构还可以提供更加灵活和高效的业务流程。
通过将不同的业务模块进行组合，可以实现不同的业务流程，从而满足不同的业务需求。
同时，业务中台架构还可以提供一些通用的业务功能和服务，如报表生成、数据分析等，这些功能和服务可以被不同的业务模块共享和复用，从而提高了业务的效率和质量。
在实施业务中台架构方案时，需要注意以下几点。
首先，需要对企业的业务进行全面的分析和规划，明确业务的核心需求和关键流程。
然后，根据业务需求和流程设计相应的业务模块和业务服务。
在设计业务模块和服务时，需要考虑模块的独立性和可复用性，避免模块间的耦合和依赖。
最后，需要建立相应的技术平台和开发框架，支持业务模块的开发和集成。
业务中台架构方案是一种将企业的业务进行拆分和重组的架构模式，它可以提高业务的效率和灵活性，实现业务功能的快速迭代和升级。
在实施业务中台架构方案时，需要充分考虑企业的业务需求和流程，并建立相应的技术平台和开发框架。
SAAS架构设计模式
SAAS架构设计模式随着云计算的迅速发展和软件即服务（Software as a Service，简称SAAS）的流行，SAAS架构设计模式也成为了云计算中的重要组成部分。
SAAS架构设计模式是指在开发SAAS应用程序时采用的一种构建模式和架构模式，可以提供可靠、可扩展和高性能的SAAS应用程序。
本文将介绍几种常见的SAAS架构设计模式。
1. 多租户模式（Multi-tenancy）多租户模式是指将多个客户的数据和应用程序部署在同一台服务器上，但是各个租户之间的数据和应用程序是相互隔离的。
这种模式可以节省资源和成本，并且可以更好地实现可伸缩性。
在多租户模式下，通常使用数据库分片和隔离技术来隔离不同客户的数据。
2. 微服务架构（Microservices）微服务架构是一种将应用程序分解为小型、独立的服务的架构模式。
每个服务都可以独立开发、部署和伸缩，通过API和消息队列进行通信。
这种模式可以提供灵活性、可伸缩性和可靠性，并且可以更快地进行开发和部署。
3. 事件驱动架构（Event-driven）事件驱动架构是一种通过事件触发和处理来实现应用程序的架构模式。
这种模式可以提供更强大的解耦性和弹性，并且可以更好地处理大规模的并发请求。
在SAAS应用程序中，事件驱动架构可以用于处理用户请求、数据更新和系统通知等不同类型的事件。
4. 缓存架构（Caching）缓存是一种在内存中存储和访问数据的技术，在SAAS应用程序中使用缓存可以提高性能和响应时间。
常见的缓存架构模式包括本地缓存、分布式缓存和反向代理缓存。
使用缓存可以减少对数据库的访问，提高系统的吞吐量和扩展性。
5. 异步处理（Asynchronous Processing）异步处理是一种将耗时的操作和后台任务分离出主线程的处理方式。
在SAAS应用程序中，常见的异步处理方式包括消息队列、任务队列和异步调用等。
这种模式可以提高系统的吞吐量、并发性和可靠性，并且可以更好地处理突发的请求和负载。
SAAS产品设计原则及产品架构特点
SAAS产品设计原则及产品架构特点SAAS（Software as a Service）是一种软件交付模式，用户通过互联网访问和使用软件，而不需要购买或安装软件。
SAAS产品的设计原则和产品架构特点对于构建高质量、可扩展的SAAS产品至关重要。
以下是SAAS产品设计原则及产品架构特点的详细解释。
1.多租户：SAAS产品需要支持多个租户同时使用，每个租户拥有独立的数据库和配置，但共享相同的应用程序、服务器和网络基础设施。
通过多租户架构，可以降低运营成本，提高系统的可扩展性和灵活性。
2.多渠道交付：SAAS产品应该支持多种交付渠道，包括网页应用程序、移动应用程序和API接口。
这样可以满足不同用户的需求，并提供更好的用户体验。
3.可定制性：SAAS产品需要提供一定程度的可定制性，以满足不同用户的需求。
通过提供配置选项、插件架构和API接口，用户可以根据自己的需求对产品进行定制和扩展。
4.安全性：SAAS产品需要采取一系列安全措施，保护用户的数据和隐私。
这包括数据加密、访问控制、审计日志、防火墙和恶意软件检测等。
5.可伸缩性：SAAS产品需要支持快速扩展，以满足不断增长的用户需求。
通过使用云计算和自动化扩展技术，可以实现系统的弹性扩展，以应对流量峰值和用户增长。
1.多层架构：SAAS产品通常采用多层架构，包括用户界面层、应用程序层和数据层。
用户界面层负责与用户交互，应用程序层处理业务逻辑，数据层负责存储和管理数据。
2.微服务架构：SAAS产品可以采用微服务架构，将整个应用程序拆分成多个独立的微服务。
每个微服务负责一个特定的功能，可以独立开发、部署和扩展，提高系统的灵活性和可伸缩性。
3. 服务容器化：SAAS产品可以使用容器化技术，如Docker，将应用程序和依赖项打包成独立的容器。
容器化可以提供更好的部署、管理和迁移能力，简化系统的维护和运维。
4.持续集成和持续交付：SAAS产品需要采用持续集成和持续交付的开发流程，确保快速、高质量的软件发布。
2023-中台技术架构演进解决方案-1
中台技术架构演进解决方案随着数字化时代的来临，越来越多的企业开始寻求数字化转型，而其中最重要的一步就是中心平台(central platform)的构建。
中台技术架构演进解决方案慢慢成为了数字化转型时期最为关键的一环。
下面将分步骤阐述中台技术架构演进解决方案。
第一步：基础架构中台技术架构演进解决方案的第一个步骤是要先明确和构建基础架构。
建立基础架构是为了实现所有中台系统的基础设施和基础环境的一致性，包括硬件设备、操作系统、网络环境、数据库等，这些要求必须满足所有中台系统的需求。
在明确了这些基础设施后，可以构建一个统一的中间件平台，提供共享服务，如负载均衡、缓存、消息队列、日志、监控等等。
第二步：数据共享中台技术架构演进解决方案的第二个步骤是数据共享。
确定数据的共享方式是至关重要的。
在设计中台的数据共享模式时，必须考虑数据的一致性、安全性和性能等方面的问题，同时还需要思考数据主人的责任和数据扩展性的问题。
要通过数据资源的智能化管理，实现数据共享和集成，提高数据的利用效率，同时还要确保数据的安全性和完整性。
第三步：统一规范中台技术架构演进解决方案的第三个步骤是规范化中台技术框架。
规范是保证中台系统互通性和稳定性的关键。
在建设中台系统架构的同时，必须根据业务需求和技术标准来妥善设计和布局架构。
要根据一些重要的规范方案，如RESTful、SOA、微服务架构等来实现中台系统的复用性和互操作性，同时实现标准化的接口、组件、框架等互相合作的能力。
第四步：平台合作中台技术架构演进解决方案的第四个步骤是要加强和信任开发者和运营者之间的交流和合作，以便更好地实现中台系统的稳定、高效和可扩展性。
要建立一个完整的开发社区和运营社区，搭建协作平台，实现真正的开放式合作。
在开发中央平台时，必须采用敏捷开发模式，确保能快速适应业务需求的不断变化。
与此同时，还要保证系统的性能和稳定性等方面。
中台技术架构演进解决方案对于数字化转型而言，是至关重要的一步。
王海龙-孩子王新零售平台中台架构演进之路
2019.12.15
王海龙
•曾任职于易迅、京东。
负责易迅中台的架构部分，以及易迅京东系统对接项目。
•2015年加入孩子王，负责孩子王新零售中台从0
到1的搭建，以及后续的各阶段完善流程。
孩子王中台研发负责人
自我介绍
Shopping mall，大店模式，会员制经营顾客关系的大数据公司专业认证的育儿顾问每年每店近千场的互动活动深度经营单客价值
关于孩子王
信息化
在线化
全渠道
顾客选购
计算可发货仓
选择配送／自提方式
计算运费
路由策略计算
门店
大仓
厂家
城市
中心店
对接外部系统较多
之前采购多套不同系统，要考虑如何兼容、替换、对接外采系统。
可靠性要求较高
尤其线下门店业务，用户就在现场，一旦系统不可用，影响比较大。
数字化程度比较低
会员、商品等基层数据数字化程度较低
业务场景更复杂
不仅有线上业务，还要兼顾线下门店业务，中台系统要考虑如何兼顾支持线上以及线下不同业务场景。
新零售中台的挑战
新零售业务中台场景
全渠道
会员通
商品通
订单通
库存通
下单无边界
提货无边界
售后无边界
线上线下业务一体化，用户体验一致，履约服务一致。
•混沌之初
•统一线上用户
•统一会员数据
•统一会员体系
•万物生长。
业务中台构建实践(25页 PPT)
渠道网关
运营工具
高可用、高性能技术实现
多功能网关
✤可伸缩 ✤一致性分场景
分库分表 中间件
✤分库分表 ✤读写分离 ✤冷热分离 ✤压测隔离
业务库
影子库
统一治理
✤业务驱动 ✤binlog ✤异步+定时 redis
在线全链路压测
压测策略 选择策略
压测处理
流量回放
✤线上录制，线下回放 ✤起于数据，止于数据
4 经验与总结
中台面临问题：持续交付乏力
✤业务发展快，需求多，要求急 ✤逻辑经常改，甚至业务下线
✤系统逻辑盘根错节 ✤稳定性要求高，不敢轻易变更逻辑 ✤人效提升乏力，不能通过加人解决问题
✤中台做着、业务看着 ✤中台排期久，业务不满 ✤业务自己上，中台成为摆设
如何提高持续交付能力？
✤招聘优秀人才
✤沉淀工具，提高复用 ✤提升工具适配能力，更大
有沉淀、但未达到理想效果
出行中台
• 最大业务孵化 • 立足于解决问题 • 最合适原则
出行中台建成、 孵化出部分业务中台
业务中台
• 支持多业务线 • 提升打通能力，赋能业务 • 提升创新能力，规范业务
做对了什么、做错了什么
✤ 业务初创期，快速支持业务最重要，中台不是必须的 ✤基于解决问题，快速迭代，更容易成功 ✤ 最大业务孵化，最合适、最小化原则 ✤ 意识升级、加强沟通，平衡多业务线 ✤ 稳定、抽象
‣数据库 ‣ redis ‣ mq ‣文件等
✤数据比较
复制策略
ES
线下集群
MQ 线上库
热点账户问题
✤余额不敏感 ✤同步写流水、异步记账 ✤增量式计算
✤余额敏感 ✤多账户增加并发度 ✤多账户余额rebalance ✤并发度不足，降级
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
建立连接标准：应⻔交互流程的抽象层次
系统间交互 应⻔容器间交互 组件间交互
逐层细化 逐层细化
建立连接标准：视图间的映射关系
N
业务⻔域
被解决 1:N
1:N
被解决
业务活动/活动分组
N:1
1:N
业务能力
被解决 N:1
应⻔架构
解决
被实现
系统
1:N
1:N
解决
应⻔容器
（数据模型、数据仓库等）
技术架构
（硬件架构、技术选型、部署架构、⻔络拓拓扑等）
建立结构标准：业务架构的抽象层次
企业
业务域
交易域
业务⻔域
收⻔核算
业务活动/活动分组
采购结算
业务能力
结算单查看
零售企业 财务域
结算管理 加盟结算 付款申请
采购域 付款管理 导购结算 代销结算
建立结构标准：应⻔架构的抽象层次
⻔
解决
业务活动/ 业务能力
（某个特定场景、业务能力问题）
法 论
普通产品+普通研发
03
中台实践案例
1 业务架构设计 2 应⻔架构设计 3 中台思考
SaaS业务架构：顶层业务域划分
开放 生态 领域
运营 核心 领域
外部对接
（对接餐道、管易云、ERP等）
应⻔市场
（主要聚焦⻔业化应⻔）
定制开发
（大客定制）
评估市场机会 制定品类计划 规划仓库布局 建立管理机制 管理促销活动 制定销售策略略 管理仓库存 制定交付策略略
制定人力战略略 制定人力计划
管理⻔店库存
管理社交媒体 制定销量量计划 拣货包装运输 管理交付需求
管理⻔试申请
管理现⻔ 更多…
管理营销内容 更多…
设计商品 更多…
管理劳动力 更多…
管理交付计划 更多…
统一认知坐标系：坐标系维度
选择视点
视图类型 ⻔广度
技术架构 数据架构 应⻔架构
业务架构
业务域
业务域
业务⻔域
业务⻔域
深度
业务活动
业务活动
业务能力
业务能力
业务域 业务⻔域 业务活动 业务能力
业务域 业务⻔域 业务活动 业务能力
时间（过去、现在、未来）
统一认知坐标系：架构视图划分
• 通过分离关注点，将复杂问题进⻔
仓库
分公司
加盟商
⻔店
⻔店
仓库
⻔店
店⻓长
收营员 导购员
部⻔架构
采购主管 运营主管
⻔店
部⻔架构
运营 导购员
背景：零售企业的业务流程众多
L1 流程类别
L2 流程组 L3 流程 L4 业务活动 L5 任务
从客户价值出发，体现了公司的业务模 式和价值链特点
一个流程组内部的业务运作逻辑是相 似 的、强相关的。⻔流程组之间的关 系相 当简单。
超市便利利
⻔婴亲⻔
服装
轻餐饮
商品属性的差异
商品运营的差异
会员管理的差异
营销⻔法的差异
销售履履约的差异
库存管理的差异
要货配送的差异
更多差异…
背景：核心挑战点是什么？
1. 复杂度的挑战
• 业务复杂度：问题域本身过于错综复杂。 • 技术复杂度：各种⻔功能性需求增多，数据规模庞大，业务与技术⻔度耦合。
2. 组织上的挑战
总部中台业务
数据中台 路由中台 运营中台 财务中台
• 承上启下 • 数据打通 • 业务单元协同
企业后台业务
采购要货 供应链管理
原材料料管控 生产制造
合同管理
加盟代理
财务总账
更多…
• 生产制造 • 供应链管理 • 财务总账
背景：零售企业组织架构复杂
连锁总部
部⻔架构
采购总监 运营总监 财务总监
⻔店
⻔店
是被重复执⻔、逻辑上相互关联的一组业 务 活动序列，将明确的输⻔转换成明确的 输 出， L3 从⻔实现为客户创造和向客户 交付 价值(产品和服务)的业务目的。
⻔活动将流程分解成落实到⻆色的可 执 ⻔单元，实现人员的专业分工
活动的一部分，将活动进一步分解的 目的在于便于理解和执⻔。
背景：零售企业的业务流程众多
拆解，使得每个局部的复杂度控制 在一个可以接受的范围。
• 通过分离变化点、提炼可复⻔的组
件，达到快速响应业务发展的目 的。
企业的业务架构s
（业务愿景、业务战略略、组织架构、流程架构等）
SaaS业务架构
（涉众分析、业务域划分、业务流程、概念模型、业务能力等）
应⻔架构
（领域建模、系统划分、模块划分等）
数据架构
企业
运营流程
管理与⻔撑服务
流程类别
管理客户体验
商品营销
商品运营
实物交付
服务交付
人⻔资源
财务资源
管理IT技术
流程组 流程
运营⻔自有渠道 管理零售⻔店
客户/市场分析
消费者营销
更多…
更多…
管理商品 管理商品来源
更多…
管理仓库
管理运输/物流
更多…
管理服务资源 交付治理 更多…
招聘/挑选 培养与指导
更多…
客户收银 客户服务
企业
系统
应⻔容器
（限界上下⻔）
组件
交易系统 收⻔核算应⻔ 领域服务组件
代码
Class1
零售企业 财务中台系统
结算应⻔ 仓储组件 Class2
采购系统 付款应⻔ 业务规则组件 Class3
建立连接标准：业务流程抽象层次
业务主流程 (端到端流程)
业务⻔流程
操作流程
系统工作流 （IT可实现）
逐层细化 逐层细化 逐层细化
被实现
(限界上下⻔)
N:1
1:N
被实现
组件
N:1
1:N
被实现
类
N:1
技术架构
实现
物理机器/设备
1:N
实现
应⻔服务器
(容器化/微服务化)
建立连接标准：组织与视图的连接
解决
业务域层次
统
（域间、域内问题）
一
架构师
的
问题拆解 ⻔案指导
架
构
解决
业务⻔域层次
语
（业务⻔域问题）
⻓言
⻔级产品+⻔级研发
和
问题拆解 ⻔案指导
• 业务越来越复杂，组织对业务的理解千差万别，缺乏全局观。 • 软件交付效率低，对市场的响应速度慢。
02
建立架构标准
1 统一认知坐标系 2 建立结构标准 3 建立连接标准
建立架构标准
统一认知坐标系
统一坐标系维度 统一架构视图
建立结构标准
抽象层级标准 结构要素标准
建立连接标准
⻔为视图标准 视图间的映射关系 组织与视图的连接
招聘候选人 更多…
规划管理会计
管理IT业务
收⻔核算 更多…
定义企业架构 更多…
执⻔计划/预算
执⻔成本核算 执⻔成本管理 执⻔收⻔会计
更多…
制定IT战略略 定义企业架构
管理IT组合 管理IT客户
更多…
业务活动
更多…
更多…
更多…
更多…
更多…
更多…
更多…
更多…
背景：零售垂直⻔业需求差异化
生鲜果蔬
蛋糕烘焙
新零售SaaS业务的中台架构实践
目录
01 零售SaaS业务背景 02 建立架构标准 03 中台实践案例
01
零售SaaS业务背景
1 零售SaaS业务背景 2 核心挑战点
零售SaaS业务背景
⻔店收银
前台销售终端
渠道分销
电商平台
O2O平台
商品 进销存
订单 智能导购
客户 会员体系
营销 资产
• 变化快、差异性大。 • 细节性体验、综合性体验。 • 跨平台、多触点。