拐点已至，云原生引领数字化转型升级

本文整理自易立在 2019 携程技术峰会上发表的题目为《拐点已至，云原生引领数字化转型升级》的演讲。

今天我跟你们分享的题目是“拐点已至，云原生引领数字化转型升级”。先作个简单的自我介绍，我叫易立，来自于阿里云容器平台，从 2015 年开始负责阿里云容器产品，以前在 IBM 工做 14 年，主要负责企业中间件和云计算的产品研发。

今天会跟你们分享咱们对云原生领域的简单思考，以及咱们对云原生发展四个趋势大概的介绍：

• 拥抱 Serverless – 极致弹性，无需运维；
• 服务网格 – 将服务治理能力与应用解耦，并下沉到基础设施层；
• 云原生应用管理标准化 – 构建高效、自动化和可信赖的应用交付体系；
• 计算无边界 – 实现云-边缘-IoT 设备的高效协同。

云原生基本概念

先简单介绍云原生一些基本的概念。

咱们接触了不少的客户，对于这些客户而言，上不上云已经不是问题，他们关注的是该怎么上云？该如何充分利用云的能力、最大化云的价值？在 All in Cloud 的时代，企业的技术能力已经成为核心竞争力，他们很是愿意用云做为企业 IT 能力的增效器。

云原生计算是一组最佳实践和方法论，在公共云、专有云环境中，构建可伸缩、健壮、松耦合的应用，能够更加快速地创新和低成本试错；容器、服务网格、无服务计算等新的计算范型不断涌现。

容器掀开了云原生技术的序幕：

• Docker 镜像造成了应用分发和交付的标准，能够将应用与底层运行环境实现解耦；
• Kubernetes 技术成为了分布式资源调度和编排的标准，Kubernetes 屏蔽了底层基础架构的差别，帮助应用运行在不一样的基础设施之中；
• 在此基础之上，社区开始创建上层的应用抽象。好比服务治理层，Istio 成为了服务通讯的网络协议栈，将服务治理能力与应用层实现解耦。

在此之上，面向领域的云原生框架也在迅速出现，好比面向机器学习的云原平生台 Kubeflow 和面向无服务器的 Knative 等等。经过这样的架构分层，开发者只需关注自身的业务逻辑，而无需关注底层实现的复杂性。

咱们能够看到一个云原生操做系统的雏形开始出现，这是开发者最好的时代，极大地提高了业务创新的速度。

在早期，Kubernetes上主要运行无状态的 Web 应用，好比基于 Apache Dubbo/Spring Cloud 的微服务应用。而如今，愈来愈多的企业核心业务、数据智能业务以及创新业务也运行在 Kubernetes 之上。

以阿里云自身的云产品举例，如企业级分布式应用服务 EDAS、实时计算平台 Flink、弹性 AI 算法服务 EAS 以及区块链平台 BaaS 也部署在阿里云 Kubernetes 服务 ACK 之上。

K8s 已经成为云时代操做系统，成为应用使用云基础设施能力的界面。阿里云 ACK 实现了对云基础设施的优化集成，提供敏捷、弹性和可移植的云原生应用平台；并且能够在公共云、专有云、边缘云上实现一致的应用部署和管理。

从容器到无服务器

Serverless Kubernetes

下面咱们来谈一下，Kubernetes 的 Serverless 进化。

全部人都喜欢 K8s 提供的强大和灵活，可是运维一个 Kubernetes 生产集群极具挑战。

阿里云的 Kubernetes 服务 ACK 简化了 K8s 集群的生命周期管理，托管了集群的 master 节点被，可是用户依然要保有 worker 节点资源池，还须要维护节点，好比进行升级安全补丁等，并根据本身的使用状况对资源层进行容量规划。

针对 K8s 的运维复杂性挑战，阿里云推出了 Serverless Kubernetes 容器服务 ASK，彻底兼容现有 K8s 容器应用，可是全部容器基础设施被阿里云托管，用户能够专一于本身的应用。它具有几个特色：

• 首先用户没有任何预留资源，按照容器应用实际消耗的资源付费；
• 对用户而言没有节点的概念，零维护；
• 全部资源按需建立，无需任何容量规划。

Serverless Kubernetes 极大下降了运维复杂性，并且其自身设计很是适合突发类应用负载，如 CI/CD，批量计算等等。好比一个典型的在线教育客户，根据教学须要按需部署教学应用，课程结束自动释放资源，总体计算成本只有使用包月节点的 1/3。

云规模的 Nodeless 架构 —— Viking

它是怎么实现的呢？ 在 2017 年末，咱们启动 Serverless Kubernetes 项目的时候，就一直在思考：若是 Kubernetes 天生长在云上，它的架构应该如何设计？咱们为它内部的产品代号为 Viking，由于古代维京战船以迅捷和便于操做而著称。

首先，咱们但愿兼容 Kubernetes。用户能够直接使用 Kubernetes 的声明式 API，兼容 Kubernetes 的应用定义，Deployment, StatefulSet, Job, Service 等无需修改。

其次 Kubernetes 底层尽量充分利用云基础设施服务的能力和云服务来实现，好比计算、存储、网络、资源的调度等；根本性简化容器平台的设计，提高规模，下降用户运维复杂性。咱们听从 Kubernetes 控制器设计模式，驱动整个 IaaS 资源状态不断地向用户应用声明的状态逼近。

咱们在资源层提供了弹性容器实例 - ECI。与 Azure Container Instance ACI, AWS Fargate 不一样，ECI 提供 Kubernetes Pod 的原生支持而不是提供单独 container 实例。ECI 基于轻量虚拟机提供了沙箱环境实现安全隔离，彻底兼容 Pod 的语义、支持多容器进程、健康检查、启动顺序等能力。这样使得上层构建 K8s 兼容层，变得很是简单直接。

在编排调度层，咱们使用了微软的 Virtual-Kubelet，并对其进行了深度扩展。Virtual-Kubelet 提供了一个抽象的控制器模型来模拟一个 Kubernetes 节点。当一个 Pod 被调度到虚拟节点上，控制器会利用 ECI 服务建立一个 ECI 实例来运行 Pod。同时控制器支持双向状态同步，若是一个运行中的 ECI 实例被删除，控制器会根据应用目标状态从新恢复一个新的 ECI 实例。

同时咱们基于阿里云的云服务实现了 Kube-Proxy、Kube-DNS、Ingress Controller 的行为，提供了完整的 Kubernetes Service 能力支持：

• 好比利用阿里云的 DNS 服务 PrivateZone，为 ECI 实例动态配置 DNS 地址解析，支持了 Headless Service；
• 经过内网 SLB 提供了 Cluster IP，提供负载均衡能力；
• 经过 SLB 提供的 7 层路由来实现 Ingress 的路由规则。

咱们也为 ECI 提供了端到端可观测性能力，并与阿里云日志服务，云监控等服务进行了深度集成，也能够轻松支持 HPA 水平扩容。

容器启动加速——“零秒”镜像下载

对于 Serverless 容器技术而言，应用启动速度是一个核心指标。容器对应用启动速度的影响主要在于：

• 资源的准备：经过端到端管控链路的优化和针对容器场景虚拟化和操做系统的剪裁和优化，ECI 能够将资源准备时间优化到秒级；
• 镜像下载时间：从 Docker 镜像仓库下载镜像并在本地解压缩是一个很是耗时的操做。下载时间取决于镜像大小，一般在 30 秒到数分钟不等。

在传统 Kubernetes 中， worker 节点会在本地缓存已下载过的镜像，这样下次启动不会重复下载和解压。为了实现极致弹性成本效率，ECI 和 ECS 采用并池的策略，计算存储分离的架构，这也意味着咱们不可能经过传统方式利用本地盘来作容器镜像的缓存。

为此咱们实现了一个创新的方案：能够将容器镜像制做成一个数据盘快照。

当 ECI 启动时，若是镜像快照存在，能够直接基于快照建立一个只读数据盘，并随着实例启动自动挂载，容器应用直接利用挂载数据盘做为 rootfs 进行启动。基于盘古 2.0 架构和阿里云 ESSD 云盘的极致 I/O 性能，咱们能够将镜像加载的时间缩小到 1 秒之内。

为了简化用户操做，咱们在 K8s 中提供了 CRD 可让用户指明哪些镜像须要构建镜像快照。同时，在 ACR 镜像仓库服务的软件交付流水线上，咱们能够声明哪些镜像须要进行加速，这样当用户推送一个新镜像时，就会自动构建相应的快照缓存。

极致弹性

下面谈弹性，对于绝大多数的企业来说，弹性是上云最重要的一个诉求，双 11 就是一个典型的脉冲式计算，峰值计算资源会是平时的不少倍。也有不可预期的峰值发生，好比一个爆款游戏大热以后，就须要迅速地在云上扩容。Kubernetes 能够将云的弹性能力发挥到极致。

ACK 在资源层和应用层提供了丰富的弹性策略，在资源层目前主流的方案是经过 cluster-autoscaler 进行节点的水平伸缩。当出现 Pod 因为资源不足形成没法调度时，cluster-autoscaler 会选择一个伸缩组中，并自动向组内加入实例。

在弹性伸缩组中，咱们能够根据应用负载需求选择 ECS 虚拟机，神龙裸金属和 GPU 实例进行扩容。值得一提的是 Spot instance，竞价实例能够利用阿里云的空闲计算资源，成本折扣能够低至按量付费实例的 90%。

竞价实例很是适合无状态和容错性好的应用，好比批量数据处理或者视频渲染等，能够大大下降计算成本。基于阿里云强大的弹性计算能力，咱们能够在分钟级实现千节点伸缩。

进一步结合上文提到的 ECI，咱们能够在 ACK 中基于虚拟节点实现弹性伸缩。virtual-kubelet 能够注册为一个虚拟节点，理论上拥有无限大的容量。当 Pod 调度到虚拟节点上时，会利用 ECI 动态建立 Pod，这很是适合大数据离线任务、CI/CD 做业、突发型在线负载等。在一个大型客户的生产环境中，弹性容器实例能够在 30 秒内启动 500 Pod，轻松应对突发的请求峰值。

在应用层，Kubernetes 提供了 HPA 的方式进行 Pod 的水平伸缩，和 VPA 进行 Pod 的垂直伸缩。阿里云提供了 alibaba-cloud-metrics-adapter，能够提供更加丰富的弹性指标，好比能够根据 Ingress Gateway 的 QPS 指标、云监控的指标，动态调整应用 Pod 数量。

另外对不少行业客户而言，应用负载的资源画像是具备周期性的。好比，咱们一个证券行业的客户，每周一到周五，股市开盘时间是交易时间，而其余的时间，只能查询不提供交易，峰谷资源需求量高达 20 倍以上的差别。

为了解决这个场景，阿里云容器服务提供了定时伸缩组件，专门应对资源画像存在周期性的场景 ，开发者能够定义 time schedule，提早扩容好资源，而在波谷到来后定时回收资源；结合底层 cluster-autoscaler 的节点伸缩能力，很好平衡了系统的稳定性和资源成本的节约。

将来咱们会发布一些基于机器学习的弹性伸缩策略，能够根据历史资源画像，实现更好地资源预测，提高弹性的 SLA。

赋能下一代无服务器应用

上文说到了为何 Serverless 受到愈来愈多开发者的欢迎，由于你们更关注本身的业务，而不是基础设施的维护。Serverless 化是云服务发展的必然趋势，咱们须要将资源调度，系统运维等能力下沉到基础设施。Google, IBM，CloudFoundry 等共同推出了 Knative 做为 Serverless 编排框架，能够很是简洁、高效地实现无服务器化应用。它提供了几个核心能力：

• Eventing - 提供了事件驱动的处理模型，咱们针对阿里云，扩展了丰富的事件源，好比当 OSS 接收到用户上传的一个视频片断，触发容器中的应用进行视频转码；
• Serving- 提供了灵活的服务响应能力，能够根据业务的请求量自动弹性伸缩，甚至支持缩容到零，利用阿里云弹性基础设施，能够大大下降资源成本；
• Tekton - 能够轻松实现从代码到应用部署的自动化流水线。

结合应用管理能力和应用性能监控服务, 咱们能够基于 Knative 快速搭建具有领域特点的应用托管服务 (Micro PaaS)，大大下降直接操做 Kubernetes 资源的复杂度，让开发者更加专一于应用迭代和服务交付效率提高。

安全沙箱容器技术进化

刚才谈完了编程模型，看一下底层实现，全部的 Serverless下面核心实现就是安全容器沙箱。传统的 Docker RunC 容器与宿主机 Linux 共享内核，经过 CGroup 和 namespace 实现资源隔离。这种方式很是高效，可是因为操做系统内核的攻击面比较大，一旦恶意容器利用内核漏洞，能够影响整个宿主机上全部的容器。

愈来愈多企业客户关注容器的安全性，为了提高安全隔离，阿里云和蚂蚁金服团队合做，引入安全沙箱容器技术。今年 9 月份咱们发布了基于轻量虚拟化技术的 RunV 安全沙箱。相比于 RunC 容器，每一个 RunV 容器具备独立内核，即便容器所属内核被攻破，也不会影响其余容器，很是适合运行来自第三方不可信应用或者在多租户场景下进行更好的安全隔离。

通过性能优化，安全沙箱容器如今能够达到 90% 的原生 RunC 性能，而且 RunV 容器提供了和 RunC 容器彻底一致的用户体验，包括日志、监控、弹性等。同时，ACK 能够在一台神龙裸金属实例上同时混布 RunC 和 RunV 容器，用户能够根据本身的业务特性自主选择。

在财年年末，咱们会推出基于 Intel SGX 可信计算技术的可信容器沙箱 RunE。容器应用运行在 CPU 中被称为 enclave 的安全可信执行环境中。一个比喻：咱们把容器放进了保险箱，任何人，包括云服务供应商，都没法从外部篡改和截获之中数据。客户能够将高机密应用，好比秘钥的加签、验签，隐私数据处理等逻辑运行在 RunE 容器中。

从微服务到服务网格

下面谈另一个方面——微服务架构的演化。 互联网应用架构催生了微服务架构的发展。它的核心思想是经过应用功能拆分，将复杂应用拆解为一组松耦合服务，每一个服务遵照单一责任原则（Single Responsibility Principle）。每一个服务能够独立部署和交付，大大提高了业务敏捷性；每一个服务能够独立横向扩展/收缩，应对互联网规模的挑战。

服务治理能力下沉

微服务框架，好比 HSF/Dubbo 或 Spring Cloud，都提供了强大的服务治理能力，好比服务发现、负载均衡、熔断降级等。这些服务治理能力以 Fat SDK 的方式与应用程序构建在一块儿，随着应用一块儿发布和维护，服务治理能力与业务逻辑的生命周期耦合在一块儿。

微服务框架的升级会致使整个应用的从新构建和部署。此外因为 Fat SDK 一般与特定语言所绑定，难以支持企业应用的多语言（polyglot）实现。

为了解决上述挑战，社区提出了 Service Mesh（服务网格）架构。它将服务治理能力下沉到基础设施，经过一个独立的 Sidecar 进程来提供服务治理能力，而应用侧只保留协议的编解码便可。从而实现了服务治理与业务逻辑的解耦，两者能够独立演进不相互干扰，提高了总体架构的灵活性；同时服务网格架构减小了对业务逻辑的侵入性，下降了多语言支持的复杂性。

服务网格

在阿里巴巴经济体内部，咱们已经开始大规模应用服务网格技术，来提供多语言支持，下降业务对接门槛；提供统一架构模式，提高技术迭代速度。以 Istio 为表明的服务网格技术具备光明的前途，可是大规模生产落地时仍然存在很是多的挑战。

• 首先是 Istio 服务网格技术自身的复杂性；

• 其次是规模化带来的稳定性和性能的挑战：

  • 在海量服务的状况下，控制平面是否能够支持服务配置的高效分发？
  • 数据平面是否能够尽量下降增长两跳后的通讯延迟？
  • 下沉可观测性和策略管理能力到数据平面，避免集中化 Mixer 引入的性能瓶颈等。
• 最后是和现有的微服务架构兼容并存，支持现有微服务的统一配置管理服务和通讯协议。

为了解决上述挑战，阿里巴巴和蚂蚁金服与 Istio 社区兼容的技术体系上，构建了服务网格能力。在今年 618，蚂蚁金服已经完成核心系统上到 SOFAMosn 的验证工做，刚刚结束的双 11，阿里巴巴和蚂蚁金服在核心系统大规模上线了 Service Mesh。

同时阿里巴巴经济体会把自身技术演进的结果及时反馈到上游去，与社区共同推动 Service Mesh 发展。好比在阿里巴巴开源的服务发现与配置管理项目 Nacos 最新版本中，就提供了 Istio 对 MCP 协议支持。 晚些时候，阿里云会推出托管 Service Mesh 服务，帮助云上的开发者可以便捷地使用服务网格技术。

聚焦应用生命周期

另一个关注的焦点是应用生命周期的自动化、标准化。咱们知道 Kubernetes 的定位是 Platform for Platform，帮助企业实现自动化应用运维、管理。

Kubernetes 为分布式应用管理提供了不少基础的元语抽象，好比面向无状态应用的 Deployment 和面向有状态应用的 StatefulSet。可是在企业生产环境中，面对应用的不一样需求，现有能力还存在一些不足。参加技术分享咱们常常会听到每一个企业都在谈如何修改 K8s 来解决本身的问题，这里面不少问题都是类似的。

OpenKruise

做为云原生技术的引领者，阿里巴巴将咱们在云原生计算技术上大规模生产的最佳实践沉淀下来，以开源项目 OpenKruise 的方式与社区开放、共建。

• 一方面帮助企业客户在云原生的探索的过程当中，少走弯路，减小技术碎片；
• 一方面推进上游技术社区，逐渐完善和丰富 Kubernetes 的应用周期自动化能力。

以以下几个新的控制器为例：

• Broadcast Job：可让一次性任务运行在机器上指定的节点，好比咱们要在节点上安装安全补丁，或者在节点上预先下载一个容器镜像；
• Sidecar Set：愈来愈多的运维能力以 Sidecare 方式提供，好比日志、监控、和服务网格中的数据平面组件 Envoy。咱们能够经过 Sidecar Set 以声明式方法管理 Sidecar的生命周期；
• Advanced StatefulSet: 支持原地发布和批量升级，让你们在更加简单地支持有状态服务。

这些控制器解决了不少客户的真实痛点。

OAM-首个开放应用模型

在 11 月 16 日，微软和阿里云共同发布了 Open Application Model（OAM），但愿可以创建起一个标准化的云原生应用模型，帮助开发者、应用运维和基础设施运维团队，进行更加高效的协同。

它采用的关注点设计标准包括不一样的维度，开发者负责定义应用的组件、依赖与架构；应用运维人员负责定义应用运行时配置与运维需求，好比发布策略和监控指标，而基础架构运维团队能够针对应用部署环境的不一样，配置定制化参数。

经过这种关注点分离（Separation of Concerns）的设计，能够将应用定义、运维能力与基础设施实现解构。让应用交付变得更加高效、可靠和自动化。

计算无边界

最后一个方面，咱们来说一下对将来无边界云计算的思考。 随着 5G 时代的临近，低延迟网络、AI 硬件算力提高和智能化应用快速发展，一个万物智联的时代必将到来，将计算能力从云延展到到边缘侧、设备侧，并经过云进行统一应用交付、资源管控，将会是云计算发展的必然趋势。

云边端一体协同

基于容器，咱们创建了云边端一体协同平台 —— ACK@Edge。这样咱们能够将一些须要低延迟处理的应用部署在边缘节点实现就近访问。好比，咱们能够把 AI 模型预测和实时数据处理放置到边缘，进行实时智能决策，而将模型训练，大数据处理等须要海量算力应用放到云端。

ACK 边缘版提供了统一管控能力，在 K8s 集群中能够同时支持云端 ECS、边缘 ENS 节点以及 IoT 设备。而且针对边缘的特殊性，提供了单元化隔离和断连自治、自愈能力。咱们已经在阿里云视频云、优酷等场景中开始大规模应用。

优酷筋斗云

咱们以优酷筋斗云为例介绍其计算架构演进。

优酷是国内最大的视频平台，随着优酷业务的快速发展，须要将原来部署在若干 IDC 内的集中式架构，演进到云+边缘计算的架构。这时候须要一种方式来统一管理阿里云十几个 region 和众多的边缘节点。

优酷选择了 ACK@Edge，能够统一管理云与边缘的节点，并实现了统一的应用发布和弹性扩缩容。经过弹性能力，节省了机器成本 50%。采用新的架构以后，用户终端能够就近访问边缘节点，让端到端网络延迟下降了 75%。

源于社区，回馈开源

最后，云原生技术源自于社区的共同的建设。阿里巴巴做为云原生的实践者和引领者，全面拥抱云原生技术，并将咱们在大规模生产最佳实践回馈到社区，与社区共同建设更加美好的云原生技术生态。

---

本文做者： 易立

原文连接

本文为云栖社区原创内容，未经容许不得转载。