【AICon】AI 基础设施、LLM运维、大模型训练与推理,一场会议,全方位涵盖! >>> 了解详情
写点什么

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

  • 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:254177

评论

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

就餐卡管理系统设计文档

nihuihua

食堂就餐卡系统设计

努力努力再努力m

架构 极客大学架构师训练营

架构师训练营-作业1-食堂就餐卡系统设计

紫极

极客大学架构师训练营 架构文档

食堂就餐卡系统设计

拈香(曾德政)

架构设计 极客大学架构师训练营

架构师和架构

拈香(曾德政)

架构师 极客大学架构师训练营

食堂就餐卡系统设计

泛岁月的涟漪

week1-食堂就餐卡系统架构设计

暖丶冬

架构师训练营总结-1

River Tree

极客大学架构师训练营 个人总结

食堂收费系统用例图

也良

架构师训练营 第一周总结

netbanner

极客大学架构师训练营

Week 01 作业:食堂就餐卡系统设计

鱼_XueTr

第一周总结

王志祥

极客大学架构师训练营

第一周:食堂就餐卡系统设计

Alex

极客大学架构师训练营

架构师到底是什么

molingwen

极客大学架构师训练营

作业一:食堂就餐卡系统设计

梦行

极客大学架构师训练营

食堂就餐卡系统设计

molingwen

极客大学架构师训练营

第一周:课程笔记及总结

Alex

极客大学架构师训练营

架构方法之架构设计文档【总结】

小叶

架构设计

架构师训练营-学习笔记-第一周

superman

学习 极客大学架构师训练营

架构师训练营-第一周总结

+╮(╯▽╰)╭/>……

架构师训练营-week1-学习总结

暖丶冬

架构师训练营第一周-总结

无心水

极客大学架构师训练营 UML

week1.学习总结

个人练习生niki👍

架构设计第一课

Dennis

第一周作业

free[啤酒]

架构

学习总结

nihuihua

架构师训练营第一周学习总结

梦行

极客大学架构师训练营

架构师训练营总结

Coder

极客大学架构师训练营

架构师训练营丨第一周丨学习总结

Frode

极客大学架构师训练营

缘起:被束缚的架构师

GAC·DU

极客大学架构师训练营

练习1-1

闷骚程序员

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