百度/小米/滴滴/京东,中台架构比较

2024-09-09 18:08

本文主要是介绍百度/小米/滴滴/京东,中台架构比较,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

小米中台建设实践

01

小米的三大中台建设:业务+数据+技术

业务中台--从业务说起

在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。

小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

通过中台架构方法论和规划方法论,小米信息部提出了小米业务中台建设三年战略,包含了持续优化、构建中以及待新建的系统,纵向分为企业战略、业务执行、业务支撑、数据治理四部分。在2018年成立时,系统还是比较分散的;在2019年,主要围绕中台的架构调整、技术体系下沉,强化运营配置中心三方面,实现绝大多数的共享服务,让小米复杂的业态共享一套体系,更好的支持业务;在2020年,期望整体完善,不断的持续优化。

数据中台--数字化转型的核心

今天大家都在谈数字化转型,数字化转型是转什么?从企业内部来讲,是想如何把一切都数字化,大企业讲数字化转型是很难的一件事情,但现在有些小企业已经做得非常好。系统很简单,但是可以把企业的百十家或者几百家店铺的每一个动作、每一次上下架,甚至是每次的价格变更,每个操作人员的动作,都放到系统里面做记录。

数字化转型,业务是基础,核心是数据。在数据分析及使用过程中,小米主要面临3大问题:

数据极度分散:数据都分散在各系统中,没有形成统一共享的数据资源池;各业务域数据尚未形成统一口径,数据从指标层面上未能很好整合。

数据指标混乱:数据分析功能偏重于日常统计分析,需建立完备的能支撑精细化管理需求的指标体系;需建立完备的业务分析逻辑,通过建立全面的业务分析场景,“用数据说话”,进而完成趋势预测、异常甄别、辅助决策。

数据工具量少:需要一站式的访问入口、可视化和交互性更强的数据展示方式、支持移动端访问。

[产品派]百度/小米/滴滴/京东,中台架构比较

从数据整体来讲,一般分为数据采集、数据清洗,形成数据集市,最后数据分析员才可以在BI去做分析,并提出改进流程,提高业务发展。下图是小米数据中台的架构,底层是大数据平台的基础,在大数据的基础之上搭建了一系列的应用。为了解决以上数据问题,小米信息部成立了X DATA团队专门做数据,更方便地让分析人员在系统上直接分析全部门的任何数据、做报表。只要在权限管控内,分析人员直接得到对应的数据并进行数据分析。小米想从业务端沉淀数据,在共享到X DATA大数据分析,然后发现问题在反馈到业务系统中解决问题。

[产品派]百度/小米/滴滴/京东,中台架构比较

在数据中台上还需要运用一些关键技术,包括:大数据离线计算、趋势预测、实时计算、自然语言处理、可视化分析、图像识别等。

数据中台对业务运营产生的价值,主要体现在生产监控、日常运营、经营管理、战略管控等方面。最底层的是生产监控管理,如实时运营监控、实时风险监控等;第三层是日常运营型分析,如日常统计分析、操作统计分析等;第二层是经营管理分析与考核型分析,如商业洞察分析、人力资源分析、财务分析、部门绩效考核等;顶层是战略管控与预测型分析,如战略绩效分析、行业对标与企业经营预测分析。

通过对数据中台的建设,小米真正意义上开始走上数据驱动的路程。数据驱动小米的设备研发、生产、供应链、销售、服务以及IOT和互联网业务,产业+互联网格局逐步成熟。数据驱动小米进步,体现在精细化运营、智慧物流探、产业互联网等方面。现在全球都在建仓,到底在什么地方建仓合适,怎么去建仓?这都是要数据分析才能得出。

[产品派]百度/小米/滴滴/京东,中台架构比较

未来,大数据是为人工智能准备的。

技术中台--更敏捷的开发效率

前面讲的都是偏业务线、偏分析的,但核心最终还是要回归到IT的本质,更敏捷的开发效率才是IT最终的目标。在早期烟囱式的建设中,企业拥有众多的研发团队,但团队人员的基础不一样,工具不一样,面临:重复建设、质量无保证,横向打通困难、技术栈混乱,严重阻碍业务中台建设等问题。

[产品派]百度/小米/滴滴/京东,中台架构比较

业务&数据中台拥有强大炮火群,为前台业务快速响应直接提供支援,而技术中台是为中台服务提供高度模块化零件&武器库,大幅缩短业务中台建设时间,提高业务中台稳定性。小米通过技术下沉,把最标准的东西沉淀出来,包括IaaS(容灾、机房、数据中心)、PaaS(中间件、研发平台、数据平台)、监控、开发过程的代码,全部陈列到底层,形成技术中台。

滴滴中台建设实践

01

中台搭建背景--业务介绍

滴滴业务包括:

出行。涵盖了专车、快车、豪车、出租车、单车、点单车、代驾等等。

车服。涵盖了加油、充电、维保、长租、短租。

国际化。即滴滴海外业务。

金融。金融相关创新业务。

02

应对多业务面临的问题

跟许多大厂遇到的问题一样,烟囱式的业务线开发团队,在技术深度上无法做到均衡,还是以业务功能实现为主。资源投入上,会存在重复造轮子的问题。数据上形成数据孤岛,浪费资源。在用户体验上还无法做到真正的统一。

03

滴滴中台发展阶段

滴滴中台的发展,经历了四个阶段:

中台前。以实现业务功能为主,往上堆模块。

The one。自上而下、⼤平台模式, 理想化的解决方案,业务发展快、变化大,有沉淀、但未达到理想效果

出行中台。最大业务孵化,⽴足于解决问题,最合适原则,出行中台建成,孵化出部分业务中台。

业务中台。支持多业务线,提升打通能力,赋能业务,提升创新能力,规范业务。

04

做对了什么、做错了什么

业务初创期,快速支持业务最重要,中台不是必须的

基于解决问题,快速迭代,更容易成功

最大业务孵化,最适合、最小化原则

意识升级、加强沟通,平衡多业务线

稳定、抽象

05

中台搭建宏观思路

中台搭建宏观思路

组织升级。如何兼顾既要快速开发,又要形成技术和业务的沉淀,是对组织最大的挑战。

意识升级。从集团军大规模作战,变成特种兵为主在前线呼唤炮火的现代型作战方式。

系统升级。系统沉淀出强大的业务能力,赋能前端业务。

06

中台边界界定

中台边界界定原则:

业务通用。把业务进行抽象,如快车、专车、出租车,其共性的接单、下单逻辑抽象。

多业务。支持集团复杂的业务形态。

下沉机制。将共性业务进行下沉,提升模块的复用性,逻辑统一性。

07

滴滴中台总体架构

[产品派]百度/小米/滴滴/京东,中台架构比较

滴滴中台总体架构,从上往下:

业务应用层。包括出行、车服、国际化、金融业务线。

业务中台层。包括:用户中心、passport、计价中心、订单中心、支付中心、触达等中台模块。

基础设施层。如RPC框架、日志、监控、大数据平台、搜索等中间件。

08

支付中台--分领域架构设计

[产品派]百度/小米/滴滴/京东,中台架构比较

以支付中台为例,来了解领域架构设计。主要分成五块:支付产品、支付业务、支付能力、支付中心、运营工具。以此类推,其它业务中台模块按此进行架构规划和设计。

09

高可用、高性能技术实现

在技术架构上,业务中台要具备高可用、高性能的技术要求。各模块以服务化的方式提供能力,有统一网关、服务治理、可伸缩、分表分库数据中间件、影子数据库等。

10

中台面临问题:持续交付乏力

中台面临问题:

1,中台做着、业务看着。中台毕竟力量有限,而且业务专家多在一线,导致交付能力不足的问题。

2,中台排期久,业务不满。中台变成交付的瓶颈,导致业务的不满。

3,业务自己上,中台成为摆设。在业务压力下,许多业务线选择自己上。

11

如何提高持续交付能力?

提高交付能力,不外乎:加人、加班。除此之外,要考虑架构上支持持续加人,也就是说,加了人整个团队的效率是可以线性增加的。

12

具体解法

这里就涉及到架构治理、IT治理了,要对业务进行抽象建模,合理划分边界,人多了不打架。

配置化,尽量解耦。

标准化,使得多个团队能够协作顺畅。

插件化,把规则形成工具,强制执行。

可隔离,各模块架构数据、部署上支持隔离。

百度搜索中台建设实践

01

百度中台的技术思路:

提供完备的通用能力、定制能力,持续完善领域技术沉淀能力。业务视角, 中台提供了灵活的可定制业务框架, 使得业务可以聚焦业务特有逻辑的开发;中台还提供了可以复用的业务组件, 使得业务可以通过配置化来复用优秀的中台能力;中台还提供了完备的文档建设、视频教程, 支持业务快速上手、快速迭代, 同时还提供了面向全流程开发效能提升的完整自动化工具链。系统架构图如下:

[产品派]百度/小米/滴滴/京东,中台架构比较

02

[产品派]百度/小米/滴滴/京东,中台架构比较

03

现在,百度不但深耕了更多的搜索结果,满足用户更完善的获取信息甚至服务的需求,也扩展了更多的流量入口,包括小程序、独立站等,随着产品思路的调整,产品形态日趋复杂,之前的平台化的思路就行不通了。原有系统核心模块无法满足业务多样性的扩展需求, 一些扩展成本非常高、上线和维护的风险特别大,使得之前的系统优势转换为了制约当前业务发展的缺陷。而转为中台战略,使得团队同时高效高质量的支持更多业务,成为可能。

[产品派]百度/小米/滴滴/京东,中台架构比较

04

直接驱动业务增长的应用技术创新,是中台的重要使命

1.通过死磕业务场景,发现增长曲线的微创新

可能需要技术系统的重大升级

新的算法催生新的突破,促进整体效果的提升

2.通过应用最新的研究成果,打造领先的产品效果

3.大部分的创新都可以低成本辐射核心业务

中台具备群体加速创新,促进创新叠加的基础

京东中台建设实践

京东:打造共建、共享、标准化的数据中台

2018年底京东零售数据中台成立,目的就是对京东零售内部的数据体系进行全面梳理,建立以数据驱动业务增长的新引擎。

数据中台:破除企业数据孤岛

在企业业务发展过程中所累积的大量数据,往往分散在各个业务单元和组织内部,形成一个个"数据孤岛"、"数据烟囱"。而数据中台是着眼于企业数据资产汇集、数据算法迭代、数据能力输出的根基平台,以数据指引业务决策并驱动业务增长,是破除数据孤岛的关键策略。

京东数据中台负责人--黎科峰介绍,目前京东集团已形成零售、数科、物流、保险、健康等多元化的业务格局,各业务都进入到精细化运营阶段,对于数据精细化运营提出了更高的需求。京东过往十多年业务发展沉淀下来的海量数据,需要通过数据中台的建设形成宝贵的数据资产,以打造强有力的数据智能能力。这也是京东自去年就开始推动数据中台建设的重要原因。

黎科峰认为,数据中台的核心包括数据基础层、数据服务层、数据应用层。除了技术之外,数据中台建设更重要的是一种协作意识和组织能力。因此京东在建设数据中台的过程中提出了共建、共享、标准化三个关键理念。

京东数据中台的共建理念,就是要联合各个业务单元,共同打造沉淀一套大数据中台。共享则是要避免数据孤岛,打破组织界限,实现数据的共通、能力共享。而标准则是指统一的数据标准,从底层的数据治理标准、数据口径标准,到统一的数据标签体系和数据模型服务,确保数据在集团内部流转和应用是基于同样的标准和基础。

京东数据中台:千尺之台,起于垒土

数据中台的建设并非朝夕之功。黎科峰介绍,京东数据中台成立之后,经过半年多的建设,基本完成了打基础的阶段。首先在数据底层的建设方面,京东建立了统一的采存算大数据平台,有节奏地合并数据集市,形成统一的大集市。数据治理环节,通过EC纠删码技术、数据分级分类、僵尸数据清理和冷数据治理等手段,数据有效性大大提高,数据逐步实现资产化,也大大节约了数据存储和计算资源。

在数据服务层,京东正在搭建一套公共的数据标签体系,汇聚前台业务部门、运营部门以及广告、搜索等各个垂直场景的标签数据,不断迭代,为各个数据应用场景赋能。同时,数据中台向各数据应用层提供数据模型能力,通过商品数据治理形成更准确的商品画像。

最后在数据应用层,京东数据中台推动前台统一了数十个数据产品,建立了统一的数据口径和数据看板。前台部门统一通过黄金眼和商智来提供对采销和商家的数据报表服务,底层通过数据中台使用同一套数据。

黎科峰认为,数据治理是数据中台建设不可或缺的一部分。数据治理要解决数据全不全、准不准、好不好用这三方面的问题,一定要让业务团队清晰地知道,公司的数据能力和数据资产应该达到怎样的标准。同时黎科峰指出,建设数据中台并不意味着中心化,而应该利用API等形式提供各相关方使用,而区块链等技术手段在实现数据资产化的过程中也将发挥重要作用。

经过多年的积累,京东的亿万消费者和商家在平台上沉淀了海量的数据,数据的深入挖掘对于提升用户体验和商家营销能力都至关重要。京东数据中台着眼于数据驱动业务精细化运营的能力建设,持续夯实数据基础,形成数据与业务正向自循环促进的关系,不仅全面推动京东内部蓬勃的业务创新,也可以更好地对外服务,带动整个产业的数字化转型。

这篇关于百度/小米/滴滴/京东,中台架构比较的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1151897

相关文章

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

关键字synchronized、volatile的比较

关键字volatile是线程同步的轻量级实现,所以volatile性能肯定比synchronized要好,并且volatile只能修饰于变量,而synchronized可以修饰方法,以及代码块。随着JDK新版本的发布,synchronized关键字的执行效率上得到很大提升,在开发中使用synchronized关键字的比率还是比较大的。多线程访问volatile不会发生阻塞,而synchronize

创业者该如何设计公司的股权架构

本文来自七八点联合IT橘子和车库咖啡的一系列关于设计公司股权结构的讲座。 主讲人何德文: 在公司发展的不同阶段,创业者都会面临公司股权架构设计问题: 1.合伙人合伙创业第一天,就会面临股权架构设计问题(合伙人股权设计); 2.公司早期要引入天使资金,会面临股权架构设计问题(天使融资); 3.公司有三五十号人,要激励中层管理与重要技术人员和公司长期走下去,会面临股权架构设计问题(员工股权激

【系统架构设计师】黑板架构详解

黑板架构(Blackboard Architecture)是一种软件架构模式,它模仿了多个专家系统协作解决问题的场景。在这种架构中,“黑板”作为一个中央知识库,存储了问题的当前状态以及所有的解决方案和部分解决方案。黑板架构特别适合于解决那些没有确定算法、需要多个知识源(或称为“专家”)共同作用才能解决的复杂问题。 一、黑板架构的组成 黑板架构主要由以下几个部分组成: 黑板(Blackboa

京东物流查询|开发者调用API接口实现

快递聚合查询的优势 1、高效整合多种快递信息。2、实时动态更新。3、自动化管理流程。 聚合国内外1500家快递公司的物流信息查询服务,使用API接口查询京东物流的便捷步骤,首先选择专业的数据平台的快递API接口:物流快递查询API接口-单号查询API - 探数数据 以下示例是参考的示例代码: import requestsurl = "http://api.tanshuapi.com/a

Java后端微服务架构下的API限流策略:Guava RateLimiter

Java后端微服务架构下的API限流策略:Guava RateLimiter 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,API限流是保护服务不受过度使用和拒绝服务攻击的重要手段。Guava RateLimiter是Google开源的Java库中的一个组件,提供了简单易用的限流功能。 API限流概述 API限流通过控制请求的速率来防止

安卓玩机工具------小米工具箱扩展工具 小米机型功能拓展

小米工具箱扩展版                     小米工具箱扩展版 iO_Box_Mi_Ext是由@晨钟酱开发的一款适用于小米(MIUI)、多亲(2、2Pro)、多看(多看电纸书)的多功能工具箱。该工具所有功能均可以免root实现,使用前,请打开开发者选项中的“USB调试”  功能特点 【小米工具箱】 1:冻结MIUI全家桶,隐藏状态栏图标,修改下拉通知栏图块数量;冻结

Arch - 演进中的架构

文章目录 Pre原始分布式时代1. 背景与起源2. 分布式系统的初步探索3. 分布式计算环境(DCE)4. 技术挑战与困境5. 原始分布式时代的失败与教训6. 未来展望 单体时代优势缺陷单体架构与微服务架构的关系总结 SOA时代1. SOA架构及其背景1. 烟囱式架构(Information Silo Architecture)2. [微内核架构](https://www.oreilly.c