Serverless

阿里巴巴云原生的 2020,注定不凡的一年

删除回忆录丶 提交于 2021-01-04 22:12:14
来源| 阿里巴巴云原生公众号 划重点 2020 年我们发布了 360 篇文章,共 1966320 字,相当于 2 部《红楼梦》,比 2019 年多 94 篇文章,约 1 部《西游记》。 内容方向由 2019 年主攻的容器方向转向容器、中间件、微服务等云原生综合技术领域,其中技术解读和实践类文章最受大家的欢迎。 2020 年注定是不凡的一年 有人见尘埃 有人见星辰 但是没关系 好在这一年所有的遗憾都将收尾 美好的 2021 即将开启 在 2020 年的最后一天 一起来看看我们共同经历过的那些“大事件”吧~ 2020 年 1 月 容器调度、混部等面向突变型峰值的关键技术获 2019 年国家技术发明二等奖 2020 年 2 月 Kubernetes SIG-Cloud-Provider-Alibaba 首次网研会召开 OCI 完成 TOB 选举,阿里工程师傅伟作为唯一华人入选全球 9 人名单 2020 年 3 月 阿里云 Java initializr 正式发布,受到了广大开发者欢迎 2020 年 4 月 Gartner 发布 2020 年公共云容器报告:阿里云覆盖九项产品能力,成为全球云原生产品丰富度最高的厂商之一 Dragonfly 晋升成为 CNCF 孵化项目 国内首个《Serverless 技术公开课》上线 2020 年 5 月 首个边缘计算云原生项目 OpenYurt 正式开源

免费下载来自阿里巴巴 双11 的《云原生大规模应用落地指南》

房东的猫 提交于 2021-01-04 22:11:49
来源| 阿里巴巴云原生公众号 复制链接到浏览器完成下载或分享: https://developer.aliyun.com/topic/download?id=1055 11 月 11 日零点零分 26 秒,天猫 双11 的订单创建峰值就达到 58.3 万笔/秒,阿里云又一次扛住全球最大规模流量洪峰。与此前不同的是,继去年天猫 双11 核心系统上云后,阿里巴巴基于数字原生商业操作系统,实现了全面云原生化,底层技术升级带来了澎湃动力和极致效能。 如今,企业上云已经成为一种必然趋势。与此同时,作为诞生于云计算时代的新技术理念,云原生让企业用云的方式发生着从“上云”到“云上”的转化。速度下载《云原生大规模应用落地指南》,从技术体系升级、到技术能力突破、再到双11云原生实践,看最全面的阿里巴巴 双11 云原生技术实践经验。 独家下载《云原生大规模应用落地指南》 《云原生大规模应用落地指南》一书目录 推荐嘉宾寄语 “2020 年 双11 的主题是「云原生」,是在「云上」实现核心系统全面云原生化的的第一年。我们看到,云的定义在不断变化,它成为了商业领域数字化的底座和基础,不再单指传统云计算了,而是将未来的方向指向云原生。某种程度上,恰恰是因为云原生,我们才能从过去的束缚中解放出来。不迈出这一步,我们的综合能力很维迎来下一次突破。” “云原生让企业用云的方式发生着从‘上云’到‘云上’的转化

Should I be using Express.js in a Serverless app?

倾然丶 夕夏残阳落幕 提交于 2021-01-04 06:43:08
问题 I wanted to know if using Express.js as middleware in a Serverless app (AWS Lambdas) a good idea? My concern comes from the fact that in Express.js there is a mono-function setup and in future if lots of request come in it'll start throttling. Are my concerns valid or I am wavering about nothing. 回答1: The decision between building a mono-lambda and one-function-per-endpoint does not have a crystal-clear answer. On one hand, if you're using cloud formation - you're limited to 200 resources per

Should I be using Express.js in a Serverless app?

南笙酒味 提交于 2021-01-04 06:42:58
问题 I wanted to know if using Express.js as middleware in a Serverless app (AWS Lambdas) a good idea? My concern comes from the fact that in Express.js there is a mono-function setup and in future if lots of request come in it'll start throttling. Are my concerns valid or I am wavering about nothing. 回答1: The decision between building a mono-lambda and one-function-per-endpoint does not have a crystal-clear answer. On one hand, if you're using cloud formation - you're limited to 200 resources per

Serverless(无服务器)架构知识梳理

[亡魂溺海] 提交于 2021-01-03 07:42:57
前题: 大多数公司在开发应用程序并将其部署在服务器上的时候,无论是选择公有云还是私有的数据中心,都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等。并需要部署运行应用程序和依赖的软件到基础设施之上。如果我们不想在这些细节上花费精力,是否有一种简单的架构模型能够满足我们这种想法?这个答案已经存在,这就是今天软件架构世界中新鲜但是很热门的一个话题——Serverless(无服务器)架构。 什么是Serverless Serverless这个词第一次被使用大约是2012年由Ken Form所写的一篇名为《Why The Future of Software and Apps is Serverless》的文章。这篇文章谈到的内容是关于持续集成及源代码控制等内容,并不是我们今天所特指的这一种架构模式。目前还没有一个普遍公认的权威的定义。最新的一个定义是这样描述的:“无服务器架构是基于互联网的系统,其中应用开发不使用常规的服务进程。 涉及核心名词解释: FaaS(Function as a Service)就是一些运行函数的平台,比如阿里云的函数计算、Lambda 等。 BaaS(Backend as a Service)则是一些后端云服务,比数据库、对象存储、消息队列等。利用 BaaS,可以极大简化我们的应用开发难度。 FaaS 函数既服务 什么是函数既服务?

Serverless 是一种思想状态

↘锁芯ラ 提交于 2020-12-25 11:59:14
函数不是重点 如果你因为喜欢 Lambda 而选择 Serverless,你这样做的原因是错误的。如果你选择 Serverless,是因为你喜欢 FaaS,你这样做的原因也是错误的。函数不是重点。 当然,我喜欢 Lambda ——但这不是我提倡 Serverless 的原因。 不要误解我,函数很好。它们让你透明地伸缩,你不必管理运行时,而且它们天然地适合事件驱动的架构。这些都是非常有用的特性。 但是函数最终应该成为整个解决方案的一小部分。你应该使用包含业务逻辑的函数作为托管服务之间的粘合剂,这些托管服务提供了构成应用程序的大部分繁重工作。 托管服务不是重点 我们很幸运,云提供商能够为应用程序的许多不同部分提供如此广泛的托管服务。数据库、身份和访问管理(真高兴我不用自己拥有它!)、分析、机器学习、内容分发、消息队列等各种不同模式。 托管服务以较少的麻烦提供你所需的功能。你不必给他们运行的服务器打补丁。你不必确保自动缩放在没有大量空闲容量的情况下正确地提供所需的吞吐量。 托管服务显著降低了你的运维负担。托管服务很棒——但……它们不是重点。 运维不是重点 很高兴知道你可以应用更少的运维资源来保持应用程序的健康。尤其重要的是,你所需要的资源主要是根据你所提供的函数数量而不是流量来伸缩的。 减少运维、效率更高——但……这不是重点。 成本不是重点 好吧,有时候企业希望你做的只是降低成本—

Serverless 架构的演进

吃可爱长大的小学妹 提交于 2020-12-25 10:18:10
The Serverless Framework (无服务器架构)允许你自动扩展、按执行付费、将事件驱动的功能部署到任何云。 目前支持 AWS Lambda、Apache OpenWhisk、Microsoft Azure,并且正在扩展以支持其他云提供商。 Serverless 降低了维护应用程序的总成本,能够更快地构建更多逻辑。它是一个 命令 行工具,提供脚手架、工作流自动化和开发部署无服务器架构的最佳实践。它也可以通过插件完全扩展。 传统单体应用架构 十多年前主流的应用架构都是单体应用,部署形式就是一台服务器加一个数据库,在这种架构下,运维人员会小心翼翼地维护这台服务器,以保证服务的可用性。 ▲ 单体架构 单体应用架构面临的问题 随着业务的增长,这种最简单的单体应用架构很快就面临两个问题。首先,这里只有一台服务器,如果这台服务器出现故障,例如硬件损坏,那么整个服务就会不可用;其次,业务量变大之后,一台服务器的资源很快会无法承载所有流量。 解决这两个问题最直接的方法就是在流量入口加一个负载均衡器,使单体应用同时部署到多台服务器上,这样服务器的单点问题就解决了,与此同时,这个单体应用也具备了水平伸缩的能力。 ▲ 单体架构(水平伸缩) 微服务架构 1. 微服务架构演进出通用服务 随着业务的进一步增长,更多的研发人员加入到团队中,共同在单体应用上开发特性

都 2021 年了,Serverless 能取代微服务吗?

寵の児 提交于 2020-12-24 18:41:25
“Serverless 能取代微服务吗?” 这是知乎上 Serverless 分类的高热话题。 有人说微服务与 Serverless 是相背离的,虽然我们可以基于 Serverless 后端来构建微服务,但在微服务和 Serverless 之间并不存在直接的路径。也有人说,因为 Serverless 内含的 Function 可以视为更小的、原子化的服务,天然地契合微服务的一些理念,所以 Serverless 与微服务是天作之合。马上就要 2021 年了,Serverless 是否终将取代微服务?从微服务到 Serverless 需要经过怎样的路径?本文将对 Serverless 与微服务在优势劣势上进行深度对比。 从概念上讲,微服务完全符合 Serverless 功能结构,微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面,像 DynamoDB 这样的服务可以让每个微服务拥有独立的数据库,并独立地进行扩展。 在我们深入探讨细节之前,先别急着“站队”,不妨先基于你团队的实际情况,真实的去思考是否适合使用微服务,千万不要因为 "这是趋势 "而去选择它。 微服务在 Serverless 环境下的优势 可选择的可扩展性和并发性 Serverless 让管理并发性和可扩展性变得容易。在微服务架构中,我们最大限度地利用了这一点。每一个微服务都可以根据自己的需求对并发性/可扩展性进行设置

都 2021 年了,Serverless 能取代微服务吗?

 ̄綄美尐妖づ 提交于 2020-12-24 14:40:26
简介: 马上就要 2021 年了,Serverless 是否终将取代微服务?从微服务到 Serverless 需要经过怎样的路径?本文将对 Serverless 与微服务在优势劣势上进行深度对比。 来源 | Serverless 公众号 编译 | OrangeJ 作者 | Mariliis Retter “Serverless 能取代微服务吗?” 这是知乎上 Serverless 分类的高热话题。 有人说微服务与 Serverless 是相背离的,虽然我们可以基于 Serverless 后端来构建微服务,但在微服务和 Serverless 之间并不存在直接的路径。也有人说,因为 Serverless 内含的 Function 可以视为更小的、原子化的服务,天然地契合微服务的一些理念,所以 Serverless 与微服务是天作之合。马上就要 2021 年了,Serverless 是否终将取代微服务?从微服务到 Serverless 需要经过怎样的路径?本文将对 Serverless 与微服务在优势劣势上进行深度对比。 从概念上讲,微服务完全符合 Serverless 功能结构,微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面,像 DynamoDB 这样的服务可以让每个微服务拥有独立的数据库,并独立地进行扩展。 在我们深入探讨细节之前,先别急着“站队”

2020云原生调查报告:较首次调查,生产环境的容器使用量飙升300%

☆樱花仙子☆ 提交于 2020-12-22 18:36:50
从2015年Google主导成立了云原生计算基金会(CNCF)到2019年的云原生大放异彩,业内对云原生也有许多定义和预判,在2020年疫情大流行的大环境下,伴随着企业的数字转型云原生又会有怎么样的趋势呢?CNCF关于云原生的一个调查报告从一定程度上反映了技术发展的方向。以下是关于调查的总结文章。 今天,我们非常激动地发布了《2020云原生调查报告》(文末有下载方式)。该报告展示了今年第八次进行的CNCF云原生调查结果。 结果表明,在全球疫情大爆发的背景下云原生工具和技术的持续增长。自2020年5月至2020年6月我们在家里通过Zoom会议的方式发起了社区外围的一些调查。 今年的调查从大型企业中收到了强烈的响应,这表明大企业正在使用云原生。三分之二的受访者来自员工超过100人的企业,30%来自员工超过5,000人的企业。这些受访者代表了软件供应商和消费者,因为54%的受访者是终端用户组织的一部分。 就结果而言,我们今年是里程碑式的,特别是在容器的使用和容器编排方面。大约92%的受访者表示他们在生产过程中使用容器,相比2016年3月的第一次调查的23%增长了300%。与去年的84%和73%相比,这也是一个显著的同比跃升。 此外,91%的受访者使用Kubernetes,其中83%正在生产中使用。这延续了去年78%和2018年仅58%的产量使用的稳定增长。