京东物流集团基础保障部架构师石继强
京东物流集团基础保障部架构师石继强从启动上云、迁移准备、迁移过程详解、案例分析、收益与问题六个方面分享了物流系统上云实战，以及远景规划。
石继强表示，京东物流之所以需要上云，除了整个京东集团上云的战略考虑外，从物流集团内部自驾的角度来看，还有三个方面的考虑，即资产-轻量化，降低成本，结构升级。
物流是一个资产非常重的行业。它还需要仓库、大量员工和物流系统。然而，如此庞大的系统却常年运行在多台物理机上。维护或损坏会带来大量的维护成本，并且随着业务的发展，必须购买更多的物理机器，这将导致资产越来越重。从整个互联网趋势来看，大家都希望自己的结构越来越轻，资产越来越轻。
二是降低成本。我们都知道云计算的特点是虚拟化和共享。如果资源在不用的时候可以回收利用，可以在使用的时候按需申请，包括计费模式，可以按小时计费，也可以按天计费。以这种方式规划集团内部资产，对于集团制定服务器预算非常有帮助。
第三，简单地将系统迁移到云端是没有意义的，简单地将系统服务器部署从私有云迁移到公有云也是没有意义的。真正的意义是在迁移的过程中，可以梳理出自己的系统架构，同时可以升级旧的、过时的、不符合当前业务发展的系统架构，包括云原生架构，这是一个很好的机会。
而这三点是京东物流启动云的动力。
确定了云迁移策略之后，下一步就是为迁移做准备，而这些准备工作必须从架构的重新设计开始。石继强表示，这是因为京东的物流系统非常复杂，不太可能照搬原来的。架构直接迁移到云端。因此，有必要对原有的物流结构进行有效梳理。
从物流系统框架图来看，在上层，京东物流有很多业务模块，包括冷链供应链、最大的客户商城等，这些支撑系统和数据平台非常复杂。此外，这些系统还包括底层业务中间件、底层基础设施数据库和缓存各种存储，整个系统庞大而复杂。
为此，在确定新的云架构时，采用VPC架构。VPC是某个BG的独立虚拟私有云区域。在这个区域中，可以划分不同的子网，根据不同的业务类型将它们放在不同的服务类型中。在不同的子网中。这样做最大的好处就是在安全上有一定的隔离性，流量也是如此。同时，由于公共子网、业务子网和数据子网也包含在新架构中，而物流系统中有很多对外提供公共服务的系统，通过VPC架构，可以将它们分开。从私人环境出发，从而保障了物流系统的安全。
定义基础架构环境后，下一步是启动迁移。这包括上线、配置CMDB、部署监控等。石继强表示，迁移前一定要做好监控，包括资源监控和性能监控，否则上线后系统会运行在不受监控的状态。公有云平台提供的相关资产和监控工具主要面向业务。客户，适合小公司，如果是大公司，在这些方面都必须有自己基于OpenAPI的定制化设计。
石继强详细介绍了京东物流迁移的流程。首先是云主机的迁移。研发通过Jone发布到应用，同时发布到私有云组和公有云组。运行到某个阶段比较稳定后，会从中间切开，相当于所有的应用实例都运行到了公众面前。云分组。基于该模型，物流研发的所有应用基本都部署在公有云上，部分系统完全放弃私有云分组设备资源，只保留在公有云分组中。
京东物流之前使用的是自研的分布式缓存服务（JIMDB）。经调查，云团队提供的缓存产品具有较大优势。云缓存是基于Redis协议的在线缓存服务，可以满足大部分业务的可用性。、可靠性和高读写要求，支持双系统热备份、容灾自动切换、弹性扩容等特性，经过双方反复磨合，在产品化的基础上，Redis定制了主从版本和物流集群 除了控制台和SDK，在用户界面层通过OpenAPI将云管理能力集成到物流系统中，实现共同治理。从 JIMDB 到 Cloud Redis 的数据迁移要求业务不能中断。双方为可持续读写开发了全增量实时同步方案。经过反复测试和实践，现已支持全自动同步，迁移效率大幅提升。
但是，数据库上云的迁移要比应用服务器的迁移困难得多。毕竟在线上完成大量数据的复制和传输是很困难的，生产期间的迁移也可能会影响到在线数据库的稳定性。对迁移时间窗口也有非常严格的要求，所以数据库的迁移计划要谨慎。经过多次演示和测试，我们采用以下两种方式进行数据迁移：
数据库原生主从模式：主要针对核心系统数据库，保证在数据库迁移过程中，如果出现问题，新旧集群可以在新旧集群之间快速切换。在这样的场景下，只有mysql的原生主从复制模式是最好的。合适的。但是为了保证私有云mysql数据库的版本和RDS数据库的版本一致，5.6和5.7版本需要开启GTID，所以这种方式只适用于少数系统。
使用自研DTS工具Data Honeycomb Dcomb：Dcomb是一个轻量级的数据处理平台，支持Join、Union、Where和自定义逻辑同步等功能，支持从MySQL到MySQL、ES、Cassandra、JDQ、Real - MQ、PostgreSQL等目标的时间数据同步，平台基于分布式架构，具有高可用和负载均衡的特点。大多数数据库都使用数据配置单元迁移到云端。
虽然数据库迁移过程困难重重，但迁移到公有云后还是有很多好处，包括故障恢复快、产品丰富、接口规范、智能监控、自动备份、快速部署等。
石继强最后表示，在上云的过程中，京东物流走在了京东集团的前列。到目前为止，90%以上的应用已经部署在公有云上，包括今年的双11.11，大量业务都在公有云上运行。以往在业务流量翻了三倍多的时候，整体运行还是比较稳定的，京东物流会在后续继续推动系统上云。上云需要架构升级，而不是简单的搬迁。未来，京东物流的愿景有四个方向，分别是容器化软件部署模式、服务器资源利用率提升、架构优化、服务治理、以及基于公有云的基础平台，进行基于流程的质量和效率平台建设。.
3 云上京东数据库的探索之路
京东云产品研发部专家架构师张成元
京东云产品研发架构服务架构师张成元谈到了京东数据库上云的探索。张成元分享了从传统运维时代到云时代的数据库云迁移的深刻理解和丰富经验云集成，云迁移的条件和时机，如何迁移上云，以及云时代DBA职业发展的思考.
为什么要将数据库放在云端？原因很明显，因为云数据库具有高弹性和可扩展性，非常适合像京东这样的电商来应对618、双11.11等购物节带来的突如其来的海量流量。
京东云数据库可提供数据自动备份保障数据高可靠性、高可用自动切换、在线扩容缩容等功能，以及一整套监控报警系统，保障用户数据安全，有效提升业务可用性，并轻松应对突然访问。流动。
对于上云的条件和时机，张成元给出了自己的理解：第一，建议创业者直接上云。企业家应该专注于他们真正想做的事情。基础设施建设往往不是创业者做的核心内容，直接上云就好了。二是现有的本地IDC服务。在这种情况下，可以考虑两个方面。一是业务发展趋于平稳，但使用的机器已经过保四年左右。保修期满后我该怎么办？二是业务不断发展，机器不断采购，但机房内难以增加新机架。
张成元总结说，上云的关键是数据库迁移。有几种情况。第一种情况是新部署的业务或可以存档历史数据的业务。数据不需要上移。这个是最简单的，直接申请新建数据库即可。第二种情况是数据需要迁移。这是一个复杂的事情，需要进行很多评估，比如数据量有多大，数据有多不可写，允许业务停止多长时间。在迁移过程中，可能会有应用跨IDC访问数据库的阶段。这个时候容易遇到的一个问题就是网络延迟。网络延迟可能只会增加一毫秒，但是在大量交互的情况下，会延迟整个业务的延迟。也会被严重放大，对业务产生比较大的影响。有些甚至需要在业务系统层面进行优化。因此，数据库上云是一个需要综合考虑的事情。
4 Istio 服务网格初学者指南
京东云产品研发部专家架构师王碧波
众所周知，lstio是业界关注度最高、生产环境落地最多的服务网格系统。王碧波从服务网格概念、Istio功能、Istio场景、Istio使用难点、京东云和Istio五个方面带来了《Istio服务网格入门指南》的课程分享。
首先，王碧波通过对比老人和孩子对数字技术的不同态度，解释了云原生的应用是什么。他认为，能够利用云弹性和丰富基础组件的技术在应用设计和实施之初就被充分采用。此类应用程序是云原生应用程序。微服务和容器是云原生技术的典型代表。
王碧波表示，微服务只是简单的将大业务划分为小单元，方便管理和维护的服务，因为功能单一的小单元比复杂的系统更容易开发、优化和调整。说到微服务，就不得不谈分割和合作。分割不仅仅是指对业务逻辑进行分割，还需要将数据、配置、工具、运行环境等从业务逻辑中分离出来。至于如何拆分，可以参考康威定律、领域驱动设计、十二要素等思路和方法。其次是与微服务的配合，包括服务之间的关系，服务所依赖的其他服务如何配合，服务与它所依赖的持久化服务如何配合，研发和上线流程如何配合，问题定位如何配合，相互之间如何配合。是比分裂更大的话题。于是，一个叫做服务治理的新概念诞生了。服务治理主要解决这些微服务如何协作的问题。
王碧波认为，服务治理的能力可以分为以下五类：流量治理、安全治理、生命周期治理、业务辅助、服务观察。流量治理包括从最基础的服务发现，到负载均衡、断路器、调用协议、策略路由、流量复制错误、信息注入、API管理等，主要解决流量管理。安全治理就是如何保证代码运行和数据配置的安全。生命周期管理包括CI和CD的机制，如何做服务部署，如何做弹性伸缩和故障恢复等。业务辅助提供了一些标准的基础能力，帮助业务实现功能逻辑。
服务治理能力的使用方式有两种，一种可以称为集成，一种是服务网格。在过去的几年里，它更多的是一种集成方式，业务需要引入很多与服务治理相关的库，与开发语言和框架紧密耦合。后来诞生了Service Mesh等技术，核心思想就是将业务模块和服务治理完全分离。这让开发者完全不用关心业务，可以直接在网络代理中做。而且，Service Mesh也可以通过直接在线配置来实现一些想要的功能，无需任何研发。当未来有新的治理要求时，
在 Service Mesh 的技术框架中，Istio 是目前最流行的技术框架。它具有架构清晰、功能齐全、实现开放等诸多优点。其中，Galley 解决了配置管理的问题，Pilot 可以做服务发现，客户端负载均衡，还可以根据 Host、Path、Header 等灵活配置路由，灵活配置容错。Mixer 的功能包括配置和调用 Quota、权限策略、请求转换逻辑等，还负责收集各种观察数据。
王碧波表示，京东云从 2018 年年中开始使用服务网格，到 2019 年底，已有 100 多个应用在服务网格中运行。为了保证稳定性，京东云建立了比较完善的测试和质量评估体系。每个版本的 Istio 都放在测试框架中持续运行，以便及时发现问题。此外，京东云团队中还有很多网络和服务治理方面的专家。选好版本后，假设以后版本有严重问题，这些专家有能力修改。在用户体验方面，京东云也做了大量的化简工作。同时，还开发了大量的在线运维工具。此外，内部安全系统、DevOps、和观察相结合，使团队更容易应用网格的各种功能。最后，京东云在各个团队的合作和接入上投入了大量精力。服务网格有很多新概念和新用法，与原来的方法有很大不同，需要大量的交流和讨论。
下图是最终效果的示意图：底层的devops系统解决了资源管理、应用管理、日志权限等一些事情，服务网格解决了服务发现、服务调用、安全治理等问题。调用链，最终让每个业务变得灵活。灰度、伸缩、简化部署流程、优化流量管理、获得原生安全能力和更好的观察能力。
通过一年多的内部线上运维，京东云积累了丰富的线上运维经验。京东云将这些能力和经验商业化，推出了云服务网格产品。欢迎您试用。
5 云原生下的 DevOps 实践
京东云产品研发部架构师景良良
景良良从云原生&DevOps、云原生下的DevOps发展与演进、京东云DevOps案例三个方面进行了阐述。
云原生&DevOps：云原生贯穿当前软件的整个研发周期云集成，重塑整个软件研发生命周期。是云原生提出的概念。它是思想的集合，包括（DevOps、持续交付、微服务、容器）。可以说，云原生既包括技术（微服务、容器等基础设施），也包括管理（DevOps，持续交付），例如康威定律、重组等。云原生也可以说是一个集合一系列云技术和企业管理方法。
DevOps 也是一个比较抽象的东西。DevOps（开发和运营的结合）是一组用于促进开发（应用程序/软件工程）、技术运营和质量保证（QA）部门沟通、协作和集成的流程、方法和系统的统称。每个企业环境不一样，角度不一样，DevOps解决的问题也不一样。
云原生中 DevOps 的演进：最明显的就是基础设施的变化。在云原生之前，我们的服务是这样的。底层是传统的IDC。基于机房、硬件、网络等，服务应用一般部署在物理机上，或者基于物理机虚拟化。在虚拟机中。研发运维不仅要关注业务，还要关注硬件、网络等资源。云原生时代，还是云时代。我们只需要关注应用，业务层。底层资源云厂商已经帮我们解决了。我们可以把更多的时间花在业务研发上。更加注重业务研发。这是基础设施的变化。
第二部分是软件交付方式的变化。随着技术的不断发展，软件的交付方式也在不断发展。为了最大限度地利用资源，此时软件会发布到虚拟机上。为了提高发布效率，发布方式也变成了脚本化。随着资源的不断增加和虚拟化技术的发展，企业逐渐开始构建自己的私有云。随着业务的发展，出版方式也变成了自动化出版。我们都知道，随着容器技术的成熟，容器已经成为应用发布和交付的标准。随着公有云的发展，很多企业已经开始拥抱公有云来提高企业的效率和成本，所以企业内部的发布方式变成了容器和包并存的方式。企业的基础设施基本上是混合云模式。发布方式在自动化的基础上开始智能化，弹性伸缩和故障自愈越来越受到推崇。
京东云DevOps案例：第三部分，井亮亮分享了京东云构建DevOps的经验。
多年来，很多企业都将多云作为企业战略，鸡蛋不是放在一个篮子里，如何支撑整个多云战略挑战？通过探索和实践，我们证明了配置管理CMDB是企业内部实施DevOps的基础，决定了整个DevOps的成败。
京东云的CMDB模型以应用为核心，对整个资源层级进行管控，将整个业务的模型服务号以的形式表达。CMDB 的准确性对于系统如何使用这些数据非常重要。整个CMDB模型的构建并不完美。有以下三点可供参考： 一是提供最简单的输入接口，方便研发、测试、运维实现整个数据。此外，还需要提供API来允许相关的业务系统。关联数据很容易。最后，通过Agent收集的方式，将部分机器中的数据主动收集上报给Agent。保证cmdb数据的准确性。
二是客户资源的挑战。根据devops中文社区2019年的统计报告显示，超过50%的企业管理着100多台机器。在这么多机器上，会给客户端带来一系列挑战，可能会面临机器代理多、各种资源限制、生存守护、部署后更新、升级、维护发布等问题。基于这个挑战，我们构建了一个超级代理。根据业务需求，针对不同的业务代理。
三是持续交付。早期，我们的方法都是代码包的形式。近年来，随着传统基础设施从自建或托管IDC机房向公有云和混合云转变；软件架构也在向微服务靠拢，部署Docker镜像的方式也从原来的包部署方式转变为Docker镜像方式。Docker镜像形成了应用分发和交付的标准，可以将应用与底层运行环境解耦；因此，在持续集成方面，不仅需要支持代码包的构建，还需要支持镜像方式，但最终所有构建产品都需要以版本化的方式存储在产品库中。一方面，除了构建，持续集成还通过管道将静态代码检查和安全漏洞检查结合起来，提高代码质量和安全性。关于构造语言，因为所有的构造都在镜像中，所以需要提供各种语言的编译镜像。当然，用户可以根据自己的需要定制一些特殊的编译镜像；对于docker的搭建，我们会提供统一的运行镜像，这样可以避免一些OS环境不一致，或者操作系统版本不一致的情况。这是 CI 方面。关于构造语言，因为所有的构造都在镜像中，所以需要提供各种语言的编译镜像。当然，用户可以根据自己的需要定制一些特殊的编译镜像；对于docker的搭建，我们会提供统一的运行镜像，这样可以避免一些OS环境不一致，或者操作系统版本不一致的情况。这是 CI 方面。关于构造语言，因为所有的构造都在镜像中，所以需要提供各种语言的编译镜像。当然，用户可以根据自己的需要定制一些特殊的编译镜像；对于docker的搭建，我们会提供统一的运行镜像，这样可以避免一些OS环境不一致，或者操作系统版本不一致的情况。这是 CI 方面。或者操作系统版本不一致。这是 CI 方面。或者操作系统版本不一致。这是 CI 方面。
部署有两个方面，包部署和容器发布。整个CMDB都有一个包发布的商业模式。商业模式是向上构建的，资源模型是向下构建的。为整个部署设置一些策略后，就可以进行发布了。注意容器释放的两点。第一点是在容器中放置一些局部计算应用，从而存储和展示整个容器的日志。第二点是打通联想系统。另外，每个企业的需求不同，弹性伸缩也不同，可以根据业务场景进行伸缩或伸缩。复杂的业务场景支持编排和部署，其特点是可以实现暂停设置、并发设置、自动重试、故障阈值，一键回滚。同时，故障自动处理机制可实现实时告警检测、预诊断分析、故障自动处理与恢复，打通周边系统，实现全流程闭环。下面是 DevOps 功能的全貌。
最后，景亮亮分享了如何在企业中实施DevOps。第一步是想清楚你为什么要改变，找出你的痛点是什么，哪里出了问题。如何获得支持。第二步，分析现状。有两种方法。一是根据现有的DevOps能力成熟度模型，自查DevOps哪个阶段需要改进，二是找咨询公司。找一些外部顾问深入企业团队，评估哪些领域需要改进。第三步，分析现状来设计要解决的问题，是购买还是基于开源，还是自己开发，根据企业的现状设计一个DevOps模型。最后也是最难的一点是推广，并且在设计工具时必须考虑兼容性。在大家都不愿意改变的情况下，先进行试点，产生实质性价值后再进行大规模复制。
看了这么多，有没有收获很多？想了解更多沙龙信息，请点击“阅读”进入京东云开发者中心观看沙龙视频~