花两个月吃透京东T8推荐的178页京东基础架构建设之路，入职定T5

Posted 2023-04-06 码农小菜子

大家首先来看看京东的职级和薪资状况！

京东岗位序列主要分M、T、列。T序列包含产品和技术，P序列为项目经理。

薪酬结构:年薪=月薪* (12+1) ，1为年终奖, 一般为1-2个月；

月薪=基本工资(70%) +绩效I资(30%基本I资+绩效系数) +餐补+ I龄补贴+全勤奖;

京东每年都在给所有中基基员工加薪，基基员工加薪幅度不低于10%，主管、经理级员工则不低于20%。

既然大家已经知道了京东的职级和薪资状况了，接下来给大家分享的就是京东的一系列核心基础架构系统，希望大家能够喜欢~~~~

目录

主要内容

本文涵盖容器集群、数据库、分布式存储、服务框架、消息队列、异 多活、机器学习等一系列经典技术话题 深入浅出地向读者展示了京东基础架构的搭建、演进、变革及发展的完整画像，系统地阐述了京东重要阶段的技术进步历程及里程碑级别的技术突破，堪称是部“从入门到精通”的基础架构经典教材。

第1章“容器集群技术”，主要介绍数据中心操作系统JDOS，即容器集群管理平台。

本章会与大家分享JDOS团队的发展历程、业务服务现状和技术发展阶段。在内容呈现上，本章讲述了从JDOS 1.0容器化“胖容器”开创京东容器化技术之路，到完成京东全部业务容器化运行后，随即推动JDOS 2.0，完全基于镜像发布方式，建设完整的容器技术生态的内容。自研分布式智能DNS、高性能负载均衡，以及为容器量身打造的分布式共享存储ContainerFS，这些都是为了更好地建设JDOS与数据中心协同发展的生态。在完成JDOS实现数据中心操作系统赋能后，进而推动JDOS 3.0以构建京东的PaaS平台，从源码、编译、构建镜像、容器集群编排、副本控制、日志、监控、中间件能力等完整PaaS生态。随着JDOS规模持续增大，精细化运营促使启动了正在演进中的JDOS 4.0阿基米德项目融合计算，实现在线业务与离线大数据计算混部，智能调度，并在满足业务计算需求的同时节约采购成本。在容器技术实践方面，京东是发展较早也比较坚定的，在实践过程中有很多理解和技术感悟。

第2章“数据库技术”，主要介绍了弹性数据库系统的演进。

本章详细记录了京东在这方面的尝试和思考，其核心观点简单明了，京东未来的技术架构是构建在弹性数据库基础之上的，可以快速响应业务的需求，有效利用资源、降低成本、提升数据库性能。这意味着DBA的角色和知识体系结构必须发生变化，DBA除了具备基础的数据库运维技能，还需要对数据领域各个产品和技术有所涉猎，包括数据库核心技术、数据库自动化运维技术、故障自愈技术、数据安全与审计、数据同步与传输和数据处理等，从而促进京东数据库架构向更全面、更合理的可持续性方向发展。

第3章“分布式存储技术”，主要介绍京东文件系统JFS及商品图片系统。

京东每年都会进行618和双11大促，大促时访问的洪峰经过业务系统的层层调用，最终都会转化为对存储系统的访问，网页丰富的商品信息展示、用户个性化的搜索结果和商品推荐，背后都需要实时地从存储系统中读取数据进行计算，用户打开的每一个页面都会转化为从多个系统中访问数据，存储系统的稳定和性能直接决定了用户购物的体验。

在开发这些存储系统的过程中，面临了很多的挑战。怎么精确、及时地发现故障，自动进行故障恢复?怎么快速地进行横向扩容、数据迁移?怎么解决系统的读写性能?每一个问题被解决的背后都有着开发人员夜以继日的奋斗。本章将会详细介绍京东存储系统的建设历程和架构。

第4章“中间件技术”，主要介绍以服务框架JSF、消息队列JMQ、缓存平台JIMDB为代表的中间件技术体系。

JMQ具有集群高可用、数据高可靠、支持集群化管理等特性。不仅考虑了高吞吐、高可用、低运维成本等方面的需求，同时还针对京东业务场景增加了重试、延时消费、归档及事务等业务方面的需求。使用Zero-Copy、日志和队列文件、组提交、内存映像文件及优化的复制协议等技术使TPS的性能比AMQ提升了近10倍。

现阶段,为配合京东异地多活整体战略,我们正在进行服务平台系统的升级改造，提升系统的灾备能力和用户体验。

回顾每次历程，不仅是对架构设计和技术实现的挑战，也是对研发人员意志力和专注力的考验，更是为我们的下一-次技术演进奠定了基础， 正所谓既是终点又是起点，我们将在实践中不断探索适合京东业务发展的技术架构之路。本章将主要介绍京东中间件在不同阶段的相关背景，解密其背后的技术选型和设计思路。

第5章“ 整体架构升级”主要介绍了“ForceBot: 全链路军演机器人”和“异地多活”两部分内容。

京东是一家以技术为成长驱动的公司，自有技术平台在不断地变化、升级，促进了各类业务的增长。能否规划出真正解决业务问题的方案，取决于是否进行了合理的架构设计，并放眼未来，迎接变革一-这就是架构的意 义。

全链路压测，是这个时期应运而生的产物。京东的业务复杂，系统庞大，每年都要经受618和双11两次大考，而随着业务量及体积的逐年增加，每次大促对系统的能力要求也就不断提高。各核心系统环环相扣，其中任何一个出现问题，就可能会影响整个链路，直接影响用户购物体验，这也导致各团队在压测方面工作量非常大。此外，直接受影响的就是系统的容量规划。系统技术团队在2016年启动了全链路压测项目，覆盖所有信息系统，基于来自全国各地的真实流量，完全在线模拟用户行为，对全链路的各个系统进行高并发验证测试。此项目牵扯到京东研发体系的所有团队，跨团队协作、跨系统协调改造等工作量非常大，挑战性可想而知。

异地多活，不仅仅是建设一个机房， 也是一个体系化的建设工程，影响着每个层级的业务状态，核心是“活”， 通过更灵活的软件来定义数据中心，机房管理、基础网络、数据库管理、持久存储、中间件、应用部署、流量接入、监控与运维保障都有新的突破，各自体现着不同的价值主张，以多元化的互联解决个性化的需求。

本章所介绍的内容，并不是研发某-些系统，而是从全局的视角来推动京东商城整体架构的升级。

第6章“机器学习技术”主要介绍京东商城基础架构中的机器学习与知识工程。

零售的变革来自于两大驱动力，即消费的改变和技术的革新，而人工智能，特别是机器学习，是当下毫无疑义的技术先锋力量。京东很早就开始了机器学习和人工智能领域的布局，在2014年9月，京东便组建了深度神经网络实验室(DNN Lab) ,后来成为基础架构部机器学习技术团队的前身。

从基础架构部的角度来看，随着GPU等硬件资源的革新，以及深度学习算法的成熟，机器学习技术已经不再是实验室的一项研究，在工业领域也有非常广泛的应用前景。

从业务角度来看，京东的业务-直在不断高速增长， 各个环节继续增加人力显得无以为继，也对运营成本提出了巨大的挑战。而且在人力增长的同时，知识和经验又无法在人与人之间快速精准地大量复制，从而导致运营的不稳定性对用户体验造成伤害。因此，我们迫切地需要用“数据”和“算法”来取代-部分的“经验” 和“人工”, 提高运营效率，改善用户体验。本章将会围绕成本、效率、体验，从应用的角度，带给你机器学习技术在零售行业的最佳实践。

机器学习技术的应用，提升了电商各环节的效率。而应用的需求和场景的不断扩展，又反过来促使了技术的进步。通过实践和迭代优化沉淀出来的计算机视觉、自然语言理解和语音能力，不仅可以服务京东内部各个部门，还可以加工形成人工智能的通用技术和服务，对外输出。本章会介绍京东在这方面的实践。

这份【京东基础架构建设之路】共有178页，本文只给大家介绍了部分知识点的内容，需要完整版内容的朋友，转发关注小编之后，后台私信小编来获取啦~~

大神评价

基础架构是京东业务的技术基石。本文的作者们，作为过去几年里推进京东基础架构变革的技术实践者，一直坚定执行京东集团“下一个十二年，只有技术”的发展路线。借《京东基础架构建设之路》，我代表所有奋战在一线的技术研发团队，将京东在基础架构技术领域这几年中的发展和创新分享给关注我们的朋友。感谢所有互联网技术从业者对我们的关注、帮助与指正。

《京东基础架构建设之路》，从底层的容器管理集群技术，到服务框架、分布式内存数据库和分布式文件存储系统，再到机器学习在京东的多场景应用和商品数据知识图谱的构建，都做了详细的介绍，向大家展现了整个系统搭建的发展历程。同时，文中也解密了京东技术研发在每年618和双11超大流量和高并发时刻的应对策略，相信会对互联网和电商行业的从业者有着不错的借鉴作用。

作为过去几年里推进京东基础架构变革的技术实践者，我们乐于把自己的经验分享给更多的基础架构从业者或感兴趣的人，技术无止境，愿我们一路相伴共创奇迹~~~~~~~~

京东上千页面搭建基石：CMS前后端分离演进史

作者

于林坤，2012年加入京东，网站移动研发部频道业务技术负责人，先后多次主导京东商城首页、频道页技改及架构升级，在高并发系统架构、前端系统架构与优化方面有丰富经验，PHPer。

京东CMS简介

CMS 即内容管理系统（ContentManagementSystem），目的是用于快速进行网站建设或者网页开发。对于京东网站部门来说，CMS 核心目的是用来快速开发和上线各种页面，诸如各种垂直频道页，访问 www.jd.com 将看到如下页面，如点击“服装城”、“家用电器”等都会跳转到一个垂直频道页；这些页面中有许多页面风格是类似的，因此很适合使用 CMS 进行快速搭建。

对于我们来说，CMS 最核心的目的就是进行数据和模板的统一管理、页面的统一发布,从而减少之前的很多重复工作。

京东 CMS 是 2014 年提出来的，经过两年多的完善，目前已经发展为一个集标准服务管理、标准组件服务和智能投放于一体的标准化导购运营系统。具有以下特点：

1. 搭建快速，统一发布，统一架构；

2. 前后端分离，后端不再负责页面渲染，只提供高性能、可复用的API；

3. 移动端页面支持；

4. 数据分析、智能投放的特点；

业务支持场景

首页、频道页、垂直页、活动页的搭建及单品页、列表页部分可维护的业务等。

从基本功能及架构来看，可以分为三个阶段：

CMS 1.0——虚拟分类系统

CMS 2.0——CMS系统

CMS 3.0——CMS-portal系统

CMS 1.0—虚拟分类系统

虚拟分类系统是一个独立的促销商品、促销文字维护系统，与具体前端业务架构脱离，哪条线接入虚拟分类，需要根据自己的业务逻辑单独开发、维护、部署自己的架构。说白了，虚拟分类系统提供一些基础数据；然后比如我要搭建一个家电频道页，则需要开发一个 Web 项目，然后调用虚拟分类系统获取数据然后进行模板渲染处理处理。因此虚拟分类系统当时只是一个基础数据维护平台，无法实现信息的共享、复用和集约化管理。这就会存在各种各样的频道页系统，导致管理混乱，性能上各有差异，出现过很多次事故。而且各系统需要独立配置，导致工作量大，占用资源多，无法快速响应业务需求。

下图是当时不同业务体系的架构：

可以看出部分频道页和活动页用的 nginx+tomcat，部分频道及垂直站用的 nginx+php-fpm，与虚拟分类联系不大，总体遵循各业务层获取虚拟分类的数据，分别独立上线、部署、维护，应用层直连 mysql，mysql 抗不住，会增加一层 memcache。

CMS 2.0—CMS系统

Cms2.0 总结了 1.0 时的不足，从节省资源、控制成本的角度考虑，把导购类的个体页面业务进行了统一，模板能复用的复用，以前虚拟分类系统的频道也需要迁移到新的系统。

我们做了以下改动

1. CMS 2.0 数据结构适合虚拟分类体系，方便新老数据兼容；

2. 升级架构，统一配置、发布流程；去 memcache 为 redis，做大量性能压测来调优 php-fpm 配置，单机 TPS 能达到 3000+； 配置定时任务，保证 redis 数据实时性；

3. 单点发布，一键预览增强采销维护数据的机动性；

4. 单机闭环，单机闭环服务设计是 CMS 整体架构的核心部分，需要展示的内容在本机获取、封装、校验；

5. 模块化、动态数据类型初期版本（CMS 3.0会细说）；

架构图

对比 1.0，新的 CMS 可以让频道页的开发周期降低 2~4 周，大大提高了业务需求的响应速度；它看起来更独立，更像一个整体，在容灾、规避风险方面做了严谨的优化；同时让采销在维护数据时，更方便、更简单。

后续由于个性化的需求越来越多，大量的频道业务需要开发人员一个一个套模板来实现，大大加大了开发人员的工作强度，之前的模板复用方式已经无法满足业务的需求，同时太简单的数据模块，需要手工来绑定数据类型也增加了开发成本，这时候需要我们必须做出改变。

CMS 3.0—CMS-portal系统

CMS 2.0 后也存在很多痛点，因此我们也想在 CMS 3.0 上解决这些问题：

1. 本质问题就是要快：快速支持、响应业务越来越多的垂直化页面改版；

2. 前后端分离，页面渲染让前端实现，解放后端让后端做高大上的事情；

3. 减轻运营人员的工作量，系统简单好用，提高导购类商品的转化率；

4. 其他系统的支撑，实现CMS的集约化管理；

5. 兼容手机端；

6. 站点管理、统一架构、容灾、高性能、水平扩容；

 

通过两版 CMS 系统的开发，我们发现 CMS 无外乎管理的是数据和模板，另外需要好的预览、一键发布支持。而传统数据管理都是静态数据类型，而我们做了动态数据类型的设计；另外我们做了模板管理中心，并抽象了模板、楼层、元件、模块的概念，从而实现更好的复用性。

统一架构

主要分为如下几部分

• CMS系统：统一管理CMS相关数据，并进行页面的生成和发布；

• 数据Worker管理中心：调用第三方服务进行数据校验（如库存不足补货），并调用CMS系统进行页面生成和发布，发布到单点服务器上；

• 单点服务器：相关页面的单机闭环实现，即CMS发布的页面会存储在这些单点服务器上；每个机房会部署一台；

• 页面定时更新Worker：定期同步单点服务器内容到静态应用服务器集群，并保存历史版本，当出现问题时可以切换回上一个版本；

• 静态应用服务器集群：静态托底实现，会存储相关的静态页面文件，当单点服务器挂了时，降级到该集群；

• 异步加载的个性化服务：有些数据不能存储到静态页，如价格/库存/推荐等数据，此时通过异步加载这些数据，实现个性化服务；

• 接入层Nginx：接入层Nginx负责请求的路由和服务的降级。

主要思路

1. 引入动态数据类型；

2. 页面模板管理中心，模板、楼层、元件、模块设计，实现可复用；

3. 使用元件实现前后端分离；

4. 动态服务和业务数据闭环；

5. 预览、一键发布，单点管理；

6. H5版直接搭建，native版 API 支持；

7. 大数据智能选品应用；

动态数据类型

所谓的动态是指能灵活扩展的，不需要上线也不需要修改数据库字段，支持自由扩展；这样做的好处是能够快速响应电商网站的日益灵活多变的促销需求。比如促销语：

目前常用的数据类型为文字链、小图文、商品池等。

操作界面：

动态数据类型数据结构：

fields 是 json 串，用于动态定义字段。

使用元件实现前后端分离

使用动态数据类型定义了数据之后，需要在模板中使用它。而在我们 CMS 系统中进行了页面、模板、楼层、元件、模块的划分。模块是某种数据类型的具体化，即有了数据的数据类型。元件是由模块和 HTML 代码段（根据模块数据进行渲染的一小段模板）组成；楼层通过一系列元件组成，而模板会引入多个楼层，当然也会引入一些 JS、CSS 等，最终通过模板渲染出相应页面。

type 是数据类型表，module 是模块表，source 是数据表，按照上面的逻辑我们是通过数据类型获取到数据模块，并同时能拿到该模块所对应的商品数据（商品池）。

 

有了这个元件之后，就可以彻底解放后端，页面渲染工作完全交由前端来开发，实现了前后端的分离。

即 CMS 研发只负责平台和基础数据（动态服务）的维护，业务人员进行模块的维护，而前端人员独立完成元件开发、模板设计、开发和发布。

动态服务

频道业务数据闭环

数据闭环，即数据的自我管理，或者说数据都在自己系统维护，不依赖与其他任何系统，去依赖化，这样得到的好处是别人抖动与我没关系。因此我们先要数据异构。

数据异构是数据闭环的第一步，将依赖系统的数据拿过来，按照自己的业务需求存储起来。频道业务需要异构的数据主要是三部分：商品基本信息、第三方数据、大数据。

数据原子化处理，数据异构的数据是原子化数据，这样未来我们可以对这些数据再加工再处理而响应变化的需求。我们有了一份原子化异构数据虽然方便处理新需求，但恰恰因为第一份数据是原子化的，那么它会很分散，前端读取时 mget 的话 性能不是很好，因此我们又做了数据聚合。

数据聚合，是将多个原子数据聚合为一个大 JSON 数据，这样前端展示只需要一次 get，当然要考虑系统架构，比如我们使用的 Redis 改造，Redis 又是单线程系统，我们需要部署更多的Redis来支持更高的并发，另外存储的值要尽可能的小。

容灾

应用层容灾

1. 数据校验，CMS在页面预览有一层严格的数据校验逻辑，比如数据格式、数据大小、敏感词等，保证页面生成100%没有问题。

   
   

   

   
   

2. 版本降级，静态页面出现问题，除了页面本身数据有问题外，潜入的js、css出现问题也会影响页面展示，这时候会版本降低为前一天的正确版本；

3. 异步服务，异步化数据容灾方面主要是监听服务的状态及响应时间；降级访问有隐藏该功能和切换服务器实现。

服务器容灾

主要是通过多机房部署，监控80端口，出现问题可以自动把流量水平切走。

智能选品

智能选品，是服务于前台的流量运营，为采销及运营人员提供运营支持，为每一次访问提供最合适和匹配的商品、品牌以及促销活动。是根据用户的行为推荐出相关的商品及活动。可以分为群体特征和个体特征。群体特征分为两部分，数据部分及规则部分。

数据部分是从大数据平台异构过来，当然这个数据是海量的，我们选择热点TOP 5000的数据来异构。

规则部分是通过京智后台创建，在审核通过后，触发MQ，通过ES 跑出对应数据，然后由频道页动态服务系统对外提供json格式的http服务。前端业务以异步的方式传递相关规则参数进行调用。

智能选品实现数据化、定制化、个性化、自动及半自动化内容运营。它可以模拟人脑选货逻辑，以运营指标为导向（GMV、订单转化率、点击量、毛利等），分区域、分用户选取最匹配的内容。目前应用于京东超市、行业频道以及618大促主会场，带来优于人工选品的转化效果，并解放采销运营人员日常繁琐的运营工作，提高了整体效率。

遇到的坑

rsync文件同步

上面的介绍过，我们的静态页面为了保持数据的一致性由单点服务器通过rsync同步静态文件到其他服务器，有时候会发现服务器负载无端的被打满。

分析问题发现如果定时任务脚本的同步未在规定时间内完成，crontab接下来的还会执行此脚本，这样就会产生相同的rsync的进程。按照这种状态，长时间就会衍生出很多个rsync进程，就会导致负载过高，甚至有些服务器会挂掉。这时候我们用到了rsync的进程锁，在目录下生成一个rsync.lock文件，当crontab执行时，rsync会判断锁文件是否存在，如果存在说明本次同步未完成，则不执行rsync。

数据一定要闭环

别人的接口抖动以及返回数据的异常，影响到前端展示对我们来说说是不能容忍的，这就需要我们针对各种情况一一校验。

CMS总结

目前通过 CMS 搭建、正在搭建以及使用 CMS API 支持的 PC 端、移动端页面约有上千个，这对 CMS 来说意义重大，随着业务需求量的越来越大，也给我们带来了新的期望。接下来，我们会从可视化编辑、数据统计分析、关键词管理、商品下架预警等方面进行相关的优化工作。