本周六在携程技术大会上分享了一篇 “拐点已至，云原生引领数字化转型升级”的演讲，整理记录如下。
今天我会简单分享一下我们对云原生计算的理解，也会介绍云原生技术发展的4个技术趋势
- 拥抱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实现了对云基础设施的优化集成，提供了现敏捷、弹性和可移植的云原生应用平台。
下面我们来谈一下，Kubernetes的Serverless进化。所有人都喜欢K8s提供的强大和灵活，但是运维一个Kubernetes生产集群极具挑战。
阿里云的Kubernetes服务ACK简化了K8s集群的生命周期管理，托管了集群的master节点被，但是用户依然要保有worker节点资源池，还需要维护节点，比如进行升级安全补丁等，并根据自己的使用情况对资源层进行容量规划。
针对K8s的运维复杂性挑战，阿里云推出了Serverless Kubernetes容器服务 ASK，完全兼容现有K8s容器应用，但是所有容器基础设施被阿里云托管，用户可以专注于自己的应用。它具备几个特点：
- 首先用户没有任何预留资源，按照容器应用实际消耗的资源付费
- 对用户而言没有节点的概念，零维护
- 所有资源按需创建，无需任何容量规划。
Serverless Kubernetes极大降低了运维复杂性，而且其自身设计非常适合突发类应用负载，如CI/CD，批量计算等等。比如一个典型的在线教育客户，根据教学需要按需部署教学应用，课程结束自动释放资源，整体计算成本只有使用包月节点的 1/3。
在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镜像仓库服务的软件交付流水线上，我们可以声明哪些镜像需要进行加速。这样当用户推送一个新镜像时，就会自动构建相应的快照缓存。
弹性是云最核心的能力之一，像双十一这样的典型脉冲应用场景，或者像爆款游戏背后都需要云提供的强大算力来支撑，而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数量。
另外对很多行业客户而言，应用负载的资源画像是具有周期性的。比如，我们一个证券行业的客户，每周一到周五，上午9:30-11:30，下午13:00-15:00为交易时间。其他的时间，只能查询不提供交易。峰谷资源需求量高达20倍以上的差异，为了解决这个场景，阿里云容器服务提供了定时伸缩组件，专门应对资源画像存在周期性的场景 ，开发者可以定义 time schedule，提前扩容好资源，而在波谷到来后定时回收资源；。结合底层 cluster-autoscaler 的节点伸缩能力，很好平衡了系统的稳定性和资源成本的节约。
未来我们会发布一些基于机器学习的弹性伸缩策略，可以根据历史资源画像，实现更好地资源预测，提升弹性的SLA。
Serverless化是云服务发展的必然趋势，让业务应用更加关注自己业务逻辑，而将资源调度，系统运维的能力下沉到基础设施。
Google, IBM，CloudFoundry等共同推出了Knative作为Serverless 编排框架，可以非常简洁、高效地实现无服务器化应用。它提供了几个核心能力
- Eventing - 提供了事件驱动的处理模型，我们针对阿里云，扩展了丰富的事件源，比如当OSS接收到用户上传的一个视频片段，触发容器中的应用进行视频转码。
- Serving- 提供了灵活的服务响应能力，可以根据业务的请求量自动弹性伸缩，甚至支持缩容到零。利用阿里云弹性基础设施，可以大大降低资源成本。
- Tekton - 可以轻松实现从代码到应用部署的自动化流水线，
结合应用管理能力和应用性能监控服务, 我们可以基于Knative快速地搭建具备领域特色的应用托管服务 (Micro PaaS)，大大降低直接操作 Kubernetes 资源的复杂度，让开发者更加专注于应用迭代和服务交付效率提升。
传统的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服务网格技术自身的复杂性
- 其次是规模化带来的稳定性和性能的挑战挑战：在海量的服务的情况下，控制平面是否可以支持服务配置的高效分发；数据平面是否可以尽可能降低增加两跳后的通信延迟；下沉可观测性和策略管理能力到数据平面，避免集中化Mixer引入的性能瓶颈等。
- 最后是和现有的微服务架构兼容并存，支持现有微服务的统一配置管理服务和通信协议。
为了解决上述挑战，阿里巴巴和蚂蚁金服与Istio社区兼容的技术体系上，构建了服务网格能力。在今年 618 蚂蚁金服已经完成核心系统上到 SOFAMosn 的验证工作，在马上来临的今年的双 11，阿里巴巴和蚂蚁金服将会在核心系统大规模上线 Service Mesh。同时阿里经济体会把自身技术演进的结果及时反馈到上游去，与社区共同推进Service Mesh发展。比如在阿里开源的服务发现与配置管理项目Nacos最新版本中，就提供了Istio对 MCP协议支持。
晚些时候，阿里云会推出托管 Service Mesh 服务，帮助云上的开发者能够便捷地使用服务网格技术。
Kubernetes为分布式应用管理提供了很多基础的元语抽象，比如面向无状态应用的Deployment和面向有状态应用的StatefulSet。但是在企业生产环境中，面对应用的不同需求，现有能力还存在一些不足。参加技术分享我们经常会听到每个企业都在谈如何修改K8s来解决自己的问题，这里面很多问题都是相似的。
作为云原生技术的引领者，阿里巴巴将我们在云原生计算技术上大规模生产的最佳实践沉淀下来，以开源项目OpenKruise的方式与社区开放、共建。一方面帮助企业客户在云原生的探索的过程中，少走弯路，减少技术碎片；一方面推动上游技术社区，逐渐完善和丰富Kubernetes的应用周期自动化能力
比如，以如下几个新的控制器为例
- Broadcast Job，可以让任务运行在机器上指定的节点，比如我们要在节点上安装安全补丁。或者在节点上预先下载一个容器镜像。
- Sidecar Set：越来越多的运维能力，以sidecare方式提供，比如日志、监控、和服务网格中的数据平面组件Envoy；我们可以通过Sidecar Set以声明式方法管理sidecar的生命周期
- Advanced StatefulSet: 支持原地发布和并行升级，
这些控制器解决了很多客户的真实痛点。
此外，在10月，阿里云联合了微软一起发布了开放应用模型 Open Application Model（OAM）
OAM 是一个专注于描述应用生命周期的标准规范，可以帮助应用开发者、应用运维人员和基础架构运维团队更好地进行协同。在这个模型里，开发人员负责定义应用组成、依赖与架构；应用运维人员负责定义应用运行时配置与运维需求，比如发布策略和监控指标，而基础架构运维团队可以针对应用部署环境的不同，配置定制化参数。
通过这种关注点分离（Separation of Concerns）的设计，可以将应用定义、运维能力与基础设施实现解构。让应用交付变得更加高效、可靠和自动化。
随着5G时代的临近，低延迟网络、AI硬件算力提升、和智能化应用快速发展，一个万物智联的时代必将到来。将计算能力从云延展到到边缘侧、设备侧，并通过云进行统一应用交付、资源管控，将会是云计算发展的必然趋势。
基于容器，我们建立了云边端一体协同平台，ACK@Edge这样我们可以将一些需要低延迟处理的应用部署在边缘节点实现就近访问，比如，我们可以把AI模型预测和实时数据处理放置到边缘，进行实时智能决策；而将模型训练，大数据处理等需要海量算力应用放到云端。
ACK边缘版提供了统一管控能力，在K8s集群中可以同时支持云端ECS和边缘ENS节点、以及IoT设备。并且针对边缘的特殊性，提供了单元化隔离和断连自治、自愈能力。我们已经在阿里云视频云、优酷等场景中开始大规模应用。
我们以优酷筋斗云为例介绍其计算架构演进。优酷是国内最大的视频平台，随着优酷业务的快速发展，需要将原来部署在若干IDC内的集中式架构，演进到云+边缘计算的架构。这时候需要一种方式来统一管理阿里云十几个region和众多的边缘节点。优酷选择了ACK@Edge，可以统一管理云与边缘的节点，并实现了统一的应用发布和弹性扩缩容。
通过弹性能力，节省了机器成本50%。采用新的架构之后，用户终端可以就近访问边缘节点，让端到端网络延迟降低了75%。
云原生技术的发展离不开社区的成长和壮大，阿里巴巴全面拥抱云原生技术，并将我们在大规模生产最佳实践回馈到社区，与社区共同建设更加美好的云原生计算。
