从0入门，Serverless 实战与创新：课时1：从0 入门，Serverless 技术及价值
Serverless架构模式
内容简介
一、介绍环节
二、静态站点
三、单体和微服务
四、事件触发
五、总结
首先简单的自我介绍一下，我是阿里云的研发工程师，西刘，也是本次赛道一的导师呃，非常荣幸能站在这里给大家分享Serverless架构模式这个主题。今天的分享会由以下五个章节依次展开
分别第一个章节的话是会深入的介绍一下service概念以及service架构的好处, 234这三个章节的话会以三个比较经典的场景，然后比较一下传统架构和升级到serverless架构以后带来的好处，做一些设计模式的探讨最后简单的做一个总结。
一、介绍环节
我用一下阿里云峰会，粤港澳大湾区，阿里云原生负责人第一演讲的主题，云上开发成为主流，serverless定义新范式。
对于定义新范式的话包括以下这四个东西，大概就是通过颜值化的服务能力前托管，让开发者更加专注于逻辑开发云服务的可编排可复用，提升开发效率，然后serverless产品的架构特性等弹性扩缩容保证了用户从容面对流量洪峰，从功能的交付的角度来看的话，也会缩短交付的周期。Gartner的预测，2025年将有50%的全球企业会采用severless架构。那既然serverless助力企业创新，然后刚刚说定义了新范式，那什么是收理架构呢？那相信大家可能有的人看过这张经典的图
以人类进化的角度来看待计算的进化就是说serverless可能会代表着一个中态，就代表着生产力的解放，会提高客户使用云的效率。
本质上来说，他可以从这个角度来看，可以看出他无需关注底层设施，更高专注于业务逻辑代码带来的收益的话，就是能效的提高，然后资源的利用率会提高。当然就是说，什么是社会生产，就是根据cnc f的官方定义的话，就是说serverless是一种一延伸的开发模式，是允许开发人员去构建运行应用程序，而不需要管理服务器。所以说serverless不等于没有服务器，只是说对于开发者来说，这个serverless可能被影响上托管了，对我来说，我只需要开发用户代码部署应用，然后我对这个应用请求的时候，这个会弹性的扩缩容。因此在有一段时间的话，在那么大影响的话，serverless架构一般指的是一种fast就是函数即服务加bus就是后端服务来解决问题的一种设计，比如说像函数计服务fast这种产品的典型代表，可能有比如说f拉玛达呀，或者说是阿里云函数计算，然后bus的话，典型的像这个S3就awS 3或者阿里云对象存储oss，其实对开发者来说他都不需要服务器管理但这个SERVERLESS的定义，可能就这个东西就说fast+bus，可能就是会让我们对这个serverless定义有一些清楚了，但是他可能也造成了一些争议，比如说现在越来越多的服务就是以前是serverless服务，就是有服务器的服务也进入了solace形态，比如说像fast这种纯按量的也有一些一游形态。但是不管怎么样，servwerless有一个最根本的理念是没有变化的，就是让用户最大化的继教他的业务价值。其他特性，比如说像serverless还有一些特性，比如说no server，不关心服务器，自动弹性，然后按量付费等，其实本质上都是为这个理念去服务的，所以我们只需要关注serverless这个理念就好了。因为有这个理念，我们可以看到很多serverless产品都有这样的特性
，第一个就是全面托管，因为只有云厂商全面托管了，对你来说才没有服务器的概念。然后资源的购买，释放，什么按量付费就不需要去管
第二个比如说是对象程度，我不需要关注存储空间，用大用少，担心预值会怎么样，对我来说我只需要按量付费就好了。所以说还要开箱即用，就是说不需要很复杂的运维；
第三个最重要的有个最重要的就是按量付费，可以看到这些特性，还是刚刚我们探讨的这个东西，其实都是为serverless最根本的理念，让用户最大化的专注逻辑这个理念去设计的，也就是阿里云自己本身也在前面拥抱serverless。有37款产品实现了serverless化，就是从计算到存储，从AI到大数据均有涉及。
从开发者自己的角度来看, 使用好这些收尾产品，实现自己serverless业务的收尾是架构也是一个大的趋势。刚刚说的就是采用那些收尾的产品，然后做一些serverless架构，是一个比较一个大势所趋的东西，那么就是说我们去做一些serverless架构的实践时，有一些延伸心智，就是在你实践serverless架构的时候最重要的心智不是你去选择那些在流行的时务或者技术，攻克哪些技术难题，而是明确专注自己的业务逻辑，这样才可以使我们选择更加合适的技术和服务。对于如何设计应用架构，有一个非常著名的社会实践者，BenKehoe就是这样描述serverless原生心智的。
第一，我的业务是什么，第二做这件事能不能让我的业务出类拔萃，三如果不能，我为什么要做这件事，而不是让别人去解决这个问题，四在解决业务问题之前，没必要解决技术问题。因为人的精力是有限的，组织的资源也是有限的，serverless的理念可以更好的让我们用有限的资源解决真正需要解决的问题，这是因为我们少做了一些事情，比如说服务器的管理，dedorce工具防护管理让别人去做这件事情，比如说银行上去把这件事做了，我们才可以在业务上做的更多。
接下来的话就是说我们会描述一些常见的业务场景，探讨如何使用serverless架构来支持这些场景，为了不使这些讨论过于抽象，我们会使用一些具体的技术实现作为参考。但是这些架构的思想是通用的，可以使用其他类似的产品去实现。当然,我们也会从两个维度去对比，比如说传统架构和serverless架构。能带来了一些优劣，比如从技术角度，我们看一下就计算存储消息通信从衡量的维度的话，我们可以看一下，运维，安全，可靠，可扩展成本等等。
二、静态站点
假设我们要做一个信息展示的网站，比如类似于最早期的中国黄页，或者现在大家都流行的企业门户网站，或者说是个人博客网站，其实信息更新的频率其实没有那么高。它的特点就是，第一展示信息，第二更新不频繁，第三不确定访问量。
架构演进①
就是说按照以前最老的服务器，也就是买一台服务器在IDC机房运行这个站点。然后客户端用户浏览器去访问这个服务器，但这个服务器可能会有淡点的问题，就是访问不确定，比如没有流量的时候，这个机器在浪费，流量一多的时候，这个机器可能就坏掉了。为了提高这个网站的稳定性和可用性，一般会提升到这个架构，前面会加一层负载均衡，然后加多个服务器，然后解决他的高可用性问题。然后可以看到，从这个self的架构传递到serverless架构的话，比如我们选用了两个serverless产品,一个是cdn， 一个是镜像存储。把这个页面发布到对象存储就好了，对象存储它是一个海量存储系统，对我来说我根本不需要担心我的容量空间会不会打爆，我只需要为我按需发布的存储空间内容去付费。然后从客户端的角度来说，我可以直接访问oss，但是如果前面加一层cdn的话，会让你的客户的访问速度得到极大的优化。另一方面，如果访问量不确定有流量洪峰，这个东西都是能帮你去把这些问题给解决掉。如果没有访问也是按量付费的，你不会付出额外的流量成本或者存储成本。同时，在cdn和oss层面上隐藏的层面上，还可以帮你把dedorce这种问题给解决掉。其实你刚我们刚才那个例子就是中国黄页，那个例子可能对当时的马云来说，最核心的价值就是展示信息让世界了解中国，这是他的核心业务，所以serverless就是这么一个理念，就最大化的让你专注我的价值，对我来说我只需要开发这个展示的页面，其他的高可用，按量付费，安全等问题，其实都交给了这个serverless产品去做，对我来说我无需管理服务器，我也不需要对资源做预估和考虑未来扩展，因为oss本身是弹性的。使用cdn会使弹性更小。然后还有一个最重要就是按实际的使用资源付费，这个可能是对我来说能带来其他的价值。
架构延伸②
当然，静态是很好的，但是还有一些动态的东西。有些动态的东西，就比如cdn可能不止可以回原到对象存储纯静态资源的东西，它也可以回原到一些计算产品。比如说函数计算fase ,Fast就是函数g服务的典型代表阿里云的函数计算，或者说是serverless、K8s就Ask或者是阿里云的serverles运用引擎，计算产品。这些计算产品都是有按息付费，弹性扩容的能力。这样你可以看到这种架构延伸，这三个都是成serverless，对开发者来说，他还是去专注在这一块，他的技术业务还是专注这一块。
三、单体和微服务
接下来我们会讲一下单体和微服务。刚刚那个讲的都是静态页面，比如说这个，现在假设有个业务需求，商品详情页。首先，他会有海量的商品呃，更新频繁，动态信息会来源广泛，如基本信息价格运费，评论等等。首先我们可以看到前面的这个ser server for单体架构可以继续支持这种场景，还是可以保留了这种高可用的特性。对所有的逻辑都在一个应用中去完成，然后结合数据库。
这是一种单体架构，但是随着业务的发展，功能会变得越来越多，访问量也变高了。这个时候会把庞大的单体应用进行拆分，拆分成微服务的做法，比如商品详情页面会有一些评论信息、售卖信息、配送信息，都可以对应一个单独的微服务，右图就是我们引进的一个service架构，
其实这种serverless架构看起来和微服务架构比较相似 ，但是他的好处是每个单元都是高度自制的， 比如可能使用客户端请求通过统一的API网关，动态资源，然后函数计算，或者是ASK这种弹性阶段产品。比如说API网关对应A函数，假如A函数就是刚说的评论信息，然后b函数就是配送信息，或者ASK的A 应用，B应用，也就是通过API网站进行预测。回到这种情况，静态资源就是刚刚我们讲的第一个场景，也就是cdn和对象存储。这个时候我们再去想想之前我们讲的serverless延伸心智,去对应一下。比如说我们是否需要去自己购买服务器安装数据库，实现高可用管理备份升级版本，还是把这些事情交给托管的服务，比如ASK,是否可以使用serverless整个数据库表格存储。或者serverless hbese ，实现了这个按需或收容和按量付费。单体应用的话，是需要自己购买服务器去运行的，还是直接把应用托管给serverless计算平台，比如说是sk函数计算或者sae。
这里提到的一些技术问题，都是和我们业务无关的，我们的业务是展示商品信息。所以我们可以想象一下让这个service这些产品去承担更多基础设施，或者说流量管理或者安量管理，让我们只专注于说这个商品信息的这个业务价值，这样我们将最主要精力集中在商品展示信息的需求上。
架构延伸③
因此的话，这个还架构还有个延伸，比如说这个微服务内部是通过阿里云应用或ask这种去实现。这里还有一个比较流行的模式，叫Bff就是baking for flat flat定制的后台，这个也是备受全单开发工程师推荐的一个东西，针对电脑和手机的不同的应用,针对这个调这个接口的话进行各种适配，这个适配其实可以是通过这个方式来做一个函数去实现的，前端就可以把这些事情给做了，微服务的后端的话要提供原则的接口，然后数据的聚合和裁剪可以完全通过中间的BFF解决。这在全南工程师里是特别流行的。
四、事件触发
接下来我们还是以业务需求为导向。比如业务需求，买家秀首先会发表视频、评论。对于后台服务需求我们需要对视图片进行缩放加水印然后 审核。同时呢，会对视频做各种格式的转换审核。这种事情会比较复杂，如果这种架构，也就是多媒体文件的处理架构大致经历了以下的演变。
结构演变
比如说第一种最简单的也是最传统的。就是发表的图片，或者这个视频直接上传到服务器由服务器处理完成，然后保存在服务器。第二种更基本，更传统，非常弱。就是引入一些serverless存储产品，比如oss还有流量加速cdn，然后把图片或视频上传到服务器，服务器直转给oss同时发一个消息告诉另外的服务器，这个服务器可能CPU能力比较强，算力比较强的。接收这个消息对oss视频进行转码，或者加水印处理完毕，再保存回oss。最后显示的时候是通过CDN加速的，可以理解成微服务的服务架构。然后我们进行下一步，进一步提升记忆事件触发的serverless架构。也就是用户直接直传这个视频到对象存储，对象存储直接利用fast和事件源的集成能力直接触发函数的执行。函数的逻辑就是对视频进行转码加水印。或者说调用第三方的审核服务。之后把处理后的视频保存回OSS，OSS通过Cdn加速到客户端显示。这样我们可以看一下这三种架构，可能会感觉到serverless架构的好处。
其实我们可以想一下，serverless架构解决了哪些问题。
第一个问题就是如何处理海量文件，走单台服务器空间有限，购买更多的服务器去做文件服务器；第二个是如何扩展WEB服务器web ，web这个应用服务器是不是适合做CPU密集型任务；第三个是如何解决上场的高可用问题。比如说slb是有带宽的，就像oss，她可能做对象存储产品的话，可能对上传的带宽，上行带宽。还有显示的时候，这个下线带宽的高可用，或者说是对于你上传视频，忽然来了一大波用户上传这个视频，对忽然一下要很多计算资源的时候，你怎么保证这个计算资源的弹性包可用。或者说怎么去自己去管理消息队列的弹性，其实这些都是问题。如果你采用serverless架构的话，对于刚才那些问题，都能很好的解决，就是我们可以看到随着serverless架构的演进，开发人员计较他的业务价值，就是说买家秀需要把这个文件处理成缩略图，打水印，视频转码，审核。其他的高可用的显示，流量防控，存储空间的扩容等我都不需要管。这样也验证了新范式里面的交付速度也是会大大提升的。当然我们就进行架构的延伸，对于这个架构的延伸，比如说消息的服务。对消息主题他可以直接同步和异步触发这个函数你可以理解成fast这种受类产品和很多其他的银产品天然进行了集成。
有一种叫pub sub模式，也就是这个服务发送一个消息就直接触发一个函数，然后把这个消息给消费执行自定义的处理。
第二种是说是拉的模式，比如我有的服务把日志写到日志服务，我需要对这个日志进行ETL处理，我们也可以这种有序拉起。还有一种thousand能力，比如说我对表格存储的变更。其实我是希望有一些订阅机制的，比如函数去做了些处理，比如说这几张简单例子，我写了个数据库，写了一个东西，我可能是需要有一些变更处理。我们可以看到天然的这个serverless产品和其他云服务的集成能力，可以让我们在写软件的时候使这种pub sub，世界流的这种模式可以简化我们的编程。因为之前的pub和sub这种中间的连接枢纽都是开发者自己去负责的，但servverless架构省略了让生产者发送事件维护连接枢纽通知用户职责。只需要关注这个消费者的逻辑就好了，这就是serverless的价值。
五、总结
第一个就是serverless期望，我们就是专注业务的，专注业务的逻辑价值也确实能帮助我们更好的专注业务逻辑。
第二使用solid架构的话，可以覆盖很多场景，这里只是介绍了下，就是说静态站点，一个动态站点就web前后端，然后微服务事件触发等几个经典场景的架构，其实它可以扩展的更多，大家可以发挥去想想，最后希望大家接下来先来想一想，想想过去做过的业务系统有哪些事情可以是完全交给别人去完成，比如说是云厂商，或者说是其他sa as服务。
而不是所有事情自己一个人去扛，首先就是刚刚就是回到那个时候的原生心智，就第一条就是我的业务是什么，就是你想一下，你让你去专注自己的一个业务，其他的，比如说安全，扩容，安全升级，补丁，这种事情是不是可以交给专业的云厂商去做。
就像这个冰川一样，就是说可能这个东西事情是很庞大的，可能对你的来说，你看到的业务价值只有这么一点点，但是可能很多事情还希望是由serverless这种产品体系架构去承担更多的责任。是让用户更快去创建更好的应用。
