建筑给排水代做网站,中国最权威的网站排名,网站查询域名ip解析,如何增加网站外链简介#xff1a; 本篇旨在介绍 Serverless 如今应用到应用#xff08;非病句#xff09;的各种困境#xff0c;以及帮助用户如何去规避一些问题#xff0c;提前了解方向。 浪潮
从 2014 年 Serverless 冒头至今#xff0c;已经有无数的勇士在前面探路#xff0c;阿里、… 简介 本篇旨在介绍 Serverless 如今应用到应用非病句的各种困境以及帮助用户如何去规避一些问题提前了解方向。 浪潮
从 2014 年 Serverless 冒头至今已经有无数的勇士在前面探路阿里、腾讯、亚马逊、百度、华为等都不断推出自己的云服务想要在这一浪潮中分一杯羹。除了最早的亚马逊国内的战争一直在不温不火地进行除了抢占市场外还在不断寻求新的解决方案期待有朝一日能够凭着新方案吸引大波用户。 从全球来看Serverless 整体的趋势还算不错特别是国内腾讯阿里的推动热潮不断。对比其他的关键字我们发现 Serverless 和微服务都在持续增长中总体说轻量化、分布式、可维护是一个趋势这符合当下的编码习惯。 ▲数据来源于 Google Trends
阿里云借由原有的首发优势同时加上首个支持预留/按量实例混合伸缩和预付费模式这些能力不断扩大用户基数同时在每年的双十一双十二活动中应用落地使得稳定性整体又上了一个台阶。同时在 2020 年 7 月信通院可信云大会上阿里云函数计算 FC 以 21 项测试全部满分的成绩首批通过可信云函数即服务认证。 ▲图片来自阿里云 2020 线上峰会
腾讯借由现有的小程序体系结合小程序云开发和 Serverless 绑定让用户迅速增长起来这步棋还是下得恰到好处能让很多开发者无缝地享受到云的能力既便利又能扩大影响力。 ▲图片来源于腾讯云
在一年的营销和推广之下不断有人尝试和使用在国内激起了不小的水花其中不乏有整体将业务迁移到 Serverless 体系的也有胆小的在远处观望。
好在有大公司的不断推动阿里淘宝、飞猪、高德、考拉以及京东、滴滴、字节等等越来越多的企业开始逐步尝试把业务迁移到 Serverless 环境一方面给其他观望的人打了样也促进了整个生态的正循环。
抛开这些大企业中小型企业、个人开发者依旧是科技领域的大多数除开观望的剩下的都是跃跃欲试想用但是摸不着门道的人群现在各家云厂商在发力争取的也正是这部分人。而现有问题最大的正也是这部分用户。
困境
很久之前我们开发的软件由 C/S 和 MVC 的架构转变为 SOA从单体架构到服务化再到更细粒度的微服务化应用开发之初就是为了应对业务特有的高并发、容错等特性需要很高的性能及可扩展性。
几十年前1975 年Fred Brooks 就在 The Mythical Man-Month 中就写到了这句话。
那么Serverless 会是解决软件开发复杂度和效率之间的那颗银弹吗
从 CNCF Cloud Native Interactive Landscape 中我们可以发现做基建托管平台的企业有不少我们了解的阿里云、腾讯、华为、Amazon 等都在其中而 Framework 以及更上层的业务工具场景其实不算很多抛开 aws 的几个工具只有 Python、JavaScript 和 Java 的工具比较出名的 Serverless Framework 加上 Spring Cloud Fucntion基本上能涵盖全球的很大一部分场景。 对于 Python、JavaScript 这种天生支持 Lambda 的开发语言和 FaaS 简直是完美结合。Serverless Framework 的调研报告也很好地说明了这一点。NodeJS、Python 是 FaaS 使用率前二的语言。 ▲图片来源于阿里云技术博客
我们知道因为 JVM 占用的内存比较大所以 Java 应用的启动会有点慢不太适合 FaaS 这个场景这也是 Java 在使用率上偏低的原因。
所以在整个 Serverless 架构上语言适合度占了非常大的部分。这也带来了一个最大的问题用户人群和基数。 身为前端大部分的场景都在前台页面展示、渲染跟 JavaScripts/HTML/CSS 打交道很少涉及服务端的部分唯一有交集的则是 Node.js 开发者在前后端领域都有着不错的输出。
而 JavaScript 在各家云平台占优的趋势下是否在使用的正是这部分人群。这部分人群隶属于前端自前端分化而来但是基数相比传统后端还是难以快速增加。
如何尽可能满足原有已经满足的人的需求同时还要扩大使用人群收割市场这正是各家云平台争相角逐之处也是当前的困境之处。
抉择
为了解决当前的人群问题只有不断地尝试至少国内的云厂商在这一方面一直在突破。我们能看到的这一年一直在做的
满足不同层面不同场景的用户需求尝试用新技术打破现有的语言困境。
阿里云上的 Serverless 产品更是帮助微博、石墨文档、跟谁学、Timing、联合利华等数万家企业客户成功落地 Serverless覆盖前端全栈、小程序、新零售、游戏互娱、在线教育等全行业应用场景。可以看到在企业的业务落地方面阿里云还是非常快速的。
除了函数计算 FC 和 SAE 两款产品之外阿里云 Serverless 产品矩阵还包括面向容器编排的 Serverless Kubernetes、以及面向容器实例的 ECI 等它们构成了当前所有云厂商中最完整的 Serverless 产品家族。 基本上阿里云已经将现有各种场景迁移到 Serverless 的路子打通从应用迁移、容器化、函数化等几个方面都包含了同时也在弹性的角度用实际的商业价值钱来吸引客户。很明显阿里云已经认识到当前的桎梏在尝试不同场景、不同语言的突破。
相对的腾讯云在这个层面更偏向于体验一站式极速部署让用户以极低的成本切入以体验为粘度去吸引用户。下面的广告我们在访问公众号/网站时经常会看到。 这一年我们收到腾讯云的培训推送很多从年初的 Serverless Framework 集成到后面的 Serverless Days以及 CloudBase Serverless 云端一体化产品方案等等。 从容器层 Custom Runtime 方案到应用层平台方案腾讯云也都有一一对应甚至在去年底还发布了国内首个 Serverless Mysql 数据库有意思。
这些林林总总的变化都是源自于不同用户层面的需求都是在争一个用户群以及未来的商业化体系。
云计算正在各领域持续深化其影响力同样各领域下日益变化的需求也在倒逼云计算不断进行自我优化。 反观用户侧除了下定决心吃螃蟹的企业们剩下的更多的是听着免费就来入场的羊毛党别小看他们只要是不花钱什么奇怪的事情都会做以及抱着学习的心态和部署个人服务的用户。
云平台更想吸引的是后者。这部分人群的问题依旧没有解决。我们会发现现有的云平台还处在一个吸引用户让用户自行摸索的阶段并没有做出对比或是 Serverless 和传统的区别之处。
棒槌
去年一年阿里双促使用 Serverless 扛下了大流量也有其他公司纷纷使用 Serverless 应用到业务的案例这些其实都是建立在足够强的保障体系下的实践如何应用到自己或者企业的业务身上才是真正的难点。
对一个企业很简单的事情比如要求提供几台虚拟机对个人开发者可能就是非常困难的。大公司有各种缓存服务有各种兜底的能力而小公司或是个人开发者只能听听一笑而之。之前 Netflix 实行业务微服务化拆开了非常多的接口模型并做了足够的分布式架构和管理体系也不是所有的公司都能学习并落地的。沉淀下来的只有经验。
对于用户来说在这些纷繁的宣传中需要去选择最适合自己的方案其实是比较困难的一般会先行熟悉然后从自己比较了解的平台入手。核心会有几个疑问
我有一个应用我怎么用上 Serverless我有一个应用是否要变为函数才能上 Serverless上了 Serverless 之后我的业务如何保持稳定最关键的Serverless我的业务怎么付钱
比如传统应用如何上 Serverless现有平台提供的迁移已存在的业务上 Serverless 方案基本使用的是 Custom Runtime 方案通过 HTTP 协议通信完成事件的响应处理即开发一个特定端口由容器内部做转发的方案。 ▲图片来自于阿里云 Custom Runtime 方案
这样将应用迁移到 Serverless 平台是现在的主流方式也是云平台推荐的方式。但是这样做是否真的没有后遗症
答案肯定是有的最明显的就是启动时间。容器的冷启动 业务的启动时间如果是函数那么基本能在 2s 内启动完毕提供服务而应用包含了太多的逻辑导致启动时间可能长达 2~10s这还是我们使用 Node.js 业务估算的平均时间如果是其他语言时间还要大幅增加。 函数的整体可访问时间会控制在比较小的范围而应用启动一般会比较久。
这就导致了整体应用的体验如果纯使用弹性的模式是不太能接受的。当然我们可以用预留模式固定一些容器来解决冷启动的问题不过大家可以去算算价格是否 ECS 会更便宜一些。
第二个问题是包大小现有函数部署云平台一般控制在 50M这不仅仅是因为存储的问题也是因为函数在启动时会下载包解压为了极速启动减少网络开销必然是希望包越小越好。应用的包如果是纯 Node.js 应用还好资源往往能卡在 100M 内但是加上前端资源传统的服务端渲染等整个包体积就会上到几百 M要知道前端可能不太关心引入包的大小毕竟 webpack 打包会自动剔除但是这可能是上到 Serverless 环境的较大隐患。
第三个问题是开发方式很多由于 Serverless 本身的限制导致业务代码的写法需要一些变化这不仅需要理解 Serverless 环境的运作机制也需要有相应的解法。比如文件上传传统应用可以完成表单上传但是在 Serverless 网关的拦截下需要通过不同的方式来做这使得传统应用开发和 Serverless 应用开发的代码不够统一导致一些维护成本。
还有固定的网络环境可能会导致网络隔离无法连接特定的服务。定制的容器环境以往的修改 nginx 支持特定协议路由转发都无法实现了。乃至 Serverless 最为美好的弹性行为也会使得代码跟原先预想的不一致比如本地的缓存、固定 ip 代理等等这些都是和原有应用不同的。
种种可能的问题你是否还能简单地将业务迁移到 Serverless
冷静下来经过我们整体的实践Serverless 的确能带给我们好处。上个月有个客户跟我讲以前纯用阿里云 ECS每个月要花好几千现在上了 Serverless每个月只要 8 块钱真实场景可以说这个吸引力是非常巨大的。
这点对于个人用户特别是学生/独立开发者特别有吸引力能够以极低的价格来完成功能交付。
虽然 Serverless 有一些问题但是真的省钱只要业务没有状态也没什么严苛的启动要求可以有一定优化减少启动时间能理解 Serverless 基础的原理就能规避我上面描述的问题。
那Serverless 一定是当前最省钱的方式是你钱包最棒的伙伴。
趋势
在过去的一年里我们发现了一个特点前端用户分化为两极一边是希望面向云原生更进一步全配置的方式将编写代码的机会变的更低nocode另一边希望以原有的应用模式逐步演进而来以及希望以一个大而全的应用进行开发部署从而减少开发协作成本。
比如 Serverless Framework腾讯去年改了三个不同的 yml 版本用来支持纯函数面向场景的业务。 ▲Serverless Framework 的 yml 配置
而下半年推出的腾讯云云开发也有着类似的方式只是配置从 yml 变成了 JSON但是核心没有太多变化。
{envId: fx,framework: {plugins: {server: {use: cloudbase/framework-plugin-node,inputs: {entry: ./api/index.js,path: /api,name: github-stats-api,wrapExpress: true}},pin: {use: cloudbase/framework-plugin-node,inputs: {entry: ./api/pin.js,path: /api/pin,name: github-stats-pin,wrapExpress: true}}}}
}
▲腾讯云开发的全配置 JSON
阿里云的 template.yml 多年也变化不大。 倒是年底推出的 Serverless Devs 吸引了一波眼球逐步把本地工具链的中心慢慢移动到配套的管理平台想必未来会有不同的变化。 和单独售卖的阿里云不同是腾讯云开发出炉了打包售卖的方式函数 存储 数据库资源来满足用户。这点在小程序开发上有非常大的优势工具 资源的整合上腾讯做得很不错。
就像之前说的那样云厂商在逐步弥补自身的不足利用不同场景的来做差异化竞争这是用户乐于看到的。
而用户的心智则没有太多的变化由于平台包裹得足够好美好我们发现后一半人应用开发逐步占据了上风业务不管如何上手都是以应用的模式来进行开发以应用开发的思路在开发、部署、调试俨然只是把 Serverless 容器当作原有的服务器充其量只是在原有的服务器上增加了一些限制比如不能登录等等。
从方案的选择中我们也发现前端更希望以一体化开发的方式前后端在一起去开发业务这就使得整个体系和原来的设想偏离得非常之多。
不过这是阿里内部的情况不得不说这是一个复古的趋势可能也是一个国内的趋势可能也是一个最容易被开发者接受的未来。
希望
在此前 InfoQ 报道的一篇《2019 年 Serverless 应用报告三分之二的落地实践都成功了》的文章其中提到了对于企业和开发者来说促使他们使用 Serverless 最直接的因素有以下三点
首先“减少运营成本”是大家采用 Serverless 的第一大原因应用 Serverless 之后就无需为潜在的流量高峰购买大部分时间处于空闲状态的服务器机架第二“自动按需扩展”采用 Serverless 之后可以随时扩展到当前的使用量消除了意外或者季节性流量高峰的困扰第三“无服务器维护”由于企业中大部分开发人员都是软件工程师并不是系统管理员所以对于软件的修复、保护和管理并不擅长而使用 Serverless 之后这些工作都可以交给供应商他们只需专注于软件开发。
每一点都足够吸引人但在这蜜糖之中有刺也有糖在使用之前我们最好能想一想到底怎么用才是最好的。
希望未来的 Serverless 形态能够足够满足业务的诉求不管是函数态还是应用态都能在其之上赋予更强大的场景和能力Serverless 国内厂商的独创能力也能领先全球为技术界添砖加瓦。
此文只是抛砖引玉仅代表个人观点不对平台做个人喜好选择。
作者Harry Chen
原文链接
本文为阿里云原创内容未经允许不得转载
