app那个网站开发比较好,xp优化大师,淘宝推广,网站界面修改Serverless 话题涉及范围极广#xff0c;几乎包含了代码管理、测试、发布、运维和扩容等与应用生命周期关联的所有环节。在线应用如何不改代码也能迁移到 Serverless 架构#xff1f;今天#xff0c;我们来揭秘阿里巴巴成千上万在线应用的Serverless 演进过程。 AWS Lambda … Serverless 话题涉及范围极广几乎包含了代码管理、测试、发布、运维和扩容等与应用生命周期关联的所有环节。在线应用如何不改代码也能迁移到 Serverless 架构今天我们来揭秘阿里巴巴成千上万在线应用的Serverless 演进过程。 AWS Lambda 是 Serverless 领域的标志性产品但如果将其应用于核心业务可能会遇到以下难题仅代表作者个人观点 要求用户以 Function 为单位进行开发全新的开发框架云厂商强绑定社区主流技术栈迁移成本高Function 启动速度要足够快毫秒级或者秒级这个限制对适用场景有很强的约束Function 之间的调用通过 API Gateway响应时间更长。 Cloud Service Engine 云服务引擎以下简称CSE是阿里云中间件团队开发的面向通用 Serverless 计算的中间件产品目的是具备 AWS Lambda 的各种优势同时可以解决用户在使用 AWS Lambda 时遇到的难题。 什么是 Serverless AWS 对 Serverless 定义是 AWS 无服务器平台提供的功能 AWS 的整套 Serverless 方案非常完善但是没有解决存量应用如何迁移到 Serverless 架构的问题。仅仅是针对新开发的应用建议用户使用 FaaS 方式开发才有机会转向 Serverless 架构。笔者认为要将 Serverless 架构大规模推广必须要能有针对存量业务的解决方案。 Serverless 对云计算的价值 云计算归根结底是一种 IT 服务提供模式不论是公共云还是专有云以 IT 设备的归属不同分类其本质都是帮助 IT 的最终使用者随时随地并且简便快速地获取 IT 服务目前IaaS、PaaS 都已经做到了按需付费PaaS 甚至做到了按请求付费如 DBCACHEMQ 等但是 IaaS 的付费粒度仍然是时间维度最快按照小时付费以分钟来交付。 因此当下的云计算场景应用的开发维护方式相比传统 IDC 时代的开发维护差别还不是很大。但 AWS Lambda 提供了一种全新的开发维护方式用户只需要写好业务代码提交到云上所有和机器容量、可用性、机器为单位的运维工作可以全部交给了云平台这种模式极大地释放了云的弹性价值真正做到了按需付费。 CSE 试图提供一种更规模化的解决方案像 AWS Lambda 一样能进一步释放云的弹性价值并且可以平滑迁移存量应用。 存量在线业务实现 Serverless 架构的挑战 存量在线应用程序具有以下特点 资源分配速度 分钟级应用程序启动速度 10分钟 基于以上客观条件通常做法是提前预定好机器数量来应对任意时刻的流量峰值假设上述技术参数变为毫秒级就有机会将应用程序架构演变成下图所示方式。 上图中Service A 在调用 Service B 时如果 B 的容量充足则调用成功如果 B 的容量不足这时候如果线程池满则直接触发限流阀值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 一个进程。 L2 的单个 SNAPSHOT 可以创建多个进程一对多关系。 两种自研方案的对比 方案一不存在 UUID 问题但是每种语言的 VM 要单独定制成本效果相比方案二略差。方案二会存在 UUID 问题若开发者希望应用的每个实例启动时都赋值一个 UUID 给一个静态变量但通过 fork 会导致每个实例的这个静态变量都相同这与开发者预期不符。方案二的优势是更易实现、和语言无关、成本效果更优适合 FaaS、NBF 这类场景或者开发者自己定义的开发框架能避免 UUID 的问题。 整体来看方案一的适用场景更广但是实现成本更高方案二较适合 FaaS、NBF 这类场景。 和 AWS Lambda 相比 Lambda 为了做到快速扩缩容要求用户的应用以 Function 为单位开发Lambda Runtime 动态加载 Function 来快速增加实例。 CSE 则通过将一个应用的多个实例启动后共享相同的指令数据抽取出不同的指令数据每次启动实例只需要加载多实例的差异部分。因此可以透明兼容社区主流技术栈如 Spring BootPHP/Java/Python/Node.JS 等。 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 的生产实践 某电商业务 AServerless 化后机器数量从11台降低到2台2~10台之间波动某促销节服务流量峰值从数千瞬间飙到十多万CSE 瞬间弹性扩容从2台--5台--10台流量峰值回落后又缩容到2台。 某电商业务 BServerless 化后机器数量从4台到2台2~10台之间波动。 某电商业务 C之前固定4台机器Serverless 化完成后机器数量变成1台1~4台之间波动预发可实现0 - 1台实例之间波动。 原文链接 本文为云栖社区原创内容未经允许不得转载。