AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

京东服务技术中台:全流程建设方法及思考总结

  • 2019-10-29
  • 本文字数:4204 字

    阅读完需:约 14 分钟

京东服务技术中台:全流程建设方法及思考总结

在 10 月 26 日结束的 GTLC · 成都站上,京东商城服务技术中台研发负责人、TGO鲲鹏会会员贾乐进行了名为「京东服务技术中台建设管理实践」的主题分享。在本次演讲中,贾乐聚焦京东服务技术中台的全流程建设方法,并分享了自己在中台建设领域的经验总结,包括:3 个前置问题、5 个必要条件及中台建设的最大挑战。本文根据其演讲整理而成,分享给未能来现场参会的你。以下内容整理自贾乐的现场发言:


编者注:查看贾乐完整版 PPT,请在 TGO 鲲鹏会公众号回复“GTLC 成都站”自动获取。



大家下午好,今天我分享的主题是京东服务技术中台探索与实践,分别从三个方面来讲:


1.为何我们要做中台


2.京东服务技术中台建设思路;


3.关于中台建设的个人思考。

为何做中台?答:拆掉烟囱

为什么要做服务技术中台呢?举个例子,假设一个用户在京东买了东西,但不满意,希望退换货。他会通过在线聊天、电话找到客服,客服会对其进行接待,并将用户反映的问题记录下来。最终京东官方会给出一个解决方案,可能是换货、退货或赔付;如果客户是从京东平台第三方商家买到的产品,那么京东还需要从中立角度为他与商家执行仲裁。


所以,若想服务好顾客,我们会和许多部门打交道,包括物流、仓储、维修等等,所以服务技术中台是围绕于人、财、物三者进行服务的。



就架构发展历程来讲,京东第一阶段的应用结构都是单体应用,例如在物理机上部署一个 Nginx+Tomcat,要求非常简单,就是快。那么多时间做复杂的设计,简单粗暴,一堆代码放上去能跑就可以了。当然,这种设计的缺点也非常明显,就是运维成本非常高,没有什么灾备部署,服务器挂了就是挂了。


第二阶段是“修身治国”,即当业务开始快速增长,我们对业务架构提出了更高的要求。在这种情况下,我们开始做业务的解耦和微服务化,将集群部署在多个不同的 IDC,统一进行服务治理,包括建立了自动部署体系、统一的日志体系、统一的监控体系等基本的运维设施。自此,运维工作具备了横向扩展能力:日常运维基于容器,部署自动化,可以很方便的收集、分析、处理告警,同时具备了一定的平台化和可配置能力。



看起来一切都已经很不错,那为什么还要做中台呢?很多同学在另一个角度上提出了这种疑惑,即微服务化改造和中台战略到底有什么区别?那么接下来,我来讲一讲为何要做中台,以及中台和微服务有什么不一样。


从单一角度来看,第二阶段确实没有什么明显问题。但如果站高一点,站到整个公司的层面俯视,就会看到一堆“烟囱”,为什么是一堆“烟囱” ?



首先我们会看到“产品烟囱”:不同的产品间,定位和功能雷同;


第二是“系统烟囱”,研发人员有一个特点:自己写代码开发的系统才用着放心,别人的不愿意用,所以总是重复开发;


第三是“数据烟囱”,在第二阶段,各个系统产生的数据其实已经汇聚到大数据平台。在一定程度上,数据不存在分别存储的问题,但这依然存在一些问题:产品不同,因而数据计算逻辑和口径是不同的,那么很可能同一个数据指标有不同的计算逻辑和计算口径去计算,导致难以合并分析;


最后就是“组织烟囱”,即“部门墙”,天然存在,存在即合理。可当“部门墙”太厚就形成了“组织烟囱”,导致信息不透明。


以上就是第二阶段存在的问题。


京东的解决思路是什么?就是中台战略,兼济天下,无论是产品还是工具,不能只为自己考虑,不管他人死活,中台要赋能整个公司、社区、环境,产品的使用人数越多越能凸显价值。

京东服务技术中台建设思路

京东服务技术中台经过检验建设,共分为三层:



平台层:核心能力包括及时通信平台能力、音视频能力,再加上业务引擎和基础 SaaS 设施,这构成了我们的平台层。


组件层:主要分为三个部分,第一部分是平台插件和中心化。对于相对通用、容易用配置实现的功能或规则,用平台配置中心完成,使标准化需求可以得到快速满足;第二部分是插件装配中心。如果一些需求无法标准化成配置,那么我们允许第三方,可以定制化自己的插件,插入我们的系统中,给用户提供相应的功能服务。比如说常见的订单插件、商品插件;最后一部分是个性化接入中心,部分业务逻辑、流程与中台已有的非常不一样,这种差异导致计划配置也要差异化实现。这时候我们提供个性化接入,让其可以变成做成标准化服务,接入整个服务网络里面。


服务产品层:在前两层之上,我们的产品体系最终得以构建,包括客服服务平台、电话呼叫中心服务平台、售后服务平台等,在这一层对接、服务京东所有的业务领域。


服务技术中台主要解决两个问题:成本和速度。


“成本”这个词非常好理解,繁多的职能和产品整合到了一起,人力成本首先得到了解决;“速度”,指的是交付速度,当新风口出现的时候,如果没有中台战略良好的底层积累,产品质量没有办法保证。而对于中台来说,新的产品可能只是换个壳。我们常说大中台、小前台,小前台可以做得很快很轻,基于中台的配置去完成。


所以,我们围绕产品、系统、数据和组织来构建中台架构。其中,组织其实是第一步工作,要把相同的产品、功能合并,再于产品之间进行整合,使之成为一个完整的个体,成为一个中台,去对外提供服务。


我称这种整合为一种艺术,为什么?第一,不同的“烟囱”确实代表业务需求不一样,如果需求一致,不可能出现几个烟囱;第二,业务方并不关心底层有几套系统在做支撑,他们关注的是体验和交付有没有得到提升,但我们要得到业务方的支持。因为中台建设其实需要投入大量的资源和人力,在这个过程中,一定程度上会减少支撑业务的技术人员数量,所以要和业务方提前达成一致。这就像要为高速奔驰的赛车更换发动机,简单的系统一两周就迁移完了,复杂的系统可能要半年、一年才能迁移完成。



这里还需要解决一个基本问题:产品整合完之后,同一个中台要支撑不同的业务线,不同的业务线又有不同的逻辑和流程、不同的业务量和资源需求,那么第一步要做什么?


就是用多租户把整个业务线的配置、资源(计算资源、存储资源)隔离开。不同产品的多租户身份必须是统一的、唯一的,因为如果每个系统都去建立自己的多租户,当两者需要配合完成任务的时候,就会发生冲突。


在这个基础上,我们要按照开放封闭原则去打造生态。开放封闭原则,大家一定不陌生,中台内部有非常完善的体系,我们并不希望外部需求去影响中台的发展。同时,为了实现这个目标,我们对外开放了足够多的扩展,包括多租户、帐户认证、订单接口等。


只要满足我们的协议,能够快速的进行配置,就完成了接入,速度非常快。同时产品和产品之间也是解耦的,包括 CM、工单和机器人。我们允许第三方接入,让单一的产品也能和第三方配合起来,同时提供 PaaS、SaaS、私有云这三种模式来给集团赋能、外部赋能。


建设中台的 3 问及 5 个必要条件

最后是我对服务技术中台的一些思考。



首先建设中台要问自己三个问题:


1.需要支撑多个不同的业务线吗?


2.用户来自不同的群体吗?


3.存在重复建设吗?


如果用户和业务线相同,其实中台在某种程度上是一个伪需求。


服务技术中台建设的一些必要条件:


1.符合公司战略发展方向;


2.领导层全力支持;


3.业务侧的协同认可;


4.基础设施能提供支撑;


5.基础服务治理。


我在分享服务技术中台的构建时,并没有分享统一日志、统一监控、分布式框架、集群、容灾等方面的内容,因为这些内容在第二阶段就已经完成了。它们重不重要?非常重要,这是服务技术中台建设的基础。所以中台建设的时机很重要,如果没有这些基础,没有领导层支持,与公司战略也不吻合,中台建设就会非常吃力。

中台建设的最大挑战

在我看来,建设服务技术中台的最大挑战,既不是技术,也不是基础设施,而是组织和文化。


为什么这么说?前面我们提到很多“烟囱”,需要将他们进行合并,最简单的方式就是将两个部门合并、将相同的产品合并,这就涉及到组织架构调整,没有高层支持是不可能的。


我之前遇到一个讲师,他在深圳做整个公司的架构负责人。他说,公司内部另外一个业务部门做了和他们一样的东西。这让他非常困惑,想推广本部门产品非常困难,推到做了“竞品”的业务部门死活推不下去,这是非常现实的情况,也是没有得到高层支持时,常见的情况。


另一个挑战是文化,其实很多公司都在进行中台建设,但是在建设过程当中会遇到很多文化挑战。文化挑战分两种:第一种是供给者,第二种是需求者。


对于需求者来说,最大的挑战是要克服“什么都要我自己做”的心理。举个例子,当产生了一个需求,最先想到的应该是,在公司内有无类似的产品是可以复用的,这时我们要有把自己的后背交给兄弟的决心,当别人的产品能够部分满足我们需求时,其实我们需要尽量的 push 他们,让产品能够尽量满足我们的需求,而不是自己做。


对于供给者来说,最大的问题是工作和 KPI 是否能保持一致。如果只是满足部门内需求就可以了,为什么要把产品给整个公司使用呢?这其实是增加了该部门的运营负担,但如果从高层想实施中台战略,那么他一定会把这个部门的职责,定义成为将产品覆盖到整个公司,而不是只服务自己。当这二者之间有了契合的时候,作为供给者的战斗力才会发挥到最大。


这是我今天的分享,谢谢大家。


嘉宾介绍


贾乐,2006 年毕业于重庆大学计算机系,2011 年加入京东,现任服务技术中台研发负责人,负责客服、售后产品线的研发工作,作为中台服务于包括零售、金融、物流、健康在内的全集团业务。专注于中台架构、即时通讯技术、高可用的微服务架构,目前致力于打造统一的服务技术中台,以低成本、快交付的中台模式支撑客服售后领域复杂多变的业务集。

活动推荐

是不是不想错过本年度最后一次技术管理者盛宴呢?


11 月 23 日,GTLC · 深圳站将正式拉开帷幕。现场有环球易购 CTO & 前苏宁科技集团副总裁乔新亮、Lazada Group CTO 郭东白、Mobvista 集团副总裁 吴峰、TalentX Consulting 创始人兼 CEO Tina Jiang 等一批业界优秀的技术领导者,分享领先的技术管理思考与理念,帮助你成为一名优秀的 CTO!


快快点击「详情」,享受优惠购票吧!





TGO鲲鹏会,是极客邦科技旗下高端技术人聚集和交流的组织,旨在组建全球最具影响力的科技领导者社交网络,线上线下相结合,为会员提供专享服务。目前,TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名,60% 为 CTO、技术 VP、技术合伙人。


会员覆盖了 BATJ 等互联网巨头公司技术领导者,同时,阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀,成为 TGO 鲲鹏会荣誉导师。


2019-10-29 11:254831

评论

发布
暂无评论
发现更多内容

什么是算力网络

天翼云开发者社区

云计算 边缘计算 算力网络

数智时代:新基建与低代码的绝妙碰撞!

快乐非自愿限量之名

低代码 新基建 数智转型 数智时代

接口测试|Fiddler弱网测试

霍格沃兹测试开发学社

【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(通用语言体系)

洛神灬殇

领域驱动设计 DDD 领域驱动设计思想 领域驱动模型

重新初始化k8s集群

tiandizhiguai

云计算 云原生 k8s

探索支付宝云开发,开启一段100ms的神奇旅程!

TRaaS

支付宝小程序 云开发

opencv目标检测之canny算法

高端章鱼哥

OpenCV

探秘AI算力革命与低代码平台:引领人工智能狂潮

不在线第一只蜗牛

低代码 数智化 AI算力

视觉系统对自动驾驶至关重要|数据堂

来自四九城儿

SQL 优化(一):慎用 SQL 函数

hungxy

Java MySQL 后端

完全自动驾驶车辆何时才能成为现实

来自四九城儿

接口测试|Fiddler设置手机抓包

霍格沃兹测试开发学社

Selenium 中并行测试的重要性

FunTester

2024深圳电子展,中国国际电子信息博览会(CITE电博会)

AIOTE智博会

电子展

Scrum看板工具在项目管理中的作用

顿顿顿

敏捷工具 scrum工具 scrum敏捷工具

零基础自学:2023年的今天,请谨慎进入网络安全行业

网络安全学海

黑客 网络安全 信息安全 计算机 渗透测试

教学实训模块升级,助力应用型数据科学人才培养|ModelWhale 版本更新

ModelWhale

数据分析 大模型 教学实训 在线编程 云课堂

如何通过场景规划帮助企业实现全面预算管理?

智达方通

智达方通 全面预算管理 财务规划和分析 财务规划与预测 全面预算管理系统

小程序容器技术在移动警务中的业务价值

FinFish

小程序容器 移动警务 警务app

分享一个在Reddit上保存视频到手机相册的办法真的YYDS!reddit video downloader!

frank

面向对象设计的逆向建模方法和开源工具

高鹏

Java 开源 架构 DDD 架构设计

接口测试|Fiddler界面工具栏介绍(三)

霍格沃兹测试开发学社

接口测试|Fiddler抓包设置及证书配置

霍格沃兹测试开发学社

StarRocks & Friends 上海站活动回顾(含 PPT 下载链接)

StarRocks

数据库 OLAP MPP 大数据 开源

何时使用Kafka而不是RabbitMQ

越长大越悲伤

Kafk Rabbit MQ 消息列队

唯一入选中国厂商!灵雀云获Gartner® 首份《DevOps平台魔力象限报告》“荣誉提及”

York

容器 DevOps 云原生 Gartner 平台工程

机遇与挑战——超级自动化产品的国产化替代已成为大势所趋

九科Ninetech

接口测试|Fiddler会话栏中添加IP列

霍格沃兹测试开发学社

跨架构平台在云计算中的应用

天翼云开发者社区

云计算 架构

Vue插槽详解

高端章鱼哥

Vue 插槽

京东服务技术中台:全流程建设方法及思考总结_技术管理_TGO鲲鹏会成都分会_InfoQ精选文章