AWSLambda是serverless领域的标志性产品，但是如果应用到核心业务中，可能会遇到以下困难：（仅代表作者个人观点）需要用户以Functions为单位进行开发，一个新的开发框架、云厂商绑定强，社区主流技术栈迁移成本高；Functions的启动速度必须足够快，以毫秒或秒为单位。长的。CloudServiceEngineCloudServiceEngine（以下简称CSE）是阿里云中间件团队针对通用Serverless计算开发的一款中间件产品。问题。什么是无服务器？AWS对Serverless的定义是：（来自AWS官网）AWSserverless平台提供的功能：（来自AWS官网）AWS完整的serverless解决方案非常完善，但是没有解决存量应用如何迁移到serverless的问题建筑学。仅对于新开发的应用，建议用户使用FaaS开发，这样才有机会切换到Serverless架构。笔者认为，要大规模推广Serverless架构，必须要有针对现有业务的解决方案。Serverless对云计算的价值云计算归根结底是一种IT服务提供模式。无论是公有云还是私有云（根据IT设备的归属不同分类），其本质都是帮助IT终端用户随时随地，轻松快捷地获取IT服务。目前IaaS和PaaS已经实现了按需付费，PaaS甚至实现了按请求付费，如DB、CACHE、MQ等，但是IaaS的付费粒度仍然是时间维度，最快按小时支付，按分钟送达。因此，在当前的云计算场景下，应用的开发和维护方式与传统IDC时代并没有太大区别。而AWSLambda提供了一种全新的开发和维护方式。用户只需要编写业务代码，提交到云端即可。所有与机器容量、可用性、机器单元相关的运维工作都可以交给云平台。该模式极大释放了云的弹性价值，真正做到按需付费。CSE试图提供更大规模的解决方案。与AWSLambda一样，可以进一步释放云的弹性价值，平滑迁移现有应用。现有线上业务实施Serverless架构的挑战现有线上应用有以下特点：资源分配速度=分钟级应用启动速度=10分钟+基于以上客观条件，通常的做法是提前预留机器数量来应对随时都有流量高峰，假设上述技术参数变化到毫秒级，就有机会将应用架构演化成下图所示的方式。上图中，ServiceA调用ServiceB时，如果B的容量足够，则调用成功；如果B的容量不足，如果此时线程池已满，则直接触发限流阈值，A收到错误码，然后直接调用资源主控系统。资源总控系统负责新分配一个ServiceB实例。这种分配非常快，需要几十毫秒。完成的请求发送给新创建的ServiceB。以上过程对开发者是完全透明的，有以下值：值1：不需要管理服务器，即不需要进行容量评估；容量评估一直是应用领导者的一个极其困难的问题，因为我们很难预测未来的峰值是什么。价值二：持续扩张；以前的做法是每个应用独占一定的资源。如果变成Serverless模式，所有应用都可以共享资源池，每个应用几乎都可以完全扩展。值3：按请求计费；因为每个实例的启动时间甚至比FaaS的函数启动时间还要快，所以可以像FaaS一样计算成本，成本只和以下几个因素有关：请求数量（QPS）CPUperrequest执行时间，比如100msMemoryspecificationforeachinstance总结一下：要实现上面描述的分布式架构，关键的技术点就是应用程序的启动速度。这里的应用启动速度是指应用可以正常处理流量。如何将应用启动速度提升到毫秒级？在应用程序启动过程中，通常会初始化多个组件，如各种中间件、数据结构、对外部服务的网络调用等。在阿里大量使用SOA和微服务的情况下，应用在启动过程中会加载大量的共享业务SDK。存在启动过程达到10分钟量级的情况，个别应用程序可能需要更长的时间。所以这个启动过程必须提前完成，才有机会以“磨枪”的方式创建新的实例。方案一：应用冷启动资源压缩方案L1弹性是指在一台物理机或大型ECS上部署同一个应用的多个实例。通过操作系统和JVM的优化，一个占用4G内存的应用可以部署10个副本只占用2.2GRAM。综上所述，L1是一种高密部署方式。由于应用已经提前启动，容器被冻结，也就是说这个应用实例的CPU使用率是0，RAM使用率相当于之前的1/20，但是它具有毫秒级的能力变通。L1的特点是启动速度极快，但是很耗资源，只能垂直弹性。L2是将应用程序启动后RAM中的指令和数据结构转储到磁盘文件中，只需要在机器之间拷贝文件即可实现水平的灵活性。这个时间消耗主要是数据的网络传输时间+内存拷贝时间，大概5秒左右就可以完成。L2的成本开销仅为网盘容量，极低，可以忽略不计。L2的每个SNAOSHOT对应一个可运行的实例。比如一个应用预计启动100个实例，那么需要提前生成100个SNAOSHOT。每个SNAOSHOT对应一个正在运行的实例。当需要启动时，从远程磁盘SNAPSHOT加载它。该方案通过L1和L2的结合达到加速应用启动的目的。具有一定的流量脉冲能力，任何应用可以在50ms内启动，平均10ms内完成。方案二：应用热拷贝启动加速方案L1使用forkseed进程来达到快速启动的效果。操作系统团队为此开发了fork2技术。与LinuxNativefork的主要区别在于您可以指定PID来fork一个进程。pid_tfork2（pid_tpid）；L2的单个SNAPSHOT可以创建多个进程，一对多关系。两种自研方案对比方案一：没有UUID问题，但是需要为每个语言单独定制VM，性价比比方案二略差。方案二：会有UUID问题。如果开发者想在应用程序的每个实例启动时都分配一个UUID给一个静态变量，但是通过fork，每个实例的静态变量都是一样的，这不符合开发者的预期。.方案二的优点是更容易实现，与语言无关，性价比更好。适用于FaaS、NBF等场景或者开发者自己定义的开发框架，可以避免UUID的问题。综合来看，方案一适用场景更广，但实现成本较高，方案二更适合FaaS、NBF等场景。与AWSLambda相比，为了实现快速扩缩容，Lambda要求用户的应用程序以Functions为单位进行开发，LambdaRuntime动态加载Functions以快速增加实例。CSE启动一个应用程序的多个实例并共享相同的指令数据以提取不同的指令数据。每次启动实例时只需要加载多个实例之间的差异。因此可以透明兼容社区主流技术栈，如SpringBoot、PHP/Java/Python/Node.JS等。CSE成本优势理论模型：serverless应用占用实例数随时变化时间，因此多个应用程序可以在交错的高峰期使用同一台机器。量化分析：Serverless的成本优势可以和CPUShare&OfflineHybrid等调度技术的成本优势叠加，给终端用户更好的综合成本。CSE的代码示例HSFdemopackagecom.test.pandora.hsf;importcom.alibaba.boot.hsf.annotation.HSFProvider;@HSFProvider(serviceInterface=HelloWorldService.class)publicclassHelloWorldServiceImplimplementsHelloWorldService{@OverridepublicStringsayHello(Stringname){return"hello:"+name;}}SpringBootdemopackagecom.example.java.gettingstarted;importorg.springframework.boot.SpringApplication;importorg.springframework.boot.autoconfigure.SpringBootApplication;importorg.springframework.web.bind.annotation.RequestMapping;importorg.springframework.web.bind.annotation.RestController;@SpringBootApplication@RestControllerpublicclassHelloworldApplication{@RequestMapping("/")publicStringhome(){return"HelloWorld!";}@RequestMapping("/health")publicStringhealthy(){//Messagebodyrequiredthoughignorereturn"Stillsurviving.";}publicstaticvoidmain(String[]args){SpringApplication.run(HelloworldApplication.class,args);}}CSE的生产实践跟某电商业务A：serverless之后，机器数量从11台减少到2台（在2到10之间波动）。某大促节期间，业务峰值流量瞬间从几千暴涨到十万多，CSE瞬间弹性膨胀，从2台-->5台-->10台，流量峰值下降后收缩到2台机器。某电商业务B：serverless之后，机器数量从4台变成2台（在2到10台机器之间波动）。某电商业务C：之前固定4台机器，serverless完成后机器数变为1台（在1-4之间波动），预发布可以实现0-1实例之间的波动。本文作者：王晓睿：华明世家，阿里巴巴资深技术专家，ApacheRocketMQ创始人&董事长，近期负责推动阿里巴巴在线业务向Serverless架构演进，消息中间件产品线云计算方向，是阿里巴巴软件中心创新项目实验室&消息中间件团队负责人。
