Serverless

更新应用时,如何实现 K8s 零中断滚动更新?

笑着哭i 提交于 2020-08-14 02:41:21
作者 | 子白(阿里云开发工程师)、溪恒(阿里云技术专家) <关注阿里巴巴云原生公众号,回复 排查 即可下载电子书> 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章,帮助你一次搞懂 6 个核心原理,吃透基础理论,一次学会 6 个典型问题的华丽操作! Kubernetes 集群中,业务通常采用 Deployment + LoadBalancer 类型 Service 的方式对外提供服务,其典型部署架构如图 1 所示。这种架构部署和运维都十分简单方便,但是在应用更新或者升级时可能会存在服务中断,引发线上问题。今天我们来详细分析下这种架构为何在更新应用时会发生服务中断以及如何避免服务中断。 图1 业务部署图 为何会发生服务中断 Deployment 滚动更新时会先创建新 pod,等待新 pod running 后再删除旧 pod。 新建 Pod 图 2 服务中断示意图 中断原因 :Pod running 后被加入到 Endpoint 后端,容器服务监控到 Endpoint 变更后将 Node 加入到 SLB 后端。此时请求从 SLB 转发到 Pod 中,但是 Pod 业务代码还未初始化完毕,无法处理请求,导致服务中断,如图 2 所示。 解决方法 :为 pod 配置就绪检测,等待业务代码初始化完毕后后再将 node 加入到 SLB 后端。 删除 Pod 在删除旧 pod

大数据实践解析(下):Spark的读写流程分析

旧巷老猫 提交于 2020-08-14 01:57:30
导读: 众所周知,在大数据/数据库领域,数据的存储格式直接影响着系统的读写性能。spark是一种基于内存的快速、通用、可扩展的大数据计算引擎,适用于新时代的数据处理场景。在“ 大数据实践解析(上):聊一聊spark的文件组织方式 ”中,我们分析了spark的多种文件存储格式,以及分区和分桶的设计。接下来,本文通过简单的例子来分析在Spark中的读写流程,主要聚焦于Spark中的高效并行读写以及在写过程中如何保证事务性。 1、文件读 如何在Spark中做到高效的查询处理呢?这里主要有两个优化手段: 1)减少不必要的数据处理。数据处理涉及文件的IO以及计算,它们分别需要耗费大量的IO带宽和CPU计算。在实际的生产环境中,这两类资源都是有限的,同时这些操作十分耗时,很容易成为瓶颈,所以减少不必要的数据处理能有效提高查询的效率; 以下面的查询为例: spark.read.parquet("/data/events") .where("year = 2019") .where("city = 'Amsterdam'") .select("timestamp") 由于在events表中按照year字段做了分区,那么首先通过 year 字段我们就可以过滤掉所有year字段不为 2019 的分区: 因为文件是parquet的文件格式,通过谓词下推可以帮助我们过滤掉 city 字段不是

从单体迈向 Serverless 的避坑指南

隐身守侯 提交于 2020-08-14 01:48:25
作者 | 不瞋 阿里云高级技术专家 导读: 用户需求和云的发展两条线推动了云原生技术的兴起、发展和大规模应用。本文将主要讨论什么是云原生应用,构成云原生应用的要素是什么,什么是 Serverless 计算,以及 Serverless 如何简化技术复杂度,帮助用户应对快速变化的需求,实现弹性、高可用的服务,并通过具体的案例和场景进行说明。 如今,各行各业都在谈数字化转型,尤其是新零售、传媒、交通等行业。数字化的商业形态已经成为主流,逐渐替代了传统的商业形态。在另外一些行业里(如工业制造),虽然企业的商业形态并非以数字化的形式表现,但是在数字孪生理念下,充分利用数据科技进行生产运营优化也正在成为研究热点和行业共识。 企业进行数字化转型,从生产资料、生产关系、战略规划、增长曲线四个层面来看: 生产资料:数据成为最重要的生产资料,需求/风险随时变化,企业面临巨大的不确定性; 生产关系:数据为中心,非基于流程和规则的固定生产关系,网络效应令生产关系跨越时空限制,多连接方式催生新的业务和物种; 战略规划:基于数据决策,快速应对不确定的商业环境; 增长曲线:数字化技术带来触达海量用户的能力,可带来突破性的增长。 从云服务商的角度来看云的演进趋势,在 Cloud 1.0 时代,基础设施的云化是其主题,采用云托管模式,云上云下的应用保持兼容,传统的应用可以直接迁移到云上

把 B 站的视频弹幕搬到小程序中,这项技术可以轻松搞定

我与影子孤独终老i 提交于 2020-08-14 01:44:03
作者| 知晓云 2019 年 12 月,Bilibili( B 站)公布了 2019 年度弹幕,「AWSL」荣登榜首。此外,「泪目」、「名场面」、「妙啊」等弹幕也入选了十大弹幕热词。 弹幕,日本弹幕视频分享网站( niconico 动画)的舶来品,由 AcFun(A 站)和 Bilibili ( B 站)引进到国内并盛行。今天,中国各大视频网站都开始增加弹幕功能,弹幕已然成为年轻人需要的一种观影体验。 awsl 源于「啊,我死了」的拼音缩写,是对幸福、喜欢、兴奋等各种喜爱之情的情绪表达 弹幕的应用 弹幕是悬浮于视频上方的实时评论,给观看者提供一种「实时互动」的错觉 。用户通过弹幕进行评论、内容补充与互动,将单向的内容输出变成双向的文化交流,也为平台创造一个良好的用户生态环境。 如今弹幕已成为社交平台、视频平台上的视频标配,但基于弹幕的属性,在不影响用户的阅读体验前提下,是可应用到更多场景中。 场景一: 在电商小程序中把下单消息和用户评价搬到商品详情页中,实时的呈现给正在浏览商品的潜在客户。也许正是因为眼前飘过的「好友**在一秒前已下单」、「还有**分钟恢复原价」,客户便提交订单完成交易。不仅有效促进用户转化,还节省了用户的选择时间。 场景二: 当你打开外卖或社区小程序,还在苦恼中午吃什么时,屏幕开始闪过大家的美食分享,此时的弹幕正如你咨询了朋友「今天吃什么」后的回答一样

从零到一,Serverless 平台在滴滴内部落地

守給你的承諾、 提交于 2020-08-13 17:58:33
本文整理自 ServerlessDay · China 大会 - 《从零到一,Serverless 平台在滴滴内部落地》分享,讲师滴滴弹性云平台负责人张健、滴滴资深前端开发工程师陈钦辉。滴滴 Serverless FT成员来自:滴滴基础平台部、车服技术部、金融事业部、普惠产品技术部。 为什么(前端)要推动建设 Serverless 更快地创建一个服务且免运维:大量的 Node.js 服务,创建服务,需要申请节点、申请机器,对接构建、部署、日志、监控,还要持续运维服。我们希望能更快创建一个服务并且免运维。 更灵活的隔离能力:前端 BFF 接口聚合、微前端等业务场景,需要创建大量的接口服务,快速创建服务的同时,还希望可以以不同粒度灵活进行接口间的隔离。 更低的成本:大量低峰期时间cpu/内存利用率很低,服务不再使用了,资源却仍然占用。 我们的方案 我们调研了业界的 Serverless 方案,最终决定了自己的方案: K8s + Knative + Istio 搭建应用级 Serverless。他的优势是: 社区相对繁荣,未来充满希望。 应用级 Serverless, 和传统通过 Docker 镜像开发,部署相近,现有服务迁移成本低。 应用级 Serverless, 通过 Serverless。 路由,可以灵活控制隔离的粒度。 通过 Serverless 升级研发模式 那有了

阿里 Serverless 架构落地实践:人力节省 50%,研发效能提升 40%

99封情书 提交于 2020-08-13 13:31:26
云栖号资讯:【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 作为一名阿里老兵,杨皓然早在 2010 年即加入阿里云,曾深度参与阿里云飞天分布式系统研发和产品迭代的全过程。如今,他是阿里云 Serverless 负责人。Serverless 有哪些典型的应用场景?Serverless 在研发效能上可以发挥怎样的作用?Serverless 在阿里内部有哪些实践?它的发展趋势是什么?带着这些问题,InfoQ 记者近日采访了阿里云 Serverless 负责人杨皓然。 Serverless 走向繁荣 Serverless 首次出现于 2012 年,中文即“无服务器架构”。它的出现将主机管理、操作系统管理、资源分配、扩容,甚至应用逻辑的全部组件都集成为服务,开发者可以更直接地将大部分后台能力作为一个能力接口来使用。将开发过程中的能力使用改为服务使用,通过构建或使用一个微服务或微功能来响应事件。 从理念空谈到实践落地,Serverless 开始走向繁荣。 根据 O’Reilly 2019 年 12 月发布的 Serverless 使用调研报告显示,已有 40% 的受访者所在的组织采用了 Serverless,并且使用 Serverless 技术的行业也十分广泛。尤其值得关注的是,有超过 50% 的受访者在一至三年内采用 Serverless,而

Istio 网关之南北向流量管理

天涯浪子 提交于 2020-08-13 12:39:49
作者 | 王夕宁 阿里巴巴高级技术专家 参与阿里巴巴云原生公众号文末留言互动,有机会获得赠书福利! 本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书,文章介绍将集群外部的客户端连接到集群内运行的服务,以及如何从集群内的服务访问集群外部的任何服务,即通常所说的南北向流量管理。其中介绍了 Istio 在南北向流量方面的路由控制能力,引出 Istio 网关的概念及其工作原理。 本文文末汇集并整理了近期 Istio 的相关问题并特邀王夕宁老师进行解答,希望能够对大家有所帮助~ Istio 网关 网络社区中有一个术语 Ingress,是指入口请求到集群内服务的流量管理。Ingress 指的是源自本地网络之外的流量,指向本地集群网络中的端点。此流量首先路由到公开的入口点,以便通过执行一些本地网络的规则和策略来确认哪些流量被允许进入。如果流量未通过这些入口点,则无法与集群内的任何服务连接。如果入口点允许流量进入,则将其代理到本地网络中的合适节点。Istio 对入口流量的管理是由 Istio 网关进行的。 Istio 网关的工作原理 传统上,Kubernetes 使用 Ingress 控制器来处理从外部进入集群的流量。使用 Istio 时,情况不再如此。Istio 网关用新的 Gateway 资源和 VirtualServices 资源来控制入口流量

Serverless 工作流给人工智能带来了哪些变化?

痴心易碎 提交于 2020-08-13 12:38:03
4月,阿里云 Serverless 工作流正式商业化,这是一款用于协调多个分布式任务执行的全托管 Serverless 云服务。产品致力于简化开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作,让用户聚焦业务逻辑开发。 精准打造云上自动生产线,Serverless 工作流正式商用 工作流是一种非常常见的场景,比如企业内部审批、采购订单、ETL等日常企业事务,或者大数据处理流水线,常规或定制化自动化运维等。此外,音视频行业的多媒体文件分片转码、格式转换、审核校验和人脸识别等长时任务,电商旅游行业的客户线上订单,AI 行业的机器学习流水线, 生信行业的基因测序也会有工作流。 这些场景面临着以下难点:一般由众多异步分布式任务组成,控制逻辑和任务逻辑交织在一起,流程复杂冗长;分布式任务可能跨越公共云和本地机房,安全的打通网络代价很大;整个工作流执行完毕耗时过长,造成资源占用的浪费;涉及异步且关键业务流程,务必保证数据一致性;繁复的执行步骤如何进行可视化监控等等。 Serverless工作流正式针对这些痛点,分离控制逻辑与任务逻辑,细化责任,便于管理和维护;将流程以模版方式统一定义控制,简化编排,通过串联或并行等多种方式编排任务;支持函数,队列,云服务等多种任务类型,打通公共云和企业内网;支持最长1年的执行任务,但却采用Serverless计费模型, 按需付费

全部满分!阿里云函数计算通过可信云21项测试

不打扰是莪最后的温柔 提交于 2020-08-13 12:14:25
今日,“2020 可信云线上峰会”正式召开。会上,中国信通院公布了混合云安全、云组网、函数即服务、消息队列、云计算安全运营中心等首次评估结果。 阿里云函数计算通过了基础能力要求、平台可观测能力、服务性能、服务安全和服务计量准确性等 21 项测试,最终以满分成绩通过可信云函数即服务能力认证。 阿里云的函数计算(Function Compute)是一种 Serverless 计算形态,采用云原生架构模式,从底层开始变革计算资源的形态,为软件架构设计与应用服务部署带来了新的设计思路,将繁重的基础设施管理工作交由云服务商负责,从而提高开发者的研发效率和创新能力,被 Gartner 称为最有潜力的云计算技术发展方向。 使用阿里云函数计算的优势: 1、开发者无需采购和管理服务器等基础设施,只需专注业务逻辑的开发,可以大幅缩短项目交付时间和人力成本; 2、函数计算提供日志查询、性能监控等完备的可观测性能力,帮助开发者快速排查故障; 3、开发者无需投入精力到繁琐的运维工作,函数计算根据业务规模毫秒级别弹性伸缩,快速扩容以应对峰值压力,性能优异; 2019年,阿里云推出函数计算 2.0,通过一系列创新的功能,解决了 Serverless 计算服务的痛点。在函数计算出现之前,客户要通过很多胶水代码完成多个云产品间的集成,还要仔细处理各种错误情况。当函数计算和阿里云对象存储集成后,对象存储中产生的上传

揭秘:如何为 Kubernetes 实现原地升级

坚强是说给别人听的谎言 提交于 2020-08-13 10:38:14
作者 | 王思宇(酒祝) 阿里云技术专家 参与阿里巴巴云原生文末留言互动,即有机会获得赠书福利及作者答疑! 概念介绍 原地升级 一词中,“升级”不难理解,是将应用实例的版本由旧版替换为新版。那么如何结合 Kubernetes 环境来理解“原地”呢? 我们先来看看 K8s 原生 workload 的发布方式。这里假设我们需要部署一个应用,包括 foo、bar 两个容器在 Pod 中。其中,foo 容器第一次部署时用的镜像版本是 v1,我们需要将其升级为 v2 版本镜像,该怎么做呢? 如果这个应用使用 Deployment 部署,那么升级过程中 Deployment 会触发新版本 ReplicaSet 创建 Pod,并删除旧版本 Pod。如下图所示: 在本次升级过程中,原 Pod 对象被删除,一个新 Pod 对象被创建。新 Pod 被调度到另一个 Node 上,分配到一个新的 IP,并把 foo、bar 两个容器在这个 Node 上重新拉取镜像、启动容器。 如果这个应该使用 StatefulSet 部署,那么升级过程中 StatefulSet 会先删除旧 Pod 对象,等删除完成后用同样的名字在创建一个新的 Pod 对象。如下图所示: 值得注意的是,尽管新旧两个 Pod 名字都叫 pod-0,但其实是两个完全不同的 Pod 对象(uid也变了)。StatefulSet 等到原先的