GMTC 全球大前端技术大会(北京站)门票 9 折特惠中,点击立减 ¥480 了解详情
写点什么

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

2019 年 10 月 29 日

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

在 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:252941

评论

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

牛排等级之美国篇

地藏@易果18916037281

在 TypeScript 处理空值异常

寇云

typescript 前端开发

不安全的“安全密码”

沈传宁

信息安全 口令安全

Java并发编程基础--Synchronized

Java收录阁

线程

权限系统设计的一种解法

双城笔录

产品 总结 产品设计

JAVA小抄-001-Retrofit初级使用

NoNoGirl

retrofit okhttp

创新真的可遇不可求么?

Yanel 说敏捷产品

产品经理 产品设计 产品开发 产品推荐

jenkins集成maven获取远程项目

kcnf

Redis学习笔记(散列类型)

编程随想曲

redis

关于 DeepL 机器翻译能力

梁帅

产品 互联网 机器翻译 谷歌Google DeepL

系统的安全性设计

Janenesome

读书笔记 程序员 架构 安全

吾谈教育

ItsFitz

去中心化网络,不止区块链(一)

石君

区块链 去中心 去中心化网络 DHT

性能优化第一课:性能指标

kimmking

性能优化

Ubuntu 20.04 装机手册

小柒

Linux #Ubuntu #geek

人生需要做减法:少即是多

我心依然

程序员 人生 减法 少即是多 less is more

《通往财富自由之路》——day1

轩呀

得到

深入理解Java中的Lambda表达式和函数式编程的关系

jerry

Lambda java8 函数编程

道德和正确的认知

沈传宁

信息安全 计算机道德

[MySQL-InnoDB] Buffer pool 并发控制

ba0tiao

MySQL 数据库 innodb

回"疫"录(9):守住我们自己的净土

小天同学

疫情 回忆录 现实纪录 纪实

测试驱动开发英制单位转换

escray

学习 CSD 认证实战营

一杯茶的时间,上手 Docker

图雀社区

node.js react.js Docker

Panzoid:一款超好用的片头制作工具

千锤百炼锅

学习 产品 效率工具 工具 产品推荐

谨防常见的一些数据误区

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

第一篇InfoQ的博客

程序员小岑

写作 体验

iTerm2使用小技巧-密码管理器

小菜与老鸟

iTerm

最好的汇报是不需要汇报

伯薇

团队管理 领导力 沟通 汇报 可视化

我为什么不买Mac

Winann

效率 效率工具 Mac apple

写文章的目的是什么?

小天同学

思考 写作 感悟 表达

一个英语渣的自救手册

寇云

学习 效率工具 程序员人生 工作效率

DIY 的 Kubernetes 集群的稳定性保障实践

DIY 的 Kubernetes 集群的稳定性保障实践

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