近日，京东云联合英特尔举办“破局丨云原生时代IT基础设施变革”技术沙龙，来自京东的4位技术大咖分别就混合多云基础发展趋势、京东在大规模集群管理的遇到的问题及解决方式、京东DevOps破局以及混合多云下PaaS组件接入的挑战及难点等话题展开分享，揭秘混合多云基础设施的发展与变革，为企业数字化转型提供借鉴意义。

云原生的出现，带来了一种新的建设思路和开发模式。从技术特征来看，云原生所具备极致的弹性能力、服务自治故障自愈能力、大规模可复制能力，极大发挥了云的优势，提升业务应用的迭代速度，加速数字基础设施升级。而今越来越多的企业愿意技术架构向“云原生”演进，Gartner报告就曾预测到2022 年，将有75%的全球化企业将在生产中使用云原生的容器化应用。

随着云原生的持续升温，它跨过了概念阶段，逐渐的进入到了应用落地的快速发展期，越来越多的企业意识到仅改变IT基础设施已经无法满足当前业务需求，也难以快速应对多方面的挑战，如何高效管理多种基础设施？如何在应用开发及业务创新层面实现运营效率提升？本期沙龙与开发者进行了深入的互动和技术交流。下文是由四位老师演讲内容整理而成：

1

混合多云基础设施的未来

京东云事业群高级总监 何小锋

IT基础设施指用于支持政府、企业级特殊需求个体的IT环境所需要的一系列IT硬件资源及基础软件的集合，主要包括计算资源、存储资源、网络资源、实现虚拟化及管理服务器的底层软件。按照部署环境的不同，IT基础设施可划分为传统IT基础设施和云基础设施。部署在非云环境下的基础设施为传统IT基础设施，部署在云计算环境下成为云基础设施，其中云基础设施可以继续分为公有云基础设施和私有云基础设施。

企业数字化转型的需求、云计算技术的不断成熟并在各个行业的持续渗透，大数据、人工智能、物联网等技术持续创新也给云计算服务带来更大的市场发展空间，《Frost&Sullivan》研究报告曾预测：中国的云基础设施市场的年复合增长速度将达到 37.0%，并在 2023 年达到 4935.9亿元的市场规模。

《Frost&Sullivan》研究报告

混合多云发展趋势

伴随着IT基础设施的高速增长，混合多云的理念持续深入，依托多云管理、云网协同、安全能力的提升，越来越多的企业愿意采用混合云部署方式。

从我国政策方面看，“十四五”规划和2035年远景目标纲要草案中将“加快数字发展，建设数字中国”作为独立篇章，描绘了未来五年数字中国建设的新蓝图。具体到云计算产业，规划纲要草案指出，要加快推进云操作系统迭代升级，推动超大规模分布式存储、弹性计算、数据虚拟隔离等技术创新，提高云安全水平，并以混合云为重点培育行业解决方案、系统集成、运维管理等云服务产业。

从行业的发展趋势上看，在全球范围内，混合云已经成为企业用云的主要形式。从国内市场来看，企业应用混合云的比例仍处于较低水平，但有很大潜力和成长空间。据《Flexera：2020年云计算报告》调查显示，86%的企业正在使用多个公有云服务；60%的企业报告使用多个私有云；53%的企业同时使用多种公有云和私有云的混合。

Flexera：2020年云计算报告

企业在使用混合云的过程中也面临挑战，一方面，多云架构的复杂性带来多云管理的复杂性。

另一方面，多云管理工具对于经济高效地管理云资源以及确保强大的治理和安全性至关重要，然而，只有三分之一的组织在利用多云管理工具。

云原生混合多云管理平台-京东云云舰

随着数字化时代的到来，混合云已经成了兵家必争之地，头部云厂商持续在混合云加大投入。企业在选择混合云厂商会面临三个问题：

1、不同的云厂商提供过的服务能力、PaaS不一致

2、容易被公有云厂商锁定，成本高，不能方便的进行跨云迁移

3、没有一致的用户体验，对开发者不友好，交付效率不高。

云原生作为云计算下一代技术基础，已成为事实标准，凭借其极致的弹性能力、服务自治故障自愈能力、大规模可复制能力、异构资源标准化的架构特性可以有效解决上述面临的三个问题，并快速帮助企业实现数字化转型。

京东是云原生最早的实践者和受益者之一。早在2014年，京东就率先将Docker容器技术大规模应用至生产环境。2016年成功从OpenStack切换到JDOS 2.0的Kubernetes技术栈，打造了完整高效的PaaS平台。基于内部实践和技术积累，京东云构建了云原生混合多云管理平台——京东云云舰。云舰提供一致的容器运行环境(COS) 、PaaS能力(T-PaaS)和应用开发运行平台(DevOps) 。基于京东多年云原生的大规模容器、PaaS、DevOps和微服务实践，帮助客户构建云计算场景，在异构基础设施上提供一致的能力，简化跨云迁移，可以真正做到“上的去，下的来”。

2

京东零售云原生介绍与案例

京东零售Kubernetes负责人  周光

京东云原生平台演进之路

京东的容器建设始于2014年，作为国内最早大规模在生产环境进行容器化部署的公司之一，京东的云原生平台JDOS演进也经历了几个阶段，2014年基于Openstack的JDOS1.0上线，实现了业务隔离；2015年经历了618和11.11两次大促的考验，具备了秒级伸缩功能；2016年完备了镜像中心和监控体系并持续对网络和存储层进行优化；2017年拥抱开源，大规模使用Kubernetes，形成了以kubernetes为基础的应用容器平台JDOS 2.0；2018年上线阿基米德调度体系，基于应用特性做持续优化；从2019年开始，我们的云原生平台开始支持大数据相关的业务，在离线计算、在线计算都有一些成果；2020年在跨集群、跨机房等这些保障方面做了一些工作。

目前，业务层面来看，目前京东商城核心交易都跑在云原生平台上；集团内的供应链、物流等业务也都在使用JDOS平台；技术层面来看，京东自己的基础中间件包括数据库业务、分布式缓存、消息系统等也全部使用容器化在管理；一些计算系统相关的，例如离线计算、AI算力相关的系统也正在全面拥抱容器化。

京东如何用云原生关键技术实践赋能技术团队

先说一下大家都比较关注的流水线发布。理想的状态，应用部署在测试环节通过的情况下就可以直接上线，但真实的情况是面对京东非常复杂的核心系统，上线步骤非常多，测试环境通过通过了部署到生产环境还会不会出现意想不到的问题，需要预热的缓存不预热会不会出现什么问题，这些情况如果人工验证需要花费大量的人力成本，所以我们必须基于容器构建高效的流水线。那么我们现在的流水线发布具备以下3个特点：

1、流水线仅需简单配置即可自动化完成摘量、更新、校验、自动化测试、挂量等操作，达到快速部署、敏捷试错。

2、支持自定义流水线、自定义流水线节点，且流水线在设计时增加外部接入点，方便将各研发团队的能力集成到流水线中，确保产品的能够高可用、可持续、高质量且安全的快速交付价值。

3、支持多种项目管理系统的对接集成，通过API接口调用、JSF接口形式以及JMQ消息的形式完成对接，贯穿项目需求、任务、人员同持续集成环节的信息流，完整的管理整个项目生命周期。

再谈一下大家比较关注的中间件部署。京东的基础服务全部基于微服务来做，目前也在大规模使用service mesh，基于容器平台我们可以快速完成单元化部署，在不同城市的机房可以分发流量到不同的单元，在大促的时候，这种方式可以保障系统的稳定和快速切换。

最后说一下京东的阿基米德调度。京东有大量的服务器资源，以往在大促前各个业务主要靠新增机器来应对高峰的瞬时流量，应用业务系统资源申请量和使用量之间差距巨大，同时，资源使用呈现明显的高峰低谷，不同的机器的资源使用率差距较大。而且也面临着资源碎片和时空不均的情况。阿基米德调度是怎么解决这些问题的呢？

1、基于预测的智能调度：利用机器学习、深度学习算法，对应用的资源使用情况进行画像统计，并能对应用的未来资源使用情况进行预测，将在线与离线应用合理的进行混合调度部署。

2、监控指标的精准驱逐与碎片整理：由于不同批次采购的服务器规格性能不同，通过批处理任务进行统一填充式调度，以达到资源碎片的填充利用和资源的时空复用的效果。

3、调度器仿真系统及回放功能：通过模拟器+线上数据回放，对调度请求进行仿真模拟，形成新的数据建模，并优化调度方案，为智能调度提供更优方案。

京东通过阿基米德平台的高效调度实现灵活高效的IT基础设施，提升行业资源效率，降低IT成本，将其打造成为行业的公共基础设施服务，实现行业共享的价值最大化。

京东如何用云原生关键技术实践赋能技术团队

最后我们通过一个案例，来看下基于云原生平台，京东是怎么部署实时计算和离线计算的。

京东的实时计算体量很大，目前都是部署在云原生平台上来做，我们现在要保证的是实时计算系统在平台上的稳定性，这是非常难的一点，因为实时计算系统和一般的应用不同，举例来说，当机器故障、磁盘有问题、CPU负载等状态时，容器会受到影响，部署在容器上的实时计算就会变慢，这个时候就需要我们介入去分析这个影响。比如CPU达到一定的异常负载，就应该驱除这种负载，但是对驱除要有一个分析，比如在线的应用，因为可以实时感知到流量的变化去进行自动调动，就不需要驱逐。而且驱逐要分层，实时计算可能有社会级、公司级、部门级，我们研究不同的级别，从低往高进行批量适当的分步骤的进行驱逐，以达到容器运行的稳定。这是容器和实时计算结合的一个难点。

接下来再说离线计算，我们先看一张图。

左边这种图显示，在凌晨的时候，因为要计算前一天的各种数据各种报表，离线系统的CPU使用率会飙高。而右边的图展示了商城交易业务因为在凌晨使用的人少，所以CPU使用率极低。那么是否可以通过容器进行调度，把凌晨闲置的交易业务的CPU资源调度起来支持离线计算系统，保证离线计算不受影响支持业务？

在把这种美好的想法落地的时候还是遇到了一些坑，第一个问题就是磁盘，当时资源调度的主要是批处理的业务，这种任务对磁盘的容量要求不太大，但是对磁盘I/O要求很高，这就挤占了原本跑在上边的在线敏感业务，所以我们按照容器级别对I/O进行了控制，通过对不同业务的I/O进行控制，保证在不影响在线业务的情况下调配资源给迁移过来的离线任务，增加混部密度。

第二个问题是CPU的分级调度，虽然在系统层面我们做了一些控制但是先计算调度过来还是对系统有冲击，比如CPU利用率会飙升，我们通过降低离线的任务的CPU权重，实现Job调度类，来管理离线业务。如图所示进行离线任务的分级和控制，可以在在线业务服务质量的不下降的前提下，提高整机CPU利用率，达到降本增效的目的。

最后一块是网络，调度过程中有可能引起网络的堵塞和抖动影响到在线业务。我们通过两个方式来解决这个问题，一个是业务分级，在容器内对业务打标，保证在线业务的高优先级在node节点优先转发并确保交换机的转发策略一致；第二是业务限流，对同一优先级pod总流量限流和针对单一pod限流来解决网络带来的问题。

最后总结一下，经过7年的技术演进，我们支撑了京东零售百万级的容器部署、调度和稳定性的挑战，帮助业务技术团队具备编译构建、流水线发布、中间件部署、serverless等关键技术实践，很好地支撑了业务的发展。同时也积极探索在大数据和AI系统的云原生化，为降本增效做出了很好的实践。

3

DevOps高效研发破局之道 

京东云事业群总监  贺玉芝

数字化时代，政企客户软件交付普遍会面临人员能力不足、工程管理规范混乱、工具选择和维护成本高等普遍困境。那么在这种困境下，企业如何实现上下同域？如何敏捷转型？如何按需交付实现更快的价值？质量效率和稳定性到底如何更好的提升？这是政企客户面临的一个巨大难题。接下来将通过几个方面来诠释京东如何探索解决这些问题的。

京东DevOps高效研发破局之道

上图是京东高效交付的黄金三角链路，我们提供一站式覆盖软件交付的整个全生命周期的DevOps工具平台，基于工具平台提供的DevOps能力可以支撑京东万人研发去建机制，组流程，落实践，并且效能度量又可以利用数据反向驱动效能提升，实现效能的闭环。这个黄金三角链路目前支撑京东近两万研发的管理和工程实践，目前在系统里承载的项目数和应用数达到三万，单日部署九千多次，这帮助我们实现了更快更可靠，端到端可持续的交付价值。

上图是DevOps落地全景图，从过程改进角度看，我们的平台功能模块覆盖需求管理、研发过程管理、敏捷开发、测试、发布、运维运营及整个软件交付生命周期管理。在此功能之上，需求统一收口、透明可视化流程流转、需求透明流转和跟踪以及研发过程管理如何灵活的排兵布阵，均是能够从源头保证资源灵活调整，实现资源最大化。

从工程实践角度看，京东在开发、测试和运维也有着丰富的最佳实践落地，比如需求和代码、流水线、发布、测试、上线等实现双向的关联，或者是代码提交后自动驱动触发持续集成，持续部署、持续交付，同时京东也在持续关注整个研发交付周期里的交付效率和交付能力，形成全集团的统一标准。

支撑万人研发的管理和工程实践

当业务复杂到一定程度，协作的团队越来越多，能否保证拉通需求和研发，能否保证在敏捷研发的体系下协同成为了最大的难题。京东是如何做的呢？

如上图所示，协同的最顶层是战略协同，那么从战略开始就需要通过OKR层层分解，用项目支撑OKR落地。同时，也要从组织的角度自上而下的关注业务的价值，做统一的产品需求规划，包括业务需求、用户需求、产品需求等，也要做层层拆分，将不同的子需求受理到不同的研发团队支撑它流转、迭代、发布上线、度量、运营等，保证需求和研发打通，形成业务闭环。

从组织协同角度，需求流转时，支持跨企业跨部门跨项目跨产品流转，在纵向可以看到通过项目去管理项目的范围、进度、成本、质量、风险，实现敏态&稳态项目管理的双模，从工程实践角度，去双向关联代码，实现所有过程的流转都是可追溯的，最后以一个全局的视角去关注用户价值以及研发整个链路中的各个环节。

通过这套机制，可以在大型研发组织中打破“组织烟囱”，确保需求在研发流程中正常流转，让研发团队目标对齐，协同为用户提供价值。

支撑万人研发的效能度量体系

数字化转型过程中，研发效能成为企业核心竞争力。京东的研发效能度量工具，目标是希望高效交付用户价值，让研发效能可量化、可分析、可提升。所以在流程方面，首先定义了核心效能指标，通过结果指标评估结果，通过过程指标指导改进，同时建立了价值流交付模型，通过度量平台采集DevOps工具网络的各类数据，形成度量报表。基于效能分析模型逐层下钻，找到影响效率或质量的根因，最终去量化驱动改进。

上图是效能度量平台的逻辑架构，总体分为四层。接入层支持JDBC等不同方式的数据接入；存储层对维度表、汇总表进行汇聚，形成各项指标；在统计分析层做实时处理、离线处理或者智能分析、效能告警，最终在展现层为不同的用户，包括管理者、最高决策层、业务负责人，最终提供一个全链路、多层级、多角色、多维度的效能报表。

上图是效能度量指标全景图，京东从业务价值、交付成本、客户满意度三点出发的，持续关注交付效率、交付质量和交付能力。左边的指标体系及右边的最佳实践是相辅相成的，指标的提升可以通过最佳实践来辅助效能做提升。除了度量指标全景图外，研发效能度量平台多层级仪表盘支持多层级，同时还提供了自定义报表的功能，也就是大家熟知的BI报表的能力。

针对不同层级关心的指标不同，我们也设置了个性化的仪表盘帮助他们各取所需，提升最核心的指标。

京东DevOps一体化平台

根据Forester报告，42%的企业的痛点是需要整合企业内部既有的4到10个DevOps工具；而根据Gartner的报告，70%的企业需要用业务价值流驱动实现更快交付。京东DevOps平台也经历了从信息化过渡到平台化演进到数智化的阶段。

上图是DevOps平台的整体架构，这里引入了DDD建模思想。在底层我们把通用的支撑领域下沉，成为平台基础组件，实现业务领域的所有的组件都复用基础组件；核心业务领域我们采用的是前后端分离的架构，在前端我们采用微前端的架构，后端我们采用微服务的架构。

基于这种架构，让DevOps平台具备了完备的可配置性和可扩展性：平台底座基于微前端架构，通过组件化技术，支持用户自研组件的注册、热插拔，能方便、快捷地集成私有化用户的自研系统；可二次开发功能扩展点，满足个性化业务功能需求。流水线具有丰富的原子能力，如编译、部署、测试以及常用工具（sh/mail等），并支持用户自定义原子能力。

最后总结一下，京东云DevOps平台-行云统一支撑京东集团内部，包含京东零售/科技 /物流/保险等多种业态；通过京东高效交付的黄金三角链路，帮助企业内部拉通研发和需求，让大规模协同成为可能；通过建立科学的度量体系，帮助团队识别研发瓶颈，解决研发效能的痛点；而具备Open API、插件生态、组件化能力和多层级选线管控的DevOps数智化基础设施是支撑这一切的基石。

4

基于云原生技术打造的混合多云统一PaaS能力

京东云事业群总监  王碧波

随着越来越多的企业拥抱云原生，混合多云开始成为主流场景，同时也是非常复杂的场景。当PaaS遇到混合多云时，会出现一些痛点，总结起来3大类：PaaS能力不足、多云PaaS能力不统一、PaaS能力不够云原生。为了解决这些痛点，一般会采用五种解决方案，这些方案各有优劣，京东采用的是“云原生平台+PaaS市场”的方案。

构建云舰TPaaS技术中台一站式解决混合多云挑战

采用“云原生平台+PaaS市场”的方法，可以在各种私有云、多云、混合云环境为客户提供一致的数据库和中间件等各类基础技术组件能力，我们将其取名为云舰-TPaaS。

因为京东PaaS能力非常多，将这些PaaS能力以统一的方式提供出来，就要选择非常好的基础、非常统一的方式来做。在这个基础上将PaaS运维运行需要的标准能力，以统一的方式接入到市场里面，接入后PaaS能力可以以非常灵活的方式按需使用。

云舰-TPaaS支持各种主流公有云、私有云、物理机、虚拟机，支持各种网络模型、存储模型，支持多云多集群的管理。既支持创建京东的K8S集群，也可以基于各家云平台去创建京东K8S集群；还可以对接各家云平台的API接口，实现集群自动创建自动伸缩，同时也支持纳管客户已有的标准集群。背后的实现是基于社区的Cluster API来实现的，它通过提供声明式API和工具，来简化集群的部署和整个生命周期的管理。

京东基于这套工具来实现扩展的技术架构的支持。它定义集群、机器这样一些标准的模型，针对标准模型实现标准控制器，用这些控制器来根据声明的集群声明，自动将集群构建出来。实现里面每一种云的基础设施都可以有自己的描述，然后针对定义的描述可以实现相应云基础设施的协同。

随后，王碧波老师分享了五个TPaaS组件示例，PostgreSQL、Redis、ChubaoFS、SGM、MPaaS，通过组件的特性展示了基于云舰是如何通过大量云原生TPaaS组件统一混合多云场景的PaaS能力。

云舰TPaaS如何赋能业务场景

先说云舰TPaaS如何解决京东内部的多场景统一架构场景的。京东有庞大的内部系统，需要基于物理基础设施部署PaaS能力；又有公有云产品，需要基于IaaS环境之上的PaaS能力；同时各类京东产品的对外赋能又需要将PaaS部署在客户各种已有基础设施之上。这些不同场景在之前应用的不同的技术栈，导致研发、运维工作无法对齐。通过我们把PaaS能力搬到标准k8s之上，我们这三块的需求实现多场景的统一架构，在这三套里面都是基于同一套平台去运行同样的基础的组件，通过这种方式实现技术架构的统一以及研发成本的节约，也保证了运行的稳定性，降低了交付难度。

 

再来看一个增强私有云能力的案例。客户在自有的私有云上面建设了Kubernetes集群，但部署的数据库和中间件都是开源的组件，没有专业的技术人员能深入了解所使用的开源组件，导致他们的数据库、中间件在稳定性上一直存在问题，同时也缺乏系统的管理能力。客户接入云舰平台TpaaS后，利用TpaaS数据库和中间件的组件，使它整套系统的稳定性、性能、管控能力有了很大的提升，可以更高性能、更稳定的支撑新的业务。

最后再看一个多云统一平台的案例。客户原来只使用一家公有云，随着业务的扩张，原有公有云服务商从产品到服务再到价格都出现了很多问题。但是因为客户使用了这家公有云特有的PaaS产品，导致切换云服务商或者采用第二家云服务商非常困难，从而也无法进行成本优化。为了解决多云的问题，在部署了云舰TPaaS后，将新业务切换到在公有云上使用云舰TPaaS，这样就在多个公有云上有了一套统一的容器PaaS和DevOps能力，解绑了单一公有云的限制。后续也会在私有云上也接入云舰平台TpaaS，真正实现了混合多云的统一能力。

总之，在混合多云的场景里，原有的PaaS使用方式有很多问题，我们选择了Kubernetes作为一个新的云时代的操作系统的底座，把我们所有的PaaS能力搬到Kubernetes上，然后以云原生Kubernetes的技术和理念去重新实现整套PaaS的能力，从而使我们整套PaaS能力既可以去补充客户现有的IaaS能力的不足，也可以帮助客户把业务实现混合多云的架构，还可以帮助客户的业务能力在他的客户那里做私有化的部署。

数智化的浪潮已来临，我们每个人身处其中。从生产、经贸、研发再到生活的方方面面，京东云正在全方位赋能产业，创造更大价值。未来，京东云还将开放哪些技术和能力，帮助传统企业抓住转型的机遇，让我们拭目以待。

点击【阅读原文】查看技术沙龙视频回放，回复关键词“PPT210327”获取演讲 PPT和视频资料。