Serverless

作者｜刘宇 前言：本文将以阿里云函数计算为例，提供了在线调试、本地调试等多种利用优化与调试计划。 Serverless 利用调试秘诀在利用开发过程中，或者利用开发实现，所执行后果不合乎预期时，咱们要进行肯定的调试工作。然而在 Serverless 架构下，调试往往会受到极大的环境限度，呈现所开发的利用在本地能够衰弱、合乎预期的运行，然而在 FaaS 平台上产生一些不可预测的问题的状况。而且在一些非凡环境下，本地没有方法模仿线上环境，难以进行我的项目的开发和调试。 Serverless 利用的调试始终都是备受诟病的，然而各个云厂商并没有因而放弃在调试方向的深刻摸索。以阿里云函数计算为例，其提供了在线调试、本地调试等多种调试计划。 在线调试1.简略调试所谓的简略调试，就是在控制台进行调试。以阿里云函数计算为例，其能够在控制台通过“执行”按钮，进行根本的调试，如图所示。 函数在线简略调试页面 必要的时候，咱们也能够通过设置 Event 来模仿一些事件，如图所示。 通过设置 Event 模仿事件 在线调试的益处是，能够应用线上的一些环境进行代码的测试。当线上环境领有 VPC 等资源时，在本地环境是很难进行调试的，例如数据库须要通过 VPC 拜访，或者有对象存储触发器的业务逻辑等。 2.断点调试除了简略的调试之外，局部云厂商也反对断点调试，例如阿里云函数计算的近程调试、腾讯云云函数的近程调试等。以阿里云函数计算近程调试为例，其能够通过控制台进行函数的在线调试。当创立好函数之后，用户能够抉择近程调试，并点击“开启调试”按钮，如图所示。 函数在线断点调试页面（一） 开启调试之后，稍等片刻，零碎将会进入近程调试界面，如图所示。 函数在线断点调试页面（二） 此时能够进行一些断点调试，如图所示。 函数在线断点调试页面（三） 本地调试1.命令行工具就目前来看，大部分 FaaS 平台都会为用户提供绝对齐备的命令行工具，包含 AWS 的SAM CLI、阿里云的 Funcraft，同时也有一些开源我的项目例如 Serverless Framework、Serverless Devs 等对多云厂商的反对。通过命令行工具进行代码调试的办法很简略。以 Serverless Devs 为例，本地调试阿里云函数计算。 首先确保本地领有一个函数计算的我的项目，如图所示。 本地函数计算我的项目 而后在我的项目下执行调试指令，例如在 Docker 中进行调试，如图所示。 命令行工具调试函数计算 2.编辑器插件以 VScode 插件为例，当下载好阿里云函数计算的 VSCode 插件，并且配置好账号信息之后，能够在本地新建函数，并且在打点之后能够进行断点调试，如图所示。 VSCode 插件调试函数计算 当函数调试实现之后，执行部署等操作。 其余调试计划1.Web 框架的本地调试在阿里云 FaaS 平台开发传统 Web 框架，以 Python 语言编写的 Bottle 框架为例，能够减少以下代码： app = bottle.default_app()并且对run办法进行条件限度 (if __name__ == '__main__')：if __name__ == '__main__': bottle.run(host='localhost', port=8080, debug=True)例如：# index.pyimport bottle@bottle.route('/hello/<name>')def index(name): return "Hello world"app = bottle.default_app()if __name__ == '__main__': bottle.run(host='localhost', port=8080, debug=True)当部署利用到线上时，只须要在入口办法处填写 ndex.app，即可实现平滑部署。 ...

简介： 当下，Serverless 概念很火，很多同学被 Serverless 的劣势吸引过去，比方它的弹性伸缩，免运维，高可用，资费少。但真正应用起来去落地的时候发现问题很多，大型项目如何组织函数，性能优化怎么做，怎么做Serverless调试，数据库，共享会话怎么加等等。上周，Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升。本文以 Serverless Devs 的利用核心（web 版)为案例，来看开箱实际计划。 当下，Serverless 概念很火，很多同学被 Serverless 的劣势吸引过去，比方它的弹性伸缩，免运维，高可用，资费少。但真正应用起来去落地的时候发现问题很多，大型项目如何组织函数，性能优化怎么做，怎么做Serverless调试，数据库，共享会话怎么加等等。上周，Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升。接下来，以 Serverless Devs 的利用核心（web 版)为案例，来看开箱实际计划。 Serverless 函数代码组织如果想充分利用 Serverless 的能力函数是最佳计划，能够最大水平缩小冷启动工夫，践行用完即走的理念，保障用户体验的同时，最大水平缩小老本，不过对于中大型项目而言，以单函数的形式组织代码，在保护上无疑是一个微小挑战，可能一个利用会有数百个函数，保护老本极高也极易出错。 最好的形式是用框架的形式组织代码，以函数的形式部署执行。框架组织代码须要做业务的划分，比方电商蕴含商品，订单，用户等服务，都放到一个框架外面并通过函数去部署执行的话显著太大了。最好就是像微服务一样，独立业务的接口能够在同一个函数中，每一个业务有本人的独立域名，再通过外部路由拜访具体的业务服务。 这样做能够最大限度的利用函数能力，并且保护得来绝对容易一些。 咱们把 Serverless Hub 的利用市场作为一类场景，进行了对立划分，具体的函数调用如下实现(残缺的代码目录 git) const { http } = require('@serverless-devs/dk');const { searchApp, getAppDetail, getSpecialDetail, getSpecialApp, getCategorys, getTags } = require('./services');http .get("/appCenter/getSpecial", async (ctx) => { const data = await getSpecialApp(ctx); ctx.body = data; }) .post("/appCenter/getSpecialDetail", async (ctx, next) => { const data = await getSpecialDetail(ctx); ctx.body = data; }) .post("/appCenter/getAppDetail", async (ctx) => { const data = await getAppDetail(ctx); ctx.body = data; }) .get("/appCenter/getCategory", async (ctx) => { const data = await getCategorys(); ctx.body = data; }) .get("/appCenter/getTags", async (ctx) => { const data = await getTags(); ctx.body = data; }) .post("/appCenter/getApps", async (ctx) => { const data = await searchApp(ctx); ctx.body = data; }) .get("/", async (ctx, next) => { let result = "Hello ServerlessDevs"; ctx.body = result; }) http.app.use(http.routes());exports.handler = http();代码应用了 Serverless Devs 提供的 @serverless-devs/dk ，咱们对规范的前端框架进行了外围封装，比方 express,koa 等，你能够持续应用习惯的 web 框架进行开发工作，最初通过 s 工具进行函数部署。s.yaml 的配置如下： ...

现在，Serverless 作为根底研发底座，被越来越多的企业所承受，并利用于业务实际中。除了互联网企业最早 “尝鲜” 之外，传统企业也纷纷开始尝试大规模应用 Serverless。 Serverless 利用逐步宽泛，对于一般开发人员来说，学习 Serverless 可能给带来什么益处呢？举个例子，当想要部署一个网站时，须要本人购买服务器并破费工夫去保护，造成资源节约不说，还要消耗精力，而 Serverless 就可能很好地解决这个问题，简略来说，就是既省钱又省力。Serverless 是一种将来的开发方式，它是属于每一位开发者。 技术图谱+场景实操=即学即用2020 年，阿里云 Serverless 团队重磅打造了「Serverless 技术公开课」帮忙超过 3 万名开发者入门 Serverless。2021 年，阿里云 Serverless 技术图谱全新公布，在原公开课内容根底上减少课时 15 节、实操场景 8 个 、电子书 1 本，知识点更细化，利用上手更简略。全新 Serverless 技术图谱，首次从根底入门、技术进阶到利用实战的 Serverless 知识点整顿成为思维导图，帮忙开发者疾速构建 Serverless 常识体系，更快学以致用。 开始学习点击获取技术图谱：https://developer.aliyun.com/... 辨认上方二维码或点击链接（https://developer.aliyun.com/...） 即可学习 局部讲师阵容

人人都在探讨的 Serverless 到底怎么用？Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。为了帮忙开发者高效解决解决实在场景下的 Serverless 难题，疾速体验 Serverless 开释红利。9月22日起，每个工作日 19:00-20:00，间断 12 堂干货直播课，8 位 Serverless 技术专家手把手带你零根底升级 Serverless 高手，拿下高手证书。实现所有打卡，即可拿到由阿里云开发者学堂颁发的纸质+电子“Serverless 高手证书”！ 直播工夫：9月22日-10月12日 工作日 19:00 - 20:00（可有限回放）可打卡工夫：9月22日—10月31日直播预约：辨认下方二维码或关上链接预约报名https://developer.aliyun.com/learning/topic/serverless? 直播亮点从 Serverless 概念开始零碎解说 Serverless以架构师视角选型 Serverless应用微服务的企业如何转型 Serverless？Serverless 在阿里团体的大规模落地案例Serverless 在企业落地难点及解析

简介： 第二届云原生编程挑战赛为酷爱技术的年轻人提供一个挑战世界级技术问题的舞台，心愿用技术为全社会发明更大价值。 作者 | 刘欣 呃，我可能是他人眼中所说的不必奋斗的一代。 大家喜爱听的什么多姿多彩的生存，我都经验过一些些。 我家里开的是连锁超市，次要集中在几个二线城市。 在我上小学的时候，各连锁店里开始装电脑，购买并装置了残缺的收银设施。 我爸说要向那些大的连锁超市学习，进步生产效率。 那个时候我对那些灰色界面的收银软件很感兴趣，惋惜爸妈不让我碰。 起初他们给我买了电脑，过后小镇上有电脑的人家不多，亲戚的小孩也经常跑到我这儿来玩电脑。 也正因为和电脑接触得早，上大学时就选了计算机专业。 我才刚上大学没几个星期，我爸就问我： 那个时候我连数据库什么的都还没有个概念，还在学反码补码，我通知他：能，但当初不行，等我一两年。 我爸说不要紧。依照他的思维，咱们不须要齐全会写，只有明确怎么写进去就行，具体的实现咱们能够交给软件公司做。 但搞明确软件是怎么造出来的很重要，因为这可能帮忙咱们在购买软件时站在供应商的角度思考，知己知彼，放大我方信息差。 做买卖实质上玩的就是这一套。 2005年，我大三，学校要搞一次软件开发大赛，一共有三个命题，其实根本涵盖了所有场景，学生能够自由发挥。于是我就想到了超市的收银软件。 过后淘宝刚火起来，我想为啥不学习一下呢， 彻底变革我爸的商业模式，从线下转到线上！ 整个网上商城， 浏览商品，购物车，下单，配送，但咱们次要卖的是本人的货源。 过后用到的技术是 MySQL+ Java + JSP，而后本人买了服务器让服务跑起来。 在学校演示这套零碎时，我拿了最高的问题。 满心欢喜之余，我尝试把这套零碎用到理论业务中，先从自家的总店开始试点。 没想到我爸给我泼了一盆冷水，他说咱们这里的用户没有上网购物的习惯，送货问题没法解决。 我不服，非要尝试，果然现实与事实间存在着微小的差别，我跌了一个大跟头。 尽管我搞了很多流动，发传单宣传商城，但真正上网购物的寥寥无几。 有些违心尝鲜的，在网上买了货色，都是我亲自开车送货的。 毕业回家，我本想出国留学，但被我爸拽了回来， 我先跟着信息部的负责人老张学习，而后缓缓接班。 过后家里的每个超市都很大，都有一二十台 POS 机， 每个超市有一台服务器，一个数据库。 POS 机间接连到本超市的服务器上， 典型的客户端/服务器构造。 在那个时代，我预计大家都是这样的吧！ 说实话，这样的软件架构外表看似挺稳的，只有机器不出问题，稳固供电，整套收银零碎就没有问题。但实际上面临着许多缺点： 机器是真的会坏的，而且真的有坏过的案例每次有商品数据要更新都要告诉每一家店的管理人员进行更新，呈现纰漏是很失常的更新软件的时候，工程师须要到各个现场配置，更新4. 各个店面对立数据艰难，每个月统计数据的时候须要对立汇总，不能随时随地得悉以后各分店的数据5. 等等......每一家店独自运作一套零碎，这毛病要是列上来就没完没了了 我倡议老张搞个地方机房，把软件集中化，每个门店都连贯到对立的机房服务器，这样就把下面的问题给解决了： 起初的零碎革新，通过招标、投标，咱们选了本地一家颇有实力的公司来做。 我施展了计算机专业的劣势，帮忙老张发现了不少问题。 看来我爸说的是对的，放大信息差很重要。 地方机房运作了几年，成果不错， 不过自家的机房治理起来十分麻烦。 平时须要认真布局、购买服务器，须要装置软件， 须要负责运维，咱们还专门建设了一个团队来应答这些事件。 更可气的是黑客攻击无处不在 ...

人人都在探讨的 Serverless 到底怎么用？Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。 为了帮忙开发者高效解决解决实在场景下的 Serverless 难题，疾速体验 Serverless 开释红利。9月22日起，每个工作日 19:00-20:00，间断 12 堂干货直播课，8 位 Serverless 技术专家手把手带你零根底升级 Serverless 高手，拿下高手证书。实现所有打卡，即可拿到由阿里云开发者学堂颁发的“Serverless 高手证书”！（纸质+电子） 直播工夫：9月22日-10月12日 工作日 19:00 - 20:00（可有限回放）打卡工夫：9月22日—10月31日直播预约：辨认下方二维码或点击文末“浏览原文”预约 辨认上方二维码，立刻预约 直播亮点从 Serverless 概念开始零碎解说 Serverless以架构师视角选型 Serverless应用微服务的企业如何转型 Serverless？Serverless 在阿里团体的大规模落地案例Serverless 在企业落地难点及解析 点击链接（https://developer.aliyun.com/learning/topic/serverless），即可预约直播哦！

简介： Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。有人说要把 Serverless 架构看成一种人造的分布式架构，须要用分布式架构的思路去开发 Serverless 利用。诚然，这种说法是正确的。然而在一些状况下，Serverless 还有一些个性，所以要转变开发观点。 前言：在 Serverless 架构下，尽管更多精力是关注业务代码，然而实际上对一些配置和老本也是须要关注的，并且必要的时候还须要依据配置与老本对 Serverless 利用进行配置和代码优化。 Serverless 利用开发观点的转变Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。有人说要把 Serverless 架构看成一种人造的分布式架构，须要用分布式架构的思路去开发 Serverless 利用。诚然，这种说法是正确的。然而在一些状况下，Serverless 还有一些个性，所以要转变开发观点。 1、文件上传办法在传统 Web 框架中，上传文件是非常简单和便捷的，例如 Python 的 Flask 框架： f = request.files['file']f.save('my_file_path')然而在 Serverless 架构下，文件却不能间接上传，起因如下： 个别状况下，一些云平台的API网关触发器会将二进制文件转换成字符串，不便间接获取和存储； 个别状况下，API 网关与 FaaS 平台之间传递的数据包有大小限度，很多平台限度数据包大小为 6MB 以内； FaaS 平台大多是无状态的，即便存储到以后实例中，也会随着实例开释而使文件失落。 所以，传统 Web 框架中罕用的上传文件计划不太适宜在 Serverless 架构中间接应用。在 Serverless 架构中，上传文件的办法通常有两种：一种是转换为 Base64 格局后上传，将文件长久化到对象存储或者 NAS 中，但 API 网关与 FaaS 平台之间传递的数据包有大小限度，所以此办法通常实用于上传头像等小文件的业务场景。 另一种上传办法是通过对象存储等平台来上传，因为客户端间接通过密钥等来将文件直传到对象存储是有肯定危险的，所以通常是客户端发动上传申请，函数计算依据申请内容进行预签名操作，并将预签名地址返给客户端，客户端再应用指定的办法上传，上传实现之后，通过对象存储触发器等来对上传后果进行更新等，如下图所示。 在 Serverless 架构下文件上传文件示例 以阿里云函数计算为例，针对上述两种常见的上传办法通过 Bottle 来实现。在函数计算中，先初始化对象存储相干的对象等： 初始化对象存储相干的对象等： AccessKey = { "id": '', "secret": ''}OSSConf = { 'endPoint': 'oss-cn-hangzhou.aliyuncs.com', 'bucketName': 'bucketName', 'objectSignUrlTimeOut': 60}#获取/上传文件到OSS的长期地址auth = oss2.Auth(AccessKey['id'], AccessKey['secret'])bucket = oss2.Bucket(auth, OSSConf['endPoint'], OSSConf['bucketName'])#对象存储操作getUrl = lambda object, method: bucket.sign_url(method, object, OSSConf['object SignUrlTimeOut'])getSignUrl = lambda object: getUrl(object, "GET")putSignUrl = lambda object: getUrl(object, "PUT")#获取随机字符串randomStr = lambda len: "".join(random.sample('abcdefghijklqrstuvwxyz123456789 ABCDEFGZSA' * 100, len))第一种上传办法，通过 Base64 上传之后，将文件长久化到对象存储： ...

前言：在 Serverless 架构下，尽管更多精力是关注业务代码，然而实际上对一些配置和老本也是须要关注的，并且必要的时候还须要依据配置与老本对 Serverless 利用进行配置和代码优化。 Serverless 利用开发观点的转变 Serverless 架构带来的除了一种新的架构、一种新的编程范式，还包含思路上的转变，尤其是开发过程中的一些思路转变。有人说要把 Serverless 架构看成一种人造的分布式架构，须要用分布式架构的思路去开发 Serverless 利用。诚然，这种说法是正确的。然而在一些状况下，Serverless 还有一些个性，所以要转变开发观点。  1、文件上传办法 在传统 Web 框架中，上传文件是非常简单和便捷的，例如 Python 的 Flask 框架：  f = request.files['file']f.save('my_file_path') 然而在 Serverless 架构下，文件却不能间接上传，起因如下：  个别状况下，一些云平台的API网关触发器会将二进制文件转换成字符串，不便间接获取和存储；个别状况下，API 网关与 FaaS 平台之间传递的数据包有大小限度，很多平台限度数据包大小为 6MB 以内；FaaS 平台大多是无状态的，即便存储到以后实例中，也会随着实例开释而使文件失落。 所以，传统 Web 框架中罕用的上传文件计划不太适宜在 Serverless 架构中间接应用。在 Serverless 架构中，上传文件的办法通常有两种：一种是转换为 Base64 格局后上传，将文件长久化到对象存储或者 NAS 中，但 API 网关与 FaaS 平台之间传递的数据包有大小限度，所以此办法通常实用于上传头像等小文件的业务场景。 另一种上传办法是通过对象存储等平台来上传，因为客户端间接通过密钥等来将文件直传到对象存储是有肯定危险的，所以通常是客户端发动上传申请，函数计算依据申请内容进行预签名操作，并将预签名地址返给客户端，客户端再应用指定的办法上传，上传实现之后，通过对象存储触发器等来对上传后果进行更新等，如下图所示。  在 Serverless 架构下文件上传文件示例 以阿里云函数计算为例，针对上述两种常见的上传办法通过 Bottle 来实现。在函数计算中，先初始化对象存储相干的对象等：  AccessKey = { "id": '', "secret": ''}OSSConf = { 'endPoint': 'oss-cn-hangzhou.aliyuncs.com', 'bucketName': 'bucketName', 'objectSignUrlTimeOut': 60}#获取/上传文件到OSS的长期地址auth = oss2.Auth(AccessKey['id'], AccessKey['secret'])bucket = oss2.Bucket(auth, OSSConf['endPoint'], OSSConf['bucketName'])#对象存储操作getUrl = lambda object, method: bucket.sign_url(method, object, OSSConf['object SignUrlTimeOut'])getSignUrl = lambda object: getUrl(object, "GET")putSignUrl = lambda object: getUrl(object, "PUT")#获取随机字符串randomStr = lambda len: "".join(random.sample('abcdefghijklqrstuvwxyz123456789 ABCDEFGZSA' * 100, len)) 第一种上传办法，通过 Base64 上传之后，将文件长久化到对象存储：  ...

来自Serverless，向世界说句你好。 背景常识什么是Serverless 自2006年8月9日，Google首席执行官埃里克·施密特（Eric Schmidt）在搜索引擎大会（SESSanJose2006）首次提出"云计算"（Cloud Computing）的概念之后，云计算的倒退能够用突飞猛进这个词来形容。那么到底什么才是Serverless呢？ 简略来说，Serverless能够说是一种架构，一种云计算倒退的产物，至于具体说什么是Serverless，可能没有谁能给他一个明确的概念，如果非要说一个能够略微容易了解一些的概念，那或者能够参考Martin Fowler在《Serverless Architectures》中对Serverless这样定义：Serverless=BaaS + FaaS。Serverless架构和传统的我的项目的区别 首先，咱们以一个常见的Web服务为例：在这个图中，服务器中可能波及路由规定、鉴权逻辑以及其余各类简单的业务代码。同时，开发团队要付出很大的精力在这个服务器的运维下面，例如要时刻关注以下问题： 客户量忽然增多时是否须要扩容服务器。服务器上的脚本和业务代码等是否还在衰弱运行。是否有黑客在一直地对服务器发动攻打。 当咱们把这个思路切换到Serverless的逻辑之后，变成了这样：能够认为，当客户端和数据库未发生变化的前提下，服务器变动微小。 之前须要开发团队保护的路由模块以及鉴权模块都将接入服务商提供的API网关零碎以及鉴权零碎，开发团队无须再保护这两局部的业务代码，只须要继续保护相干规定即可。 在这个构造下，业务代码也被拆分成了函数粒度，不同函数示意不同的性能。 咱们曾经看不到服务器的存在，是因为Serverless的目标是让使用者只关注本人的业务逻辑即可，所以一部分平安问题、资源调度问题（例如用户量暴增、如何实现主动扩容等）全都交给云厂商负责。 绝对于传统我的项目而言，传统我的项目无论是否有用户拜访，服务都在运行中，都是有老本收入，而Serverless而言，只有在用去发动申请时，函数才会被激活并且执行，并且会按量免费，相对来说能够在有流量的时候才有反对，没有流量的时候就没有收入，相对来说，老本会进一步升高。 通过以上剖析和形容，不难看出Serverless架构绝对于传统的开发模式的区别，也逐步的发现了它的劣势。然而问题来了，很多工作都交给了云厂商来做，那咱们做什么呢？应用Serverless架构的劣势 从上文中咱们不难看出，绝对于传统我的项目，Serverless具备的以下劣势： 您无需洽购和治理服务器等基础设施，运维成本低。您只需专一业务逻辑的开发，应用函数计算反对的开发语言设计、优化、测试、审核以及上传本人的利用代码。以事件驱动的形式触发利用响应用户申请。与阿里云对象存储OSS、API网关、日志服务和表格存储等服务无缝对接，帮忙您疾速构建利用。例如，通过OSS解决图片和视频的存储问题，当有新数据写入您的OSS资源时，主动触发函数解决数据。提供日志查问、性能监控和报警等性能疾速排查故障。毫秒级别弹性伸缩，疾速实现底层扩容以应答峰值压力。按需付费，反对百毫秒级别免费。只需为理论应用的计算资源付费，适宜有显著波峰波谷的用户拜访场景。 总而言之，Serverless是在传统容器技术和服务网格上倒退起来，更多指的是后端服务与函数服务的联合。对于开发者而言，可能将更多的精力关注在函数服务上，更偏重让使用者只关注本人的业务逻辑即可。 同时，Serverless也是云计算倒退到肯定阶段的必然产物。作为普惠科技，云计算倒退的指标肯定是绿色科技和公众科技的产品------而Serverless可能很好的诠释这些：最大水平利用资源、缩小闲暇资源节约；同时升高学习老本和应用老本。 Serverless架构被称为是"真正实现了当初云计算的指标"，这种说法尽管有些夸大，然而也从另一方面体现出了大家对Serverless架构的期盼和信念。自2012年被提出至今，Serverless架构也是经验了7年工夫，正在逐步的走向成熟。 开明并进入到阿里云Serverless产品1.通过阿里云首页，找到"产品"->"弹性计算"->"Serverless"->"函数计算FC"2.点击进入函数计算FC的页面 点击治理控制台按钮，并进行账号注册/登陆4.针对首次应用的用户须要进行函数计算服务的开明，须要浏览协定，并且批准（点击1中的抉择框），而后点击右下角的立刻开明即可5.进入控制台之后，如果右上角有“体验新版控制台”按钮，请点击该按钮，如果没有该按钮，能够跳过本步骤创立服务和函数1.抉择左侧的服务及函数之后，能够先进行服务的创立 依照页面揭示，进行服务名称设定，而后能够选择性的进行形容信息填写、日志服务和链路追踪性能开启，最初点击确定即可实现服务的创立之后，能够进行函数的创立须要咱们天蝎函数名，抉择一个本人相熟的编程环境，以及设置一个内存规格，最初点击创立即可创立之后能够在代码框中，编写代码，例如默认的Hello World# -*- coding: utf-8 -*-import logging# To enable the initializer feature (https://help.aliyun.com/document_detail/158208.html)# please implement the initializer function as below：# def initializer(context):# logger = logging.getLogger()# logger.info('initializing')def handler(event, context): logger = logging.getLogger() logger.info('hello world') return 'hello world'6.当代码有变更之后，零碎会进行揭示，咱们须要部署代码 部署代码之后，咱们能够进行测试函数测试实现之后，能够看到最终的return将会作为返回后果进行展现，两头的logger.info将会作为日志输入进行展现创立一个能够通过网址拜访的Hello World在刚刚的流程中，咱们创立的是一个通过其余触发器触发函数的案例，此时咱们能够创立一个通过HTTP申请触发函数的案例。 此时须要留神的几个点： 什么是触发器：https://help.aliyun.com/docum...什么是HTTP触发器：https://help.aliyun.com/docum... 创立一个新的函数，并在创立函数的时候，抉择“通过HTTP申请触发” 创立实现之后，与刚刚的代码不同的是，这个Http触发的代码包含了一些Http的信息# -*- coding: utf-8 -*-import loggingHELLO_WORLD = b'Hello world!\n'# To enable the initializer feature (https://help.aliyun.com/document_detail/158208.html)# please implement the initializer function as below：# def initializer(context):# logger = logging.getLogger() # logger.info('initializing')def handler(environ, start_response): context = environ['fc.context'] request_uri = environ['fc.request_uri'] for k, v in environ.items(): if k.startswith('HTTP_'): # process custom request headers pass # do something here status = '200 OK' response_headers = [('Content-type', 'text/plain')] start_response(status, response_headers) return [HELLO_WORLD]对于不同语言的HTTP触发办法案例能够参考文档：https://help.aliyun.com/docum... ...

简介： 2020 年 10 月 23日，阿里巴巴正式发表开源其首个 Serverless 开发者平台 Serverless Devs。历经近一年精心打磨，明天 Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升，更加贴近开发者的理论生产诉求，应用体验再晋升，让开发者像应用手机一样玩转 Serverless，疾速享受 Serverless 技术红利。 作者 | 寒斜、江昱 2020 年 10 月 23日，阿里巴巴正式发表开源其首个 Serverless 开发者平台 Serverless Devs。历经近一年精心打磨，明天 Serverless Devs 2.0 正式版全新公布。Serverless Devs 2.0 在平台能力、利用模板以及开发者套件方面能力晋升，更加贴近开发者的理论生产诉求，应用体验再晋升，让开发者像应用手机一样玩转 Serverless，疾速享受 Serverless 技术红利。 这就是 Serverless DevsServerless Devs 是一个开源凋谢的 Serverless 开发者平台，Serverless Devs 也是业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理的平台，致力于为开发者打造 Serverless 利用开发一站式服务, 帮忙解决目前的工具链之困，让开发者一键体验多云产品，极速部署 Serverless 我的项目。 Serverless Devs 由"两端一核心体系"组成： Serverless Devs CLI (命令行客户端)，适宜极客开发人员应用，玲珑轻便，易于集成Serverless Desktop (桌面客户端) ，具备更宽泛的适用性，领有开发，构建，部署，调试，可观测等全方位利用治理能力Serverless Hub 利用核心，提供利用的集散和散发，作为公共服务提供给 开发者或贡献者实用。 ...

一个新技术的呈现不是无中生有，从石头中凭空蹦出来的，而是在原有根底上的继承和倒退。 Serverless也不例外，咱们回顾下IT基础设施的倒退，就会发现，Serverless天然就会浮现进去，你本人就能够创造它（然而却实现不了它）。 局域网时代上世纪90年代，你是一家IT部门的负责人，公司须要建设一个信息管理系统， 这时候的零碎都是局域网的， 是C/S模式的， 业务逻辑次要在客户端软件中， 须要被装置到各个电脑下来，而后拜访同一个数据库。 在部署这个零碎之前，你须要做很多的工作： 搭建局域网， 购买交换机，路由器。买服务器，装置操作系统，比方Window NT装置数据库软件，例如Oracle。而后再把那些Delphi/VB/PowerBuilder写的客户端装置到电脑上, 整个零碎跑起来了。 数据中心C/S模式的很大弊病就是客户端更新特地麻烦，不能在用户无感知的状况下实现降级，还有臭名卓著的DLL天堂问题，让程序员抓狂。另外服务器能撑持的用户也不大。 Web衰亡后，你们公司的利用也与时俱进，从C/S模式变成了B/S模式，用户次要应用浏览器来拜访利用，业务逻辑在服务器端运行。 这时候，你还须要买服务器，而后放到数据中心去托管，毕竟那里的条件更好，更稳固。 网络不须要本人来搭建了， 掏钱买数据中心的网络带宽就好。 还须要本人装置软件， 比方Linux操作系统、Tomcat、Ngnix、MySQL等等。 随着性能的减少，你还须要新的服务器来解决缓存，搜寻等性能。 为了应答高并发、还须要分布式、负载平衡、数据复制。 你须要认真地布局， 看看这些缓存、搜寻、数据库、 负载平衡等都须要什么样的服务器，有些要求CPU很强，有些要求内存很大，有些要求硬盘很快。 总之，本人运维这样一套零碎，十分麻烦。 虚拟化然而，如果你的网站没人拜访了，这一套简单的零碎，这些低廉的服务器就会变成陈设，你想卖都很难卖掉，这是微小的节约。 一个想法就会浮现进去： 为什么要用物理服务器？谁要是能提供虚拟机给我就好了！用完了就能够“扔掉”！于是那些有实力的大厂就这么做了，有亚马逊开始，把平时闲暇的物理服务器的计算能力，存储能力对立治理，对立调配，对外提供的就是虚拟机。 他们把这种形式叫做云计算，你应用了云计算当前，有很多益处： 物理服务器不必买了，申请虚拟机就能够了。什么样的CPU， 多少内存，多大的硬盘，对应的价格也不同。操作系统会依照你的要求主动给你装置好。网络天然不必操心， 要多大带宽间接买就行。这些虚拟机能够包月、包年计费。然而，如果没有人拜访你的利用，没有流量，你也得掏钱。现实模式想必你的脑海中曾经浮现出了解决方案： 不要再思考什么物理服务器/虚拟机了， 把代码上传到云端，间接运行。按应用状况（如CPU工夫、内存大小）来免费（IBM： 我的大机始终按应用状况免费，你们玩了几十年，终于回到我这里了 ^-^） 如果没有人拜访你的利用，就不要部署它，这样只会占用一点点存储空间，不必应用CPU和内存；如果有人拜访，把利用迅速部署到某个服务器上，执行这次申请，返回给用户，而后卸载这个利用。 和之前的形式相比，最大的特色是即用即走，不会在服务器/虚拟机中常驻。 然而这么做可能吗？ 不行，利用的粒度太大，一个利用几十、上百模块，每个申请来了就部署整个利用，只执行那么一点儿代码， 而后就卸载掉。 如果每个申请这么来回地部署和卸载，你是疯了吗，兄弟？ 那微服务呢？粒度还是太大 ！ 如果是微服务中的一个API，或者说就是一个“函数”呢？ 这个粒度应该差不多了。 这里说的函数到底是什么？ 须要看具体的业务来划分，比方搜寻产品，图像转换， 它须要足够小，足够繁多，能疾速启动，运行，卸载。 一个“函数”真的只做一件事件，并且不放弃状态。 这样一来它能够轻松地被扩大到任意多的服务器/虚拟机/docker容器中去。申请多了就扩容，申请少了，就膨胀，申请没了，就卸载，切实是太爽了。 这种形式当初称为Serverless，并不是说没有服务器，而是说服务器对用户来说是通明的。 利用的装载、启动、卸载，路由是须要平台来搞定。 Serverless 的特点Serverless的开发模式和运行模式相似这样： 程序员编写实现业务的函数代码。上传到反对Serverless的平台，设定触发的规定。申请到来，Serverless平台依据触发规定加载函数，创立函数实例，运行如果申请比拟多，会进行实例的扩大，如果申请较少，就进行实例的膨胀。如果无人拜访，卸载函数实例。如果有多个函数，怎么确定调用哪一个？ 必定须要一个货色来转发一下。 （微服务： 我就是这么玩儿的啊！） 如果业务比较复杂，一个函数搞不定怎么办？ 能够把多个函数给编排起来！ （SOA： 我早就这么做了！） 按需装载，主动伸缩，不必你苦逼地去布局硬件，装置软件，还能够依照应用状况付费，这么好的货色，咱们是不是马上投入Serverless的怀抱？ ...

简介： 弹性是 Serverless 外围能力之一，SAE 在传统弹性能力根底上，提供了多维的监控指标和弹性策略，是利用零革新上云的最佳抉择。 Serverless时代的降临 Serverless 顾名思义，是一种“无服务器”架构，因为屏蔽了服务器的各种运维复杂度，让开发人员能够将更多精力用于业务逻辑设计与实现。在serverless架构下，开发者只须要关注于下层应用逻辑的开发，而诸如资源申请，环境搭建，负载平衡，扩缩容等等服务器相干的简单操作都由平台来进行保护。在云原生架构白皮书中，对serverless的个性有以下概括： 全托管的计算服务，客户只须要编写代码构建利用，无需关注同质化的、累赘沉重的基于服务器等基础设施的开发、运维、平安、高可用等工作； 通用性，可能撑持云上所有重要类型的利用； 主动的弹性伸缩，让用户无需为资源应用提前进行容量布局； 按量计费，让企业应用老本得无效升高，无需为闲置资源付费。 回顾整个serverless的倒退历程，咱们能够看到从2012年首次提出serverless概念为终点，再到aws推出lambda云产品的这段时间内，人们对serverless的关注度呈现了爆发式的增长，对无服务器的期待和畅想逐步引爆整个行业，但serverless的推广和生产落地的过程却不容乐观，serverless理念与实操生产的过程中存在gap，挑战着人们固有的应用体验和习惯。阿里云深信serverless将作为云原生之后确定性的倒退方向，相继推出了fc,sae等多款云产品来笼罩不同畛域，不同类型的利用负载来应用serverless技术，并且一直在推动整个serverless理念的遍及与倒退。 就以后serverless整个市场格局而言，阿里云曾经做到了Serverless产品能力中国第一，寰球当先，在去年forrester评测魔力象限中能够显著的看到阿里云在serverless畛域曾经与aws并驾齐驱，于此同时，阿里云 Serverless 用户占比中国第一，在2020年中国云原生用户调研报告中整个阿里云serverless用户占比曾经达到了66%，而在serverless技术采纳状况的调研中表明，曾经有越来越多的开发者和企业用户将serverless技术利用于外围业务或者将要利用于外围业务之中。 Serverless弹性摸索 弹性能力作为云的外围能力之一，所关注的问题是容量布局与理论集群负载间的矛盾，通过两幅图的比照能够看到，如果采纳事后布局的形式进行资源安顿，会因为资源筹备量和资源需求量的不匹配导致资源节约或者资源有余的状况，进而导致老本上的过多开销甚至业务受损，而咱们冀望极致弹性能力，是筹备的资源和理论需要的资源简直匹配，这样使得利用整体的资源利用率较高，老本也随业务的增减和相应的增减，同时不会呈现因容量问题影响利用可用性的状况，这就是弹性的价值。弹性其实现上分为可伸缩性和故障容忍性,可伸缩性意味着底层资源能够参照指标的变动有肯定的自适应能力，而故障容忍性则是通过弹性自愈确保服务中的利用或实例处于衰弱的状态。上述能力带来的价值收益在于降老本的同时晋升利用可用性，一方面，资源使用量贴合利用理论消耗量，另一方面，晋升峰值的利用可用性，进而灵便适应市场的一直倒退与变动。 上面将对以后较为广泛的三种弹性伸缩模式进行论述和剖析。 首先是IaaS弹性伸缩，其代表产品是各云厂商云服务器弹性伸缩，如阿里云ess,能够通过配置云监控的告警规定来触发相应的ecs增减操作，同时反对动静增减slb后端服务器和rds白名单来保障可用性，通过健康检查性能实现弹性自愈能力。ess定义了伸缩组的概念，即弹性伸缩的根本单位，为雷同利用场景的ECS实例的汇合及关联slb,rds,同时反对多种伸缩规定，如简略规定，提高规定，指标追踪规定，预测规定等，用户的应用流程为创立伸缩组和伸缩配置，创立伸缩规定，监控查看弹性执行状况。 kubernetes弹性伸缩，这里次要关注于程度弹性hpa，其代表产品为k8s以及其所对应的托管云产品，如阿里云容器服务，k8s做为面向利用运维的基础设施和Platform for Platform,提供的内置能力次要是围绕着容器级别的治理和编排来开展的,而弹性能力聚焦于对底层pod的动静程度伸缩，k8s hpa通过轮询pod的监控数据并将它与指标期望值比拟进行，通过算法实时计算来产生冀望的正本数，进而对workload的正本数进行增减操作，用户在理论应用上须要创立并配置对应的指标源和弹性规定以及对应的workload，能够通过事件来查看弹性的执行状况。 最初介绍一下利用画像弹性伸缩，其次要用于互联网公司外部，如阿里asi容量平台。容量平台提供容量预测服务和容量变更决策服务，领导底层容量变更组件如AHPA/VPA实现容量弹性伸缩，并依据弹性后果修改容量画像。以画像驱动为主 + 指标驱动为辅实现弹性伸缩能力，通过提前伸缩 + 实时修改来升高弹性伸缩危险。整个弹性伸缩会借助odps和机器学习能力对实例监控等数据进行解决并产生利用画像，如基准画像，弹性画像，大促画像等，并借助容量平台来实现画像注入，变更管控和故障熔断等操作。用户应用流程为利用接入，基于历史数据/教训生成对应的容量画像，实时监控指标修改画像，并监控查看弹性执行状况。 从比照能够看出各产品弹性伸缩性能模式上从形象来讲基本相同，均由触发源，弹性决策和触发动作组成，触发源个别依赖内部监控零碎，对节点指标，利用指标进行采集解决，弹性决策个别基于周期性轮询并算法决策，有局部基于历史数据分析预测以及用户定义的定时策略，而触发动作为对实例进行程度扩缩，并提供变更记录与对外告诉。各个产品在此基础上做场景丰盛度，效率，稳定性的竞争力，并通过可观测能力晋升弹性零碎的透明度，便于问题排查和领导弹性优化，同时晋升用户应用体验与粘性。 各产品弹性伸缩模型也存在这肯定的差别，对于IaaS弹性伸缩，其作为老牌弹性伸缩能力，积淀工夫长，功能强大且丰盛，云厂商间能力趋于同质化。弹性效率相较容器受限，且强绑定各自底层iaas资源。kubernetes作为开源产品，通过社区力量一直优化迭代弹性能力和最佳实际，更合乎绝大部分开发运维人员诉求。对弹性行为和api进行高度形象，但其可扩展性不强，无奈反对自定义需要。而利用画像弹性伸缩具备团体外部特色，依据团体利用现状和弹性诉求进行设计，且更聚焦于资源池估算老本优化，缩容危险，复杂度等痛点。不易拷贝扩大，特地对于内部中小客户不实用。 从终态指标上，能够看出私有云与互联网企业方向的不同： 互联网企业往往因为其外部利用具备显著流量特色，利用启动依赖多，速度慢，且对整体资源池容量水位，库存财务管理，离在线混部有组织上的诸多诉求，因此更多的是以容量画像提前弹性扩容为主，基于metrics计算的容量数据作为实时修改，其指标是容量画像足够精准以至于资源利用率达到预期指标。私有云厂商服务于内部客户，提供更为通用，普适的能力，并通过可拓展性满足不同用户的差异化需要。尤其在serverless场景，更强调利用应答突发流量的能力，其指标在于无需容量布局，通过指标监控配合极致弹性能力实现利用资源的近乎按需应用且整个过程服务可用。Serverless弹性落地 Serverless作为云计算的最佳实际、云原生倒退的方向和将来演进趋势，其外围价值在于疾速交付、智能弹性、更低成本。 在时代背景下，SAE应运而生，SAE是一款面向利用的Serverless PaaS平台，反对 Spring Cloud、Dubbo等支流开发框架，用户能够零代码革新间接将利用部署到 SAE，并且按需应用，按量计费，能够充分发挥serverless的劣势为客户节俭闲置资源老本，同时体验上采纳全托管，免运维的形式，用户只需聚焦于外围业务开发，而利用生命周期治理，微服务治理，日志，监控等性能交由SAE实现。 SAE的技术架构如图所示，下层runtime分为网关路由，利用生命周期治理与商业化，镜像构建，定时工作，集群代理等多个模块。底层infra为多租Kubernetes，应用神龙裸金属平安容器、VK对接ECI两种形式提供集群计算资源。用户在SAE中运行的利用会映射到Kubernetes中相应的资源。其中多租能力是借助零碎隔离、数据隔离、服务隔离和网络隔离实现租户间的隔离。 弹性的竞争力次要在于场景丰盛度，效率，稳定性的竞争力，先讲一下SAE在弹性效率上的优化。 通过对SAE利用的整个生命周期进行数据统计和可视化剖析，其蕴含调度，init container 创立，拉取用户镜像，创立用户容器，启动用户容器&利用这几个阶段，示意图中对其耗时的占比进行了简化。咱们能够看到整个利用生命周期耗时集中于调度，拉取用户镜像，利用冷启动这几个阶段。针对于调度阶段，其耗时次要在于SAE以后会执行买通用户VPC操作，因为该步骤强耦合于调度，自身耗时较长，且存在创立长尾超时，失败重试等状况，导致调度链路整体耗时较长。由此产生的疑难是可否优化调度速度？可否跳过调度阶段 ? 而对于拉取用户镜像，其蕴含拉取镜像与解压镜像的时长，特地是在大容量镜像部署的状况下尤为突出。优化的思路在于拉取镜像是否能够优化应用缓存，解压镜像是否能够优化。而对于利用冷启动，SAE存在大量单体和微服务的JAVA利用，JAVA类型利用往往启动依赖多，加载配置慢，初始化过程长，导致冷启动速往往达到分钟级。优化的方向在于可否防止冷启动流程并使用户尽量无感，利用无革新。 首先SAE采纳了原地降级能力，SAE起初应用了k8s原生的deployment滚动降级策略进行公布流程，会先创立新版本pod，再销毁旧版本pod进行降级，而所谓原地降级，即只更新 Pod 中某一个或多个容器版本、而不影响整个 Pod 对象、其余容器的降级。其原理是通过 K8s patch 能力，实现原地降级 container，通过 K8s readinessGates 能力，实现降级过程中流量无损。原地降级给SAE带来了诸多价值，其中最重要的是防止重调度，防止Sidecar容器（ARMS,SLS,AHAS）重建,使得整个部署耗时从耗费整个Pod生命周期到只须要拉取和创立业务容器，于此同时因为无需调度，能够事后在Node上缓存新镜像，进步弹性效率。SAE采纳阿里开源openkruise我的项目提供的cloneset作为新的利用负载，借助其提供的原地降级能力，使得整个弹性效率晋升42%。 ...

摘要：这天上班后，小 Hi 坐在公司的咖啡厅，正想着要约运维MM小V 早晨一起看电影，忽然，老板打来了电话……本文分享自华为云社区《【疾速玩转华为云开发】 看小 Hi 如何通过 DevStar 疾速入门 Serverless 架构》，作者：麻利的小智 。 初创公司R：刚刚创建，致力于通过热门技术，帮忙中小企业数字化转型，富丽转身。 公司成员：老板R、程序猿小Hi、高级专家大V、运维妹子小V… … 注：剧情须要，本文情节纯属杜撰，请勿对号入座。 程序员小 Hi 上次应用华为云 CLI 联合批处理脚本完满的帮运维妹子搞定了批量扩容，恋情事业双丰收，好像本人的人生曾经达到了巅峰。这天上班后，小 Hi 坐在公司的咖啡厅，正想着要约运维MM小V 早晨一起看电影，忽然，老板打来了电话…… 小 Hi 心里想，本人最近的体现越来越优异，老板必定要给本人贬值加薪了。 老板：刚刚完结的除夕流动，咱们的服务禁受住了考验，在大量的用户同时拜访的状况下，服务仍然能做出疾速的响应，十分的难得，然而流动曾经过来了，咱们不再须要几百台 ECS 和磁盘了，为了节约老本，把 ECS 和磁盘的容量缩小一些，素日够用即可。等咱们的业务量下来了或者再搞流动时，再扩容。 小 Hi：好的，老板，我这就去解决。 …… 小 Hi 的情绪此时五味杂陈，好像人生从巅峰自由落体到了低谷。” 哪里有说的那么容易……”, 小 Hi 心里暗自嘀咕，无论扩容还是缩容，都须要先理解服务在日常的场景中须要承载的用户量，并且做深度的性能测试，如果贸然拍脑门缩容，万一服务出问题，怎么像老板交代…… 哎！！！ 此时，高级专家大V听到了小 Hi 的叹气声，立即问他产生了什么事件。 …… 得悉小 Hi 的困惑后，高级专家大V笑了笑，对小 Hi 说，曾经 2021 年了，何不借此大好时机尝试给架构做一次降级？目前比拟火的 Serverless 架构正好可能解决你的困扰。待我给你介绍下 Serverless 给用户具体会带来哪些商用价值： 升高运维需要 Serverless 使得利用与服务器解耦，业务上线前无需预估资源，无需进行服务器购买、配置；Serverless 也使得底层运维工作量进一步升高，业务上线后，也无需担心服务器运维，而是全副交给了云平台或云厂商；升高经营老本 Serverless 的利用是按需执行的。利用只在有申请须要解决或者事件触发时才会被加载运行，在闲暇状态下 Serverless 架构的利用自身并不占用计算资源；而在应用 Serverless 产品时，用户只须要为解决申请的计算资源付费，而无须为利用闲暇时段的资源占用付费；缩短迭代周期、上线工夫 Serverless 架构带来的是进一步的业务解耦，利用性能被解形成若干个细颗粒度的无状态函数，开发能够聚焦在单功能的疾速开发和上线上；同时拆解后的云函数，也都能够进行独立的迭代降级，更疾速的实现业务迭代，缩减性能的上线工夫；疾速试错 利用 Serverless 架构的简略运维、低成本及疾速上线能力，能够来疾速尝试业务的新形态、新性能；利用 Serverless 产品的强弹性扩容能力，在业务获得成功时，也无需为资源扩容而放心；小 Hi: （真的吗？） ...

简介： Serverless 的呈现给传统企业数字化转型带了更多时机。 某零售商超行业的龙头企业，其次要业务涵盖购物中心、大卖场、综合超市、规范超市、精品超市、便利店及无人值守智慧商店等零售业态，波及全渠道批发、仓储物流、餐饮、生产服务、数据服务、金融业务、跨境贸易等畛域。为了继续反对业务高速且稳固地倒退，其在疾速上云后，将外围业务革新为全 Serverless 架构的中台模式，采纳函数计算 + API 网关 + 表格存储 OTS 作为计算网络存储外围，弹性撑持日常和大促峰谷所需资源，轻松撑持 618/ 双 11/ 双 12 大促。 传统企业为什么更须要关注 Serverless为了升高技术研发老本、晋升运维效率，越来越多的企业抉择应用 Serverless 作为根底研发底座，大力发展业务。在 CNCF Serverless 钻研报告中显示，大量的国内开发人员正在将传统架构往 Serverless 上做迁徙。Serverless 的呈现给传统企业数字化转型带了更多时机。 现如今，大量尖端技术人才更偏差在互联网公司待业，传统企业又面对着大量技术升级和重构技术架构的刚需，人才缺口和技术升级之间产生了对云原生技术的需要。Serverless 的呈现抹平了研发人员在估算、运维教训上的有余。在帮忙企业反抗业务洪峰的状况下，研发人员能轻易掌控解决，不仅极大地升高了研发技术门槛，而且大规模晋升了研发效率。对于开发者而言，线上预警、流量观测等工具一应俱全，要害是免去了运维累赘，切实为宽广开发者提供了普惠技术红利。对传统企业而言，Serverless 缩短了互联网公司与传统企业之间技术竞争力的间隔。 从上云到云原生2016 年当前，随着国内公共云的迅速倒退，全面上云势不可挡。某出名大型商场在 2018~2019 年期间，把自建机房中的各个系统模块逐步迁徙到了私有云，整体架构没有太大扭转，因而迁徙工作比较顺利。 零碎全面迁徙上云后一些改良和有余不再须要关怀网络、操作系统的硬件细节 比方阿里云的 ECS 会提前做调度和预警，把用户数据转移并做多份数据的备灾，避免磁盘坏掉的状况产生。 降级快捷简略 比方用户应用的是 4 核的机器，当发现业务增长迅速须要做硬件降级时，就只须要做一个镜像。比方在夜间做一个磁盘快照，从新申请一台新机器，而后把快照复原下来，就能够实现一键迁徙。对用户来说这是十分快捷的形式，对开发者来说也是较好的体验。 机器扩容工夫大幅缩短 下面提到的是单机扩容，比方 4 核升到 8 核、16G 升到 32G 的内存。除此之外还有横向的扩容，例如用户交易系统的 API 接口，随着业务的倒退须要由原来的 2 台机器扩到 8 台机器，这种状况下用户只需去申请机器，而后将镜像扩大到不同的机器上即可。 资源估算艰难 无奈预估业务遇到大促流动时所能达到的体量，因而无奈精确计算出所需硬件的数量。 程度扩大 程度扩大对研发有较高的要求。比方数据是否要做到无状态，无状态的话程度扩大会比拟容易，而如果是有状态，数据可能就须要做缓存，这就会波及到数据库相干的问题，例如数据过期、一致性等。如果对这些理解不够透彻，做程度扩大就会比拟艰难。 水位监控 许多开发者在水位监控上解决得并不欠缺，如果将各个业务零碎混在一台机器上，当遇到机器水位较高，想要疾速排查问题并及时进行流控、拆分、长期修复等就显得尤为艰难。 财务预算艰难 与资源估算艰难相似。 硬件降级老本高 要做到用户无感无损降级，可能会波及到连贯上的解决与数据库一致性的问题。如果多个模块须要同时降级，还要留神数据结构的兼容问题。 ...

某零售商超行业的龙头企业，其次要业务涵盖购物中心、大卖场、综合超市、规范超市、精品超市、便利店及无人值守智慧商店等零售业态，波及全渠道批发、仓储物流、餐饮、生产服务、数据服务、金融业务、跨境贸易等畛域。为了继续反对业务高速且稳固地倒退，其在疾速上云后，将外围业务革新为全 Serverless 架构的中台模式，采纳函数计算 + API 网关 + 表格存储 OTS 作为计算网络存储外围，弹性撑持日常和大促峰谷所需资源，轻松撑持 618/ 双 11/ 双 12 大促。传统企业为什么更须要关注 Serverless为了升高技术研发老本、晋升运维效率，越来越多的企业抉择应用 Serverless 作为根底研发底座，大力发展业务。在 CNCF Serverless 钻研报告中显示，大量的国内开发人员正在将传统架构往 Serverless 上做迁徙。Serverless 的呈现给传统企业数字化转型带了更多时机。现如今，大量尖端技术人才更偏差在互联网公司待业，传统企业又面对着大量技术升级和重构技术架构的刚需，人才缺口和技术升级之间产生了对云原生技术的需要。Serverless 的呈现抹平了研发人员在估算、运维教训上的有余。在帮忙企业反抗业务洪峰的状况下，研发人员能轻易掌控解决，不仅极大地升高了研发技术门槛，而且大规模晋升了研发效率。对于开发者而言，线上预警、流量观测等工具一应俱全，要害是免去了运维累赘，切实为宽广开发者提供了普惠技术红利。对传统企业而言，Serverless 缩短了互联网公司与传统企业之间技术竞争力的间隔。 从上云到云原生 2016 年当前，随着国内公共云的迅速倒退，全面上云势不可挡。某出名大型商场在 2018~2019 年期间，把自建机房中的各个系统模块逐步迁徙到了私有云，整体架构没有太大扭转，因而迁徙工作比较顺利。零碎全面迁徙上云后一些改良和有余改良 不再须要关怀网络、操作系统的硬件细节 比方阿里云的 ECS 会提前做调度和预警，把用户数据转移并做多份数据的备灾，避免磁盘坏掉的状况产生。降级快捷简略 比方用户应用的是 4 核的机器，当发现业务增长迅速须要做硬件降级时，就只须要做一个镜像。比方在夜间做一个磁盘快照，从新申请一台新机器，而后把快照复原下来，就能够实现一键迁徙。对用户来说这是十分快捷的形式，对开发者来说也是较好的体验。机器扩容工夫大幅缩短下面提到的是单机扩容，比方 4 核升到 8 核、16G 升到 32G 的内存。除此之外还有横向的扩容，例如用户交易系统的 API 接口，随着业务的倒退须要由原来的 2 台机器扩到 8 台机器，这种状况下用户只需去申请机器，而后将镜像扩大到不同的机器上即可。 有余资源估算艰难 无奈预估业务遇到大促流动时所能达到的体量，因而无奈精确计算出所需硬件的数量。程度扩大程度扩大对研发有较高的要求。比方数据是否要做到无状态，无状态的话程度扩大会比拟容易，而如果是有状态，数据可能就须要做缓存，这就会波及到数据库相干的问题，例如数据过期、一致性等。如果对这些理解不够透彻，做程度扩大就会比拟艰难。水位监控许多开发者在水位监控上解决得并不欠缺，如果将各个业务零碎混在一台机器上，当遇到机器水位较高，想要疾速排查问题并及时进行流控、拆分、长期修复等就显得尤为艰难。 财务预算艰难与资源估算艰难相似。 硬件降级老本高要做到用户无感无损降级，可能会波及到连贯上的解决与数据库一致性的问题。如果多个模块须要同时降级，还要留神数据结构的兼容问题。数据库单点故障许多厂家将数据全副放在一个数据库中，如果解决不得当可能会造成单点故障。这就要做数据拆分，粗拆的话，须要留神事务和锁相干的问题，效率会大打折扣；细拆的话，做查问和排序时就会比拟艰难，给业务实现造成肯定麻烦。业务挑战在一次年中大促时，因为线上业务用户拜访不可控，数据量过大，MySQL 单机拜访被打爆，导致了存储数据库呈现问题，影响到了多个零碎，造成了肯定的损失。因而在后续服务化革新过程中，数据库选型由 MySQL 更改为表格存储 OTS，表格存储最大的长处是用户不须要关怀访问量和机器数的比例关系。只有访问量扩充，后盾会主动扩容增扩机器，满足高并发的数据读取；在数据并发申请升高处于低峰期时，后盾就会将机器回收，用户不再须要关怀机器的数量及如何调动。 Serverless 革新 针对用户流量不可控问题，客户引入了阿里云的产品 “API 网关” ，API 网关能够针对不同渠道商做管控公布及流量管制。比方发现微信渠道流量有异样，就能够借助 API 网关进行限流。 ...

事件是这样的…… 前天下午天太热，我在家看电视，换台忽然就看到了正在播《西游记》，窗外蝉声特地响，我一下就有种穿梭回小学寒假的感觉。过后，我就特地想把我那台小霸王翻出来，玩两盘街霸……虐一下春丽翻了大半天，也没找到我的童年回顾...要么找找看有没有啥开源的能够玩玩吧！作为一名家养程序员，搜寻技能必须牛逼，一顿搜寻之后，我发现最近阿里云有一个挺火的体验流动，这个流动是用 Serverless 部署掌上游戏机，实现后还送一台实物游戏掌机。这不跟我想一块去了，开整！整个过程的确简略，我先把链接放上面。 PC端体验好一点：https://developer.aliyun.com/... 体验过程想撸完游戏机就走，起初发现这个体验有点意思。这个体验的部署应用了 Serverless 产品阿里云函数计算和开发者工具 Serverless Devs，整个体验工夫短，步骤分明，应用资源收费，能真实感受到 Serverless 的劣势。我先分享一下体验过程。 步骤一：函数计算入门-Hello World首先依照文档要求开明函数计算服务，体验须要的函数计算资源收费。留神肯定要用本人的阿里云账号，用子账号部署必定失败。 接下来，要在函数计算控制台首页新建函数，看到函数运行胜利，并返回：你好，世界！这一步才算实现，非常简单。 步骤二：一键部署掌上游戏机 这个步骤会应用到 Serverless Devs 命令行工具，这是一个组件化与插件化的 Serverless 开发者平台也是开源的，开发者能够在平台中可插拔式的应用不同 Serverless 的服务和框架，用它就不必学习市场上 Serverless 其余工具，简略、快能比较简单、快捷的上手支流 Serverless 服务和框架。 这个步骤有6个操作：1、执行如下命令，在以后门路初始化一个掌上游戏机我的项目。 s init fc-nes-game2、为要创立的我的项目输出一个名称，本示例中为：fc-nes-game。fc-nes-game3、抉择默认凭据后按按回车。返回后果如下，示意初始化实现。4、执行如下命令，进入fc-nes-game目录。 cd fc-nes-game5、执行如下命令，部署掌上游戏机我的项目。 s deploy返回后果如下，示意装置掌上游戏机我的项目部署实现，并复制 custom_domain->domain的url。6、关上手机浏览器，在浏览器地址栏粘贴 url并拜访。如果呈现二维码页面，示意部署胜利，用手机扫描二维码，就能玩掌上游戏机。到这就实现全副体验了，接下来坐等每天早上10:00 秒游戏机就行了。 手机秒变游戏机网上很多开源我的项目能够下载掌机游戏（nes 格局的），能够间接放在这个掌机里玩，让手机变成游戏机，能够搜寻下载掌机游戏（nes格局的）：1）寄存到 src/roms 目录下2）批改 index.htm 的 91 行代码，自行添加游戏名称和寄存的相对路径 坐等游戏机体验晦涩，奖品也很香，昨天秒到了一台当初坐等发货了！流动从7月28日到8月10日，每个工作日发200台，只有做完体验，每天早上 10:00 去领，能够冲！流动链接：https://developer.aliyun.com/...

简介： 云原生曾经成为IT界最风行的一个定语，仿佛不谈云原生就out了，但什么才是真正的云原生？ 注：本文作者马涛，阿里云智能研究员、阿里巴巴团体内核团队创始人之一、阿里云根底软件部操作系统团队负责人。先后在ORACLE、阿里巴巴负责Linux以及操作系统内核相干的研发工作。十五年以上操作系统和内核相干研发教训，国内出名Linux内核研发人员，在文件系统、内存治理、通用块设施层等方面均有深厚的积攒，屡次受邀在国内外出名Linux操作系统以及内核相干会议上发表讲座。 当初咱们在各个场合能够看到各种各样的“云原生XXX”，云原生曾经成为IT界最风行的一个定语，仿佛不谈云原生就out了。但什么才是真正的云原生？把老的技术跑在云上就能够了么？貌似不太行！用阿里云高级研究员蒋江伟的一句话来定义——“因云而生才是云原生”。简略来说，一个产品或者技术要能真正加上云原生这个定语，肯定要有因云而生的翻新和演进，所以想加上云原生这个定语可不是容易的。如果各位读者感兴趣，能够上网搜寻文章“阿里云蒋江伟：什么是真正的云原生？” 明天，我就自告奋勇来讲讲云原生操作系统。 大家可能比拟好奇，操作系统不是所有用电脑的人每天都在应用的玩意么？“操作系统原理”不是个别计算机系同学的第一门艰深的专业课么？当初最风行的操作系统Linux不是1991年就由Linus Torvalds大神创建了么？以上问题的答案都是必定的，那么，这么一个颇为传统的系统软件也能够云原生了么？对，操作系统也要与时俱进！所以，明天我站在操作系统的角度，来谈谈这个颇为传统的系统软件是如何因云而生、因云而变，成为“云原生操作系统”的。 在开展讲技术之前，我先简略介绍一下本人。我是从2006年开始与操作系统结缘的，最开始是在Oracle从事操作系统的开发工作，2010年退出淘宝外围零碎做操作系统，作为阿里最早一批做操作系统的同学，从淘宝到阿里云始终坚守在操作系统畛域，一路参加和见证了操作系统在阿里因云而生的演进倒退。尽管淘宝也是一家互联网公司，然而淘宝的操作系统和传统的操作系统其实区别并不大。所有因云而生的扭转从我2012年从淘宝转入阿里云开始。 那个时候，阿里云的操作系统和淘宝的有区别么？主观来说区别不大。惟一的一点点区别：在淘宝，操作系统是淘宝的一个根底组件；而在阿里云，操作系统和虚拟化成为了第一代云计算的基石，这是操作系统和云的第一次密切接触。 2000年左右，VMware和Xen虚拟化技术相继呈现，操作系统通过将物理资源虚拟化达到进步资源利用率和灵便调度的目标，最终催生了云计算的诞生。晚期的AWS、阿里云都是利用这一技术提供虚拟主机的服务。这是云原生么，是因云而生的么？当然不是。首先这些云厂商大都是在线下硬件上实现一个虚拟化层（hypervisor），把原来间接操控硬件的操作系统架到hypervisor上运行，而后服务器物理资源层面的形象和治理都由hypervisor从新实现。那么，这个事件线下能做么？相对能够，所以显然这不合乎云原生的定义。虽说这是云的开始，但这不是云原生的。 工夫来到了2013年，操作系统和云的第二次密切接触源于容器的诞生和倒退。与虚拟机的服务器资源虚拟化不同，容器是操作系统虚拟化，在技术栈上回升了一层——通过内核里实现的cgroup和namespace等技术为不同利用提供轻量、隔离的运行环境。2013年docker的横空出世，使得利用容器的打包散发变得非常简单易用，随后k8s等容器编排技术的呈现，容器生态系统失去了疾速的遍及和倒退，容器也迅速成为利用打包散发和开发测试的支流状态，逐步成为云计算的次要运行单元。 这就是CNCF定义的云原生了，但它只是“广义”的，操作系统在这个“广义”云原生中起到了很大的作用，但其实它并不是真正意义上的“因云而生的”，也没有在云上体现任何革命性的技术革新。 不过仔细观察一下上图，咱们能够发现——容器在平安方面的有余在云上成为了一个大问题。一方面传统的操作系统对于容器之间的烦扰问题没有很好的解决方案，另一方面容器之间还存在彼此攻打，共享一些要害资源等十分重大的平安问题。机会总是留给有筹备的人，此时的操作系统终于须要因云而变、为云演进了。咱们基于操作系统实现了轻量级虚拟化和利用内核等技术，打造了一种全新的平安的容器，咱们称之为平安沙箱容器。 沙箱容器在解决容器平安隔离问题的同时，依然保留容器残缺的技术生态和体验，能够跟一般容器无缝的混合应用。这是操作系统在容器场景上因云而生的一个重要演进，至此操作系统实现了“因云而生”的丑陋转型，成为一个云原生操作系统。目前这套零碎曾经服务于阿里团体各个云原生相干业务，也通过阿里云上各种容器实例产品服务于咱们的云客户。 故事到这里还没有完结。面向未来的云原生，操作系统如何持续“因云而不同凡响”呢？这就不得不提云原生中另外一个趋势Serverless。 2019年，UC伯克利大学预测Serverless将会逐步取代Serverful计算，成为云时代的新计算范式。随着云原生理念的推广以及各种云原生技术的一直倒退，Serverless计算的趋势在减速。在这种新场景中，用户只须要专一于利用和业务逻辑，更多的通用性能、资源和零碎能力都下沉到云，用户不须要提前布局容量，不须要运维底层零碎，能够真正像用水、用电一样按需应用按需付费，Serverless将大幅晋升云的生产效率。 背景介绍完，问题也来了—— Serverless和操作系统有啥关系呢？我认为要构建好Serverless服务，操作系统肯定不能缺席。因为Serverless场景下服务边界的上移，对用户来说利用容器或函数代码之下的零碎就是一个整体，用户不再感知底层零碎的技术栈分层。这个变动给技术垂直整合发明了条件。咱们认为云原生的操作系统须要进行整体性的全栈优化和重塑，这样能力为Serverless提供更优的底层零碎能力，根底运行环境、资源弹性、高效执行等能力也将因而失去极大的开释。 如果说在容器和K8S时代操作系统是“因云而演进”，那么到了Serverless时代，咱们则要彻底发明出一个全新的云原生操作系统。通过底层零碎全栈技术的协同交融，为云原生平台和利用提供高效和翻新的云原生零碎服务。这次改革和翻新的力度对于传统操作系统而言是前所未有的，然而咱们深信，操作系统肯定会为云而扭转，为云而新生。在阿里外部，咱们给这样的云原生操作系统起了一个嘹亮的名字——“袋鼠”。 多年之后，兴许大学课程“操作系统原理”里的内容会因为这次改革而产生天翻地覆的扭转，但咱们深信，这就是云带给咱们这一代操作系统研发人员的使命：从新定义操作系统。只有通过因云而生的技术创新打造进去的操作系统，才是真正的云原生操作系统。 原文链接本文为阿里云原创内容，未经容许不得转载。

简介：夏日大作战，体验极速部署的乐趣！ 起源 | 阿里云开发者公众号 Serverless 以其疾速交付、智能弹性、高可用性、低成本等外围价值成为云计算中一股新生力量，取得有数开发者的青眼。 为了让更多开发者在实在场景中，体验 Serverless 的劣势，破解工具之困，这一次咱们用 Serverless 开发者工具 Serverless Devs + 函数计算形式打造乏味场景，推出《1 分钟 Serverless 极速部署掌上游戏机》体验流动！让你只用 “一行命令” 进入 Serverless 世界，找回小时候的乐趣！ 2021 年 7 月 28 日 至 8 月 10 日期间，开发者顺次通过 2 个挑战工作，即可取得掌上游戏机，咱们会在每个工作日送出 200 台！ 立刻体验 https://developer.aliyun.com/adc/series/activity/serverlessdevs 如何参加辨认下方二维码即可进入体验页面。 若有相干问题可钉钉搜寻群号：35791205 进群征询！ 流动详情 一键进入 Serverless 世界！ https://developer.aliyun.com/adc/series/activity/serverlessdevs 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：原来的微服务用户须要自建十分多的组件，包含 PaaS 微服务一些技术框架，运维 IaaS、K8s，还包含可观测组件等。SAE 针对这些方面都做了整体的解决方案，使用户只须要关注本人的业务零碎，这极大地升高了用户应用微服务技术的门槛。作者 | 陈涛 微服务架构的长处和痛点1、微服务架构的诞生背景 回到互联网晚期时代，也就是web1.0时代，过后次要是一些门户网站，单体利用是过后的支流利用，研发团队绝对较小，这时候的挑战在于技术的复杂度，以及技术人员的匮乏。到了新世纪互联网时代，呈现了较大规模的一些利用，比方社交、电商等，流量和业务的复杂度也大幅减少，呈现了几百甚至上千人的研发团队，研发团队扩充之后，合作问题成为困扰。SOA 解决方案是互联网的产物，其外围在于分布式、拆分等。然而因为 ESB 这样一些单点的组件，所以没有失去很好的推广。阿里巴巴在过后推出的 HSF、开源的Dubbo 等技术，其实是相似于分布式的一个解决方案，过后就曾经有了微服务架构的理念。 微服务架构正式名称的诞生是在挪动互联网时代，这时的生存曾经实现全面互联网化，各种各样的生存类 APP 涌现，网民以及流量复杂度绝对于新世纪互联网时代显著加强。另外，较大规模的研发团队也已成为支流。这时候，大家广泛都对效率有了更高的谋求，而不只是原来只有几个巨头须要有这方面的技术。微服务架构以及微服务技术的推出，如 Spring Cloud、Dubbo 等框架的遍及，极大地推广了微服务技术。 当初咱们曾经进入全面的数字化时代，社会全面互联网化，各种各样的单位（包含政企、绝对传统的单位）都须要较强的研发能力。流量的挑战、业务复杂度的挑战、研发团队的扩充等，使得大家对效率有了更高的要求。这时候微服务架构失去了进一步的推广和遍及。 微服务架构通过这么多年的倒退，是经久不衰的一项技术，为什么它可能有这样继续的倒退？ 2、微服务架构的长处 咱们来回顾一下微服务架构和单体架构的区别，以及微服务架构的外围劣势。 单体架构外围的问题在于抵触域太大，包含共享代码库。在研发过程中特地容易抵触；边界和模块的规模不清，使得团队效率也会升高。 而在微服务架构下，外围就在于拆分，包含解耦的研发态，解耦的部署态，极大地开释了团队的研发效率。大道至简，这也是微服务架构为什么可能继续倒退的一个起因。 3、微服务时代痛点 依据复杂性守恒定律，咱们解决了一个问题，问题会以另一种模式呈现，咱们又须要去解决。能够看到，微服务时代下会引入十分多的一些痛点，外围就是稳定性。因为从原来的一些本地调用改成近程调用当前，可能会产生稳定性的点激增，包含调度放大，即可能因为底层的一些近程调用问题，造成下层的一些不稳固，以及期间须要做的限流降级、调用链等。 在微服务时代定位一个问题的复杂度，也会成指数级的一个增长，这外面可能还须要服务治理。另外如果没有较好的设计和事后的一些构想，可能会呈现微服务利用的爆炸，包含研发人员和测试人员之间的合作也都会成问题。 微服务技术通过这么多年的倒退，业界其实曾经有了一些解决方案。 如上图显示，如果要比拟好地玩转微服务技术，除了开发本人的业务零碎以外，可能还要配套地搭建多个零碎，包含CI/CD、公布零碎、研发流程、微服务组件相干的一些工具，以及可观测性相干的实时监控、告警零碎、服务治理、调用链等等，还须要运维根底的 IaaS 资源。在这个时代，为了更好地运维 IaaS 资源，可能还须要本人保护一个K8s 集群。 所以说，在这样的背景下，很多企业会抉择搭建一个运维团队，或者中间件团队，或者说由一些后端研发同学兼职。然而试想，有多少企业对本人外部搭建的这套零碎是称心的？零碎的迭代效率是多少，有没有踩到过一些开源的坑，这些坑当初有没有解决？这些应该是在企业的CTO、架构师心中一个继续的痛点。 Serverless时代下的解决方案1、Serverless时代 Serverless 从2012年第一次提出，到 2014年 推出了 Lambda 这样一个引爆性的产品后，短暂地达到了一个影响力的高峰。然而这样一个新生事物，忽然到实在的、简单的生产环境中，其实有许多不适应，包含须要改善的中央，所以后续几年它可能要进入一个低谷。 然而，Serverless 的“将简略交给用户，简单留给平台”的理念，其实是十分正确的一个方向。所以在开源界包含业界，其实都在持续性地进行 Serverless 方面的一些摸索和倒退。 阿里云在2017年推出了函数计算（Function Compute，FC），在2018年推出了Serverless利用引擎 SAE，在 2019年以及后续的这些年，阿里云继续地在 Serverless 畛域进行投入，反对了包含镜像部署、预留实力、微服务场景等。 2、Serverless 市场详情 在2021年最新的 Forrester 评测中，阿里云 Serverless 产品能力是中国第一、寰球当先，阿里云的 Serverless 用户占比也是中国第一。这侧面阐明了阿里云 Serverless 是曾经越来越多地进入到企业实在的生产环境中，越来越多的企业认可 Serverless 以及阿里云 Serverless 的能力和价值。 ...

简介：现在，曾经有评测机构给出了40条规范来对Serverless的服务能力进行评估，这些评估细则既是技术生态凋敝倒退的一种体现，也能够作为新进入者评估Serverless落地功效的一种参考根据。 编者按：两年前，咱们还在探讨什么是Serverless，Serverless如何落地。现在，曾经有评测机构给出了40条规范来对Serverless的服务能力进行评估，这些评估细则既是技术生态凋敝倒退的一种体现，也能够作为新进入者评估Serverless落地功效的一种参考根据。 在 Forrester 的这份函数即服务 (FaaS) 平台评估报告中，咱们抉择了阿里巴巴、亚马逊、谷歌、华为、IBM、微软、Nimbella、甲骨文和腾讯这 9 家最具影响力的提供商，并根据 40 条规范对其进行了钻研、剖析和评分。该报告展现了每个提供商在各方面的体现，旨在帮忙从事利用程序开发与交付 (AD&D) 的专业人士找到最合乎本身需要的提供商。 Forrester Wave™：函数即服务 (FaaS) 平台 2021 年第一季度报告FaaS 平台帮忙开发人员疾速创立云原生服务FaaS 平台的抽象化让开发人员不再须要关注简单的容器或虚拟机集群治理与扩容工作，从而能够疾速创立云原生微服务。将底层基础架构的管理工作交给 FaaS 提供商之后，开发人员就能够在编程环境中，应用 Java、C#、JavaScript 或 Python 等相熟的语言，将微服务编写成简略的小函数。而后，FaaS 提供商会依据服务要求，主动对这些微服务进行扩容或缩容。应用 FaaS 平台的开发人员示意，通过免于基础架构治理，借助抽象化打消与此相关的简单操作后，他们能够迅速将新的想法推入部署阶段，同时能够依据执行微服务的理论资源需要来确定基础架构费用。在筛选 FaaS 提供商时，开发人员应剖析该提供商是否具备以下条件： • 反对函数和容器打包。随着开发人员将越来越多类型的工作负载部署到 FaaS 平台，FaaS 平台应容许开发人员简略地将一个函数打包成 ZIP 或 JAR 文件并加以部署，或者将自定义代码打包成合乎凋谢容器规范 (OCI) 的容器，并部署与之对应的框架。FaaS 平台应同时反对这两种选项，能力在开发部署 Web、内容和事件驱动的工作负载方面为开发人员提供最大的灵活性。 • 提供强壮的平安性能。随着开发人员不断扩大对 FaaS 平台的使用范畴，确保相干人员可能以平安的形式拜访被封装到虚构公有网络，或虚构公有云 (VPC) 中的数据和利用程序接口 (API) 就变得十分重要。另外在函数扩缩容的同时，相干人员还须要可能疾速接入这些资源，而无需期待耗时的“冷启动”。 • 反对第三方生态系统和凋谢规范。除非您违心齐全依赖一家私有云提供商，否则您就应抉择平台集成更为便当的 FaaS 提供商。您须要关注的性能包含第三方可观测性、事件绑定和音讯协定等。 评估摘要本次 Forrester Wave™ 评估报告将待评估对象别离纳入“领导者”(Leaders)、“强劲表现者”(Strong Performers)、“竞争者”(Contenders) 和“挑战者”(Challengers) 这几个象限。这是对市场头部厂商的评估，并不代表市场的整体状况。您能够查看咱们对于无服务器架构 (Serverless) 技术的报告，获取无关这个市场的更多信息。咱们心愿这份评估报告只是一个终点，倡议客户应用基于 Excel 的厂商比拟工具来查看产品评估并调整规范权重（请参见图 1 和图 2）。点击 Forrester.com 上网页版报告结尾的链接即可下载上述工具。 ...

简介： 基于Java语言的Spring生态，还是否适应新的开发方式，比方Cloud Native、Serverless、Faas等，它还会是云原生时代的最佳平台的抉择吗？本文将从5个角度来为你剖析一下这个问题，别离是：Java和JDK的倒退、充斥良性竞争的JVM语言、成熟的面向服务架构的Spring Boot和Spring Cloud、让事件驱动架构更易使用的Spring Reactive。 作者 | 雷卷起源 | 阿里技术公众号 大家好，我是陈立兵，花名雷卷，Java/Kotlin工程师、 Alibaba RSocket Broker开发者Reactive基金会的初创成员。目前次要关注于Reactive/RSocket、Serverless、WebAssembly、 Deno/Rust等相干技术。 明天和大家聊聊为什么我认为Spring依然会是云原生时代最佳平台之一。 工夫回到2015年，过后我在华盛顿参加SpringOne 2015大会，主题演讲是Cloud Native Enterprise。那次大会的口号也是Cloud Native，铺天盖地的海报都与Cloud Native无关。 你可能会感到奇怪，那个时候容器还没有风行啊，怎么就敢称为Cloud Native呢？尽管不少同学对Cloud Native的了解可能不太一样，然而越来越多的人置信“Cloud native is about culture, not containers”。能够必定的是，云原生不等于容器，它是一种软件开发的文化，即使后续有基于V8隔离的Serverless或者WebAssembly FaaS平台，也还是云原生的领域。 而在云原生的潮流下，Spring做了很多事件，比方反对分布式架构的Spring Cloud，它根本是Java利用分布式和云化的必备框架，各个云厂商都有Spring Cloud的对接版本，比方Spring Cloud Alibaba、AWS、Azure、GCP等，Spring Cloud极大地简化了Java利用和云服务的对接。 能够说，在微服务逐步风行的过程中，Spring生态始终处于领先地位。很多人可能会纳闷：Spring之前获得的这些成就咱们都晓得，可这两年如同并没有什么倒退，Spring还能持续引领该技术趋势吗？ 其实，之所以会有这样的纳闷，是因为当咱们谈到基于云和云原生环境的开发时，广泛更关注的是技术栈的抉择，而这背地次要是费用的问题。 每一位开发者或中小公司都心愿购买更少的云资源干更多的事件，其中最次要的是内存和CPU。内存耗费要求小，如果能编译为独立可执行程序，就尽量抉择一些轻量型的开发框架；而且要思考语言高效且全异步化的框架，这样能够保障充分利用CPU，防止线程期待等造成的节约。 综合来看，很多人会更偏向于抉择Rust、Node.js、Golang等技术栈。而Java启动慢，耗费内存多，如同还比拟费钱，看起来曾经不太适宜接下来的云原生时代。 那么作为基于Java语言的Spring生态，还是否适应新的开发方式，比方Cloud Native、Serverless、Faas等，它还会是云原生时代的最佳平台的抉择吗？ 接下来，我将从5个角度来为你剖析一下这个问题，别离是：Java和JDK的倒退、充斥良性竞争的JVM语言、成熟的面向服务架构的Spring Boot和Spring Cloud、让事件驱动架构更易使用的Spring Reactive。 一 Java 和 JDK的倒退咱们晓得Spring基于的是Java框架，而JDK又是运行Java程序的根底。要探讨“Spring还会不会是云原生的最佳平台之一”这个问题，咱们须要先来看看JDK这个底座怎么样，是不是能为Spring与时俱进的倒退提供良好的根底。 首先是版本迭代。当初OpenJDK的开发速度十分快，之前是三年出一个重大版本，当初半年就出一个版本。好多同学感叹当初都快Java 17了，而本人还在用Java 1.8。咱们都说软件开发要小步快跑，这个是一个好的开发方式：小步快跑、疾速反馈、疾速迭代开发。相似的还有JavaScript一年一版，TypeScript一年三版，Java一年两版，能够说都是十分好的节奏。 其次是JDK个性的更新。如果你关注JDK的话就不难发现，越来越多的个性被融入到JDK中，比方相似协程的轻量级线程Loom我的项目、晋升Native调用反对的Panama我的项目（SIMD反对）、更高级的GC算法等。 而针对咱们后面提到的Java启动慢、耗费内存多的问题，Oracle推出了基于OpenJDK的GraalVM，它能够间接在JVM中运行JavaScript、Python、Ruby等语言，是货真价实的Ployglot JVM。另外，GraalVM还提供了Native Image个性，能够将Java代码转换为独立可执行程序。Spring也推出Spring Native我的项目，能够十分不便将Spring Boot利用native-image化，这样Spring利用启动的速度更快，耗费的内存也更少。native-image化后的Spring利用就能够满足每一位开发者或中小公司对“上云且费用更少”的需要。即使是Java的命令行利用，GraalVM也有十分好的解决方案——Picocli + GraalVM Native Image + upx，它能够将Java利用编译为更便捷的可执行程序。 ...

作者 | 望宸起源 | Serverless 公众号 相比去年，国外 Serverless 的实用群体在迅速扩充，函数执行时长一直减少，应用形式也越加成熟，开发者工具也更加凋谢。本文是对 Datadog 最新的一份 Serverless 报告的解读，欢送大家留言探讨。每项新技术的产生和演进过程中，都会有他本人的拥趸，也会有持怀疑论者。Serverless 的美在于他能够尽可能的解放客户在基础设施上的投入，只需专一于本人的业务，让技术产生更多商业价值，同时，客户只须要真正为使用量付费，毋庸让计算资源常驻。“Datadog 上一半的 AWS 客户应用了 Lambda，80% 的 AWS 容器客户应用了 Lambda。” 是的，这个数据来自 Datadog 去年的一份调研报告，主观反映了 Serverless 在海内市场的落地过程。一年之后，Datadog 公布了第二份 Serverless 调研报告，咱们来一起看看 Serverless 在海内的最新进展，这对于无论是曾经投入建设 Serverless，还是仍处于张望状态的决策者和使用者而言，兴许都能取得一些参考。 观点 1. Lambda 的调用频率比两年前高 3.5 倍，运行时长达 900 小时 / 天Serverless 的应用深度如何来定义？自 2019 年以来，始终在应用 Lambda 的企业已大大提高了其使用率。均匀而言，到 2021 年初，这些公司每天调用函数的次数是两年前的 3.5 倍。此外，在同一组 Lambda 用户中，每家企业的性能均匀每天均匀运行达 900 个小时。 一般云服务器，是按服务器的租用配置和租用时长进行免费的，其中，租用配置是根据 vCPU 和内存定价。而函数计算则不同，按应用过程中的调用次数和函数运行时长免费的。因而，调用次数和函数运行时长是掂量客户应用 Serverless 深度的指标。报告中未提供每天调用次数绝对值的信息，但咱们能够根据每天运行 900 小时运行时长的数据，对客户在 Serverless 的生产做一个区间预估。阿里云函数计算的免费规范来计算，应用预付费模式： 1GB 计算力实例运行 1 秒所需的费用是 0.00003167 元，以内存规格 1GB，每天运行 900 小时来计算，预计将生产 102.6 元，年度生产是 3.7 万，再搭上存储、网络、平安、数据库等其余云产品的生产，曾经是一个中型企业的云上收入了。此外，函数的调用次数所产生的费用通常不会太多，尤其是 Python 这类和 AI 建模相干的函数利用，阿里云函数计算每天调用 100 万次的费用是 13.3 元。 ...

作为十大将来将影响基础设施和运维的技术趋势之一，Serverless 从诞生伊始，便被誉为“云计算的将来”。这样一项新潮的技术有哪些最新的前沿风向？在不同业务场景下，应如何进行 Serverless 最佳实际？间隔 Serverless 成为普适性的架构模式，还面临着哪些挑战？ 2021 年 6 月 5 日，由腾讯云 TVP 联结 ServerlessDays 主办的第二届 Techo TVP 开发者峰会，在北京市朝阳区嘉瑞文化核心盛大举行。以「无服务器，大有将来 Serverless，Empower More」为主题，这场技术盛会首次会集了腾讯、AWS、阿里、字节等寰球 TOP 云厂商和互联网企业。来自海内外的 20 位大咖从 Serverless 的技术生态、产品生态、行业生态三大视野，为超过 500 位到场的开发者以及 9 万名观看线上直播的观众带来了全天候、全方位、沉迷式的分享，参会规模创下了国内 Serverless 峰会的新记录。 在峰会伊始，主持人 Westar 实验室创始人、腾讯云 TVP 杨卫华倾情介绍了 Serverless 技术的发展前景：据 KBV 钻研公司预言，到 2024 年，寰球 Serverless 架构市场的规模将达到 140 亿美元，年复合增长率达 21.9%。“咱们能够看到，无服务器是大有将来的。” Westar 实验室创始人、腾讯云 TVP 杨卫华 腾讯云 Serverless 核心副总经理罗茂政的收场致辞拉开了峰会的帷幕，在致辞中， 他首先分享了对 Serverless 理念的粗浅洞见：对 Serverless 的概念了解，能够用大家相熟的领取畛域的倒退举例，在领取畛域，以前是用现金支付，当初倒退为线上领取。在过来，用户须要应用和治理现金，关注现金的安全性；而线上领取的呈现则节俭了对现金的实体治理。服务器 Server 也是如此，用户对 Server 的利用和治理相似于应用现金的概念。“Serverless 不仅仅是一个技术理念，甚至能够是一种生存理念”。 Serverless 作为热门的前沿技术，国内生态也在迅速倒退当中，如何更好地在云上赋能代码？罗茂政对峰会示意期待，置信顶尖的技术专家们会带来令人不虚此行的优质分享。 ...

作者 | 王骜起源 | Serverless 公众号 导读USENIX ATC (USENIX Annual Technical Conference) 学术会议是计算机系统畛域的顶级会议，入选中国计算机协会（CCF）举荐 A 类国内会议列表；本次会议共投稿 341 篇论文，接管 64 篇，录用率 18.8%。 阿里云 Serverless 团队第一个提出在 FaaS 场景下的去中心化疾速镜像散发技术，团队创作的论文被 USENIX ATC’21 录用。以下是论文核心内容解读，重点在缩短阿里云函数计算产品 Custom Container Runtime 的函数冷启动端到端提早。 USENIX ATC 将于 7.14-7.16 在线上举办，论文信息见：https://www.usenix.org/conference/atc21/presentation/wang-ao 摘要Serverless Computing（FaaS）是一种新的云计算范式，它容许客户只关注本身的代码业务逻辑，零碎底层的虚拟化、资源管理、弹性伸缩等都交给云零碎服务商进行保护。Serverless Computing 上反对容器生态，解锁了多种业务场景，然而因为容器镜像简单，体积较大，FaaS 的 workload 动态性高且难以预测等个性，诸多业界当先的产品和技术并不能很好的利用于 FaaS 平台之上，所以高效的容器散发技术在 FaaS 平台上面临着挑战。在这篇论文中，咱们设计并提出 FaaSNet。FaaSNet 是一个具备高伸缩性的轻量级零碎中间件，它利用到镜像减速格局进行容器散发，指标作用场景是 FaaS 中突发流量下的大规模容器镜像启动（函数冷启动）。FaaSNet 的外围组件蕴含 Function Tree (FT)，是一个去中心化的、自均衡的二叉树状拓扑构造，树状拓扑构造中的所有节点全副等价。 咱们将 FaaSNet 集成在函数计算产品上，试验结果表明，在高并发下的申请量下，相比原生函数计算（Function Compute, 下称 FC），FaaSNet 能够为 FC 提供 13.4 倍的容器启动速度。并且对于因为突发申请量带来的端到端提早不稳固工夫，FaaSNet 相比 FC 少用 75.2% 的工夫能够将端到端提早复原到失常程度。 ...

编者按：两年前，咱们还在探讨什么是 Serverless，Serverless 如何落地。现在，曾经有评测机构给出了 40 条规范来对 Serverless 的服务能力进行评估，这些评估细则既是技术生态凋敝倒退的一种体现，也能够作为新进入者评估 Serverless 落地功效的一种参考根据。在 Forrester 的这份函数即服务 (FaaS) 平台评估报告中，咱们抉择了阿里巴巴、亚马逊、谷歌、华为、IBM、微软、Nimbella、甲骨文和腾讯这 9 家最具影响力的提供商，并根据 40 条规范对其进行了钻研、剖析和评分。该报告展现了每个提供商在各方面的体现，旨在帮忙从事利用程序开发与交付 (AD&D) 的专业人士找到最合乎本身需要的提供商。 《Forrester Wave™：函数即服务 (FaaS) 平台 2021 年第一季度报告》1. FaaS 平台帮忙开发人员疾速创立云原生服务FaaS 平台的抽象化让开发人员不再须要关注简单的容器或虚拟机集群治理与扩容工作，从而能够疾速创立云原生微服务。将底层基础架构的管理工作交给 FaaS 提供商之后，开发人员就能够在编程环境中，应用 Java、C#、JavaScript 或 Python 等相熟的语言，将微服务编写成简略的小函数。而后，FaaS 提供商会依据服务要求，主动对这些微服务进行扩容或缩容。应用 FaaS 平台的开发人员示意，通过免于基础架构治理，借助抽象化打消与此相关的简单操作后，他们能够迅速将新的想法推入部署阶段，同时能够依据执行微服务的理论资源需要来确定基础架构费用。在筛选 FaaS 提供商时，开发人员应剖析该提供商是否具备以下条件： 反对函数和容器打包。随着开发人员将越来越多类型的工作负载部署到 FaaS 平台，FaaS 平台应容许开发人员简略地将一个函数打包成 ZIP 或 JAR 文件并加以部署，或者将自定义代码打包成合乎凋谢容器规范 (OCI) 的容器，并部署与之对应的框架。FaaS 平台应同时反对这两种选项，能力在开发部署 Web、内容和事件驱动的工作负载方面为开发人员提供最大的灵活性。提供强壮的平安性能。随着开发人员不断扩大对 FaaS 平台的使用范畴，确保相干人员可能以平安的形式拜访被封装到虚构公有网络，或虚构公有云 (VPC) 中的数据和利用程序接口 (API) 就变得十分重要。另外在函数扩缩容的同时，相干人员还须要可能疾速接入这些资源，而无需期待耗时的“冷启动”。反对第三方生态系统和凋谢规范。除非您违心齐全依赖一家私有云提供商，否则您就应抉择平台集成更为便当的 FaaS 提供商。您须要关注的性能包含第三方可观测性、事件绑定和音讯协定等。2. 评估摘要本次 Forrester Wave™ 评估报告将待评估对象别离纳入“领导者”(Leaders)、“强劲表现者”(Strong Performers)、“竞争者”(Contenders) 和“挑战者”(Challengers) 这几个象限。这是对市场头部厂商的评估，并不代表市场的整体状况。您能够查看咱们对于无服务器架构 (Serverless) 技术的报告，获取无关这个市场的更多信息。咱们心愿这份评估报告只是一个终点，倡议客户应用基于 Excel 的厂商比拟工具来查看产品评估并调整规范权重（请参见图 1 和图 2）。点击 Forrester.com 上网页版报告结尾的链接即可下载上述工具。 ...

作者 | 王恒飞（承荫） 本文整顿自飞猪旅行前端技术专家--王恒飞（承荫）在【阿里云 Serverless Developer Meetup 上海站】上的分享。直播回放：https://developer.aliyun.com/live/246653。过来两年，飞猪前端始终在踊跃地进行 Serverless 建设和实际，2019 年 - 2020 年咱们和团体 Node 架构组、研发平台一起实现了根底能力的建设和业务试点，成为团体率先落地 Serverless 实际的 BU，2020 年 - 2021 年咱们开始大规模地在飞猪推广应用 Serverless 的能力，从导购全链路到外围中后盾，都可能看到 Serverless 的身影，这一年咱们实现了 Serverless 从业务试点到生产力工具的转变，本文将次要分享飞猪基于 Serverless 的实际成绩以及将来想要做的事件。 Serverless 的应用规模2020 年 - 2021 年飞猪 Serverless 的规模和重要度都有很大的变动，次要体现在三方面： 一是函数组规模增长一倍以上，Qps 峰值增长 650%。二是应用 FaaS 开发的人员规模增长 560%，其中前端人员 80% 以上参加到 FaaS 的开发中。三是影响力的体现，目前不仅飞猪前端都对 Serverless 很相熟，客户端也有很多人参加到 FaaS 的开发，更重要的是后端和产品同学也晓得咱们有 Serverless 进行服务开发的能力。具体的数据如下： 为什么要引入 Serverless飞猪为什么这么迫切地要引入 Serverless？这次要是出于前后端研发模式降级以及前端职能扩大的思考，上面回顾一下飞猪前端架构的倒退和研发模式的演进。 1. 飞猪前端架构的倒退飞猪前端架构总结下来就是从最后纯正的前端开发，到解决多端一致性的跨端开发，再到接管视图服务端逻辑的前台开发，Serverless 就是前端降级转变的外围一环。 2. 研发模式的演进历程前端人员为什么肯定要参加服务侧开发？从前后端研发模式的演进来看，次要经验了以下三个大的阶段：第一阶段是资源解耦，这个阶段前端把动态资源分离出来部署到 cdn，解决了和后端服务同机部署的耦合。第二阶段是模板解耦，咱们之前提到的前后端解耦大部分指的就是模板的解耦，一种不彻底的解法就是渲染解耦，服务端放一个空模板内容局部全靠 CSR，彻底的解法就是前端接管模板，能够独立部署模板也能够应用 node.js 代替。第三个阶段就是试图解耦，一方面是因为客户端体系和前端的离线体系的限度，端侧对于视图的动态性要求极高，没有服务侧能力的前端只能将视图的动态性放在服务端做，另一方面因为端侧架构对于数据接口协议的特殊要求，须要服务端来进行协定的转换，也就是服务端常说的 Do 到 Vo 的解决，这就造成了前后端视图的耦合，为了去除这部分耦合，前端通过 Node.js 做 BFF 层来接管视图层的逻辑，Serverless 则是给了前端做 BFF 开发的最佳抉择。 ...

AWS Serverless 服务是一种对利用工程师来说无服务器的计算形式，根底概念是将运行服务所需的基础设施交由 AWS 治理。应用 AWS Serverless 服务的工程师能够专一于面向客户逻辑服务层的开发，而不须要在基础设施的构建、治理、扩容等工作上扩散过多精力。AWS Serverless 开发的外围是名为 Lambda 的计算服务。 明天咱们将围绕 Lambda ，介绍在不同的利用场景下Lambda与各种 AWS 服务的不同组装模式，来初步探讨基于 AWS Serverless 的开发和部署。 What？首先介绍一下什么是 Serverless 开发。 和经典的开发、编译、部署运行形式不同，应用 AWS Serverless 计算服务 Lambda，仅须要上传源文件，抉择执行环境并执行，便能失去运行后果。在这过程中，服务器部署、runtime 装置、编译、都由 AWS Serverless 计算平台治理执行。对开发人员来说，只须要保护源代码和 AWS Serverless 执行环境的相干配置即可。 Why？为什么要抉择 Serverless 呢？ 对开发人员来说，应用 AWS Serverless 服务可能节俭大量治理基础设施架构的精力，并更好地专一于业务逻辑的开发。而对服务而言，AWS 自身的服务性质使得它能很好的反对弹性扩大和高并发场景。此外基于 AWS Serverless 的开发往往领有疾速更新、疾速部署的长处，其按需免费（on-demand）的免费形式，在如轻量部署测试环境、疾速验证等利用场景下对削减开销也有劣势。 How？那么，咱们来看一下如何用 AWS Serverless 的相干服务迅速组装一个简略的 Web Service。 AWS Serverless 提供了丰盛的服务目录，以笼罩各种性能的应用需要。搭建 Web Service 服务除了外围的计算服务 Lambda 之外，经常还须要和申请入口路由（API Gateway）、长久化存储（S3）、CDN（CloudFront）、防火墙（WAF）、域名解析（Route 53）等服务组合应用。如果须要反对 https 协定，还能够应用证书治理服务（ACM）实现。 将上述服务组装好之后，一个残缺的响应申请流程将会是这样的： 用户申请经由域名解析达到 CloudFront，由 WAF 进行频率管制、IP 过滤、header 验证等安全性保障后，通过 API Gateway 路由转发给外围的 Lambda 计算服务。Lambda 会对申请进行解决，解决时如若须要会从长久化存储 S3 中读取或存储数据，并且最终将处理结果通过 API Gateway 返回给用户端。Lambda 在逻辑计算时产生的日志会输入到 CloudWatch 提供的日志治理服务中以便日后查问。此外，还能够进行额定的优化，比方配置 CloudFront 间接从 S3 中加载动态资源，以加重工夫和计算开销。Lambda 的启动形式 ...

简介：体验函数计算相干场景，即可支付流动礼品 阿里云体验实验室 是为开发者打造的一站式体验学习平台，在这里你能够理解并亲自动手体验各类云产品和云计算根底，无需关注资源开明和底层产品，无需任何费用。只有有一颗想要理解云、学习云、体验云的心，这里就是你的上云第一站。 流动阐明： 1.流动期间 体验函数计算相干场景，即可支付礼品。（同一用户的不同账号限领一次）； 2.礼品每日刷新50件，领完即止。每日支付礼品不同，请按需支付； 3.奖品以实物为主，图片仅供参考。奖品数量无限，领完流动即终止，本流动最终解释权归阿里云所有。 礼品刷新阐明 5月18日（周二） 50件1024定制帽子 5月19日（周三） 50件1024定制帽子 5月20日（周四） 50件1024定制卫衣（M） 5月21日（周五） 50件1024定制卫衣（L） 5月24日（周一） 50件1024定制卫衣（XL） 5月25日（周二） 50件1024定制卫衣（2XL） 流动工夫： 2021.5.18-2021.5.25 Step1 登陆 阿里云开发者实验室，进入流动页面 Step2 体验函数计算相干场景 Step3 支付奖品，填写您的收件人信息。（奖品将在流动完结后20个工作日内收回） 开发者实验室地址：https://developer.aliyun.com/adc/labs/ 流动地址：https://developer.aliyun.com/adc/series/activity/serverless FAQ： 为什么我还没有开始体验间接能够支付？ 感谢您对体验实验室场景反对， 体验并实现了场景实际，本次工作会主动实现 奖品什么时候刷新？ 每日上午10时刷新奖品，每次50件。 能够更换奖品吗？ 暂不反对（流动完结后可至钉钉群征询 关注最新动静） 单干社区： 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： 在对于无服务器的第二篇文章中，咱们将探讨一些更宽泛的问题。再次强调，咱们并不是要做硬性规定。咱们想提出一些观点，以促成所有利益相关者之间的探讨。许多说所有应用程序都将是无服务器的应用程序的人并未大规模运行其应用程序，也未解决与提早、复杂性和供应商锁定无关的所有问题。这就是咱们在这里要议论的。 原文 | https://www.pulumi.com/blog/i...作者 | Lee Briggs & Piers Karsenbarg译者 | donghui 在对于无服务器的第二篇文章中，咱们将探讨一些更宽泛的问题。再次强调，咱们并不是要做硬性规定。咱们想提出一些观点，以促成所有利益相关者之间的探讨。许多说所有应用程序都将是无服务器的应用程序的人并未大规模运行其应用程序，也未解决与提早、复杂性和供应商锁定无关的所有问题。这就是咱们在这里要议论的。 供应商锁定怎么办？你有多关怀厂商锁定问题？例如：你很可能无奈将 AWS 中的无服务器架构转移到另一个云提供商。有些组织不关怀厂商锁定问题，但很多组织关怀。如果你真的在乎，那么在你继续前进之前，请决定你应该在乎多少。 您的组织有多大？无服务器对于较年老的组织或较小的组织来说是一个很好的抉择，兴许大型组织中的老手团队间接关注于交付价值。一旦组织倒退到足够大，能够反对专门治理基础设施的团队了，并且使用率增长了，可能就该从新评估状况了。胜利采纳无服务器平台的大型组织往往是经验了文化转变才获得成功。如果您还没有筹备好在组织的所有级别上进行大量投资，以使无服务器的采纳获得成功，那么应用更传统的办法（由专门的团队管制供给基础设施）可能更适合。 最初，正如在前一篇文章中所探讨的，大型企业可能想要思考构建一个基础设施平台，在那里像 Kubernetes 这样的技术能够受害。 架构是什么样的呢？须要思考的一点是无服务器的产品和更"传统"的办法在思维形式上的显著差别，这意味着当切换平台时，应用程序可能常常须要从新设计。您可能须要思考这些体系结构更改的 ROI 是什么。通常，从工夫和财务的角度来看，任何应用程序的从新设计都是低廉的，甚至会给最胜利的工程团队带来问题。 无论您是在开发一个新开发的应用程序还是评估一个现有的应用程序，思考无服务器应用程序的架构都是很重要的。传统的 N 层格调的体系结构或 N 层格调的 web 应用程序须要大量的投资能力迁徙到无服务器的平台。 总结总而言之，无服务器并不能解决所有问题，然而在正确的中央能够提供很多服务。请记住以下问题： 1. 您有多在乎供应商锁定？ 无服务器架构不能简略地从一个云提供商迁徙到另一家云提供商。您的组织在多大程度上关怀供应商锁定？ 2. 您的组织规模是多大？ 无服务器通常更适宜小型组织。一旦有了 IT 员工来反对它，您可能想看看更传统的抉择。大型企业可能心愿钻研 Kubernetes。 3. 您是否比提供应用程序透明性更关怀疾速提供价值？ 如果您心愿尽快将应用程序推向市场，那么无服务器可能是一个不错的抉择。然而，您将就义应用程序的指标和洞察力。随着规模的增长，这可能会导致真正的问题。 4. 您理解应用程序的属性吗？ 通常说无服务器能够省钱，因为您只需为应用工夫付费。然而，如果您的应用程序具备较长的响应或启动工夫，请仔细观察。无服务器可能是一个低廉的抉择。 5. 您的应用程序的体系结构是什么样的？ 不要冀望传统的端层格调的体系结构可能很好地与无服务器的应用程序配合应用。寻找能够分解成更小的组件一起工作的应用程序。另一方面，将无服务器应用程序迁徙到您管制的服务器也须要从新构建应用程序。你有工夫和人去做吗？ 6. 无服务器是绕过 IT 的一种办法吗？ 应用无服务器作为绕过 IT 部门的办法可能不是最好的主见。编写不合规且容易受到攻打的代码太容易了。相同，请应用 DevOps 办法并与所有利益相关者会面以提出解决方案。 7. 安全性如何？ 无服务器架构的安全性存在问题。云提供商提供了一些现成的选项，例如 Amazon GuardDuty，然而它们可能有很多限度，限度了无服务器提供的灵活性。实现平安的无服务器应用程序须要大量的思考。 原文链接本文转载自 Serverless Life 公众号，转载请分割原作者。

简介： 心愿这些博客文章能帮忙您在所有相干人员中展开讨论，就最佳业务计划达成统一。该课程可能波及无服务器，也可能不波及。在这第一篇文章中，咱们将思考在探讨无服务器时最常见的几个问题。在第二篇文章中，咱们将钻研一些更宽泛的问题。 原文 | https://www.pulumi.com/blog/i...作者 | Lee Briggs & Piers Karsenbarg译者 | donghui 许多开发人员说，无服务器是计算的将来，而其余开发人员说，它永远不会胜利。咱们本人的观点没有那么两极分化。咱们将无服务器视为一种抉择，这是从初创企业到中型企业，再到大型企业的一个可能的垫脚石。在这两篇博文中，咱们将探讨无服务器如何适应这一过程，以及它的长处和毛病。 咱们的指标是帮忙您切实地评估无服务器计算。咱们心愿激发探讨，而不是下意识的反馈，无论是赞成还是拥护。心愿这些博客文章能帮忙您在所有相干人员中展开讨论，就最佳业务计划达成统一。该课程可能波及无服务器，也可能不波及。在这第一篇文章中，咱们将思考在探讨无服务器时最常见的几个问题。在第二篇文章中，咱们将钻研一些更宽泛的问题。 什么是无服务器？“无服务器"这个术语有点用词不当。更愤世嫉俗的人可能会嘀咕，“无服务器依然在服务器上运行！“这是真的。不论你应用什么云提供商，你总是应用服务器来运行你的应用程序。必须配置、治理和保护这些服务器。云提供商提供的无服务器服务通常会形象出难以治理的运行应用程序组件：它们为您运行和治理服务器。开发人员能够运行他们的应用程序，而不必放心底层，比方操作系统，甚至计算能力。 为什么采纳无服务器？当人们推广无服务器时，会给出一些现成的答案。咱们将在这里疾速地提到它们，而后咱们将更认真地钻研这些说法。以下是人们给出的三大理由。 1. 这是一个疾速开始的形式将服务器的治理移交给提供商意味着您能够十分快地将应用程序提供给用户。有很多底层基础设施您不用为其编写或保护代码。 2. 它很便宜无服务器能够通过几种形式为您省钱。首先，因为提供者治理服务器，所以能够升高治理老本。您也不须要编写那么多代码，因为服务器不是您关怀的问题。您能够更快地将应用程序推向市场，这意味着您能够更快地开始创收。最初，依据您的应用模式，您只需领取执行代码所用的工夫。你不必为闲暇工夫付钱。 3. 它处于 IT 管制之外在采纳云工程的组织中，人们常常转向无服务器，因为他们感觉 IT 太慢或反应迟钝。在"传统"组织中，可能很难购买硬件，洽购工夫可能太慢，或者可能会因经营或财务而退缩。这通常是人们转向云提供商的一个起因，作为迁徙的一部分，他们可能会思考应用无服务器。 如果在提供云资源的过程中遇到了诸如严格的权限之类的阻碍，那么在曾经采纳云计算的公司中，您还会看到无服务器的采纳。无服务器是一种绕过被视为"拦路虎"的问题来实现工作的简略办法。有时，无服务器的推动可能来自开发部门之外的部门。例如，市场营销部门可能心愿公布一些对工夫至关重要的内容，因为它与某个事件无关。 或者是？让咱们更认真地看看人们提倡无服务器的起因。 1. 这真的是一种疾速开始的形式吗？应用无服务器可能会使您的应用程序更容易推向市场，但这须要重新考虑如何构建和开发应用程序，这会导致当前的劳动惩办。当您开始利用无服务器产品时，您的组织在构建生产应用程序时采纳的传统做法可能须要重新考虑，甚至须要从新调整。这方面的一个很好的例子是在思考监控和可察看性时：许多监控平台工作在一个您无法访问的层上，您无奈深刻理解应用程序的性能。从新设计和从新思考如何应用无服务器技术构建生产就绪的应用程序，可能会给无服务器的旅程带来意想不到的提早。 2. 真的便宜吗？无服务器被认为具备老本效益的起因之一是，您只需为应用的计算工夫付费。然而，应用无服务器可省钱并非必然。分析您的应用程序是否适合十分重要。这里有两个注意事项。 申请的模式是什么？如果您的应用程序有许多小的疾速申请，那么无服务器可能是一个不错的抉择。另一方面，如果您的应用程序依赖长时间运行的操作，那么您在查看账单时可能会感到震惊。 那启动工夫呢？请记住，您依然须要为应用程序的启动工夫"付费”。无服务器服务通常会受到"冷启动"的惩办，因而，如果您很少应用或基本没有应用，则可能必须在后盾运行其余过程以确保您的应用程序不会为此付出代价。这也意味着您的第一个申请将比随后的申请破费更长的工夫。如果无服务器性能须要始终疾速响应，则能够为诸如预置并发之类的实现领取额定费用，以改善冷启动的损失。然而，与传统的软件部署办法相比，这能够轻松对消您可能节俭的任何老本。 3. 管制又如何呢？采纳无服务器平台作为部署机制意味着将为基础设施打补丁的责任移交给提供者。您不再可能对操作系统层的平安正告做出快速反应；你信赖你的供应商来做这些。在这种状况下，你可能不想放弃控制权。 您依然须要管理应用程序依赖项中的平安告诉，并且须要一种机制来对这些问题作出反应。因为不足须要治理的基础设施，无服务器的采集者常常会产生谬误的印象，认为他们的应用程序是"平安的”，但这种状况很少产生。您可能须要为应用程序的浸透测试而采纳的任何现有机制进行调整，并适宜于任何新的无服务器平台。尽管您的攻击面可能较小，但依然须要确保任何潜在的攻击者都很难通过无服务器基础设施程度地进行攻打。 如果您抉择无服务器是因为您或其余部门心愿绕过规范 IT 过程，那么这将指向组织外部的问题，而不是对无服务器的需要。技术不能解决文化问题。真正能解决这些问题的是人们互相交换，找出如何让每个相干的人生存得更好。 您必须明确，您正在将服务器的控制权移交给提供者，而不是本人管制，须要具体钻研合规性和无服务器劣势之间的衡量。 原文链接本文转载自 Serverless Life 公众号，转载请分割原作者。

就这几天，共事给我转了一个调查报告说你们 FC 又获奖了我还纳闷什么奖原来是 CNCF 公布了 2020 年度的中国云原生调查报告在报告中的 Serverless 考察局部阿里云函数计算 FC 继 2019 年后再次成为国内最受欢迎的 Serverless 产品 有人想问 ️CNCF 是一个什么机构，权威性如何当初调查报告太多，就怕被带节奏 CNCF全称 Cloud Native Computing Foundation中文意思就是云原生计算基金会基金会听下来很高大上但其实干的事件还是很接地气的依据官网的介绍CNCF 致力于推动云原生技术的遍及那如何去推动呢 例如CNCF会对一些云原生的开源我的项目进行孵化帮忙其成为更加成熟的开源我的项目并会帮忙我的项目推广给更多的企业应用一些大家耳熟能详的云原生我的项目，例如Kubernetes、Prometheus、Envoy 都是孵化自 CNCF这很像一些守业公司的孵化器 为初创企业的倒退提供办公场地、财税等各类反对不同的是，CNCF 不仅是一个孵化器还造成了本人的社区，有本人的社区运行章程社区中有会员 分为白金、金牌、银牌、最终用户、学术和非赢利成员不同级别的会员在治理委员会中的投票权不同阿里云、AWS、苹果、ARM、Google、微软等都是白金会员 还有最终用户社区推动 CNCF 技术的驳回并选举最终用户技术咨询委员会中国民生银行、中国联通、PingCAP、网易、蚂蚁金服等都是采纳 CNCF 所孵化的开源我的项目的典型国内用户 此外，还会举办很多业内有影响力的会议和培训看到这，你会发现CNCF 汇集了云原生畛域最出名的开源我的项目、厂商和客户是有较高权威性的第三方、非营利性、独立机构因而，他所出具的调查报告，也具备较高的参考价值 说了这么多 CNCF咱们来看看这次调查报告中和 Serverless 相干的内容这是 CNCF 在中国进行的第四次云原生考察共计 439 人参加了考察没有最好的技术，只有最适宜的技术因而，参加调研的企业散布决定了调研后果的参考价值度从 439 人的散布看企业规模/行业属性/职业散布如下 ↑ ↑ ↑ 企业规模散布 ↑ ↑ ↑ 行业散布  ↑ ↑ ↑ 职位散布  整体上，调研样本是比拟平衡的规模 100 人以上的企业为主软件类和技术类企业居多其中，有 49% 还是 CNCF 的社区成员企业这些特色和咱们身边正在实际云原生的企业也较为匹配 ...

简介： 高德为什么要搞 Serverless/Faas？是如何做 Serverless/Faas 的？技术计划是什么样的？目前停顿怎么样？后续又有哪些打算？本文将和大家做一个简略的分享。 作者 | 邓学祥（祥翼）起源 | Serverless 公众号 高德从 FY21 财年开始启动 Serverless 建设，至今一年了，高德 Serverless 业务的峰值超过十万 qps 量级，平台从 0 到 1，qps 从零到十万，成为阿里团体内 Serverless 利用落地规模最大的 BU，这两头的过程是怎么样的？遇到过哪些问题？高德为什么要搞 Serverless/Faas？是如何做 Serverless/Faas 的？技术计划是什么样的？目前停顿怎么样？后续又有哪些打算？本文将和大家做一个简略的分享。 1. Why-高德为什么要搞 Serverless高德为什么要搞 Serverless？背景起因是高德 FY21 财年启动了一个客户端上云我的项目。客户端上云我的项目的次要目标是为了晋升客户端的开发迭代效率。 以前客户端业务逻辑都在端上，产品需要的变更须要走客户端发版能力公布，而客户端发版须要走各种测试流程、灰度流程，解决客户端解体等问题，目前的节奏是一个月一个版本。 客户端上云之后，某些易变的业务逻辑放到云上来。新的产品需要在云端来开发，不必走月度的版本公布，放慢了需要的开发迭代效率，离产研同频的现实指标又近了一步（为什么要说“又”，是因为高德之前也做了一些优化往产研同频的方向致力，然而咱们心愿云端一体化开发能够是其中最无效的一个技术助力）。 1.1 指标：客户端开发模式--端云一体尽管开发模式从以前的端开发转变为当初的云 + 端开发，开发同学应该还是原来负责相应业务的同学，然而大家晓得，服务端开发和客户端开发显然是有差别的，客户端开发是面向单机模式的开发，服务端开发通常是集群模式，须要思考分布式系统的协调、负载平衡、故障转移降级等各种简单问题。如果应用传统的服务端模式来开发，这个过渡危险就会比拟大。 Faas 很好地解决了这一问题。咱们联合高德客户端现有的 xbus 框架（一套客户端上的本地服务注册、调用的框架），扩大了 xbus-cloud 组件，使得云上的开发就像端上开发一样，指标是一套代码、两地运行，一套业务代码既能在客户端上运行，也能在服务端上运行。 高德客户端次要有三个端：IOS、android、车机（类 Linux 操作系统）。次要有两种语言：C++ 和 Node.js。传统地图功能：如地图显示、导航门路显示、导航播报等等，因为须要跨三个端，采纳的 C++ 语言来开发。地图导航根底之上的一些地图利用性能，如行前/行后卡片、举荐目的地等，次要用 Node.js 来开发。 FY20 财年淘系前端团队开发了 Node.js Faas runtime。高德客户端上云我的项目，Node.js 的局部就采纳了现有的淘系的 Node.js runtime，来接入团体的 Faas 平台，实现 Node.js 这部分的一些业务上云。2020 年十一期间很好地撑持了高德的十一出行节业务。 ...

简介： 2019 年 双11 过后，世纪联华疾速上云，将线上外围业务革新为全 Serverless 架构的中台模式，采纳“函数计算+API 网关+OTS”作为计算网络存储外围，弹性撑持日常和大促峰谷所需资源，轻松撑持 618 / 双11 / 双12 大促。 作者 | 朱鹏（旻苍）起源 | Serverless 公众号 一、世纪联华超市简介公司简介 杭州联华华商团体有限公司成立于 2002 年 7 月，次要业务涵盖购物中心、大卖场、超市、便利店等零售业态，G20 杭州峰会食材总仓建设、保障单位，是浙江省商贸龙头企业。 团体 200 多家门店中，次要波及 POS 机交易、联华超市、CITY LIFE、天华世纪城等，除此之外还有线上精选 APP，提供线上购买、送货到家服务，还会不定时推出优惠券支付、限时秒杀等流动。 世纪联华技术架构演进计划 2002 年，公司成立后始终应用物理单机架构。2014 年，因为双十二事件，导致公司不得不做出扭转，将业务迁徙到地方机房。2018 年，随着国内公共云的倒退，开始部署全面上云。2019 年 6 月，公共云上呈现数据库压力过大，世纪联华由此开始摸索新架构形式。到 2019 年 11 月，仅用大略 4 个月工夫，世纪联华就把一部分业务搬到了阿里云的 Serverless 上，包含 API 网关、函数计算、表格存储，在 双11 期间，这三款产品的利用体现十分优异，使得世纪联华决定 All in Serverless。截至 2020 年 11 月，All in Serverless 使得整个公司的开发效率失去极大进步，老本大幅节俭。二、技术架构演进物理单机架构 2014 年及以前物理单机架构下，一个超市通常只有 2~20 台 POS 机，最多 20 个客户端，架构十分简洁，只有在一台物理机上部署好本地数据库，交易系统、会员零碎、商品治理全都放在一个过程上就足够。如果要做相干操作，比方调取某个交易、给用户注册相干信息、调整商品价格，只有通过 Admin 客户端连贯过程再做相应改变即可。通常来说，一个大型超市只有买一台性能足够强的机器，就能够服务好几十个 POS 机发动的申请。 ...

简介： 函数计算可观测性经历了 1.0 -> 2.0 的倒退，从闭门造车的可观测倒退成开源的可观测，从平台的可观测倒退为开发者的可观测，从FaaS Only 的可观测演进成了云原生的可观测。 作者：夏莞 背景Serverless 将成为下一个十年云的默认编程范式随着 Serverless 概念的进一步遍及，开发者逐步从张望状态进入尝试阶段，越来越多的企业用户开始将业务迁徙到 Serverless 平台。在阿里团体外部，淘宝、飞猪、闲鱼、高德、语雀等外围性能稳步落地，在阿里团体内部，新浪微博、世纪联华、石墨文档、TPLink、蓝墨云班课等各行各业的企业也纷纷解锁 Serverless 应用的不同场景。Serverless 正在成为成为下一个十年云的默认编程范式。 更多案例请参考 函数计算用户案例 Serverless 降本增效免运维的个性为开发者带来了实打实的益处：基于函数计算的 Serverless 计划为蓝墨节俭了 60% 左右的 IT 老本，为石墨文档节约了 58% 的服务器老本；晋升码隆科技的开发效率，实现两周内性能上线；安稳撑持负载的波峰波谷相差 5 倍以上的新浪微博，每天轻松解决数十亿申请。 广告工夫：欢送退出云原生Serverless 团队（函数计算，Serverless工作流，Serverless利用引擎），以公共云、团体、开源社区三位一体的形式打造业界当先的Serverless 产品体系。职位需要见 JD，招聘长期有效，有趣味的同学能够分割本文作者或 @Chang, Shuai(shuai.chang)。 可观测性成为 Serverless 倒退的绊脚石？随着 Serverless 的深刻应用，开发者逐步发现 Serverless 架构下的问题定位比传统利用更加艰难，次要起因如下： 组件散布化：Serverless 架构的利用往往粘合多个云服务，申请须要流经多款云产品，一旦端到端延时变长或体现不合乎预期，问题定位十分复杂，须要顺次去各个产品侧逐渐排查。调度黑盒化：Serverless 平台承当着申请调度、资源分配的责任，实时弹性扩容会带来不可避免的冷启动，Serverless 的资源伸缩是无需开发者参加也不受开发者管制的。冷启动会影响端对端延时，这次申请有没有遇到冷启动，冷启动的工夫都耗费在哪些步骤，有没有可优化的空间都是开发者急于晓得的问题。执行环境黑盒化：开发者习惯于在本人的机器上执行本人的代码，出了问题登录机器查看异样现场，查看执行环境的 CPU/内存/IO 状况。面对 Serverless 利用，机器不是本人的，登也登不上，看也看不了，开发者眼前一片乌黑。产品非标化：在 Serverless 场景下，开发者无法控制执行环境，无奈装置探针，无奈应用开源的三方监控平台，考察问题的形式不得不产生扭转，传统的考察问题教训无奈施展，十分不棘手。函数计算是阿里云的 Serverless 产品，在过来的一年，函数计算团队为了更好地答复以上问题做了很多致力。 本文次要介绍函数计算在可观测性上的尝试与函数计算可观测性现状。 Serverless 下可观测性可观测性是通过内部体现判断零碎外部状态的掂量形式。 --维基百科 在利用开发中，可观测性帮忙咱们判断零碎外部的健康状况。在零碎安稳运行时，帮忙咱们评估危险，预测可能呈现的问题。当零碎呈现问题时，帮忙咱们疾速定位问题，及时止损。 一个好的可观测性零碎要帮忙用户尽可能快地发现问题、定位问题并且端到端地解决问题。 在 Serverless 这种免运维的平台体系中，可观测性是开发者的眼睛，没有可观测，何谈高可用？ 可观测性 1.0 图1：可观测性根底 ...

对于 Apache Pulsar Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/Pulsar Functions 是开源数据技术框架 Apache Pulsar 为轻量级计算提供的内置流处理器。在 2020 年 Pulsar Summit 会议上，我发表了一次对于 Pulsar Functions 的演讲。本文将深刻探讨 Functions 的架构和实现细节。 Pulsar Functions 简介Pulsar Functions 是 Pulsar 音讯零碎的外围计算根底构造。应用 Pulsar Functions，无需部署独自的零碎（如 Apache Storm、Apache Heron），即可基于单条音讯创立简单的解决逻辑，简化事件流并引入无服务架构。 轻量级计算 function 从一个或多个 Pulsar topic 生产音讯，将用户提供的解决逻辑利用于每条音讯，并公布计算结果到其余 topic。因为不须要内部解决零碎，Pulsar Functions 不仅使利用程序开发更便捷，还简化了故障排除操作，加重了运维累赘。 另外，开发人员能够间接应用 Pulsar Functions 的 API。理解 Java 语言的程序员能够间接应用 Java SDK 编写 function。示例如下： import java.util.function.Function; public class ExclamationFunction implements Function<String, String> @Override public String apply(String input) { return input + "!"; }}Pulsar Functions 旨在借助简略的 API 和执行框架解决常见的流应用场景（如过滤、路由、裁减），而不是替换重量级流解决引擎（如 Spark、Flink）。 ...

我在2019年的文章中（别找了，被我删了）已经介绍过，国内的 Serverless 产品能够分为两个大类： 大公司产品：包含腾讯云云开发、字节跳动微服务、阿里云的云开发产品、Google 的 Firebase小公司产品：比方 LeanCloud、Bmob 等等而前者的最佳倒退路线我也已经提到过，大公司的 Serverless 想要博得工夫的最佳计划，是通过外部资源的整合，将开发者彻底绑架在本人的平台战车之上。 而这样的计划，当初曾经在各家的计划中有所体现，比方腾讯云云开发和微信单干推出的「小程序·云开发」产品中的「云调用」能力、轻服务推出的免鉴权调用小程序 API 的能力。 在微信小程序中，你能够通过 cloud.openapi.templateMessage.send 来实现免鉴权调用公众号的模板音讯 API ，将过来数百行的代码简化为一行代码实现，能够无效的晋升开发者的开发效率。 现在，轻服务提供了相似的性能，你能够通过 inspirecloud.openapi.tt.sendTemplateMessage实现免鉴权调用推送模板音讯。 我始终感觉，Serverless 这样的产品，是为小团队、创意者而生的。而这些人的特点是，对于技术的深度可能不那么在意，毕竟他们关注的是我要实现一个创意，解决一个问题，至于 Scale 的问题，是在后续才须要留神的。而对于大公司的产品来说，想要干掉小公司的产品，一个利器就是免鉴权调用平台 API。 免鉴权调用平台 API 对于开发者而言是一杯毒酒，不喝，你可能会被竞争对手超过，最终失去用户而死；喝了，你就会因为 Serverless 这样的产品模式，最终被绑死在战车之上。随之而来的，便是随同着产品用户规模的一直晋升的，是这些 Serverless 基础设施的老本就会逐步超过你应用传统的服务器模式的老本。 但回过头来说，你真的能回绝这样的平台劣势么? 很难，即便作为我这样的前后端一把梭的开发者，也很难抵御 Serverless 产品后期的低成本和疾速迭代，对于大量无奈独立实现大型后端开发的工程师来说，这是一个必须喝下去的毒酒。 心愿你在抉择技术计划的同时，不给本人挖坑。

作者 | Mike Butusov起源 | Serverless 公众号 在过来的 5 年里，应用云厂商解决利用后盾的风行水平大幅飙升。其一，初创企业主采纳 Serverless 形式，以节俭基础设施老本，并随用随付。随着公司规模的扩充，依附第三方供应商能够使其疾速取得后端资源。 其二，尽管实现基于云的基础设施次要在初创企业主中风行，但大型公司也会应用分布式架构。Amazon Polly （一种将文本转换为真切语音的服务）就齐全依附 AWS 来提供我的项目反对。 在本文中，咱们次要聊聊 Serverless 对于初创公司最突出的劣势。你将会发现，为你的下一个项目选择分布式应用是十分正确的。 守业公司应用 Serverless 的益处Serverless 容许企业主只在用户申请或事件被触发时才为服务器付费。因而，技术团队打消了闲置工夫，确保他们不会为服务器电源领取额定费用。除此之外，通过 Serverless 化，初创企业的管理者能够雇佣更少的人才进行我的项目保护，从而能够专一于推广公司的外围服务。 老本和工夫效率并不是初创公司在 Serverless 中的惟一益处。让咱们认真看看分布式架构的劣势。 1. 简略部署和继续交付与基于服务器的架构不同，基于分布式系统的后盾更容易设置和部署。将源码连贯到你抉择的任何一个平安的 Serverless 守业公司供应商平台（AWS、Google、Azure 等），就能够部署我的项目了。 继续交付是初创企业应用 Serverless 产生的另一个益处。代码的每一个变动都会在测试后主动部署。整个过程都是自动化的，团队无需对每一次更新进行监控。 2. 节约基础设施老本如上所述，Serverless 架构是企业主管制基础架构方面收入的无效形式。如果一个初创网站的访问量少于 1000 人，改用现收现付的模式，能够削减高达 90% 的后盾保护和资源老本。要理解 Serverless 的全副老本效益，无妨看看这些 Serverless 企业守业案例： 一家名为 Heavywater 的初创公司在抉择应用 Serverless 架构后，保护后盾老本从 4000 美元降至 30 美元；Nordstrom 的创始人利用 Serverless 基础架构的高扩大后劲和降低成本的能力，来反对一个高流量的网络应用。该公司应用 AWS Lambda 和 APIs Gateway 作为我的项目的技术骨干；Postlight 的初创公司创始人通过转向 Serverless 来解决高额的后端收入，将基础设施老本从每月 1 万美元降至 370 美元。3. 有限扩展性在服务器上的利用有扩展性的限度。这意味着越来越多的用户须要重建和翻新利用的技术架构。这也是为什么那些优先思考流量或用户获取的初创公司，更偏向于应用 Serverless 的起因，因为它具备有限的扩大能力。 ...

作者 | 江昱起源 | Serverless 公众号 前言Serverless 概念自被提出就倍受关注，尤其是近些年来 Serverless 焕发出了前所未有的生机，各畛域的工程师都在试图将 Serverless 架构与本身工作相结合，以获取到 Serverless 架构所带来的“技术红利”。 验证码(CAPTCHA)是“Completely Automated Public Turing test to tell Computers and Humans Apart”（全自动辨别计算机和人类的图灵测试）的缩写，是一种辨别用户是计算机还是人的公共全自动程序。能够避免歹意破解明码、刷票、论坛灌水，无效避免某个黑客对某一个特定注册用户用特定程序暴力破解形式进行一直地登陆尝试。实际上验证码是当初很多网站通行的形式，咱们利用比拟繁难的形式实现了这个性能。CAPTCHA 的问题由计算机生成并评判，然而这个问题只有人类能力解答，计算机是无奈解答的，所以答复出问题的用户就能够被认为是人类。说白了，验证码就是用来验证的码，验证是人拜访的还是机器拜访的“码”。 那么人工智能畛域中的验证码辨认与 Serverless 架构会碰撞出哪些火花呢？本文将通过 Serverless 架构和卷积神经网络（CNN）算法，实现验证码辨认性能。 浅谈验证码验证码的倒退，能够说是十分迅速的，从开始的单纯数字验证码，到起初的数字+字母验证码，再到起初的数字+字母+中文的验证码以及图形图像验证码，单纯的验证码素材曾经越来越多了。从验证码的状态来看，也是各不相同，输出、点击、拖拽以及短信验证码、语音验证码…… Bilibili 的登录验证码就包含了多种模式，例如滑动滑块进行验证： 例如，通过顺次点击文字进行验证： 而百度贴吧、知乎、以及 Google 等相干网站的验证码又各不相同，例如抉择正着写的文字、抉择包含指定物体的图片以及按程序点击图片中的字符等。 验证码的辨认可能会依据验证码的类型而不太统一，当然最简略的验证码可能就是最原始的文字验证码了： 即使是文字验证码，也是存在很多差别的，例如简略的数字验证码、简略的数字+字母验证码、文字验证码、验证码中包含计算、简略验证码中减少一些烦扰成为简单验证码等。 验证码辨认1. 简略验证码辨认验证码辨认是一个古老的钻研畛域，简略说就是把图片上的文字转化为文本的过程。最近几年，随着大数据的倒退，宽广爬虫工程师在反抗反爬策略时，对验证码的辨认要求也越来越高。在简略验证码的时代，验证码的辨认次要是针对文本验证码，通过图像的切割，对验证码每一部分进行裁剪，而后再对每个裁剪单元进行类似度比照，取得最可能的后果，最初进行拼接，例如将验证码： 进行二值化等操作： 实现之后再进行切割： 切割实现再进行辨认，最初进行拼接，这样的做法是，针对每个字符进行辨认，相对来说是比拟容易的。 然而随着工夫的倒退，在这种简略验证码逐步无奈满足判断“是人还是机器”的问题时，验证码进行了一次小降级，即验证码下面减少了一些烦扰线，或者验证码进行了重大的扭曲，减少了强色块烦扰，例如 Dynadot 网站的验证码： 不仅有图像扭曲重叠，还有烦扰线和色块烦扰。这个时候想要辨认验证码，简略的切割辨认就很难取得良好的成果了，这时通过深度学习反而能够取得不错的成果。 2. 基于 CNN 的验证码辨认卷积神经网络（Convolutional Neural Network，简称 CNN），是一种前馈神经网络，人工神经元能够响应四周单元，进行大型图像处理。卷积神经网络包含卷积层和池化层。 如图所示，左图是传统的神经网络，其根本构造是：输出层、隐含层、输入层。右图则是卷积神经网络，其构造由输出层、输入层、卷积层、池化层、全连贯层形成。卷积神经网络其实是神经网络的一种拓展，而事实上从构造上来说，奢侈的 CNN 和奢侈的 NN 没有任何区别（当然，引入了非凡构造的、简单的 CNN 会和 NN 有着比拟大的区别）。绝对于传统神经网络，CNN 在实际效果中让咱们的网络参数数量大大地缩小，这样咱们能够用较少的参数，训练出更加好的模型，典型的事倍功半，而且能够无效地防止过拟合。同样，因为 filter 的参数共享，即便图片进行了肯定的平移操作，咱们照样能够辨认出特色，这叫做 “平移不变性”。因而，模型就更加持重了。 ...

作者 | 江昱起源 | Serverless 公众号 前言Serverless 概念自被提出就倍受关注，尤其是近些年来 Serverless 焕发出了前所未有的生机，各畛域的工程师都在试图将 Serverless 架构与本身工作相结合，以获取到 Serverless 架构所带来的“技术红利”。 验证码(CAPTCHA)是“Completely Automated Public Turing test to tell Computers and Humans Apart”（全自动辨别计算机和人类的图灵测试）的缩写，是一种辨别用户是计算机还是人的公共全自动程序。能够避免歹意破解明码、刷票、论坛灌水，无效避免某个黑客对某一个特定注册用户用特定程序暴力破解形式进行一直地登陆尝试。实际上验证码是当初很多网站通行的形式，咱们利用比拟繁难的形式实现了这个性能。CAPTCHA 的问题由计算机生成并评判，然而这个问题只有人类能力解答，计算机是无奈解答的，所以答复出问题的用户就能够被认为是人类。说白了，验证码就是用来验证的码，验证是人拜访的还是机器拜访的“码”。 那么人工智能畛域中的验证码辨认与 Serverless 架构会碰撞出哪些火花呢？本文将通过 Serverless 架构和卷积神经网络（CNN）算法，实现验证码辨认性能。 浅谈验证码验证码的倒退，能够说是十分迅速的，从开始的单纯数字验证码，到起初的数字+字母验证码，再到起初的数字+字母+中文的验证码以及图形图像验证码，单纯的验证码素材曾经越来越多了。从验证码的状态来看，也是各不相同，输出、点击、拖拽以及短信验证码、语音验证码…… Bilibili 的登录验证码就包含了多种模式，例如滑动滑块进行验证： 例如，通过顺次点击文字进行验证： 而百度贴吧、知乎、以及 Google 等相干网站的验证码又各不相同，例如抉择正着写的文字、抉择包含指定物体的图片以及按程序点击图片中的字符等。 验证码的辨认可能会依据验证码的类型而不太统一，当然最简略的验证码可能就是最原始的文字验证码了： 即使是文字验证码，也是存在很多差别的，例如简略的数字验证码、简略的数字+字母验证码、文字验证码、验证码中包含计算、简略验证码中减少一些烦扰成为简单验证码等。 验证码辨认1. 简略验证码辨认验证码辨认是一个古老的钻研畛域，简略说就是把图片上的文字转化为文本的过程。最近几年，随着大数据的倒退，宽广爬虫工程师在反抗反爬策略时，对验证码的辨认要求也越来越高。在简略验证码的时代，验证码的辨认次要是针对文本验证码，通过图像的切割，对验证码每一部分进行裁剪，而后再对每个裁剪单元进行类似度比照，取得最可能的后果，最初进行拼接，例如将验证码： 进行二值化等操作： 实现之后再进行切割： 切割实现再进行辨认，最初进行拼接，这样的做法是，针对每个字符进行辨认，相对来说是比拟容易的。 然而随着工夫的倒退，在这种简略验证码逐步无奈满足判断“是人还是机器”的问题时，验证码进行了一次小降级，即验证码下面减少了一些烦扰线，或者验证码进行了重大的扭曲，减少了强色块烦扰，例如 Dynadot 网站的验证码： 不仅有图像扭曲重叠，还有烦扰线和色块烦扰。这个时候想要辨认验证码，简略的切割辨认就很难取得良好的成果了，这时通过深度学习反而能够取得不错的成果。 2. 基于 CNN 的验证码辨认卷积神经网络（Convolutional Neural Network，简称 CNN），是一种前馈神经网络，人工神经元能够响应四周单元，进行大型图像处理。卷积神经网络包含卷积层和池化层。 如图所示，左图是传统的神经网络，其根本构造是：输出层、隐含层、输入层。右图则是卷积神经网络，其构造由输出层、输入层、卷积层、池化层、全连贯层形成。卷积神经网络其实是神经网络的一种拓展，而事实上从构造上来说，奢侈的 CNN 和奢侈的 NN 没有任何区别（当然，引入了非凡构造的、简单的 CNN 会和 NN 有着比拟大的区别）。绝对于传统神经网络，CNN 在实际效果中让咱们的网络参数数量大大地缩小，这样咱们能够用较少的参数，训练出更加好的模型，典型的事倍功半，而且能够无效地防止过拟合。同样，因为 filter 的参数共享，即便图片进行了肯定的平移操作，咱们照样能够辨认出特色，这叫做 “平移不变性”。因而，模型就更加持重了。 ...

前言Serverless是近些年来流行起来的架构理念，进入市场化应该是2014年亚马逊公布FaaS Lambda。 一个热词的产生，必然会有一些商家抢注商标的景象，所以，咱们目前搜寻Serverless,搜寻后果第一页会看到名为Serverless的产品。 咱们日常说的Serverless，个别是指架构理念，或基于架构理念产生的产品全类，而非指某个具体的产品。 Serverless是对运维体系的极其形象，这里有一个名次“形象”、两个定语“运维体系的”、“极其”。 Serverless是一个形象，就阐明Serverless不是指具体的某个产品。"运维体系的"，阐明了Serverless的职能边界，是对运维体系流程的优化，当然，也对开发流程产生了一些副作用，但，次要的职能在运维方向。"极其形象"，是表明基于Serverless理念输入的产品，将运维体系的复杂度内化，只预留简略的接口供内部调用。带来的后果就是，能够让零运维教训的人，几分钟就部署一个Web利用上线，稍后我会在==示例==中演示一下。 运维发展史 先看一下整个倒退流程，经验了手动运维、主动运维、DevOps开发运维、智能运维几个阶段。 按社会的精细化分工来说： 手动运维阶段，开发者交付代码，运维团队须要进行服务器协调、运行环境部署、上线、版本控制、日志监控、扩缩容设计、容错容灾高可用设计...等等工作。 如果线上产品呈现问题，须要开发者和运维团队独特查找问题。主动运维阶段，通过编排脚本命令将一些简略的工作进行打包解决，肯定水平上缩小重复性的手工操作。随着微服务、容器技术的倒退，来到了DevOps阶段，DevOps=Development + Operations，开发者开始承当一部分的运维职责，甚至有些公司呈现了跨职能团队：运维、开发团队交融，突破手动运维阶段开发、运维两座孤岛的景象。这个阶段，就Docker工具而言，开发者交付镜像，运维团队不用在操心代码的运行环境问题。智能运维阶段，Serverless只是其中的一个倒退节点。 各大服务厂商将基础设施云化，对外提供接口，实现基础设施即代码，让开发者能够通过利用程序代码拜访、配置基础设施(BaaS：形象粒度大多在机器级别)。计算机算力的晋升，如函数计算[阿里云]、云函数[腾讯云]将计算服务的形象粒度进步到了函数级别，实现实时的弹性伸缩容机制，按毫秒级计量、按需计费(FaaS)。产生背景从整个发展史能够看出，技术的倒退起到了重要的推动作用。历史运维体系的痛点：企业中长尾利用的经营老本问题。 什么是中长尾利用？就是每天大部分工夫没有流量或者有很少流量的利用为了保障这些利用的失常运行，至多要安顿一台服务器跑这些利用。而Serverless借助计算机算力，能够实现实时的弹性扩缩容机制。缩小研发人员的关注点，研发人员无需治理、保护底层的基础设施，无需布局预估容器所须要的计算资源，升高整合和决策的代价，只须要专一利用程序代码的编写，进步研发效力。下个定义广义Serverless = FaaS架构广义的Severless是指基于函数计算将Serverless体系产品整合在一起，构建成一个Serverless利用。广义Serverless = FaaS架构 = Trigger + FaaS + BaaS = FaaS + Baas 狭义Serverless是指具备Serverless个性的云服务。 Serverless能够分为Server和less，其中less不是指无服务器端，或者少服务器端，而是指无感知，也对应了“Serverless是对运维体系的极其形象”这句话。 倒退现状目前大多数互联网公司都还在DevOps时代。 局部一线大厂有本人的Serverless解决方案并对外开放。如阿里云的函数计算、腾讯云的云函数。 目前Serverless架构实现并没有对立的标准，实现和提供服务的厂商强关联，如果在不同厂商之间迁徙，会有很大的工作量和艰难。 函数计算以阿里云平台的函数计算来介绍一下FaaS函数即服务。 咱们先相熟一下平台设计。 能够通过支付宝扫码受权登陆。间接用“产品”菜单下的搜寻性能搜寻“函数计算”。点击“控制台”间接进入。顶部 能够切换代码部署的地区如果在“服务/函数”下找不到本人已有的代码，检查一下地区是否抉择正确。“概览”页面 能够直观的看到使用量、监控的概览，还有一些快捷入口。收费执行次数和免费资源使用量，在测试阶段能够无效的避免用超过，也很难用超过。监控的可视化图形新建函数的快捷入口“服务及函数” 能够创立新服务、新函数，查看已有服务和函数。点击服务列表中的某项，能够在右侧查看、编辑蕴含的函数列表、服务相干的配置信息。点击函数列表中的某项，能够进入函数详情，查看、配置函数的信息。自定义域名 通过自定义域名拜访FC函数，须要配合HTTP触发器应用==HTTP触发器==后续讲函数类型的时候会提到。FaaS上面咱们具体看一下函数计算。 首先，咱们创立一个服务、一个函数。 创立好一个服务当前，默认关上“服务配置”Tab，从该Tab页，咱们能够查看服务以后的配置并进行批改。 切换到“函数列表”Tab页，点击新增函数按钮，这时会发现，函数有两类： 事件函数HTTP函数这里HTTP函数，就是上边所说，有HTTP触发器的函数，能够通过网络申请触发FC函数的执行； 因为上边咱们提到了HTTP触发器，那就先创立一个HTTP函数。 创立胜利后，默认进入函数的“触发器”Tab页，能够看到“事件类型”是http，申请办法是GET、POST，不须要受权拜访。 为了更清晰的看到触发器的配置项，咱们从新创立一个触发器。 而后，切换到“代码执行”Tab页，咱们能够看到示例代码。 HTTP函数示例代码： 构造：exports.handler = (req, resp, context) => {} 函数调用时，执行定义的handler逻辑，参数是req、resp、context；这些参数后续==调试阶段==咱们能够看一下打印标准版的输入hello world组装申请数据字段将body数据提取并输入组装的数据咱们执行一下看看会产生什么？ 打印返回的后果打印函数执行日志打印RequestID 这是惟一存在的ID，每次执行都会扭转。能够通过该ID查问日志。在“执行”按钮处，能够配置一些参数，扭转一下配置看看输入的后果。 POST申请门路Params扭转URL上的过滤参数Body扭转POST的申请输入，GET申请下不会呈现该Tab页而且，在批改的过程中，会发现上方的URL会发生变化。 咱们能够通过Postman去申请该地址，调用FC函数，能够通过“日志查问”查看调用后果。 最初，咱们看一下exports导出的函数，默认函数名为handler，这个名字能批改么？ 答案是必定的。 切换到“概览”Tab页，“批改配置”，批改“函数入口”切换回“代码执行”，执行看一下后果，报错将exports.[fnName]批改成配置项，“保留”，再执行，胜利。看完了HTTP函数，咱们返回去看一下事件函数。 返回到服务列表页面。 “新增函数” ——> “事件函数” ——> “配置部署” 配置页面： ...

TL;DR 「五」更乏味一点 一、概念梳理 前情提要，@midway/faas 是原生 serverless 模式的开发，然而目前还在演变中，集体的应用体验是离成熟还挺远我想要的是 @midway 的语法糖，和原生 serverlessdeployType: egg 从外观上看满足了这个要求二、锁版本 # dep@midwayjs/cli@1.2.32@midwayjs/decorator@2.4.7@midwayjs/web@2.5.4egg@2.29.1egg-scripts@2.13.0egg-view-nunjucks@2.2.0# devDep@midwayjs/egg-ts-helper@1.0.4# 局部不影响本文但确是外围的依赖并没有列出来三、提供接口 规范 egg 利用目录构造，没有特地的，把你的旧代码复制过去就能用src/ app/ controller/ api.ts config/ config.default.ts# app/controller/api.ts@Provide()@Controller('/')export class ApiController { @Inject() ctx: Context; @Inject() dataService: DataService; @Get('/api/fetch-data') async fetchData(@Query('pn') pageNo: number=1, @Query('ps') pageSize: number=10) { const { page, data } = await this.dataService.fetchData(pageNo, pageSize); return { code: 0, message: 'ok', page, data }; }}package.json 要害配置：要指定 framework 为 @midway/web"scripts": { "start": "egg-scripts start --title=bilibili --framework=@midwayjs/web --env=prod", "dev": "cross-env ets && cross-env NODE_ENV=local midway-bin dev --ts"},"egg": { "framework": "@midwayjs/web"},package.json 要害配置：ts 要手动构建，这里把钩子设在了生命周期的公布前阶段"midway-integration": { "lifecycle": { "before:package:cleanup": "npm run build" }},f.yml 要害配置：deployType: eggf.yml 要害配置：能够按前缀将一类申请都指向这个服务functions: myservicename: runtime: nodejs12 handler: index.handler events: - http: path: /api/* environment: FORCE_COLOR: 0四、提供动态资源 ...

在腾讯 2020 Techo Park 开发者大会上，围绕新形势下的技术改革与趋势，腾讯云展现了其在云计算、大数据、人工智能等泛滥畛域的最新技术、最新成绩、以及最佳实际。 面向寰球开发者，腾讯云正式公布了企业云原生路线图，同时还降级和公布了八款产品，推动云原生技术的疾速落地。其中便蕴含了 Serverless FaaS 计算平台云函数 SCF。 腾讯云副总裁王慧星分享主题演讲《新形势下的技术改革与趋势瞻望》，王慧星示意： 「数字化技术正在给各行各业带来微小的改革，但同时也给作为撑持的云计算基础设施提出更高的需要。腾讯云将围绕老本、平安、翻新、工具，以及智能等维度，继续加大基础设施投入规模和自研技术创新力度，通过构建云、边、端一体化产品和服务体系，为千百万开发者一站式提供设计、开发、测试、运维残缺产品矩阵，助力开发者晋升效率，疾速上云。」 Serverless 利用已进入企业级时代在 12 月 20 日的 Techo Park 开发者大会上，腾讯云正式对外公布 Serverless 企业级解决方案。 作为 Serverless 专场论坛出品人，腾讯云 Serverless 总经理兼首席架构师 Yunong Xiao 从 Serverless 生态、Tencent Serverless 企业级解决方案到研发效率的晋升给观众带来了一场精彩的分享。 针对企业客户降本增效和理论业务需要，Tencent Serverless 提供了音视频计划、ETL 数据处理、HTTP 服务等实用落地场景。 音视频解决方案中，Tencent Serverless 具备高配置实例、超长工夫运行实例、Custom Runtime 和多媒体实验室等个性，比照传统主机服务实现音视频转码计划，Serverless 转码效率晋升 30%，费用升高 40%；Enterprise ETL 解决方案中，Tencent Serverless 具备多起源事件触发、多存储服务反对、AWS 工作流、泛滥模板和工具，是更便宜、更高效、更易用的 ETL 解决方案；HTTP 服务，不仅反对支流 Web 框架，同时引入了 Serverless Component，是一种全流程可监控，并且实现了 1ms 计费粒度的企业级解决方案。 势如疾风，Serverless 实际在口头在本次 Techo Park 开发者大会中，AWS Lambda 创始人 Tim Wagner 受腾讯云 Serverless 团队之邀，为中国开发者分享对 Serverless 技术的最新洞见和趋势探讨。 ...

作者 | 许晓斌 阿里云高级技术专家 本文整顿自《Serverless 技术公开课》，关注“Serverless”公众号，回复 入门 ，即可获取 Serverless 系列文章 PPT。 传统单体利用架构十多年前支流的利用架构都是单体利用，部署模式就是一台服务器加一个数据库，在这种架构下，运维人员会小心翼翼地保护这台服务器，以保障服务的可用性。 ▲ 单体架构 单体利用架构面临的问题随着业务的增长，这种最简略的单体利用架构很快就面临两个问题。首先，这里只有一台服务器，如果这台服务器呈现故障，例如硬件损坏，那么整个服务就会不可用；其次，业务质变大之后，一台服务器的资源很快会无奈承载所有流量。 解决这两个问题最间接的办法就是在流量入口加一个负载均衡器，使单体利用同时部署到多台服务器上，这样服务器的单点问题就解决了，与此同时，这个单体利用也具备了程度伸缩的能力。 ▲ 单体架构（程度伸缩） 微服务架构1. 微服务架构演进出通用服务随着业务的进一步增长，更多的研发人员退出到团队中，独特在单体利用上开发个性。因为单体利用内的代码没有明确的物理边界，大家很快就会遇到各种抵触，须要人工协调，以及大量的 conflict merge 操作，研发效率直线降落。 因而大家开始把单体利用拆分成一个个能够独立开发、独立测试、独立部署的微服务利用，服务和服务之间通过 API 通信，如 HTTP、GRPC 或者 DUBBO。基于畛域驱动设计中 Bounded Context 拆分的微服务架构可能大幅晋升中大型团队的研发效率。 2. 微服务架构给运维带来挑战利用从单体架构演进到微服务架构，从物理的角度看，分布式就成了默认选项，这时利用架构师就不得不面对分布式带来的新挑战。在这个过程中，大家都会开始应用一些分布式服务和框架，例如缓存服务 Redis，配置服务 ACM，状态协调服务 ZooKeeper，音讯服务 Kafka，还有通信框架如 GRPC 或者 DUBBO，以及分布式追踪零碎等。 除分布式环境带来的挑战之外，微服务架构给运维也带来新挑战。研发人员原来只须要运维一个利用，当初可能须要运维十个甚至更多的利用，这意味着平安 patch 降级、容量评估、故障诊断等事务的工作量出现成倍增长，这时，利用散发规范、生命周期规范、观测规范、自动化弹性等能力的重要性也更加凸显。 ▲ 微服务架构 云原生1. 基于云产品架构一个架构是否是云原生，就看这个架构是否是长在云上的，这是对“云原生”的简略了解。这个“长在云上”不是简略地说用云的 IaaS 层服务，比方简略的 ECS、OSS 这些根本的计算存储；而是应该了解成有没有应用云上的分布式服务，比方 Redis、Kafka 等，这些才是间接影响到业务架构的服务。微服务架构下，分布式服务是必要的，原来大家都是本人研发这样的服务，或者基于开源版本本人运维这样的服务。而到了云原生时代，业务则能够间接应用云服务。 另外两个不得不提的技术就是 Docker 和 Kubenetes，其中，前者标准化了利用散发的规范，不论是 Spring Boot 写的利用，还是 NodeJS 写的利用，都以镜像的形式散发；而后者在前者的技术上又定义了利用生命周期的规范，一个利用从启动到上线，到健康检查，再到下线，都有了对立的规范。 ...

作者 | 许晓斌 阿里云高级技术专家 本文整顿自《Serverless 技术公开课》，关注“Serverless”公众号，回复 入门 ，即可获取 Serverless 系列文章 PPT。 回顾架构的演进过程，咱们不难发现，研发运维人员正在逐步地把关注点从机器上移走，不再去治理机器。 其实咱们都晓得，尽管说是 Serverless，但 Server（服务器）是不可能真正隐没的，Serverless 里这个 less 更确切地说，应该是开发者不必关怀服务器的意思。这就好比古代编程语言 Java 和 Python，开发不必手工调配和开释内存，但内存仍然在哪里，只不过交给垃圾收集器治理了。称一个能帮忙你治理服务器的平台为 Serverless 平台，就好比称说 Java 和 Python 为 Memoryless 语言一样。 然而，如果咱们把眼光放到明天这个云的时代，那么就不能广义地把 Serverless 仅仅了解为不必关怀服务器。云上的资源除了服务器所蕴含的根底计算、网络、存储资源之外，还包含各种类别的更下层的资源，例如数据库、缓存、音讯等。 Serverless 的愿景2019 年 2 月，UC 伯克利大学发表了一篇题目为《Cloud Programming Simplified: A Berkeley View on Serverless Computing》的论文，论文中也有一个十分清晰形象的比喻，文中这样形容： 在云的上下文中，Serverful 的计算就像应用低级的汇编语言编程，而 Serverless 的计算就像应用 Python 这样的高级语言进行编程。例如 c = a + b 这样简略的表达式，如果用汇编形容，就必须先抉择几个寄存器，把值加载到寄存器，进行数学计算，再存储后果。这就好比明天在云环境下 Serverful 的计算，开发首先须要调配或找到可用的资源，而后加载代码和数据，再执行计算，将计算的后果存储起来，最初还须要治理资源的开释。论文中所谓的 Serverful 计算，是咱们明天支流的应用云的形式，但不应该是将来咱们应用云的形式。我认为 Serverless 的愿景应该是 Write locally, compile to the cloud，即代码只关怀业务逻辑，由工具和云去治理资源。 ...

作者 | 李国强 阿里云资深产品专家 明天来讲，在 Serverless 这个大畛域中，不只有函数计算这一种产品状态和利用类型，而是面向不同的用户群体和应用习惯，都有其各自实用的 Serverless 产品。例如面向函数的函数计算、面向利用的 Serverless 利用引擎、面向容器的 Serverless Kubernetes，用户能够依据本人的应用习惯、应用场景或者利用类型，去抉择应用什么样的 Serverless 产品。上面通过本文给大家介绍一下，阿里云都有哪些可供大家抉择的 Serverless 产品。 Serverless 产品及分层家喻户晓，最早提出 Serverless 的是 AWS，其在 Serverless 畛域的旗舰产品是 function compute。同样阿里云也有函数计算的产品，帮忙用户构建 Serverless 函数。但 Serverless 不仅仅是函数，如下图所示，其实用户会冀望在利用、容器等层面也可能享受到 Serverless 的益处，包含按量付费、极致弹性等，这样也更合乎用户原有的应用习惯。 在上图中，大家可能看到，阿里云针对函数、利用和容器都推出了对应的 Serverless 产品，用户能够针对本人的应用场景抉择不同的产品。 函数计算1. 函数计算介绍 上图展现了函数计算的应用形式。从用户角度，他须要做的只是编码，而后把代码上传到函数计算中。这个时候还不会产生费用，只有到被调用的时候才有费用。调用的形式能够是产品提供的 API/SDK，也能够通过一些事件源，比方阿里云的 OSS 的事件。比方用户往 OSS 里的某一个 bucket 上传了一个文件，心愿这个文件被主动解决；比方上传一个 zip 包，心愿可能主动解压到另外一个 bucket，这都是很典型的函数场景。 另外，函数计算可能提供十分好的弹性能力，最终的费用是依据时长和内存数进行计费的，如果调用量小的话，只会有很少的费用。并且它在语言方面也十分丰盛，罕用的 nodejs、php、python、java 都间接反对。同时提供自定义的运行环境，能够反对任意的可执行的语言。 2. 函数计算典型场景从应用场景来说，次要有三类： Web 利用。能够是各种语言写的，这种能够应用 Serverless 框架新编写的程序，也能够是已有的利用。比方小程序后端、或者公布到 API 市场的 API 后端利用等。对计算能力有很强的弹性诉求的利用。比方 AI 推理、音视频解决、文档转换等。事件驱动型的利用。比方通过其余阿里云产品驱动的场景、Web Hook、定时工作等。函数计算曾经与很多产品进行了买通，比方对象存储、表格存储、定时器、CDN、日志服务、云监控等，能够十分疾速地组装出一些业务逻辑。3. 函数计算外围竞争力函数计算对客户的一个最大的价值，就是可能让用户只关注本人的业务逻辑开发，齐全不须要治理运维，诸如计算资源、网络设置等都不须要关怀。在隔离性上提供 vm 级别的隔离，保障用户在运行时的数据安全、运行时平安等；在可用性方面默认提供 3az 的高可用架构，保障客户默认就是高可用的最佳实际架构；在弹性方面，能够做到毫秒级的弹性效率，满足客户突发的流量冲击；在计费方面也非常灵活，真正依照用户的申请状况进行免费，也反对对 long run 的利用更敌对的预付费模式。 ...

作者 | 西流 阿里云技术专家 前言随着计算机技术和 Internet 的突飞猛进，视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青眼，而在以后，云计算平台厂商的产品线一直成熟欠缺，如果想要搭建视频点播类利用，辞别刀耕火种，间接上云会扫清硬件洽购、 技术等各种阻碍，以阿里云为例： 这是一个十分典型的解决方案，对象存储 OSS 能够反对海量视频存储，采集上传的视频被转码以适配各种终端，CDN 减速终端设备播放视频的速度。此外还有一些内容平安审查需要，比方鉴黄、鉴恐等。 而在视频点播解决方案中，视频转码是最耗费计算力的一个子系统，尽管您能够应用云上专门的转码服务，但在很多状况下，您会抉择本人搭建转码服务。比方： 您曾经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频解决服务，是否在此基础上让它更弹性，更高的可用性？您有并发解决大量视频的需要；您有很多超大的视频须要批量疾速解决完，比方每周五定期产生几百个 4G 以上的 1080P 大视频，然而心愿当天几个小时后全副解决完；您有更高级的自定义解决需要，比方视频转码实现后，须要记录转码详情到数据库，或者在转码实现后，主动将热度很高的视频预热到 CDN 上，从而缓解源站压力；自定义视频解决流程中可能会有多种操作组合，比方转码、加水印和生成视频首页 GIF。后续为视频解决零碎减少新需要，比方调整转码参数，心愿新性能公布上线对在线服务无影响；您的需要只是简略的转码需要，或是一些极其轻量的需要，比方获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长，本人搭建老本更低；各种格局的音频转换或者各种采样率自定义、音频降噪等性能；您的视频源文件寄存在 NAS 或者 ECS 云盘上，自建服务能够间接读取源文件解决，而不须要将它们再迁徙到 OSS 上。如果您的视频解决零碎有上述需要，或者您冀望实现一个弹性、高可用、低成本、免运维、灵便反对任意解决逻辑的视频解决零碎，那么本文则是您期待的最佳实际计划。 Serverless 自定义音视频解决在介绍具体计划之前，先介绍两款产品： 函数计算：阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，您无需治理服务器等基础设施，只需编写代码并上传。函数计算会为您筹备好计算资源，以弹性、牢靠的形式运行您的代码，并提供日志查问、性能监控、报警等性能。函数工作流：函数工作流（Function Flow，以下简称 FnF）是一个用来协调多个分布式工作执行的全托管云服务。您能够用程序，分支，并行等形式来编排分布式工作，FnF 会依照设定好的步骤牢靠地协调工作执行，跟踪每个工作的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。收费开明函数计算，按量付费，函数计算有很大的收费额度。 收费开明函数工作流，按量付费，函数工作流有很大的收费额度。 函数计算牢靠的执行任意逻辑，逻辑能够是利用 FFmpeg 对视频任何解决操作，也能够更新视频 meta 数据到数据库等。 函数工作流对相应的函数进行编排，比方第一步的函数是转码，第二步的函数是转码胜利后，将相应 meta 数据库写入数据库等。 至此，您应该初步了解了函数计算的自定义解决能力 + 函数工作流编排能力简直满足您任何自定义解决的需要，接下来，本文以一个具体的示例展现基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频解决零碎，并与传统计划进行性能、老本和工程效率的比照。 1. Simple 视频解决零碎假如您是对视频进行单纯的解决，架构计划图如下： 如上图所示，用户上传一个视频到 OSS，OSS 触发器主动触发函数执行，函数调用 FFmpeg 进行视频转码，并且将转码后的视频保留回 OSS。 OSS 事件触发器，阿里云对象存储和函数计算无缝集成。您能够为各种类型的事件设置处理函数，当 OSS 零碎捕捉到指定类型的事件后，会主动调用函数解决。例如，您能够设置函数来解决 PutObject 事件，当您调用 OSS PutObject API 上传视频到 OSS 后，相关联的函数会主动触发来解决该视频。Simple 视频解决零碎示例工程地址 ...

作者 | 不瞋 导读：Serverless 是如何产生的？以后有哪些落地场景？Serverless 的将来又将如何？本文分享了阿里云高级技术专家不瞋对于 Serverless 的认识，回顾其倒退历程，并对 Serverless 的发展趋势做出预测。 源起回望整个计算机技术发展史，咱们会发现 “形象、解耦、集成” 的主题贯通其中。产业每一次的形象、解耦、集成，都将翻新推向新的高度，也催生出宏大的市场和新的商业模式。 大型机时代，硬件和软件都是定制化的，应用专有的硬件、操作系统和应用软件。 PC 时代，硬件被形象解耦成 CPU、内存、硬盘、主板、USB 设施等标准化的部件，不同厂商生产的部件能够自由组合，组装成整机。软件被形象解耦为操作系统、库等可复用组件。硬件和软件的形象解耦，发明了新的商业模式，开释了生产力，造就了 PC 时代的凋敝。 云的时代，硬件软件化和软件服务化成为最显著的两个趋势。 硬件软件化的外围在于硬件性能中越来越多的局部由软件来出现，从而在迭代效率、老本等方面取得显著劣势。以软件定义存储（Software Defined Storage，SDS）为例，SDS 是位于物理存储和数据申请之间的一个软件层，容许用户操控数据的存储形式和存储地位。通过硬件与软件解耦，SDS 可运行于行业标准零碎或者 X86 零碎上，意味着用户能够无差别的应用任何规范的商用服务器来满足一直增长的存储需要。硬件与软件解耦也让 SDS 可能横向扩大，打消容量布局，老本治理等方面的复杂性。 云时代的另一趋势是软件服务化。应用软件的性能通过网络以近程调用的模式被海量用户应用。服务成为利用构建的根底，API 被实现为服务提供给开发者，微服务架构取得宽泛的胜利。服务也成为云产品的根本状态。过来 10 年，云曾经证实了它的胜利。用户只须要通过调用 API 就能获取服务器，而无需本人建设数据中心。算力以前所未有简洁的形式提供给用户。 还记得 Google 那篇驰名的 “Datacenter as a computer” 论文吗？如果咱们把云看作是 DT 时代的计算机，那么一个很天然的问题是：随着云的 API（全托管服务）越来越丰盛，什么才是适宜于云的编程模型？咱们该当以何种 “形象、解耦、集成” 的形式构建基于云的利用？ 在答复上述问题之前，让咱们首先将眼光转向 SaaS 畛域。Salesforce 是 SaaS 畛域的明星企业，在平台化能力建设方面的布局为咱们提供了一个绝佳的案例。晚期的 SaaS 产品采纳标准化的交付模式，通过凋谢 API 接口实现被集成的能力。随着 Salesforce 产品越来越丰盛，客户规模日益增长，企业开始面临新的挑战： 如何更快地推出新产品，增强产品间的整合和协同？客户迅速增长，需要多样。如何高效地满足客户的定制化需要，减少客户粘性？如何进步产品被集成的能力，更好的连接上下游资源？当产品能力和 API 残缺度达到肯定水准后，如何让开发者疾速整合 API，围绕 Salesforce 能力便捷地开发利用？如何设计好的商业模式，让客户、企业和开发者共赢？Salesforce 的策略是让整个业务、技术和组织平台化。平台放大了企业的价值，让企业、客户、开发者三方受害。通过一直晋升平台的利用交付能力，对内大幅提高产品的研发效率，增强产品的集成和整合；对外则大幅提高了产品的被集成能力，建设开发者生态。 ...

作者 | 邓青琳（轻零） 阿里云技术专家 导读：本文分为三个局部，首先给大家演示 Serverless Kubernetes 集群的创立和业务利用的部署，其次介绍 Serverless Kubernetes 的罕用性能，最初对利用扩缩容的操作进行探讨。 集群创立及利用部署1. 集群创立在对 Serverless Kubernetes 的根底概念有了充沛理解之后，咱们间接进入容器服务控制台（https://cs.console.aliyun.com/#/authorize）进行集群的创立。 在创立页面，次要有三类属性须要抉择或填写： 集群创立的地区和 Kubernetes 的版本信息；网络属性：能够抉择容器服务主动创立或者指定已有的 VPC 资源；集群能力和服务：能够按需抉择。属性实现后，点击“创立集群”即可，整个创立过程须要 1~2 分钟的工夫。 2. 利用部署集群创立实现后，接下来咱们部署一个无状态的 nginx 利用，次要分成三步： 利用根本信息：名称、POD 数量、标签等；容器配置：镜像、所需资源、容器端口、数据卷等；高级配置：服务、路由、HPA、POD 标签等。 创立实现后，在路由中就能够看到服务对外裸露的拜访形式了。 如上图所示，在本地 host 绑定 ask-demo.com 到路由端点 123.57.252.131 的解析，而后浏览器拜访域名，即可申请到部署的 nginx 利用。 罕用性能介绍咱们个别会通过容器服务控制台和 Kubectl 两种形式，来应用 Serverless Kubernetes 的罕用性能。 1. 容器服务控制台 在容器服务管制台上，咱们能够进行以下性能的白屏化操作： 根本信息：集群 ID 和运行状态、API Server 端点、VPC 和安全性、集群拜访凭证的查看和操作；存储卷：PV、PVC、StorageClass 的查看和操作；命名空间：集群 namespace 的查看和操作；工作负载：Deployment、StatefulSet、Job、CronJob、Pod 的查看和操作；服务：工作负载提供出的 Service 的查看和操作；路由：Ingress 的查看和操作，用来路由 Service；公布：对基于 Helm 或者容器服务分批公布的工作进行查看和操作；配置管理：对 ConfigMap 和 Secret 的查看和操作；运维治理：集群的事件列表和操作审计。2. Kubectl除了通过控制台，咱们还能够基于 Kubectl 来进行集群操作和治理。 ...

作者 | 不瞋 导读：用户需要和云的倒退两条线推动了云原生技术的衰亡、倒退和大规模利用。本文将次要探讨什么是云原生利用，形成云原生利用的因素是什么，什么是 Serverless 计算，以及 Serverless 如何简化技术复杂度，帮忙用户应答疾速变动的需要，实现弹性、高可用的服务，并通过具体的案例和场景进行阐明。 ### 现在，各行各业都在谈数字化转型，尤其是新批发、传媒、交通等行业。数字化的商业状态曾经成为支流，逐步代替了传统的商业状态。在另外一些行业里（如工业制作），尽管企业的商业状态并非以数字化的模式体现，然而在数字孪生理念下，充分利用数据科技进行生产经营优化也正在成为钻研热点和行业共识。 企业进行数字化转型，从生产资料、生产关系、战略规划、增长曲线四个层面来看： 生产资料：数据成为最重要的生产资料，需要/危险随时变动，企业面临微小的不确定性；生产关系：数据为核心，非基于流程和规定的固定生产关系，网络效应令生产关系逾越时空限度，多连贯形式催生新的业务和物种；战略规划：基于数据决策，疾速应答不确定的商业环境；增长曲线：数字化技术带来触达海量用户的能力，可带来突破性的增长。从云服务商的角度来看云的演进趋势，在 Cloud 1.0 时代，基础设施的云化是其主题，采纳云托管模式，云上云下的利用放弃兼容，传统的利用能够间接迁徙到云上，这种形式的外围价值在于资源的弹性和老本的低廉；在基础设施提供了海量算力之后，怎么帮忙用户更好地利用算力，减速企业翻新的速度，就成为云的外围能力。 如果仍在服务器上构建根底利用，那么研发老本就会很高，治理难度也很大，因而有了 Cloud 2.0，也就是云原生时代。在云原生时代，云服务商提供了丰盛的托管服务，助力企业数字化转型和翻新，用户能够像搭积木一样基于各种云服务来构建利用，大大降低了研发老本。 云原生利用因素云原生利用有三个十分要害的因素：微服务架构，利用容器化和 Serverless 化，麻利的软件交付流程。 1. 微服务架构单体架构和微服务架构各有各的特点，其次要特点对比方下图所示。总的来说，单体架构上手快，然而保护难，微服务架构部署较难，然而独立性和敏捷性更好，更适宜云原生利用。 ▲ 单体架构 VS 微服务架构 2. 利用容器化和 Serverless 化容器是以后最风行的代码封装形式，借助 K8s 及其生态的能力，大大降低了整个基础设施的治理难度，而且容器在程序的撑持性方面提供十分杰出的灵活性和可移植性，越来越多的用户开始应用容器来封装整个利用。 Serverless 计算是另外一种状态，做了大量的端到端整合和云服务的集成，大大提高了研发效率，然而对传统利用的兼容性没有容器那么灵便，然而也带来了很大的整洁性，用户只须要专一于业务逻辑的编码，聚焦于业务逻辑的翻新即可。 3. 麻利的利用交付流程麻利的利用交付流程是十分重要的一个因素，次要包含流程自动化，专一于性能开发，疾速发现问题，疾速公布上线。 Serverless 计算1. 阿里云函数计算Serverless 是一个新的概念，然而其外延早就曾经存在。阿里云或者 AWS 的第一个云服务都是对象存储，对象贮存实际上就是一个存储畛域的 Serverless 服务；另外，Serverless 指的是一个产品体系，而不是单个产品。以后业界云服务商推出的新性能或者新产品绝大多数都是 Serverless 状态的。阿里云 Serverless 产品体系包含计算、存储、API、剖析和中间件等，目前云的产品体系正在 Serverless 化。 阿里云 Serverless 计算平台函数计算，有 4 个特点： 和云端无缝集成：通过事件驱动的形式将云端的各种服务与函数计算无缝集成，用户只须要关注函数的开发，事件的触发等均由服务商来实现；实时弹性伸缩：由零碎主动实现函数计算的弹性伸缩，且速度十分快，用户能够将这种能力用在在线利用上；次秒级计量：次秒级的计量形式提供了一种齐全的按需计量形式，资源利用率能达到百分之百；高可用：函数计算平台做了大量工作帮忙用户构建高可用的利用。那么，阿里云函数计算是如何做到以上 4 点呢？阿里云函数计算的产品能力大图如下图所示，首先函数计算产品是建设在阿里巴巴的基础设施服务之上的产品，对在其之上的计算层进行了大量优化。接着在应用层开发了大量能力和工具，基于以上产品能力，为用户提供多种场景下残缺的解决方案，才有了整个优良的函数计算产品。函数计算是阿里云的一个十分根底的云产品，阿里云的许多产品和性能均是建设在函数计算的根底上。目前阿里云函数计算曾经在寰球 19 个区域提供服务。 ▲ 阿里云函数计算产品能力大图 ...

起源|阿里巴巴云原生公众号 2020 年，新冠肺炎疫情催化数字化生存形式渐成常态。在企业踊跃进行数字化转型、全面晋升效率的明天，简直无人否定背负“降本增效”使命诞生的 Serverless 行将成为云时代新的计算范式。 Serverless 将开发者从沉重的手动资源管理和性能优化中解放出来，正在引发云计算生产力的新改革。 然而，Serverless 的落地问题却往往很辣手，例如传统我的项目如何迁徙到 Serverless，同时保障迁徙过程业务连续性，在 Serverless 架构下如何提供欠缺的开发工具、无效的调试诊断工具，如何利用 Serverless 做更好的节约老本等，每一个都是难题。 尤其波及到在支流场景大规模的落地 Serverless ，更是并非易事。正因为这样，业界对于 Serverless 外围场景规模化落地最佳实际的召唤更加迫切。 总交易额 4982 亿元，订单创立峰值 58.3 万笔/秒，2020 年天猫 双11 又一次发明记录。对于阿里云来说，往年的 双11 还有另一个意义：阿里云实现了国内首例 Serverless 在外围业务场景下的大规模落地，扛住了寰球最大规模的流量洪峰，发明了 Serverless 落地利用的里程碑。 Serverless 落地之痛挑战一：冷启动耗时长快弹是 Serverless 人造自带的属性，然而快弹的条件是要有极致的冷启动速度去撑持。在非核心的业务上，毫秒级别的延时，对业务来说简直不受影响。然而，对于外围业务场景，延时超过 500 毫秒曾经会影响到用户体验。 尽管 Serverless 利用轻量化的虚构技术，一直的升高冷启动，甚至某些场景能升高到 200 毫秒以下。但这也只是现实的独立运行场景，在外围业务链路上，用户不仅是运行本人的业务逻辑，还要依赖中间件、数据库、存储等后端服务，这些服务的连贯都要在实例启动的时候进行建连，这无形中加大了冷启动的工夫，进而把冷启动的工夫加长到秒级别。 对于外围在线业务场景来说，秒级别的冷启动是不可承受的。 挑战二：与研发流程割裂Serverless 主打的场景是像写业务函数一样去写业务代码，简略疾速即可上线，让开发者在云上写代码，轻松实现上线。 然而在事实中，外围业务的要求把开发者从云上拉回到事实，面对几个灵魂拷问：如何做测试？如何灰度上线？如何做业务的容灾？如何管制权限？ 当开发者答复完了这些问题，就会变的心灰意冷，原来在外围业务上线中，“函数失常运行”只占了小小的一环，离上线的间隔还有长江那么长。 挑战三：中间件的连通问题外围在线业务不是独立函数孤立运行的，须要连贯存储、中间件、数据中后盾服务，获取数据后再计算，进而输入返回给用户。 传统中间件客户端须要买通和客户的网络、初始化建连等一系列操作，往往会使函数启动速度降落很多。 Serverless 场景下实例生命周期短、数量多，会导致频繁建连、连接数多的问题，因而针对在线外围利用罕用的中间件的客户端进行网络连通优化，同时对调用链路进行监控数据买通，帮忙 SRE （Site Reliability Engineer ）从业者更好的评估函数的上游中间件依赖状况，对于外围利用迁徙上 Serverless 十分重要。 挑战四：可观测性差用户大多数的外围业务利用多采纳微服务架构，看外围业务利用的问题也就会带有微服务的个性，比方用户须要对业务零碎的各种指标进行十分详尽的查看，不仅须要查看业务指标，还须要查看业务所在零碎的资源指标，然而在 Serverless 场景中没有机器资源的概念，那这些指标如何透出？是否只透出申请的错误率和并发度，就能够满足业务方的需要？ 实际上，业务方的需要远不止这些。可观测性做的好坏还是源于业务方是否信赖你的技术平台。做好可观测性是博得用户信赖的重要前提。 挑战五：近程调试难度高当外围业务呈现线上问题时，须要立刻进入考察，而考察的第一因素就是：现场的保留，而后登陆进行调试。而在 Serverless 场景中没有机器层面的概念，所以如果用户想登陆机器，在现有的 Serverless 根底技术之上是很难做到的。当然起因不仅限于此，比方 Vendor-lockin 的放心等。 ...

作者 | 落语 阿里云云原生技术团队 本文整顿自《Serverless 技术公开课》，关注“Serverless”公众号，回复“入门”，即可获取 Serverless 系列文章 PPT。 流量治理从面向实例到面向利用 在 Serverless 场景下，因为弹性能力以及底层计算实例易变的个性，后端利用实例须要频繁高低线，传统的 ECS 场景下的负载平衡治理形式不再实用。 SAE 产品提供给用户面向利用的流量治理形式，不再须要关怀弹性场景以及公布场景的实例高低线，仅仅须要关怀监听的配置以及利用实例的健康检查探针，将面向实例的简单配置工作交给 SAE 产品。 单利用的负载平衡配置 对于单个利用，SAE 产品反对将应用服务通过公网或私网 SLB 实例监听裸露，目前反对仅反对 TCP 协定。思考到传统的 HTTP 类型利用存在 HTTPS 革新的需要，SAE 还反对配置 HTTPS 监听，让 HTTP 服务器无需批改就可能对外提供 HTTPS 服务。 公网 SLB 用于互联网客户端拜访，会同时产生规格费与流量费用；私网 SLB 用于 VPC 内客户端拜访，会产生规格费用。 为了让 SAE 产品可能精确管制实例高低线机会，用户须要在部署时正确地配置探针，防止业务呈现损失。 多利用的路由策略配置 大中型企业在实践中，经常会将业务拆分成不同的利用或者服务，例如将登陆服务、账单服务等关联度较高的局部，独自拆分为利用，独立进行研发以及运维，再对外通过对立的网关服务进行裸露，对用户来说就像应用单体利用一样。 SAE 提供基于 SLB 实例的网关，将流量依照域名以及 HTTP Path 转发到不同的利用的实例上，从性能上对标业界的 Nginx 网关。 公网 SLB 实例实现的网关用于互联网客户端拜访，会同时产生规格费与流量费用；私网 SLB 实例实现的网关用于 VPC 内客户端拜访，会产生规格费用。 自建微服务网关 ...

作者 | 代序 阿里云云原生技术团队 本文整顿自《Serverless 技术公开课》，“Serverless”公众号后盾回复“入门”，即可获取系列文章 PPT。 导读：本次课程介绍在 SAE 场景下，如何借助压测工具与 SAE 弹性能力来应答大促的实际。次要蕴含 3 局部要点：传统大促面临的挑战、SAE 大促计划以及疾速压测验证。传统大促挑战 一次常见的大促流动，技术人员通常会从上面几个方面着手，进行筹备工作： 架构梳理：对参加大促的服务，进行系统性的架构梳理；容量布局：联合架构梳理，确定零碎 SLA 指标，造成容量模型，帮忙业务进行评估；性能测试：外围零碎的单机容量评估，与外围链路全链路压测，能够验证容量模型，发现零碎存在的问题；利用/数据库优化：对发现的零碎问题，譬如热点、死锁或慢 SQL 等，进行优化，确保零碎能够撑持大促；筹备扩容计划：通过容量布局与性能测试，能够确定一套满足流动需要的扩容计划，既保障业务，又降低成本；应急预案筹备：当遇到突发状况如何应答，譬如业务降级，砍掉非核心逻辑，或者限流降级，保障外围链路稳固；大促在线应急保障：专人专项，对问题进行响应，执行应急预案。要实现上述筹备工作，常常会遇到如下痛点： 系统核心全链路，短少全局关系视角。须要花大量工夫，整顿依赖关系。链路上下游问题、定位问题比拟耗时。压测与在线应急保障过程中，汇总链路上下游问题，定位问题比拟耗时，短少疾速定位剖析工具。业务开发迭代快，须要常态化压测反对。大量重复性人力投入，给大家造成很大累赘。预留资源老本高，须要频繁扩缩容。须要产品化反对主动弹性伸缩，升高自建机房等高老本高闲置的固定投入。SAE 大促解决方案 首先，SAE 是一款面向利用的 Serverless PaaS 平台，在传统 PaaS 性能之外，提供了齐备的全链路监控、微服务治理等能力，并借助 Serverless 能力，最大水平进行疾速扩缩容、升高手工运维老本。 SAE 提供的解决方案，将从三方面动手： 指标可视化：借助利用监控 ARMS 提供丰盛的 JVM、全链路 Tracing 、慢 SQL 等性能，便捷地评估水位、定位问题；利用高可用：借助 AHAS 限流降级能力，流量激增时，爱护外围服务，保障可用性不齐全跌 0；性能压测：借助压测工具如 PTS，模仿单机压测或全链路压测，验证容量布局、发现利用问题。疾速压测验证那么如何通过 SAE ，进行一次疾速的大促压测验证呢？上面将进行一次残缺的展现： 第一步：察看利用监控指标，大抵拟定弹性/压测/限流降级 通过观察利用监控，对日常业务的监控指标，有一个大抵的概念。以一个典型的电商类利用为例。 从监控状况看： 该利用为 HTTP 微服务利用；利用依赖大量 HTTP 微服务调用，大量应用 Redis / MySQL 服务，适宜应用单机 + 分布式压测工具，别离进行压测；QPS 指标，相比 CPU、MEM 和 RT 指标，对业务更敏感，更适宜作为弹性策略指标。第二步：抉择适合的压测工具 ...

作者 | 行松 阿里巴巴云原生团队 利用公布、服务降级始终是一个让开发和运维同学既兴奋又放心的事件。 兴奋的是有新性能上线，本人的产品能够对用户提供更多的能力和价值；放心的是上线的过程会不会出现意外状况影响业务的稳定性。的确，在利用公布和服务降级时，线上问题呈现的可能性更高，本文咱们将联合 Serverless 利用引擎（以下简称 SAE）就 Serverless 架构下，探讨如何保障上线过程中服务的优雅下线。 在平时的公布过程中，咱们是否遇到过以下问题： 公布过程中，呈现正在执行的申请被中断？上游服务节点曾经下线，上游仍然持续调用曾经下线的节点导致申请报错，进而导致业务异样？公布过程造成数据不统一，须要对脏数据进行修复。有时候，咱们把发版安顿在凌晨两三点，赶在业务流量比拟小的时候，心惊胆颤、睡眠不足、苦不堪言。那如何解决下面的问题，如何保障利用公布过程稳固、高效，保障业务无损呢？首先，咱们来梳理下造成这些问题的起因。 场景剖析 上图形容了咱们应用微服务架构开发利用的一个常见场景，咱们先看下这个场景的服务调用关系： 服务 B、C 把服务注册到注册核心，服务 A、B 从注册核心发现须要调用的服务；业务流量从负载平衡打到服务 A，在 SLB 上配置服务 A 实例的健康检查，当服务 A 有实例停机的时候，相应的实例从 SLB 摘掉；服务 A 调用服务 B，服务 B 再调用服务 C；图中有两类流量，南北向流量（即通过 SLB 转发到后端服务器的业务流量，如业务流量 -> SLB -> A 的调用门路）和东西向流量（通过注册核心服务中心服务发现来调用的流量，如 A -> B 的调用门路），上面针对这两类流量别离进行剖析。 南北向流量南北向流量存在问题当服务 A 公布的时候，服务 A1 实例停机后，SLB 依据健康检查探测到服务 A1 下线，而后把实例从 SLB 摘掉。实例 A1 依赖 SLB 的健康检查从 SLB 上摘掉，个别须要几秒到十几秒的工夫，在这个过程中，如果 SLB 有继续的流量打入，就会造成一些申请持续路由到实例 A1，导致申请失败； 服务 A 在公布的过程中，如何保障通过 SLB 的流量不报错？咱们接着看下 SAE 是如何做的。 ...

一、背景Serverless 概念从2012年开始提出，真正推出相干云产品是2014年AWS推出Lambda。如果咱们将 Serverless 比作一个婴儿，那么它曾经6岁了。 尽管业界对Serverless尚无统一认可的定义，然而我置信大部分开发者在听到 Serverless时，会联想到Lambda，并且冒出“函数”、“按需（调用次数）免费”、“事件驱动”等关键词。的确当年刚刚诞生的Serverless就像上面可恶的“紫薯人”，紫色充斥神秘感（当年刚推出的时候相对是黑科技），让人印象粗浅。 AWS的微小影响力以及自身携带的一身黑科技，的确让人记住了 Serverless，然而也正因为诞生的时候太印象粗浅，以至于当初提到曾经6岁的 Serverless，很多人的印象还是停留在Serverless=Lambda或者Serverless=FC（Function Compute），这不得不说是某种遗憾。 明天企业都在全面数字化转型，整个技术架构体系都渴望依靠云原生来获取微小技术红利，Serverless从诞生的第一天起就是云原生的，所以咱们有必要再零碎的认识一下Serverless的理念以及这些年诞生的相干产品，置信不论你是前端、后端、架构师、SRE、CTO都会有所播种，并且在将来能更好的施展Serverless的技术价值助力商业胜利。 二、定义业界始终在尝试定义Serverless，比方CNCF给出的定义是：NoOps 和Pay as You Run，还有伯克利说 Serverless=FaaS+BaaS。然而我想说，Serverless 其实无需再去定义，他自身就曾经十分清晰明确：“Server+less”，他是一个理念，核心思想就是你不再须要关注 Server，作为比照的是 IaaS 时代，购买服务器，装置各种工具，再在下面开发本人的业务。 Server不会隐没，而是让个别的开发者不须要再关注 Server，这意味着【智能弹性】、【疾速交付】、【更低成本】，这也是 Serverless 相干产品的典型个性。 所以没必要再去给 Serverless 做什么定义，他自身曾经形容的很清晰。咱们抛开概念，具体看看在各个具体技术畛域的产品，置信你会有更直观的意识。 三、PaaS在 Serverless 时代的新生PaaS 自身的概念挺大，狭义的说它处于IaaS和SaaS之间，咱们先从一个具体的产品说起：GAE（Google App Engine）。2006年AWS推出了IaaS的云计算，Google认为云计算不应该是IaaS这样的底层状态，所以在2008年推出了本人的云计算代表产品GAE（对于这里的倒退原因，能够参考张磊的这篇文章：容器十年 ，一部软件交付编年史）。 初推出的GAE，也像Lambda，让人眼前一亮，然而很快开发者就发现它的限度十分多，用明天的话说就是典型的“我不要你感觉，我要我感觉”，最初的后果就是大家都纷纷回到了IaaS的怀抱。 到起初的PaaS产品比方Cloud Foundry，这类PaaS产品绝对更理论一些，底层IaaS还是云厂商提供，下层提供一套利用治理生态，背地的思维还是不心愿开发者通过IaaS这么底层的形式去应用云计算，而是从PaaS开始，不过它也不是Serverless化的，你还是要思考服务器的保护、更新、扩大和容量布局等等。 SAE（Serverless App Engine）到了当初，随着容器技术的成熟，以及Serverless理念的进一步倒退，PaaS和Serverless理念也开始交融，这样的产品既有PaaS为代表的【疾速交付】，又有Serverless的特点【智能弹性】、【更低成本】，典型的产品代表就是阿里云在2019年推出的产品：SAE（Serverless App Engine）。 首先，它是一个PaaS，再具体一点说，是一个利用PaaS。这意味着大部分开发者应用起来都会十分天然，因为外面的概念你会十分相熟，比方利用公布、重启、灰度、环境变量、配置管理等等。 同时，它也是Serverless化的。这意味着你不用再关怀服务器，不必再申请机器，保护服务器，装一堆工具，而是按需应用，按分钟计费，联合弱小的弹性能力（定时弹性、指标弹性）实现极致老本。 最初，得益于Docker为代表的容器技术的倒退，SAE解决了经典PaaS的突出问题（各种限度和强绑定），依靠于容器镜像，在下面能够跑任意的语言的利用 看到这里，我置信大部分开发者对于 PaaS 和 Serverless 联合的产品曾经有了一个轮廓，在中国云原生用户调研报告中(2020年) ，这种状态的Serverless产品开始被越来越多的开发者采纳。 在这个根底上，还有另外一个话题值得再讨论一下，那就是微服务和 Serverless。 微服务和 Serverless当初业界对于微服务和 Serverless，会有局部这样的认知：认为以后云计算典型代表技术是微服务，下一代的代表技术是 Serverless，这会让你 Serverless 比微服务要先进，甚至会感觉将来有了 Serverless 就没有微服务了，相似上面这张图： ...

在中国信息通信研究院重磅公布的国内首个《云原生用户调查报告》中，阿里云 Serverless 产品凭借在双十一的技术锻炼和丰盛的利用实际，在国内 Serverless 用户规模的占比达到 66%，远超其余云厂商总和，被认为是国内 Serverless 用户的首选。 阿里云函数计算（简称 FC）：用户规模最大、利用最宽泛阿里云是最早提供 Serverless 计算服务的云计算厂商。函数计算（简称 FC）是用户规模最大、利用最宽泛的 Serverless 产品，也是首个反对预留/按量实例混合伸缩和预付费模式的 Serverless 产品。函数计算 FC 撑持超过百万函数，月调用数千亿次，50ms 冷启动，3ms 热复原，百毫秒极致弹性，稳固撑持阿里巴巴 双11 千万级 QPS 峰值。在往年 7 月信通院可信云大会上，阿里云函数计算 FC 以 21 项测试全副满分的问题首批通过可信云函数即服务认证。 阿里云致力于打造当先的 Serverless 开发者生态。函数计算 FC 提供了齐备的后端云服务和开发者工具，如事件总线 EventBridge、Serverless 工作流、开发者框架、命令行工具、Web IDE 等，从开发者体验登程，推出 Serverless-tools 与 Serverless 利用核心，打造更加凋谢、规范、无厂商绑定的 Serverless 社区。此外，函数计算 FC 还反对容器镜像，与容器生态深度交融。 阿里云 SAE：Serverless 畛域的一匹黑马在这次调研中，阿里云 SAE（Serverless App Engine）作为一匹“黑马”，体现非常亮眼。SAE 是面向利用的 Serverless PaaS，零门槛、零革新、零容器根底就能享受 Serverless + K8s + 微服务带来的技术红利，更适宜 PaaS 层用户间接应用。 非 Serverless 计划与 SAE 极致弹性计划的比照： ...

Serverless 从概念提出到利用，曾经走过了 8 个年头，开发者对 Serverless 的应用激情一直低落。为帮忙开发者实现一键体验多云产品，极速部署 Serverless 我的项目，10 月 23 日，阿里巴巴正式发表开源首个 Serverless 开发者平台 Serverless Devs，这也是业内首个反对支流 Serverless 服务/框架的云原生全生命周期治理的平台。 这就是 Serverless DevsServerless Devs 是一个开源凋谢的 Serverless 开发者平台，致力于为开发者提供弱小的工具链体系。通过该平台，开发者能够一键体验多云 Serverless 产品，极速部署 Serverless 我的项目。 Serverless Devs 蕴含 Serverless Devs Tool （Serverless 开发者工具）和 Serverless Devs App Store（Serverless 利用核心）： Serverless Devs Tool 是一款能够让 Serverless 开发者的开发和运维效率翻倍的工具。通过应用该工具，开发者能够更简略、更疾速的进行利用创立、我的项目开发、测试、公布部署等，实现我的项目的全生命周期治理。Serverless Devs App Store 是一个集 Serverless 利用在线搜寻，一键部署以及资源可视化编辑于一体的利用核心产品。利用核心领有海量的生产级我的项目模板，案例模板，开发者能够自由选择，并将我的项目一键部署到指定的云平台上。 Serverless Devs 的开源为国内外开发者提供了 Serverless 工具的新抉择，让开发者以更短的门路体验到多云 Serverless 产品，以更快的速度创立和部署 Serverless 利用，以更简略和更自动化的办法进行项目管理和运维，Serverless 我的项目通过该平台实现全自动化后，可节俭 99.9% 的治理老本。 Serverless 工具链之困Serverless 正在扭转将来软件开发的模式和流程，并被预测将引领云计算的下一个 10 年，但尽管如此，开发者在抉择应用 Serverless 时仍有诸多担心，这其中最受关注的无疑就是工具链体系的匮乏。 ...

前言在大型分布式 IT 架构畛域，微服务是一项必不可少的技术。从实质上来讲，微服务是一种架构格调，将一个大型的零碎拆分为多个领有独立生命周期的利用，利用之间采纳轻量级的通信机制进行通信。这些利用都是围绕具体业务进行构建，能够独立部署、独立迭代，也可能依据业务负载独立进行程度扩大。 微服务思维以及相干的技术为 IT 架构的倒退带来了一系列粗浅的改革： 易于开发和保护：一个利用只会关注一组特定的业务性能，通过服务拆分，能缩小利用之间的耦合度，让开发和保护更加简略。 技术栈不受限制：在微服务架构中，能够联合我的项目业务及团队的特点，正当的抉择技术栈。 放慢零碎演进速度：每一个利用都能够独立的进行版本更新，通过灰度公布等技术手段能确保公布过程中整个零碎稳固运行。 突破性能瓶颈：每个利用都能独立的程度伸缩，使零碎性能能够依据计算资源的减少而失去线性的扩大。 微服务的挑战世上没有收费的午餐，微服务技术让 IT 零碎变得更麻利、更强壮、更高性能的同时，也带来了架构复杂度的晋升。对于开发者而言，要想更好的驾驭微服务架构，须要解决继续集成、服务发现、利用通信、配置管理、流量防护等一系列难题。侥幸的是，针对这些普遍存在的难题，业界涌现了一系列优良的开源技术组件和工具，让开发者能够更轻松的构建微服务利用。像 Spring Cloud 和 Dubbo 这样的技术框架，通过多年的倒退，曾经演变为微服务畛域的通用规范，极大地升高了微服务的门槛，但这些技术框架仍然没有方法解决其中两个最大的挑战，这两个挑战成为摆在开发者背后的两座大山。 挑战一：亟需欠缺的生命周期治理与服务治理计划在一个频繁迭代的零碎中，每个利用会经常性面临新版本公布需要，须要对利用的上线、下线、更新、回滚等流程进行集中性的治理，并配合精密粒度的灰度公布伎俩，缩小版本迭代对业务造成的影响。 在一个简略的微服务架构中，如果某利用处于整个链路的入口地位，它的前端个别会挂上负载平衡组件（上图中的利用 A），以承接来自于最终用户的业务申请。这类利用在进行生命周期治理的时候，复杂度会更高，为了确保利用在新版本公布过程中的均衡稳固，会通过如下的步骤： 在这个流程中，还没有波及到对于流量精密粒度管制的高级灰度计划，但曾经足够体现出其复杂性和操作难度了。如果仅仅依赖于简略的公布脚本进行治理，岂但效率很低，还很容易导致顾此失彼，对系统稳定性造成微小的危险。 挑战二：亟需欠缺的程度扩容与缩容计划** 当某一个利用的性能呈现瓶颈，须要通过减少实例数量来晋升性能的时候，就须要引入新的计算资源。 新的计算资源从何而来呢？ 对于线下 IDC 而言，计算资源是须要事后布局的，扩容并不是一件简略的事件，可能会因为各种条件的制约而导致扩容无奈实现。当然这种困扰在云计算时代不复存在了，为一个利用裁减计算资源是信手拈来的事件，但光有计算资源是不够的，还得在下面部署利用，并将利用包容到微服务体系中。 依据这个流程，如果须要扩容一个利用实例，激进预计也须要 20 分钟以上，其中购买、零碎初始化、利用部署都须要占用大量的工夫。假如零碎流量突增，须要在 2 分钟之内紧急扩容，这个计划就无用武之地了。 一剂良药：容器化技术为了解决这两个难题，开发者们尝试了各种各样的计划，新的理念以及技术框架在过来的这五年层出不穷。在一轮轮的优胜劣汰下，以 Docker 为代表的容器技术，在 Kubernetes 生态的撑持下，在业界成为了支流，是构建云原生（Cloud Native）利用的必备因素。容器化相干技术可能更大程序的开掘云计算的价值，在肯定水平上帮忙开发者解决这两个难题。 在利用生命周期治理以及服务治理方面， Kubernetes 提供了比较完善的实现机制，通过构建 Deployment 资源，配合 proStop 和 postStart 脚本，能比拟不便的实现滚动公布以及利用的优雅高低线。尽管在灰度公布的过程中，仍然没有方法间接对流量进行精密粒度管制（引入 Service Mesh 技术能加强流量控制力，不在本文探讨范畴），但相比简略的公布脚本，曾经有了飞跃性的晋升。 在利用的程度扩容与缩容方面，通过容器化技术能够极大水平的缩小操作系统装置以及零碎级初始化的工夫，但购买虚拟机的操作是无奈防止的，所以在零碎遇到流量增突的时候，仍然没有方法实现疾速程度扩容。咱们能够预留一部分计算资源，放在资源池中，当利用有扩容需要的时候，就向资源池申请资源，当业务负载降落的时候，再把多余的计算资源偿还到资源池中。 这其实并不是一个好主见，每一个计算资源都是须要老本的，资源池尽管可能解决计算资源疾速投入使用的问题，却造成了微小的节约。另外，到底布局多大的资源池，也是一件很伤脑筋的事件，池子越大，造成的节约就越大，但池子太小，又可能满足不了扩容的需要。 资源老本更深层次的剖析可能有的开发者会认为，目前的业务运行十分的稳固，在用户流量上并不存在显著的突增，所以扩容和缩容是一个伪需要，在未来也不会有这样的需要。这可能是对互联网业务的一种误会，因为齐全没有扩容需要的状况是不存在的。 首先，只有一个零碎是为人服务的，就必然存在波峰和波谷。对于一个 7*24 小时运行的零碎，不可能永远放弃同样的用户流量，二八准则对于很多业务零碎仍然实用（ 80% 的用户流量集中在 20% 的时间段）。即使是用户流量绝对均衡的零碎，在凌晨也存在流量的低谷，如果能更进一步的开释闲置计算资源，晋升资源利用率，就能显著的升高资源应用老本。 另外，相比生产环境，开发和测试环境对于扩容和缩容的需要会更加迫切。一套微服务利用由不同的团队进行开发，在现实的状况下，多个团队会共享一套测试环境： ...

一、背景Serverless 概念从2012年开始提出，真正推出相干云产品是2014年AWS推出Lambda。如果咱们将 Serverless 比作一个婴儿，那么它曾经6岁了。 尽管业界对Serverless尚无统一认可的定义，然而我置信大部分开发者在听到 Serverless时，会联想到Lambda，并且冒出“函数”、“按需（调用次数）免费”、“事件驱动”等关键词。的确当年刚刚诞生的Serverless就像上面可恶的“紫薯人”，紫色充斥神秘感（当年刚推出的时候相对是黑科技），让人印象粗浅。 AWS的微小影响力以及自身携带的一身黑科技，的确让人记住了 Serverless，然而也正因为诞生的时候太印象粗浅，以至于当初提到曾经6岁的 Serverless，很多人的印象还是停留在Serverless=Lambda或者Serverless=FC（Function Compute），这不得不说是某种遗憾。 明天企业都在全面数字化转型，整个技术架构体系都渴望依靠云原生来获取微小技术红利，Serverless从诞生的第一天起就是云原生的，所以咱们有必要再零碎的认识一下Serverless的理念以及这些年诞生的相干产品，置信不论你是前端、后端、架构师、SRE、CTO都会有所播种，并且在将来能更好的施展Serverless的技术价值助力商业胜利。 二、定义业界始终在尝试定义Serverless，比方CNCF给出的定义是：NoOps 和Pay as You Run，还有伯克利说 Serverless=FaaS+BaaS。然而我想说，Serverless 其实无需再去定义，他自身就曾经十分清晰明确：“Server+less”，他是一个理念，核心思想就是你不再须要关注 Server，作为比照的是 IaaS 时代，购买服务器，装置各种工具，再在下面开发本人的业务。 Server不会隐没，而是让个别的开发者不须要再关注 Server，这意味着【智能弹性】、【疾速交付】、【更低成本】，这也是 Serverless 相干产品的典型个性。 所以没必要再去给 Serverless 做什么定义，他自身曾经形容的很清晰。咱们抛开概念，具体看看在各个具体技术畛域的产品，置信你会有更直观的意识。 三、PaaS在 Serverless 时代的新生PaaS 自身的概念挺大，狭义的说它处于IaaS和SaaS之间，咱们先从一个具体的产品说起：GAE（Google App Engine）。2006年AWS推出了IaaS的云计算，Google认为云计算不应该是IaaS这样的底层状态，所以在2008年推出了本人的云计算代表产品GAE（对于这里的倒退原因，能够参考张磊的这篇文章：容器十年 ，一部软件交付编年史）。 初推出的GAE，也像Lambda，让人眼前一亮，然而很快开发者就发现它的限度十分多，用明天的话说就是典型的“我不要你感觉，我要我感觉”，最初的后果就是大家都纷纷回到了IaaS的怀抱。 到起初的PaaS产品比方Cloud Foundry，这类PaaS产品绝对更理论一些，底层IaaS还是云厂商提供，下层提供一套利用治理生态，背地的思维还是不心愿开发者通过IaaS这么底层的形式去应用云计算，而是从PaaS开始，不过它也不是Serverless化的，你还是要思考服务器的保护、更新、扩大和容量布局等等。 SAE（Serverless App Engine）到了当初，随着容器技术的成熟，以及Serverless理念的进一步倒退，PaaS和Serverless理念也开始交融，这样的产品既有PaaS为代表的【疾速交付】，又有Serverless的特点【智能弹性】、【更低成本】，典型的产品代表就是阿里云在2019年推出的产品：SAE（Serverless App Engine）。 首先，它是一个PaaS，再具体一点说，是一个利用PaaS。这意味着大部分开发者应用起来都会十分天然，因为外面的概念你会十分相熟，比方利用公布、重启、灰度、环境变量、配置管理等等。 同时，它也是Serverless化的。这意味着你不用再关怀服务器，不必再申请机器，保护服务器，装一堆工具，而是按需应用，按分钟计费，联合弱小的弹性能力（定时弹性、指标弹性）实现极致老本。 最初，得益于Docker为代表的容器技术的倒退，SAE解决了经典PaaS的突出问题（各种限度和强绑定），依靠于容器镜像，在下面能够跑任意的语言的利用 看到这里，我置信大部分开发者对于 PaaS 和 Serverless 联合的产品曾经有了一个轮廓，在中国云原生用户调研报告中(2020年) ，这种状态的Serverless产品开始被越来越多的开发者采纳。 在这个根底上，还有另外一个话题值得再讨论一下，那就是微服务和 Serverless。 微服务和 Serverless当初业界对于微服务和 Serverless，会有局部这样的认知：认为以后云计算典型代表技术是微服务，下一代的代表技术是 Serverless，这会让你 Serverless 比微服务要先进，甚至会感觉将来有了 Serverless 就没有微服务了，相似上面这张图： ...

导语 | Serverless Components 是 Serverless Framework 推出的最新解决⽅案，具备基础设施编排能⼒，开发者通过使⽤ Serverless Components，能够灵便构建、组合和部署 Serverless 应⽤。本文是对腾讯云云函数团队前端负责人蔡卫峰在云+社区沙龙online的分享整顿，介绍Serverless Components在腾讯云的落地和实际，心愿与大家一起交换。点击此链接查看残缺直播回放 一、Serverless Components 实现原理1. Serverless CLI 工具 Serverless是一个重开发和部署的产品利用，服务提供了弹性伸缩、主动运维的能力，开发者次要关怀开发和部署。所以，开发和部署的体验对于serverless业务来说是十分重要的。 Serverless的函数自身只是提供了计算的资源，要想实现一个残缺的利用，必然会波及到云上的其余资源，比方网关、cdn、数据库等。 如果是控制台操作，须要在不同的服务之间跳来跳去，比拟割裂。如果能有一个基于利用的对立的命令行管理工具，对于开发者必然会不便很多 Serverless CLI 是用户受权后，通过命令行工具，调用云API帮忙用户治理云资源，不便对云上资源进行比拟残缺的操作。 2. 什么是 Serverless Framework  Serverless Framework 当初大量的使用者是 web 服务的开发者，次要定位于 web 服务场景，它是北美研发团队开源的一个我的项目，是业界⾮常受欢迎的⽆服务器应⽤框架，开发者⽆需关⼼底层资源即可部署残缺可⽤的 Serverless 应⽤架构。 Serverless Framework 定义了一套残缺的标准化标准，各私有云的插件遵循这套标准，通过对云上资源的编排，笼罩编码、调试、部署、排障等全⽣命周期，帮忙开发者通过联动云资源，迅速构建 Serverless 应⽤。 3. Serverless Framework CLIServerless Framework CLI 是一个开源命令行工具，它应用基于事件触发的计算资源，例如腾讯云云函数，AWS Lambda，阿里云函数计算等。 Serverless Framework 为开发和部署 Serverless 架构提供脚手架，自动化工作流以及最佳实际。并且它反对通过丰盛的插件进行性能扩大。 Serverless Framework 在 Github 有将近 4 万的 Star，在国外比拟受欢迎。咱们团队最开始也保护了一个本人的 CLI，然而保护老本比拟高，想做体验好操作晦涩的 CLI 须要投入大量人力精力，Serverless Framework 的 CLI 开发者接受程度比拟高，它的协定也凋谢，所以依照标准接入即可。 ...

如果你在往年入住酒店的话，可能会发现有一群人比今年出镜率要高，他们十分有急躁的为你指引路线、送餐、送物品，24 小时 stand by 满足你的需要。 你猜对了！他们就是又萌又强的机器服务员。机器服务员「入职」酒店，不仅仅升高了酒店的人工成本、进步工作效率，还因为他们可恶的形象为酒店带来更高的评估。 图片来源于网络 酒店投入使用机器人，是其数智化转型的重要尝试。近年来，数字化、智能化成了各行各业的热门词，传统酒店都面临着经营理念和模式的挑战。但数字化转型并非易事，尤其是国内连锁酒店，他们往往绝对审慎，因为哪怕是一些渺小的改变，也是牵一发而动全身。 现在 80、90 后成为生产主力，他们更加谋求体验和效率，须要酒店提供更便捷的订房服务、更舒服更平安的入住服务，甚至须要更多娱乐化的服务。 大部分传统酒店依赖于 OTA（Online Travel Agency） 平台来进行线上引流和获客，但入驻 OTA 平台不仅佣金高，还面临越来越强烈的市场竞争，酒店的拓客老本高，大大压缩了利润空间。 传统酒店亟需通过互联网、物联网、人工智能等技术来扭转在「治理」和「营销」上的窘境，晋升服务、降本增效。 打造智能化、本土化的酒店小程序，实现服务降级作为一家国内连锁酒店，希尔顿不仅要思考智能化，还须要思考本土化。希尔顿酒店借助微信残缺的生态（微信公众号和小程序）连贯顾客，传递品牌价值，提供一站式服务，则是数智化转型的一大翻新。 希尔顿联合微信生态的翻新模式，次要集中在顾客入住前和入住后两个场景的服务降级。 希尔顿上线的「希尔顿官网入住」小程序，蕴含了北上广深 19 家酒店的详细信息，并通过 「吃喝」、「玩乐」 两大栏目帮忙用户摸索周边美食和景点，线路性能则间接为用户安顿了若干游览线路，贴心且实用。 在线预约开发票的性能更是希尔顿用户思维的间接体现。毕竟在效率至上的时代，为了开发票在前台排队等半小时是高节奏的商旅人士难以忍受的，希尔顿用小程序中一个简略的性能就解决长久以来困扰酒店和客人的问题，顾客只有在小程序中填写好发票低头、入住日期等必要信息，即可在预约工夫内返回酒店前台取票。由此可见，当许多酒店仍停留在一味地晋升硬件、设计等外在条件时，希尔顿曾经先行一步，利用技术手段摸索用户服务的新方向。 小程序内置游戏入口则是希尔顿投合年老群体生存形式和兴趣爱好，实现用户精细化经营的体现。希尔顿依据酒店的经营打算定期上线游戏和会员福利流动，顾客通过小程序即可参加游戏互动，满足了娱乐需要，同时通过本人致力得来的优惠也会更加有价值。而小程序与希尔顿与订票平台、商城、会员零碎买通，在领取过程中可间接调用优惠券，实现业务的无缝连接。 技术赋能酒店服务，一个小程序解决入住全流程希尔顿借助小程序晋升了顾客入住前后的体验，而香格里拉则是借助小程序，为顾客提供便捷和平安的住房和生产体验。 香格里拉推出的「酒店自助入住」小程序，在保障平安的前提下，对接酒店的客房管理系统，对接人脸识别认证零碎，买通客房蓝牙解锁零碎，交融第三方领取，从酒店搜寻到房间预订、从办理入住到退房、从领取费用到开取发票，顾客只需几步手机操作即可实现传统模式下繁琐的住房流程，为顾客提供全自助高效平安的入住流程体验。 香格里拉通过新技术实现人脸平安认证和酒店服务在小程序端的整合，建设了新时代的酒店入住零碎，是其在推动酒店数智化降级的重要冲破。 利用微信生态构建用户流量池，升高获客老本希尔顿借助微信生态搭建服务体系，以公众号为品牌流传入口，以小程序为服务载体，为顾客提供优质的服务，并一直积淀用户流量池，同时充沛利用微博等自媒体平台、OTA 等单干渠道，将粉丝引流到本人的流量池，通过会员零碎、积分零碎、营销工具进行精细化经营，促成顾客复购和新顾客转化。 希尔顿酒店构建本人的微信生态服务产品，不仅仅进步了服务质量，更是在脱离酒店对 OTA 平台的依赖，通过本人的形式来获取新顾客，升高获客老本。 通晓云通过本身成熟的微信生态技术开发和经营教训，为希尔顿等连锁酒店在获客和线上服务方面继续赋能，增强用户经营能力，进步用户转化，使用科技和翻新进行品牌降级、服务降级，从而晋升企业的市场竞争力。 随着酒店服务能力和场景的拓展，优化降级的空间也相应变得更大，既要投合绿色清洁的环保趋势，也要拥抱数字化和人工智能。如何利用翻新和技术为消费者带来更舒服的住宿体验，希尔顿和香格里拉的做法或者能给酒店行业带来一些启发。

作者 | 林昱(苏河)起源|阿里巴巴云原生公众号 技术的成熟度源自大规模的实际，在 Java 畛域，阿里将本身的实际源源不断的反哺给微服务技术体系；在 Node.js 畛域，阿里正掀起了前所未有的前端反动浪潮，将实际反哺给  Serverless 技术体系，并逐步拓展到其余多语言体系和后端 BaaS 上。 Serverless 云研发平台作为阿里巴巴团体前端委员会发动的一体化云研发平台，底层基于函数计算 FC，是整个 Node Serverless 体系中的研发入口，承接了淘宝、飞猪、ICBU、考拉、高德、娱乐等研发、交付和运维工作。目前，团体曾经有上千位前端和客户端的工程师应用 Serverless 云研发平台进行业务的开发工作，包含但不限于营销导购、中后盾、行业前台等规模化场景。 从往年 双11 整体的大盘数据来看， 仅淘系 Node Serverless 的撑持流量就曾经从去年的 2K QPS 峰值减少到往年的 30K QPS 峰值，峰值流量减少了近 15 倍，团体整体更加是从近 5.8K QPS 达到往年的 50K QPS 峰值。 解决方案上，咱们定制了面向更多场景的能力，包含考拉 Dart 解决方案的落地，以及一些面向导购的模型驱动解决方案；运维上，咱们优化了大促态和日常态流程，让开发者在应答更高 QPS 规模时，精力破费升高至多 50%；在研发体验侧，打造解决方案体系，升高研发门槛，反对前端疾速入场，晋升研发效率 39%；在底层 Serverless 基座上，咱们适配了多个 Serverless 平台，反对多平台的实时切换，以应答繁多平台的不确定性。 本文将介绍 Serverless 云研发平台是通过提供哪些能力保障各租户业务的疾速开发和平安交付的。 研发的实质大家可能都在「人员协同、服务可靠性」上领取着高额的人力老本，但研发的实质是交付「业务性能」。 明天，咱们从传统的「前端开发者」缓缓走向「利用研发者」，摸爬滚打不容易，除了须要去思考「什么是真正的按需付费」、「弹性」等底层运维相干的命题之外，还须要去思考「研发效力」相干命题，这也是为什么有更高效的协同模式、组织关系的变动，甚至整个前后端协同的生产关系都在发生变化的起因，明天咱们谈「云端一体」，实质是从用户的视角去思考问题，用更高效的形式去解决业务问题。 现在，软件开发对于老本的管制要求越来越高，单位工夫的产能会缓缓成为掂量一个团队是否高效的规范。 因而从研发的实质，咱们来看看 Serverless 云研发平台要解决的命题： 让业务开发变轻，聚焦业务逻辑；让业务开发变快，晋升产研效率；让基础设施变厚，晋升稳定性。图为 Serverless 云研发平台架构图 ...

起源|阿里巴巴云原生 2012 年，云基础设施服务提供商 Iron.io 的副总裁 Ken 谈到软件开发行业的将来，首次提出了 Serverless 的概念，为云中运行的应用程序形容了一种全新的零碎体系架构。尔后，以 AWS 为代表的云服务厂商将 Serverless 概念逐渐落地，陆续推出了基于 Serverless 的 FaaS（函数即服务）产品。通过几年的倒退，Serverless 架构已被业内认为是引领云原生下一个十年的倒退潮流。 据 Gartner 报告，2020 年寰球已有 20% 的企业采纳 Serverless 技术部署，Serverless 从底层进行技术改革计算资源的状态，为企业的软件架构设计和应用服务部署引入翻新的技术设计思路。  尽管如此，国内的一些企业和开发者在面对 Serverless 时仍然持张望态度。一方面是相干技术在国内起步较晚，局部开发者对新技术的接受度较低；另一方面，国内的 Serverless 生态建设较为落后，市面上相干的工具链并不欠缺，这导致开发和部署难度大、老本高。  近日，阿里云 Serverless 技术团队发表开源 Serverless Devs 平台，为开发者提供了一套 Serverless 工具链体系。据介绍，通过该平台，开发者能够一键体验多云 Serverless 产品，疾速部署 Serverless 我的项目。 为了进一步理解 Serverless Devs 我的项目的个性，以及 Serverless、微服务等云原生技术生态在国内的发展趋势，开源中国邀请到了阿里云 Serverless 研发负责人杨皓然(不瞋)，阿里云 Serverless 产品经理、Serverless Devs 我的项目发起人江昱，与咱们分享了 Serverless 我的项目的细节与国内 Serverless 生态的状况。 以下为采访原文： 1. 请简要介绍一下阿里云 Serverless Devs 我的项目的技术团队成员形成。<江昱>：团队是由阿里云智能云原生中间件前端负责人带队，联结阿里云智能云原生函数计算团队的多名技术专家，以及数名社区爱好者。通过开源思路，进行我的项目建设，耗时 120 天。  Serverless Devs 的技术团队外围研发人员次要包含： ...

起源 | Serverless 公众号 作者 | 弈川 阿里巴巴云原生团队 导读：本节课程蕴含三局部内容，前两个局部简略介绍近程调试以及端云联调的原理，最初在 Serverless 利用引擎中进行理论演示。通过之前课程的学习，置信大家对于 Serverless 利用引擎（SAE）曾经有了肯定的理解，SAE 是一款基于容器与 kuberneters 的利用 PaaS 平台，在 SAE 提供的 Serverless 场景下，咱们不须要再关注底层资源的运维，只须要关注利用的业务逻辑自身。然而，咱们在开发测试阶段通常会须要用到调试性能，因而，为了不便用户调试，咱们提供了近程调试性能，目前只反对 Java 程序的近程调试。 近程调试Java 近程调试原理 家喻户晓，咱们的 Java 程序是运行在 Java 虚拟机（JVM）之上的，JVM 不单单为咱们的 Java 程序提供了跨平台能力，并且也提供了相应接口与协定不便近程调试。JDK 中有一个叫 JPDA 的体系来标准与反对 Java 程序的调试，在这个体系中，调试发起者与被调试程序的 JVM 底层别离由 JDI 与 JVMTI 模块来反对，而两个接口之间则是有 JDWP 来负责相互之间的通信。 由此可见，近程调试的实质就是两个 JVM 通过一个连贯放弃通信，被调试的程序作为服务端，在某个指定的端口监听调试指令，而调试发起者则是作为客户端连贯指标端口，发送各种调试指令并且接管调试状态。 咱们此时曾经理解了 Java 程序近程调试的原理，那么对于部署在 SAE 中的 Java 利用是如何实现近程调试的？ SAE 中的 Java 近程调试 首先，在 SAE 部署的 Java 利用须要先开启调试模式，因而须要在部署利用时增加相干的启动命令。另外，因为 SAE 的利用默认是无奈提供公网拜访的，所以须要一个 SLB 提供公网拜访能力。以上两条都设置好之后，最初能够取得一个调试程序用 IP 与端口，将这个 IP+端口 设置到 IDE 中就可能开始近程调试了。 ...

Valine 是一款款式精美，部署简略的评论零碎， 第一次接触便被它精美的款式，无服务端的个性给吸引了。它最大的特色是基于 LeanCloud 间接在前端进行数据库操作而无需服务端，极大的缩减了部署流程，仅须要在动态页引入 Valine SDK 即可。 ???????? 初识 Valine以下是 Valine 官网提供的疾速部署脚本，其中 appId 和 appKey 是你在 LeanCloud 上创立利用后对应的利用密钥。也正是基于这对密钥，Valine 在外部调用了 LeanCloud SDK 进行数据的获取，最终将数据渲染在 #vcomments 这个 DOM 上。这便是 Valine 的大略原理。 <head> .. <script src='//unpkg.com/valine/dist/Valine.min.js'></script> ...</head><body> ... <div id="vcomments"></div> <script> new Valine({ el: '#vcomments', appId: 'Your appId', appKey: 'Your appKey' }) </script></body>有同学可能会有疑难了，appId 和 appKey 都间接写在前端了，那岂不是谁都能够批改数据了？这就须要牵扯到 LeanCloud 的数据安全问题了，官网专门写了篇文档《数据和平安》 来阐明这个问题。简略的了解就是针对数据设置用户的读写权限，确保正确的人对数据有且仅有正确的权限来保证数据的平安。 乍听一下，保障用户数据只读的话，感觉还是挺平安的。可事实真的如此么，让咱们持续来看看。 ????♂️ Valine 的问题???? 浏览统计篡改Valien 1.2.0 减少了文章浏览统计的性能，用户拜访页面就会在后盾 Counter 表中依据 url 记录拜访次数。因为每次拜访页面都须要更新数据，所以在权限上必须设置成可写，能力进行后续的字段更新。这样就造成了一个问题，实际上该条数据是能够被更新成任意值的。感兴趣的同学能够关上 https://valine.js.org/visitor... 官网页面后进入控制台输出以下代码试试。试完了记得把数改回去哈~ ...

场景介绍场景介绍如何应用函数计算服务开发HelloWorld利用。您能够通过控制台或Funcraft工具实现。 背景常识什么是Serverless 自2006年8月9日，Google首席执行官埃里克·施密特（Eric Schmidt）在搜索引擎大会（SESSanJose2006）首次提出“云计算”（Cloud Computing）的概念之后，云计算的倒退能够用突飞猛进这个词来形容。那么到底什么才是Serverless呢？ 简略来说，Serverless能够说是一种架构，一种云计算倒退的产物，至于具体说什么是Serverless，可能没有谁能给他一个明确的概念，如果非要说一个能够略微容易了解一些的概念，那或者能够参考Martin Fowler在《Serverless Architectures》中对Serverless这样定义：Serverless=BaaS + FaaS 步骤一：连贯ECS服务器阿里云云产品资源体验地址：https://developer.aliyun.com/... 场景将提供一台配置了CentOS 7.7的ECS实例（云服务器）。通过本教程的操作，您能够基于已有的环境开发一个基于函数计算的HelloWorld利用。 步骤二：开明函数计算服务在应用函数计算前，须要开明函数计算服务。 阐明： 本场景中提供的阿里云子账号无函数计算服务操作权限，请应用您本人的阿里云账号操作。您无需放心扣费问题，因为函数计算服务有肯定的收费额度，请参见计费形式。 1.应用您本人的阿里云账号登录阿里云控制台，而后进入函数计算产品详情页。 2.单击【收费开明】。 浏览《函数计算服务协定》勾选批准服务协定，最初单击 【立刻开明】 。4.单击【治理控制台】进入函数计算控制台。 步骤三：在控制台开发函数计算HelloWorld利用1.在函数计算控制台首页，单击【新建函数】。2.抉择【HTTP函数】，而后单击【下一步】。 3.参考以下阐明填写函数和触发器配置，而后单击【实现】。 所在服务：例如hello_world_service。绑定日志：填写所在服务名称后默认勾选绑定日志，日志服务会收取大量费用，您能够抉择勾销勾选。函数名称：例如hello_world。运行环境：抉择nodejs10。触发器名称：例如hello_world_trigger。认证形式：抉择anonymous。申请形式：抉择GET。4.在 代码执行治理 页面，将index.js文件中的内容替换为如下所示： var getRawBody = require('raw-body')module.exports.handler = function (request, response, context) { getRawBody(request, function (err, data) { var respBody = new Buffer.from("你好，世界！"); response.setStatusCode(200) response.setHeader('content-type', 'text/html') response.send(respBody) })};替换后如下所示： 单击编辑器右上角【Save Invoke】保留并运行示例代码。能够看到函数运行胜利，并返回： 你好，世界！ 步骤四：应用Funcraft开发函数计算HelloWorld利用Funcraft 是一个用于反对Serverless利用部署的工具，能帮忙您便捷地治理函数计算、API 网关和日志服务等资源。它通过一个资源配置文件（template.yml），帮助您进行开发、构建和部署操作。本步骤操作将在ECS服务器上应用Funcraft工具开发函数计算HelloWorld利用。1.依照以下步骤创立资源。 a. 在页面左侧，单击 云产品资源 下拉菜单，查看本次试验资源。b. 单击 收费开明 创立所需资源。阐明： 资源创立过程须要1~3分钟。实现试验资源的创立后，您能够在 云产品资源 列表查看已创立的资源信息，例如：IP地址、用户名和明码等。 ...

场景介绍场景介绍如何应用函数计算服务开发一个IP查问工具。 背景常识什么是Serverless 自2006年8月9日，Google首席执行官埃里克·施密特（Eric Schmidt）在搜索引擎大会（SESSanJose2006）首次提出“云计算”（Cloud Computing）的概念之后，云计算的倒退能够用突飞猛进这个词来形容。那么到底什么才是Serverless呢？ 简略来说，Serverless能够说是一种架构，一种云计算倒退的产物，至于具体说什么是Serverless，可能没有谁能给他一个明确的概念，如果非要说一个能够略微容易了解一些的概念，那或者能够参考Martin Fowler在《Serverless Architectures》中对Serverless这样定义：Serverless=BaaS + FaaSServerless架构和传统的我的项目的区别 首先，咱们以一个常见的Web服务为例： 在这个图中，服务器中可能波及路由规定、鉴权逻辑以及其余各类简单的业务代码。同时，开发团队要付出很大的精力在这个服务器的运维下面，例如要时刻关注以下问题： 客户量忽然增多时是否须要扩容服务器。服务器上的脚本和业务代码等是否还在衰弱运行。是否有黑客在一直地对服务器发动攻打。当咱们把这个思路切换到Serverless的逻辑之后，变成了这样：能够认为，当客户端和数据库未发生变化的前提下，服务器变动微小。 之前须要开发团队保护的路由模块以及鉴权模块都将接入服务商提供的API网关零碎以及鉴权零碎，开发团队无须再保护这两局部的业务代码，只须要继续保护相干规定即可。在这个构造下，业务代码也被拆分成了函数粒度，不同函数示意不同的性能。咱们曾经看不到服务器的存在，是因为Serverless的目标是让使用者只关注本人的业务逻辑即可，所以一部分平安问题、资源调度问题（例如用户量暴增、如何实现主动扩容等）全都交给云厂商负责。绝对于传统我的项目而言，传统我的项目无论是否有用户拜访，服务都在运行中，都是有老本收入，而Serverless而言，只有在用去发动申请时，函数才会被激活并且执行，并且会按量免费，相对来说能够在有流量的时候才有反对，没有流量的时候就没有收入，相对来说，老本会进一步升高。通过以上剖析和形容，不难看出Serverless架构绝对于传统的开发模式的区别，也逐步的发现了它的劣势。然而问题来了，很多工作都交给了云厂商来做，那咱们做什么呢？应用Serverless架构后： 开发团队不须要再本人保护服务器，也不须要本人操心服务器的各种性能指标和资源利用率，而是能够让开发团队付出更多的工夫和精力去关注应用程序自身的状态和逻辑。Serverless利用的部署将变得非常容易。咱们只有上传根本的代码，例如Python程序只须要上传其逻辑与依赖包，C/C++、Go等语言只需上传其二进制文件，Java只须要上传其Jar包等即可，同时不需应用Puppet、Chef、Ansible或Docker来进行配置管理，大大降低了运维老本。Serverless架构也不再须要监控底层的数据，例如不再须要监控磁盘使用量、CPU使用率等，能够更加专一的将监控眼光放到监控应用程序自身的度量。同时在Serverless架构上，运维人员的工作角色会有所转变，部署将变得更加自动化，监控将更加面向应用程序自身。应用Serverless架构的劣势 从上文中咱们不难看出，绝对于传统我的项目，Serverless具备的以下劣势： 您无需洽购和治理服务器等基础设施，运维成本低。您只需专一业务逻辑的开发，应用函数计算反对的开发语言设计、优化、测试、审核以及上传本人的利用代码。以事件驱动的形式触发利用响应用户申请。与阿里云对象存储OSS、API网关、日志服务和表格存储等服务无缝对接，帮忙您疾速构建利用。例如，通过OSS解决图片和视频的存储问题，当有新数据写入您的OSS资源时，主动触发函数解决数据。提供日志查问、性能监控和报警等性能疾速排查故障。毫秒级别弹性伸缩，疾速实现底层扩容以应答峰值压力。按需付费，反对百毫秒级别免费。只需为理论应用的计算资源付费，适宜有显著波峰波谷的用户拜访场景。总而言之，Serverless是在传统容器技术和服务网格上倒退起来，更多指的是后端服务与函数服务的联合。对于开发者而言，可能将更多的精力关注在函数服务上，更偏重让使用者只关注本人的业务逻辑即可。 同时，Serverless也是云计算倒退到肯定阶段的必然产物。作为普惠科技，云计算倒退的指标肯定是绿色科技和公众科技的产品——而Serverless可能很好的诠释这些：最大水平利用资源、缩小闲暇资源节约；同时升高学习老本和应用老本。 Serverless架构被称为是“真正实现了当初云计算的指标”，这种说法尽管有些夸大，然而也从另一方面体现出了大家对Serverless架构的期盼和信念。自2012年被提出至今，Serverless架构也是经验了7年工夫，正在逐步的走向成熟。 步骤一：连贯ECS服务器阿里云云产品资源体验地址：https://developer.aliyun.com/... 场景将提供一台配置了CentOS 7.7的ECS实例（云服务器）。通过本教程的操作，您能够基于已有的环境开发一个基于函数计算的IP查问工具。 步骤二：开明函数计算服务在应用函数计算前，须要开明函数计算服务。 阐明： 本场景中提供的阿里云子账号无函数计算服务操作权限，请应用您本人的阿里云账号操作。您无需放心扣费问题，因为函数计算服务有肯定的收费额度，请参见计费形式。 1.应用您本人的阿里云账号登录阿里云控制台，而后进入函数计算产品详情页。 2.单击【收费开明】。 浏览《函数计算服务协定》勾选批准服务协定，最初单击 【立刻开明】 。4.单击【治理控制台】进入函数计算控制台。 步骤三：装置Funcraft工具Fun 是一个用于反对Serverless利用部署的工具，能帮忙您便捷地治理函数计算、API 网关和日志服务等资源。它通过一个资源配置文件（template.yml），帮助您进行开发、构建和部署操作。 本步骤将在ECS服务器上安装Funcraft工具。 1.执行以下命令装置NodeJS。 curl -sL https://rpm.nodesource.com/setup_10.x | bash - && yum install -y nodejs2.执行以下命令装置Funcraft。 npm install request @alicloud/fun -g3.执行fun config命令进行本地配置。 fun config请参考以下信息输入您的阿里云账号ID、AccessKeyID和AccessKey密钥等信息。 Aliyun Account ID：请在账号平安设置页面查看您的账号ID。 Aliyun Access Key ID和Aliyun Access Key Secret：请在 平安信息管理 页面查看您账号的AK ID和AK Secret。 ...

简介： 在利用公布和服务降级时，线上问题呈现的可能性更高，本文咱们将联合 Serverless 利用引擎（以下简称 SAE）就 Serverless 架构下，探讨如何保障上线过程中服务的优雅下线。 作者 | 行松 阿里巴巴云原生团队 利用公布、服务降级始终是一个让开发和运维同学既兴奋又放心的事件。 兴奋的是有新性能上线，本人的产品能够对用户提供更多的能力和价值；放心的是上线的过程会不会出现意外状况影响业务的稳定性。的确，在利用公布和服务降级时，线上问题呈现的可能性更高，本文咱们将联合 Serverless 利用引擎（以下简称 SAE）就 Serverless 架构下，探讨如何保障上线过程中服务的优雅下线。 在平时的公布过程中，咱们是否遇到过以下问题： 公布过程中，呈现正在执行的申请被中断？上游服务节点曾经下线，上游仍然持续调用曾经下线的节点导致申请报错，进而导致业务异样？公布过程造成数据不统一，须要对脏数据进行修复。有时候，咱们把发版安顿在凌晨两三点，赶在业务流量比拟小的时候，心惊胆颤、睡眠不足、苦不堪言。那如何解决下面的问题，如何保障利用公布过程稳固、高效，保障业务无损呢？首先，咱们来梳理下造成这些问题的起因。 场景剖析 上图形容了咱们应用微服务架构开发利用的一个常见场景，咱们先看下这个场景的服务调用关系： 服务 B、C 把服务注册到注册核心，服务 A、B 从注册核心发现须要调用的服务；业务流量从负载平衡打到服务 A，在 SLB 上配置服务 A 实例的健康检查，当服务 A 有实例停机的时候，相应的实例从 SLB 摘掉；服务 A 调用服务 B，服务 B 再调用服务 C；图中有两类流量，南北向流量（即通过 SLB 转发到后端服务器的业务流量，如业务流量 -> SLB -> A 的调用门路）和东西向流量（通过注册核心服务中心服务发现来调用的流量，如 A -> B 的调用门路），上面针对这两类流量别离进行剖析。 南北向流量南北向流量存在问题当服务 A 公布的时候，服务 A1 实例停机后，SLB 依据健康检查探测到服务 A1 下线，而后把实例从 SLB 摘掉。实例 A1 依赖 SLB 的健康检查从 SLB 上摘掉，个别须要几秒到十几秒的工夫，在这个过程中，如果 SLB 有继续的流量打入，就会造成一些申请持续路由到实例 A1，导致申请失败； ...

最近我利用腾讯云云函数（serverless）实现了公众号后盾对接和简略爬虫利用，本着好货色要分享的互联网准则，决定写一篇入门文章，从用云函数搭建集体站点这个案例登程，次要面向苦后端久矣的前端开发人员，简略介绍云函数是什么、能够用来做什么以及如何入手应用它。 更酷的是，如果你和我一起跟着这个案例入手，搭建进去的站点是收费的、保护简略的、全网可拜访的。 鉴于自己编码程度个别，serverless也是第一次玩，两头有什么讲得不对的中央还请各位大神海涵并指出；如果有些敌人是齐全零根底但对文中提到的货色感兴趣的，也能够留言发问，我会尽可能回答。 那么，让咱们开始吧。 A 云函数是什么呢？ 依据腾讯云云函数产品文档（您也能够拜访https://cloud.tencent.com/doc... 查看文档）的形容：腾讯云云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮忙您在无需购买和治理服务器的状况下运行代码， 是实时文件解决和数据处理等场景下现实的计算平台。您只需应用 SCF 平台反对的语言编写外围代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、平安地运行代码。 简略说就是如果你以前对服务器常识无所不知，那么当初也不须要晓得了，你能够用你趁手的语言写个函数（比方用js，懂点node就行），函数即是服务（接口），写好间接就能够在任何中央触发调用了，其它的诸如服务器配置什么的都不须要操心。 B 云函数能干什么？ 实践上传统后端无能的事儿云函数都无能，但术业有专攻，依据云函数的个性和当下的支流环境，倡议用云函数来搭建小型web利用后端、公众号/小程序、工具型接口等。 事实上小程序推的云开发就是基于腾讯云的serverless的，包含了云函数、云数据库和云存储。 C 开始应用云函数 要应用腾讯云的云函数首先当然得登录腾讯云。 这里咱们抉择用腾讯云控制台的形式创立、编写和调试云函数，一来面向初学者图形界面更直观，二来集体我的项目没那么简单，控制台足以笼罩常见场景。感兴趣的各位能够自行尝试命令行的形式。 登录后从控制台进入云函数性能页，点击左侧“函数服务”菜单进入函数治理页，点击“新建”新建云函数。 进到新建函数页，看运行环境一栏，作为一个只会JS的前端，我毫不犹豫选了Nodejs；云函数提供了4个版本的Nodejs供选择，6.10和8.9版本对async的反对有瑕疵，12.16版本绝对太新，稳当起见我选了10.15版本。 上面有很多有意思的模板能够抉择，明天咱们先选个Hello World。 而后就能看到生成的代码是这样的： 'use strict';exports.main_handler = async (event, context, callback) => { console.log("Hello World") console.log(event) console.log(event["non-exist"]) console.log(context) return event};能够在这编辑代码，但咱不焦急，先点击“实现”实现函数的创立。而后咱们能够看到腾讯云提供了在线编辑、在线调试、查看日志等十分实用且必要的性能。当初咱们进入“函数治理-函数代码”从新扫视主动生成的hello world代码。 这个函数有三个入参：event、context 和 callback，其中 callback 为可选参数。依据官网的文档： event：应用此参数传递触发事件数据。context：应用此参数向您的处理程序传递运行时信息。 callback（可选）：应用此参数用于将您所心愿的信息返回给调用方。在 Node.js 8.9 和 6.10 版本中，均能够应用 callback 来返回。在 Node.js 10.15 及 12.16 中，应用 async 形容的入口函数，须要应用 return 关键字返回，非 async 模式的入口函数，须要应用 callback 入参返回。 ...

简介： Serverless 将开发人员从沉重的手动资源管理和性能优化中解放出来，就像数十年前汇编语言演变到高级语言的过程一样，云计算生产力再一次产生改革。Serverless 的外围价值是什么？阿里云公布了哪些 Serverless 生态产品，各有什么特别之处？阿里云函数计算的体现如何？阿里云研究员叔同将通过本文分享阿里布局 Serverless 的历程和信心。 引言早在 2009 年，伯克利曾预测云计算将会失去蓬勃发展。近乎有限的云端计算资源，客户无需自建机房，按须要付费成为可能，企业在 IT 方面的投入显著升高，云计算所开释出的技术红利让越来越多的企业客户从云下搬到了云上。 然而，大部分客户在应用云服务时，依然要面对简单的运维、较高的闲置资源、无奈做到真正按需付费，云计算的劣势并未施展到极致。 2015 年 AWS 推出了 Lambda 服务，2017 年阿里云推出了函数计算 FC，2019 年伯克利再次预测 Serverless 将取代Serverful 计算；由此，Serverless 引发业内的宽泛关注。 Serverless 将开发人员从沉重的手动资源管理和性能优化中解放出来，就像数十年前汇编语言演变到高级语言的过程一样，云计算生产力再一次产生改革。与其说 Serverless 是云计算的升华，不如说 Serverless 从新定义了云计算，将成为云时代新的计算范式，引领云的下一个十年。 Serverless 的外围价值疾速交付、智能弹性、更低成本，这是 Serverless 的外围三大价值。 首先，是疾速交付 Serverless 做了大量的端对端的整合以及云服务之间的集成，为利用开发提供了最大便利性，用户无需关注底层的 IaaS 资源，只需专一于业务逻辑的开发，聚焦于业务翻新，大大缩短了企业应用 Go-To-Market 的工夫，发明了更大的业务价值。 其次，是极致的弹性 在 Serverless 之前，置信很多开发者都有过相似的教训，一旦遇到突发流量可能会间接导致系统超时、异样，甚至是解体；当咱们在做大促的时候，须要进行屡次的容量评估并提前做好扩容，一旦评估不准，可能会带来灾难性的影响；而有了Serverles 之后，应答突发流量、容量评估等都将变得更加简略。 其三，是更低的老本 就跟咱们生存中的水电煤一样，Serverless 只为理论产生的资源耗费付费，而无需为闲置的资源买单。 基于以上三大外围价值，Serverless 势必将会取得越来越多企业和开发者关注和青眼。 阿里布局 Serverless 的历程阿里巴巴的 Serverless 实际在业内处于领先地位，不仅淘宝、支付宝、钉钉等曾经将 Serverless 利用于生产业务，阿里云上的 Serverless 产品更是帮忙微博、石墨、跟谁学、Timing 等数万家企业客户胜利落地 Serverless，笼罩前端全栈，小程序、新批发、游戏互娱、在线教育等行业或场景。 ...

Serverless 作为云原生时代下最炽热的名词之一，其架构所提供服务的便捷性，在日常、预发、线上等多套环境中即可部署、调试、运行利用，实现真正的按需付费和免运维，置信关注先进技术的你肯定有所耳闻吧。 而在当下，Serverless 虽提出了一个先进的概念，但对于如何利用Serverless 利用于理论开发，服务于生产效率，切实感触到 Serverless 的便利性，置信大多数开发者还没有体感。 为了疾速帮忙国内开发者触手可及地感触到 Serverless，面向社会上对 Serverless 和云原生感兴趣的开发者，阿里云发动了一个“脑洞试验”：想邀请 10000 名工程师，花 5 分钟工夫，体验 Serverless 架构在云上部署的便利性，在云上写下你的第一行基于 Serverless 的 Hello World。 为了更好得实现这项挑战，阿里云与国内技术社区联结发动这个流动。如果你也感兴趣，不如让咱们从一行 Hello World 开始了解 Serverless？ 三步云上 Hello World· 第一步：花 1min 签到，让你的身影呈现在 DataV 的实时大屏上 · 第二步：花 3mins 提交代码，把你的 Hello World 留在云上 · 第三部：花 1min 查看后果，10000 人指标胜利后，你将收到寰球惟一序列号的私人定制证书 该试验仅反对在PC端实现，链接：https://developer.aliyun.com/topic/yiqi/hol 另外，这次云栖大会有一个全部都是福利的开发者斜杠栏目: Hands-on Labs，没啥特地的，为了承包你一周的T恤，咱们付出了全副致力，举荐看看。

简介： 本文次要分为三个局部：概述中介绍可观测性的基本概念，次要包含 Logging、Metrics、Tracing 三个方面；而后具体介绍函数计算上的 Logging、Metrics、Tracing；最初以几个常见场景为例，介绍在函数计算中如何疾速定位问题并解决问题。 作者 | 夏莞 阿里巴巴函数计算团队 本文整顿自《Serverless 技术公开课》，关注“Serverless”公众号，回复“入门”，即可获取 Serverless 系列文章 PPT。 导读：本文次要分为三个局部：概述中介绍可观测性的基本概念，次要包含 Logging、Metrics、Tracing 三个方面；而后具体介绍函数计算上的 Logging、Metrics、Tracing；最初以几个常见场景为例，介绍在函数计算中如何疾速定位问题并解决问题。概述可观测性是什么呢？维基百科中这样说：可观测性是通过内部体现判断零碎外部状态的掂量形式。 在利用开发中，可观测性帮忙咱们判断零碎外部的健康状况。在零碎呈现问题时，帮忙咱们定位问题、排查问题、剖析问题；在零碎安稳运行时，帮忙咱们评估危险，预测可能呈现的问题。评估危险相似于天气预报，预测到今天下雨，那出门就要带伞。在函数计算的利用开发中，如果察看到函数的并发度继续升高，很可能是业务推广团队的致力工作导致业务规模迅速扩张，为了防止达到并发度限度触发流控，开发者就须要提前晋升并发度。 可观测性包含三个方面：Logging、Metrics、Tracing Logging 是日志，日志记录了函数运行中的要害信息，这些信息是离散且具体的，联合谬误日志与函数代码能够迅速定位问题。Metrics 是指标，是聚合的数据，通常以图表的模式展示。图表中的 tps、错误率等外围指标，能够反映函数的运行状况与健康状况。Tracing 是链路追踪，是申请级别的追踪，在分布式系统中能够看到申请在各个模块的延时、剖析性能瓶颈。函数计算中的 Logging/Metrics/Tracing1. 日志在函数计算中如何查看函数日志呢？在传统服务器开发方式中，能够将日志记录到磁盘中的某个文件中，再通过日志收集工具收集文件的内容；而在函数计算中，开发者不须要保护服务器了，那如何收集代码里打印的日志呢？ 1）配置日志 函数计算与日志服务无缝集成，能够将函数日志记录到开发者提供的日志仓库（Logstore）中。日志是服务配置中的一项，为服务配置 LogProject 和 Logstore，同一服务下所有函数通过 stdout 打印的日志，都会收集到对应的 Logstore 中。 2）记录日志 那日志怎么打呢？在代码中间接通过 console.log/print 打印的日志能够收集到吗？答案是能够的。各个开发语言提供的打印日志的库都将日志打印到 stdout，比方 node.js 的 console.log()、python 的 print()、golang 的 fmt.Println() 等。函数计算收集所有打印到 stdout 的日志并将其上传到 Logstore 中。 函数计算的调用是申请维度的，每次调用对应一个申请，也就对应一个 requestID。当申请量很大时，会有海量日志，如何辨别哪些日志属于哪个申请呢？这就须要把 requestID 一起记录到日志中。函数计算提供内置的日志语句，打印的每条日志前都会带上申请 ID，不便日志的筛选。 3）查看日志 当函数日志被收集到日志服务的 Logstore 中，能够登录日志服务控制台查看日志。 同时，函数计算控制台也集成了日志服务，能够在函数计算管制台上查看日志。函数计算控制台有两种查问形式： 简略查问：简略查问中列出每个 requestID 对应的日志，能够通过 requestID 对日志进行筛选；高级查问：高级查问嵌入了日志服务，能够通过 SQL 语句进行查问。点击链接观看 Demo 演示：https://developer.aliyun.com/lesson_2024_18996 ...

Cube诞生背景 随着云原生技术的推广及落地，容器技术在企业生产环境中的应用比重越来越大。Kubernetes作为容器编排的事实标准，在企业服务中被大量采纳。UCloud容器团队在2018年推出了Kubernetes产品UK8S, 这款产品基于UCloud私有云环境实现，无缝集成了UCloud IaaS层计算、网络及存储的服务，使客户可能疾速获取到生产可用的Kubernetes集群，并领有灵便管制集群的能力。 但在UK8S产品推广及接入客户过程中，容器团队也陆续收到一些用户反馈的问题：** 保护Kubernetes集群减少了额定的累赘；用户除了管利用还须要后端资源，并未能实现以利用为核心的业务管理。Kubernetes体系较为简单，学习曲线比拟平缓，须要客户团队有肯定技术储备；对于曾经应用了容器但尚未尝试Kubernetes的客户也是如此，一方面须要理解Kubernetes的技术体系，另一方面须要批改利用架构适配Kubernetes。心愿能有一款即开即用的容器产品，通过容器间接拉起利用，不须要期待虚拟机就绪再部署利用，缩短利用就绪等待时间。**为解决上述用户问题，容器团队开发了一款新的serverless容器产品Cube&version=12040210&nettype=WIFI&lang=zh_CN&fontScale=100&exportkey=AeyrACYKyIn6fp2sFm1vTgs%3D&pass_ticket=4wqmpVNc2jvkdI3dVYbM1f74r5bD%2FzhEMtm19sXCUL0fO4Be09DNFqEUoj08GHxM&fontgear=2.000000)，目前正处在公测阶段。除了升高用户应用容器的门槛，该产品还具备以下个性： 免运维：没有保护资源累赘，不须要关怀运行地位，以利用为核心，以容器镜像为利用打包规范。按需付费：依照利用理论应用资源付费。主动扩缩容：基于海量资源，提供API，可按需拉起和敞开利用，主动调度资源。高可用：产品自身高可用，同时提供利用自愈能力。技术选型 在实现Cube产品个性的过程中，容器团队须要解决几个技术问题： 1. 容器运行时的选型 私有云产品必然要思考多租户隔离问题。不同于UK8S产品以云主机为根底构建的隔离性，Cube产品则间接在宿主物理机上运行容器。规范docker实现的容器并不能实现同台宿主机上不同用户不同容器之间的强隔离，因而Cube产品须要一款同时具备虚拟机强隔离性和容器疾速启动特点的容器运行时计划。 容器团队留神到AWS开源了轻量级虚拟机firecracker，具备资源占用少、启动速度快、易于保护等诸多长处，并已用于理论生产环境，十分合乎Cube业务场景，因而最终采纳了以firecracker轻量级虚拟机为根底的容器运行时计划。从上面两张图能够看出，通过对云计算场景特地的精简和优化， firecracker绝对于目前支流的虚拟化组件qemu在启动速度和内存耗费方面有显著的劣势。 VMM启动工夫和内存占用比照，图片援用起源&version=12040210&nettype=WIFI&lang=zh_CN&fontScale=100&exportkey=AeyrACYKyIn6fp2sFm1vTgs%3D&pass_ticket=4wqmpVNc2jvkdI3dVYbM1f74r5bD%2FzhEMtm19sXCUL0fO4Be09DNFqEUoj08GHxM&fontgear=2.000000) 2. 容器治理服务 反对虚拟机容器运行时的容器治理服务也有多种开源计划，例如containerd/cri-o，kata-container和firecracker-containerd等。通过比拟，容器团队抉择了cri-o + firecracker-containerd的组合。这二者在性能上可能满足单机容器治理的需要，而且和其余选型相比，代码架构更加清晰，调用链路简单明了，便于后续依据产品需要定制和革新。 3. 容器调度服务 Kubernetes曾经成为了容器调度的事实标准，具备丰盛的性能和良好的可扩展性。因而容器团队采纳Kubernetes作为根本调度框架，并依据产品需要做相干革新，最终根本的服务架构如下所示： 优化改良尽管采纳开源计划能够放慢开发进度，但为满足产品需要仍需解决一些问题，次要包含以下几个方面： 1. 容器镜像 在规范的容器镜像实现中，镜像是通过分层构造存储在宿主上的。当创立容器时，容器运行时会在镜像层之上创立一个可写层，并挂载在宿主上供容器实例应用。但Cube容器并不是间接在宿主上运行的，也不须要在宿主上挂载容器根目录。因而容器团队批改了cri-o中镜像层的相干实现，间接将容器可写层以块设施的形式挂载到轻量级虚拟机中而非宿主上，减低了宿主对Cube容器的烦扰。 另外，为了解决新镜像拉取迟缓导致的容器实例启动慢的问题，容器团队提出了镜像近程挂载的解决方案。将容器镜像以块设施的模式存储在缓存集群，当须要在此镜像上生成容器实例时，先将容器镜像通过近程挂载的模式挂载到宿主上，而后容器运行时会在宿主上创立一层可写层生成容器实例。同时后盾会将近程镜像同步到宿主本地，进一步减速读取，升高集群危险。上述办法可使宿主上首次获取镜像的工夫缩短至3s以下，并有进一步优化空间。目前这一性能以镜像缓存的产品模式提供给用户应用，并正在逐渐整合到一般镜像拉取过程中。 2. 应用私有云资源 网络方面，Cube容器的网络模型和云主机的基本相同。在将相干网络性能以cni插件的模式实现之后，Cube容器就能够很好的接入到私有云vpc网络中。 存储方面，Cube容器目前反对了两种类型的存储：能够多点读写的网络文件系统nfs和仅单点读写的云硬盘udisk。在文件存储性能上，Cube产品实现了在轻量级虚拟机中主动挂载nfs的性能，用户只需在配置文件中指定好挂载点和挂载参数，就能间接在容器中应用网络文件系统，并能够同时反对vpc网络内用户自建的nfs和UCloud私有云产品ufs。在块设施性能上，容器团队扩大了firecracker块设施的实现。通过增加对vhost-user协定的反对，Cube轻量级虚拟机能够间接对接到spdk服务，从而实现了对高性能的rssd型云硬盘挂载和应用。 3. 容器运行环境 为了缩小额定资源耗费，容器团队在容器治理服务和容器运行时上做了大量优化工作。 容器团队批改了cri-o治理容器组的架构，采纳了单pod对应单shim的模型。通过一个shim治理一个pod内全副容器，能够显著的升高shim资源耗费，简化容器治理。对于轻量级虚拟机，容器团队也对kernel/rootfs/init过程等做了充沛地精简优化，只保留了最根本的性能，以放慢启动速度，减小平安攻击面，升高资源耗费。另外，容器团队还在轻量级虚拟机中内置了infra container的实现，Cube作为pod运行时能够不用挂载额定的infra容器。 4. k8s革新 Kubernetes作为一个通用的容器调度框架，可能满足大部分容器治理的需要。但针对Cube特定的应用场景，容器团队仍需对k8s组件做一些革新。在管制面，容器团队采纳了自定义的调度器，能够更好的满足多租户场景下工作优先级，调度速度，资源管理的需要。在宿主节点上，鉴于Cube容器运行时的特点，容器团队精简了一些不须要kubelet实现的性能，例如在宿主上挂载configmap/volume目录，运行cni插件，收集特定目录日志等，加强了容器与宿主之间的隔离安全性。 Cube将来瞻望在实现了上述开发革新后，Cube产品胜利上线，并获得良好效果。后续Cube产品会持续沿着帮忙用户晋升效率、升高开销、简化保护、节约老本的思路继续迭代更新。在容器性能方面，容器团队会持续优化轻量级虚拟机IO门路，缩小虚拟化及治理组件的性能损耗，确保用户容器实例稳固高效运行。在服务治理方面，Cube产品层面会推出多种的容器治理控制器，并实现Cube实例间接接入Kubernetes集群的能力，为用户提供多层次的资源调度形式，不便用户按理论须要治理保护。 如果您对UCloud Cube产品感兴趣，欢送扫码退出Cube测试交换群！

过来几年间，Serverless 倒退迅猛，与其相伴的还有从小程序、挪动端等到前后端一体化的演进与实际，也正因如此，从云计算到前端，泛滥开发者都极为关注。本文介绍了腾讯云CloudBase 的 Serverless 实际，置信会对关注 Serverless 以及研发模式的开发者有所裨益。 Serverless到底是什么？在国内，Serverless 通常被称说为「无服务计算」。但 Serverless 不是一种具体的框架、代码库或者工具集，而是一个为了加重开发者的服务经营/运维老本而提出来的一套实践思维。 为了简化开发者们的了解老本，业界对 Serverless 有一种联合云计算行业的定义形式： Serverless = FaaS + BaaS FaaS：Function as a Service，函数即服务。 对于 FaaS，业界曾经有比拟多的成熟厂商提供了线上产品，例如： AWS Lambda，起步最早的 FaaS 云产品，和 AWS 的云产品有很好的互动，开发者应用较多。Azure Functions，来自微软的私有云函数计算产品，晚于 AWS lambda 公布。Google Cloud Functions，来自 Google 的私有云计算产品，和 Google 的 Firebase 有较深的互动。腾讯云 Serverless Cloud Fucntion，来自腾讯云的私有云计算产品，和腾讯云的云开发有较深的联合落地。BaaS: Backend as a Service， 后端即服务。 对于 BaaS，笼罩的范畴会更广大一些，须要去解决 Serverless 落地过程中除去计算而外的所有后端场景，例如数据库服务，音讯队列和存储服务等。开发者在应用 BaaS 服务的时候，不再须要去感知后端的服务运维，提出服务需要，享受服务即可。例如在数据库服务局部，通常又被细称为 DBaaS（Database as a Service）。传统场景下，开发者的运维团队要关怀数据库运维的细节问题，而基于 DBaaS，开发者只须要关注业务逻辑即可。 云开发是什么？云开发（Tencent CloudBase，TCB）是腾讯云提供的云原生一体化开发环境和工具平台，为开发者提供高可用、主动弹性扩缩的后端云服务，蕴含计算、存储、托管等serverless化能力，可用于云端一体化开发多种端利用（小程序，公众号，Web 利用，Flutter 客户端等），帮忙开发者对立构建和治理后端服务和云资源，防止了利用开发过程中繁琐的服务器搭建及运维，开发者能够专一于业务逻辑的实现，开发门槛更低，效率更高。技术文档：https://cloudbase.net ...

对于serverless读了这篇文章有所启发，珍藏记录一下。前端还是任重道远。

我偶尔会想要在家里搭建服务器，然后通过动态域名服务ddns绑定域名进行访问。使用ddns的一个前提就是获取自己的外网IP，有一些免费的获取外网IP的服务，比如 http://members.3322.org/dyndns/getip俗话说，免费的就是最贵的，不知道这些服务什么时候会停服。最近在学习腾讯云的serverless，发现可以有免费的400万次调用，于是就写了个简单的获取外网IP的服务。 代码很简单 <?phpfunction main_handler($event, $context) { return $event->requestContext->sourceIp;}?>使用方法 curl https://service-65vvblqg-1255315622.gz.apigw.tencentcs.com/release/client_ip

之前就想让 nest.js 在阿里云上部署 serverless 试试，但在网上没有搜到相关的例子 只找到了 express 的例子，但我不知道怎么从 nest.js 获得 express app 对象。就此陷入僵局，但在搜索的过程中发现腾讯云是有 nest.js 的例子的，一看他们的代码，( • • )✧ express app 原来是这么拿的啊,只要用 ExpressAdapter 就好了，但之前没用过就不了解 然后我刷刷刷的写出了如下代码 //file://src/index.tsimport { NestFactory } from "@nestjs/core";import { ExpressAdapter } from "@nestjs/platform-express";import { Server } from "@webserverless/fc-express";import express from "express";import { AppModule } from "./app.module";let p = (async () => { const adapter = new ExpressAdapter(app); const app2 = await NestFactory.create(AppModule, adapter); app2.enableCors(); await app2.init(); return new Server(app);})();module.exports.handler = function (req, res, context) { p.then((server) => { server.httpProxy(req, res, context); });};结果 （；´ ｀）ゞ 他啪啪啪的一直超时，我就不明白了他为啥调用一直超时。 ...

简介： 对于大多数应用而言，借助 Serverless 服务，开发者可以将绝大多数精力投入在业务逻辑的开发整合上，大大缩短开发周期，降低运维成本。有人说：Serverless 正在改变未来软件开发的模式和流程，它就是云计算的未来。技术领域真正的变革看似是新技术的高歌猛进，为客户创造价值才是任何技术变革的原点。本文将从客户价值的角度，再一次探讨为什么说 Serverless 是云的未来。 作者 | 不瞋  阿里云高级技术专家 每隔几年，IT 界就会出现新突破性的进展。回望整个计算机技术发展史，我们会发现“抽象、解耦、集成”的主题贯穿其中。产业每一次的抽象、解耦、集成，都将创新推向新的高度，也催生出庞大的市场和新的商业模式。 对于大多数应用而言，借助 Serverless 服务，开发者可以将绝大多数精力投入在业务逻辑的开发整合上，大大缩短开发周期，降低运维成本。有人说：Serverless 正在改变未来软件开发的模式和流程，它就是云计算的未来。技术领域真正的变革看似是新技术的高歌猛进，为客户创造价值才是任何技术变革的原点。本文将从客户价值的角度，再一次探讨为什么说 Serverless 是云的未来。 Serverless 对客户的价值为客户创造价值是任何技术变革的原点，从客户价值倒推，真正需要回答的是：客户的痛点是什么？Serverless 在解决客户痛点上是否有明显优势？甚至为客户创造新的机会？以企业的平台化策略为例，为什么众多 SaaS 企业不能像 Salesforce 一样实施平台策略，打造 PaaS 或者 Serverless 计算平台？甚至做 PaaS，做中台变成了企业生死劫？这其中固然有业务、组织的顶层设计原因，但不可否认，打造平台的难度和成本太高也是其中很重要的原因。一方面要支撑前台业务的高速发展，另一方面又要抽象、重组，对系统进行重构。因此需要有新的方法论和工具来降低平台构建的成本，实现快速迭代演进。 从更宏观的视角来看，企业交付价值的方式，正在被数字技术重塑。根据阿里研究院的报告，在零售、金融等行业，数字化的商业形态正在代替传统商业形态，成为主流和必然。即使在工业制造等领域，企业的商业形态并非通过数字化的形式表现，但充分利用数据科技进行生产运营优化，也正在成为行业共识。在数字化转型的时代 ，企业面临巨大的竞争压力和不确定性，产品 time-to-market 的能力比任何时候都重要。根据微软的估计，未来 5 年会产生 5 亿个应用，比过去 40 年的总和都多，现有的研发模式已无法支撑这样规模的应用开发需求。 Serverless 计算的思想是将同质化的、负担繁重的基于服务器等基础设施的开发和运维等工作从未来云上应用开发中移除，借助云上丰富的托管服务能力，以搭积木的方式构建弹性、可靠、低成本的系统或应用。除此之外，云服务商也通过事件驱动的方式加强产品集成和被集成的能力。 以 Serverless 的核心计算产品函数计算为例，在函数计算出现之前，客户要通过很多胶水代码完成多个云产品间的集成，还要仔细的处理各种错误情况。当函数计算和阿里云对象存储集成后，对象存储中产生的上传 / 删除对象等事件能够自动、可靠地触发函数处理，而且每个环节都是弹性高可用的，客户能够快速实现大规模数据的实时并行处理。同样的，通过消息中间件和函数计算的集成，客户可以快速实现大规模消息的实时处理。在未来，无论是一方云服务，还是三方应用，所有的事件都将被捕获，被函数计算等服务可靠地处理。 对比传统开发模式，Serverless 模式基于大量成熟的云服务能力构建应用，客户的技术决策点更少，实施复杂度更低。随着云产品的完善，产品的集成和被集成能力的加强，软件交付流程自动化能力的提高，我们相信在 Serverless 架构下，企业的敏捷性有 10 倍提升的潜力。 Serverless 对云服务商的价值Serverless 有助于云服务商建立更宽广的差异化竞争优势。基础设施即服务（IaaS ）层的竞争本质是规模。云服务商通过提升供应链的议价能力、资源并池、采用异构硬件、软硬协同优化等手段来最大化性能功耗比（performance per watt）和性能价格比（performance per dollar）。基础设施层竞争的主要形式是价格战。 但云的竞争一定不是单一维度的，正如苹果提供了移动应用编程模型最好的实现，这是硬件、软件、服务三位一体的协同整合能力，以此为基础形成的出色用户体验和粘性让其在移动互联网产业中独树一帜。云服务商也需要思考如何在基础设施、产品体系、生态等方面多维度，立体化地打造竞争力。发展 Serverless 关乎于产品体系差异化竞争力的建设，对云服务商至关重要。 ...

导读：本文主要介绍Serverless计算相关技术与其在华为云数据湖探索服务（后文简称DLI）中的技术落地。Serverless是DLI将计算能力服务化和产品化关键技术，与传统IAAS和PAAS技术不同，DLI运用Serverless技术向客户提供了一种高效易用易扩展的计算框架，使得客户更能聚焦业务，避免牵扯集群运维的细枝末节。本文将从以下几点解读Serverless技术： 1. serverless计算简介 2. 云计算架构演进—从IaaS到Serverless 3. Serverless计算应用场景与潜力 4. DLI Serverless 计算 serverless计算简介 图 Serverless与传统云计算比较 无服务器计算（Serverless）是一种新型的云计算范式，在业界也被称为FaaS（函数即服务），它有别于传统的IaaS（基础设施即服务）和PaaS（平台即服务）技术，旨在帮助开发者摆脱减少甚至免去底层基础架构管理上的诸多烦扰。Serverless计算服务允许客户在不构建一个复杂的基础设施的情况下开发，运行和管理应用程序。在2014年10月先由http://hook.io提供给业界，接着AWS推出Lambda，2016年Google Cloud Functions，Microsoft Azure Functions对外提供服务，接下来IBM的OpenWhisk并开源。目前华为云也提供类似FaaS产品FunctionStage，而DLI服务也向用户提供Serverless Spark产品。 图 Serverless成本优势 Serverless计算并非旨在实现真正意义上的“无服务器”，而是指企业将后端基础结构的维护交由可靠云服务公司，云服务公司以服务的方式为开发者提供所需各类功能等，加快企业产品研发和发布周期，同时增强服务的扩展性。 Serverless计算免去后端基础服务的诸多事宜，开发者可以专注在产品代码，不需要维护任何的服务器。服务器由云服务商提供，服务扩容的便捷性、灵活性大大提升。Serverless应用程序运行应用的服务默认提供高可用、容错高。无服务器计算，相比传统服务性价比高，企业只需要支付所使用的部分，没有任何与无服务器计算相关的成本，尤其是应用程序使用随时间变化大的企业是非常划算的。 云计算架构演进—从IaaS到Serverless云服务第一阶段的云主要解决硬件资源（网络，计算，存储）的运维和供给问题，也就是 IaaS 云，可以理解成基于硬件资源的共享经济。IaaS 云的交付的主要是资源，接口以及控制台也是面向资源的，尽量以模拟物理机房环境来降低应用的迁移成本。而云发展到当前阶段来看，出现了两种需求： 真正的按需计算 原来云的按需计算只是虚拟机维度的，按时间计费以及弹性伸缩，并不能正真做到按需计算，计算和内存资源都是预申请规划的，和服务的请求并发数并没有明确的关系，哪怕一段时间一个请求没有，资源还是依然占用。而 Serverless计算可以做到按请求计费，不需要为等待付费，可以做到更高效的资源利用率。 面向应用 本质上用户对云的期望是应用的运行环境，并且最好是只让用户关心业务逻辑，而不需要关心，或者尽量少关心技术逻辑（比如监控，性能，弹性，高可用，日志追踪等）。这也是云原生应用（Cloud Native Application）这个概念提出的背景。 随着两种需求日益强烈，Serverless计算模式孕育而生。它给出的方案就是应用只需要把包含自己业务逻辑的功能模块提交给云，其他的事情由云来完成。这样，云相当于直接接管了业务逻辑模块，然后其他的技术功能直接由云来提供，不依赖开发者在自己应用中引入标准化框架来实现。 Serverless计算应用场景与潜力Serverless计算敏捷灵活，适用门槛低，综合成本低的优势，特别适合以下几个场景： 视频，图片以及流式事件处理 其本质上是需要一种通用的，可自定义的，工作流应用。当前的工作流一般都是针对具体场景的，尚无支持自定义逻辑并且适用于各种类型事件的分布式工作流。而基于 Serverless计算有可能诞生这样一种工作流。通过与Flink，Spark Streaming这样的流式大数据处理平台结合，Serverless计算模型将充分发挥其价值。 事件驱动以及响应式架构 这个场景和视频图片流场景有相似之处，只不过前一个关注的是应用场景，这条单指技术架构场景。服务器端的事件驱动和响应式架构和客户端技术相比，一直缺少一种统一的体系解决方案，主要原因是服务器端缺少分布式系统级别的支持，纯开发框架的方式实现比较困难，如果调度系统和开发框架配合，实现这种架构就比较容易了。 IoT 物联网场景实际上和前面的流式事件处理以及事件驱动架构都有关系。这里单独作为一条阐述，主要是物联网对应用开发带来的不仅仅是架构上的变化。互联网主要是信息技术，主要是面向人的应用，要求及时把信息展示给用户，所以应用多是 http 的请求响应模式，对延迟比较敏感（毫秒级）。而物联网场景下，多是事件触发，哪怕有人参与的场景，比如智能开关，也是触发事件后控制另外的设备，对延迟忍耐度较高（秒级），协议多也不是 http，而是物联网相关的消息协议。 应用系统的自定义扩展需求 任何一个标准的系统，发展到一定程度都会有不同的自定义扩展需求。一种是提供内置扩展机制，比如 Java 的许多应用，可以允许在应用中增加扩展，应用自己通过 jvm 的隔离机制提供插件运行环境。另外一种是通过远程接口（无论是 http 还是其他远程协议），由用户按照协议实现自定义需求，然后整合，应用本身不提供扩展运行环境。前者对编程语言有约束，隔离性差，后者开发运维成本比较高。如果基于Serverless计算支持一种分布式的扩展运行环境，自动和应用整合，相当于兼有了二者的优势。可以预见，在未来几年里，大多数 SaaS 以及 API 服务都会提供类似Serverless计算的环境来托管用户的自定义扩展。如果私有环境中也有标品，私有部署的应用也会逐渐提供这种整合能力。 跨云与混合云场景 当前大多数混合云解决方案都只能做到基础设施的混合，至于用户的应用要实现多云，则只能在用户自己的应用中处理，云平台能提供的帮助有限。但因为Serverless计算侵入了应用的架构，接管了应用的事件输入，乃至事件输出，所以它可以做的更多，也可能提供一种基于Serverless计算的混合云开发框架，用户按照架构模式实现逻辑就天然跨云。 边缘计算场景 边缘计算当前的应用场景还没凸显出来，但可以预见的是，边缘的计算能力肯定不如云端，更小的资源使用粒度对边缘更友好。此外，边缘的具体资源要对用户透明。从以上两点来看， Serverless计算对边缘计算是天然友好的。同时，边缘计算要解决的很多问题和混合云场景类似。 ...

简介： Serverless 是如何产生的？当前有哪些落地场景？Serverless 的未来又将如何？本文分享阿里资深技术专家对 Serverless 的看法，回顾其发展历程，并对 Serverless 的发展趋势做出预测。 源起回望整个计算机技术发展史，我们会发现 “抽象、解耦、集成” 的主题贯穿其中。产业每一次的抽象、解耦、集成，都将创新推向新的高度，也催生出庞大的市场和新的商业模式。 大型机时代，硬件和软件都是定制化的，使用专有的硬件、操作系统和应用软件。 PC 时代，硬件被抽象解耦成 CPU、内存、硬盘、主板、USB 设备等标准化的部件，不同厂商生产的部件可以自由组合，组装成整机。软件被抽象解耦为操作系统、库等可复用组件。硬件和软件的抽象解耦，创造了新的商业模式，释放了生产力，造就了 PC 时代的繁荣。 云的时代，硬件软件化和软件服务化成为最显著的两个趋势。 硬件软件化的核心在于硬件功能中越来越多的部分由软件来呈现，从而在迭代效率、成本等方面获得显著优势。以软件定义存储（Software Defined Storage，SDS）为例，SDS 是位于物理存储和数据请求之间的一个软件层，允许用户操控数据的存储方式和存储位置。通过硬件与软件解耦，SDS 可运行于行业标准系统或者 X86 系统上，意味着用户可以无差别的使用任何标准的商用服务器来满足不断增长的存储需求。硬件与软件解耦也让 SDS 能够横向扩展，消除容量规划，成本管理等方面的复杂性。 云时代的另一趋势是软件服务化。应用软件的功能通过网络以远程调用的模式被海量用户使用。服务成为应用构建的基础，API 被实现为服务提供给开发者，微服务架构获得广泛的成功。服务也成为云产品的基本形态。过去 10 年，云已经证明了它的成功。用户只需要通过调用 API 就能获取服务器，而无需自己建设数据中心。算力以前所未有简洁的方式提供给用户。 还记得 Google 那篇著名的 “Datacenter as a computer “ 论文吗？如果我们把云看作是 DT 时代的计算机，那么一个很自然的问题是：随着云的 API（全托管服务）越来越丰富，什么才是适合于云的编程模型？我们应当以何种 “抽象、解耦、集成” 的方式构建基于云的应用？ 在回答上述问题之前，让我们首先将目光转向 SaaS 领域。Salesforce 是 SaaS 领域的明星企业，在平台化能力建设方面的布局为我们提供了一个绝佳的案例。早期的 SaaS 产品采用标准化的交付模式，通过开放 API 接口实现被集成的能力。随着 Salesforce 产品越来越丰富，客户规模日益增长，企业开始面临新的挑战： 如何更快地推出新产品，加强产品间的整合和协同？客户迅速增长，需求多样。如何高效地满足客户的定制化需求，增加客户粘性？如何提高产品被集成的能力，更好的衔接上下游资源？当产品能力和 API 完整度到达一定水准后，如何让开发者快速整合 API，围绕 Salesforce 能力便捷地开发应用？如何设计好的商业模式，让客户、企业和开发者共赢？Salesforce 的策略是让整个业务、技术和组织平台化。平台放大了企业的价值，让企业、客户、开发者三方受益。通过不断提升平台的应用交付能力，对内大幅提高产品的研发效率，加强产品的集成和整合；对外则大幅提高了产品的被集成能力，建立开发者生态。 ...

蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲整理成文并将陆续发布在“金融级分布式架构”公众号上，本文为其中一篇。本文作者：杨延昭（杨冰），蚂蚁金服智能科技产品技术部总监 互联网技术发展日新月异，我们正在进入云原生时代，这个过程中金融行业要如何拥抱云原生？在近两年蚂蚁金服将云原生在金融领域落地，沉淀下一些实践经验，接下来我想分享在蚂蚁的演进过程当中，我们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及我们是怎么解决的。 经过多年云计算的蓬勃发展，上云已经不是太大问题，接下来的问题是怎么把云用好，用得更高效。RightScale 2019年最新数据显示，现在公有云规模占22%，只使用私有云的客户占3%，更多客户通过混合的模式去使用云，通过混合云取得数据隐私、安全与效率、弹性的平衡。 再看全球整个 IT 行业，公有云的比例只占整个基础 IT 市场的10%，市场空间仍然很大，IT 市场中剩下很多都是传统企业客户。为什么传统行业无法很好地利用公有云，一个重要的原因是因为他们的 IT 系统经过很长时间建设，很多都有自己的机房。另外有些则业务比较稳定，对上公有云没有很强的需求。它们通常会发展混合云策略，把一些核心业务留在私有云，而把一些边缘业务或创新业务放在公有云上。 这些特点在金融行业也非常明显，除此之外金融行业还有两个特征： 业务形态走向开放和互联网化：随着互联网和数字化经济的发展，金融机构需要进行数字化转型，以及业务敏捷化、服务场景化，以应对新的商业模式带来的冲击；监管合规的诉求：金融行业的业务特点决定了必须是强隔离，强监管的，所以公有云上的资源共享模式在监管方面会有比较大的挑战。因此，混合云战略对金融机构更为适用。这一结论也得到研究支持，根据调研机构 Nutanix 的报告，全球金融业在混合云应用方面的发展速度超过其它行业，目前部署普及率达到21%，而全球平均水平为18.5%。 那么，什么样的混合云是适合金融机构的呢？以蚂蚁的演进历程为例。 蚂蚁在第四代架构的时候演变成为云平台架构，而且为了应对互联网业务形态下突发性业务对资源的弹性需求，蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。现在蚂蚁已经演进到第五代云原生架构。蚂蚁又是如何在云原生的架构下，把混合云变成金融级的混合云，我想会对各位有些启发。在这个发展过程中，有一条主线，是不同阶段蚂蚁对研发的标准和要求，包括：自主、成本、安全、稳定、海量、敏捷，这也是在在线金融的时代，我们对云原生架构的要求。 从分布式到云原生 建立金融级交易支付系统 建立金融级的在线交易系统，第一步是要实现金融级分布式的架构，蚂蚁在这方面的代表技术是 SOFAStack 和 OceanBase，目前都已对外商业化，并有丰富的案例。SOFAStack 代表的是，在整个应用层或者无状态服务这个层面上，如何去做可伸缩、可扩展的一套架构。OceanBase 代表的是以数据库为代表的存储或者是有状态服务层面，如何在架构上面去进行分布式。它们拥有四个特性： 高可用，99.99%+的可用性保证，确保系统始终连续运行不中断；一致性，在任何异常情况下数据最终一致，确保资金安全；可扩展，支持应用级、数据库级、机房级、地域级的快速扩展；高性能，存储采用读写分离架构，计算引擎全链路性能优化，准内存数据库性能。而这四个关键的特性都是金融业务最为看重的，而且需要在应用和存储上端到端实现。 以一致性为例，在单个数据库内是可以确保数据一致性的，但在大规模应用的情况下，单个数据库总是会出现瓶颈，数据往往会像服务或者应用一样，按照类似交易、支付、账目等粒度垂直拆开，当这些数据分别存储在不同的数据库集群后，就需要在应用层来解决一致性问题了，同时为了支持海量数据，数据库集群内部也会做分别和多副本，OceanBase 就是这样一套分布式数据库，在其内部也要实现分布式事务。只有这样上下配合才能解掉所有分布式架构下的一致性问题，缺一不可。 再比如可扩展性方面，有些系统号称做了分布式架构，实际可能只是用了微服务框架，做了应用层的服务化改造，但数据库层既没有用水平扩展的技术，也没用分布式数据库，整个系统的可扩展性就卡在数据层的短板上。 所以，真正的分布式系统，需要实现端到端的分布式，才能实现无限可扩展和高性能，而真正的金融级分布式系统则要实现端到端的高可用和一致性。 蚂蚁金服三地五中心异地多活架构我们认为，高可用架构最关键的目标是数据不丢，业务不停。在这个目标的基础上，我们设计并实施了三地五中心的异地多活架构。它的核心优势包括城市级容灾，低成本交易，无限可扩展，以及 RPO=0，PTO<30s. 大家知道我们在去年云栖大会上做了一次剪网线的demo，它演示了整个架构层面上怎么样做到跨城市多活和灾难情况下的恢复快速恢复能力。同时在高可用达标的情况下，我们也做了很多风险相关的事情，总结起来就是在高可用的基础上还要做到资金的安全、变更的免疫和故障的快速恢复。 解决了高可用的问题，其实金融级最被高频提到的话题就是安全，在云原生时代，我们要解决的是全链路、端到端的安全风险。具体分为三个层面： 云原生网络安全，包括策略化高效流量控制，全链路加密，流量劫持与分析；云原生基础设施安全，包括安全容器，不共享内核，以及安全沙箱；云原生业务安全，包括 SOFAEnclave 机密计算中间件，以及内存安全的、多任务 Enclave LibOS Occlum。 这个部分我的同事在《金融服务的云原生安全架构》演讲中会详细介绍。小结一下，所谓金融级的能力，最主要是要实现端到端的金融级的高可用，同时实现端到端的安全。接下来我想分享的是，在云原生这个阶段往前走遇到了哪些问题。 从单元化到弹性架构 应对互联网爆炸式的流量脉冲 从单元化到云原生下的弹性架构 首先解释下什么是单元化，大家可能比较容易理解数据库层的分库分表或者说  Sharding，能够通过分片的方式解决集中存储计算性能问题，单元化的核心思想是把数据的分片提前到了入口请求的分片，在机房的网络接入层将用户请求根据某个纬度（比如用户 ID）进行 Sharding，这就好比把每个机房就当做了一个巨大无比的有状态的数据库分片，当你是一个 ID 尾号为007或者008用户的时候，当请求通过手机端或者网页域名发送到机房，接入层就已经识别出应该将你路由到华东地区还是在华南地区。当你进入到某个地区的机房时，大部分请求处理工作可以在机房内部完成。偶尔会有一些业务可能会发生跨机房的服务调用，比如说数据在 A 机房的用户给数据在 B 机房的用户转账。这个时候就需要在这个机房上去做有状态的设计。 我们走向云原生时代的时候，在大的架构上面用 Kubernetes 为基础来设计，在单元化架构下，我们选择在每个单元里部署一个 Kubernetes 集群，将支持多 K8s 集群管理和管控指令下发的 Federated APIServer 做逻辑上的全局部署，其中管控元数据是存储在一个 ETCD 集群的，以保持全局数据一致，但大家知道 ETCD 也只能解决同城双机房的容灾，无法再应对多城市多数据中心的一致性，因此我们正在把 ETCD 搬到我们的 OB 的 KV 引擎上，这样在引擎层还是保持 ETCD 的存储格式和语义，存储层就具备了三地五中心高可用能力。 ...

前言概述本文介绍了使用函数计算部署深度学习 AI 推理的最佳实践, 其中包括使用 FUN 工具一键部署安装第三方依赖、一键部署、本地调试以及压测评估， 全方位展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。 1.1 DEMO 概述 通过上传一个猫或者狗的照片， 识别出这个照片里面的动物是猫还是狗 DEMO 示例效果入口： http://sz.mofangdegisn.cnDEMO 示例工程地址： https://github.com/awesome-fc/cat-dog-classify1.2 解决方案 如上图所示， 当多个用户通过对外提供的 url 访问推理服务时候，每秒的请求几百上千都没有关系， 函数计算平台会自动伸缩， 提供足够的执行实例来响应用户的请求， 同时函数计算提供了完善的监控设施来监控您的函数运行情况。 1.3. Serverless 方案与传统自建服务方案对比1.3.1 卓越的工程效率 自建服务函数计算 Serverless基础设施需要用户采购和管理无开发效率除了必要的业务逻辑开发,需要自己建立相同线上运行环境， 包括相关软件的安装、服务配置、安全更新等一系列问题只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署学习上手成本可能使用 K8S 或弹性伸缩( ESS )，需要了解更多的产品、名词和参数的意义会编写对应的语言的函数代码即可1.3.2 弹性伸缩免运维 自建服务函数计算 Serverless弹性高可用需要自建负载均衡 (SLB)，弹性伸缩，扩容缩容速度较 FC 慢FC系统固有毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力，免运维监控报警查询ECS 级别的 metrics提供更细粒度的函数执行情况，每次访问函数执行的 latency 和日志等， 更加完善的报警监控机制1.3.3 更低的成本 函数计算 (FC) 固有自动伸缩和负载均衡功能，用户不需要购买负载均衡 (SLB) 和弹性伸缩。具有明显波峰波谷的用户访问场景(比如只有部分时间段有请求，其他时间甚至没有请求)，选择按需付费，只需为实际使用的计算资源付费。对于明显波峰波谷或者稀疏调用具有低成本优势， 同时还保持了弹性能力，以后业务规模做大以后并没有技术切换成本，同时财务成本增长配合预付费也能保持平滑。部分请求持续平稳的场景下,可以配合预付费解决按需付费较高单价问题。函数计算成本优化最佳实践文档。假设有一个在线计算服务，由于是CPU 密集型计算， 因此在这里我们将平均 CPU 利用率作为核心参考指标对成本，以一个月为周期，10台 C5 ECS 的总计算力为例，总的计算量约为 30% 场景下， 各解决方案 CPU 资源利用率使用情况示意图大致如下: ...

提到天气预报服务，我们第一反应是很简单的一个服务啊，目前网上有大把的天气预报 API 可以直接使用，有必要去使用 Knative 搞一套吗？杀鸡用牛刀？先不要着急，我们先看一下实际的几个场景需求： 场景需求 1：根据当地历年的天气信息，预测明年大致的高温到来的时间场景需求 2：近来天气多变，如果明天下雨，能否在早上上班前，给我一个带伞提醒通知场景需求 3：领导发话“最近经济不景气，公司财务紧张，那个服务器，你们提供天气、路况等服务的那几个小程序一起用吧，但要保证正常提供服务”。从上面的需求，我们其实发现，要做好一个天气预报的服务，也面临内忧（资源紧缺）外患（需求增加），并不是那么简单的。不过现在更不要着急，我们可以使用 Knative 帮你解决上面的问题。 关键词：天气查询、表格存储，通道服务，事件通知 场景需求首先我们来描述一下我们要做的天气服务场景需求： 1. 提供对外的天气预报 RESTful API根据城市、日期查询（支持未来 3 天）国内城市天气信息不限制查询次数，支持较大并发查询（1000）2. 天气提醒订阅国内城市天气信息，根据实际订阅城市区域，提醒明天下雨带伞使用钉钉进行通知整体架构有了需求，那我们就开始如何基于 Knative 实现天气服务。我们先看一下整体架构： 通过 CronJob 事件源，每隔 3 个小时定时发送定时事件，将国内城市未来 3 天的天气信息，存储更新到表格存储提供 RESTful API 查询天气信息通过表格存储提供的通道服务，实现 TableStore 事件源通过 Borker/Trigger 事件驱动模型，订阅目标城市天气信息根据订阅收到的天气信息进行钉钉消息通知。如明天下雨，提示带伞等基于内容较多，我们分上、下两篇分别进行介绍： 上篇我们会主要介绍如何对接第三方的天气预报 API、定时同步并更新天气信息以及提供 RESTful API；下篇我们会主要介绍如何实现 TableStore 事件源、订阅天气信息并通过钉钉发送提醒通知；基于 Knative 实现天气服务-上篇对接高德开放平台天气预报 API查询天气的 API 有很多，这里我们选择高德开放平台提供的天气查询 API，使用简单、服务稳定，并且该天气预报 API 每天提供 100000 免费的调用量，支持国内 3500 多个区域的天气信息查询。另外高德开放平台，除了天气预报，还可以提供 IP 定位、搜索服务、路径规划等，感兴趣的也可以研究一下玩法。 登录高德开放平台: https://lbs.amap.com， 创建应用，获取 Key 即可： 获取Key之后，可以直接通过 url 访问：https://restapi.amap.com/v3/w...;用户 key>，返回天气信息数据如下： ...

KubeCon China 2019 大会上， Serverless 应用服务正式亮相，在 SOFAStack 工作坊吸引了百余名参与者同场体验。市场观察当我们回顾云计算的发展历程，会看到基础架构经历了从物理机到虚拟机，从虚拟机再到容器的演进过程。在这大势之下，应用架构也在同步演进，从单体过渡到多层，再到当下的微服务。在变化的背后，有一股持续的动力，它来自于三个不变的追求：提高资源利用率，优化开发运维体验，以及更好地支持业务发展。 目前， Serverless 已成为云原生社区关注的重点之一，它的发展也不例外。相比容器技术，Serverless 可以将资源管理的粒度更加细化，使开发者更快上手云原生，并且倡导事件驱动模型支持业务发展。从而帮助用户解决了资源管理复杂、低频业务资源占用等问题；实现面向资源使用，以取代面向资源分配的模式。根据 CNCF 在2018年底基于 2400 人的一份统计报告，已有 38% 的组织正在使用 Serverless 技术，相比 2017 同期增长了 22%。(数据来源：CNCF Survey) 图片来源：Gartner Report: China Summary Translation Evolution of Server Computing - VMs to Containers to Serverless - Which to Use When目前市场上，云厂商提供了多种 Serverless 产品和解决方案，大致可划分为： 函数计算服务：如 AWS Lambda，特点是以代码片段为单位运行，并对代码风格有一定要求。面向应用的 Serverless 服务：如 Knative，特点是基于容器服务，并提供了从代码包到镜像的构建能力。容器托管服务：如 AWS Fargate，特点是以容器镜像为单元运行，但用户仍需感知容器。从社区来看，CNCF 云原生基金会正通过 Serverless 工作组协调社区讨论并促进规范和标准的形成，工作组产出了 Serverless 白皮书和全景图等重要内容。其中，全景图将目前的生态划分为了平台层，框架层，工具链层和安全层这四个模块。 图片来源：https://landscape.cncf.io/落地挑战在交流过程中，我们发现 Serverless 很好地解决了客户的一些诉求：包括通过 0-1-0 的伸缩能力来提高资源时用率，降低成本；支持代码包出发，从而让客户无感化实现云原生，历史应用无需经过容器化改造；支持灵活的触发器配置，引导用户对应用进行事件驱动的改造，从而适应业务的高速发展等。这些优势，使得 Serverless 在小程序开发的场景下大放异彩。 同时，对于在企业级应用的生产环境落地 Serverless，各方也有了很多探索和突破。在本周刚结束的 KubeCon China 2019 大会上，Serverless 工作组会议也以此为话题展开了讨论。目前的核心挑战可归纳为： ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。Kubernetes v1.16 发布周期开始随着前段时间 Kubernetes v1.15 的发布，v1.16 的发布周期开始了。本次的发布周期一如往常，本月底增强功能冻结，下月底代码冻结，9 月初完善文档，计划在 9 月中发布 v1.16 版本。 其实按这个节奏看得话，大家如果需要维护生产中的 Kubernetes 集群的话，还是尽快测试验证并完成升级，以免所用版本 EOL，带来一些其他的问题。 Knative Serving v0.7.x 发布本周 Knative Serving 发布了 v0.7.1 版本，Knative 近期的开发还是比较活跃的。 需要注意的是若使用 v0.7.x 版本中新增的 serving.knative.dev/v1beta1 API 的话，则需要 Kubernetes v1.14 版本以上。具体原因请参考 #4533 Non-root 容器：在这个版本中所有发布的容器均以非 root 用户运行，这使得我们可以使用更严格的 PSP。 当然此版本中也包含一些破坏性变更，比如 status 字段废弃。 关于此版本更多的细节请参考 ReleaseNote Debian 10 buster 正式发布Debian 10 正式发布了，其实按一般的角度来看，Linux 的一个发行版发布不会出现在 K8S 生态周报中的。 但这里有个需要注意的点，对于使用此版本部署 Kubernetes 时，需要注意一下。此版本中使用的 systemd 版本是 241.5 而这个版本中有个对于使用 Kubernetes 而言值得注意的点。 ...

导语在万物皆可云的时代，你的应用甚至不需要服务器。云函数功能在各大云服务中均有提供，那么，如何用“无所不能”的 node.js 实现呢？ 一、什么是云函数？云函数是诞生于云服务的一个新名词，顾名思义，云函数就是在云端（即服务端）执行的函数。各个云函数相互独立，简单且目的单一，执行环境相互隔离。使用云函数时，开发者只需要关注业务代码本身，其它的诸如环境变量、计算资源等，均由云服务提供。 二、为什么需要云函数？程序员说不想买服务器，于是便有了云服务；程序员又说连 server 都不想写了，于是便有了云函数。 Serverless 架构通常我们的应用，都会有一个后台程序，它负责处理各种请求和业务逻辑，一般都需要跟网络、数据库等 I/O 打交道。而所谓的无服务器架构，就是把除了业务代码外的所有事情，都交给执行环境处理，开发者不需要知道 server 怎么跑起来，数据库的 api 怎么调用——一切交给外部，在“温室”里写代码即可。 FaaS而云函数，正是 serverless 架构得以实现的途径。我们的应用，将是一个个独立的函数组成，每一个函数里，是一个小粒度的业务逻辑单元。没有服务器，没有 server 程序，“函数即服务”（Functions as a Service）。 三、如何实现？由于本实现是应用在一个 CLI 工具里面的，函数声明在开发者的项目文件里，因而大致过程如下： 1、函数声明与存储声明我们的目标是让云函数的声明和一般的 js 函数没什么两样： module.exports = async function (ctx) { return 'hahha' }};由于云函数的执行通常伴随着接口的调用，所以应该要能支持声明 http 方法： module.exports = { method: 'POST', handler: async function (ctx) { return 'hahha' }};存储由于有 method 等配置，因此编译的时候，需要把上述声明文件 require 进来，此时，handler 字段是一个 Function 类型的对象。可以调用其 toString 方法，得到字符串类型的函数体： const f = require('./func.js');const method = f.method;const body = f.handler.toString();// async function (ctx) {// return 'hahha'// }有了字符串的函数体，存储就很简单了，直接存在数据库 string 类型的字段里即可。 ...

原文地址 近年来NODEJS发展迅速，很多工程师尤其是前端工程师，用NODEJS来开发一些后端应用。同时，研发效率和研发成本成为开发者关注的重点，对于一些基础常用功能，如何避免重复开发，成为大家关注的重点，而 Parse Server 就是抽象了常用功能的NODEJS开源项目。 首先，从整体上看看 Parse Server 提供了哪些基础功能: 用户的登录注册用户身份的认证数据存储 && 灵活查询文件存储实时查询消息推送缓存服务与云平台很好的对接自定义业务逻辑与Hook机制服务快速搭建默认情况下，Parse Server 使用的默认数据库是 MonogDB，所以需要提前安装该数据库。关于数据库的安装与使用不是本文的重点，暂且跳过。 const config = require('./config');const app = express();var api = new ParseServer({ databaseURI: config.databaseURI, cloud: './cloud/main.js', appId: config.appId, masterKey: config.masterKey, // push: { ... }, // See the Push wiki page // filesAdapter: ..., // 对应不同云厂商的 FilesAdapter // javascriptKey: config.javascriptKey, // js客户端认证 liveQuery: { // 建立websocket链接，实现实时通信 classNames: ['Sdtuent'] }});var dashboard = new ParseDashboard({ "apps": [ { "serverURL": "http://localhost:1337/parse", "appId": config.appId, "masterKey": config.masterKey, "appName": "test" }, ]});// Serve the Parse API at /parse URL prefixapp.use('/parse', api);app.use('/dashboard', dashboard);const port = 1337;const httpServer = http.createServer(app);httpServer.listen(port, function() { console.log('parse-server-example running on port ' + port + '.');});var parseLiveQueryServer = ParseServer.createLiveQueryServer(httpServer);通过上述少量的代码，快速完成服务的搭建，/parse 是API的前缀，/dashboard 是后台的页面路由前缀，这样就可以快速使用 Parse Server 提供的各种功能。 ...

前言Knative Eventing 0.7 版本已经于 6 月 26 号正式发布。本次发布主要围绕重构 Channel 特性展开。本篇文章重点解读了这些特性，并且以此展望一下 Knative Eventing 后续版本的发展。 新特性重构 Channel作为 Eventing v0.7 版本最大的特性， 重构了 Channel 的设计：为每个 Channel 单独创建了CRD资源。在 Eventing v0.6 版本中， Channel 是通过 provisioner 模式实现的。以 kafka Channel 为例： apiVersion: eventing.knative.dev/v1alpha1 kind: Channel metadata: name: my-kafka-channel spec: provisioner: apiVersion: eventing.knative.dev/v1alpha1 kind: ClusterChannelProvisioner name: kafka这里是通过指定名称为 kafka 的 ClusterChannelProvisioner。这样的实现方式存在以下问题： Channel 中只通过一个 provisioner 字段就设置了包含的所有属性。每一个Channel Controller都会监听到所有的资源，再进行过滤。Event Source中的实现方式更符合规范，即每个Source 单独的CRD和Controller，值得借鉴。针对这些之前存在的不合理的设计， 在Eventing v0.7版本中，为每个Channel 单独创建了CRD资源，改造涉及如下： InMemoryChannel CRD 替换 in-memory ClusterChannelProvisionerKafkaChannel CRD 替换 kafka ClusterChannelProvisionerNatssChannel CRD 替换 natss ClusterChannelProvisioner改造后的 kafka Channel 示例如下： ...

阿里妹导读：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 无服务器平台提供的功能：（摘自 AWS 官网） AWS 的整套 Serverless 方案非常完善，但是没有解决存量应用如何迁移到 Serverless 架构的问题。仅仅是针对新开发的应用，建议用户使用 FaaS 方式开发，才有机会转向 Serverless 架构。笔者认为，要将 Serverless 架构大规模推广，必须要能有针对存量业务的解决方案。 Serverless 对云计算的价值云计算，归根结底是一种 IT 服务提供模式，不论是公共云还是专有云（以 IT 设备的归属不同分类），其本质都是帮助 IT 的最终使用者随时随地，并且简便快速地，获取 IT 服务，目前，IaaS、PaaS 都已经做到了按需付费，PaaS 甚至做到了按请求付费，如 DB，CACHE，MQ 等，但是 IaaS 的付费粒度仍然是时间维度，最快按照小时付费，以分钟来交付。 ...

Serverless 话题涉及范围极广，几乎包含了代码管理、测试、发布、运维和扩容等与应用生命周期关联的所有环节。AWS Lambda 是 Serverless 领域的标志性产品，但如果将其应用于核心业务，可能会遇到以下难题：（仅代表作者个人观点）首度揭秘：  要求用户以 Function 为单位进行开发，全新的开发框架，云厂商强绑定，社区主流技术栈迁移成本高；Function 启动速度要足够快，毫秒级或者秒级，这个限制对适用场景有很强的约束；Function 之间的调用通过 API Gateway，响应时间更长。本文将介绍阿里云中间件团队在探索 Serverless 过程中的思考以及正在做的事，目的是尽可能让开发者少改代码，甚至不改代码，就能具备 AWS Lambda 的技术优势。 Cloud Service Engine 云服务引擎（以下简称CSE），是阿里云中间件团队开发的面向通用 Serverless 计算的中间件产品，目的是具备 AWS Lambda 的各种优势，同时可以解决用户在使用 AWS Lambda 时遇到的难题。 什么是 ServerlessAWS 对 Serverless 定义是：（摘自 AWS 官网） AWS 无服务器平台提供的功能：（摘自 AWS 官网） AWS 的整套 Serverless 方案非常完善，但是没有解决存量应用如何迁移到 Serverless 架构的问题。仅仅是针对新开发的应用，建议用户使用 FaaS 方式开发，才有机会转向 Serverless 架构。笔者认为，要将 Serverless 架构大规模推广，必须要能有针对存量业务的解决方案。 Serverless 对云计算的价值云计算，归根结底是一种 IT 服务提供模式，不论是公共云还是专有云（以IT设备的归属不同分类），其本质都是帮助 IT 的最终使用者随时随地，并且简便快速地，获取 IT 服务，目前，IaaS、PaaS都已经做到了按需付费，PaaS 甚至做到了按请求付费，如DB，CACHE，MQ等，但是 IaaS 的付费粒度仍然是时间维度，最快按照小时付费，以分钟来交付。 因此，当下的云计算场景，应用的开发维护方式相比传统 IDC 时代的开发维护，差别还不是很大。但 AWS Lambda 提供了一种全新的开发维护方式，用户只需要写好业务代码，提交到云上，所有和机器容量、可用性、机器为单位的运维工作可以全部交给了云平台，这种模式极大的释放了云的弹性价值，真正做到了按需付费。 ...

摘要： Knative Serving以Kubernetes和Istio为基础，支持无服务器应用程序和函数的部署并提供服务。我们从部署一个HelloWorld示例入手来分析Knative Serving的代码细节。概念先知官方给出的这几个资源的关系图还是比较清晰的： 1.Service: 自动管理工作负载整个生命周期。负责创建route,configuration以及每个service更新的revision。通过Service可以指定路由流量使用最新的revision，还是固定的revision。2.Route：负责映射网络端点到一个或多个revision。可以通过多种方式管理流量。包括灰度流量和重命名路由。3.Configuration:负责保持deployment的期望状态，提供了代码和配置之间清晰的分离，并遵循应用开发的12要素。修改一次Configuration产生一个revision。4.Revision：Revision资源是对工作负载进行的每个修改的代码和配置的时间点快照。Revision是不可变对象，可以长期保留。 看一个简单的示例我们开始运行官方hello-world示例，看看会发生什么事情： apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata: name: helloworld-go namespace: defaultspec: runLatest: // RunLatest defines a simple Service. It will automatically configure a route that keeps the latest ready revision from the supplied configuration running. configuration: revisionTemplate: spec: container: image: registry.cn-shanghai.aliyuncs.com/larus/helloworld-go env: - name: TARGET value: "Go Sample v1"查看 knative-ingressgateway： kubectl get svc knative-ingressgateway -n istio-system 查看服务访问：DOMAIN kubectl get ksvc helloworld-go --output=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain 这里直接使用cluster ip即可访问 ...

本文归纳于微服务与云原生 https://github.com/wx-chevalier/Backend-Series系列文章，其相关的参考资料声明于 Awesome Serverless List。 Serverless????Node.js Puppeteer 渗透测试爬虫实践参考 CNCF 的定义，Serverless 是指构建和运行不需要服务器管理的应用程序的概念；而 AWS 官方对于 Serverless 的介绍是：服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如 AWS Lambda 服务），客户端逻辑和服务托管远程过程调用的组合。 Serverless 目前主要的落地形式为 BaaS 与 FaaS。BaaS 后端即服务，即是一些后端云服务，比如云数据库、对象存储、消息队列等。利用 BaaS，可以极大简化我们的应用开发难度。FaaS 函数即服务，则是暂存容器中运行的自定义代码，函数是无服务器架构中抽象语言运行时的最小单位。在 FaaS 中，用户主要为函数的运行时间付费，而不需要关心 CPU 或 RAM 或任何其他资源及其运维的负担。 参考 BaaS 与 FaaS 的定义，我们可以知道 Serverless 的主要特点有： 事件驱动：函数在 FaaS 平台中，需要通过一系列的事件来驱动函数执行。无状态：因为每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。如果要共享数据，则只能通过第三方服务，比如 Redis 等。无运维：使用 Serverless 我们不需要关心服务器，不需要关心运维。这也是 Serverless 思想的核心。按实际使用计费：使用 Serverless 成本很低，因为我们只需要为每次函数的运行付费。函数不运行，则不花钱，也不会浪费服务器资源。这些特征的本质，是用户对于云端应用开发，乃至于所谓云原生应用中的用户友好与低心智负担方向演讲的最直接途径，而这种简单、经济、可信赖的期许，也是云计算的初心。当然 Serverless 并不拘泥于 Function，而是应该多种部署形态并存，譬如以应用方式部署，则是遵循单一职责原则，但是能够触发多个事件；也可以在容器级别部署，能够包含任意语言、任意运行时，譬如 Knative 这样的解法。在微服务与云原生/Serverless 一节中我们也讨论了更多的 Serverless 落地模式。 前端视角的 Serverless在现代 Web 开发基础与工程实践 https://github.com/wx-chevalier/Web-Series 系列的前言中，我们也讨论了 Web 技术与生态经历了模板渲染、前后端分离与单页应用，工程化与微前端，大前端与 Serverless 这三个不同的阶段。自然从前端的视角来看，Serverless 也赋予了前端更多的自由与可能性，在服务端渲染，小程序开发的简单服务端支持，包括 BFF 接口聚合等方面都有很多的空间。 ...

这几天基于支持HTML5无感认证的ServerLess平台开发了一款博客、门户网站等web平台常用的PV统计工具：page-counter 。主要用到的技术是js+webpack。 回首看来，解决了以下几个比较有意思的问题： 如何设计代码，用统一的方式支持多个ServerLess平台？如何架构项目，使得其支持CDN和npm两种方式引入？如何精简源码，源码大小控制在4kb？如何借助webpack分离生产和测试环境？源码地址：https://github.com/dongyuanxin/page-counter npm地址：https://www.npmjs.com/package/page-counter 如果有兴趣的同学，欢迎在阅读完本文后一起接入其他平台的开发； 觉得不错的同学，欢迎给个Star哦 。 ????查看全部文章目录 / 阅读原文???? 项目目录 如上图所示，bin/backend 目录是暂时没用的。几个比较重要的目录功能说明： build/ : webpack的配置文件，分别是公共配置、开发模式配置、生产模式配置dist/ index.template.html: 开发模式下配合webpack的html模板文件page-counter.min.js: 打包后的page-counter内容，供CDN引入page-counter.bomb-1.6.7.min.js：我手动修改并且打包的Bomb平台源码examples/ : gh-pages页面，请看此页面deploy.sh : gh-pages部署脚本，支持ssh和https协议index.js : npm的入口文件index.build.js : CDN打包入口文件src/ : serverless/ : 暴露不同平台的统一接口config.js : 自动读取全局配置utils.js : 常用函数方法抽象接口：支持多Serverless平台src/serverless/interface.js 中定义了不同平台的类的公共父类。虽然js不支持抽象接口，但是也可以通过抛出错误来实现： export default class ServerLessInterface { constructor () {} ACL () { throw new Error('Interface method "ACL" must be rewritten') } setData () { throw new Error('Interface method "setData" must be rewritten') } count () { throw new Error('Interface method "count" must be rewritten') }}而 leancloud.js 、bomb.js 等不同平台的类都要实现这个接口中的这3个方法。然后通过 src/serverless/index.js 统一暴露出去： ...

摘要： 在 Knative Eventing 中创建 Broker 时，如果不指定 provisioner， 系统会自动创建默认的 provisioner， 那么这个机制是如何实现的呢？ 本文基于 Knative Eventing 0.5 版本，介绍了这个实现机制。场景通常的在创建Broker时，我们需要通过 spec.ChannelTemplate 指定使用某个具体的 Channel Provisioner。例如这样的Broker: apiVersion: eventing.knative.dev/v1alpha1kind: Brokermetadata: name: pubsub-channelspec: channelTemplate: provisioner: apiVersion: eventing.knative.dev/v1alpha1 kind: ClusterChannelProvisioner name: gcp-pubsub这里通过spec.ChannelTemplate 指定了名称为gcp-pubsub的provisioner。那么我们也遇到过这样的Broker： apiVersion: eventing.knative.dev/v1alpha1kind: Brokermetadata: name: default并没有指定使用某个具体的 channel, 但创建完Broker之后会发现已经创建出来了Channel: apiVersion: eventing.knative.dev/v1alpha1kind: Channelmetadata: ... name: default-broker-8ml79 namespace: default ownerReferences: - apiVersion: eventing.knative.dev/v1alpha1 blockOwnerDeletion: true controller: true kind: Broker name: default uid: 2e4c3332-6755-11e9-a81f-00163f005e02spec: provisioner: apiVersion: eventing.knative.dev/v1alpha1 kind: ClusterChannelProvisioner name: in-memory...分析我们知道 Broker创建之后，会通过 reconcile controller 会创建相应的Channel, 也就是下面这段代码： ...

首先介绍下在本文出现的几个比较重要的概念： 函数计算（Function Compute）: 函数计算是一个事件驱动的服务，通过函数计算，用户无需管理服务器等运行情况，只需编写代码并上传。函数计算准备计算资源，并以弹性伸缩的方式运行用户代码，而用户只需根据实际代码运行所消耗的资源进行付费。函数计算更多信息 参考。Fun: Fun 是一个用于支持 Serverless 应用部署的工具，能帮助您便捷地管理函数计算、API 网关、日志服务等资源。它通过一个资源配置文件（template.yml），协助您进行开发、构建、部署操作。Fun 的更多文档 参考。2.0 版本的 Fun，在部署这一块做了很多努力，并提供了比较完善的功能，能够做到将云资源方便、平滑地部署到云端。但该版本，在本地开发上的体验，还有较多的工作要做。于是，我们决定推出 Fun Init 弥补这一处短板。Fun Init: Fun Init 作为 Fun 的一个子命令存在，只要 Fun 的版本大于等于 2.7.0，即可以直接通过 fun init 命令使用。Fun Init 工具可以根据指定的模板快速的创建函数计算应用，快速体验和开发函数计算相关业务。官方会提供常用的模板，用户也可以自定自己的模板。背景阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，并提供日志查询、性能监控、报警等功能。借助于函数计算，您可以快速构建任何类型的应用和服务，无需管理和运维。而且，您只需要为代码实际运行所消耗的资源付费，代码未运行则不产生费用。 当我们写 nodejs 函数时，函数往往会依赖很多第三方依赖，这样导致函数代码少则几十兆，多则上百兆。代码包太大，会有如下问题： 可能会导致没法成功上传代码到函数计算服务，因为函数计算服务对代码包大小是有限制的，压缩后最大不能超过 50 MB，解压后最大不能超过 250 MB会导致冷启动时间是变大，因为下载代码的过程变大了每次更新代码时间变大另外，函数计算目前只支持 nodejs8 和 nodejs6 这两个版本，这两版本不支持 es6 语法，但是我们可能已经写习惯了 es6 语法该怎么办呢？ 熟悉 nodejs 的同学应该知道，项目工程化管理工具 webpack，我们完全可以通过 webpack 将 es6 代码编译成 es5，并且剪切打包压缩成一个 js 文件，然后将该 js 文件上传到函数计算中运行。 快速开始我这里提供了一个 fun 模板，帮助快速搭建一个函数计算 nodejs 项目骨架，支持 es6 代码编译成 es5，并且剪切打包压缩成一个 js 文件，然后将该 js 文件上传到函数计算中运行。操作作步骤如下： ...

导读：近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is Serverless》一书的部分内容，可以说是对Serverless科普与观察的上佳素材。在了解了何为Serverless，各种服务组件之后，如何将服务组件组合成完整的应用程序？ 基于Serverless开发的应用架构什么样子？与传统非Serverless应用程序架构相比，Serverless有哪些优势？本文将回答这些问题。原著：《What is serverless : understand the latest advances in cloud and service-based architecture》作者：Mike Roberts & John Chapin译文来源：深入浅出谈架构（ID：deep-easy-arch）译者：灵雀云邵明岐假设有这么一个应用程序，它是一个支持多用户的手机游戏，具有以下高级要求：友好的移动端交互界面具备用户管理和身份验证有一些基本的业务逻辑，比如游戏排行榜，历史记录等我们暂时忽略游戏中可能会遇到的其他功能，毕竟我们的目的不是实际开发一个游戏，而是将Serverless程序架构与传统的非serverless架构进行比较。传统非Serverless架构 根据上面的要求，传统非Serverless架构看起来应该是这样的：Native Mobile App 是iOS或者安卓客户端。Java Application Server是Java代码编写的应用逻辑，运行在Tomcat或者JBoss这类应用服务器里面。数据存储在关系型数据库，比如Mysql里面。在这个架构中，移动应用程序负责呈现游戏界面并处理来自用户的输入，但它将大多数实际逻辑删除到后端，从代码的角度来看，移动应用程序简单轻便，它使用HTTP调用后端Java应用程序提供的不同API。用户管理、身份验证和各种游戏操作都使用Java应用程序代码进行封装， 后端应用程序还与单个关系数据库交互，以便维护正在进行的游戏的状态，并存储已完成游戏的结果。为什么要改变架构？这个简单的架构似乎符合我们的要求，那么为什么对它做改进呢？ 关键在于未来开发和运维方面带来的一系列潜在的挑战和陷阱。在构建游戏时，需要具备iOS和Java开发方面的专业知识，以及配置，部署和操作Java应用程序服务器的专业知识，还需要配置和操作关系数据库服务器。 除了应用服务器和数据库，也需要配置和运行各自的主机，无论这些系统是基于容器还是直接在虚拟或物理硬件上运行。 我们还需要通过配置路由策略，访问控制列表等，来确保系统组件之间以及用户端和服务端之间的网络连通性。有了上面这些，我们仍然只是提供最基本的让游戏可用的环境还没有涉及安全性、可扩展性或高可用性，这些都是现代生产系统的关键方面。 最重要的是，即使在简单的体系结构中，也存在许多固有的复杂性，用来满足现实世界各种各样的需求。 构建系统并不难，但是当我们修复错误，添加功能或尝试快速构建新的创新想法时，所有这些复杂性将会变成强大的阻力。如何改变？现在已经发现了传统架构的一些挑战，如何改变它？ 让我们看看如何能够满足高级需求，并使用Serverless架构模式和组件来解决传统方法的一些挑战。在之前的文章已经说过了，Serverless组件可以分为两类，BaaS和FaaS。 考虑到游戏的要求，其中一些可以通过BaaS组件解决，一些可以通过FaaS组件解决。Serverless 架构基于Serverless构建的游戏，架构看起来应该是下图这个样子的：虽然用户界面仍是移动应用程序的一部分，需要自己通过代码来实现，但用户身份验证和管理可由AWS Cognito等BaaS服务处理，这些服务可以直接从移动应用程序调用，以处理注册和身份验证等面向用户的功能，其他后端组件可以使用相同的BaaS来检索用户信息。现在由BaaS处理用户管理和身份验证，后端Java应用程序的逻辑被简化了， 可以使用另一个组件AWS API Gateway，以安全、可扩展的方式来处理移动应用程序和后端游戏逻辑之间的HTTP请求。 然后可以将每个不同功能的操作封装在FaaS函数中。这些后端FaaS功能可以与像DynamoDB这样的NoSQL数据库进行交互，以存储游戏的状态。 实际上，一个重大变化是不再在服务器端应用程序代码中存储任何会话状态，而是将所有会话状态保存到NoSQL存储中。 虽然这可能看起来很麻烦，但它有助于扩展。移动应用程序可以无缝访问同一个数据库，以检索过去的结果和排行榜数据。 这允许我们将一些业务逻辑移动到客户端实现，而不是将其放到到后端实现。Serverless架构优势这种新的Serverless架构看起来很复杂，而且它比传统架构需要更多的组件，但是，由于我们使用完全托管的Serverless组件，已经消灭了很多因为管理应用程序基础设施和底层系统而带来的挑战。我们编写的代码现在几乎完全集中在游戏独特的业务逻辑上，更重要的是，组件已经解耦和分离，因此，可以非常快速地将它们切换出来或添加新逻辑，而不会出现非无服务器架构中固有的阻力。扩展，高可用性和安全性也有所提升，这意味着随着我们的游戏越来越流行，不需要担心购买功能更强大的服务器，也不需要担心数据库是否会崩溃，或者排查防火墙配置故障。简而言之，我们降低了制作游戏的人工成本，以及运行游戏的风险和计算成本，它的所有组成部分都将灵活扩展。 当我们有一些新的想法，交付期会大大缩短，可以开始获得反馈并更快迭代。云计算的基础设施外包带来五大好处：降低人工成本、降低风险、降低基础设施成本、扩展性、交付时间 。Serverless 同样也有这五大优点， 前四个都或多或少是关于成本节约的，这就是Serverless最为人所知的：如何以更低的成本做以前做过的同样的事情。但是，对我们来说，节省成本并不是无服务器最令人兴奋的部分，最大的好处是，它减少了从新的想法到实施上线的时间，换句话说，它能够让你更快地创新。降低人工成本我们在之前说过，Serverless本质上不再需要关心自己的服务器和进程 ，只需要关心应用程序的业务逻辑和状态，所有其他不必要的工作都交给平台来处理。这里的第一个明显好处是运维工作量减少， 您不再管理操作系统，补丁级别，数据库版本升级等。如果您正在使用BaaS数据库，消息总线或对象存储，那么祝贺你，这些基础架构也都不要你来运维。通过其他BaaS服务，对于节省人工成本是比较直观的，自己开发的逻辑更少了。 我们已经多次讨论过身份验证的BaaS服务，其中最大的好处是可以使用较少的代码来定义开发、测试、部署和运营，所有这些都减少了工程师时间成本，另一个例子是像Mailgun这样的第三方邮件 BaaS 服务，它消除了处理电子邮件发送和接收的大部分复杂工作。与传统方法相比，FaaS还具有显著的劳动力成本优势。 使用FaaS进行软件开发得以简化，因为大部分基础架构代码已移至平台。 这里的一个例子是HTTP API服务的开发，这里所有的HTTP级请求和响应处理都是由API网关完成的。使用FaaS进行部署更容易，因为我们只是上传打包成Zip格式(如果是 JS或者Python脚本语言)的基本代码，或者如果是Java的话，则上传普通的JAR文件，没有要管理的Puppet，Chef，Ansible或Docker配置。其他类型的操作活动也变得更加简单，例如，由于不再关注“永远在线”服务器进程，因此可以将监控限制为更多面向应用程序的指标。 这些是统计信息，例如执行持续时间和面向客户的指标，而不是可用磁盘空间或CPU使用率。降低风险当考虑软件应用风险时，我们经常考虑对故障和宕机的敏感程度，我们的团队负责管理的不同类型的系统或组件的数量越多，发生问题的风险就越大。我们可以不是自己管理这些系统，而是像之前描述的那样，让“外包”系统来解决这些问题。虽然整体而言仍然面临应用程序发生故障的风险，但我们选择以不同的方式管理风险–我们现在依靠其他人的专业知识来解决其中的一些故障，而不是自己修复它们。这通常来说是一个好主意，因为应用的技术栈中，一些技术是平时很少发生变更的，当它们发生故障时，修复时间和难度都不确定。通过Serverless，我们可以显著减少直接操作的技术栈数量，那些我们仍在自己管理的技术，通常是我们非常熟悉并且频繁变更的，因此我们更有能力在失败时自信地处理失败。例如，管理分布式NoSQL数据库。 一旦安装了组件，节点发生中的故障可能相对罕见，但是当它发生故障时，会发生什么？ 您的团队是否具备快速有效地诊断，修复和恢复问题的专业知识？ 常常没有。 相反，团队可以选择使用Serverless 的NoSQL数据库服务，例如Amazon DynamoDB， 虽然DynamoDB中的中断偶尔会发生，但由于亚马逊拥有致力于此特定服务的整个团队，因此它们发生故障的次数更少，并且能够更快的恢复。因此，我们说当使用Serverless技术时，风险会降低，因为组件的预期宕机时间会减少，并且修复它们的时间会更少。降低资源投入成本通常，当运行应用程序时，我们必须弄清楚它们将运行的底层主机类型和数量。 例如，数据库服务器需要多少内存和CPU？ 需要多少个不同的实例来支持扩展？ 或者如何支持高可用性（HA）？一旦规划了我们需要的主机或资源，就可以分配应用程序的哪些部分将在哪些资源上运行。 最后，一旦我们开始准备部署应用程序，就需要实际获得我们想要的主机，这是环境配置。整个环境配置过程很复杂，我们很少提前知道我们的资源要求是什么，因此高估了我们的计划，这称为过度配置，这实际上是正确的做法：拥有备用容量并保持应用程序运行比在负载下降低更好。对于某些类型的组件（如数据库），可能很难在以后扩展，因此可能希望通过过度配置，来承载未来预期的负载。过度供应意味着我们总是为满足处理峰值预期负载所需的容量付费，即使我们的应用程序没有遇到负载也是如此。最极端的情况是，我们的应用程序处于空闲状态时，我们正在为服务器付费，而事实上它并没有做任何有用的事情。但即使我们的应用程序处于活动状态，我们也不希望主机得到充分利用。相反，我们希望留下一些空间，以应对意外的负载峰值。无服务器给这个领域带来的巨大好处是不需要计划，分配或配置资源，让服务精确地提供我们在任何时间点所需的容量，如果我们没有任何负载，那么不需要任何计算资源，也不会支付任何费用。 如果我们只有1 GB的数据，我们不需要容量来存储100 GB。我们相信当需要时，服务将按需扩展，并且这同样适用于FaaS和BaaS服务。除了消除资源分配带来的问题，无服务器还使成本更加高效。对于负载不一样的各种应用程序，我们将通过使用无服务器来节省资源成本。 例如，如果我们的应用程序每小时只运行5分钟，我们只需支付每小时5分钟，而不是整个60分钟。 此外，良好的无服务器产品将具有非常精确的使用增量; 例如，AWS Lambda按100毫秒的使用时间收费，比EC2的每小时计费精确36,000倍。在现代非 Serverless 应用程序中，我们通过自动伸缩等技术获得了一些收益，但是，这些方法通常不如无服务器产品那么精确，并且通常无法自动扩展数据库。提高扩展性所有这些资源成本优势都来自于这样一个事实，即Serverless服务可以精确地满足我们的需求。那么如何才能真正实现这种扩展呢？ 我们需要设置自动缩放组吗？ 监控流程？ 没有！ 事实上，缩放是自动完成的，不费力气。以AWS Lambda为例。 当平台收到第一个触发函数事件时，它会启动一个容器来运行代码，如果在收到另一个事件时仍在处理此事件，则平台将启动代码的第二个实例以处理第二个事件。 这种自动、零管理、水平扩展将持续到Lambda有足够的代码实例来处理负载。一个特别好的方面是AWS仍然只会根据你代码执行的时间收取费用，无论它有多少个容器要启动。例如，假设所有事件的总执行时间相同，在一个容器中按顺序调用Lambda 100的成本与在100个不同容器中同时调用Lambda 100次的成本完全相同。减少交付周期通过采用Serverless技术，可以带来显著的成本节省。康卡斯特有线电视公司首席技术官Sree Kotay在2016年8月AWS峰会上说：他不是在谈论Serverless，他在谈论康卡斯特如何从各种其他基础设施外包中获益匪浅，从“本地”转向云计算：经历了云和敏捷的这一旅程，过去五年我们已经实现了收益，而且这些收益都是围绕成本和规模进行的，它们是关键且重要的，但有趣的是它们并不是最引人注目的，最关键部分是这真的改变了你的创新周期，它从根本上改变了你对产品开发的看法。Sot Kotay复制代码我们要提出的一点是，一家大公司的首席技术官说，成本和规模对他来说并不是最重要的，最重要的是创新。 那么Serverless如何在这方面提供帮助呢？Adrian Cockcroft（AWS云架构战略副总裁，Netflix前云架构师）谈到：我们开始看到开发应用程序的时间越来越短，小型开发团队在短短几天内从头开始构建生产就绪的应用程序。 他们使用简短的功能和事件将强大的API驱动的数据存储和服务粘合在一起。 已完成的应用程序已具有高可用性和可扩展性，高利用率，低成本和快速部署。-Adrian Cockcroft复制代码在过去几年中，我们看到通过持续交付和自动化测试以及Docker等技术改进开发的增量周期时间取得了很大进展。 这些技术很棒，但只有在设置和稳定后才能实现。 对于真正蓬勃发展的创新而言，缩短周期时间是不够的，您还需要更短的交付周期–从新产品或功能的概念化到以最小的可行方式部署到生产环境的时间。由于Serverless消除了在生产中大规模构建，部署和运行应用程序的大量附带复杂性，因此它为我们提供了巨大的杠杆作用，以至于软件交付方式可以颠倒过来。通过正确的组织支持，创新和“精益创业”风格，实验可以成为所有企业的默认工作方式，而不仅仅是为初创公司或“黑客日”保留的东西。这不仅仅是一种理论。 除了Adrian的的观点之外，我们看到相对缺乏经验的工程师完成项目通常需要几个月的时间，并需要更多资深工程师的帮助。 相反，使用Serverless，他们能够在几天内基本上无需帮助地实施项目。这就是为什么对Serverless感到非常兴奋：除了节省所有成本之外，还可以释放他们的能力，让他们专注于让产品与众不同的地方。 ...

本文主要介绍 Serverless 应用的网络环境以及 Serverless 应用容器内的环境，了解背景知识以及基本的运维知识后可以利用 Webshell 完成基本的运维需求。Webshell 简介用户可以通过阿里云控制台直接获取 ECS 的 Shell，从而完成自己的运维需求。如果 ECS 内开启了 SSH 服务，且 ECS 存在弹性公网 IP，那么用户也可以在本地通过 SSH 服务获取 ECS 的 Shell 完成运维需求。由于 EDAS Serverless 特殊的架构以及网络环境，用户暂时无法直接从本地通过 SSH 服务获取应用容器的 Shell。在 Serverless 场景中，容器是一个暂态的、供应用运行的环境，一般来说不需要进入运维。为了方便用户进行线上问题定位排查，EDAS 在控制台提供了一个简单的Webshell，供用户查看调试自己的容器。EDAS 默认给出的 Jar War 类型应用的容器基础镜像主要是面向应用运行时，不带有冗余的排查工具，因此对运维人员可能不够友好。对于用户自身的镜像，不需要镜像中启动 SSH 服务，只需要带有可执行的/bin/bash即可。用户自己的镜像可以带上必须的运维工具方便排查。目前 Webshell 不支持 Windows 镜像。EDAS 应用节点的网络环境EDAS 应用节点处于用户自己购买的阿里云 VPC 内。在 EDAS 中，还额外提供了一层中间件服务调用隔离的手段：EDAS 命名空间。EDAS 命名空间与 VPC 内的 VSWITCH 是绑定关系，一个 EDAS 命名空间对应一个 VSWITCH，一个 VSWITCH 可以对应多个EDAS命名空间。VPC 的原理以及基本的产品情况可以在阿里云VPC官方文档了解。简单来讲，VPC 内的 IP 地址为局域网地址，不同 VPC 内的2层以上数据包无法路由到目的地。EDAS 命名空间主要做中间件逻辑隔离，不同命名空间内的应用在中间件层面是隔离的，如服务发现以及配置下发等。由于 VPC 的产品特性以及当前的 EDAS Serverless 的产品特性，容器无法直接触达 VPC 外的服务（阿里云产品除外，如 OSS、镜像服务等）。在没有额外配置的情况下，你的容器运行在网络“孤岛”环境。了解了基本的网络情况，现在可以明白为什么用户无法直接触达自己的容器了。容器内需要访问公网服务，可以通过购买 NAT，并配置 VPC 内 VSWITCH 的SNAT规则即可，详见阿里云Serverless文档。SNAT规则可以让VPC内地址访问公网地址，从而使用公网暴露的服务，获取到公网的资源。EDAS 构建的镜像的方案基于阿里云容器镜像服务，EDAS 集成了为用户构建以及管理镜像的功能。用于构建的基础镜像为centos:7，在此基础上为用户配置好了时区、语言与编码方式、Open JDK 运行环境。容器存在的目的是为了让应用运行起来，EDAS 不可能以占用所有用户运行时资源为代价，集成过多的工具，对于容器内工具有需求的用户，建议自行构建镜像，或者按需从 OSS 拉取。常见的分析手段线上容器的运维一般是不必要的。如果你确定需要进入容器进行运维，请务必了解你的操作对线上业务的风险：对于单点应用，你的行为可能导致容器 OOM，从而导致分钟级别的业务中断，而对于多点部署的业务，上述现象可能造成业务秒级中断。诊断 EDAS 应用一般从这几个方面入手：常规检查，上传搜集的日志。常规检查常规检查的方法比较多，以 Java 应用为例，一般是检查进程、线程以及 JVM 的健康状态。首先执行命令ps -ef | grep java检查你的 Java 进程是否还存在。这里必须特别说明的是，容器内一般需要使用主进程启动你的应用，这样一旦你的应用被kill掉，容器也会退出，EDAS 会将退出的容器重新启动，防止业务中断。如果进程不见了，可以执行命令dmesg | grep -i kill查看OOM相关日志。如果存在日志，那么说明你的应用进程被 kill 掉了，接着检查工作目录下hs_err_pid{PID}.log日志文件，定位具体的原因。Java 类型应用的在线分析可以使用阿里巴巴开源软件 Arthas 解决，建议在测试镜像中集成Arthas工具进行常规诊断。Arthas可以很方便地实时查看类加载情况，观察方法出入参，环境变量等。# 接入arthas，需求打通公网wget https://alibaba.github.io/arthas/arthas-boot.jarjava -jar arthas-boot.jar对于网络层的诊断，在了解上述EDAS应用节点网络情况的前提下，一般可以通过curl -v {host/ip} {port}检查域名解析以及连通性，通过tcpdump抓包观察分析网络调用情况。日志上传解决方案受限于容器内工具的匮乏，比较推荐的方案是将容器内搜集到的日志上传到云端，然后下载到本地进行分析。目前，EDAS 暂时没有提供容器内日志的下载功能，这里给出一种基于阿里云 OSS 服务的解决方案。OSS 打通了阿里云生态几乎所有的网络环境，你几乎可以在任何网络环境下上传以及下载 OSS 上的文件。首先在容器内部安装OSS命令行工具。以64位centos系统，root下没有打通公网的情况下可以选择在本地下载，然后将这个文件上传到oss，然后取oss的vpc内地址进行下载wget http://gosspublic.alicdn.com/...chmod 755 ossutil64* 然后配置你的 OSS 命令行工具，附上当前 region VPC 内的endpoint（VPC内的上传不要求打通公网，也不消耗公网带宽流量，更加经济），填写用于接收上传文件的账号的AK/SK，然后查看已经创建的Bucket，来检查你的OSS服务是否可用。请先确保账号（不必是当前账号，任意开通阿里云oss服务的账号均可）已开通 OSS 服务按照提示配置你的 AK SK endpoint信息，ststoken 不需要填写./ossutil64 config检查账号是否可用，如果报错则配置错误，如果没有bucket，则建议前往oss控制台创建，命令行工具也支持创建./ossutil64 ls这里创建一个模拟的日志文件，用于上传echo “Hello” > edas-app.log./ossutil64 cp edas-app.log {bucket-address，例如：oss://test-bucket，可以从上述命令"./ossutil64 ls"中查看}* 从 OSS 控制台或其他工具中找到你的日志文件，下载到本地，并使用你熟悉的工具进行分析。本文作者：落语（阿里云智能中间件技术开发工程师，负责分布式应用服务 EDAS 的开发和维护。）<hr>本文作者：中间件小哥阅读原文 ...

最近尝试将应用的页面 JS 错误报警功能通过 Serverless 来实现。本文主要介绍一下具体实现过程，以及遇到的一些问题。报警功能的需求也很简单，就是定时（如每隔 1 分钟）去读取 ARMS 的错误日志，如果有错误日志，则通过钉钉消息发送错误详情进行报警。在这之前，我通过定时任务实现了该功能。从成本上来说，这种方案就需要单独申请一台服务器资源；而且定时任务只在对应的时间才执行，这件意味着，服务器有很长的时间都是空闲的，这就造成了资源的浪费。而使用 Serverless，就不需要再申请服务器，函数只需要在需要的时候执行，这就大大节省了成本。总的来说，我觉得函数计算的优势就是：对于开发者，只需要关系业务逻辑的实现，不需要关心代码所运行的环境、硬件资源、以及运维节省成本通过 Serverless 实现前端日志报警，依赖的云服务是阿里云函数计算，依赖的其他工具还有：函数计算的命令行工具 fun，用于本地调试、部署函数函数计算的可交互式工具 fcli，用于本地测试阿里云 JS SDK aliyun-sdk-js，用于读取 SLS 日志，ARMS 的日志是存储在 SLS 中的编程语言使用 Node.js安装和配置 fun初次使用需要先安装 fun$ npm install @alicloud/fun -g安装完成之后，需要通过 fun config 配置一下账号信息 Aliyun Account ID Aliyun Access Key ID Aliyun Secret Access Key 以及默认的地域。地域这里有个需要注意的是，如果需要使用 SLS 记录函数日志，则需要 SLS 和函数服务在同一个地域。这里稍后会详细介绍。$ fun config? Aliyun Account ID ******? Aliyun Access Key ID ******? Aliyun Secret Access Key ******? Default region name cn-shanghai? The timeout in seconds for each SDK client invoking 60? The maximum number of retries for each SDK client 6Aliyun Account ID Aliyun Access Key ID Aliyun Secret Access Key 可以在阿里云的控制台中查找和设置。Aliyun Account ID![Aliyun Account ID]Aliyun Access Key ID Aliyun Secret Access Key函数初始化先通过 fun 创建一个 Node.js 的 demo，之后可以在这个 demo 的基础上进行开发。$ fun init -n alarm helloworld-nodejs8Start rendering template…+ /Users/jh/inbox/func/code/alarm+ /Users/jh/inbox/func/code/alarm/index.js+ /Users/jh/inbox/func/code/alarm/template.ymlfinish rendering template.执行成功后，分别创建了两个文件 index.js 和 template.yml。其中 template.yml 是函数的规范文档，在里面定义了函数需要的资源、触发函数的事件等等。template.yml接下来简单看看生成的默认的 template.yml 配置文件。ROSTemplateFormatVersion: ‘2015-09-01’Transform: ‘Aliyun::Serverless-2018-04-03’Resources: alarm: Type: ‘Aliyun::Serverless::Service’ Properties: Description: ‘helloworld’ alarm: Type: ‘Aliyun::Serverless::Function’ Properties: Handler: index.handler Runtime: nodejs8 CodeUri: ‘index.js’首先定义了规范文档的版本 ROSTemplateFormatVersion 和 Transform，这两个都不用修改。Resources 里面定义了一个名为 alarm 的函数服务（Type: Aliyun::Serverless::Service 表示该属性为函数服务），并且该服务里面定义了名为 alarm 的函数（Type: ‘Aliyun::Serverless::Function’表示该属性为函数）。函数服务里面可以包含多个函数，就相当于是一个函数组。后面我们会提到的函数日志，是配置到函数服务上的。函数服务里面的所有函数，都用同一个日志。可以根据实际情况修改函数服务名和函数名。下面就将函数服务名称改为 yunzhi，函数名依旧保留为 alarm。ROSTemplateFormatVersion: ‘2015-09-01’Transform: ‘Aliyun::Serverless-2018-04-03’Resources: yunzhi: # 函数服务的名称 Type: ‘Aliyun::Serverless::Service’ # 表示 yunzhi 是一个函数服务 Properties: Description: ‘helloworld’ # 函数服务的描述 alarm: # 函数的名称 Type: ‘Aliyun::Serverless::Function’ # 表示 alarm 是一个函数 Properties: Handler: index.handler # 函数的调用入口 Runtime: nodejs8 # 函数的运行环境 CodeUri: ‘index.js’ # 代码的目录alarm 函数里面的 Properties 定义了函数的调用入口、运行环境等，如上面的注释所示。关于 template.yml 的配置详见 Serverless Application Model。index.jsindex.js 文件就是函数的调用入口了。index.handler 就表示，函数的调用的是 index.[extension] 文件中的 handler 函数。module.exports.handler = function(event, context, callback) { console.log(‘hello world’); callback(null, ‘hello world’); };初始化之后的代码就上面这几行，很简单。主要是理解上面的几个参数。event 调用函数时传入的参数context 函数运行时的一些信息callback 函数执行之后的回调必须要要调用 callback 函数，才会被认为函数执行结束。如果没有调用，则函数会一直运行到超时callback 调用之后，函数就结束了callback 的第一个参数是 error 对象，这和 JS 回调编程的思想一致关于 event 和 context，详见 Nodejs 函数入口。实现报警功能的主要逻辑，就写在 index.js 里面。具体的实现，就不细说，下面用伪代码来描述：alarm/alarm.js// alarm/alarm.js // 实现报警功能module.exports = function() { return new Promise((resolve, reject) => { // 查询 SLS 日志 // - 如果没有错误日志，则 resolve // - 如果有错误日志，则发送钉钉消息 // - 如果钉钉消息发送失败，则 reject // - 如果钉钉消息发送成功，则 resolve resolve(); })}alarm/index.js// alarm/index.js // 调用报警函数const alarm = require(’./alarm’);module.exports.handler = function(event, context, callback) { alarm() .then(() => { callback(null, ‘success’); }) .catch(error => { callback(error); })};CodeUri如果函数里面引入了自定义的其他模块，比如在 index.js 里面引入了 alarm.js const alarm = require(’./alarm’);，则需要修改默认的 codeUri 为当前代码目录 ./。否则默认的 codeUri 只定义了 index.js，部署的时候只会部署 index.js。ROSTemplateFormatVersion: ‘2015-09-01’Transform: ‘Aliyun::Serverless-2018-04-03’Resources: yunzhi: # 函数服务的名称 Type: ‘Aliyun::Serverless::Service’ # 表示 yunzhi 是一个函数服务 Properties: Description: ‘helloworld’ # 函数服务的描述 alarm: # 函数的名称 Type: ‘Aliyun::Serverless::Function’ # 表示 alarm 是一个函数 Properties: Handler: index.handler # 函数的调用入口 Runtime: nodejs8 # 函数的运行环境 CodeUri: ‘./’ # 代码的目录如果没有修改 CodeUri，则会有类似下面的报错$ fun local invoke alarmFC Invoke End RequestId: 16e3099e-6a40-43cb-99a0-f0c75f3422c6{ “errorMessage”: “Cannot find module ‘./alarm’”, “errorType”: “Error”, “stackTrace”: [ “Error: Cannot find module ‘./alarm’”, “at Module._resolveFilename (module.js:536:15)”, “at Module._load (module.js:466:25)”, “at Module.require (module.js:579:17)”, “at require (internal/module.js:11:18)”, “at (/code/index.js:9:15)”, “at Module._compile (module.js:635:30)”, “at Module._extensions..js (module.js:646:10)”, “at Module.load (module.js:554:32)”, “at tryModuleLoad (module.js:497:12)”, “at Module._load (module.js:489:3)” ]}fun local invoke alarm 是本地调试的命令，接下来会讲到。本地调试在开发过程中，肯定需要本地调试。fun 提供了 fun local 支持本地调试。fun local 的命令格式为 fun local invoke [options] <[service/]function>，其中 options 和 service 都可以忽略。比如调试上面的报警功能的命令就是 fun local invoke alarm。需要注意的是，本地调试需要先安装 docker。$ brew cask install docker安装成功后启动 docker。如果 docker 没有启动，运行 fun local 可能会有如下报错$ fun local invoke alarmReading event data from stdin, which can be ended with Enter then Ctrl+D(you can also pass it from file with -e)connect ENOENT /var/run/docker.sock正常的输出如下$ fun local invoke alarmReading event data from stdin, which can be ended with Enter then Ctrl+D(you can also pass it from file with -e)skip pulling image aliyunfc/runtime-nodejs8:1.5.0…FC Invoke Start RequestId: 9360768c-5c52-4bf5-978b-774edfce9e40load code for handler:index.handlerFC Invoke End RequestId: 9360768c-5c52-4bf5-978b-774edfce9e40successRequestId: 9360768c-5c52-4bf5-978b-774edfce9e40 Billed Duration: 79 ms Memory Size: 1998 MB Max Memory Used: 54 MB第一次调试的话，会安装 runtime 的镜像，可能需要点时间。默认的 Docker 镜像下载会很慢，可以使用国内的加速站点加速下载。出现 Reading event data from stdin, which can be ended with Enter then Ctrl+D 的提示时，如果不需要输入，可以按 ctrl+D 跳过。函数部署开发完成之后，就需要将函数部署到阿里云的函数计算上面了。部署可以通过 fun deploy 命令。前面已经在安装 fun 之后，通过 fun config 命令配置了阿里云的账号和地域信息，fun deploy 会将函数自动部署到对应的账号和地域下。在 template.yml 中，也配置了函数的服务名和函数名。如果在函数计算中没有对应的服务或函数，fun deploy 会自动创建；如果已经存在，则会更新。$ fun deployusing region: cn-shanghaiusing accountId: ***********4698using accessKeyId: ***********UfpFusing timeout: 60Waiting for service yunzhi to be deployed… Waiting for function alarm to be deployed… Waiting for packaging function alarm code… package function alarm code done function alarm deploy successservice yunzhi deploy success部署成功之后，就可以在函数计算的控制台中看到对应的函数服务和函数了。目前还没有配置触发器，可以手动在控制台中点击“执行”按钮来执行函数。触发器对于应用到生产环境的函数，肯定不会像上面一样手动去执行它，而是通过配置触发器去执行。触发器就相当于是一个特定的事件，当函数计算接收到该事件的时候，就去调用对应的函数。阿里云的函数计算支持 HTTP 触发器（接收到 HTTP 请求之后调用函数）、定时触发器（定时调用函数）、OSS 触发器等等。详见 触发器列表。对于报警功能，需要用到的是定时触发器，因为需要间隔一定的时间就调用函数。触发器是配置到函数中的，可以通过函数的 Event 属性去配置ROSTemplateFormatVersion: ‘2015-09-01’Transform: ‘Aliyun::Serverless-2018-04-03’Resources: yunzhi: Type: ‘Aliyun::Serverless::Service’ Properties: Description: ‘helloworld’ alarm: Type: ‘Aliyun::Serverless::Function’ Properties: Handler: index.handler Runtime: nodejs8 CodeUri: ‘./’ Events: # 配置 alarm 函数的触发器 TimeTrigger: # 触发器的名称 Type: Timer # 表示该触发器是定时触发器 Properties: CronExpression: “0 0/1 * * * *” # 每 1 分钟执行一次 Enable: true # 是否启用该定时触发器上面的配置，就为 alarm 配置了一个名为 TimeTrigger 的定时触发器，触发器每隔 1 分钟执行一次，也就是每隔 1 分钟调用一次函数。配置完成之后，再执行 fun deploy 就可以发布函数及触发器到函数计算上。这里需要注意的是，阿里云函数计算服务目前支持的触发器，最小的间隔时间为 1 分钟。如果小于 1 分钟，则无法设置成功。定时触发器的详细介绍可参考文档 定时触发函数。函数日志对于 serverless 应用，虽然不用关心运维了，其实我们也并不知道我们的函数运行在哪台服务器上。这个时候，函数的日志就尤为重要了。没有日志，我们很难知道程序运行状态，遇到问题更是无从下手。所以接下来需要对函数配置日志。阿里云的函数计算可以使用阿里云日志服务 SLS来存储日志。如果要存储日志，则需要先开通 日志服务。不存在日志库如果是第一次使用日志服务，则肯定不存在日志库。可以在 template.yml 像定义函数服务一样，通过 Resource 来定义日志资源。前面也提到，函数日志是配置到对应的服务上的，具体配置也很简单，就是通过函数服务的 LogConfig 属性来配置。完整的 template.yml 如下ROSTemplateFormatVersion: ‘2015-09-01’Transform: ‘Aliyun::Serverless-2018-04-03’Resources: log-yunzhi: # 日志项目名称为 log-yunzhi Type: ‘Aliyun::Serverless::Log’ # 表示该资源是阿里云的日志服务 Properties: Description: ‘yunzhi function service log project’ log-yunzhi-store: # 日志的 logstore Type: ‘Aliyun::Serverless::Log::Logstore’ Properties: TTL: 10 ShardCount: 1 log-another-logstore: # 日志的另一个 logstore Type: ‘Aliyun::Serverless::Log::Logstore’ Properties: TTL: 10 ShardCount: 1 yunzhi: Type: ‘Aliyun::Serverless::Service’ Properties: Description: ‘helloworld’ LogConfig: # 配置函数的日志 Project: ’log-yunzhi’ # 存储函数日志 SLS 项目: log-yunzhi Logstore: ’log-yunzhi-store’ # 存储函数日志的 SLS logstore: log-yunzhi-store alarm: Type: ‘Aliyun::Serverless::Function’ Properties: Handler: index.handler Runtime: nodejs8 CodeUri: ‘./’ Events: TimeTrigger: Type: Timer Properties: CronExpression: “0 0/1 * * * *” Enable: true 在上面的配置中，就定义了名为 log-yunzhi 的日志项目（Project），并且在该 Project 中创建了两个日志仓库（LogStore）：log-yunzhi-store 和 log-yunzhi-store。一个 Project 可以包含多个 LogStore。 注意：日志项目的名称必须全局唯一。 即配置中，og-yunzhi 这个项目名称是全局唯一的。执行 fun deploy 之后，就会自动在函数服务对应的地域创建日志 Project 及日志 logstore，同时也会自动为 logstore 加上全文索引，然后自动为函数服务配置日志仓库。之后函数的运行日志都会存储在对应的 logstore 里。$ fun deployusing region: cn-shanghaiusing accountId: ***********4698using accessKeyId: ***********UfpFusing timeout: 60Waiting for log service project log-yunzhi to be deployed… Waiting for log service logstore log-yunzhi-store to be deployed… retry 1 times Waiting for log service logstore log-yunzhi-store default index to be deployed… log service logstore log-yunzhi-store default index deploy success log serivce logstore log-yunzhi-store deploy success Waiting for log service logstore log-another-logstore to be deployed… Waiting for log service logstore log-another-logstore default index to be deployed… log service logstore log-another-logstore default index deploy success log serivce logstore log-another-logstore deploy successlog serivce project log-yunzhi deploy successWaiting for service yunzhi to be deployed… Waiting for function alarm to be deployed… Waiting for packaging function alarm code… package function alarm code done Waiting for Timer trigger TimeTrigger to be deployed… function TimeTrigger deploy success function alarm deploy successservice yunzhi deploy success如果日志库已经存在，且定义了日志资源，则 fun deploy 会按照 template.yml 中的配置更新日志库。存在日志库如果日志库已经存在，即已经在日志服务中创建了日志项目 Project 和日志库 Logstore ，就可以直接为函数服务添加 LogConfig，不用再定义日志资源。注意，日志库需要和函数服务在同一个地域 Region。否则不能部署成功。下面是一个配置函数日志到已经存在的 Project 和 Logstore 中的例子。ROSTemplateFormatVersion: ‘2015-09-01’Transform: ‘Aliyun::Serverless-2018-04-03’Resources: yunzhi: Type: ‘Aliyun::Serverless::Service’ Properties: Description: ‘helloworld’ LogConfig: # 配置函数的日志 Project: ’log-yunzhi-exist’ # 存储函数日志到已经存在的 Project: log-yunzhi-exist Logstore: ’logstore-exist’ # 存储函数日志到已经存在的 logstore: logstore-exist alarm: Type: ‘Aliyun::Serverless::Function’ Properties: Handler: index.handler Runtime: nodejs8 CodeUri: ‘./’ Events: TimeTrigger: Type: Timer Properties: CronExpression: “0 0/1 * * * *” Enable: true 如果日志库和函数服务不在同一个地域，函数服务就会找不到日志库，fun deploy 也会报错。如下所示，yunzhi-log-qingdao 是我创建的一个青岛地域的日志 Project。$ fun deployusing region: cn-shanghaiusing accountId: ***********4698using accessKeyId: ***********UfpFusing timeout: 60Waiting for service yunzhi to be deployed… retry 1 times retry 2 times retry 3 times retry 4 times retry 5 times retry 6 times retry 7 timesPUT /services/yunzhi failed with 400. requestid: 6af2afb8-cbd9-0d3e-bf16-fe623834b4ee, message: project ‘yunzhi-log-qingdao’ does not exist.其他问题子账号 AccessDenied如果是使用 RAM 子账号来开发、部署函数计算，则 fun 工具的配置中 Aliyun Access Key ID Aliyun Secret Access Key 是对应子账户的信息，但 Aliyun Account ID 还是主账号的信息。RAM 子账号有一个 UID，这个不是 Account ID。如果 Aliyun Account ID 写错了，则使用 fun 或 fcli 的时候，可能会遇到下面的错误Error: { “HttpStatus”: 403, “RequestId”: “b8eaff86-e0c1-c7aa-a9e8-2e7893acd545”, “ErrorCode”: “AccessDenied”, “ErrorMessage”: “The service or function doesn’t belong to you."}代码版本的管理在实现报警功能的过程中，我依旧使用了 GitLab 来存储代码。每次开发完成之后，将代码 push 到 GitLab，然后再将代码部署到函数计算上。不过这两个过程是独立的，还是不那么方便。环境问题一般我们开发的时候，需要日常、预发、线上多个环境部署、测试。阿里云函数计算是一个云产品，没有环境的区分。但对于报警整个功能，我也没有去区分环境，只是本地开发的时候，将报警消息发到一个测试的钉钉群，所以也没有特别去关注。经济成本使用函数计算的经济成本，相比于购买云服务器部署应用，成本低了非常多。本文中涉及到函数计算和日志服务两个云产品，都有一定的免费额度。其中函数计算每月前 100 万次函数调用免费，日志服务每月也有 500M 的免费存储空间和读写流量。所以只用来测试或者实现一些调用量很小的功能，基本是免费的。函数计算计费方式日志服务产品定价总结配置了函数的日志之后，将函数部署到函数计算上，就算是正式发布上线了。现在回过头来看，整个流程还算比较简单。但从零开始一步一步到部署上线的过程，还是遇到了很多问题。比如文中的许多注意事项，都是在不断尝试中得出的结论。最近 serverless 这个话题也很火热，也期待这个技术即将带来的变革。more https://github.com/nodejh/nodejh.github.io/issues ...

摘要： 本文介绍了一种新的面向开发者的简单镜像构建实践，基于阿里云Serverless Kubernetes容器服务，可以自动化而且低成本的构建容器镜像，以便让开发者了解如何使用Serverless运行CI/CD和自动化任务。前言：在云原生时代中，容器镜像是一切应用分发的基础载体，除了dockerhub作为流行的镜像仓库外，各大公有云厂商也都提供了功能丰富镜像仓库服务，如ACR（Aliyun Container Registry）, GCR（Goolge Container Registry），构建容器镜像已是所有开发者必须掌握的基础实践能力。无论开发者选择在本地使用docker完成基本的镜像构建，还是使用CI/CD服务（如Jenkins），本质上都是遵循“pull -> build -> push”的过程，完成镜像的构建、分发和同步等操作。本文介绍了一种新的面向开发者的简单镜像构建实践，基于阿里云Serverless Kubernetes容器服务，可以自动化而且低成本的构建容器镜像，以便让开发者了解如何使用Serverless运行CI/CD和自动化任务。why serverless kubernetes？容器镜像的构建是需要计算资源的，开发者在本地使用docker pull/build/push时，其计算资源是本地开发机器，如果开发者在传统kubernetes集群中部署Jenkins或Gitlab-runner服务，其计算资源也是需要持续运行。但是，容器镜像的构建基本属于高度动态的行为，往往是定时或者条件触发引起的操作，所以为了动态的构建操作而维护一个固定的计算资源池对成本是不利的。Serverless Kubernetes不同与传统基于节点的k8s集群，serverless集群中只有pod运行时才会收费，意味着只有在构建镜像时用户才需要付费，当构建结束时，也就停止计费。所以在成本上与传统k8s集群或ecs部署的方式相比显著减少。Kaniko在Serverless Kubernetes集群中，pod没有privileged权限，无法访问主机上的docker daemon，也就无法使用docker in docker方案进行镜像的操作，那么如何在kubernetes集群中不依赖宿主机的Docker情况下构建镜像呢？显然这是一个通用需求，社区也有了推荐的方案：kaniko。kaniko的工作原理与docker build类似，但是不依赖docker daemon，在pod中完成Dockfile各层的解析和build，这使得pod不需要privileged权限也可以完成镜像的pull/build/push。实践示例：定时同步容器镜像下面让我们使用Serverless Kubernetes和Kaniko实现一个简单的镜像build实验：定时同步镜像到国内ACR。步骤1: 创建Serverless Kubernetes集群登陆容器服务控制台, 5s即可完成Serverless集群创建。（如果是国外的源镜像仓库，可以选择美西区域）步骤2: 创建secret，配置ACR的用户名密码，用于推送镜像到ACR可登陆cloudshell操作如下命令。#docker login registry.cn-hangzhou.aliyuncs.com…#kubectl create secret generic regsecret –from-file=/root/.docker/config.json…步骤3: 创建定时任务CronJob在控制台选择模版创建如下定时任务，每小时同步busybox镜像到ACR。apiVersion: v1kind: ConfigMapmetadata: name: dockerfile-cmdata: Dockerfile: | FROM busybox:latest—apiVersion: batch/v1beta1kind: CronJobmetadata: name: kaniko-builderspec: schedule: “*/60 * * * *” jobTemplate: spec: template: spec: containers: - name: builder image: gcr.io/kaniko-project/executor:latest imagePullPolicy: Always args: - “–dockerfile=/configs/Dockerfile” - “–destination=registry.cn-hangzhou.aliyuncs.com/jovizhangwei/busybox:latest” volumeMounts: - name: dockerfile readOnly: true mountPath: “/configs/” - name: secrets readOnly: true mountPath: “/root/.docker/” volumes: - name: dockerfile configMap: name: dockerfile-cm - name: secrets secret: secretName: regsecret restartPolicy: OnFailure待job执行后，可查看ACR镜像仓库，确认镜像已同步。用户可以按照需求定制此模版文件，比如修改需要同步的镜像，添加build步骤等，也可以设置pod的资源限制（vcpu 0.25/0.5/1等)， 以最小的计算成本完成同步任务。结束通过上面的示例，我们看到基于Serverless Kubernetes的按需付费特性，可以使用很低的成本运行一些定时和CI/CD任务，而不用维护一个固定的计算资源池，其同样适用于压力测试、数据计算、工作流处理等其他场景。Happy Hacking！更多参考信息Serverless Kubernetes快速部署jenkins环境及执行流水线构建: https://yq.aliyun.com/articles/685219kaniko intro：https://cloud.google.com/blog/products/gcp/introducing-kaniko-build-container-images-in-kubernetes-and-google-container-builder-even-without-root-access本文作者：贤维阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

阿里妹导读：尽管大部分前端的工作并不涉及server，但最近半年serverless这个词汇以及其引发的热烈的讨论，深深触动了阿里巴巴高级前端技术专家伐薪。作为接触前端十余载的老开发，伐薪认为serverless可能会是接下来引起前端领域革命性变化的技术之一。今天，伐薪将为大家梳理serverless的历史发展进程以及对前端的影响，希望对前端工程师有所启发。上图是serverless 这个词最近5年在 google 的搜索趋势，可以看到最近半年已经达到巅峰。历史上前端领域的重要技术革命Ajax 的诞生先来回顾一下前端技术领域的重要历史节点，第一个节点是2005年，google的Jesse James Garrett 发表了一篇文章——《Ajax：Web应用程序的新方法》，首次发布了Ajax 这个新的词汇（准确说并不是新的技术，只是新的词汇），当时我还在读大二，虽然ajax不是什么新的技术，只是对XmlHttpRequest等技术的包装，但是这个技术被google宣传之后成为全球web开发的标杆，间接促进了富客户端应用（RIA）和单页应用（SPA）的流行，这些应用大都具备丝滑般的体验（局部刷新），并一直伴随着web 2.0的发展，ajax的深入人心，使得前端js的工作更加复杂和重要，专业分工越来越细，间接促进了专职的前端开发人员这一角色诞生，在此之前，web开发并不区分服务端和浏览器端的工作，因此ajax是前端领域的第一次重要事件。Nodejs 对前端规范化和工程化的促进接下来对前端变化最大的一个里程碑事件是2009年诞生的 nodejs（包括common js及npm）的出现和流行，它对前端领域的重要意义并不仅仅是让前端可以快速用js写server那么简单，个人认为它最大的贡献反而是commonjs、npm以及其便捷开发体验促进的前端工程化，它使得前端开始从刀耕火种的和传统软件工程格格不入的部署方式，发展为接近传统企业应用的研发模式，在此之前，前端开发在资源引用、依赖管理以及模块规范上缺乏有效的工具和标准，但是nodejs流行以后，基于commonjs的模块及npm的包部署和依赖管理成为主流（类似java的maven体系），并诞生了多种基于nodejs开发的cli工具辅助前端开发（如grunt、gulp），npm目前是全球最大的包管理仓库，并且成为前端项目的包依赖管理事实标准。而webpack的出现，又使得前端代码的部署更加简便，让前端可以以类似java jar包的形式发布应用（bundle），而不管项目中是何种类型的资源。React 的组件化及vdom理念第三个革命性事件是2013年开始出现的react，尽管web components标准在此之前早已发布，但是真正让组件化理念深入人心并且应用最广的库是react，它还至少有两点特性足以让它成为历史上最具前瞻性的前端库，第一个特性是vdom的出现，在此之前，所有的ui库，都直接与dom关联，但是react在UI创建与渲染引擎之间，增加了一个中间层——vdom（一个使用轻量级json描写UI结构的协议），除了改善了其本身的dom diff性能之外，还有一个重大意义就是UI的编写与渲染开始分离，一次编写，多端渲染的UI得以实现，这个多端包括server端、移动端、pc端以及其他需要展示UI的设备，之后的react native以及weex都是这一分层思想的受益者。除了vdom之外，react还有一个重要的理念非常超前，即UI是一个函数（类），函数输入一个state，一定返回确定的视图，在此之前，大部分框架和库，都会把UI分离成一个html片段（通常支持模板写法以渲染数据），一个为该html片段绑定事件的js，尽管这样比较好理解，但是react对UI这种抽象却反映了UI的实际本质，并且这种函数式理念，在后面可以看到，将与faas及serverless技术产生美妙的碰撞。react 的诞生对此后，甚至此前的框架和库都产生了深远的影响，包括不限于angular和vue都陆续采纳了它很多技术思想，并且成为前端开发领域目前已经趋于稳定的屈指可数的几个技术选型之一。再来总结一下，ajax使得前端的角色逐渐分离出来，nodejs促进了前端的开发模式向传统编程语言靠近（工程化），react的出现，基本结束了后端常常对前端”技术变化快“的吐槽，至此，前端的技术体系逐步成熟和标准化。serverless 理念与前端的关系那么为什么说下一次对前端技术领域有较大影响的理念是serverless呢，事实上，尽管serverless这个词汇由亚马逊提出来还不到几年，但是这个理念并不是什么爆炸性的新理念，在早期，cdn还不普及的时候，web工程师会把js资源和视图文件（可能是静态也可能是动态的）传到服务器，那个时候前端是需要关心服务器的，但是cdn及回源策略的普及，工程及搭建系统的大规模使用，使得前端可以快速把一个js或者静态文件扔到cdn节点，通过回源机制（cdn回源到一个动态服务），半动态的视图层渲染也成为可能，在这整个过程，前端开发无需关心任何服务器的知识，也不知道cdn有多少节点，如何做负载均衡，做gslb的，也不需要知道qps多少，一个cdn可以放各种业务各种开发的资源，可以说cdn是serverless理念的的先行者。回到应用部署，在前几年nodejs刚流行的时期，已有开发者意识到应用与机器的部署与运维成本对业务方会是个问题，出现了一些容器化的思想，比如cbu在15年出的naga，在这个naga容器里，业务逻辑是一个个插件，容器负责请求的路由分发，负载及稳定性管理，业务方只需要编写并上传最直接的业务代码即可，对业务方来说是实现了serverless的理念，因为naga的维护者帮你解决了部署及运维的问题。再说对前端息息相关的页面搭建系统以及bff层，无论是各种搭建系统（如斑马、积木盒子、TMS），还是基于graphQl的平台，还是通过web ide快速编写api gateway的产品——如cbu的mbox，都让业务开发只关心业务逻辑，无需关心部署运维知识，它们一定程度上体现了serverless的理念。serverless 将对前端的影响综上所述，前端早已与serverless产生了联系，但是很多人还没感知，接下来，serverless显示化地爆发将给前端带来更为深远的影响，主要体现在三个方面。前端将会重新回归到web应用工程师这一职能在最前面说了，前端是社会分工的细化，大约起源于2007年左右，在此之前是没有专门的前端开发角色的，通常称作web工程师或网站工程师，早期的网页大都是服务器渲染，使用asp、php、jsp等server page技术，js仅仅是web工程师需要掌握的小小技能之一，但是随着web 2.0及互联网、移动互联网、电子商务的发展，需要专门的人专注于编写具备很好兼容性和体验的UI，因此逐渐产生了专注于浏览器及移动端的前端工程师。但是前端技术领域逐渐趋于稳定，伴随着十几年的发展，各种开箱即用的库、垂直方案以及工程手段唾手可得，甚至目前出现了一些辅助工具可以把设计师的视觉稿生成UI代码，前端可以安心并且以非常低的成本编写UI和业务逻辑，而不用耗费大量精力在选型、造轮、还原视觉、处理兼容性、性能优化、调试和部署上，这种情况，前后端工种分离造成的协同成本反而放大了，因为在前后端角色分离的情况下，后端往往还会充当bff层的角色，比如为前端表现层封装各种api gateway，经常出现相互等待、联调协议的情况，而且bff层通常只是一些数据的加工，其他的角色经过短期的培训可以快速上手，因此前端一直在尝试接入到server端的bff层。在15年前端开始推广使用nodejs来部署应用，阿里内外也出现了不少nodejs的框架，如业界的express，在生产环境，包括给买家、商家以及内部人员使用的系统，有不少使用了nodejs，但是到今年2019年，再来回顾一下，发现这个数字并没有超出预期。造成这一现象的原因，个人认为归根到底还是因为分工太细导致的前端对服务器知识的缺乏，nodejs本身的定位是服务器技术，本质上在服务器要面对的问题与java无异，现有的前端jd招聘的人才，鲜有能在服务器上工作游刃有余的人，除非专门招的nodejs人才，server服务的长期运行会暴露很多问题，比如接口很慢，进程core，cpu飙升，内存泄漏等，另外负载均衡、扩缩容，高并低延等知识，大部分前端都是没有这些经验的。云计算的本质就是要让业务开发专注于业务逻辑，业务之下的硬件及软件设施都是按需采买，开箱即用，而serverless理念及相关技术，将使得开发人员不再需要关心应用及机器的问题，甚至连流量能不能撑住也不用关心了，它能自动扩缩容，因此，未来web开发人员的运维成本会大幅降低，前端也可介入到bff层的开发，而后端可以聚焦于数据处理、业务逻辑与算法。这一变革符合研发效能提升的背景，未来的云设施将会做得非常厚，非常专业、稳定，而前台开发人员可以快速地，最低成本地在云设施上建立业务逻辑，前端和服务器的前端（对整个请求链路来说，前端是相对的，只要离客户请求更近的角色都可以称自己为前端），分工将没那么明确，以前的浏览器端的前端，将逐步承担一部分服务器端接入层以及bff层的工作，返璞归真，回到历史上曾经的web开发工程师角色，这是对前端最大的一个变革。当然，serverless技术让前端回归到传统的web层，不代表前端不用掌握服务器知识了，掌握操作系统内核及网络编程知识仍有助于你编写高性能、高可用的业务应用。实时SSR将成为展示端UI的主要开发模式最早的web开发，其实处理UI都是以服务器渲染为主，比如perl、php等动态网页技术，但是在前端逐渐成为一个工种开始负责了绝大部分UI开发，并且技术域逐渐缩小到客户端范围之后，网页静态化以及客户端的渲染逐渐成为主流。但是这种模式对用户体验肯定是有问题的，导致了较多的白屏时间，而由于新的前端库如react和vue在vdom这层的抽象，服务器渲染的技术成本更低，因此SSR在最近几年，又逐步开始流行。但是SSR的难点恰恰是前面说的，服务器端人才的匮乏，虽然nodejs和vdom的普及提升了SSR的实施效率，但由于服务器知识的缺乏，通常只有少部分具备综合知识的前端会深入的实践这一领域。serverless技术的普及将把这个问题消除掉，借助于serverless技术，前端可以快速搭建一个ssr的场景，在服务器取数，在服务器渲染，直出html给到客户端，而不用关心这个渲染服务能否扛得住流量，会不会挂掉，这些事情云设施供应商会去解决。在前面说过，react有一个核心理念就是把UI看成函数，如果说一个页面是多个组件组成的，那一个组件是函数，我们可以把一个页面看成是多个函数的组合，不同函数的组合，组合成不同的导购场景，如果把一个函数看成一个微服务，一个场景就是微服务的聚合，这恰恰是faas的理念。通过serverless低成本地实时ssr，可以让客户体验更好，借助算法和大数据，还可以快速实现UI的千人n面，构建真正的导购大脑。基于场景的云开发（web ide）将成为主流开发模式在提到serverless技术的时候，有一个关联的领域不得不提，那就是web ide，很多互联网大型企业把一个web ide当成了云的基础设施并且大力投资，这是为何？个人认为有两个原因。第一个是因为serverless目前在业界使用以垂直场景为主，他们有一个共同点，就是代码足够标准、规范，场景较为垂直，代码复杂度不是很大，而且借助web ide可以快速地与云平台结合，做到一键发布，因此这种场景，是比较适合轻量的在线编码到部署全链路打通的。另一个原因是，目前所有的云设施解决的是业务运行问题，但是软件开发有一个非常大但是大部分人可能会忽略的痛点，那就是环境问题，相信很多人都有那种clone别人的项目但是废了九牛二虎之力都无法启动的问题，因为要装各种环境啊？另外就是和别人联调的时候，是不是因为各种环境部署缺失的问题，联调效率很低？借助容器如docker等技术，软件的运行及调试环境，可以快速地移植给别人复用，而目前基于js的代码编辑器已经非常强大，vscode editor就是基于js编写并且沉淀出一个库 Monaco Editor，因此可以说，大部分认为web ide可能在语法提示、智能感知上比不上本地ide的想法是过时了。同时web ide可以快速地与平台集成，深入定制，打通业务平台，一键部署，极大地提升研发效率。web ide还能解决跨地办公的问题，因为解决了环境准备这一老大难问题，你可以在家里，在公司，甚至在火车上，快速编写并交付代码。因此未来的paas平台，都将关联一个深度定制的web ide，需要编写业务逻辑时，一个连接跳转到web ide即可编码，完全无需关心本地环境问题，做到真正的envless。比如你要开发一个TMS模块，那么点击”新建“，跳到了web ide，代码会帮你初始化好，点击运行，会在云端启动服务器运行该组件，编写好之后，一键即可发布到TMS。对于各种faas、api gateway系统以及其他云服务，都会一样，web ide将成为企业云化的基础设施。尽管阿里云目前还未发布媲美cloud9以及coding.net的web ide，但是很欣喜地看到集团内部已经涌现出一些优秀的产品，如aone的ide，以及数据平台的app studio，其体验已经接近业界顶级水准。结语在云计算领域，serverless将会掀起一场革命，即使看起来与这一领域关联不大的前端，也会经受即ajax、nodejs以及react之后的又一重大变革，你做好应对了吗？本文作者：伐薪阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

有了它，再也不用早起偷能量了自从支付宝在 2016 年 8 月推出蚂蚁森林后，我便开始了每天早上 7:00 准时醒来，在被窝中睡眼惺忪地收能量的生活，梦想着在阿拉善或者通辽种下一颗樟子松。但随之而来的是 10 年前在开心网被偷菜的恐惧，每次被偷能量都能让人捶胸顿足，火冒三丈。每个来我这偷能量的朋友都是阻挡在我和保护地球母亲中间的恶党。于是久而久之，这个活动开始变味，大家忙于互偷却忘记了最开始的初衷，种树。那么有没有一款能让你不用很努力同时也不用担心被偷能量的种树神器呢？ 有的，也就是今天要介绍的：Ecosia能种树的搜索引擎Ecosia 代表一种未来的公司形式，就像我们在之前 Serverless 的文章中（点击直达原文）阐释过的，未来随着云计算的发展，越来越多的通用性能力会被云厂商打包成产品提供给客户，省去客户搭建和维护的成本，帮助客户聚焦自身业务，在细分市场打造核心竞争力。Ecosia 就是使用了微软的 Bing 引擎，加上自身对行业的理解，通过 “种树” 项目为搜索引擎行业带来新的想象空间。Ecosia 的故事非常简单，每次你使用它进行搜索，它就会获取一定的广告收入，不同于其他把广告收入装入腰包的搜索引擎，它承诺将 80% 的利润投入到全球的绿化和森林修复项目中，通过这样的方式，让搜索结果中的广告变得不那么讨厌。顶部工具栏有搜索计数器，大约每 45 次搜索后 Ecosia 就能获得种一棵树的收入。Ecosia 从 2009 年成立至今，已经在全球超过 15 个国家种植了超过 50000000 颗树。Ecosia 在布基纳法索（非洲西部的内陆国）的植树项目，1 年时间对比：同时 Ecosia 作为非上市公司，还坚守财务透明原则，公布每月通过搜索广告获得的收入，和所有收入的用途。种树报告也会每月实时同步。经过实际使用，Ecosia 除了能帮助拯救地球以外，作为一款搜索引擎来说也是非常优秀（尤其在国内不能使用 Google 的情况下）：搜索官网和某些特定问题时，效率明显高于百度，且没有误导信息。没有广告侧边栏。基于 Bing 的搜索，对多语言环境比较友好。注重用户隐私，没有“个性化”搜索。总的来说，在新兴企业如何利用云厂商包装好的通用型产品，配上一个优秀的商业模式在细分领域打开市场上，Ecosia 是一个很好的例子。同时 Ecosia 满足了大家种树的愿望，也成功获得了 Certified B Corporations（B 类企业认证，指追求经济利益之外、注重社会效益和环境效益的企业认证体系）。Kudos to Ecosia！同时 CODING 的 CSR 计划也欢迎各类非盈利组织和学生群体申请，我们会为符合条件的组织/团队提供免费的 CODING 研发管理系统权益。点击即可报名！