凌云时刻 · 技术
导读：阿里云智能资深技术专家韩伟东在首届中国云计算基础架构开发者大会上做了主题为《云原生底层系统思考》的技术演讲。
作者 | 韩伟东
来源 | 云巅论剑
前言
10 月 25 日，首届中国云计算基础架构开发者大会（简称 CID）在长沙召开，阿里云智能共分享 5 个演讲主题，阿里云智能资深技术专家韩伟东也在会上做了主题为《云原生底层系统思考》的技术演讲。
本文内容根据其演讲内容整理而成。以下为演讲全文：
云原生的发展
经过云计算十几年的发展和普及，用户逐渐从迁移上云演进到更好地使用好云的阶段。在传统模式下设计和实现的应用没法最大化的利用云计算基础设施的特点和能力，所以开发者开始基于云计算设施去设计和实现应用，这就是所谓的从云里长出来的云原生应用。2015 年 Matt Stine 给出了 twelve-factor applications 来定义云原生应用。2018 年，CNCF 给出了更全面的云原生定义，不仅涉及到应用，也包括代表技术、基础设施、运维等，可以说云原生已经从最初的应用层扩展到整体云计算技术栈。
相比于 IaaS，云原生应用场景有很多的不同，比如应用特点上有有状态和无状态以及长生命周期和短生命周期的区别，用户使用体验上有购买资源和按需使用服务的区别。所有这些差异点，能够很好的体现出云原生在提升效率和降低成本上的优势。
我们站在用户视角和系统视角来看一下云原生的变化。用户视角看，一个很大的变化是可以业务不相关的工作从应用剥离下沉到底层平台，用户只需要关心业务逻辑。
系统视角看，系统提供的用户服务界面上移，从物理资源层、虚拟化资源层上升到应用开发和运行层，云原生应用之下的底层系统技术栈变深。
云原生底层系统定义
服务界面上移这个变化使得应用开发和运行层之下的技术栈都变成了云厂商的内部系统，这需要从整体上重新去审视如何打造这个系统。我们从这个角度出发，给云原生底层系统做了一个定义：单机上支持应用代码和应用容器运行的整个软件系统。云原生场景下，在单机上是云原生应用+云原生底层系统，另外在集群层面，还有云原生应用平台，这个平台负责编排调度、服务治理、智能运维等。
云原生底层系统的构建思路
首先我们考虑云原生底层系统需要具备什么样的核心能力。
第一个能力是隔离性，在公有云场景，多租户的安全隔离是最基本的要求，同时在私有云场景和 Serverless 架构下各种业务应用混部部署，以及云原生轻量化后产生的高密部署，需要底层系统提供性能隔离和故障隔离上的保障。
第二个能力是兼容性，云计算是社会性的基础设施，面对的是全场景的用户，通用也是最基本的要求，云原生作为云计算新阶段，也必须保证好通用性，从底层系统上来说，需要有技术创新，但是需要做好各种兼容，应用兼容、服务兼容、云原生技术生态和标准兼容等，降低用户升级到云原生的门槛和成本。
第三个是效率，这是支撑实现云原生核心价值的能力，包括，资源效率：减少资源损耗，提高资源使用效率，降低成本；弹性效率：快速启动、并发效率等；运行效率：高性能。
IaaS 时代的运行单元是虚拟机，云原生时代需要什么样的运行单元？在企业内部，容器是一种很好的运行单元，但是普通容器存在很明显的缺陷就是隔离性，公有云场景的多租户安全隔离，私有云场景下性能隔离和故障隔离也不理想。兼顾隔离性、兼容性和效率，我们认为安全容器将会是云原生时代的重要运行单元。
实现安全容器有几种技术流派：
第一种是基于轻量级虚拟化和容器技术相结合的 MicroVM，这种方案整体上在隔离性、兼容性和效率更优，也是目前业界最主流的方案，各大云厂商都在积极投入。
下图是 MicroVM 的基本架构。
第二种是基于进程级虚拟化的应用内核方案，由于采用全新的用户态内核，兼容性不够好，同时对性能也有一定的影响。
第三种是 libos / unikernel，让应用带上轻量化的内核，一般都需要修改应用，兼容性不好。
安全容器作为运行单元已经体现出隔离性、兼容性和轻量化资源开销的好处，接下来我们看一下弹性效率方面。
启动速度是实现弹性效率的关键。
我们以一个应用容器的启动为例，可以分成如下几个主要的阶段，首先镜像加载是一个很耗时的阶段，一般需要网络下载和解压，需要用到按需加载或缓存等方法加速。网卡和磁盘的创建也比较耗时，要做到极速需要用到预创建这样的方法。安全容器自身的启动，需要通过轻量化设备模型和精简内核等方法。应用启动速度跟语言和应用自身有关，一般来说 Java 应用启动会比较慢，这方面已经有人在探索 Java 启动加速的相关技术。
这里稍微展开介绍一下我们在镜像加速上的方案。为了解决镜像下载和解压耗时大，以及镜像解压后无法再被校验，无法感知恶意篡改的问题，阿里云智能和蚂蚁集团的工程师一起实现了 Nydus 镜像加速服务，实现新的镜像格式，分成元数据和数据两层，并实现一个用户态文件系统，可以按需加载下载启动容器镜像，大大缩短镜像加载时间，并提供端到端的镜像数据一致性校验，从而让用户能够更安全快捷地管理容器应用。Nydus 已经正式开源，在 CNCF Dragonfly 项目中引入 Nydus 镜像加速服务。
欢迎大家关注和参与 Nydus 项目，开源代码地址：https://github.com/dragonflyoss/image-service
接下来简单介绍一下实现底层系统高性能的思路。因为底层系统技术栈很深，而且这些技术栈是不直接暴露给用户，所以为打破边界和重塑提供了机会，我们的核心思路是通过全栈优化来实现高性能，从最底层的软硬协同，到 host 和 guest 内核的上下协同甚至融合，到最上面的中间件和预研 runtime 跟 OS 的垂直优化。
到这里我们把计算相关的部分告一段落，接下来看看底层系统的其它方面。
在 Kubernetes 服务网络方面， kube-proxy 基于 netfilter 框架，性能和扩展性比较差。Service mesh 引入 sidecar 架构，数据链路上额外增加网络上一跳，影响性能。我们的一个思路是通过 eBPF 来加速这些网络，对于 Kubernetes 网络，基于 eBPF 实现一种新的服务网络和服务策略 tc-ebpf。tc-ebpf 位于 Linux 协议栈的 L2 层，可以 hook 网络设备的入、出双向流量到 eBPF 实现的 datapath。性能相比 kube-proxy 有明显的提升。对于 service mesh，我们采用基于 eBPF 的 sockmap 进行加速。sockmap 允许将 TCP 连接之间的数据转发过程卸载到内核中，从而绕过复杂的 Linux 网络协议栈直接在内核完成 socket 之间的数据转发操作，减少了上下文切换以及用户态和内核态之间的数据拷贝操作，优化 TCP 连接之间 socket 数据转发的性能。
关于云原生底层系统的存储，我们从问题和场景需求两方面入手。
首先对于 9pfs 作为安全容器 rootfs 的问题，我们建议采用 virtio-fs 替换 9pfs，可以从性能上有数倍的提升。Serverless 场景高密部署和按需短时生命周期执行请求的特点，高速临时存储将会很重要，一方面可以考虑对现有的存储处理进行一定的简化提升性能，另一方面也可以考虑通过高速介质（比如 AEP、内存）进行加速。
安全方面，除了前面提到的多租户安全隔离，以及兼容支持各种云计算的安全服务之外，还要考虑云原生技术和安全技术结合支持新的业务场景。机密计算是一种解决数据安全的新方法，是在一个基于硬件的可信执行环境（TEE）中保护数据执行计算。为了在云原生场景支持机密计算，我们实现了Inclavare containers，一种在硬件强制实施的TEE中运行enclave runtime和可信应用的新型容器运行时：
l 兼容容器生态：OCI runtime和容器镜像标准
l 基于Library OS技术，改善enclave引入的约束条件所带来的兼容性问题
l 提供对高级语言Runtime的支持，进一步提升泛用性
l 定义通用的Enclave Runtime PAL API规范，构建Enclave Runtime生态
Inclavare containers 项目已经开源，项目官网：https://inclavare-containers.io
开源代码：https://github.com/alibaba/inclavare-containers
欢迎大家关注和参与！
阿里巴巴云原生底层系统：袋鼠
介绍完我们对云原生底层系统的一些思考，也简单看一下我们构建的云原生底层系统：袋鼠。
我们不仅仅实现安全容器和 inclavare containers 这样的全新运行单元，而且在云原生底层系统整体层面构建了一些关键能力。袋鼠已经开始规模化地支撑阿里巴巴的云原生产品和业务。
小结
云原生在重构整个软件生命周期，是一项体系化的工作，整体上云原生还处于早期阶段，云原生技术正在快速的发展演进。我们的判断是云原生底层系统将会迎来一波的技术创新高峰，我们在这里分享的一些思考主要是抛砖引玉，面向未来，希望能够跟同行们一起推动云原生底层系统技术的创新和突破，构建更好更强大的云原生服务提供给广大的用户。
END
往期精彩文章回顾
云湖共生，下一代数据湖来了？
您有一封阿里云自动化运维沙龙邀请函待查收
这款机器人也想体验双十一！
如何应对互联网和物联网化带来的工业安全新风险？
阿里马涛：重新定义云时代的开源操作系统
如何构建一套高性能、高可用性、低成本的视频处理系统？
新增“组件池”概念，平头哥剑池 CDK 新版本实现组件强复用
阿里云张献涛：公共云平台四大发展趋势
我对零售云在云原生体系中的角色的思考（下）
我对零售云在云原生体系中的角色的思考（上）
长按扫描二维码关注凌云时刻
每日收获前沿技术与科技洞见
