天猫五化战略下的电商架构

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 天猫五化战略下的电商架构 何崚(大少) @ 天猫 helin8@gmail.com 2014.12
2. Agenda 天猫五化战略 - 架构挑战 服务能力接入 服务能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
3. 自我介绍 • 我 – 2006 年初加入阿里 , • 负责阿里巴巴中文站的架构 – 2012 年初加入天猫,先后负责天猫的架构师团队,交易链路,无线团队 • 构建 B2C 基础平台(交易,物流,库存体系),及天猫客户端的建设 • 垂直化行业的建设 • 天猫架构团队 • 性能,容量,稳定性问题基本解决,消费者链路日趋完善 • 目前重心:互联网营销平台向服务平台转变的架构探索 • 天猫架构团队是阿里集团冲在业务线最前沿的架构师团队,我们使命是如何改善我 们的架构设计,架构驱动业务发展,为业务注入创新活力。
4. 天猫 – 平台型电商 大量的商家在天猫平台上做生意 • 数量大,品类多 • 品牌商 / 托盘商 / 代运营商,旗舰店 / 专营店,能力参差不齐 天猫提供电商基础的水电煤设施 • 提供搜索 / 店铺等流量承接入口,交易通道 • 除了少数几个品类,天猫不强管控供应链 平台,商家, TP (……)构成生态体系 • 包括物流商,服务商,软件提供商,摄影师等服务提供者增强了商家的能力 • 既竞争,又协同
5. 平台型电商生态体系的繁荣三要素 多样性 • 品类丰富度: • 消费者对不同品类的核心诉求是不同的, • 对于一些新兴品类而言,远远不是卖个商品再找个快递送出去这么简单的。以家装为例,家装。搬楼,安装,设计,装修。 • 按行业分配资源,充分挖掘并满足用户对这些行业的核心述求。这就是所谓的行业垂直化。 • 品牌丰富度 • 不同消费层次的用户对不同品牌的偏好是不一样的,这代表着他的生活态度,这个平台的品牌分层是否合理,品牌丰富度是否 能满足不同用户对于平台 • 例,北上广深几个城市的时尚青年线下经常逛的商场里的品牌 , 天猫定位于时尚电商平台,必须接入。这就是品牌时尚化。 • 消费层次覆盖度 • 不同层次的消费者对商品的诉求是不同的,有些对价格敏感,有些对品牌敏感,有些对对服务敏感,需要建立一套商业智能体 系,对不同层次的用户提供不同的服务。 • 通过建立的这套服务标准体系去影响商家、 消费者、乃至整个商业流通体系。 竞争性 • 平台要充分鼓励竞争,让有能力服务好消费者的商家赚到更多钱,淘汰服务差的商家。 • 但是首先,这个平台有没有让商家把自己的核心竞争力在线上发挥出来,对于品牌商而言,其实它在线下是有很强的能力的,尤 其是在线下会员体系,供货能力,服务能力,能够在平台上表达出来,形成用户的品牌心智,赢得竞争优势,而不仅仅是在拼营 销能力,低水平竞争 互补性 • 平台,商家,服务商,供应链的各个角色能否协同起来,互相补位,给消费者提供这个行业所能提供的最好的服务体验,
6. 平台型电商生态体系的繁荣三要素 多样性 品类丰富度 行业垂直化 品牌丰富度 品牌时尚化 消费层次覆 盖度 服务分层化 行业垂直化 行业的供应链多 角色协同 品牌时尚化 互补性 竞争性 品牌线下竞争力 接入平台
7. 天猫五化战略下的架构挑战 行业垂直化 • 如何以互联网的方式来快速,低成本的建立一套体现该行业特征心智的服务体系? 品牌时尚化 • 如何快速接入大牌? • 如何让品牌商的线下竞争力在平台得以体系 服务分层化 • 如何不同层次消费者对服务的差异化诉求 无线个性化 • 在流量结构无线化的趋势下,如何支持各种行业特色服务在多个终端快速同步落地?
8. 行业垂直化 – 架构思路( 1 ) 定义行业基础服务 • 挖掘反应行业心智的消费者核心诉求,定义成行业基础服务模型。 • 例如家装(送货上门安装) 建设服务能力 • 建设服务能力接入平台:接入平台所谓不具备的第三方服务能力,形成服务互联网 • 例:家电维修 • 建设服务能力整合平台:整合平台,商家,服务商的服务能力,打包成行业基础服务 • 例: 送货上门安装(由干线物流 + 支线物流 + 落地配 + 安装 打包而成) 行业服务的表达 • 建设服务表达平台,体系化的把行业服务在导购交易链路表达出来,建立消费者对服务的认 知 • 例:搜索可按服务维度筛选,详情展示服务承诺
9. 行业垂直化 – 架构思路( 2 ) 行业服务的交易 • 建设服务交易平台,服务绑定商品,体系化的改造现有交易系统,使得消费者可以在购买商 品的时候同时订购各种相关行业服务 • 例:家具,送装一体,物流点自提 行业服务的履行 • 建设服务履行平台,下发各种服务订单给服务提供者,同时收集服务提供者的反馈给消费者 ,平台监控服务履行情况,处理异常 行业服务的商业应用 • 电商平台的行业化运营思路:活动 + 频道 • 活动: XXX 包送货上门安装活动 , XXX 首发, XXX 预售 , • 专场频道: XXX 生鲜频道 • 活动 = 一组行业服务集合 • XX 首发:预售 + 分期贷款 + 送货上门安装 + 闪电赔付 +…… • 建设服务运营平台,提供给运营和商家,使用服务来定义商业应用
10. 服务分层化和无线个性化 – 架构思路 服务分层化 • 问题:不同层次的用户对服务的诉求不同 • 例如:重价格轻服务(便宜但是发货慢),重服务轻价格(贵但是发货快) • 建设服务数据平台 • 利用大数据分析用户的消费层次,在购买决策路径,优先推荐符合用户消费层次的 服务,降低用户的购物选择成本, 无线个性化 • 问题:流量结构无线化的大趋势下,谁也不敢轻视无线端的流量拓展,甚至要采用 无线优先的战略。 • 无线端的屏幕小,适合结合用户大数据、 LBS 、应用场景下的千人千面。 • 各个终端的研发基础技术不同,且业务上线受到发版周期的影响, • 对于开发者而言,最大的挑战是,如何让业务能够快速同步到各个终端 • 需要建设多终端快速开发解决方案,来加快业务在不同终端上线的速度
11. 架构改造流程 - 商品平台向服务平台的转变 服务定 义 能力接 入 能力整 合 服务表 达 服务推 荐 服务交 易 服务履 行 服务运 营 • 行业服务模 • 服务接入平 • 服务整合平 • 服务表达平 • 服务推荐平 • 服务交易平 • 服务履行平 • 服务运营平 型 台 台 台 台 台 台 台 • 行业心智 • 接入各方 • 服务能力 • 导购链路 • 大数据推 • 交易流程 • 服务履行 • 选择服务 的用户核 服务能力 打包成行 表达 荐服务 挂接服务 的调度和 定义商业 心诉求的 业解决方 监控 应用 • 跨终端的 定义 案 快速表达
12. Agenda 天猫五化战略 - 架构挑战 能力接入 能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
13. 能力的接入 平台在行业垂直化后的能力缺失 • 对于很多行业有它特色的行业服务,而这些服务能力是平台所不具备的,需要引入第三方的服务提供者 • 例如家电的维修服务能力 三种服务能力提供者 • 品牌商具备线下能力 • 第三方服务商服务能力 • 平台自建能力 • 例如:菜鸟物流 问题 • 消费者端互联网化,但是在服务供应链领域,并未真正的互联网化,商家端的服务能力体系是一个个竖井,独立运作,彼此不 通,供应链领域各能力分布碎片化,未互联网化,独立运作,互不协同 • 小商家,没有服务能力,又找不到服务商,给消费者提供不了好的服务体验 • 品牌商,有服务能力,又不能把自己的线下竞争力反映到平台上来,只能和普通商家做低水平拼价格竞争 • 各个能力提供者缺少能力协同的通道,无法相互协同起来去给消费者提供 1+1>2 的服务 解决方案 • 构建服务接入平台,以互联网的思维整合服务 • 服务商能够披露服务提供者所提供的服务 • 服务提供者提供的服务,能够在系统层面,被平台调用到。
14. 服务能力披露 - 服务市场 家装能力市场 安装商 1 物流商 1 物流商 2 XX 能力市场 家居安装服务 1 家具维修服务 1 XXXX 服务 1 …… 物流能力大市场 干线物流服务 1 支线物流服务 1 干线物流服务 2 XXX 服务 1 服务模板 线路 1 ,报价 1 ,时效 1 线路 2 ,报价 2 ,时效 2 …… XX 能力市场 …… 行 业 能 力 市 场 基 础 能 力 市 场
15. 服务能力接入系统 商家 / 服务商系统 能 力 接 入 平 台 QOS 安全 商品发布 API 仓储发布 API 通信 订单队列 Open API 天猫系统 监控 对账 物流订单 队列 流控 服务状态变 更通知队列 管控 Message Service 其他形 式……
16. 审计和对账 问题 • 多角色服务履行链路过于复杂,不稳定容易造成资损 • 服务履行流程,横跨平台,商家,服务商系统,公网调用,经常不稳定出错, 导致账务对不齐,造成资损,且很难及时发现和定位。 • 例:商家把钱退给用户,但通知平台失败,平台又扣了商家保证金再赔一遍。 原则 • 相信统计学,不要完全相信数据库里的值。 • 基于单据明细的实时审计对账。 案例 • 为避免库存因系统原因超卖导致缺货赔付,实时审计对账公式: • 数据库中剩余库存数 = 零点库存数 + 商家补库存数 – 已付款订单商品数 • 实时监控订单支付状态,统计付款订单数,实时监控商家补库存行为,实时计算 等式右侧的结果,如果和左侧值不一致,通知商家并下架商品,订正数据库,避 免缺货赔付
17. Agenda 天猫五化战略 - 架构挑战 能力接入 能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
18. 服务整合 - 服务能力整合成行业解决方案 干线 行业解决方案 1 - 送货上门安装 支线 ( optio 落地配 + + + n) 计算规则 最短时效 安装 最低总价 商品 1 服务订单 1 服务引擎 计算 绑定 服务订单 2 拆单 服务订单 3 服务大市场 干线物流服务 1 支线物流服务 1 落地配服务 1 干线物流服务 2 支线物流服务 2 安装服务 1 服务模板 线路 1 ,报价 1 ,时效 1 线路 2 ,报价 2 ,时效 2 行业化的主要方向是制定符合这个行业心智的一体化服务解 决方案 一体化解决方案由多个基础服务打包组成
19. 服务全生命周期设计 服务表达 服务履行 • 导购链路 UI 扩展 点设计 • 服务履行链路的 扩展点机制 服务购买 • 交易流程扩展点 设计
20. Agenda 天猫五化战略 - 架构挑战 能力接入 能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
21. 服务表达的扩展点 • • 服务表达 – 实施路径:导购链路各个系统 – 目标:给消费者建立服务感知 – 特点: UI 的扩展点 UI 扩展点的示例 - 家装的送货上门安装 搜索(服务标) 商品详情(服务说明) …… …… • • UI 扩展点固定化 – 服务表达要固化到消费者的体验心智中去,因此服务表达入口位置必须要固定,不能变来变去 架构挑战 – 如何定义导购链路不同系统的服务表达扩展点? – 如何把服务表达的内容快速挂接到各扩展点上?
22. 服务表达的 UI 扩展点 搜索(服务标) - 展示层两级 DSL 设计 商品详情(服务说明) …… …… • 导购链路表达,涉及到导购链路各个系统的扩展 • 第一级:扩展地图( UI EXTP MAP ) – 服务表达地图,该服务在所有相关系统的需 要表达的位置说明 – PD 维护 • 第二级:扩展点模板( UI EXTP TEMPLATE ) – 服务表达模板,是每个扩展点的 HTML5 内 容展示 – 设计师维护 服务表达地图( JSON ) XXX 系统 扩展点位置 ( URL+DIV-ID ) 展示模板名称 XXX 系统 扩展点位置 ( URL+DIV-ID ) 展示模板名称 服务表达模板( HTML ) 内容 HTML5 CDN 和二级 静态缓存中
23. 服务表达的 UI 扩展点 • • - 服务参数 扩展点数据( UI EXTP DATA ) – 是服务的参数列表,描述了某个服务的具体描 述 – 是服务商发布到服务市场的服务描述 扩展点数据的生命周期 – 服务商发布服务描述时,生成 JSON 文件,静 态放在 CDN 和二级静态缓存上 – 服务商变更服务时重新生成或生成 服务详细参数 商家 …… 价格 …… 时效性 …… 赔付标准 …… …… ……
24. UI 扩展点的内容生成 - 服务内容渲染 JS • 扩展点地图变更时, • 生成渲染 JS 文件,放到 CDN • 渲染 JS 嵌入到系统指定模板 • 渲染 JS : • DISPLAY ( DIV-ID, UI EXTP TEMPLATE , UI EXTP DATA URL ) • 根据扩展点地图指定的该页面的扩展点位置的 DIV-ID ,展示模板名称,和传入的绑定该商品 的服务参数数据完成渲染 服务表达 模板 服务数据 渲染 JS 生成服务表 达 HTML5 渲染 JS 扩展点位置 (所在的 DIV ) 来自扩展地图 扩展点模板名 来自扩展地图 扩展点参数 该商品绑定的服务的 参数 插入扩展点所在系统 指定页面的指定 DIV
25. 服务表达的管理 工具化的服务表达管理 角色 监听事件 系统变更 产品经理 修改 服务表达链路 重新生成扩展地图( UI EXTP MAP ),然后遍历扩展地图,推送 渲染 JS 文件到 CDN 和二级静态缓存 服务商 修改服务内容 重新生成服务数据 JSON 文件,推送 渲染 JS 文件到 CDN 和二级静态缓存 设计师 重新设计服务展现的模板 重新生成扩展内容文件( UI EXTP CONTENT ) , 推送至 CDN 和二级 静态缓存
26. Agenda 天猫五化战略 - 架构挑战 能力接入 能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
27. 消费者购买流程支持服务可售 购物车(服务选择) 下单(服务说明) 目标: • 交易流程支持服务可售 • 涉及到交易主流程的扩展点设计 解决方案: • 交易流程扩展点机制,在下单流程挂接服务和其他扩展 • 订单模型按业务分层,公共基础模型 + 业务扩展模型 • 交易流程按水平业务领域划分成多个业务节点( Provider ) • 基于 Provider ,使用 DSL 编排 SPI • 基于 NS 隔离不同垂直业务 • 不同开发团队在各自的 bundle 中模块化开发
28. 交易的两级流程化改造 - 第一级 交易主流程( MainProcess ) • 1. 第一级流程:交易主流程 – 将下单流程按照不可再分的业务领域划分成多个业务领域子流程( provider ) 商品会员 信息验证 Provider 补全商品会 员信息的订 单 物流计算 Provider 补全物流服务 信息的订单 价格计算 Provider 计算价格后 的订单 服务计算 Provider 一级流程, mainProcess ,千锤百炼,非常稳定,不会变(如果要变,天猫业 务方向发生重大变化),除非由交易团队维护 二级流程, Provider ,内部经常变,交由各自水平领域的团队维护,如物流 ……
29. 交易的两级流程化改造 - 第二级 业务领域子流程( Provider ) • 1. 第二级流程:业务领域子流程( Provider ), – 每个 Provder ,按照垂直业务,又挂接了多个垂直业务扩展点,称为 SPI 物流计算 Provider XXX SPI • XXX 自提 SPI XXX 包邮 SPI 2. Provider 的 DSL 设计,要反映 SPI 之间的关系 – 组合:统一品类下 – 互斥:不同品类间 没有物流 SPI ……SPI
30. 垂直业务之间的隔离 - NameSpace • 垂直业务的相互影响 – 不同的垂直开发团队开发不同的垂直业务,家装 SPI 调用了电器 SPI ,电器的 SPI 出 bug 了, 家装也不能下单了。 – Namespace 机制隔离不同垂直业务相互影响 物流 Provider 流程节点,挂接 SPI 例:家装 Namespace Ns1 电器 Ns2 汽车 Ns3 家装 Ns… Namespace 代表 1 个业务,不同 NS 互补可 见 行业间复制: Provider 的 DSL 设计,要支持友元机制,来支持 行业间的能 力复制,例:送装一体
31. 模型分层  所有交易模型公共部分  如商品 ID ,卖家 ID ,价格等 公共部分 公共模型 (SDO)    垂直业务相关扩展  OTC 医药(药监码……) 扩展模型 (Ext)     只读 所有 bundle 可 见 订单基础模型 预售扩展 只读 懒加载 同一名空间可见 加为友元的名空间可见 电子票扩展 通过 ExtensionSpi 设置扩展 …… ……
32. 部署 – 使用 Bundle 来隔离不同大开发团队 • 行业隔离 – 问题:各团队,发布,打包相互影响 – 使用 Bundle 来隔离不同的大团队开发 Bundle 各开发独立团队维护 Bundle- 开发团队 1 Bundle- 开发团队 2 Plugins container
33. 行业化服务在交易链路的表达 - 行业化后开发模式的转变 行业化后 行业化前 交易团队开发交易基础需求,行业开发团队开发行业化定制需求 交易团队开发所有需求 大家电开发团队 交易系统 …… 交易需求 交易团队 中心化开发模式 瓶颈 …… 医药 OTC 医药馆开发团队 行业化定制需求( SPI ) 淘宝交易需求 天猫交易需求 大家电预售 物流团队 物流 …… 服务 服务团队 领域子流程( Provider ) 交易主流程 性能稳定性 交易团队 交易主流程( Main process ) 去中心化开发模式 底层技术和上层业务之间,水平业务和垂直业务之 间,发挥专长,高效协同,快速业务试错
34. Agenda 天猫五化战略 - 架构挑战 能力接入 能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
35. 服务履行的语义化表达 - 单据流 • 单据流 – 服务履行的全生命周期,基本分为 商品订单履行,物流订单 履行 ,服务订单履行 商品订单履行 物流订单履行 服务订单履行 • 交易订单 • 出库单 • 物流订单 • 物流发货单 • 服务订单 • 服务工单 – 因此,服务履行可以用一组相互关联的单据流来表达 • 单据表达的好处: – 语义化强,商家熟悉 – 每个行业都有行业化的订单履行流程,容易沉淀行业的规范
36. 中心化的服务履行管理 – 订单中心 单据流的拆单 • 交易订单 拆成 商品订单,物流订单,服务订单,分布交由商家,物流商,服务商履行 单据流的调度 • 单据是跨系统执行 • 在天猫的交易系统,结算系统,商家的 ERP/TMS 系统,物流商的 TMS 系统,服务商的 ERP 系统中完成,彼 此之间需要状态互通,这种复杂架构需要有中心化的调度 • 单据的扭转是有时序性的, • 例如:许多服务订单要在物流订单完成后履行,家装,送货上门,安装,也需要有中心化的调度 单据流的监控 • 服务商的系统不稳定,订单异常会导致流程挂起,导致消费者投诉,增加客服压力 • 订单异常会造成资金损失 • 需要监控异常,并及时通知处理 结论: • 建设中心化的单据履行管理 - 订单中心
37. Agenda 天猫五化战略 - 架构挑战 能力接入 能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
38. 商业应用层 - 背景 需求 • 电商平台的行业化业务的运营思路: • 短期运营行为,活动: XXX 家装包送货上门安装活动 , XXX 手机首发, XXX 汽车预售 , • 日常运营行为,专场频道:生鲜吃遍全球频道 问题 • • • • 业务方和开发在不同的视图中考虑商业应用,导致系统设计周期长,系统扩展性沉淀差 PD ,业务视角 – 产品视角 架构师,产品视角 – 技术实施视角 例如:家装节活动 • PD 考虑,交易要不要搞个预售,服务要不要全场包送货上门安装,服务要不要 以旧换新…… • 开发考虑,搜索系统修改,交易系统修改,物流系统修改, TOP API 开放,商家系统修改…… 解决思路 • 每个运营活动是代表这个行业消费者心智的服务组合 • 开发者是从系统构建, PD 是从服务能力构建, PD 如果能够提出需要构建的能力列表,开发就能通 过系统构建的方式实现功能列表 • 产品和技术在统一的产品开发视图(业务服务二维表),以规则化,菜单化的方式,编排商业应用
39. 商业应用的语义化表达 – 业务 – 服务 二维视图,菜单化编排应用 服务能力 商业应用 XXX 家装活动 XXX 手机首发 XXX 预售 Yes Yes Yes 分期购贷款 XXXXXX Yes Yes XXXXX Yes XXXX Yes XXXXX Yes XXXX …… Yes 开发通过构建服务的系统实现来实现能力,业务方通过菜单化的服务编排来实现商业应用 统一产品和开发的视角,并且容易工具化
40. 商业应用 – 行业化业务运营中心 业务方 服务列表 规则 引擎 行业业务 运营中心 菜单化编辑 读取 业务 - 服 务二维表 分解 服务 列表 服务 1 服务 2 服务 n 服务 表达 服务 可售 服务 履行 服务表达平台 (服务表达地 图) 交易流程行业定制 ( NS + SPI ) 服务履行平台 (订单中心)
41. 多终端下的业务开发视图 - 基于 业务 – 服务 – 终端 三维表 iPad 端 终端 商业应用 Android 端 XXX 家装活动 IOS 端 XXX 手机活动 XXX 汽车首发活动 PC 端 服务能力 分期购贷款 预售 XX 包邮 次日达 送货上门安装 七天无理由退货
42. 多终端开发下的架构挑战 研发工程量暴涨 • 由于 IOS , Android,H5 的开发体系差异很大,同一业务在各个终端下要开发几遍,导致研发成本上升很大 研发周期受客户端发版周期影响 • 客户端有自己的发版节奏,需求在客户端上线受到发版周期的影响,成为瓶颈 H5 不用发版,但体验差于 Native • 采用 H5 技术可以快速上线 新业务,但是性能和体验要远远差于 Native 实现,且很多传感器和互动特征无 法使用 如何兼顾研发效率和性能? • 多终端最大的差异是 View 层的开发技术 • 电商应用的 UI 界面相对单一可枚举(橱窗,瀑布流,时间轴,搜索框……) • 思路: • 定义标准大粒度组件库,跨终端通用的布局库,屏蔽掉语言差异,采用动态推送内容(布 局 + 数据)到客户端,转成 Native 布局后渲染成 Native view 。
43. 跨终端的业务生成体系 移动终端有动态 native 渲染引擎 的 SDK ,把资源 转换成本地 Native UI View 动态 UI 服务将 设计师开发的界 面,和运营提供 的数据,绑定为 动态 Native 语 言,提供给终端 统一数据接入 层统一接入来 自云端的数据 ,提供 HSF 服 务 Android 客户端 iPhone 客户端 Native View Native View Dynative 渲染引擎 Dynative 渲染引擎 Dynative View DSL 动态 UI 服务 组件 布局 z 数据绑定规则 其他终端 UI 设计系 统 数据绑定工具 模板存储 无线网关 检查发布工具 可视化编辑 HSF2JSON HSF 服务网关 无线网关负责将 HSF 服务返回的数 据转换成移动端更 容易理解的 JSON 接口 数据源 云端 消费链路数据 设计师 界面开发 组件库 JSON Data 统一数据接入系统 IDE :所见即所得 的 UI 设计,类 CSS 的布局 商家链路数据 运营 数据绑定 开发 提供数据
44. Agenda 天猫五化战略 - 架构挑战 能力接入 能力整合 服务表达 服务交易 服务履行 服务数据 商业应用 总结
45. 开放,协同,数据驱动 的 电商创新平台 XX 手机 首发 家装节 天猫超市 生鲜食品 专场 …… 规则编排 个性化推荐 数据计划层 ( plan ) 供应链计划 …… 服务推荐 供应链计划 商业应用层 ( Application ) 供应链预测 送装一体 先试后买 预售 行业服务 手机抢购码 …… 解决方案层 ( Service ) 打包 平台能力 贷款 冷链配送 商家能力 七天无理 区域仓 由退货 安全 灾备 流控降级 服务市场 服务表达地图 交易扩展机制 服务商能力 … 安装维修 … 服务能力层 ( API ) 订单中心 行业运营中心 支撑 弹性计算 能力接入平台 服务整合平台 计算 跨行业服务 Framework 审计对账 基础容器层 ( kernel ) Dynative
46. 何崚(大少) @ 天猫 helin8@gmail.com

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-17 00:46
浙ICP备14020137号-1 $bản đồ khách truy cập$