技术沙龙 | 云时代下的架构演进—企业云及云原生技术落地实践

云改变了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职业发展思考四个方面为你们分享了他对数据库上云的深入理解和丰富经验。

为何要把数据库上云？缘由是显而易见的，由于云数据库具备高度的弹性和扩展性，而这些对于京东这样的电商应对例如61八、双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模型。最后也是最难的一点就是推广，在设计工具时必定要考虑到兼容性。在你们不肯意改变的状况下，先进行试点，实质产生价值后进行规模化复制。

看了这么多，你们有没有收获满满呢，若是您想了解更多关于沙龙的相关讯息，请点击“阅读”，进入京东云开发者中心查看沙龙视频~