通常谈到大数据，想到的是大数据平台、Hadoop生态或者数据湖技术，关注于大数据存储、大数据计算方向上的技术发展与应用；谈到云原生，想到的是微服务架构、容器化或者SRE（Site Reliability Engineer）运维范畴。大数据产品大多直接部署在物理机上，少有人应用云原生技术在大数据产品，这里分成4个部分来谈谈大数据云原生，第一部分是云原生的发展历程，第二部分是云原生的核心技术，第三部分是大数据的发展历程，第四部分介绍京东零售的架构实践；最后是展望这个交叉领域的发展方向。
一、云原生发展历程
1、云原生概念
对于物理世界的描述，美国哈佛大学的研究小组提出了资源三角形:没有物质，什么也不存在;没有能量，什么也不会发生;没有信息，什么都没有意义。人类改造世界创造生产力的过程是对这三大资源的不断挖掘利用，首先是物质资源，由此产生了手工生产力;其后是能源资源的开发，诞生了机器生产力;随着人类对物理世界认识的不断深入，信息成为新的增长点，衍生出不可思议的数据生产力。
这里我们以水、电、计算为例，代表三个时代的资源。在信息时代，我们已经从大型机、小型机、x86服务器等物理机发展到云计算，相对于物理机的分散固定的资源，云计算可以提供即插即用、极致弹性的计算存储资源。在云计算基础上，应用从搬迁上云逐步转变为基于云计算基础设施设计、发展、演进的云原生应用。
云原生带来了两个转变：一是开发方式的改变，原来应用开发从开发、编译、测试、发布、运维有一整套的技术流程规范，云原生是一种新的技术规范体系；更是一种架构设计的转变，原来应用想着部署在具体的一台物理机器上，从设计开始，就要考虑到系统是运行在一个可扩展、弹性、自动化管理的云端。
比如业务要申请一套数据系统，一定要申请几台64核128G的机器，为什么要申请这些资源？因为预计业务发展3年后可能会用到。如果使用云原生的思维，就不会这样去做。业务开始只申请一个小规格的数据系统，随着业务发展的需要，弹性扩展系统副本数或者规格大小。这是一种思维理念的转变，越是有经验的越难以转变。
2、云原生发展历程
云原生的发展历程不得不提两个组织，一个是Pivotal，大家可能不太熟悉，它是Java的Spring框架和Greenplum数据库的主要技术贡献者，云原生也是由Pivotal公司于2013年首次提出。另一个组织是CNCF云原生计算基金会（Cloud Native Computing Foundation），2105年成立到2018年重新定义云原生：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
同时Gartner也预测云原生平台将成为95%以上的新数字化计划的基础。
3、云原生技术产品发展
这里列出来的云原生技术：微服务、容器、服务网格、Serverless都出现在CNCF和Pivotal的云原生定义中，都有对应的代表产品。2013年Docker的出现让容器技术得到普及，K8s从发布到容器编排框架大战中胜出，如今以绝对的市场占有率推动了云计算基于K8s的容器PaaS化。2018年发布的Istio和Knative也推进了服务网格和Serverless技术的落地。最后Kubevela产品v1.0版本的开源，代表了OAM（Open Application Model）开放应用模型的一种实践，将复杂应用的部署和运维动作进行标准化交付；京东这次分享的数据云原生实践也有借鉴OAM的思路。
二、云原生核心技术
1、微服务
微服务是一种云原生架构方法，在单个应用中包含众多松散耦合而且可单独部署的小型组件或服务。这里推演一下微服务的演进过程。软件应用一开始都是单体应用，21世纪初，各行业的单个系统应用都有几百人甚至几千人去开发，整个产品的开发、测试、运维迭代的周期很长，随着功能的不断扩展、用户的不断增长等问题，单体架构难以适应。在这种情况下，面向服务体系架构SOA（Service Oriented Architecture）应运而生，以松耦合的方式，将应用系统进行拆分，通过定义接口实现服务集成。同时企业服务总线ESB（Enterprise Service Bus）为服务整合提供了解决方案，达到数据集成、应用集成、流程集成和门户集成，提高了系统灵活性和可扩展性。
SOA架构仍然有几个问题：缺乏有效的服务治理，服务资产混杂不清；业务支撑响应慢，无法模块化实时更新；创新业务难以快速支撑等。为此，提出了微服务架构，系统拆分为多个微服务，每个微服务独立部署运行，每个微服务只需要完成本身的任务。微服务体系架构的优势主要体现在：分布式、高可用、弹性可伸缩、技术异构、与组织结构匹配等方面。技术异构可以理解为每个微服务都是独立的，开发技术栈不受系统其它服务限制，这样每个服务可以选择合适的开发语言来开发，底层服务可以用c/c++/go，应用服务可以用java/python等。组织的结构也可以划分为一个个小的团队，微服务架构与组织结构相匹配，避免出现大的代码库，小团队的合作沟通效率更高。微服务代表性的框架有：Spring Cloud、Dubbo、JSF，JSF是京东内部的高性能服务框架，还有K8s平台上的Service Mesh，云原生的服务治理框架。
2、容器技术
3、服务网格
服务网格是微服务架构的更进一步升级，核心目的是实现网络通信与业务逻辑的分离，使得开发人员更加专注在业务的实现上。
看一下服务网格的演化过程，两个服务之间的通信，TCP协议的实现可以解决网络传输中的通用流量控制问题，将网络传输处理逻辑从业务逻辑中分离出来，成为操作系统网络层的一部分。微服务1.0时代，服务发现、负载均衡、安全通信等问题暴露出来，在应用中用代码可以解决，但是这些非功能性代码的编写与维护占用太多的时间。微服务2.0时代，一批可复用的类库和框架：Spring Cloud、Apache Dubbo等应运而生，带来了质量和效率上的大幅提升；但是这些框架本身复杂度高，上手有成本，与框架绑定限制了技术栈的选择，框架的升级牵连应用的编译升级。
下一步希望把分布式服务框架功能如同TCP协议一样提取到底层平台中，让业务开发工程师专注于业务逻辑。想在操作系统的网络层加入这些功能并不可行，尝试找到的解决方案是抽象为一组代理，提出sidecar的概念，在应用程序之外作为辅助进程运行提供额外的功能，发展出Linkerd和Envoy。在云原生技术结合，为每个服务Pod中配置sidecar容器，服务通过sidecar代理相互通信，代理之间互连形成了一个网状网络，即为Service Mesh。
这么优秀的Service Mesh为什么没有大范围落地呢？有几个问题：第一个就是性能损耗，原本服务A与服务B的通信，要经过两个sidecar转发，增加了网路延迟；其次是资源占用，特别是在大流量的数据服务中，sidecar占用的资源跟业务应用相接近。除此之外，数据流会变得复杂，Service Mesh还有控制平台，大家入手门槛高。总之Service Mesh说是一个很有前景的发展方向，在生产环境去使用，需要找到合适的场景。
4、Serverless
按照 CNCF 对 Serverless 计算的定义，Serverless 架构应该是采用 FaaS（函数即服务）和 BaaS（后端服务）服务来解决问题的一种设计。BaaS（后端服务）已经相当成熟，无论公有云还有企业私有云，都已经可以提供：对象存储、云数据库、消息队列、网关等等的后端服务。另一部分FaaS函数平台，开发人员可以直接提交代码，不需要将代码编译成应用发布部署，以代码片段的形式直接发布，由函数平台来由消息触发，去调用函数执行。Serverless带来的优势，1、可维护性：无需管理服务器，比如操作系统的补丁升级、故障处理，都交给BaaS和FaaS了；2、可扩展性：无需对未来发展做资源预估，云服务都是弹性可扩展的；3、成本：按量付费，没有请求不收费；4、安全性：DDoS攻击都交给云服务解决。
实践Serverless是架构设计理念的转变，不再以应用服务器为核心去设计架构，而是改为将数据、事件为中心，基于云服务平台去构建业务逻辑。
这里容器包含了从镜像构建、镜像存储、镜像分发到容器编排和容器运行整个容器生命周期。容器技术是一个比虚拟机更加轻量化的虚拟化技术，是在一个部署节点上共享操作系统；容器本身的创建、销毁和调度的速度比虚拟机更快；基于CGroups技术限制、记录、隔离进程级别的资源。
声明式API是指我们使用K8s API对象的方式，一般会编写对应API对象的YAML文件交给K8s，而不是使用一个个命令来一步步操作。这里API对象的YAML文件其实就是一个“声明”，表示所期望的最终状态是什么样子，K8s API Server会协调控制API对象的最终状态达成，以及处理过程中出现的异常问题。
不可变基础设施是2013年就提出的一种构想：任何基础设施（服务器、容器等软硬件）一旦创建之后便为只读状态，不可对其进行任何更改。如果需要修改，唯一的方式就是创建一批新的实例以替换。这种模式的好处显而易见，配置工作可实现重复性，让持续集成与持续部署变得流畅；同时易于应对部署环境的差异及版本管理。容器将应用程序与所有的依赖都封装在一起，解决了依赖问题；也解决了云环境依赖问题，只要有容器运行时如Docker，容器编排技术如K8s，都可以无差别的运行。应用依赖及依赖冲突、环境差异、配置管理一直是复杂应用系统的噩梦，开发人员花在集成和部署上的时间与精力甚至超过开发本身。
三、数据中台发展历程
企业数据中台建设或者数字化建设分为四个阶段：第一阶段是信息化系统，将业务数据以数字化的形式存储下来，选择一个事务型数据库：Oracle、MySQL、PostgreSQL，解决结构化数据的保存和查询的问题。
第二阶段是数据仓库，在事务型数据库基础之上，打通各部门的业务数据，保存业务历史快照，数据聚合计算，支持BI分析。将数据从各个业务数据库导入到数据仓库中，建立统一数据模型，通过数据分析支持企业决策。
第三阶段是大数据平台，随着互联网的发展，出现大量的非结构化和半结构化的数据，为存储这些多样化、大数据量、高速、低价值密度的数据，诞生Hadoop生态以及各类云存储平台。
有业务数据仓库，又有大数据平台，这两类数据有了融合的需要，要提供全局跨部门、跨产品的数据仓库以及端到端的数据应用开发体系，这就是现在的数据中台建设。在电商场景中，为提供千人千面的应用，本质上是根据不同的人群，优先推荐最可能成交的商品，提供购买转化率。这里涉及到结构化业务数据：用户信息、订单信息、商品信息，半结构化数据：商品点击流、商品曝光流等，非结构化数据：商品详情、用户评价等；为用户建立用户画像，给商品打标签，融合基于内容、基于协同过滤的推荐算法，实现个性化推荐。
四、数据云原生实践
京东的大数据平台，已经实现了规模化、体系化、智能化。规模化：集群规模数万台机器，存储数据达到EB级，数据处理任务数达到百万级。体系化：可管理、可维护、标准化数据模型的一站式平台。智能化：集成九数算法，建立统一的标签服务、特征中心、模型训练以及在线算法应用。
同时面临着诸多的挑战，资源利用率：为支持大促按照峰值预留资源，资源弹性不足，资源利用率不高；产品高耦合：平台覆盖数据采、存、算、管、用全链路产品，产品间相互耦合；商业交付难：系统交付部署周期长，资源配置要求高。由此，我们希望通过云原生的建设，解决这些挑战。
1、技术选型
社区通常的解决方案是为每一个产品开发一个Operator，比如Redis Operator、Etcd Operator，发布在Operators Hub中。如果使用社区的Operator去改造，跟企业内部的安全、运维规范的集成就是一个问题，比如SSO打通，日志监控系统对接，需要每一个Operator进行改造。另一个问题是大数据平台上的产品大多没有社区Operator，需要为各个内部产品开发Operator，这个人力资源也是无法承受。
另一种技术选型是使用OAM模型，在开源产品KubeVela的基础上打造。这个方案的问题是KubeVela是面向开发者，对于公司内部的运维人员，开发CUE扩展存在一定技术门槛。
下面将介绍京东内部采用的创新性的技术方案，为大数据平台一系列产品提供快速云原生转型。
2、架构与模型
数据云原生方案可以说包装K8s并提供一个通用Operator，可以承接京东数据中台包含存储、计算引擎、多维分析、治理、算法、可视化、集成与开发等一系列的产品。这个通用Operator集成了内部的安全、监控报警、日志这些特性，同时适配内部容器云JDOS和其它公有云K8s。
这个解决方案提出了通用的标准应用模型，将数据中台产品需要的应用特性抽象到这个标准应用模型中，不需要集成人员再开发应用特性。标准应用模型通过应用模板为每个产品定义需要的组件、配置和相关的应用特性；在创建一个产品应用实例时，将应用模板渲染成应用CRD(Custom Resource Definition)，最终创建出应用所有的K8s资源。
标准应用模型可以支持的应用代表，无状态应用是最简单的，原生的Deployment就可以支持。对于有状态应用，不同于原生的Statefulset，我们可以支持多个组件多副本，比如HBase应用有Master、RegionServer。此外，对于Zookeeper这种，一个组件有多个角色：server、observer，标准应用模型可以至此。还有有状态多分片的应用，比ClickHouse分为多个Shard，应用的总副本数是Shards的Replica乘积。
3、工作流编排
要支持多种类型应用，除了上面介绍的通用的应用模型，还需要有适配不同产品的Reconcile工作流。在这里的工作流编排中，支持通用的生命周期工作流，完成大部分产品的目标态的协调。
同时支持运维工作流，支持目标态没有发生变化情况下的，运维动作的执行。比如要完成Pod的重建，业务进程的重启等操作，应用CRD的yaml目标态是没有变化的，要进行顺序或批量的运维操作。
对于复杂应用，通用的生命周期工作流无法完成应用的构建，还可以自定义专属该应用的生命周期工作流，在完成K8s资源构建的同时还可以进行完成接口的调用或产品初始化操作。
4、可插拔应用特性
公司内部都有标准的运维辅助系统，这些系统的建立比数据中台更早，产品云原生化之后还需要同运维辅助系统集成。应用模板可支持这些应用特性的选配，包括日志、监控、报警、自愈等特性。如果应用模板定义中开启了日志功能，在应用实例创建的时候，就会为该实例注入日志采集sidecar，该sidecar会同已有日志系统集成，进行的日志管理。
运维系统的升级只需要更新对应的sidecar版本，对业务系统是无感的。已有的应用实例可以独立的升级特性sidecar版本和配置，将业务逻辑与运维能力分离，独立管理。
5、弹性扩缩
这里以ClickHouse作为案例来说明弹性扩缩容的能力。弹性能力分为三个维度，第一是扩缩副本，水平横向的扩缩容，一个Shard本来有两副本，可以扩容到三个副本。第二是扩分片，从原来的两个Shard，扩容到三个Shard；扩分片涉及到数据的移动，数据云原生平台将第三个分片的Pod拉起来，并调整应用集群的配置（反映Shard数量的变化），产品本身需要支持数据的移动，将Shard1、Shard2的部分数据移动到Shard3.第三个维度是纵向规格的扩缩，从原来单POD4核8G的资源规格，扩容到单POD8核16G，以支持单个POD的性能瓶颈。
有了这样的扩缩容能力的支持，原来物理机形态的扩缩容从周、天级别，缩小到小时、分钟级别。配合存储磁盘的扩缩能力，可以实现根据业务需要，快速应用实例扩缩，有效提高资源的利用率。
6、存算分离
存算分离是数据云原生平台提供的一种远端云存储挂载能力。分为两种方式：独立存储，每个POD可以挂载一个远端云存储卷，副本扩容时需要创建出一个新的存储卷。这种存储挂载的优势在于远端存储被挂载为本地磁盘，应用基本无需改造；劣势在于应用多副本设计会造成数据的冗余，远端云存储本身有三副本的冗余。
另一种方式共享存储卷，将一个共享远端存储卷挂载到每一个POD中，各个POD在共享卷重分目录结构去使用。这个方案应用是需要进行改造的，因为要分目录存放数据，不能按照原来应用占有整个数据盘来读写数据；另一点就是远端数据盘的读写性能问题，所有POD都读写在一个远端盘上，读写受到带宽和远端数据盘的限制。优势在于极致弹性，计算节点的扩缩容与数据分离，而且数据在应用层没有进一步的冗余备份。
这两种方案可以根据不同应用场景选择使用，可以先试用独立存储完成存储分离，再改造应用完成存算分离。
五、挑战与展望
数据云原生平台支持了京东内部几十种数据产品的云原生改造，包括开源数据产品Hadoop、OLAP，也有独立开发的数据集成、数据开发产品。
展望未来，数据云原生有两个方向继续探索，一个是应用标准化。在数据中台，存在多种类型应用：无状态、有状态、多分片、多组件等等，不能为每种应用类型去适配云原生，必然要有一种标准应用模型以及工作流来支持所有的产品，以消除不同应用类型带来的复杂性。在服务治理、Serverless同样需要标准的方案来提供；智能弹性需要支持HPA、VPA，根据资源系统指标或应用指标自动弹性扩缩。应用组合指的是商业化输出根据不同场景需要，组合不同的应用产品为一个数据系统，支持TB、PB、EB级不同数据规模，数据复杂度的数据中台。
另一个方式是资源规模化，目标是为降本增效，提高资源的利用率，提升运维的效率。具体应用方面可以有：联邦集群，即跨集群的应用创建，实现应用的跨集群高可用；多云适配，支持多种公有云K8s平台，应用在多中云平台轻松迁移；分级调度，多应用划分级别，对高优先级应用优先保证资源分配，在资源紧张情况下，通过驱逐低优先级应用以保障核心应用的稳定性；混合部署，可以是物理机应用部署与云原生平台的混合部署，也可以是离线云原生和在线云原生应用的混合部署。资源池的规模效应，规模越大，应用类型越是丰富，资源越是可以混合有效的加以利用。
王国维先生在《人间词话》里提到的三重境界，我们数据云原生实践也是经历了这样的三重境界，第一重境界是“独上高楼，望尽天涯路”，为寻找一个合适的新技术方案，必须得了解当前的各种技术方案，再选择一个方向去尝试。第二种境界是“衣带渐宽终不悔，为伊消得人憔悴”，这是《蝶恋花》里的一名句，既然选定了一个技术方案，就要不断的去推进，去优化，把我们标准化的应用模型去做出来，落实到大数据的各个产品上。即使衣带渐宽很辛苦，也决不后悔。现在在京东内部已经取得很好的效果，有数千个应用完成云原生平台创建与管理。第三重境界“众里寻他千百的千百度，蓦然回首那人却在灯火阑珊处”，这是为我们的一个技术发展去寻找一个希望，它将指引着我们不断前进。终将有一天这个方向会被更多人所接受，推动数据应用云原生的进一步发展。
参考资料：
- Open Application Model：OAM | Open Application Model Specification
- Pattern: Service Mesh：Pattern: Service Mesh
- 一文详解 Serverless 架构模式
- Serverless简介：Tencent Serverless - 文档
转载：https://blog.csdn.net/u011798638/article/details/128455682