Serverless AI训练营:课时6:如何通过 0 改造,享受 Serverless 技术红利(三)
课时6:如何通过 0 改造,享受 Serverless 技术红利(三)
在常规的SAE架构下,上层有 pode、continue 的一个概念,但底层实际上是一个容器。 Serverless 这种产品形态其实是不适合的,为什么呢?因为传统的容器不太适合工云场下的多组环境,共享内核让他有被穿透的风险。
所以我们实际上采用了安全容器,安全层面上的虚拟机,但这个层面又符合开发S下的容器。虚拟机的安全其实通过acs就知道,他是经过考验的,所以他跟开发S结合以及容器生态的结合,就是一个非常好的一个方案。
比如我们在用户的层面他会有不同的命名空间,命名空间其实是可以部署在不同的VPC,他是相互隔离的。然后再看开发S层面他也有一个命名空间,他也是隔离的。底层通过一个技术来隔离,接下来详细说一下。
业界有几种主流的安全容器的相关技术,包括 Kata 、 Firecracker 、 gVisor 。因为他是一个最早、也是最成熟的一个技术来实现的一个安全容器。并且她不但做到了一个安全的隔离,还实现了性能与故障的隔离。
举一个最简单的例子,在传动ross共享模式下,如果有一个容器引起了内核故障,那么很有可能整个物理机都得崩掉。在安全容器的一个环境下,他其实没有这样一个风险。
3.极致弹性 极致成本
前面大概介绍了 Serveless 中最核心的一个资源隔离,抑制网络隔离的技术。接下来介绍Serveless 另外一个核心,也就是极致弹性、极致成本。一个非常简单的道理,如果弹性的效率越高,他越能达到一个极致,贴近业务真实需求的一个成本。
如果最开始仅仅是部署在ess这种,没有很好的弹性的话,那么可能造成非常大的资源的浪费,还有可能因为评估不足造成资源的受损。比较理想的情况下是能够尽快的弹出来,通过业务相关的一些指标,比如CPU、内存都可以作为一个弹性的指标,做成更贴近业务需求的一个资源的容量。具体我们是如何做相关的一个建设以及努力呢?
5. SAE极致弹性建设:部署&重启
在最开始我们可以看到标准的pode创建的过程是从调度到 init container 创建再到拉取镜像,创建用户容器、启动用户容器&应用,最后再运行应用。整个过程非常长,阶段也非常多。我们会持续在每个阶段做一些提高效率方面的建设。
首先是SAE原地升级的一个策略,标准开发S项目下,涉及到调度以及init container 的创建,然后我们借助了阿里巴巴的一个负载,实现了原地升级,效率提升了42%。他的核心的原理就是省去了 pode 的重新调度,以及容器创建的时间。他只是重建里面的一个容器。另外的话,在镜像拉取方面,我们做了镜像预热,把原来串起来调度改成并起来调度。也实现进一步的效率提升。另外用户在启动进程方面特别是 java 的一个生态,我们也做了一个特定的增强。
6. SAE极致弹性建设:Java启动加速
比如说我们知道 Java 相比其他语音,启动速度一直是它的重点,原因在于Java的加载机制需要对应每一个类,就是每一个加载进行便利解析及加载。
那么阿里巴巴实现了APP CDS 他们的核心原理就是将相对于比较缓慢的cas一个个加载的过程达到一个压缩包中。其实只需要一次性加载这个压缩包就可以了。在最简单的Java启动,Java应用以及Spring book 的场景可以提升45%的效率。
7. SAE极致弹性建设
在微服务场景,我们通常会有较做的一个线程,原生的微服务,他的一些线程都是对应到了操作系统的线程。他们在高平发的场景下,会有一个较大的线程调度的开销。
SAE是结合了阿里开源来加工Y11实现的一个加速,将原来的Java原生线程协程化,100个线程可能对于底层就是10个线程,极大的降低了线程切换的一个开销。这是我们实测压测的一个结果,可以看到至少有20%的提升。
四、总结和展望
首先我们分析到了微服务场景下的优势以及额外带来的一些比较大的一个复杂的新的一个生态组件。阿里云 Serveless 应用引擎将 Serveless 的一个理念发挥到了极致,从最底层到上层的开发S、应用Pass、CI/CD、微服务套进来的一个机制,客观性的一个增强都做了 Serveless 化的一个托管。用户根本不需要感知各方面的东西,他只需要用就行了。它不需要感知功能提供者,不需要感知组件的运维。
实际上 Serveless 对于微服务场景下完整的一个举止方案。未来的话SAE也会在每一个模块做持续的一个能力增强。包括应用层Pass层面,对越来越多的云产品,CI/CD等做更好的继承。
以及企业级能力的增强,比如说我们会做一些审批,应用发布/变更一定要等到上级审批才能做,尽量减少误操作或者恶意操作带来的一些困难,或者一些不可预计的毁灭性的成果、效果。
另外,在 Serveless 我们持续会优化弹性能力,会有越来越多的弹性指标、弹性效率、弹性预测,在底层方面我们会做一个技术的发明,其实SAE的使用是非常便宜的,因为是按分钟计费,对于不同的测试开发环境,它可以做到一键齐停。
比如白天我可能需要开发测试,我可以把整个环境一键激起来,到晚上开发测试环境就不需要了,我可以把整个环境都全部停掉。然后在微服务组件生态我们会集成越来越多的微服务组件,做到端到端的解决方案,解决开发者在面对微服务技术时的门槛。
比如说故障组、全面组压测。最后在可观测层面,其实平台内部已经在持续做一些能力的建设,在 Serveless 场景下将复杂度由用户交给平台,相对于把复杂的东西交给平台。怎么好去运维这么多应用,其实也是我们的核心能力。这对于目测我们也会考虑像应用大盘试用中心这些能力,接下来再做开发。