活动时间：2023年3月2日 - 2023年3月31日活动对象：华为云全体云推官（点击立即成为云推官，即刻参与本活动）重要提示：1、云推官需在活动时间内通过活动报名页进行报名，方可成功参加本月活动，2、云推官成功推荐的客户，注册和购买时间需要在活动限定时间内（2023年3月2日 - 2023年3月31日）。3、本月“活动一”与“活动二”可同时参与，且可以叠加《华为云奖励推广活动规则》的基础现金奖励，本月新加入的云推官最多可获得5万元现金奖励+4000元礼品卡 + P40 Pro+手机，已经在推广的云推官最多可获得8万元现金奖励+4000元礼品卡 + P40 Pro+手机。4、本次“活动一”的“礼品卡”为京东购物卡，以“礼包”形式发放，实际到手面值≥活动描述面值，参加有惊喜！5、请务必在活动报名页填写正确的邮箱信息，以便后续正常接收“礼品卡”。6、活动发放的“礼品卡”，云推官需在接收后30天内和个人账号完成绑定，如有问题，可随时沟通。7、如有任何活动问题，您可通过华为云奖励推广官方企业微信沟通交流。活动1：开年采购季推荐客户数额外激励说明：云推官推荐成功的客户，购买的产品需要在《可参加返利产品明细表》中，且订单类型为包年包月或一次性。云推官推荐单客户的现金付费金额≥35元；礼品数量有限，需先报名参加活动，先到先得，如果对应礼品区间参与人数大于礼品数，则按“推荐金额”排序向后顺延。活动2：开年采购季消费金额额外激励说明：云推官推荐成功的客户，单客户的现金付费金额需≥35元；云推官活动期间成功推荐付费客户数需≥2；云推官推荐成功的客户，购买的产品需要在《可参加返利产品明细表》中；礼品数量有限，需先报名参加活动，先到先得，如果对应礼品区间参与人数大于礼品数，则按“推荐金额高→低”排序向后顺延。本月其他热门活动：S3/C3 系列弹性云服务器额外奖励专项活动——可得3%额外现金奖励其他奖励推广计划常见问题：如何加入推广1. 如何参与推广返利？①完成个人实名认证，在奖励推广计划活动页点击“立即加入”即可加入推广。②点击“立即推广”复制分享推广专属链接。③新用户通过推广链接注册账号建立关联关系。④关联期内新客户下单即可获得返利。2. 我是企业用户，能够加入奖励推广吗？不可以，华为云奖励推广计划只适用于个人用户加入。3. 为什么我实名认证完成后，依然无法加入？本活动仅限已实名认证的个人用户参与，渠道以及子客户、NA客户、有专属商务经理对接的客户不参与此活动；另外涉及账号违规的用户也不能参与此活动。4. 同一实名认证个人如果在华为云有多个账号，是否可以重复加入奖励推广计划？同一个实名的个人，在华为有多个账号的，只允许其名下一个账号加入奖励推广。5. 加入奖励推广计划之后，能否变更为企业认证用户或渠道用户？奖励推广计划仅限个人实名认证用户参加，一旦加入奖励推广计划后身份无法变更为渠道子、企业认证用户等身份。6.我有多个华为云账号，可以都参加奖励推广计划活动么？不可以，云推官在主体名下（身份证主体）只能有一个华为云账号加入奖励推广计划，注册的其他账号无法加入。如何建立关联1. 如何建立关联？点击“立即推广”复制分享推广专属链接，客户点击链接注册账号即建立关联关系，关联期间新客产生的有效新购订单累计消费金额返利。2. 建立了关联的客户，就一定会返利嘛？不一定。建立有效的关联是推广的前提条件，成功建立关联后，如果被风控拦截，订单无法参与返利，如果购买产品为非返利产品或金额不满足返利条件，订单关联成功也无法参与返利。3. 已注册的华为云账号是否能与云推官建立关联？目前推广产生关联仅适用于新注册用户，已经注册的用户通过推广链接直接购买产品无法建立关联，不能计算返利。4.我推广的客户登录下单了，为什么没有关联记录？只有通过云推官分享的专属推广链接新注册的账号才可与云推官建立关联关系，客户未通过分享链接注册账号或客户通过已有华为云账号登陆下单都无法与云推官建立关联。5.同一个客户不同账号我可以进行多次推荐么？不可以，如云推官的一个被推荐主体（身份证主体）有注册多个账号与云推官进行关联，则只允许一个账号关联有效，其他关联关系会失效，有效关联账号以最早注册的账号为准。返利规则1. 推广哪些产品可以获得返利？适用产品：可参与返现的产品有弹性云服务器、虚拟私有云、云硬盘、云数据库、企业主机安全、 DDoS高防、分布式缓存服务、管理检测与响应等107款产品。其他产品均不参加返利，另储值卡、资源包、按需套餐包付费订单类型也不纳入返利计算，注：云速建站产品2020年12月起不参与返利。点击查看更多返利产品2.推广订单如何计算奖励？推广产生关联的新注册用户，推广金额为活动期间的实付现金金额（续订订单不计为有效订单）。推广奖励返利=订单实际支付现金金额×返现比例3. 推广判定为有效订单的要素？①推广的必须是未注册过华为云账号新客户；②与客户创建了有效关联关系（通过推广链接注册账户）；③客户关联期内新购订单累计付费金额＞0元，且购买产品为可参与返利产品；④新客户下单后没有被判定为风控（即存在同手机号、同身份证、同邮箱、同设备注册或登录等风控信息，或用户账号判定违规如涉及黑卡黑产、违规操作、违反华为云用户协议等）；⑤推广订单未发生退订行为，退订订单不计为有效订单。4. 是不是推广的新客户下单首次预付费购买就有奖励？新购实付订单金额＞0元的客户方为有效客户，2020年12月起，每月的推广返利将会分四个月发放到您的银行卡内；；5. 其他常见的无效推广情况？⑴推广下单的产品不在返利产品范围内；查看可参与返利产品明细⑵不是新客户；⑶发生退款行为；⑷风控判定云推官与客户存在同手机号、同邮箱、同身份证、同设备注册或登录等风控信息；⑸用户账号判定违规（如涉及黑卡黑产、违规操作、违反华为云用户协议等）；⑹用户身份发生变化（如变更为渠道以及子客户,NA客户等）。6. 被推广客户下单但未支付、退款是否奖励？未支付的订单不奖励，退款订单将按照客户退款之后的订单付费金额，来计算奖励。7. 被推广客户使用代金券、优惠券、储值卡支付是否返利？仅按照实付金额返利，实付金额不含代金券、优惠券等支付部分，储值卡支付部分也不会计算返利。8. 加入奖励推广后推广自己购买产品，是否返利？此情况为风控的同人无效订单，不返利。云推官如需购买产品，可关注官网主页“最新活动”，或参与阶段性活动，享受华为云云各类优惠或回馈。9. 官网活动优惠订单，还可以返利吗？官网活动产品订单原则上可以返利，以相应活动或推广奖励计划规则说明为准。10. 推广规则是固定不变的吗？推广规则不是固定不变的，如有变更会及时在推广奖励计划官网活动规则和开发者论坛-cps奖励推广合作版块更新。返利发放问题1. 云推官获得的返利多久结算？我们一般会在次月末统计出您上个月的推广业绩。2020年12月起，推广返利分四个月发放到您已通过商业信息认证的银行卡内（返利发放比例为：20%、20% 、 20%、40%）2. 返利如何发放？返利金额会在次月底以邮件方式发送给云推官，并会尽快安排发放返利，云推官可以在官网“账号中心-我的奖励推广计划-我的返利账单”查看返利账单，并申请**，现金奖励会直接发放到云推官在华为云账号中心-商业信息认证绑定的银行卡中，请云推官务必绑定正确的银行卡信息，以确保奖励正常发放。3. 推荐客户发生退款，返利是否会被要求退还？推广客户发生退款，对应云推官相应订单的返利将可能进行冻结或扣除。如所推广客户持续退单，严重者将纳入黑名单，冻结奖励、限制推广。4. 加入奖励推广计划后，实名认证信息是否还可以在修改？实名认证信息在加入推广后无法再变更。请确认账号中心绑定实名认证信息与商业信息认证银行卡信息为同一人，以确保奖励正常发放。

快速体验恒温空调云端控制有人会吗

构建块和组件构建基块封装分布式基础结构功能。 可以通过 HTTP 或 gRPC API 访问该功能，目前版本有如下构建块。Buiding Block 是每个 Dapr Sidecar 可以扩展的概念，每个 Block 由多个 Components 组成，开发者可以自行设计、扩展 Component，然后贡献给社区。基于这样的设计，Dapr 把最核心的Component 提供了基于分布式系统的 最佳实践 (Best Practice)和 设计模式(Design Patterns)Input/Output Bindings:全部列表：Supported external bindingsPub / Sub:全部列表：Supported pub/sub brokers Middleware: Dapr 的一种特殊 Components，后面介绍。Service discovery name resolution: Dapr 的特殊 Components，后面介绍。State Stores全部列表：Supported state storesSecret Stores全部列表：Supported secret stores这些核心的设计可以通过代码仓库了解：仓库 cid:link_5 是Dapr 官方开放的Component ，开发者可以通过 PR 提交来把 扩展的Component 贡献给社区，目前已经有70 多个Components 可以使用，使用的时候要注意版本的阶段性是在Alpha / Beta / GA，一定要做好风险评估。

Dapr实际上是把分布式系统与微服务架构实践的挑战以及k8s 这三个主题的全方位的设计组合，特别是《Kubernetes设计模式》一书作者Bilgin Ibryam提出的Multi-Runtime Microservices Architecture这一概念。分布式系统 和微服务架构实践的核心问题就是要解决系统复杂性这个难题，降低复杂性的通常做法就是分而治之，Dapr的最核心的设计就是Sidecar Pattern + Building Block，如下图：Sidecar Pattern: 通过职责分离与容器的隔离特性，降低应用程式的复杂度。Building Block:  类似于乐高搭积木方法，通过Dapr 提供的核心组件(Component)，分离与抽象化系统架构。Dapr 设计上几乎和Bilgin Ibryam 提出的Multi-Runtime Microservices Architecture 不谋而合，它有几个核心的设计点：SidecarBuilding Block & ComponentService InvocationMiddlewareState基于上面的这些核心设计，Dapr 有了多运行时微服务架构 的特性，以此延伸出底下的重要功能，或者说设计模式：SecurityObservability: tracing, metrics, logs and healthPub / Sub / Batch ProcessActorsSecret ManagementConfig Management 正在开发中……SidecarSidecar是非常重要的云计算设计模式，下面这张图是 Sidecar 与Microservice 之间搭配后形成多个服务的关系图，这样的结构形成了服务网格的概念， Dapr 通过配置的方式，动态生成Sidecar ，随后伴随着App，一组Dapr Sidecar + App 的组合称为Dapr AppDapr App 在K8s 里面的形态就是 Pod = (App_Container + Sidecar_Container)同样的概念，如果Dapr App跑在k8s外面，也就是自承载模式。 在自承载模式下，微服务和 Dapr sidecar 在没有容器业务流程协调程序（如 Kubernetes）的单独本地进程中运行。每个Dapr App 都通过Sidecar 沟通，在通信之前，Dapr App 要知道的是对方在哪？所以服务发现和服务调用是Dapr App 要解决的第一个问题，知道彼此在哪了，然后就是通信模式，Dapr 支持HTTP / gRPC 两种通信模式。 Dapr App 之间的默认的通信模式使用gRPC，也就是如果使用HTTP调用Dapr API，内部服务之间的通信也会转成gRPC。gRPC 是一种新式的高性能框架，它通过 RPC (远程过程调用) 改进。 gRPC 使用 HTTP/2 作为传输协议，该协议通过 HTTP RESTFul 服务提供显著的性能增强，包括：对通过同一连接发送多个并行请求的多路复用支持 - HTTP 1.1 将处理限制为一次处理一个请求/响应消息。双向全双工通信，用于同时发送客户端请求和服务器响应。内置流式处理，支持对大型数据集进行异步流式处理的请求和响应。若要了解有关详细信息，请查看适用于 Azure 电子书的.NET Cloud-Native中的 gRPC概述。Dapr Sidecar 有了服务调用、服务发现和通信模式之后，定义出来了一个Building Block （构建块）的概念，使用声明的方式，定义多个组件Component 扩展Sidecar的能力，这些能力正是分布式系统需要面对的问题。

华为GES图引擎服务优质博文精选图数据基础知识 & GES介绍人人都在谈的图数据库到底是个啥？ 作者：你好_TT, 2021-05-08从零开始学Graph Database:什么是图 作者：弓乙, 2022-10-08画张图，就能秒级洞察千亿复杂关系 2021-01-12华为云新一代黑科技核心算法揭秘 作者：mr.FangYang, 2018-08-21云图说-解析华为云”黑科技“---图计算技术 作者：阅识风云, 2018-07-10聊聊图的相似性 作者：你好_TT, 2021-12-25图算法实践之k-hop 作者：你好_TT, 2021-05-12GES容灾介绍  2023-07-22【干货】华为云图数据库GES技术演进 作者：Chenyi， 2023-08-23华为云GES：十年磨一剑，打造业界一流的云原生分布式图数据库 2023-08-24GES使用指引 &图进阶学习华为云图引擎服务 GES 实战——创图 作者：你好_TT, 2021-08-22调用 GES 服务业务面 API 相关参数的获取 作者：你好_TT, 2021-08-23图数据库对 NULL 属性值支持情况 作者：你好_TT, 2021-06-18Gremlin语言学习系列链接汇总 作者：你好_TT, 2021-02-05如何使用GES进行社交关系考据？---GES查询能力介绍 作者：弓乙, 2021-10-19聊聊图上超级快的多跳过滤查询 作者：弓乙, 2023-4-12使用GES4Jupyter连接GES并进行图探索 作者：蜉蝣与海, 2022-06-25使用参数化查询提高Cypher查询的性能 作者：蜉蝣与海, 2022-04-10记一次图引擎GES cypher慢查询的分析与优化作者：蜉蝣与海, 2022-05-08GES对图细粒度权限控制的支持 作者：你好_TT, 2021-12-29使用Cypher子查询进行图探索 作者：蜉蝣与海, 2023-05-10华为云图引擎服务GES属性管理进阶 2024-01-15GES场景化应用全链路数据血缘在满帮的实践 作者：你好_TT, 2021-12-09GES与Flink的对接 作者：你好_TT, 2021-12-29要想推荐系统做的好，图技术少不了 作者：你好_TT, 2021-12-27图计算助力智慧金融 作者：你好_TT, 2020-04-18扒一扒GES如何赋能互联网电商风控 作者：Dr Thunder, 2021-04-23使用GES处理金融风控场景示例一 作者：图森破, 2020-05-19基于人货场的电商知识图谱的构建 作者：某某人, 2020-07-04采用GES构建锅炉仿真系统的关系图谱 作者：犀牛, 2020-06-28基于GES图数据库的网络架构模型构建 作者：左手看星星, 2020-07-29华为云ModelArts与图引擎联手打造，图深度学习强势落地！ 作者：我们都是云专家, 2019-08-08基于GES图数据库的大规模数据追溯服务优化 2021-03-03618 技术特辑（一）不知不觉超预算3倍，你为何买买买停不下来？ 作者：技术火炬手, 2021-06-11云图说-复杂网络的破解之道，图引擎带你径直迈向成功作者：阅识风云, 2019-10-16云图说-互联网应用的关系分析利器——企业EI的百晓生“图引擎”作者：阅识风云, 2019-04-19爱库存X华为云：乘“云”破浪，逐梦新电商: 外部链接 云社区链接构建站点数字孪生，支撑确定性运维：华为云九洲云图CloudMap 作者：HWCloudAI 2023-03-315分钟迁移关系型数据库到图数据库 作者：RiverSide 2023-07-17HyG超大规模图计算引擎专题GES图计算引擎HyG揭秘之图切分 作者：π, 2022-06-23CSR格式如何更新？ GES图计算引擎HyG揭秘之数据更新 作者：π, 2023-06-15图神经网络 & 图深度学习专题图嵌入&知识表征の初体验 作者：图森破, 2020-05-15在OCR场景使用GCN图卷积 作者：图森破, 2020-06-11风控领域图深度学习算法思考 作者：图森破, 2020-07-14知识图谱trans系列算法介绍 作者：图森破, 2021-06-29图嵌入算法介绍 作者： 图森破, 2021-06-29图神经网络！打开企业盈利的下一个风口 作者：chenyi, 2019-12-28图卷积神经网络初探 作者：chenyi, 2019-11-29图技术漫谈Neo4j闭源转商，成为强大图计算平台还需要几步？作者：chenyi, 2019-12-28Freebase Data Dump结构初探, 作者：蜉蝣与海, 2021-07-27带你认识图数据库性能和场景测试利器LDBC SNB, 作者： 闹闹与球球, 2022-06-24从图引擎平台技术，看华为云EI的决心和野心作者：chenyi, 2018-01-29使用Jupyter可视化图查询语言Cypher语法树 作者：蜉蝣与海, 2022-08-22Euler浅析 作者：弓乙, 2019-01-23从两个开源图数据库PR看查询执行时的编码设计问题 作者：蜉蝣与海, 2022-05-03Notebook案例精选图数据库实践-新冠患者轨迹追溯电商风控案例教育知识图谱利用图数据库研究COVID-19论文数据集基于图引擎的医药查询系统Koolab新冠患者轨迹追溯端边云Serverless大数据湖解决方案附录：GES首页：cid:link_21GES最新动态：cid:link_17AI训练营图数据库系列 作者：Ray博士第一讲第二讲第三讲开发者中心-图引擎服务GES开发指南：cid:link_0GES帮助文档：cid:link_9GES算法API参数参考：cid:link_11

Serverless、微服务二者架构的联系和区别微服务架构微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有Spring cloud、Dubbo等。其架构图如下所示：易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。单个微服务启动较快：单个微服务代码量较少， 所以启动会比较快。局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战。运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。Serverless架构2014年11月14日，亚马逊AWS发布了Lambda。当时Lambda被描述为：一种计算服务，根据时间运行用户的代码，无需关心底层的计算资源。从某种意义上来说，Lambda姗姗来迟，它像云计算的PaaS理念：客户只管业务，无需担心存储和计算资源。2014年10月22日，谷歌收购了实时后端数据库创业公司Firebase。Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作，只需编写HTML＋CSS＋JavaScrip前端代码，不需要服务器端代码（如需整合，也极其简单）。相对于上两者，Facebook 在2014年二月收购的 Parse，则侧重于提供一个通用的后台服务。这些服务被称为Serverless或no sever。想到PaaS（平台即服务）了是吗？很像，用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA（服务等级协议），按照调用次数进行计费，有效的节省应用成本。ServerLess的架构如上图所示。其优点如下所示：低运营成本：在业务突发性极高的场景下，系统为了应对业务高峰，必须构建能够应对峰值需求的系统，这个系统在大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。在微服务架构中，服务需要一直运行，实际上在高负载情况下每个服务都不止一个实例，这样才能完成高可用性；在Serverless架构下，服务将根据用户的调用次数进行计费，按照云计算pay-as-you-go原则，如果没有东西运行，你就不必付款，节省了使用成本。同时，用户能够通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩容方式有效的应对业务峰值，在业务波谷期将资源分享给其他用户，有效的节约了成本。简化设备运维：在原有的IT体系中，开发团队即需要维护应用程序，同时还要维护硬件基础设施；Serverless架构中，开发人员面对的将是第三方开发或自定义的API 和URL，底层硬件对于开发人员透明化了，技术团队无需再关注运维工作，能够更加专注于应用系统开发。提升可维护性：Serverless架构中，应用程序将调用多种第三方功能服务，组成最终的应用逻辑。目前，例如登陆鉴权服务，云数据库服务等第三方服务在安全性、可用性、性能方面都进行了大量优化，开发团队直接集成第三方的服务，能够有效的降低开发成本，同时使得应用的运维过程变得更加清晰，有效的提升了应用的可维护性。更快的开发速度：这一点在现在互联网创业公司得到很好的体现，创业公司往往开始由于人员和资金等问题，不可能每个产品线都同时进行，这时候就可以考虑第三方的Baas平台，比如使用微信的用户认证、阿里云提供的RDS，第三方支付及地理位置等等，能够很快进行产品开发的速度，把工作重点放在业务实现上，把产品更快的推向市场。

Serverless、事件和触发器Serverless 系统本质上就是事件驱动的系统，采用了事件驱动的架构。这种架构改变了 Serverless 系统的开发和管理方式。微服务架构的主要目标是提供高度响应的 API，这也是服务间主要的交互机制。Serverless 架构的主要目标是对发生的事件做出响应，API 是生成事件的唯一机制。在 AWS 生态系统（最为成熟的 Serverless 生态系统）中，API 并不是主要的接口，事件变得更为重要。这也就是为什么会有将近 50 个事件来触发一个 Lambda 函数。如果可以不通过 API 网关来触发 Lambda 函数，就会更快、更高效，特别是在从其他 AWS 接口触发事件的时候。其中最重要的是函数的单向性。大多数微服务采用的是请求 / 响应式的架构，这也是大多数 Web 应用程序的运行模式。Serverless 应用程序里的函数通常是单向的，并使用队列充当回路断路器，所以请求 / 响应式的架构就变得不那么常见了。数据层的管理方式也不太一样。最好是可以使用多个函数，而不是使用一个带有切换开关的代理函数。相比微服务架构，多函数还有另外一个好处。例如，如果一个函数出错，因为它是无状态的（或至少应该是），所以只会影响该函数本身，不会影响到应用程序的其余部分。如果只是简单地从微服务转向 Serverless 架构，虽然确实会给你带来一些好处，但也会错失很大一部分 Serverless 应用程序的真正价值。从很多方面来看，微服务与 Serverless 应用程序是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。从微服务到 Serverless那么，从微服务到 Serverless 需要经过怎样的路径？微服务已经相当普及了，那么是否存在一条简单的路径，可以直接从一方过渡到另一方？我想，这也正是 Serverless 世界正在解决的问题。最近，Twitter 上有很多与这个话题相关的推文。这里引用其中的一条，看看社区都是怎么讨论这个话题的。现在有很多工具声称它们会让 Serverless 应用程序的构建变得更容易，但实际上最终都是要去到它们的平台上。我不认为它们会带来额外的价值或者会让人们更好地理解什么是 Serverless 架构。我们非常清楚地意识到，我们正在讨论的是 Serverless 架构的未来，但并没有说这会让从旧架构风格过渡到 Serverless 会变得更容易，或者断定 Serverless 是不是一个正确的选择（在某些情况下可能不是）。这是有原因的。人的思维是不容易改变的。构建一个 Lambda 函数很容易，但构建一个真正的 Serverless 应用程序并不容易，它需要在思维上做出一系列改变，而这样做相对没有那么容易。

2015 年，第一个使用 AWS Lambda 和 API 网关的教程出现了，它主要关注的是如何复制微服务。但是，随着时间推移，那些大规模使用 AWS Lambda 的人越来越清晰地意识到，使用 AWS Lambda 的微服务存在严重的局限性。首先说说为什么会有微服务？微服务之所以会出现，主要是因为单体应用程序存在不足。简单地说，单体就是把所有逻辑都塞进同一个逻辑代码库的应用程序。在单服务器环境时代，多服务器价格十分昂贵。默认情况下，应用程序是按照单服务器的方式进行构建的。部署一个单体就是把应用程序的一部分或者整体部署到一台服务器上。在部署单体时，必须确保不出任何问题。通常，一个很小的改动都会导致整个应用程序和服务器宕机。在云服务出现之后，通过简单的操作就可以在几分钟而不是几天或者几周之内分配好服务器实例，这就为关注点分离提供了条件。于是，拆分单体就成了一件势在必行的事情，微服务也就孕育而生。你不再需要把所有逻辑都部署在同一个实例或服务器上，你可以把不同的部分放在不同的实例上，然后使用轻量级的通信协议（比如 HTTP API）把它们连接起来。于是，应用程序架构就从单体转向了微服务。微服务的价值在于，在做出修改时，你修改的不是整个代码库，而是其中的一个微服务，它只是整个应用程序的一部分。也就是说，改动不会造成整个应用程序宕机。但这毕竟也只是一个美好的理论，一个比单体更好的理论，在现实中，它并不完美。服务接口（通常是 HTTP 接口）是微服务的关键所在。这本没有什么问题，但是，当存在大量的服务时，要协调好它们就成了一个大问题。向 Serverless 架构转变AWS 上的第一个 Serverless 应用就是一个微服务：一个 API 网关接口，网关背后是 Lambda 函数和路由器。每一个 API 网关都是一个服务接口，看起来似乎是合乎逻辑的。你可以构建一系列的服务，每个服务都可以独立伸缩，某种程度上说，这样做非常合理。但问题是，AWS Lambda 和 FaaS 不应该被当作实例或服务器看待。因为底层使用了服务器（互联网上的很多东西都运行在服务器之上，但就是没有人指出“S3 也是有服务器的”、“BigTable 也是有服务器的”或者“Azure Active Directory 也是有服务器的”），所以我们假设你应该简单地把 FaaS 函数看成是服务，也就是有些人所谓的“minilith”。但问题是，Serverless 的关键点是事件，而这一点往往被忽略掉。

1.1.12 与传统模式架构的区别传统的架构模式是使用C/S架构的，在典型的web应用程序中，服务器接收前端的HTTP请求处理，在保存或查询数据库之前，数据可能会经过多个应用层，最终后端会返回一个响应。比如它可以是JSON形式或其他格式等。然后他会将响应返回给客户端，比如如下图所示：在传统开发模式中，开发流程：设计师设计页面 -> 服务端开发 和 前端分别开发，服务器开发完成后，-> 服务部署 ->服务部署完成后，就是前后端联调 -> 前后端联调 -> 前后端联调完成后就是测试了，-> 测试， 测试完成需要上线，因此 -> 上线，上线完成后，需要运维维护，因此 -> 运维。在传统开发模式中，开发一个应用程序，从开始到上线需要不同的角色来做不同的事情，沟通成本非常大，并且运维过程中需要考虑到 服务器的负载均衡、事务、集群、缓存、消息传递和数据冗余等等这些事情，在目前传统模式中存在如上问题。可以使用如下示意图来看下如上流程。如下图所示：在Serverless架构中，应用业务逻辑是基于FaaS架构形成多个相互独立的功能组件的。并且以API服务的形式向外提供服务，在FaaS中，后端的应用被拆分成为一个个函数，我们只需要编写完成函数后部署到serverless服务即可。后续我们也不用关心任何服务器的操作。那么整个流程就只需要我们一个前端工程师的角色来完成所有的开发工作，那么沟通成本降低了。因此我们可以使用如下示意图来表示项目流程，如下所示：前端工程师是居于serverless去写后端服务的，典型的就是居于 AWS Lambda 中编写代码，AWS中支持不同的语言。Lambda计算服务它能够以大规模并行的方式执行代码来响应事件。通过使用Lambda以及使用各种功能强大的API和Web服务，开发者可以快速的构建松耦合，可扩展性及高效的架构体系。

1.1.11 现状与局限Serverless现状与局限当前国内的很多公司也在尝试Faas或者Serverless架构，不过可以猜测出大家或多或少都心存疑虑或者有不放心之感，不敢真正的放上自己的线上服务。目前看来，虽然Serverless市面上都吹的很火，但实际落地的寥寥可数，星星点点的一些火花，还是难以形成燎原之势。Serverless这片土地十分辽阔，但是各大云厂商却都是在自己和自己过家家，至于其他人怎么玩的，就不怎么关心了。所以，目前一个很大的问题就是我们在一家函数计算平台跑了自己的服务之后，基本上就和这个平台绑定了，特别是如果你还用到Eventing，由于都是基于平台内部特定的事件触发机制，迁移成本还是比较高的。终极原因，目前还没有一个强势而大一统的框架和平台，可以让大家甘愿臣服。想当年，容器编排领域兴起，Kubernetes和Mesos大战，两边各自有人站队，云厂商也各自押宝，如今Kubernetes一统江湖，大家都默默的建立起了基于Kubernetes的容器云平台，于是围绕着Kubernetes的云原生生态蓬勃发展。由于没有统一的平台，针对Serverless目前还存在的一些局限，大家做的优化和改进也是各自为战，难以落地生根。实现：KnativeKnative是某厂商开源的Serverless架构方案，旨在提供一套简单易用的Serverless平台，把Serverless 标准化。Knative不局限于Faas，而是期望能够运行所有的无状态工作负载。像其他绝大部分的Faas或者Serverless平台一样，Knative也是基于Kubernetes，不过，Knative还基于Istio或者Gloo网关等实现流量的分发和管理。还在不久之前，Knative分为三个组件：BuildServingEventingBuild负责将代码转换成我们需要的容器镜像，Serving则是提供Serverless的运行方式，Eventing则致力于提供标准化的事件触发机制。不过，现在Build模块已经被弃用，被由Build的设计思路而发起的Tekton项目替换（参考：《Kubernetes原生CI/CD工具：Tekton探秘与上手实践》）。当然你也可以使用其他合适的CI/CD工具替代。Serving模块主要做的工作本质上就两个：流量入口的自动创建和管理以基于istio为例，Knative自动创建istio的ingressgateway，服务的service等，将流量导入新部署的服务，而不需要手动的创建各种service，ingress暴露服务和流量入口。同时，将不同版本对应不同的deployment，可以方便的实现蓝绿、灰度等发布部署方式。如下图所示：冷启动和自动扩缩容Knative有自身基于流量请求算法的metric自动扩缩容（KPA）的方式，也支持Kubernetes原生的HPA实现自动扩缩容。同时，在服务缩容为0之后，Serving会将服务流量路由到冷启动的组件，缓存请求，然后扩容服务，再将流量导入启动后的服务副本。Knative Eventing则联合 CNCF Serverless WG制定一套事件格式规范并推广：Knative Eventing与CNCF Serverless WG制定的事件格式规范只需要各个云厂商都按照这个规范，我们的Serverless服务就可以进行跨平台的事件触发，也不会被特定的云厂商绑定。

1.1.10 服务特性除了服务的粒度不一样之外，无状态工作负载和Faas一般都具有以下Serverless的特性：1-step deploy既然是Serverless，开发者真正关心和面对的是代码层面，所以不管是函数还是一个代码工程，一键构建和部署是我们的终极期望。Kubernetes生态下有各种CI/CD解决方案，但是缺乏更加一键式的工具可以帮我们将代码（函数）迅速转变成部署的服务。所以，一个足够好用的本地client工具、一个完善而高效的CI/CD平台很重要。对于Faas，可以让用户便捷的将函数部署到Serverless平台，对于无状态负载，则可以根据用户需求暴露一些构建的自定义配置和流程。Automatically在Kubernetes上一般服务实际的运行都或多或少的需要我们创建很多的Kubernetes资源，例如service、ingress等，而Serverless会做更多的自动化操作，以便更方便的提供服务。例如，Serverless平台会自动提供流量入口和路由，部署完成后可以迅速对外提供服务，同时提供类似蓝绿发布、灰度等流量管理等功能。Auto-scale毫无疑问，Kubernetes也有HPA可以提供自动扩缩容。不过，HPA敢让服务副本数缩为0吗？当然不敢，试想一下，如果服务的副本数为0，相当于不再运行了，用户的流量如何导入呢，用户连服务的接口都调不通了，HPA更没有metric数据来感知去扩容服务了。HPA无法缩容为0，对于某些短运行的计算类服务来说，是无法接受的，因为这样就不能真正的做到无服务，不实际运行时不占资源不计费。当然Serverless可以做到，让服务在没有请求时自动缩为0，在有流量的时候从0启动，或者流量增大时快速的扩容，迅速应对流量的变化。不过，还有一个Serverless业界都很关注的点，就是服务从0扩容为多副本时启动的延时时间，一般称为冷启动的问题。如果冷启动时间太长，对于用户的第一次请求肯定有很大影响，业内也有很多大厂在做一些优化。但是如果不是直接面向用户流量的服务，例如我只想跑个数据处理算法，其实也不在乎这几百毫秒的启动延迟，如果是类似前端的web服务，恐怕大部分人还是宁愿空跑一个单副本的服务，也不愿意冒这个风险吧。EventingServerless的另外一个特征是基于eventing事件进行触发，事件实际上是一个比较抽象的说法，很多东西都可以理解为事件。例如，用户的请求可以认为是一个事件，git的webhook可以认为是事件，kafka上有了消息可以理解为一个事件，包括Kubernetes的各种资源操作等等都是。所以，其实事件触发我们并不陌生，我们的平时开发和设计架构里经常都会有意无意的使用到事件触发的机制，只是太过平常，反而没有人去注意和抽象出这么一个理念。现在大家都在倡导云原生，很多服务都是往云上迁移和部署，事件触发机制在云上可以有更多的扩展性和想象力。例如，我们的Serverless应用可以监听云上的中间件或者基础组件的事件，通过这些事件，触发特定的Serverless应用，从而打通云上的Paas服务，实现云上服务的一体化。总结下来，虽然目前Serverless很火但我们更应该静下心来思考，为什么会有Serverless的诞生，Serverless最原始的需求和驱动力在哪？是Kubernetes不够好用还是Servicemesh不够友好？Kubernetes被认为是下一代的分布式操作系统，操作系统上必然会运行各种各样千奇百怪的程序，有的需要直面系统内核，有的只是提供用户更好的UI，不过，有一类程序可以以更便捷的方式去编译、运行，而提供这一切的工具与平台就是Serverless。所以，Serverless其实只是一种云原生应用更为特殊的实现和表现方式，也有很多的应用并不适合以Serverless的方式去运行。无服务器固然是愿景，大量的封装和抽象让开发者无需感知很多东西，但这个宇宙运行的规律可能并非直白的线性系统，混沌和复杂性才是常态。如果有人告诉你，Serverless是所有应用的终极目标。

1.1.9 核心诉求为什么需要Serverless前端为什么想要上Serverless，其实也很好理解，随着node.js的普及、前端工程化以及BFF的兴起，越来越多的前端需要关心服务的构建、部署、运维，服务的日志、监控报警等等，严重拖累了前端的开发效率，让前端花很多时间在服务器上排查问题，无疑是痛苦而低效的。对于前端来说，最原始的诉求是，我不愿意管服务器等底层资源，哪台节点宕机了，麻烦不用通知我；流量太大了，服务需要扩容了，我也不想关心；我只需要写好代码，就可以自动部署到服务器上，代码有bug，能让我看日志和监控排查问题就行。其实这也不单单是前端的梦想，很多后端或者数据类的研发，也有同样的需求。不过咋看很美好，但是仔细想想，有一些后端的业务很复杂，服务间调用关系以及各种特异化需求其实很难适用于Serverless，想完全不关心底层的服务器，有点困难。所以，Serverless并非银弹，关键是看业务场景和需求，就算只有50%的业务适合，能解决这50%业务的问题，那也是了不起的成就。Faas和Baas又是什么？了解Serverless的同学，或多或少都听过Faas，Faas即Function as a service，一般称作函数即服务。作为开发人员，只需要写一个函数，就可以在例如AWS Lambda等各种函数计算平台上运行起来，真正实现了对服务器的无感知，同时可以对外快速暴露API接口，可以基于函数级别的自动扩缩容，可以监听各种事件进行触发。而且Faas结合云平台的webIDE，如果webIDE设计的足够好，可以给我们带来云平台上更方便的开发体验，结合云上的各种工具和生态，未来会有更大的想象空间。不过，显而易见，以函数为最小粒度，有一些局限性。微服务是以功能职责为划分，拆分成一个一个专注于特定功能和需求的服务，为了解决微服务之间的网络调用和流量管理，引入了很多服务治理等相关的功能和组件，可以想象一下，如果把服务模块再拆分为函数的粒度，函数之间的调用关系无疑会爆炸，再思考一下，如何把老的服务改造成Faas形态，如何复用函数之间的逻辑，如何管理大量函数代码，这无疑对开发者带来了很多困扰。所以，Faas不太适合一般后台长期运行的web服务型应用，真正适合的是那些数据计算、批处理等业务，这些业务逻辑比较单一，运行完可以停止，而且更适合Serverless中基于事件触发的特性，冷启动的延时也无所谓。Faas的一个基本特征是无状态，那实际上的数据或者状态该如何存储呢，所以说到Faas一般都会提及Baas，即Backend as a service，不过类似的Xaas的名词太多了，Baas这个名词看着就像是有人为了强行补充Faas没有干的活儿而起的。因此有些人粗暴的总结Serverless = Faas + Baas，当然如果你要强行认为Serverless就是函数计算，那这个也没有问题。不过，我们的观点是：Faas只是Serverless的一种特例。在这个世界上，除了Faas，还有更多的无状态工作负载适合以Serverless的形态去运行。

1.1.8 业务场景常见的业务处理场景「Web 应用/移动应用后端」Serverless 架构和云厂商所提供的其他云产品进行结合，开发者能够构建可弹性扩展的移动或 Web 应用程序 – 轻松创建丰富的无服务器后端，而且这些程序可在多个数据中心高可用运行，无须在可扩展性、备份冗余方面执行任何管理工作。例如 Web 应用处理示例：「实时文件/数据处理」视频应用、社交应用等场景下，用户上传的图片、音视频往往总量大、频率高，对处理系统的实时性和并发能力都有较高的要求。例如：对于用户上传的图片，可以使用多个函数对其分别处理，包括图片的压缩、格式转换、鉴黄鉴恐等，以满足不同场景下的需求。例如：通过 Serverless 架构所支持的丰富的事件源，通过事件触发机制，可以通过几行代码和简单的配置对数据进行实时处理，例如：对对象存储压缩包进行解压、对日志或数据库中的数据进行清洗、对 MNS 消息进行自定义消费等：「离线数据处理」通常要对大数据进行处理，需要搭建 Hadoop 或者 Spark 等相关大数据的框架，同时要有一个处理数据的集群。通过 Serverless 技术，只需要将获得到的数据不断的存储到对象存储，并且通过对象存储相关触发器触发数据拆分函数进行相关数据或者任务的拆分，然后再调用相关处理函数，处理完成之后，存储到云数据库中。例如：某证券公司每 12 小时统计一次该时段的交易情况并整理出该时段交易量 Top 5；每天处理一遍秒杀网站的交易流日志获取因售罄而导致的错误从而分析商品热度和趋势等。函数计算近乎无限扩容的能力可以使用户轻松地进行大容量数据的计算。利用 Serverless 架构可以对源数据并发执行多个 mapper 和 reducer 函数，在短时间内完成工作；相比传统的工作方式，使用 Serverless 架构更能避免资源的闲置浪费从而节省成本，整个流程可以简化为：「人工智能领域」在 AI 模型完成训练后，对外提供推理服务时，可以使用 Serverless 架构，通过将数据模型包装在调用函数中，在实际用户请求到达时再运行代码。相对于传统的推理预测，这样做的好处是无论是函数模块还是后端的 GPU 服务器，以及对接的其他相关的机器学习服务，都是可以进行按量付费以及自动伸缩，从而保证性能的同时也确保了服务的稳定：「IoT 等物联网领域」目前很多厂商都在推出自己的智能音箱产品，用户可以对智能音箱说出一句话，智能音箱可以通过互联网将这句话传递给后端服务，然后获得到反馈结果，再返回给用户。通过 Serverless 架构，可以将 API 网关、云函数以及数据库产品进行结合来替代传统的服务器或者是虚拟机等。通过这样的一个架构，一方面，可以确保资源的按量付费，只有在使用的时候，函数部分才会计费，另一方面当用户量增加之后，通过 Serverless 实现的智能音箱系统的后端，也会进行弹性伸缩，可以保证用户侧的服务稳定，当要对其中某个功能进行维护，相当于对单个函数进行维护，并不会对主流程产生额外风险。相对来说会更加安全、稳定等：「监控与自动化运维」在实际生产中，经常需要做一些监控脚本来监控网站服务或者 API 服务是否健康，包括是否可用、响应速度等。传统的方法是通过一些网站监控平台 （如阿里云监控等）来进行监控和告警服务，这些监控平台的原理是通过用户自己设置要监控的网址和预期的时间阈值，由监控平台部署在各地区的服务器定期发起请求对网站或服务的可用性进行判断。当然，这些服务很多都是大众化的，虽然说通用性很强，但是实际上并不一定适合。例如，现在需要监控某网站状态码，不同区域的延时，并且设置一个延时阈值，当网站状态异常或者延时过大时，通过邮件等进行通知告警，针对这样一个定制化需求，目前来说大部分的监控平台很难直接实现，所以定制开发一个网站状态监控工具就显得尤为重要。除此之外，在实际的生产运维中，还非常有必要对所使用的云服务进行监控和告警，例如在使用 Hadoop、Spark 的时候要对节点的健康进行监控；在使用 K8S 的时候要对 API Server、ETCD 等多维度的指标进行监控；在使用 Kafka 的时候，也要对数据积压量，以及Topic、Consumer等指标进行监控；这些服务的监控，往往不能通过简单的 URL 以及某些状态来进行判断，在传统的运维中，通常会在额外的机器上设置一个定时任务，对相关的服务进行旁路监控。Serverless 架构的一个很重要应用场景就是运维、监控与告警，通过与定时触发器进行结合使用，可以非常简单地实现某些资源健康状态监控与感知，并进行一些告警功能建设、自动化运维能力建设：总结从虚拟空间到云主机，从自建数据库等业务，到云数据库等服务，云计算的发展是迅速地，未来的方向和形态却是模糊的，没人知道云计算的终态是什么。诚然，现在有人说 Serverless 实现了当初了云计算目标，Serverless才是真正的云计算，但是没人可以肯定地说，Serverless 就是云计算的终态表现，客观地说，或许，Serverless 也仅仅是一个过渡的产物，但是这就要交给时间去验证了。

1.1.7 应用场景Serverless 架构作为云原生技术未来的演进方向，无服务器架构技术也从观望逐渐落地，据 Gartner 的过往预测数据显示：到 2020 年全球将有 20% 的企业部署无服务器架构。Serverless 将进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高应用开发效率。同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。聚焦业务核心价值随着云服务的发展，计算资源被高度抽象化，从物理机到云服务器，再到容器服务，计算资源逐渐变得更加细腻化。Serverless 架构将会成为未来云计算领域中重要的技术架构，被更多的业务所采纳，成为其技术选型，那么再进一步的深究，Serverless 在什么场景下可以有非常优秀的表现，在什么类型的场景下可能表现得并不是很理想呢？或者说，有哪些场景更适合 Serverless 架构呢？Serverless架构的应用场景，通常是由其特性决定方向，所支持的触发器决定具体场景。CNCF Serverless Whitepaper v1.0 所描述的用户场景如图上图所示，在 CNCFServerless Whitepaper v1.0 关于 Serverless 架构所适合的用户场景包括：异步的并发，组件可独立部署和扩展的场景应对突发或服务使用量不可预测的场景短暂、无状态的应用，对冷启动时间不敏感的场景需要快速开发迭代的业务，因为无需提前申请资源，因此可以加快业务上线速度CNCF 基于 Serverless 架构的特性给出了四个用户场景之外，还结合常见的触发器提供了详细的例子：响应数据库更改 （插入、更新、触发、删除） 的执行逻辑对物联网传感器输入消息 （如 MQTT 消息） 进行分析处理流处理 （分析或修改动态数据）管理单次提取、转换和存储需要在短时间内进行大量处理 （ETL）通过聊天机器人界面提供认知计算 （异步）调度短时间内执行的任务，例如 CRON 或批处理的调用机器学习和人工智能模型持续集成管道，按需为构建作业提供资源，而不是保持一个构建从主机池等待作业分派的任务以上是从理论上描述了 Serverless 架构适合的场景或业务，云厂商将会站在自身的业务角度，整体来描述 Serverless 架构的典型场景。通常情况下，对象存储为触发器在 Serverless 架构的典型应用场景包括视频处理、数据 ETL 处理等；API 网关更多会为用户赋能对外的访问链接以及相关联的功能等，当以 API 网关作为 Serverless 相关产品的触发器时，常见的应用场景就是后端服务，包括 App 的后端服务，网站的后端服务甚至是微信小程序等相关产品的后端服务，同时像一些智能音箱也会开放相关的接口，这个接口也是可以通过 API 网关出发云函数，获得相应的服务等；除了对象存储触发以及 API 网关触发，常见的触发器还有消息队列触发器，Kafka 触发器，日志触发器等。

1.1.6 架构优势在 2017 年，CNCF Serverless WG 成立了，并且开始以社区的力量推动 Serverless 快速前行，包括 CNCF Serverless Whitepaper、CloudEvents 等相关的立项研究与探索，2017 年末，eWEEK 的 ChrisJ. Preimesberger 发表文章Predictions 2018: Why ServerlessProcessing May Be Wave of the Future 来表达在 “全新的阶段下” 大家对 Serverless 的看法和期盼，在这篇文章中诸多来自知名团队以及公司的相关负责人对 Serverless 表达了自己的想法：Serverless 可能是继容器之后的未来，可以预见 Serverless 将不断扩大影响力；重塑软件的构建方式。而到了 2018 年，Serverless 的发展速度要比想象中的更加快速，国内外云厂商不断发力推出新技术，同年 CNCF 也正式发布了 Serverless 领域的白皮书：CNCF Serverless Whitepaper V1.0，阐明 Serverless 技术概况、生态系统状态，为 CNCF 的下一步动作做指导。同时 CloudEvnent 规范，进入 CNCF Sandbox。在这一年，UC Berkeley 发文 Serverless Computing: One Step Forward, Two Steps Back，表达了对 Serverless 的担忧和挑战，作者认为 Serverless 会对开源服务创新有所阻塞。其实，任何一个新的技术、概念出现都会遇到一定的挑战和担忧，就如同当年云计算出现时，也被一些人认为只是又一个商业炒作的概念，当然事实也证明，任何一个新的事物，只有在经历各种挑战和质疑之后，才能更茁壮地成长。从 2019 年开始，Serverless 进入到了一个真正意义上的生产应用，最佳实践快速发展阶段，这一年对 Serverless 而言是具有里程碑式意义的，被很多人定义为 “Serverless 正式发展的元年”。在这一年不仅有 KubeCon 在中国上海的 CloudNativeCon 中关于 Serverless 的 “海量主题演讲”，更有 UC Berkeley 最新的文章，Cloud Programming Simplified: A Berkeley View on Serverless Computing。在这篇文章中，经历了一年的发展，UC Berkeley 的学者们也从一年前的质疑，悲观转变成了自信与期待，并这篇文章中犀利断言 Serverless 将会在接下来的十年被采用并得到飞速的发展，认为 Serverless 将引领云计算的下一个十年，并且重点阐述了以下新观点：1、新的 BaaS 存储服务会被发明，以扩展在 Serverless 计算上能够运行更加适配的应用程序类型。这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久可供选择。2、比现有的 x86 微处理器更多的异构计算机。3、更加安全、易用的编程，不仅具有高级语言的抽象能力，还有很好的细粒度的隔离性。4、基于 Serverless 计算的价格将低于 Serverful 计算，至少不会高于 Serverful 计算。5、Serverless 将会接入更多的后台支撑服务，如 OLTP 数据库、消息队列服务等。6、Serverless 计算一旦取得技术上的突破，将会导致 Serverful 服务的下滑。7、Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，因此也意味着服务器 - 客户端模式的终结。可以看到，从 IaaS 到 FaaS 再到 SaaS，再到如今的 Serverless，云计算的发展在近十余年中发生了翻天覆地的变化，相信随着 5G 时代的到来，Serverless 将会在更多领域发挥至关重要的作用。