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