云原生领域的热门技术趋势及架构实践

作者 | 赵钰莹

在刚刚结束的 KubeCon 上海站，可以明显感受到国内外各大厂商对云原生的探索已经进入不同发展阶段并有所侧重，本文重点探讨云原生领域的热门技术趋势并分享阿里巴巴云原生架构实践。

2013 年，Docker 项目发布，当时这不过是 LXC 的使用者，创建和使用应用容器的逻辑跟 Warden 等没有本质不同，但“容器镜像”的出现真正解决了困扰 PaaS 用户已久的一致性问题，Docker 项目通过容器镜像直接将应用运行所需的完整环境，即整个操作系统的文件系统打包，这也带领着容器技术走向成熟。可惜的是，Docker 公司并没有赢得接下来的容器编排大战。

2017 年末，Google 在过去十年编织全世界最先进容器化基础设施的经验，最终帮助 Kubernetes 项目取得关键领导地位，并将 CNCF 这个以“云原生”为关键词的组织和生态推向巅峰。

根据 CNCF 的定义（V1.0），云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。本文采访了阿里巴巴高级技术专家张磊和资深技术专家李响，共同探讨云原生领域热门技术背后的争议及最佳实践。

云原生热议技术

如果从广义上理解云原生，李响表示，这实际上是一套方法论，这套理念的目标是最佳利用云本身的交付能力，比如弹性、基础设施优势等，以容器、微服务、服务网格等技术为基础构建起来的云原生应用可以很好得满足这一目标，因此这也被称为通常意义上的最佳实践。在这之中，Kubernetes 又成为当时整个社区推动云原生实践的最佳翘点，因为其让用户在管理应用时能最大程度发挥容器和云的价值。

如上所述，云原生涉及的领域众多。根据 CNCF 公布的云原生全景图谱，每个领域又包含众多细分选项和开源项目，一篇文章很难说清楚。因此，本文重点探讨云原生领域的热议技术和值得重点关注的方向。

Service Mesh

2016 年 1 月 15 日，离开 Twitter 的基础设施工程师 William Morgan 和 Oliver Gould，在 GitHub 上发布了 Linkerd 0.0.7 版本，他们同时组建了一个创业公司 Buoyant，业界第一个 Service Mesh 项目诞生，但在当时，以 Spring Cloud 为代表的传统开发框架占据着微服务市场的主流地位。直到 2017 年底，非侵入式的 Service Mesh 技术才从萌芽走向成熟。

对于这一技术的未来发展，李响建议回归技术本质，Service Mesh 的本质是为了将原来应用层的服务治理能力下沉到基础设施，让开发者免去关心这些繁琐的问题，由基础设施进行统一管控，但这项技术发展至今更多还处于探索阶段，在灵活性、规模性和性能层面还面临很多挑战。举例来说，原来由开发人员掌握的能力下沉到基础设施，解放开发人员的同时也让其丧失了部分灵活性。如果想要更好地实践 Service Mesh，一定要找到开发人员和基础设施之间的平衡点，并努力解决其产生的一些性能损耗，Service Mesh 本身的 工具 链和生态也需要不断完善。

在这些工具中，Istio 是目前 Service Mesh 社区最引人注目的开源项目，并在今年 3 月份发布了期待已久的 Istio 1.1 版本，对流量管理、安全、策略和遥测以及配置管理进行了更新和调整。然而，在过去一年，Istio 基本都在专注自家生态，既没有捐给 CNCF，也没有推进一些标准型或者接口型的生态技术，微软牵头在本届 KubeCon EU 站上发布的 Service Mesh Interface（SMI），几乎所有 Service Mesh 玩家都参与了，唯独谷歌或者说 Istio 缺席了，这不仅让人对其未来走向感到担忧。

采访中，李响表示，每个项目都存在一条适合自己的技术和用户演进曲线，对于现阶段的 Istio 而言，相比于开放化或者加入基金会，能够根据用户需求集中式快速迭代，扩大用户群体可能是更重要的事情。回顾 Kubernetes 的发展，起初也不是一个完全由社区驱动的项目，后期才逐渐加入 CNCF 并且变得更开放。这只是各大项目生命周期的一个过程，每个阶段的时间长短可能各有不同。但是，从另一个方面讲，Istio 目前在国内的接受度还是比较高的，不少企业已经将其放入生产环境大规模实践，其现状可能是对其技术演进比较合适的选择。

对此，张磊补充道，从技术层面来看，Istio 本身并不属于偏生态型的项目，它的目的在于解决服务治理存在的问题，而不是连接更多项目和开发者，定位上的差异让其技术演进路线存在不同。虽然国内已经有企业开始实践，但更多还是偏向控制面，国际上对数据平面的关注同样很高，比如 CNCF 的 Envoy 项目，本身在国内并没有得到很好的落地，这也与国内企业的技术栈和关注点有关，比如阿里早期更关注中间件，这就属于控制平面的事情，而国外很多开发者的背景是基础架构，更习惯从底向上看待整个事情。虽然角度有所不同，但数据平面是国内企业和开发者值得关注的方向。

Serverless

Serverless 是一种“无服务器架构”模式，它无需关心程序运行环境、资源及数量，只需要将精力聚焦到业务逻辑上的技术。目前很多公司已经实现 DevOps 化，正在向 Serverless 迈进。今年初，曾经以独特视角定义云计算的伯克利又以新的视角发布了一篇文献：将云中的编程变得简单：伯克利视角下的 Serverless 计算。其认为：

Serverless 所提供的接口，简化了云计算的编程，其代表了 程序员 生产力的又一次变革，一如编程语言从汇编时代演变为高级语言时代。

不难看出，伯克利对此非常看好，而也有观点认为 Serverless 只是新型的 SOA 架构。对此，李响在采访中表示，Serverless 的本质在于一方面提高开发效率，免去对机器管理、环境配置等运维域的繁琐工作，另一方面提高资源效率，通过按需使用、按量计费降低一次性投入成本和使用成本。Serverless 需要定义基础设施和开发人员之间的界限，其本身的定义也是动态变换的。在虚拟机时代，运营商将物理机器服务化对外提供虚拟机的 API，包括现在提及的“容器即服务（CaaS）”的思想，开发者需要关心的是一个容器的 API，这本身也是一种无服务器的思想，但是随着资源对利用率要求更高，又提出新的函数即服务（FaaS）的理念，这种是看上去是更彻底的无服务器架构，开发者聚焦在业务函数代码本身，对运行环境完全无感知，前端开发工程师能很轻松构建起完整的系统。随着技术的逐渐成熟，界限的水位线将逐渐升高，最终的结果是开发人员的负担越来越低，但这个最佳平衡点在哪目前还没办法下定论。

在众多 Serverless 项目中，Knative 是近期关注热度较高的话题，这是谷歌在 2018 的 Google Cloud Next 大会上发布的一款基于 Kubernetes 的 Serverless 框架。Knative 很重要的目标是制定云原生、跨平台的 Serverless 编排标准。通过整合容器构建 (或者函数)、工作负载管理 (和动态扩缩) 以及事件模型这三者来实现 Serverless 标准。

然而，发展至今，Knative 也逐渐面临与 Istio 相同的问题，微软发布的开源 KEDA 与 Knative 多有重合，但 Knative 本身与 Kubernetes 的集成度并不是很高，KEDA 在“事件驱动的水平扩展”这一细分领域，跟 Kubernetes 项目本身有着更好的集成度，更多强调可扩展性和接口设计，显然也有推动这一领域技术标准化的含义。张磊表示，从不同的角度解决开源工具存在的不足，这是社区和企业目前喜闻乐见的事情，社区中存在很多不同的开源项目从不同的角度解决问题，这本身也是对现有项目缺点的补充。至于 FaaS 是否就是未来 Serverless 的最佳实践模型，现在有挺多实践落地的例子，但是还无法轻易下结论，FaaS 对开发范式有一定的要求，需要对现有业务进行改造，节约计算成本和研发的投入需要找个平衡点，短期内 Serverless 在面向开发者的层面可能还是会持续“百花齐放”的现状。

值得关注的技术

除此之外，云原生领域还有很多其他项目值得关注，比如监控领域，李响透露，Prometheus 就是值得关注的项目之一。最近，OpenTracing 和 OpenCensus 也在进行合并成为 OpenTelemetry。Containterd 项目后续与 Docker 的关系，整个 Kubernetes 下面的运行时是否会切换到更标准、开放的技术，包括与 Containterd 存在一些竞争关系的 CRI-O，刚刚加入 CNCF 成为孵化项目。无论如何，运行时部分将有新的故事发生。

至于应用交付领域，Helm V3 已经发布。张磊认为，该领域未来会有较大发展。因为，Helm 起初的定位是 Package  Manager（包管理），这本身是一个比应用更小的维度，未来可能抽象到应用层面，管理由多个包组成的应用。最后，CNCF 成立了 Special Interest Group（SIG），也在讨论如何在云原生上定义应用，并把云原生应用交付到 Kubernetes 标准化集群。未来，标准化也将是云原生领域的重要方向。

阿里巴巴云原生实践

在云原生领域，开发者的诉求和使用方法永远是丰富的、复杂的、多样的。在这种背景下，短时间内很难有技术能够大一统地解决开发者面临的所有问题，阿里巴巴内部对云原生的探索也一直在进行中。

2011 年，阿里巴巴开始向容器等云原生技术进行演进，最初的目标是为了增强资源本身的利用率，随后又开始探索调度、存储等方向，逐步提高资源的可靠性和稳定性。在这一基础上，阿里巴巴又开始想办法提高业务稳定性和开发者效率，引入诸如 Kubernetes、CI/CD 等技术，推动云原生在阿里巴巴稳健、优雅的落地。李响表示，在整个平台切换到 Kubernetes 之后，阿里巴巴开始尝试将 PaaS 平台做得更加自动化，以实现应用自愈；提高监控和可运维性；让 Kubernetes 与 PaaS 平台实现最佳交互；与社区融合，将社区的新技术引入阿里巴巴内部进行实践以帮助社区落地，并将内部优秀的技术成果贡献给社区，让整个阿里巴巴云原生技术栈更加开放。

如果总结整个过程，张磊认为可以分为两大维度：一是从外向内引入社区技术，这让阿里巴巴的基础设施完成了一次自我升级，并变得更加开放标准；二是从内向外的输出，对社区提出有价值的代码，推动整个云原生社区向更大规模的方向演进。

基于上述理念驱动，阿里巴巴近日再次开源了两大云原生领域项目：国内首个开放云原生应用中心 Cloud Native App Hub 和云原生应用自动化引擎 OpenKruise。

Cloud Native App Hub

开放云原生应用中心，是云原生上托管和分发应用的集散地，同时也是国内开发者使用云原生应用的重要基础仓库。在 Kubernetes 生态中，“应用”是一组 YAML 格式的描述文件，而云原生应用中心，则为搜索、使用和分享这些应用描述文件提供了一个完全开源与开放的交互平台。

在当前的 Kubernetes 应用生态当中，Helm 是目前最被广泛使用的应用定义标准之一。所以在本次云原生应用中心的发布当中，对 Helm 格式应用的托管、搜索和分发能力成为了中心首次上线的能力。

为了能够让中国的开发者更好的使用 Helm Hub 的能力，阿里云开发者中心与 Helm 社区达成系列技术合作，在开放云原生应用中心提供国内首个 Helm Hub 北美官方站的同步镜像仓库与 Hub 站点。与此同时，Helm Hub 官方也在其核心 Charts 仓库中推荐了“开放云原生应用中心”作为中国开发者使用 Helm Charts 的首选。

在开放云原生应用中心当中，所有默认的 Helm Charts（Helm 格式的应用），都定时同步自 Helm Hub 北美官方站并托管在 Github 上。在这个过程中， 云原生应用中心会自动对同步过来的所有 Charts 进行“本地化”操作，包括将 gcr.io，qury.io 等访问不畅的镜像 URL 替换成国内镜像源；将托管在 Google Cloud 存储中的应用制品 URL 替换为国内镜像地址，并且不间断的通过后台 CI 系统在阿里云 Kubernetes 服务中验证这些 Charts。

与此同时，“开放云原生应用中心” 6 个月内的所有 Roadmap 都会直接在 Github 上开源，并接受所有开发者反馈，在开发者诉求的驱动下进行迭代和演进。

尽管 Helm 目前是社区主要使用的云原生应用管理工具，但开放云原生应用中心并不是一个完全的 Helm Hub “克隆”。事实上，Helm 只是云原生应用中心所支持的应用描述格式与管理能力的其中一种。

在开放云原生应用中心很快就会发布的后续版本中，应用中心将会率先提供基于 Kustomize 的应用描述文件修改能力：K-R（Kube-Resource）服务。

K-R 服务将使得用户可以直接通过 Overlay 的方式修改所有的应用描述文件的所有字段，而不会像 Helm 默认那样仅能通过模板替换或者 DSL 的方式修改应用描述文件，进而造成描述文件的“不可复用”化与碎片化。

访问地址：

https://developer.aliyun.com/hub

OpenKruise

Kruise 是 cruise 的谐音，'k' for Kubernetes。字面意义为巡航，豪华游艇，寓意 Kubernetes 上应用的自动巡航，满载阿里巴巴多年应用部署管理经验。

Kruise 的目标是 automate everything on Kubernetes。Kruise 项目源自于阿里巴巴经济体应用过去多年的大规模应用部署、发布与管理的最佳实践，源于容器平台团队对集团应用规模化运维，规模化建站的能力。

Kruise 的核心是自动化，将从不同维度解决 Kubernetes 之上应用的自动化问题，包括部署，升级，弹性扩缩容，Qos 调节，健康检查，迁移修复等。此次，Kruise 开源的内容主要在应用部署，升级方面，即一套增强版 controller 组件用于应用的部署和级和运维。后续，Kruise 会依次开源智能化的弹性扩缩容组件，以及应用 Qos 自调节能力的组件等。

Kruise 第一期开源主要包含 Advanced StatefulSet，扩展了原生 StatefulSet，加入了原地升级和允许最大不可用实例配置两个新特性；SidecarSet，大规模场景下 的 Sidecar 管理利器等。较为重要的是，OpenKruise 是一个 Umbrella 项目，正在计划发布更多 Controller 覆盖更多场景和功能，比如丰富的发布策略，金丝雀发布，蓝绿发布，分批发布等。

开源地址：

https://github.com/openkruise/kruise

结束语

云原生是 IT 基础技术以及应用的新趋势。Gartner 报告指出，到 2022 年有 75% 的全球化企业将在生产中使用容器化应用。历经 9 年技术沉淀，阿里云已拥有国内最丰富的云原生产品家族，覆盖八大类别 20 余款产品。截至 2019 年 6 月，阿里共开源近 700 个项目，收获近 40 万 star，聚拢全球 3.3 万开发者，其中 Star 数位列全球企业前四，国内第一。

未来，李响表示，阿里巴巴将继续从两个维度贡献开源：一是阿里云生态层面，帮助阿里云上用户和企业更容易得构建整个云原生技术栈；二是帮助更广泛的开发者培养云原生土壤，并持续与国际社区进行标准化合作。在第二个层面，张磊补充道，阿里巴巴也将通过与国际社区合作举办线上公开课等方式帮助国内开发者更好地实践，阿里巴巴有责任也有义务让云原生技术在国内更好落地。