今天我分享的主题是京东服务技术中台探索与实践，分别从三个方面来讲：
为何我们要做中台？
京东服务技术中台建设思路；
关于中台建设的个人思考。
为何做中台？答：拆掉烟囱
为什么要做服务技术中台呢？举个例子，假设一个用户在京东买了东西，但不满意，希望退换货。他会通过在线聊天、电话找到客服，客服会对其进行接待，并将用户反映的问题记录下来。最终京东官方会给出一个解决方案，可能是换货、退货或赔付。如果客户是从京东平台第三方商家买到的产品，那么京东还需要从中立角度为他与商家执行仲裁。
所以，若想服务好顾客，我们会和许多部门打交道，包括物流、仓储、维修等等，所以服务技术中台是围绕于人、财、物三者进行服务的。
就架构发展历程来讲，京东第一阶段的应用结构都是单体应用，例如在物理机上部署一个 Nginx+Tomcat，要求非常简单，就是快。那么多时间做复杂的设计，简单粗暴，一堆代码放上去能跑就可以了。当然，这种设计的缺点也非常明显，就是运维成本非常高，没有什么灾备部署，服务器挂了就是挂了。
第二阶段是“修身治国”，即当业务开始快速增长，我们对业务架构提出了更高的要求。在这种情况下，我们开始做业务的解耦和微服务化，将集群部署在多个不同的IDC，统一进行服务治理，包括建立了自动部署体系、统一的日志体系、统一的监控体系等基本的运维设施。自此，运维工作具备了横向扩展能力：日常运维基于容器，部署自动化，可以很方便地收集、分析、处理告警，同时具备了一定的平台化和可配置能力。
看起来一切都已经很不错，那为什么还要做中台呢？很多同学在另一个角度上提出了这种疑惑，即微服务化改造和中台战略到底有什么区别？那么接下来，我来讲一讲为何要做中台，以及中台和微服务有什么不一样。
从单一角度来看，第二阶段确实没有什么明显问题。但如果站高一点，站到整个公司的层面俯视，就会看到一堆“烟囱”，为什么是一堆“烟囱”？
首先我们会看到“产品烟囱”：不同的产品间，定位和功能雷同；
第二是“系统烟囱”，研发人员有一个特点：自己写代码开发的系统才用着放心，别人的不愿意用，所以总是重复开发；
第三是“数据烟囱”，在第二阶段，各个系统产生的数据其实已经汇聚到大数据平台。在一定程度上，数据不存在分别存储的问题，但这依然存在一些问题：产品不同，因而数据计算逻辑和口径是不同的，那么很可能同一个数据指标有不同的计算逻辑和计算口径去计算，导致难以合并分析；
最后就是“组织烟囱”，即“部门墙”，天然存在，存在即合理。可当“部门墙”太厚就形成了“组织烟囱”，导致信息不透明。
以上就是第二阶段存在的问题。
京东的解决思路是什么？就是中台战略，兼济天下，无论是产品还是工具，不能只为自己考虑，不管他人死活，中台要赋能整个公司、社区、环境。产品的使用人数越多越能凸显价值。
京东服务技术中台建设思路
京东服务技术中台经过检验建设，共分为三层。
平台层：核心能力包括及时通信平台能力、音视频能力，再加上业务引擎和基础 SaaS 设施，这构成了我们的平台层。
组件层：主要分为三个部分，第一部分是平台插件和中心化。对于相对通用、容易用配置实现的功能或规则，用平台配置中心完成，使标准化需求可以得到快速满足；第二部分是插件装配中心。如果一些需求无法标准化成配置，那么我们允许第三方，可以定制化自己的插件，插入我们的系统中，给用户提供相应的功能服务。比如说常见的订单插件、商品插件；最后一部分是个性化接入中心，部分业务逻辑、流程与中台已有的非常不一样，这种差异导致计划配置也要差异化实现。这时候我们提供个性化接入，让其可以变成做成标准化服务，接入整个服务网络里面。
服务产品层：在前两层之上，我们的产品体系最终得以构建，包括客服服务平台、电话呼叫中心服务平台、售后服务平台等，在这一层对接、服务京东所有的业务领域。
服务技术中台主要解决两个问题：成本和速度。
“成本”这个词非常好理解，繁多的职能和产品整合到了一起，人力成本首先得到了解决；“速度”，指的是交付速度，当新风口出现的时候，如果没有中台战略良好的底层积累，产品质量没有办法保证。而对于中台来说，新的产品可能只是换个壳。我们常说大中台、小前台，小前台可以做得很快很轻，基于中台的配置去完成。
所以，我们围绕产品、系统、数据和组织来构建中台架构。其中，组织其实是第一步工作，要把相同的产品、功能合并，再于产品之间进行整合，使之成为一个完整的个体，成为一个中台，去对外提供服务。
我称这种整合为一种艺术，为什么？第一，不同的“烟囱”确实代表业务需求不一样，如果需求一致，不可能出现几个烟囱；第二，业务方并不关心底层有几套系统在做支撑，他们关注的是体验和交付有没有得到提升，但我们要得到业务方的支持。因为中台建设其实需要投入大量的资源和人力，在这个过程中，一定程度上会减少支撑业务的技术人员数量，所以要和业务方提前达成一致。这就像要为高速奔驰的赛车更换发动机，简单的系统一两周就迁移完了，复杂的系统可能要半年、一年才能迁移完成。
这里还需要解决一个基本问题：产品整合完之后，同一个中台要支撑不同的业务线，不同的业务线又有不同的逻辑和流程、不同的业务量和资源需求，那么第一步要做什么？
就是用多租户把整个业务线的配置、资源（计算资源、存储资源）隔离开。不同产品的多租户身份必须是统一的、唯一的，因为如果每个系统都去建立自己的多租户，当两者需要配合完成任务的时候，就会发生冲突。
在这个基础上，我们要按照“开放封闭原则”去打造生态。开放封闭原则，大家一定不陌生，中台内部有非常完善的体系，我们并不希望外部需求去影响中台的发展。同时，为了实现这个目标，我们对外开放了足够多的扩展，包括多租户、账户认证、订单接口等。
只要满足我们的协议，能够快速进行配置，就完成了接入，速度非常快。同时产品和产品之间也是解耦的，包括CM、工单和机器人。我们允许第三方接入，让单一的产品也能和第三方配合起来，同时提供PaaS、SaaS、私有云这三种模式来给集团赋能、外部赋能。
建设中台的3问及5个必要条件
最后是我对服务技术中台的一些思考。
首先建设中台要问自己三个问题：
需要支撑多个不同的业务线吗？
用户来自不同的群体吗？
存在重复建设吗？
如果用户和业务线相同，其实中台在某种程度上是一个伪需求。
服务技术中台建设的一些必要条件：
1.符合公司战略发展方向；
2.领导层全力支持；
3.业务侧的协同认可；
4.基础设施能提供支撑；
5.基础服务治理。
我在分享服务技术中台的构建时，并没有分享统一日志、统一监控、分布式框架、集群、容灾等方面的内容，因为这些内容在第二阶段就已经完成了。它们重不重要？非常重要，这是服务技术中台建设的基础。所以中台建设的时机很重要，如果没有这些基础，没有领导层支持，与公司战略也不吻合，中台建设就会非常吃力。
中台建设的最大挑战
在我看来，建设服务技术中台的最大挑战，既不是技术，也不是基础设施，而是组织和文化。
为什么这么说？前面我们提到很多“烟囱”，需要将他们进行合并，最简单的方式就是将两个部门合并、将相同的产品合并，这就涉及到组织架构调整，没有高层支持是不可能的。
我之前遇到一个讲师，他在深圳做整个公司的架构负责人。他说，公司内部另外一个业务部门做了和他们一样的东西。这让他非常困惑，想推广本部门产品非常困难，推到做了“竞品”的业务部门死活推不下去，这是非常现实的情况，也是没有得到高层支持时，常见的情况。
另一个挑战是文化，其实很多公司都在进行中台建设，但是在建设过程当中会遇到很多文化挑战。文化挑战分两种：第一种是供给者，第二种是需求者。
对于需求者来说，最大的挑战是要克服“什么都要我自己做”的心理。举个例子，当产生了一个需求，最先想到的应该是，在公司内有无类似的产品是可以复用的，当别人的产品能够部分满足我们需求时，其实我们需要尽量地push他们，让产品能够尽量满足我们的需求，而不是自己做。
对于供给者来说，最大的问题是工作和KPI是否能保持一致。如果只是满足部门内需求就可以了，为什么要把产品给整个公司使用呢？这其实是增加了该部门的运营负担，但如果高层想实施中台战略，那么他一定会把这个部门的职责，定义成为将产品覆盖到整个公司，而不是只服务自己。当这二者之间有了契合的时候，作为供给者的战斗力才会发挥到最大。
（作者：京东商城服务技术中台研发负责人贾乐 本文由一鹏根据贾乐在10月26日结束的GTLC·成都站上的现场发言整理而成。）
