京东为什么建中台?因为“烟囱”多了太碍事

2019-10-29 Kanye 京东商城服务技术中台研
浏览

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

为何我们要做中台?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用户来自不同的群体吗?

存在重复建设吗?

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

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

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

2.领导层全力支持;

3.业务侧的协同认可;

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

5.基础服务治理。

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

中台建设的最大挑战

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

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

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

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

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

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

(作者:京东商城服务技术中台研发负责人贾乐本文由一鹏根据贾乐在10月26日结束的GTLC·成都站上的现场发言整理而成。)