面向生态开放的新一代企业级应用架构

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 面向生态开放的新一代 企业级应用架构 微盟研发中心 / 喻立久
2.
3. 目录 • 微盟SaaS业务介绍 • 零售客户业务诉求 • 面临的挑战 • 架构方案 • 效果体现
4. 微盟SaaS业务介绍 微盟成立于2013年,致力于商家数字 化转型,服务超过10万+电商零售客 户 典型客户:联想、巴拉巴拉、江南布 衣、特步、星巴克、热风等等
5. 典型客户数字化升级诉求 效率 营销产品 交易产品 渠道管理 数据BI 运营效率、获客效率、营销效率等 财务产品 协同 商家 经营 多应用之间可以融合与协同,共同服务业务 货物管理 线下导购 成本 技术投入成本可控
6. 客户数字化升级实施策略 自研 优势 外采 优势 劣势 实现完全个性化 成本巨大 业务安全性高 数据完全集中 VS 劣势 成本可控 个性化受限制 人才缺口 专业度高 数据割裂 闭关锁国 生态繁荣 供应商选择困难
7. 零售商户数字化升级面临的挑战 1 产品集成困难 2 定制成本高 商户应用众多,各应用之间能力和数 对于集团性连锁客户,往往存在着 据互相割裂,存在着协议不统一、数 个性化定制需求,传统软件定制化 据模型不一致等问题,集成打通较为 的开放成本,部署成本,维护成本 困难 都较高;制约着商户快速适应市场 变化 3 灵活度差 4 数据不统一 零售客户的经营活动涉及较多线下 多个产品的人-货-场数据不统一, 场景,对产品的灵活性要求较高; 散落在各个应用里,统计和分析较 比如客户的组织架构需要根据经营 为困难 场所的归属关系灵活配置
8. 微盟SaaS产品的总体架构思路 一个中心 四项原则 产品功能:灵活定义 产品自身的灵活性决定着商户适应市场变化的敏捷性,是否 连接能力:降本提效 对于大型客户,应用之间的可连接性与连接效率决定着数字化升级 业务能力:高度复用 多产品、多业务线的场景下,底层能力需要具备强的可复用性与扩 领域模型:灵活扩展 通过针对底层数据模型的泛化设计,解耦数据模型与现实世界实体 行业生态 兼容并包 支持产品功能的灵活定义,决定做着商家经营决策的执行力 的成败,也决定着生态合作伙伴共同服务商家的效率 展性,从而支持灵活多变的业务诉求 的绑定关系,从而尽可能做到任意扩展
9. 面向生态开放的SaaS产品架构实践 生态应用 标准产品 运营组件 装修组件 应用市场 商家自研 菜单层级 首页 ERP OMS 页面主题 商品详情 开放能力 接口 集成平台 CRM 互动营销 消息 连接器 控制器 转换器 基本信息 业务中台 规范标准 名称 通用模型 API 数据分析 版本 权限校验 AI工具 。。。 流程编排 通用能力 业务编排 个性化扩展 。。。 SPI MSG 前端融合 框架模型
10. 关键设计 领域模型可扩展 业务能力可编排 应用高效集成 产品功能组件化
11. 关键设计之模型扩展 典型场景 背景:微盟体系有多条业务线,比 如零售、到店、酒旅、医药等等, 标准的 “商品”或“订单”等领域模型 无法满足特定业务线的个性化需求 诉求:希望中台底层模型支持业务 个性化属性定义,比如商品领域模 型增加“医药-渠道信息” 传统方案 新方案  数据库表增加扩展字段  业务中台领域模型面向全行业进行高度抽象设计  定义Json类型字段  定义扩展独立存储,与主模型隔离  可视化管理,动态存储,无需提前定义数据模型 缺点:  表列膨胀,影响查询效率  字段内容之间互相影响 MySQL ES  核心服务稳定性失控 Mongo 业务扩展管理控制平台 (业务线自助管理)
12. 面向生态的领域模型泛化设计案例 典型场景 背景:零售商家的经营组织架构体 系较为复杂,有集团型,多品牌 型,加盟型等等 诉求:零售SaaS产品能否支持客户 自定义组织架构,从而快速适应客 户的经营变化 解决方案 设计方法论:组织架构体系从“变量的枚举”到“变量的自解释”,从而支持灵活扩展 枚举 名称:品牌A 自解释 类型:区域 集团 Node 品牌 品牌 Node 区域 门店1 门店2 权限:XXX Node Node Node Node 约束:。。
13. 关键设计之业务能力编排 典型场景 背景:微盟商城支持商品参加各种 促销活动,比如满减满折,秒杀, 拼团,砍价等等,同一个商品在不 同场景下展示的促销活动类型可自 由定义  在商品查询促销活动服 务里进行逻辑控制,类 似if-else的结构 缺点: 诉求:希望有一套通用的流程,各 业务线共享,并且可自由定义个性 化逻辑 新方案 传统方案  代码可维护性差  灵活性较低     拆分核心业务逻辑,由更小粒度的业务单元组合而成 业务单元可以被自由组合 支持对业务单元的可视化编排 业务单元可定义更细粒度的个性化扩展
14. 能力编排平台运行逻辑 产品 获取 使用 业务组件 消息路由 能力路由 扩展点路由 (mapping) 业务组件 流程编排 元数据 配 置 域 业务身份 下发 核 心 运 行 域 流程单元 扩展实现-1 SPI 能力路由 路由策略 扩展实现-2 业务中台 扩 展 运 行 域
15. 关键设计之高效集成 典型场景 背景:商户A同时使用了微盟的 【微商城解决方案】、某公司的 【CRM】产品和【抖音小店】 诉求:微盟商品同步到抖音小店, 且抖音订单回流至微盟商城,同时 增加CRM的积分  进行系统之间API对接  可视化流程编排,一站式测试和发布上线  硬编码实施  0代码或者低代码完成产品之间的能力互通  测试发布上线,后期维护  流程可复用,提升应用之间的连接效率 缺点:  研发成本高  集成效率低 CRM 新方案 传统方案  重复工作多 同步商品至 抖店 (https) 微盟商城 异常处理 (grooby) 参数校验 (groovy) 获取微盟商 品 (dubbo) 获取权益开通 状态 (dubbo) 库存校验 (dubbo) 上传商品 (https)
16. 集成平台架构设计 连接器 微盟商城连接器 协议层 HTTP 微盟CRM连接器 抖音小店连接器 Dubbo SQL Transformer Connector Choice FlowReference ObjectStore MQ 流程引擎 工作流日志 网关 Parallel 视频号连接器 。。。 Kafka TryCatch JOB ForEach While 控制层 基础层 Worker CICD 灰度 监控
17. 关键设计之功能组件化 典型场景 背景:电商零售的促销活动众多, 比如限时折扣、满减满折、优惠套 装等等,无法穷举,并且市面上不 断出现新的促销玩法,帮助商家拉 动销售 传统方案  进行全新的产品逻辑设计  促销活动按“准入”-“条件”-“优惠”等维度进行抽象  每种活动一套独立的微服务  每个维度拆分为更细粒度的原子组件  原子组件支持可视化页面拼装 缺点:  研发成本高 诉求:怎么通过统一的模型来承载 千变万化的玩法,以不变应万变 新方案  维护成本高  重复工作多
18. 支持生态开放的其他关键设计 前端集成 数据集成 开放平台  页面级和组件级的灵活融合  一站式数据开发工具  完善的开发套件  统一SDK,支持生态标准化接入  可视化的数据分析与制表能力  多维度开放能力  丰富的组件库,快速构建端应用  自定义数据集成  支持生态应用快速接入
19. 真实场景举例 典型场景 背景:一家专注购物商场等线下 SaaS产品研发的ISV ,最近构建发 一种全新的停车应用,该应用需要 与微盟的产品体系无缝整合 诉求:该停车应用借力微盟的底层 能力快速实施,并且与微盟产品进 行深度集成 实施方案 1  确定产品定位  注册产品基本信息 4  产品上线  入驻微盟云应用市场  商户试用与购买 2  基于中台底座构建上层业务  流程编排+SPI扩展支持个性化 3  集成平台进行产品连接  通过前端SPI扩展,实现与微 盟在交互上的无缝集成
20. 效果体现 生态创新效率 效率提升 >50% 1. 复用微盟业务中台的底层模型以 生态创新能力 产品能力更加开放 生态创新成本 低代码应用范围持续扩大 API开放数量提升 43% 流程编排数量 3000+ SPI开放数量提升 116% 可复用的业务组件 30+ MSG开放数量提升 84% 业务组件扩展点: 400+ 及业务逻辑,大幅降低重复性工作 2. 通过集成平台,快速与商场主产 品进行能力打通 3. 前端与微盟产品进行无缝整合
21. 未来展望 1 行业标准 2 PaaS能力 3 国际化 行业缺乏通用的底层模型标 将SaaS能力PaaS化,期望更 微盟的SaaS产品已经在做国际 准、应用之间交互的标准流 全面地赋能生态 化逻辑,面临的主要挑战有: 支持异构云环境 程协议等 除了SaaS产品的提供更多开放 支持多环境部署 比如售后流程,产品之间有 能力,微盟还提供B-PaaS, 底层模型支持多语言/时区/货 较大差异,导致业务流集成 iPaaS,D-PaaS等等更底层的 币等 相对比较低效 能力
22. 微盟研发中心微信公众号,对微盟感兴趣的伙伴可以关注一下
23.

Home - Wiki
Copyright © 2011-2024 iteam. Current version is 2.139.0. UTC+08:00, 2024-12-22 19:47
浙ICP备14020137号-1 $Map of visitor$