网站开发前准备,网渠道,网站建设中的风险,做网站一年费用Cloud Service Engine#xff0c;简称CSE#xff0c;是中间件部门研发的面向通用Serverless计算的中间件产品#xff0c;目标是具备AWS Lambda的各种优势#xff0c;同时可以解决AWS Lambda的关键技术缺陷。
AWS Lambda如果用于核心业务#xff0c;可能会有以下缺陷…Cloud Service Engine简称CSE是中间件部门研发的面向通用Serverless计算的中间件产品目标是具备AWS Lambda的各种优势同时可以解决AWS Lambda的关键技术缺陷。
AWS Lambda如果用于核心业务可能会有以下缺陷仅代表个人观点
要求用户以Function为单位开发全新的开发框架云厂商强绑定。社区主流技术栈迁移成本高。Function启动速度要足够快毫秒级或者秒级这个限制对适用场景有很强的约束。Function之间的调用通过API Gateway响应时间更长。
CSE目前在集团内测中本文非完整产品介绍Serverless话题涉及范围极广几乎包含了代码管理测试发布运维扩容等与应用生命周期关联的所有环节。本文主要回答个人在探索这个方向时的思考以及中间件部门正在做的解决方案目标是尽可能让开发者少改代码甚至不改代码就能具备AWS Lambda的技术优势。
我认为的Serverless是什么
AWS对Serverless的定义 以上观点来自AWS官网 链接 AWS 定义的Serverless包含了哪些功能项 个人的补充观点
个人对Serverless的观点仅在AWS上补充AWS的整个方案非常完善但是没有解决存量应用如何迁移到Serverless架构仅仅针对新开发的应用建议用户用FaaS方式开发才有机会变成Serverless架构。 要将Serverless架构大规模推广必须要能有针对存量业务的解决方案。 Serverless在云计算中的位置是什么
云计算归根结底是一种IT服务提供模式不论是公共云还是专有云以IT设备的归属不同分类其本质都是IT的最终使用者可以随时随地并且简便快速地获取IT服务并以获取服务的层次分为IaaS、PaaS、SaaS。目前看IaaS、PaaS都已经做到了按需付费。PaaS甚至做到了按请求付费如DBCACHEMQ等但是IaaS的付费粒度仍然是时间维度最快按照小时付费按照分钟来交付。
基于以上现状应用的开发维护方式相比传统IDC模式的开发维护差别还不是很大而AWS Lambda提供了一种全新的方式只需要用户写业务代码提交到云上所有和机器容量可用性机器为单位的运维工作全部交给了云平台这种模式极大的放大了云的弹性价值真正做到了按需付费。
本文试图提供一种更规模化的解决方案像AWS Lambda一样能继续放大云的弹性价值并且是可以兼容存量应用。
现存在线业务演变成Serverless架构的关键挑战是什么
当前的在线应用程序具有以下特点
资源分配速度 分钟级应用程序启动速度 10分钟
基于以上客观条件通常做法是提前预定好机器数量来应对任意时刻的流量峰值假设上述技术参数变为毫秒级就有机会将应用程序架构演变成下图所示方式。 上图中Service A在调用Service B时如果B的容量充足调用成功如果B容量不足这时候可能是线程池满可能直接触发限流阀值A会收到一个错误码A会直接调用资源总控系统资源总控系统负责新分配一个Service B实例这个分配的速度非常快耗时几十毫秒同时把B的服务地址直接返回给AA将之前未完成的请求发送到新创建的Service B。 以上过程对于开发者完全透明具备了以下价值 价值一无需管理服务器意味着无需容量评估容量评估这件事情对于应用负责人一直是一个极难解的问题因为我们很难预测未来的峰值是什么。价值二持续扩展之前的做法是每个应用程序独占一定数量的资源如果变成Serverless模式意味着所有应用程序共享资源池也意味着每个应用程序几乎可以无限扩展。 价值三按照请求计费因为每个实例的启动时间甚至比FaaS的函数启动时间还快就可以像FaaS一样来核算成本成本只与以下因素有关 请求数量QPS每次请求CPU执行时间例如100ms每个实例的内存规格综上所述为了做到以上描述的分布式架构关键技术点在于应用启动速度这里的应用启动速度是指应用可以正常处理流量为止。 如何将应用启动速度加速到毫秒级
应用在启动过程中通常会初始化多个组件如各种中间件各种数据结构以及网络调用外部服务在阿里内部广泛推广SOA微服务情况下会大量加载共享业务SDK会存在启动过程达到10分钟量级的情况个别应用可能会更长。 因此这个启动过程必须提前完成才有机会临阵磨枪的方式去创建新实例。 方案一应用冷启动资源压缩方案 L1弹性能力是指在一台物理机或者大规格的ECS上部署同一个应用的多个实例通过操作系统和JVM的优化一个占用4G堆内存的应用即使部署10份仅需占用2.2G RAM。以线上菜鸟生产应用为例。
L1总结来看是一种高密度部署方式由于应用已经提前启动并且对容器进行冻结意味着这个应用实例CPU占用率为0RAM占用相当于之前的1/20但是具备了毫秒级弹性的能力。L1的特点是启动速度极快但是需要消耗资源且只能垂直弹性。
L2是通过将应用程序启动后在RAM中的指令和数据结构 dump到磁盘文件只需要在机器之间拷贝文件即可以达到横向弹性的能力这个时间消耗主要是数据的网络传输时间内存拷贝时间大约在5秒左右可以完成。L2的成本开销只有网络磁盘容量开销极低可忽略不计。
L2的每个SNAOSHOT对应一个可运行的实例例如预计一个应用需要最大启动100个实例那么需要提前生成100个SNAOSHOT每个SNAOSHOT对应一个运行实例需要启动时从远程磁盘加载这个SNAPSHOT。 此方案通过L1和L2的组合来达到加速应用启动的目的在支持一定流量脉冲能力下可以最大50ms内启动任意应用平均在10ms内完成。 方案二应用热复制启动加速方案
L1采用通过fork种子进程达到快速启动的效果操作系统团队专门为此开发了fork2技术与linux native fork的关键区别是可以指定PID来fork一个进程 pid_t fork2(pid_t pid);
L2的单个SNAPSHOT可以创建多个进程一对多关系。
自研两种方案对比
方案二会存在UUID问题如开发者希望应用每个实例启动都赋值一个UUID给一个静态变量而通过fork会导致每个实例的这个静态变量都相同与开发者预期不符。 优势是整个方案更易实现语言无关成本效果更优。
适合FaaS、盒马NBF这类场景或者开发者自己定义开发框架能避免UUID这种情况的 场景使用。
方案一不存在UUID问题但是每种语言的VM要单独定制成本效果相比方案二略差。整体来看方案一的适用场景更广但是实现成本更高方案二较适合FaaSNBF这类场景。 与AWS Lambda方案对比 Lambda为了做到快速扩缩容要求用户的应用以Function为单位开发Lambda Runtime动态加载Function来快速增加实例。
CSE通过将一个应用的多个实例启动后共享相同的指令数据抽取出不同的指令数据每次启动实例只需要加载多实例的差异部分。因此可以透明兼容社区主流技术栈如Spring BootPHP/Java/Python/NodeJS等。
CSE的成本优势
理论模型 Serverless方式应用占用的实例数随时在变化因此可以多个应用错峰使用同一台机器。 量化分析 Serverless的成本优势是可以和CPU Share离在线混部等调度技术的成本优势做叠加能给最终用户一个更优的总体成本。 CSE的代码样例
HSF demo
package com.test.pandora.hsf;import com.alibaba.boot.hsf.annotation.HSFProvider;HSFProvider(serviceInterface HelloWorldService.class)
public class HelloWorldServiceImpl implements HelloWorldService {Overridepublic String sayHello(String name) {return hello : name;}
}
Spring Boot demo
package com.example.java.gettingstarted;import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;SpringBootApplication
RestController
public class HelloworldApplication {RequestMapping(/)public String home() {return Hello World!;}RequestMapping(/health)public String healthy() {// Message body required though ignoredreturn Still surviving.;}public static void main(String[] args) {SpringApplication.run(HelloworldApplication.class, args);}
}
CSE的成功案例
盒马p0级服务文描在双十二场景验证中机器数量从11台到2台2~10台之间波动。3.8女王节的最新数据盒马导购域的P0级服务流量峰值从4000瞬间飙到12万CSE瞬间弹性扩容从2台--5台--10台流量峰值回落后又缩容到2台。 盒马p0级服务天气在双十二场景验证中机器数量从4台到2台2~10台之间波动。1688的buyer-tools应用之前固定4台机器serverless化完成后机器数量变成1台1~4台之间波动。预发可实现0 ~ 1台实例之间波动。CSE的约束和限制
高脉冲型流量业务消耗的成本会更高。应用尽可能避免后台活动线程的CPU消耗。应用尽可能无状态。应用尽可能使用短连接长链接要能支持断线毫秒级重连能力。
原文链接 本文为云栖社区原创内容未经允许不得转载。
