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

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