如何优雅地把握 Serverless 和 Serverful 的平衡点？

Posted 2021-08-18 QcloudCommunity

导语 | Serverless 拥有运维和成本优势，但通常需要业务改造。腾讯云弹性容器服务可使容器化用户无需关心节点运维且无需业务改造的情况下，灵活地在 Serverful 与 Serverless 架构间迁移。本议题介绍了相关技术与实现。本文由腾讯云容器产品技术总监 于广游在Techo TVP 开发者峰会 ServerlessDays China 2021上的演讲《腾讯云弹性容器服务EKS：Serverless与Serverful的优雅平衡点》整理而成，向大家分享。

点击可观看精彩演讲视频

一、从Serverful到Serverless

我今天分享的题目是“腾讯云弹性容器服务EKS Serverless 与 Serverful 的优雅平衡点”。内容主要分为三个部分，第一部分谈谈从 Serverful 到 Serverless 的演进，第二部分讲讲腾讯云服务EKS怎么做到平衡，最后是未来展望。

我先谈谈我心中的 Serverless 是什么。但是谈 Serverless 之前，想先谈一下我心中的云计算是什么。从业之后，这个问题我思考了非常久，后来我意识到云计算跟第二次工业革命非常像，虽然说得有点远。19世纪末期，是电力、灯泡、工厂刚刚出现的时候。每家企业开一个工厂，需要从头制造火电站，发电系统，这其实是第二次工业革命前期的时候社会的现状。我们做云计算的时候，一开始也面临这样的现状，现在是信息革命，我们希望信息革命能够延伸到各行各业。但每个企业想构建自己软件的时候，都需要先构建自己的私有云。

在2010年之前，有两家科技巨头——AWS和Google，基于对云计算不同的理解提出了两种不同的形态。AWS认为云计算是水和电，我要做的事情就是建国家电网，所有人想创业的时候，只需要插入到国家电网的系统中，就能够取得电力。谷歌不一样，它认为一个企业要创业，生产产品，需要电力、代工厂、设计，最终出来产品，我不如直接为你提供代工厂，谷歌认为云计算是PaaS，要提供一个产品GKE。这是我们最早看到的云计算两种产品的区别，由于两个厂商心中的云计算概念不一样，最终衍生出不同的产品形态。

事实上我们发现，AWS（认为云计算是水和电）的IaaS路线发展得非常好。而直接给一个代工厂，但事实上你用我的代工厂，需要接入设计体系、产品体系、流水线，在公共国家电网都还没有普及的情况下去推广，是非常危险的。这是我想谈的第一个观点，关于“云计算是什么”，和大家分享我看到的观点。

到2014年的时候又发生一件事，谷歌推出GKE，AWS推出Lambda，这一次产品推出也是基于对云计算理解不同而推出的，谷歌认为到了2014年已经不仅仅是云计算是什么的问题，而是怎么去用好云计算，发挥业务的最大价值。谷歌说：怎么用好云计算？用云原生的方式，开放、标准、多云的技术体系，用这套体系就能够把云计算用好。AWS说：云计算的下一步叫 Serverless，不需要关注任何的技术，不需要关注任何的运维，只需要用我提供给你的这样一个产品，就能够用好云计算，获得业务的巨大成功。其实从这个角度来看，云原生和 Serverless 在本质和目标上来看是一个东西，用这个东西，只要用了就是灵丹妙药，能够解决一切的运维问题，得到业务的最大创新，但其实路径不一样。云原生强调的是开源、中立、多云。Lambda和函数体系强调的是极致、专有、个性化。

为什么这样强调？除了技术问题，其实没有很强的商业目的。谷歌在云厂商竞争中比较靠后，用户不愿意搬迁，所以强调说要开源、多云，希望用户赶紧搬迁。而AWS已有庞大的客户体系，希望提供更多更好的服务，就强调函数。但是他们希望达成的目标是一样的，只是过程不一样。有意思的是，上一次AWS推出了低层抽象的产品，Google推出了高层抽象的；这一次相反，AWS推出了高层抽象的产品，Google推出了低层抽象的；但无论如何，云计算又向前一步，出现云原生和 Serverless。由于K8s体系通用、开源，甚至一开始就成立了CNCF（云原生计算基金会）去推广，使得它比 Serverless 影响更大。

我们把刚才的四个技术放在一起，其实从最左端的 Serverful 虚拟机和物理机到最右端的 Serverless，给用户提供的抽象层级越来越高，更少关心运维，弹性能力更强，计费模式更加灵活。曾经需要按照主机的一流资源收费，现在只需要按照真实使用的函数收费，使我们获得更好的价值。但从左往右的技术，随着封装层级提高，本身的灵活度下降了，迁移成本变得更高了。我们会发现，Serverless 似乎跟通用性和迁移成本是一个不可调和的矛盾。这其实也是我们推出EKS产品的背景。

我们进行详细的对比，K8s和FaaS，本次讨论的语境中的 Serverless，某种情况下强调的是 Serverless 的意义，某种情况下强调的也是FaaS。对比两者，K8s的通用性非常强，开源，迁移成本非常低，如果是微服务就很容易迁移上来；FaaS的优点是完全免除运维，有非常强的业务价值。不足之处是K8s的节点非常复杂，而FaaS的不足之处是迁移成本非常高。

我们细看一下这样的迁移成本，和K8s维护的工作。K8s的架构分为Master（控制器）和Node（云主机、物理机），我们要使用好一个K8s集群，除了要把Master用好，还有大量的节点运维工作。节点中有内核需要维护，有资源需要规划，有各种各样的隔离性问题。最关键的是，我们之前的Linux内核更多的是为业务的独立部署去设计，在隔离、资源非常紧张的情况下，稳定性非常不好。所以我们用K8s真的有巨量的维护工作，但是它的价值又非常好。我们就想，能不能有一种产品，既兼顾K8s的通用性、迁移成本非常低，又能够像 Serverless 一样，不用运维、获得非常高的业务价值？进行分析后，我们发现K8s的价值主要是K8s API带来的通用性，可扩展性和可一致性。主要的维护成本在于节点server维护的工作，有没有一种办法可以保留K8s的能力，但是又消除node的维护成本，是不是就能够取得 Serverful 和 Serverless 之间的平衡？

二、腾讯云EKS：渐进式的Serverless方案

答案当然是可以。在这样的背景下，我们推出新的产品——EKS，腾讯云的弹性容器服务。

容器服务，一般都是由K8s托管服务。我们方案的独特之处，是把本身是云主机的节点，替换成一个虚拟节点。它就是一段程序，这段程序告诉K8s说我是一台机器，CPU无穷大，内存无穷大；K8s调度给这台机器的任何一个容器，会把任务下发给腾讯云的整个大池子。通过这样的技术，每个K8s集群不太有云主机，只需要虚拟节点，这个虚拟节点无穷大，对于K8s任何的请求都会调度到虚拟节点上，进而把请求发送到腾讯云，通过这样的架构，得到什么价值？我们得到了一个完全兼容K8s API的集群服务；同时，我们又有一个无穷大的免运维的节点。我们的业务不需要再去按照虚拟机和物理机交付，而是按照容器交付。弹性收缩能力，不需要先申请虚拟机再申请容器，获得了非常高的弹性深度的能力。

我们接下来针对免运维弹性和成本进行简单的对比。在没有nodeless架构之前，我们有非常大的节点资源规划、问题定位、升级维护的工作。有了它之后，就完全不需要去关心这些工作了，这是抽象给我们带来的价值。

再做一个弹性的自举，严格来说使用虚拟机的时候一般不进行弹性，因为虚拟机的购买消费不是重要问题，重要的问题是我们购买之后，业务怎么自动部署、自动注册、进行健康检查、进行切流。使用K8s的时候，我们大部分情况先会进行弹性伸缩。一个很关键的问题是，需要两层的弹性伸缩，需要先伸缩我的容器，然后容器调度不起来了，没有足够的机器，再去伸缩机器。同时，不同业务的容器会在一些云主机或者物理机上进行混布，造成能伸不能缩的效果。弹性伸缩的意义就非常低，只能用它来应对流量突发，而无法对它进行成本的节省。使用EKS的架构情况下，这显而易见是非常容易的，只需要对业务容器进行弹性伸缩，就能够获得极高的资源利用率。根据现有的调查，使用虚拟机的情况下，通常10%左右；使用K8s，普通情况下20%，好的情况下30-40%。Master也有非常高的兼容性。

接下来再介绍比较特殊的能力，虚拟节点能力。在EKS这样的产品中，最关键的技术在于虚拟节点技术，通过一个虚拟节点能够消除节点运维，提供非常好的抽象。可不可以延伸一下？虚拟节点能否不要只插在我们的集群中，放在其他的K8s集群中。答案是当然可以，目前来看有三种使用模式。EKS作为虚拟节点，把它插入用户已经自建的K8s集群中，只需点击一个按钮就可以变成 Serverless 化的K8s集群。可以通过K8s的调度策略，动态地让你的业务运行在物理节点、虚拟节点上，不需要任何的迁移成本，只需要一个简单的调度策略，就可以完成整个业务架构的微服务化改造，这是第一个使用场景。

第二个使用场景，混合云场景。假设在IDC中有非常庞大的K8s集群，不可能整个去掉，传统情况下混合运营的方案，是由云厂商给你一揽子的方案。我们基于EKS的nodeless架构，有非常优雅的混合云方案，可以把K8s集群作为虚拟节点，插入到普通的K8s集群中去。这样可以通过非常简单的策略，把你的业务进行混合云架构的改造。

第三个场景，大数据容器化的场景。通常我们用yarn对大数据业务进行调度，node部署在物理机和云主机中，一般情况下不能进行弹性伸缩。我们的EKS支持指定已经存在的，跑得非常好的大数据集群，能够把EKS作为大数据集群的虚拟节点存在。接下来对于大数据发任务的时候，可以指定一些调度策略，动态地把一部分任务运行在现在的大数据集群现在的节点上或是EKS节点上，通过这样的方式，就能够做到大数据集群渐进式的 Serverless 的改造。

这是我们一个非常典型的客户案例，有非常多离线、在线业务，希望提升资源利用率，我们帮他们的业务进行整体的容器化改造，同时使用了大数据进行容器化的方案，能够让客户随时运行大数据的计算任务，动态扩缩出一个EKS的pod，最终达成资源利用率非常高的提升。

三、总结与展望

说说未来展望。Serverless 最关键的点，是有没有降低运维成本，有没有真正地按需计费，有没有完成一些真正的弹性？根据刚才的描述，其实它的计费、弹性还是不够完全 Serverless 的。下一步的计划是让它的弹性不再按照容器实例计费，而按照容器实例实际使用的CPU核实计费，弹性指标也根据业务伸缩。

最后是我的一些简单的思考，随着技术的发展，确实是会有层出不穷的名词，对于每个名词，大家都会有层出不穷的解释，每个解释都让我们非常困惑，到底什么是云计算、云原生、Serverless？有的解释说了好像等于没有说，希望在座以及所有线上的开发人员能够习得一种能力，这种能力是能够看破这些概念的表象，抓住它的本质，之后我们的业务、技术就能够往前走，每个技术会更加通用，兼容不同的场景。

讲者简介

于广游

腾讯云专家工程师

腾讯云专家工程师，腾讯云容器技术总监，主导了腾讯云容器产品从0开始的设计、研发和运营工作，并在腾讯云海量k8s集群的治理和落地过程中积累了大量的经验。腾讯自研业务全面云原生上云的主要参与者之一，在云原生领域有丰富的实践和思考。当前致力于k8s在 Serverless、混合云等场景的探索。

推荐阅读

微服务和 Serverless 如何强强联合？

Function Mesh：Serverless 在消息与流数据场景下的火花

初创企业的福音，还有这么贴心的云原生数据库？

用了 Serverless 这么久，这里有其底层技术的一点经验

---

???? 错过了直播懊悔不已？本次峰会所有嘉宾的演讲视频回顾上线啦，点击「阅读原文」即可观看~

???? 看视频不过瘾还想要干货PPT？关注本公众号，在后台回复关键词「serverless」即可获取！