云原生技术成熟度分析及开源探索

Posted 2021-04-02 移动Labs

Labs 导读

2021新年伊始，新冠仍在肆虐，这场人类生命的挑战改变了人们的生活方式，同时也推动了移动互联网和云计算服务的持续发展，例如美团、盒马和多点等生鲜生超APP外送或自取的方式被更多人所接受，而这些APP背后都是云原生技术在做技术支撑。云原生作为云计算最佳的使用方式正在被各类行业应用广泛采纳和推广，在国家大力推动各行业数字化转型的契机下，相信云原生技术一定会扎根各行业，助力各行各业的高速发展。

云原生技术包罗万象，本文旨在厘清其核心技术内涵并提供一种有效的评估云原生技术成熟度的评估方法，并应用此方法评估云原生技术中的容器和微服务等开源技术栈，分享业界云原生相关的开源项目，并在文章最后给出下一步研究方向。

作者简介：

陈鹏翔 中国移动研究院研究员，研究方向云原生、微服务、熟悉开源项目和技术贡献，曾就职于HP等企业从事NFV架构师工作。

1

云原生技术和本文范围

云原生技术是由Pivotal的Matt Stine于2013年提出，核心内容为描述一种应用，这应用符合12要素、微服务架构、敏捷基础设施、基于API协作和反脆弱性，该描述较为抽象，特别是12要素的具体描述，实际应用起来并不拿来可用。Pivotal于2017年更新了一个具象的描述：云原生是一种构建和运行应用的方法，他利用了云计算交付模型的优势，企业需要一个平台来构建和管理云原生应用程序和服务，该平台实现了自动化且集成了DevOps、持续部署、微服务和容器等关键技术。这个描述更加偏重于平台侧应具备的能力，与“公要善其事必先利其器”如出一辙。这一点上CNCF（Cloud Native Computing Foundation，后简称CNCF）做的更纯粹。

CNCF成立于2015年，由Google、思科和Docker等参与成立，给出的云原生定义为容器化封装、自动化管理和面向微服务。显然从一开始，CNCF就立足于平台侧，因为其下的开源容器调度平台Kubernetes（后简称K8S）在后续发生的容器调度平台大战中战胜了Mesos和Docker Swarm，做云原生技术的厂商更愿意把开源应用放到CNCF进行托管。2018年CNCF在托管了服务网格中的翘楚Envoy和Linkerd后，重新定义了云原生技术的范围，包括容器、服务网格、微服务、不可变基础设施和声明式API。

我们给云原生的定义为:一系列面向云计算的技术和管理理念的集合，开发者要在应用架构、开发模式和运维部署阶段贯穿实现这种理念，最终达到降低开发运维复杂度，最大限度发挥云计算的价值的目的。

核心技术包含不限于：

容器：是云原生应用的封装事实标准，软件及其依赖封装到容器镜像的内部，一次打包，到处部署，通过容器编排调度实现敏捷交付，主要包含容器编排、运行时层（容器运行时，云原生存储和云原生网络）等。

微服务：应用开发方通过标准化服务化开发方式，将大型应用程序开发拆解为多个小型服务集合的体系方法。更高级的要求是将微服务基础能力（比如服务注册，服务熔断等）同应用的业务逻辑彻底解耦，使用平台侧的服务网格能力。主要包含微服务支撑层（服务网格、API网关和服务注册发现）等。

无服务计算(Serverless)：是一种构建和管理基于微服务架构的完整流程，允许在服务部署级别而不是服务器部署级别来管理应用部署，构建或使用一个微服务或微功能来响应一个事件。

管理理念包含：

持续交付：让单个应用随时处于可发布状态，通过自动化不断的将小批量软件运送到生产环境中，而不用等待与其他变更绑定到一次发布中。

DevOps：软件开发人员同IT运维运营人员之间的高效协作方式。采用DevOps研发模式、自动化工具，实现软件开发、测试、部署、维护一体化迭代。

不可变基础设施：应用的微服务部署之后，内容不可修改，修改的方式就是替换这个应用的微服务；也就是说在生产环境基础设施的各层组件（从os、虚拟机到集群，节点管理和单个节点的安装软件配置）中仅通过替换组件而不是修改组件来更改基础设施，以此来降低系统的依赖和复杂度。

云原生是一个从应用向下拆解的过程，根据云原生的核心理念，作为云原生平台能力的提供方，构建云原生平台应具备如下核心能力：(见图1)

图1

云原生技术体系以容器编排调度为核心，南向接口通过多种容器运行时、存储和网络插件可对接异构的基础设施层（即传统云计算层），北向接口提供标准声明式API和用户自定义资源（CRD）接口，便于构建平台上的平台，这些平台包括微服务支撑层，应用定义与开发层和观察与分析层，同时支持无服务计算这种新型服务形态。

由于云原生技术范围较大，本文研究范围为图1中的红色框红色字体的技术栈：容器编排调度，服务网格，服务注册发现，API网关和无服务计算，分析在众多开源项目中组件选型中的技术成熟度。

2

云原生技术成熟度评估方法

图2

云原生技术成熟度评估模型的评估指标分为两大类，一类是开源软件通用评估指标，一类是软件专用功能指标，每类指标有各自评估维度和算法，最终评估标准，按照

总分=开源软件通用评估结果* 60% + 软件专用功能评估结果 * 40%

根据量化分值情况判断技术的成熟度水平。以服务网格的通用指标和专用指标为例，看下指标类中权重最高的3个指标项的具体内容：

通用指标：占比最高的3个指标项为托管代码受关注数量、代码贡献者数量和主导团队。

托管代码，该指标受关注数量以Github为例，星标代表托管代码受关注数量，星标数量越高，代表该项目更受大家关注，注册了Github的用户均可以对关注的项目加星标，定量指标，20000以上为满分

代码贡献者数量，该指标直接反应了代码在行业内的应用情况，代码贡献者越多，证明基于该代码进行商用转化程度多高，定量指标，500人以上为满分

主导团队，代码开源初期大多有单独厂商主导开源，好处是如果厂商能力强，软件发展方向明确，项目会在短期快速发展，但对后期加入的厂商来说，会面临缺乏话语权问题，会导致代码出现众多分支，定量指标，代码托管3年以上且委员会成员7个厂商以上为满分

专用指标：占比最高的3个指标项为多开发语言支持，代码侵入性和性能影响。

多开发语言支持，微服务同软件开发紧密相关，针对java，C#，go等语言都各自使用的微服务框架；第二代微服务框架也提供了支持多语言的能力，定性指标，支持多语言为满分

代码侵入性，早期微服务框架与开发语言绑定，配置信息会编译到代码内部；第二代微服务框架提供了无侵入式的方式，定性指标，完全无侵入，应用无感知为满分

性能影响，微服务组件参与到软件内部通讯中，性能问题会导致整个软件提供服务能力的下降；以无服务代理时能力为基准，定量指标，下降10%以内为满分

3

云原生技术成熟度评估结果

此次主要评估的开源软件大部分来源于CNCF托管项目，容器调度编排涉及K8S、Swarm和Mesos，服务网格涉及Istio和Linkerd，服务发现涉及Zookeeper、Etcd和Nacos，API网关涉及Ambassador、Kong和Sentinel，Serverless涉及Knative、Kubeless和OpenFaaS。

3.1 容器编排

从通用和专用两个方面看，K8S均是大幅度领先，特别是通用评估大类中的主流热度子类，K8S已经将曾经从事Openstack、Swarm和Mesos的高端人才集中，以每年更新4个版本小步快跑的策略保持着技术上的领先。Mesos的优势在于对Hadoop和Spark等框架的支持，但缺点是架构偏重，特别是基于Zookeeper做一致性保证。Swarm的优势在于同Docker绑定，安装Docker即可使用，同时缺点是功能单一。K8S的优势在于通过CRI、CNI和CSI对接多种云计算环境，通过CRD/Operator等技术对上支持各种平台上的平台。从行业认知来看K8S已经是容器调度编排的事实标准。

3.2 服务网格

功能方面，Istio和Linkerd持平，性能方面Linkerd略胜一筹，但国内主流的公有云厂商和私有云厂商主要是基于Istio做持续的优化以提供服务网格能力，并且Istio在蚂蚁金服体系内经历过大规模部署和使用。Istio是Google研发的，原本计划于去年贡献给CNCF，但最终托管在其他组织里，依然掌握在Google手中，相对而言，发展方向把控上是一家独大，Istio的最新版本也经历了从微服务到单体的巨大改变，主要是弥补其性能损耗上的问题，Istio和Linkerd从技术的角度看差别很小，考虑遇到问题更容易找到解决办法，应考虑Istio为主要跟踪技术栈。

3.3 服务注册发现

服务注册发现模块整体得分较低，ZooKeeper由于是基于Java框架开发，对应用也要求其最好为Java开发，且历史比较久远，整体体量过重，已经很少有应用基于它作为服务发现组件，Nacos是阿里开源的，也是基于Java框架开发，但提供TCP/DNS/UDP/TLS等多种方式调用，其各方面都不太成熟，而Etcd由于是K8S默认的服务注册发现组件，安装量很大，其社区相对活跃，基于Golang语言开发，较为轻量，且提供HTTP和gRPC方式调用。建议以Etcd为主要跟踪技术栈。

3.4 API网关

API网关在整体微服务体系中处于极为重要的位置，但目前开源软件整体评分较低，阿里开源的Sentinel更多的是作为一种辅助型插件使用。从生态和活跃度来看，Kong遥遥领先，Kong的插件有30多种，而Ambassador的插件只有4种。后续以Kong为主要跟踪技术栈。

3.5 Serverless

Serverless是一种新型的云计算提供方式，目前开源软件整体评分较低，国内各大主流公有云厂商的Serverless服务大都采用自研的方式，各家SDK没有统一标准，且与各自提供的多种云服务紧密结合，厂商绑定严重。后续可以跟踪业界是否有统一标准，开源软件方面以Knative为主要跟踪技术栈。

4

中国移动发起的网络云云原生开源探索

中国移动研究院也在网络云领域积极探索云原生技术的应用场景，主导在Linux基金会发起业界首个面向5G及未来网络的云原生PaaS平台项目—XGVela。

该项目旨在依托云原生理念及技术在运营商网络云中引入平台即服务（PaaS）功能，使运营商可以通过XGVela平台快速设计、开发、创新、管理网络功能和服务。通过这种方式，运营商及设备商将会更多地关注于上层业务，避免陷入复杂的电信基础设施。

XGVela平台将选择灵活可扩展的PaaS框架，选择性引用业界广泛使用技术成熟度水平高的General PaaS能力，实现General PaaS能力的电信级增强适配，并开发具有强电信特色的Telco PaaS能力。

目前项目技术委员会由中国移动、中国电信、中国联通、爱立信、华为、Intel、Mavenir、Nokia、红帽、SigScale、STC、风河、ZTE等13家国内外电信运营商、设备商、云服务商组成。种子代码及项目Wiki请参照原文链接。

5

后续研究方向

云原生技术栈方面，重点研究观察和分析层的相关技术，包括监控相关的prometheus及其相关的exporter，日志相关的EFK整体解决方案，调用链相关的Opentracing协议，Jaeger、Zipkin和Skywarking等APM软件，这些技术栈虽然没有服务网格等技术热度那么受关注，但是这些技术栈对于我们了解应用云原生化程度以及带来哪些好处，能够给出客观可直观的数据。另一个需关注的点就是对于云原生应用的封装方式，目前已经具备的Helm，Operator等，2020年微软与阿里提出的OAM（Open Application Model）标准与参考实现都是为了更加直观简单的描述应用，屏蔽或归拢复杂的K8S识别的Yaml，为开发和运维云原生应用降低门槛，从而促进云原生应用的普及。

成熟度方面可以从后评估角度，第一，对平台应用效果等方面进行评估，平台能够提供哪些能力支持云原生应用的快速开发，自动化集成部署，便捷运维等；第二，对应用进行评估，应用进行微服务改造后，需要给出一个评估模型去评估微服务改造的效果。这两点都需要同前述云原生技术栈的研究相结合。

云原生技术广袤，并且总有新的技术栈加入进来，结合不同应用场景的开源项目也层出不穷，我们认为云原生技术的推广和云原生技术本身的涵盖范围的不断迭代是并行展开的，不能等到云原生技术完全成型时再进行推广，因此也在积极通过面向网络云的云原生PaaS项目XGVela基于成熟度高的项目推动产业落地。也许我们正在尝试推广的技术栈以后会被新的技术栈替代，这也正是技术的生命力所在。

转载出处：中移it先锋队

●  

●  

●