Serverless Develpoer Meetup 课程_Kubernetes开发与运维_技术课程_开发者学堂

阿里云
为了无法计算的价值
打开APP
阿里云APP内打开
开发者社区> 开发者学堂> 全部课程> Serverless Develpoer Meetup 课程

Serverless Develpoer Meetup 课程

1课时 |
71人已学 |
免费
课程介绍

阿里云首场线下 Serverless Developer Meetup 即将亮相,来自阿里云、淘宝、闲鱼、百富旅行的技术大咖,洞察 Serverless 在中国的发展趋势;深度分享 Serverless 在 双11 和企业的落地经验;首次披露 Serverless Devs 开源细节。

Serverless Developer Meetup 深圳站

 

 

Serverless 正当时

 

前言:

Serverless 从概念的产生到现在规模化的场景有9年的时间,Serverless 技术有从低谷到高潮的变化,现在 Serverless 是正当时的状态。

 

目录:

一.简化For开发者:Serverless 带来的生产关系改变

二.Serverless 最佳场景

三.最后:Serverless+团队=打造小而美的团队

四.复杂化 For 云开发商

五.简化For开发者

 

一.简化For开发者:Serverless 带来的生产关系改变

前端后延(前后端一体化),后端下沉(微服务BaaS化),运维云化(CNCF运维)

 

Serverless 未来的职责可以向后端延伸,后端功能从传统的应用 Baas化上线,慢慢的 Baas 化,做服务级别的开发。以前的运维工程师学 CNCF 云延伸。CNCF 可以在任何场景搭建,私有云、公有云、本地环境都可以搭一套架构。以后的运维工程师更偏向于云端偏移。Serverless 对研发生产链带来一些变故。

前后端一体化概念,之前的前后端一体化概念需要更专业的前端工程师做全栈工程师,有了 Serverless 以后前端工程师写后端接口编排非常简单。已经有前端编排可视化的工具。

 

二.Serverless 最佳场景

1.Serverless最佳之:事件驱动+FaaS(无状态)+BaaS(状态存储) FaaS语言无关,各采所长:Node.js,Py,Java,PHP,go,Ruby,Rus

t…自建镜像

 

Serverless 在缓慢爬坡,Serverless 提供的能力、边界需要了解。了解 Serverless 边界最容易的方法是看云服务端有支持哪些 Trigger 事件驱发。下面例子云服务端支持 OSS,当上传文件到 OSS,上传成功后事件驱发把函数拉起。

在写 FaaS 时与传统的 requst 调用 FaaS 不同,request 包装成 Tigger,所有的 FaaS 在封闭的包裹里,通过Tigger唤醒包裹,腾讯语音已经推出了 web socket 的 Tigger。可以用 web socket 与用户建立长连接。用 web socket 唤醒函数可以处理聊天室。云服务商哪些提供 Serverless 化,哪些提供 BaaS 能力。BaaS与语言无关的。Serverless 可以保证这样做是最便宜的。

 

  1. Serverless最佳之:Serverless+BFF=SFF数据编排

前端团队需要和 Java 工程师对接,Java 工程师提供微服务,可以理解为提供 RPC 接口。

 

3.Serverless 最佳之:Serverless+Git=GitOps

 

自建一套自动发布上线的管道,不需要像以前修改版本,测试一遍,上线以后流量回归自查一遍。GitOps 整个方案非常成熟,Git 本身支持大量 book 函数,打造流程非常容易。10%验证发布的灰度环境版本,灰度环境版本验证一天或几天没有问题将版本替换掉。发布流程非常自动化。

 

三.最后:Serverless+团队=打造小而美的团队

前端和后端做得很开,前端有前端的 leader,后端有后端的 leader。所以就会产生前端有前端的开发后端有后端的开发。打造小而美的团队打破隔阂,Serverless 是比较适合的场景,通过 SFF 以后前端可以把服务编排解决掉,前端去导推。

 

组织架构决定技术架构

用SFF隔离后端变化:数据编排交给前端,前后端一体化。GitOps 解决部署运维:降低前端心智负担。

模型驱动+低代码(跑题):前端同学专心抽象业务模型。

未来新的数据增长点数据驱动,前端同学很长时间被认为不适合做业务只是搭建页面,前端同学做模型抽象以页面为维度,将模型抽象划分模块。

当前业务特点建立业务模型数据后,通过模型驱动页面,低代码化不需要用大页面,所有的页面都用可以所见即可的工具搭建。只需要将当业务的前端模型抽象出,用模型驱动。

 

前言:先达成几点共识

1.软件工程没有银弹:Serverless也不是银弹;

  1. Serverless解决的是运维域的问题;

3.复杂度守恒定律(Tesler’slaw)--泰斯勒定律:苹果产品;云服务商承受复杂,开发者变简单;

4.邓宁-克鲁格效应(the Dunning-Kruger effect)

 

 

整个 PC 的复杂度是固定的,将复杂的工程留给系统的工程师和软件开发工程师,让用户体验非常简单。以前运维应用、网站复杂的通用的能力沉淀给云服务商,用户变简短但整体的复杂度守恒。由失望的低谷缓慢爬坡,Gartner 将这套理论用来做技术发展的曲线。

Serverless 刚推出后对它充满无数的想象,当想象到巅峰时会慢慢意识到并不是想的那样。可以做很多设想当真正做的时候,切身去体会,在产品中使用时会掉到技术的低谷,然后缓慢的爬坡。所有的技术发展都是这样的曲线。前端工程师体感新的工程层出不穷。

 

四.复杂化 For 云开发商

1.复杂化 For 云开发商:Serverless 运维集大成者

 

大部分服务跑到容器 CaaS,用 K8S 来调动容器,laaS 是虚拟机,最底层物理机。Serverless 的应用必须跑到这样的架构上,KS 的实现有很多。Component 是解决网络像 Service Mesh 东西流量。基本上Serverless 背后虚拟的架构都是这样。

 

2.复杂化For云开发商:不可变基础设施

复杂度下沉,CNCF无缝迁移,vendor-unlock

整个应用的架构是 CNCF 与云服务商无关,可以部署到阿里云,可以部署到腾讯语音上,整个框架与配置文件迁移。云服务商传统的优势会渐渐失去。云服务商非常白热化,要打价格战,看谁提供更好的服务。

 

3.复杂化 For 云开发商:Serverless化

云服务商的内卷BaaS竞争白热化,新的vendor-lock

.狭义Serverless(最常见)

FaaS应用=Trigger+FaaS(函数即服务)+BaaS(后端即服务,持久化或第三方服务)

  • 广义Serverless

服务端免运维=具备Serverless特性的云PaaS服务

 

云服务商在面向 FaaS 激烈的竞争,主要提供 BaaS 的能力。BaaS 与 FaaS 配套使用。

图上最上面一层部署,不需要关心底层的基础建设,只需要关心函数怎么去运行,云服务商提供了哪些 BaaS 的能力。在 FaaS 函数里马上创建一个数据库,插入数据写数据,云服务商的竞争不停的提供新的 BaaS 能力。之前在使用BaaS 能力、数据库能力时面向于 IPv4。

广义的 Serverless 整个的云服务商运维体系 Serverless 化

 

 

  1. 简化 For 开发者

 

发展阶段

 

Serverless 有哪些边界的限制、弹性越来越清晰

绿色代表已经成熟但还在试点的圈内,试点用没有问题,但线上环境有许多边界问题。

 

1.简化For开发者:Serverless只是运维域过渡态

终局思想,无穷接近终局,过渡形态长期化

未来面向终局思考是 NoOps,对 Serverless终局的猜想,终局未必是一定达到的,可能一直处在过渡的状态,终局只是理想状态,尽可能无限接近终局未必能达到终局的状态。终局是 NoCode 不用写代码,LowCode 是写少量的代码前身是 ProCode 。LowCode 概念正在攀高峰对它充满了想象力,LowCode 是解决 UI 搭建的问题,并不是教大家写更少的代码,是解决特定域的问题。

之前提供数据接口要面向前端开发工程师写大量后端的数据接口。现在有 BFF/SFF 函数编排,可以用现在的状态写,理想状态是模型驱动,不需要写接口。后端服务之前是 SOA面向服务的编程,现在是微服务的概念,未来全部 BaaS 化,提供一个后端服务不需要了解有多少后端服务器。

2.简化For开发者:Serverless+

结合 Serverless 做技术变革

现在是用 Serverless 做变革的阶段,LowCode+Serverless 会让 LowCode 搭建的页面快速的部署上线。

 

FaaS在复杂业务场景下的提效实践

 

大纲:

第一点前端 FaaS 演进之路,怎样从业务系统构建 FaaS 能力。第二点在实际的业务场景里怎样把 FaaS 与传统的服务结合在一起。第三点以非常实际的业务场景的例子介绍怎样在复杂的业务场景做提效实践。最后做总结和展望。

 

Part1:1688的FaaS演进之路

Part2:Business with FaaS

Part3:复杂业务场景的实践

Part4:总结与展望

 

简介:

.1688商品详情业务简介

B类商品的详情业务很复杂,首先是面向B类的交易,不像传统的C类交易的买卖关系,可能有很多交易渠道比如现货、分销、加工定制,每个渠道的交易方式价格都不一样,这样导致交易渠道是复杂的。

第二有很多垂直业务定制的需求,比如B类里消费品的赛道有工业赛道,不同的行业需要定制,不同的产品详情的样式与功能完全不一样,像新做的功能。电商的促销,天天要应对促销的活动、大促营销氛围多变。几个因素叠加在一起成为一个复杂的业务场景。

技术架构,在没有改造之前一个典型的业务逻辑组织团队。

底层是商品的基础产品,部门基础的商品中心的产品,对接集团的中台,商品的能力沉淀领域模型的服务和一些核心的商品逻辑,往上面对商品逻辑的业务场景的服务端就是无线服务端,面向前台的页面去设计视图模型,做一些轻量的逻辑和字段映射的编排,再往上的搭建机制,搭建平台有对应的页面路由控制组建的顺序

 Intro

阿里集团-国内贸易事业部(CBU)

主要负责1688.com以及手机端阿里巴巴的app,这两个业务是 B2B 的业务,更多的消费者接触不到。

面向B2B电商业务(批发、分销、加工定制)场景为小型企业提供零售批发、分销、加工定制等。国内最大的B类电商交易平台阿里最早的业务

For APP端

大量的电商导购类业务场景负责 CBUServerless 和工程效能参与集团FaaS统一战役。

站在业务和技术结合的视角分享 Serverless 落地的实际经验。

 

Part1:1688的FaaS演进之路

阿里集团在14、15年时主要的战役,大目标 All in 无线。业务状态的背景是移动互联网刚刚兴起,需要将大量存在的 PC 端业务复制到移动端,设立无线服务端,将 PC 端存在的业务通过微服务体系进行调用,面向前排的移动端业务进行轻量业务逻辑编排和 UI 层映射,最后经过移动端网关像搬运工一样将这些业务从 PC 业务搬运到移动业务。

移动互联网的功能迭代非常快,业务的迭代速度比之前快很多。传统的微服务体系构建、发布、调试时间效率与需要非常频繁的迭代业务逻辑层的编排和 UI 层相关的改动 match 不上。需要一种新的能力支持更好的业务,在15年探索类似 Serverless 的技术。

整个1688主要以 FaaS 能力为主,FaaS 能力主要落地有两个阶段,第一个阶段2015年部门内部自研一套 JVM 动态加载系统来实现快速发布快速上线部署的效果,第二阶段2020年FaaS 能力上行到阿里云函数计算。

1.第一阶段MBOX:基于JVM动态加载机制的FaaS系统

MBOX 主要特点、核心思想是充分利用了 JVM 的热加载特性,JVM 可以在线上不重启,动态的将外部的 Class 字典码加载进去,成为 JVM 正在运行的实例,在此技术之上构建了自己业务的 FaaS 容器,FaaS 容器可以从外部接受一段代码,可能是脚本、函数,对代码进行实时的语法编译,在做代码加固,注入集团内部中间件,通过自定义的 Class Loader 加载成线上正在运行的 JVM 中,实际运行的 Class 对外提供服务,实现了类似热加载机制的函数效果。在整个无线端需要快速迭代,需要寻找类似 FaaS 的能力。

系统的特点相对于传统服务在线开发脚本式编程,写一段代码实时编辑所见即所得,研发效率非常高。热加载更新的机制实现秒级的发布,业务服务上线的迭代效率高。

对于使用系统的人来说其实是 Serverless 的服务,因为所有的运维、机器的部署包括服务需要多少时令,都由 MBOX的提供商承担。担任了类似云厂商的角色,对于使用 MBOX 且服务的开发来说不需要关心任何事情只关心写代码。

在这套机制下迈出了 Serverless 的第一步,在长达五年的时间系统承载了包括1688超过十万的 QPS 业务并且线上最高超过1500个函数,在整个无线扩张业务阶段立下了非常大的功劳。

随着时间的推移,系统的弊端也明显的体现,第一个隔离性问题,根据 JVM 做热加载机制,JVM 的隔离性约等于没有。

对于 MBOX 的维护来说成为吃资源的怪兽,有非常多的资源占用,但没办法判定是哪个服务资源占用,因为做了业务集群的隔离,因为 JVM 的隔离性,拆了很多物理集群尽可能实现服务的隔离,导致应用变成了有状态的应用,每一个集群加载的脚本服务是不一样的,没办法做弹性,不是无状态的应用。在这样的背景下要进行技术的换代和升级,18年开始探索 Serverless BaaS 相关的成熟实现。最终与阿里云 FC 团队进行共建,阿里云团队在建设和收拢整个集团内部统一的 FaaS 能力。作为 JVM FaaS 能力的先行者与阿里进行比较深度的共建。

2.阿里云FC:集团FaaS统一方案

Serverless Serverless 底层K8s 来提供容器相关的知识,容器之上重点 Runtime 层业务函数明细的设计。第一点使用 Sidecar,Sidecar 去年和微软一起共建一套面向 Serverless 环境运行。之前的微软、FaaS 系统的业务代码的容器与中间件的内容吻合在一起,导致启动非常慢,弹性难。实现语言中立,阿里系的中间件主要以 JVM 为主,在很长时间里 JVM 都是作为服务端开发的主流语言,如果想逃出框架做申领很难。特点编程语言中立并且 FRAMEwork层的 Runtime 可以支持定制,扩展性更强。Sidecar 构架,让整个业务容器更轻量,弹性更容易,启动速度更快。实现了容器化隔离并且实现高密部署。弹性伸缩,按量计算的能力。

4.回顾过往十年

集团第一批大规模落地 Serverless 的部门:超过80%的业务参透率,积累5年的经验沉淀

 

Part2:Business with FaaS

Business with FaaS结合使用 FaaS 的经验探讨 FaaS Serverless 在实际场景进行落地时会有哪些问题、怎样去解决、是否和想象中一样非常好。

1.Serverless 之殇

.存量业务的改造

想要拥有 Serverless 的能力难道要将正在运行的 Serverful App 变成 Serverless Function 吗?像飞机正在运行不能让它停下来同时要给它加油甚至换引擎,风险非常大收益不好衡量,要找到一个适当的平衡点。不是一定用 Serverless 这种方式。

.FaaS 碎片化问题

传统微服务应用里比较庞大,高内聚的应用。绝大多数独立业务的场景,业务相关的部门会放在传统的微服务应用里。同一个场景之前是一个微应用解决,用 FaaS 后多了30、40几个函数。同样的业务扩张函数很难管理非常分散。

.研发效能的瓶颈

Serverless 能提供 Only Focus on Business 超级提效的研发体验,真正落地发现并不是如此,研发效率更多的是关注其它的问题

2.存量复杂业务如何与FaaS有机结合?

.BFF模式

绝大多数同学好理解是常见的主流做法,将传统的 Serverful 逻辑进行抽象,在业务场景分为两种,一个代码变动层,特点逻辑轻,产品的需求。将变动层抽象出放在 Serverless 函数里,实现了 BFF 层的效果。前台消费方直接通过函数调用 Serverful App 有一个缓冲的区域,实现更快的发布和交付更少的运维。包袱丢不掉但可以集中80%的经历有提效的效果。

适用场合:前台类业务应用,如M-V-C架构中的 Controller 层。

.扩展点模式

比较适合中后台场景,业务里的电商中台商品中心。

模式非常复杂业务逻辑多,历史悠久,可以将复杂的业务程序进行抽象。现有的业务逻辑可以将业务抽象成扩展点的方式,底层逻辑可以完全不动,只是修改代码结构让它成为一个扩展点的实现,有了扩展点可以用 FaaS 实现。在代码的架构定义出清晰的扩展点,可以让 FaaS  作为扩展点的实现,可以通过机制提供函数,让函数提供的服务成为 Serverless 业务逻辑的一部分,相当于是逻辑的提供者。通过这样的方式实现未来业务增量的迭代,可以让原来封闭式的架构,实现架构的开放。中台的业务场景很难让业务方定制这种模式后,业务方帮助进行定制业务逻辑,实现架构的开放。

适用场景:偏基础类业务应用中台型场景,需要服务多业务方。

3.避免 FaaS 的碎片化问题

.第一做编辑界面的权衡

函数集符不完全是函数,在定义里 Serverless 所谓FaaS 里的 Function 更接近一个微运行时或者微应用,在里边可以做很多事情。没有必要做到极致,做一个函数的代码就变成一个独立的函数运行,可以扩展函数的定义。

结合之前做完 loss 老系统之后的经验和教训,那时是纯脚本编程导致函数数量膨胀的很快,而且难以管理,代码很难做。共建 JVM 函数的 Runtime 的编程界面时,制定两个原则,第一个原则做的是 Micro App 不是 Single Function。这样做一个函数提供多个接口,并且接口之间能实现相互复用,可以避免函数数量过于膨胀,第二个原则整个代码工程结构是 Code Project 一个完整的项目工程,而不是一个 Single Script。通过这两种方式可以实现整个 Serverless 函数管理。

面向开发者可玩的空间更大,数量不会像传统脚本的方式膨胀的太快。

第二点在基础上建设服务市场的能力,即便采用了 Micro App 的方式,函数比传统的微应用多很多,不是一个数量级,函数很轻量创建起来没有心理负担,防止泛滥成无法管理,函数在 Code Project 工程里做一个插件,插件会在编译时自动打包,自动扫描代码,判断函数属于哪个业务域,然后做函数组的划分、函数的划分以及函数内部每个接口详细的划分,对接口维度进行接口所属团队、维护人以及功能的业务描述和自动文档的生成。

通过自动上传和采集分类归档的方式建设服务市场的标准,让所有的 FaaS 函数有个地方能看到每个业务团队下有哪些函数,这些函数具体做哪些功能,维护人是谁,通过这种方式有效的避免 FaaS 的碎片化问题并且对函数进行裁剪时有迹可循,这是对 FaaS 碎片化问题做的两个尝试。

.编辑界的权衡

代码复用 研发效率 隔离性 可维护性

Micro App,Not Single Function

Code Project,Not Single Script

.建设服务市场

分类归档+自动采集:建设标准

4.研发效率的瓶颈在哪里?

Serverless 从诞生开始就号称能够 Only Focus on Business,如果只是生搬硬套将 Serverless 运用到环境中会发现真的 Only Focus on Business了吗?

在初期的 Serverless 中确实发现写代码效率高很多,但从整体的业务团队、业务需求交付的角度包括产品和运营反馈在整个大环境的反馈来看研发效率没有太大的提升。阿里内部有研发者幸福度调研结果一天有14.7%编码,剩下的时间在开会、联调、沟通、做方案设计等等。运用 Serverless 实际可以将编码的时间裁剪掉,但其他的时间很难用技术颠覆掉。如果站在业务团队的角度,真正想要提高业务效率只靠一门技术是不能实现的,更多的是关注技术之外的事情,比如很严重的沟通和协调效率之间的问题。在传统的前后端模式里,如果想要加强沟通协作的效率,可能采取工具性的方式,比如后端与前端之间通过自动生成的文档、样例以及幕后数据的一些方式来实现前后端工具化的协作,尽可能降低沟通成本,但这种方式可以闭环由一个人员从头开发到尾,消除了沟通的鸿沟和沟通的成本,Serverless 解决研发效率更多从这个角度出发。

技术之外:沟通和协作效率

方向一:通过工具优化协作流程,降低沟通成本 方向二:全栈开发,消除沟通鸿沟

总结来说在研发效率 Serverless 不是提效的银弹,研发效能提升的关键在于人与技术的结合。要结合实际场景、业务团队以及组织架构。

技术架构改造

 

没有改造前基本逻辑简化基本上是以下模型

商品的后端包括无线服务端都是采用传统的微应用 Serverful App 来实现业务逻辑,包含商品逻辑的核心业务逻辑以及无线服务端前台业务逻辑除此之外还有集团中台,都是微服务的方式提供 RPC 接口给前端进行消费。

第一个改造引入 BFF 层先把前台业务逻辑,无线服务端,提高研发效率,这逻辑变动最多,发布最频繁。解出来后先将发布迭代开发性能做实验解决。

当提供了 BFF 层后意外收获是有了 BFF 层后做了UI 逻辑上行,前端有多种实践,多端代码的逻辑不同。如果将逻辑交给客户端做,可能实现两端逻辑不一致,如果想做跨端方案,组件逻辑非常复杂,所以将业务逻辑上新到 BFF 层。前端的组件非常干净只做展示,让多端的差异得到了很好的抹平并且跨端的方案得到了发展。

 

核心业务逻辑定义的扩展点,扩展点允许业务方通过函数的方式来把定制的业务逻辑进行实现。比如工业品和消费品的场景都需要定制价格和库存,通过扩展点的定义,业务方可以写一个函数实现价格和库存的逻辑直接接进,整体不用任何改动,通过这种方式实现了封闭架构开放化,更容易支持定制逻辑。

比如当前业务后端想要定制一个属于自己业务场景的业务详情,可以通过扩展点加前台函数的方式自己完成此过程,不需要与商品的后端、无线的服务端进行沟通、协作。沟通和协作成本比之前底很多。前后端是分离的在前后端沟通上对领域模型和视图模型都做了抽象文档样例的功能减少沟通的成本。

5.前端工程师开发项目时,创建一个项目做脚手架,怎样与 Serverless 相结合?

一个完整的业务链路包换几个部分,第一部分前端的组件,第二部分可能有一个业务的函数工程,第三部分有一个同样的接口。

目前在开发全栈式的开发流程,比如有一个业务脚手架的功能,在对应的业务场景通过脚手架一键创建出组件,组建的模板函数的模板以及对应的 RPC 接口的调用装,通过这种方式无论是前端的开发还是后端的开发,在整个工程初始化后可以直接写代码,并且函数组件消费的数据源 real model

与函数强绑定,做一些预发的样例实时采集幕后数据这些方式来加速前端组件和函数逻辑的结合度,能更好的结合在一起。目前探索的前后端相关事情的一些方式。

前端的发明有没有脱离本地 ID

 

Part3:复杂业务场景的实践

1.Only Focus on Business 的研发实践

定制一个业务场景以架构组织为例,业务方团队需要实现业务扩展的函数 FaaS 里有定义好的接口,以及接口的实现来进行业务逻辑的定制,业务逻辑定制之后商品的领域模型定制后会自动更新检测出来添加了哪些字段生成一个文档给前台视图层开发者进行参考,视图层的入参就是对应的模型,在里面做简单的 UI 映射,面向前台逻辑的业务封装,也是一段函数编写逻辑,这段函数发布完后形成视图模型是面向 UI 层的 real model。

前端的开发者直接消费模型。从理论上看不断优化的过程中包括技术站语言通用的情况下,完整的业务逻辑有可能实现从业务扩展点到视图层的逻辑再到前台 UI 的逻辑一个人完全开发。

 

 

2.提效结果

总体来看研发流程比之前高效很多,以数字看实际的业务效果。引入 FaaS 能力以及架构之后在业务场景里发布的等待时常降低了80%,FaaS 的发布只需要1分钟,但原来传统的微服务发几个小时。

发布频次持续提成和持续交锋的能力提升了300%,从产品的感知看需求的吞吐量提升了20%,最关键的是在保证吞吐量提升的情况下人员投入减少了。原来的业务场景服务端需要两个正式员工投入现在只需要半个正式员工加一个外包就可以做到业务逻辑的 cover,整体提升效果好。

 

Part4:总结与展望

站在云原生的风口

小结

  • Serverless无疑是一轮新的革命,FaaS等核心技术所带来的生产力提升已经得到了有效证明
  • Serverless的落地要结合实际业务场景有的放矢,不要一杆子捅到底。不是推翻所有的微服务都是不好的,都用 Serverless,不现实。
  • 任何技术都不是提效的“银弹”,研发效能的提升更多要站在人的角度去思考

虽然目前公有云 FaaS 能力比较成熟,还是有很大的进化空间,比如目前的冷启动问题弹性的能力,在业界正在探索以两者结合实现一套新的标准 FaaS 体系,有更好的弹性和资源利用率。FaaS 不会完全替代传统微服务,微服务是运行在传统的 FaaS 体制还是K8s 体制,微服务在 FaaS Serverless 在很长时间内有效的共存,团队要做好准备,有效的结合。在组织架构、研发角色定位上 Serverless 可以看到全栈和低代码开发,这种一栈式开发逻辑在未来的业务场景和未来的业务团队尤其是前台的业务团队来讲越来越成为趋势,这种方式是最大实现技术提效的方式。

 

答疑:

低代码怎么做 Serverless 的 UI 层

Serverless 是解决运维问题,低代码 Serverless 化,低代码通常是搭建出来的网页,打包成一个简单工程用 Serverless 交付,CI 是整个研发链路最右边是部署上线,左边是研发,是整个研发上线中间的环节,持续部署和 CI 这套东西用 Serverless 很好的解决 CI CD 的问题。

 

如何定制一套 Serverless 应用部署流程

 

前言:

何为 Serverless 架构,本身应用是以 Serverless 为计算核心 ,存储、应用依然会需要应用。架构往往是抽象的,有没有一种可能开发者以代码的方式去把它开发起来,快速的部署上去,值得思考。

目录:

一.弹幕应用部署展示

二.弹幕应用设计到落地原理解析

三.Serverless开发者工具模型(SDM)介绍

四.定制Serverless应用部署流程

 

一.弹幕应用部署展示

做一套实操的演示,在应用市场找弹幕的应用,打开可以看到整个预览效果以及要部署应用需要提前准备什么东西。Serverless 本身是 BaaS 和 FaaS 结合。网关和网络也要提前准备,基本上是免费的。将 BaaS 的连接资源准备好开始一键部署。

选一个本地的目录下载。首先需要自己的自定义域名,花40元在外网申请一个,名字随便命名。因为做了动静态分离,需要用 OSS ,准备一个 Bucket, 要保证 Bucket 是唯一的。需要用到业务存储部分。

创建数据库,创建实例。进入配置页面,弹幕应用有大屏幕、网站、手机端、管理端,几个服务。两个函数,控制函数用于收发的弹幕,第二个与 Web socket 触发连接的事件函数。还需要网关等基本东西,把字节必要的别名准备好。Run 起来后这些工具会把所有的组件,准备好的资源做一次执行,将几个前端部署到 OSS 上,把函数部署到函数计算上,将网关相关的路由配置好,最后将 DNS 的解析设置好。

创建网关路由的阶段,因为本身弹幕应用用了11个路由。将字节的域名放在浏览器里。缺一个步骤,有一个环节没有找到阿里云的 API OSS 的域名绑定,这一步骤必须手动做一下优化。弹幕应用并不是一个很完美的应用,还可以继续将点赞以及管理后台做更加详细一点。

创建好后提供一个专门的访问链接。后台可以设置控制拦截大家的弹幕,后面会讲详细的架构。一个复杂的弹幕应用部署完毕。

弹幕背后实现的原理。

需求的来源是小江同学提的需求,后面全部的工作都是由前端工程师去 cover,用 Serverless 时想到它的场景,场景有时不是自己凭空想的。

如果把整个 Serverless 技术掌握的非常透彻,工具的应用比较扎实,可以在很短的时间内将整个业务的需求 cut 掉。

Serverless架构的弹幕应用需求说明

.弹幕显示位置:全屏幕播放模式:实时播放

  • 是否显示头像:随机显示,类似Github(也可不)字的颜色:彩色或者黑色

.屏幕背景:固定壁纸我可以给你·速度:不是很快

.审核:需要管理员审核放出

  • 点赞:可以看到点赞的红色心从右下角飘出

 

二.弹幕应用设计到落地原理解析

1.弹幕应用预览

整个弹幕的架构,前端工程部分有三个端屏幕段、玩家端、管理端。需求用 Web socket,函数本身是用完即走,本身不适合做长连接。应该有一个网关承接 Web socket 的连接,用阿里云网关做连接。有两个 socket 连接,一个是设备,包括屏幕的设备、后台管理会连上去做全装工。是否是管理员拦截的,如果是不会把弹幕推到屏幕上,会先推到管理后台。下载是一个相对完整的 Serverless 架构。

 

 

 

2.弹幕应用访问架构

通过域名访问,经过 dns 解析到网关,网关主要是承担了路由分发的角色,根据不同的路径,是网站的路径、大屏幕的路径、后台管理的路径,会帮做转发到函数,通过事件驱动。这个架构可以 cover 一个外部应用场景。虽然 Serverless 本身有自己的局限性,如果将 Serverless 也看成 BaaS 的服务一个组件,组件在结合后台的其他服务,数据存储、网络,把这些整个整合后能力可以延展到无限大。

 

演示经过了很多过程,工具做了很多事情,处理本地的代码压缩,分化到 OSS 上传到函数计算。

工具本身模型的设计原理

 

三.Serverless开发者工具模型(SDM)介绍

1.ServerlessDevsModel抽象模型展示

  • 人(应用开发者及组件贡献者
  • 货(Serverless应用及组件)
  • 场(开发生产过程)

人指开发者分两种,一种是使用开发好的代码应用,另外一种是做应用的人。可以是互帮互助的角色

场是构建整个 Serverless 的平台,这两个角色会在厂里做业务的开发、贡献自己的应用组件。

货虽然指 Serverless 应用,有可能是一个非常简单的 FaaS 的应用,有可能是非常复杂的 Serverless 架构的应用。

有了这个模型后可以在小生态里做闭环,通过 Serverless 技术来满足各式各样的开发诉求。

 

2.ServerlessDevsModel详解说明

整个模型拆分,除了人员模型也包括数据仓库模型,自己的应用和组件最终存储到哪,别人是否可以自建变成自己公司沉淀的数据仓库,分离出这个模型让 Devs 使更多同学在自己公司搭建人、货、场的体系。

工具平台模型把应用模型单独拿出来做一个详细的介绍。需要云厂商不同的信息,腾讯云的秘钥、华为云的秘钥、阿里云的秘钥都是本地工具连接云上资源,需要极为小心在本地保管好。后面会做关于 Serverless 应用安全开发方面的实践,教大家怎么避免不小心把秘钥信息给透出到开源的代码仓库上。

 

3.应用模型(web)应用

展开应用模型

 

可以把整个弹幕的架构看成是一个应用,应用是自己做的一层抽象,根据刚才弹幕的例子把它看成整体的应用。每一个子的部分叫做服务,比如网关是一个服务、FaaS 后端是一个服务、静态资源也是一个服务,这些抽象的都会体现在代码配置里。将抽象做成代码配置,只需要根据提供的相关的使用文档将该填的配置填好,就可以正常将流程走起来。

 

4.组件模型(apigateway)

应用本身是上层抽象的概念,真正执行逻辑的实际上是组件。将代码进行压缩上传,其实是组建的逻辑去执行的,包括网关组件需要配置文件传递的路由信息,包括路由背后是一个的函数。执行以下几个步骤,先找到配置的秘钥是什么,决定在哪个云上。

具体网关的逻辑,网关有一个分组的概念,将一层 APR 做聚合,业务是一个 barrage 的业务,分组名为 barrage,分组下开始创建不同的 APi 最后做域名绑定最终才能通过域名访问。

整个流程下来可以完成非常好的闭环,把网关自己的组件逻辑处理掉,接下来交给下一个。可能下一个是 dns,dns 也会拿到它的返回结果,会返回自己的域名让 dns 做绑定。

工具本身做了很多事情,处理本地代码、压缩、分化到 OSS

 

四.定制Serverless应用部署流程

1.弹幕应用落地过程

简单的说明对业务需求的梳理,基于业务结合自己掌握的知识做架构的设计,更细的实现每一块的开发和研调。初始化一个前端的项目,细化 UI 调接口,初始化函数,在后端函数写各种接口,最后将前面的工作成果做整合,通过工具罗列起来搭成工作流,最后执行。

最后的重点是最后一步,前面容易理解,后面与自己工具链的规范相关的核心是组件。

需求梳理:梳理需求的逻辑列出现实所需要的基础云资源

应用架构设计:以基础云资源搭建整体应用架构

开发调试:借助s工具云产品控制台进行开发调试

 

2.服务模块拆解

上边的解耦拆分

组件定制-初始化

ing s init→Dev Template for Serverless Devs→ Component Scaffold

 

3.组件定制-开发调研

.安装依赖

.查看入参

.模块联调

怎样做组件,怎么样调试

做一个域名解析的组件,通过命令行指令初始化提供的模板。在模板上做调试修改,单独对 dns 做部署操作。先用s指令打一个测试,新建一个目录做组件的初始化,ts 工程的目录。提供一个 example 主要做测试,可以打s 指令。启动项目,整个用 ts 做编译,在 example 上测试s test,将 test 方法做输出,参数包括了从 sk 组件传入的 crops 以及隐含了设置的秘钥信息。秘钥信息是调用云端资源的重要的东西。做组件可以用这样的方式尝试测试。

单独将写好的 dns 组件打开,把用户传入的 dns 做绑定,打一个断点。组件是更加聚合性的云端资源的逻辑,很多云都有自己的服务,网关服务、OSS 服务,组件可以对云做专门的映射来处理云服务的需求。断点进入,一步步向下走去具体查看入参有哪些,决定相应的逻辑处理,相当于实际的编程。组件改名字,改成 dns 地址。确定当前组件所在的目录,复制。

 

答疑:

公共方法调用函数

最后一层加了一个网关,所有的请求都会经过网关回流。在真正的企业实践里,希望函数本身通过 vpc 的访问方式,更安全。在刚才的 keys 上函数之间的调用需要绕一层,绕到网关里在打到 http 触发器

一个函数有很多组件有基础函数还有其它函数怎么权衡

具体影响的数值没有实际测试,如果觉得影响性能化,可以加预留,让整个运行稳定。选择快一点的语言。产品在做深刻改造,以及基于老的容器方案,现在底层基于底层服务商。

整个热启动的时间大概为55毫秒,如果在理想状态下云主机上可能比55毫秒更小,当数值达到一定程度时,40毫秒50毫秒是非常敏感的业务,99%的业务不会对这时有太多顾虑。如果是0.1的业务对时间很敏感, AK 网关调用可以走内容机制不会慢,可以用冷启用优化方案,优化加在一起不会对业务产生不可控影响。

依赖的问题,函数会依赖底层函数,Serverless 给人的感觉是资源的利用更加细,想要依赖基础的东西,需要通过网关的形式走,直接引入代码库的方式直接走。比如阿里云函数a依赖底层函数引入本地的一段代码,代码因为必要原因必须走公网的形式,完全没有问题。

网络分为公网和内网,函数被其他几个函数依赖,没有放在层里,走的内网,效率不会低很多。内网的流量基本上免费。

Serverless 冷启没有做到非常理想的状态,作为服务商做相关方面的探索,考虑替换现有容器的方案,目前不成熟,可以继续关注。

 

GiteeGo x Serverless Devs让持续集成更简单

 

前言:

gitee 一直在做国内开源的活动,与Serverless Devs 合作,做了分类,如果有合适的 Serverless Devs 的组件或项目,可以放在 gitee,用开源的方式完细。

gitee 代码托管·研发协作管理平台

 

目录/TOC

一.我眼中的 Serverless

二.现有Serverless的困惑/困境与机会

三.如何在 Gitee 上使用 Serverless-Devs

  1. 四. Serverless-Devs+Gitee案例展示

 

  1. 我眼中的Serverless

Serverless 与 Serverless-Devs 是完全的两个东西,Serverless 与之前的开发有哪些区别,给我们的生活带来了哪些颠覆,开发更关注代码,运维关注运维的工作,这些与我们有什么关系。

Serverless从复杂多变的云上环境出发,目标回归纯粹的业务开发。

这为开发者提供了全新的 DevOps 体验,让业务更专注业务让架构更加直观易懂。

不管是业务入门还是学习架构,Serverless是不可多得的选择。

Serverless 更多的是运维上的东西,产品经理经常提出无厘头需求,不太关注怎么做的但就要。从开发的角度理解产品经理是比较困难的,开发更多的是将复杂的业务逻辑简单化。产品经理不理解开发,是不理解复杂度。

两者的关系从Serverless 云厂商理解为开发,用户不太关心网络怎么样、服务器是怎样的甚至具体到机房,机房的交换机一般有四个网口,内网的一条线、外网的一条线、备用线。在日常开发和运维工作里运维机房的级别。

随着实践越来越复杂,最终看到的 Serverless 是怎样的。创建一个工程引用一个包,一个 SDK,无后端开发,直接用 CURD 做。完全不需要后端,前端顶 SDK 后对后端的 DB 做 CURD,都是 Serverless 上层应用的体现。是非常新颖的方式,让业务不用 care 太多 。但在从业者来说如果只懂基础的结构是比较危险的事情。行业会慢慢两极化,不会永远不会,能懂的人更懂,中间层会断掉。

Serverless 提供了一个场景,不断的深入底层架构级别,运维机房的级别,但如果是 IVE 或 VE 的角色,去接触 Serverless 可以打破右层向下的壁垒的门槛。可以关注领域的技术,包括中间用了什么,在网络层、应用层怎样去解决的一些具体问题。

把过去几年的东西重新包一下,包的比以前更彻底,以前可能有虚拟机、Docker ,现在 Docker 的编排已经看不到了,甚至不理解在本地,远端跑了一个 Docker。各个云厂商将自己的能力,APi 以及实践向外放,过程是学习不可多得的机会。

结论

.抛弃传统架构的运维负担,让 Ops 更简单。

.高度灵活拓展,低成本,见效快

.按量付费

.....

 

 

二.现有Serverless的困惑/困境与机会

研发:对应用本身精细化程度要求高

架构解决运维复杂度问题,但没有解决业务研发的复杂度问题。

数据:数据持久化的处理

从传统架构转变到Serverless架构,需要对数据持久化有一个新的认识与处理方式的转换。

测试:服务集成测试复杂度提升迁移:业务迁移代价

平台:需要更多的SAAS厂商支持,否则容易出现平台锁定。

此行业处于稳定的爬坡期,为什么会处于爬坡期。因为技术多数是承接业务或现实的需求所增长出来的,现有的计算能力在不断的向前翻的情况下,业务的膨胀并不是能跟上的节奏。过于新的技术是否有诉求,一定要现在 ready 或者怎么去论证是很困难的事情。

人工智能AI 能够自动编排、自动调动,事实上做到这层,对现有业务的助力,大部分用户,用服务的平台或开发者对于调度感觉比较小。

今天上了一个平台创建一个服务,比平时少了几秒钟的延迟。但为了延迟很多云厂商投入很多人力和资源去解决这个问题,保证它的高可用和高可靠。

 

眼下遇到的第一个问题膨胀出来认证价值的问题。第二个问题对现有技术的挑战,从教育的角度。Serverless 很多人听过产生各种各样的歧义,大部分开发者开始学的简单的 HTML 快速的入门,直至从业两三年,不会太多接触架构级别,行业、技术很卷,破解局面的方法,读书,读书破万卷。

面对新东西,像是一只未知但很凶猛的野兽。建议可以大胆的去接触了解。

Serverless 只解决了运维的复杂度问题,运维不用管多少台机器,只要按量去花钱、需要的时候调动,但应用并不是这样。

一个后台包了20几个模块,将它解耦能够让它用函数调用的方式去做,而不是业务上的强耦合,很多的服务是不够的。对于nfc的转型,不是全部去拆而是先把能够做的小的部分,或者能快速拆出来的部分,是所谓的降本增效过程中解决的最关键的部分。其它部分做了都是在拖慢后退,提高成本。

数据的持久化,一旦无状态后数据的持久化是头疼的问题。但从云厂商角度看,提供了很多数据库对象存储服务,数据库是好解决的问题,数据除非高可用做的非常彻底。不然会有各种各样的延迟,但目前使用云数据库的成本比较高。对一家企业所有的服务都转为云部分,云数据库徒增的成本比将现有的服务切成 Devs 所降下来的成本高。

如果想要尝试开发或项目落地时可以从这个角度琢磨,分析合不合适。

对于测试好的是面向一个函数,测试用力比较好写。但业务上最复杂的是为了去满足功能或最后一个接口,连着调一堆接口,整体的服务集成测试复杂度提高。如果本身的项目即便拆解的非常好,但在集成测试做的不好,要求非常高。

 

业务的迁移代价是比较现实的问题。

拨开迷雾,现有Serverless的机会

研发:对应用本身精细化程度要求高

架构解决运维复杂度问题,但没有解决业务研发的复杂度问题。业务的稳定取决于研发水平的完整度,技术债迟早要还。数据:数据持久化的处理

业务云化,依托云厂商的数据存储服务可以很大程度解决数据持久化维护的问题。

测试:服务集成测试复杂度提升

大量CI/CD工具的能力是可以与Serverless共存的

迁移:业务迁移代价

业务架构演进往往是一个缓慢的过程,Serverless对传统架构不会产生太大的侵入与破坏

平台:需要更多的SAAS厂商支持,否则容易出现平台锁定。

越来越多的厂商重视并发力Serverless Serverless-Devs 跨云厂商能力的支持

Serverless 解决了运维测的问题,研发测不是它的问题。如果产品本身的技术化程度不高,随着技术的淘汰迟早遇到性能瓶颈。如果不跟着学新技术自然卷是很自然的事情。

数据持久化在业务云化时基于云端的数据存储服务是必要的,不管是在高可用还是服务时间的角度说已经是现状。

测试是最简单的。平台锁定已经不是问题,依赖于上层设计与解决方案,越早认识问题能做的准备越多。

 

三、如何在 Gitee 上使用 Serverless-Devs

1.如何用 Gitee 的 CICD 产品做持续集成

什么是GiteeGo

Gitee Go是Gitee全新推出的一款CICD工具,可提供持续集成、持续交付(部署)能力,帮助企业不断提升应用交付的质量和效率。通过构建自动化、测试自动化、部署自动化,完成从代码提交到应用交付的自动化。通过交付流程度量,发现效率问题,并推荐优化方案。

下图是描述持续集成

如果想在代码提交贡献,与在公司一样,有多个人在写代码时,总有一个写的最菜。之前的方式组织代码评审会,随着工具的使用发现自动化的工具不单单可以解决在生产上的问题,测试场景是更多公司关注喜欢用的。

 

交付到部署的过程中,一般会遇到过程和内容。在集成过程做一些编译构建,是最简单的。作为开发自己给自己做单元测试,服务起来后做基本的接口响应。比如全部为200反应的参数入参是否符合预期。这些过程可以通过高程度的集成解决问题。

通过结构化的方式对应了接口文档,接口文档把功能实现,接口文档可以衍生出接口自动化测试的内容。包括现有测试框架,并不是维护一遍后面都要重来。

交付过程中更多的是做部署、部署发布动作。最简单的每一开发每一功能有自己流水线,除了本地可以推到 test 环境,自己将环境验证。如果业务越庞大越需要,因为本地只有一台电脑,应用是分布式的,应用只是配了其中一个模块,这时测试不全面。

高级的做灰度、蓝绿的流量控制以及运维层面上做的事,大部分情况下,很多中小企业只讲到运维监控,甚至运维监控都没有。一般验证系统好不好,打开看快不快,能不能打开。

2.基于单机版本的Serverless环境的开发部署模式

非常简单的动作不需要测试环境,在本地开发调试时中间不会有太多内容,直接部署到云上环境。

最典型的例子,博客写到代码仓库里,开通后给一个域名,只管写,写完代码后提交,页面自动部署。阿里最早13-15年一个产品 ace,底下是 svn 做的。只要推了 svn 自动拉代码,对应给一个万有域名,每一次拿它做测试环境,每次推代码大概1-4秒中间会重启。拉完代码重启。

Serverless-Devs 目前提供的工具功能大概是一个人。如果团队里面有三四个小伙伴,会出现刚推出来的东西不是自己的,因为隔壁在自己推完以后又推了一把,面对这种情况会出现问题。

好处对个人来说管理非常灵活,对应用来说没有测试。如果是多个人协作,可能面临单点的问题。Serverless 除了用函数调用的方式,现在的 Serverless 是换汤不换药的说法,用的是 Serverless 但所谓的调用链、工具是给自己用的,自己就是这样的产品,但是最后跑了K8、Docker,把应用放进去。本质上对开发同学在相当长时间发现该写什么写什么,很多东西与变化没有太大关系。但需要了解在环境开发不一样的地方。这样结构下将 csd 加进来,在 gitee 上如果做协作开发,如何保证同学在推代码时需要整合,如果有四个人去推代码,最终有一个单点发布,单点发布与传统相同,三个同学写了代码集合,一样要去评审处理。

优点:灵活便捷,调试开发后即可部署,个人开发展者友好小型应用友好。

不足:缺少有效的集成测试多人协作仍然需要单点(个人或特定发布环境)发布。代码协作缺少评审,开发质量难以保障

本地自己调试,Serverless-Devs 提供了本地 debug 的能力,自己调完后像本地自测,自测完成后推到远程的代码仓库。

gitee 目前提供的与 action 差不多的产品能力,可以通过自己编排流程的流水线,触发对应的几个能力。第一个做基本构建,单元测试目前依赖的是开源项目本身自己做的单元测试。单元测试很难在 CICD 上产品化,如果用 Go,用 Gitee 这类框架,自己做集成,最后可以将结果、报告与平台去买云主机,如果手头开发很多,需要的测试环境或并行测的内容很多,用 Serverless-Devs 成本可控,可以起n个通过一两个域名把业务此域名绑上,可以形成几条固定的流水线。比如 UAT、TEST 一些基本的预测环境。

CI先过,很多公司纠结要不要投入很多资源在 CI 上去建设。没有经过自动化门进去做,与做自动化的效率低10%-20%

 

 

自动的测试通过后分叉到 QA。很多公司自动化的提成率没有超过30%,最稳妥的测试是人肉10%-20%。因为开发的代码经常有问题,各种各样的小问题,自己提交上并不是完整的时候会影响后面所有人的工作。在基本的 CI 过完后进入到 Code Review,Code Review 一开始推完代码也可以做。如果有很低的错误这时组织 Review 的价值不大,还要回头再组织。完成两个之后进入 QA 、Code Review 最后集成到生产。通过服务对外发布,有Serverless-Devs 部署,不可能只用一个架构,可能有各种额外的。例如前端资源需要额外的 cdn 的分发,目前这一部分 Serverless-Devs 覆盖,可能有自己的冒烟。没有 Serverless-Devs 就是日常的开发内容,Serverless 解决运维端的问题,提供了监控,不需要发布,本身自己有此能力。上生产 DEBUG 的动作,提供了工具相比之下更安全。基于基础后更多的是循环,不断改进、调整代码、调整业务,团队去落实持续集成做参考。

 

资料文档:

.持续集成:依托于CI工具的构建编译与测试

.部署发布:依托于Serverless-Devs+GiteeGo的部署与交付,满足业务在传统架构与Serverless架构业务并存的发布与交付上的诉求

.相关文档:

Serverless-Devs文档:https://www.serverless-

devs.com/zh-cn/docs/overview/intro.html

GiteeGo 帮助中心:https://gitee.com/help/categories/69

  1. Serverless与GiteeGo集成一本地开发调试

很多同学配置样文件比较头疼,目前 SET Steps 出了 desktop 工具,上边是本地开发,可以在 desktop 工具里去配置应用包括秘钥。可以不生产,但不建议。自测时需要自动化工具帮助解决问题。

  1. Serverless与GiteeGo集成一流水线编排

配置文件,流水线的配置存在仓库里,前面是集成测试,UAT,还处于测试环境的部分。大的企业基础设施强的可以自已做流量控制,通过流量投放去发布。UAT 测试完成后进入预发布阶段,预发布有审批功能、制品的存档。

Serverless 提供了回滚的机制,目前状态大多数应用不好控制。回滚是很困难的事情,比如在生产上换了架包,假设是手动发布或自动发布,一开始脚本这样写,为了平滑去做,架包起一个端口,前端去该配置,改完配置切到端口上平滑重返,把现有的服务干掉。上完线后发现架包是有问题的,发现架包被删,上一个版本被删,这时返回快速恢复。

 

 

 

 

  1. Serverless与GiteeGo集成一效果一览

现有集成的效果,有些测试环境也有 gitee 的环境,以及具体运行出来大概的效果。

 

 

Serverless Kubernetes的落地实践

 

目录:

一.为什么要做 Serverless Kubernetes

二.如何实现Serverless Kubernetes

三.Serverless Kubernetes落地实践

 

一.为什么要做 Serverless Kubernetes

1.K8s 已经是原生业界的实施标准

Kubernetes 是一个开源的容器编排。

通过 K8s 降低运维成本,提高运维效率,提供了标准化的 AKI。已经形成了以 K8s 为核心的生态,K8s 已经是原生业界的实施标准

 

2.面向标准 K8s API 进行 Serverless 编程

Serverless 与 Kubernetes

Serverless理念:

Serverless我们可以理解为云原生技术发展的高级阶段,用户更聚焦在业务逻辑,而减少对基础设施的关注。

Serverless 运维主要包括两部分,一为应用的运维,二为底层资源的运维。

怎样在原生基础标准上做 Serverless

思考:

在K8s上是否也能做到更专注于应用业务逻辑?

Kubernetes 做 Serverless 有哪些优势

 

  1. 如何实现Serverless Kubernetes

1.LaaS 节点免运维

减少对基础设施的关注:LaaS 免运维

 

 

 

三个阶段首先对于原生使用 K8s 关注节点,减少关注节点做托管节点池,相当于用户节点通过托管节点池的方式管理起来,让用户减少对节点的关注。托管节点池需要维护节点池策略。通过虚拟节点和ECI,ECI 是阿里云底层弹性容器池里,通过这种方式真正做到节点免运维。

 

2.Serverless Kubernetes

ASK(Serverless Kubernetes)

 

.基于容器

敏捷部署

安全隔离

生态连接

高移植性

.无服务器管理

无需节点容量规划

无需OS和系统软件维护

无需升级服务器零基础设施运维

.弹性扩容

“无限”容量

秒级扩容

基于容器扩容

.按需付费

没有闲置资源

更高资源利用率

总体更低计算成本

3.聚焦业务逻辑:以应用为核心

聚焦业务逻辑以应用为核心,应用的元素离不开应用部署、灰度发布、自动弹性、多版本管理、可观测性、流量管理。

多版本管理,如果每一次发布一个版本可以管理起来,回滚非常方便。一种开箱即用的方案去解,答案是 Knative

 

Knative 是什么

Knative 是基于Kubernetes之上提供的一款开源 Serverless应用框架,帮助用户部署和管理现代化的 Serverless 工作负载,打造企业级 Serverless 平台。

Knative 具备如下优势:

.在几秒钟内建立可扩展、安全、无状态的服务。

.具有更高级别 Kubernetes应用抽象的API

.可插拔组件,让您可以使用自己的日志记录和监控、网络和服务网格。

.在Kubernetes运行的任何地方都可以运行Knative,无需担心供应商锁定。

.开发者无缝体验,支持GitOpsDockerOpsManualOps等。

.支持常用工具和框架,例如 Django、Ruby on RailsSpring等。

 

4.Serverless Framework:Knative

简单应用模型 自动弹性 缩容到0 事件驱动 流量灰度发布

用于工作部署负载 Serving,用于事件驱动的 Eventing。Serving 本身在 K8s 原生的资源,负责版本的管理,支持流量灰度发布策略此外支持缩容到0。Eventing 提供了丰富的事件源的对接,还提供了 Broker、Trigger 的事件模型,模型是对模型订阅分类的处理。

5.为什么是 Knative

像阿里巴巴、谷歌已经提供了生产级别的 Knative 能力。看到 Knative 被越来越多开发者所接受

 

 

 

三.Knative 落地挑战、应对与效果

开源的项目真正落地到产品,需要接触用户的受界面,建立网关,在网关对请求进行分发,分发时做自动弹性。

阿里云 Serverless Kubernetes 落地方案

典型应用场景

Web 服务托管

  • 自动管理 Ingress
  • 自动管理 Service
  • 集成灰度发布能力

应用Serverless编排

.弹性伸缩

.接管应用流量,可按百分比拆分

.自动集成灰度发布能力

AI服务托管

  • 基于任务队列的弹性伸缩
  • 自动集成灰度发布能力

.Pod 安全下线

.使用 ECI 节省保有成本

SaaS服务托管

  • 用户提交代码自动构建
  • 自动集成灰度发布能力
  • 流量和弹性伸缩

 

1.落地实践:异构资源,按需使用

客户痛点

用户希望通过Serverless技术按需使用资源,节省资源使用成本,简化运维部署。另外有 GPU的业务诉求。希望使用容器化的Serverless,支持使用GPU资源,同时简化应用运维音署(尽可能少的操作k8sdeployment/svc/ingress/hpa等资源),IaaS资源免运维。

解决方案

使用Knative+ASK作为Serverless架构。数据采集之后,通过服务网关访问数据处理服务数据处理服务根据请求量按需自动扩缩容

2.落地实践:事件驱动,精准分发

某客户直播系统支持用户在线互动。消息数据的处理主要有以下技术挑战:

.业务弹性波动,消息并发高。

.互动实时响应,低延迟。

客户选择阿里云的Knative服务进行数据的弹性处理。应用实例数随着业务波峰波谷实时扩容和缩容,真正做到了按需使用,实时弹性的云计算能力。整个过程完全自动化,极大的减少了业务开发人员在基础设施上的心智负担

本身有自己的系统发送到消息系统卡不卡,通过卡不卡事件源,卡不卡事件源也是 Kafka 社区本身提供的消费事件,消费完后转到事件网关,事件网关做精准的调动,通过请求自动弹性。

 

小结

.为什么在Kubernetes提供Serverless

1.K8s已成为云原生业界标准

2.面向标准K8sAPI进行Serverless编程

  • 如何实现Serverless Kubernetes

1.IaaS 节点免运维

2.Serverless Framework(Knative)

  • 落地实践

1.异构资源,按需使用

2.事件驱动,精准分发