完成实操截图实践一：10分钟开发我的个人主页实践二：OBS自动化文件解压实践三：定时拨测场景学习笔记Serverless直译为中文是“无服务器”，但是实际上它仍需要服务器，只不过服务器的管理以及资源分配部分对用户不可见，为避免误导读者，译文中还是将英文保留。最开始，一台单用户的物理服务器便能满足我们的日常所需，它快速，可靠并且安全，只对管理员负责。但是在实际中配置和扩展都很麻烦。虚拟机的出现满足了灵活性和可扩展性的需求，之后云服务提供商为我们带来了基础架构即服务（IaaS），云平台自助服务也由此诞生。在这片肥沃的土壤中出现AWS（Amazon Web Services），编排，以及基础设施即代码（IaC），之后开始了集装箱化，带来了平台即服务（PaaS）的架构，一切看起来都很顺利......但程序员仍想要更多的功能，如独立于编程语言（language agnostic）的端点，服务器的水平伸缩能力，以及可以实时支付服务使用量的能力。为了满足这些需求，Serverless计算应运而生，Serverless计算也被称为功能即服务（FaaS）。运行时只会执行程序但不会存储数据。这意味着像AWS（Amazon Web Service），谷歌云以及微软Azure云这样的云服务提供商会动态的管理资源的分配和分布。Serverless是付完即走，基于实际的消费而不是基于预测的预付款进行收费的。这本是基础设施应该有的样子，在2018年终于出现在我们面前。

三个实践做下来能较全面地体验实现serverless需要的步骤。实践一：10分钟开发我的个人主页这个代码是静态页面，实现一个静态网站的访问 。部署和测试比较简单，教学文档也很清晰。实践1完成！实践二：OBS自动化文件解压这个主要 实现在一个obs桶上传压缩文件，在另一个obs桶输出解压后的文件。如果转换失败，需要看日志，确认参数有没有配置错误。实践2完成！实践三：定时拨测场景这个主要实现定时测试url等通不通，代码的第三个url是不存在的，所以会发告警到短信或者邮箱。告警间隔是自己设置的3mins实践3成功！

完成实操截图实践一：10分钟开发我的个人主页实践二: OBS自动化文件解压实践三:定时拨测场景学习笔记“Serverless 计算将会成为云时代默认的计算范式，并取代 Serverful（传统云）计算模式。”Serverless作为一种新的开发范式，软件的架构也一定随着这种新范式的出现而做出对应的变化。传统的单体是个完全封闭的架构，业务模块耦合，牵一发而动全身。微服务架构采用标准的接口来解耦各个业务模块，通过容器技术也使得开发更有效率，但是开发者仍需要关注容器的部署位置，需要Devops的紧密联动。Serverless的架构进一步让开发者回归业务本质，免去非业务相关的运维，通过函数的方式来构建应用，使得应用解耦的颗粒度更小。Serverless 带来的业务价值主要体现在三个方面：更轻量化：用户专注于业务创新和代码开发，代码运行环境由云平台提供，无需管理基础设施资源。更快弹性：根据请求的并发数量自动调度资源运行函数，毫秒级弹性伸缩，高效应对业务峰值。更低成本：根据函数调用次数、运行时长和节点转换次数计费，函数不运行时不产生费用，更加节省成本。

获奖公示恭喜以上获奖小伙伴，礼品将于5月6日前安排发放~请留意“华为云PaaS小助手”论坛私信或企业微信私信（添加小助手微信请备注“中奖华为云账号名+DevStar体验活动领奖”）活动详情DevStar是啥？是基于模板快速开发云应用的开发平台，提供丰富的应用模板和一站式创建代码仓、生成框架代码、集成中间件以及建立DevOps流水线等能力，让开发无须从零开始，效率得以大幅提高。本任务10分钟带你上手一个实践 — 如何基于DevStar模板开发serverless应用，并带你斩获“华为云高校实习生技能大比拼”活动的10积分，还有50元京东卡等你赢取活动截止时间：2022/4/24（与主线活动同步） 规则1、点击这里获取指导书2、按照指导书成功完成体验后，将部署截图（示例见置顶评论，需露出华为云账号首尾部分字符，以便辨别不同账号）和识别结果截图在本帖回复。（完成到此就斩获积分啦）3、新增额外福利：进产品体验交流群还可以参与抽50元京东卡等福利活动，具体细则群内公示，快进群吧PaaS产品体验大本营附则：论坛活动通用规则   1）请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）。2）严禁灌水，严禁带有色情、政治、宗教、推广、外链广告内容，严禁抄袭、复制他人内容，一经发现，取消中奖资格。3）请确保您邀请的用户为真实有效的用户，如发现存在恶意注册、恶意邀请等行为（“恶意”是指为获取奖励资格而异常注册账号等破坏活动公平性的行为），我们将取消相关人员获奖资格。同时，将对该账号进行禁言禁止参与社区活动3个月的处罚，行为严重的将对账号进行永久封号。4）获奖用户需在华为云进行实名认证，同一身份信息只能获奖一次。5)对于严重违反活动规则的用户，将纳入社区失信黑名单，取消获奖资格，并做封号处理。6）所有参加本活动的用户，均视为认可并同意遵守《华为云用户协议》《华为云社区运营机制》。其他未尽事宜请参考：1、华为云社区常规活动规则：https://bbs.huaweicloud.com/forum/thread-5766-1-1.html2、所有参加社区活动的开发者用户，均视为认可并同意遵守《华为云开发者用户协议》，包括以援引方式纳入《华为云开发者用户协议》的《可接受的使用政策》、《法律声明》、《隐私政策声明》、相关服务等级协议（SLA），以及华为云服务网站规定的其他协议和政策（统称为“云服务协议”）的约束。云服务协议链接的网址：http://www.huaweicloud.com/declaration/sa_cua.html如您不同意以上活动规则及相关条款，请勿参加论坛相关活动。

本文分享自华为云开发者社区《[CNCF Serverless工作流社区携手华为云FunctionGraph，开拓Serverless编排新时代](https://blog.csdn.net/devcloud/article/details/123323056?spm=1001.2014.3001.5501)》，作者： 技术交流。 企业应用从微服务架构向Serverless（无服务器）架构演进，开启了无服务器时代，面向无服务器计算领域的Workflow也应运而生。CNCF为了给业界提供一种标准方法，建立100%由社区贡献者驱动的Serverless Workflow开源社区，携手社区伙伴，以更全面的规范、更丰富的元素，赋能企业产品化，并有效解决厂商锁定等问题，推进无服务器计算领域的发展。 华为云作为CNCF Serverless Workflow社区的官方合作伙伴，联合2012实验室华为元戎团队在函数工作流优化、版本兼容等多方面提供了优质高效的改进建议。在2021年10月的KubeCon NA 2021（North America）活动中，Tihomir Surdilovic社区领导人介绍了CNCF Serverless Workflow的开源合作伙伴，华为是2021年度CNCF Serverless Workflow 社区贡献排名榜前五中唯一的国内厂商。 # 工欲善其事，必先利其器 许多Serverless应用程序是由系列函数组成，这些函数可能会根据不同的事件触发器依次执行、并行执行或在分支中执行，我们称之为函数工作流。为了使Serverless 平台正确执行 Serverless 应用程序的函数工作流，应用程序开发人员需要对系列函数进行编排，如何支持应用开发人员简单快速进行函数编排，需要定义一套完整、易用的工作流规范。 就像在微服务架构中，只需要编写Workflow定义的JSON，就可以完成对不同业务流程的调度、编排与自动化，同时国际工作流管理联盟（Workflow Management Coalition，WfMC）还对微服务的Workflow定义了一套完整的参考规范，以使不同厂商的微服务工作流产品之间可以平滑地交换工作单元。 当下，Serverless大行其道，各个大厂纷纷下场布局。Workflow作为其工具链中的一部分，每个厂商都有一套自己的服务接口，当某一厂商暂停服务或者用户想要更换厂商时，这种各自为政的模式导致用户陷入被厂商锁定、移植困难、成本高甚至需要重构系统的艰难境地。 因此，如同WfMC为微服务的Workflow定义参考规范一样，Serverless Workflow也急需一种完整的标准方法和参考规范来打破各大厂商闭门造车的局限。 # 集众人之长，成Serverless之利 为了给业界提供一种标准方法，CNCF在2020年7月成立了Serverless Workflow 社区，与社区贡献者一起共同构建、完善Serverless Workflow 规范，以促进Serverless应用程序在不同厂商平台之间的可移植性。该社区的开源项目包括：基于DSL的工作流规范、为编程语言提供SDK等，同时与CNCF其他项目也有深度的合作，比如CloudEvents, OpenAPI等。 CNCF Serverless Workflow规范针对无服务技术领域，所以关注点会在事件驱动应用、函数或微服务。CNCF Serverless Workflow规范是一种用于微服务、事件和函数编排的工作流语言规范，可以通过YAML或JSON的格式描述和定义工作流，具有以下优势： **基于通用的、声明式的思想提炼语言，更容易表达** 目前，工作流语言分为四个类型（如下图所示），CNCF Serverless Workflow 规范是一种基于通用的、声明性的思路提炼出的工作流规范，且支持通过YAML或JSON的格式描述和定义工作流，更容易表达像functions, events, retries这些无服务器技术领域的元素。  四类工作流语言 **支持强大的、业界通用的控制流逻辑** CNCF Serverless Workflow规范本身提供了非常强大的控制流逻辑，包括了大多数业界支持的核心功能，如顺序执行，以便用户可以定义流水线。在顺序执行的基础上，用户也可以定义并行的执行，如并行调用函数或微服务。另外，也支持使用不同种类的循环结构执行数据库循环调用之类的工作流。此外，重试、错误处理、工作流的手工干预，还有诸如等待和恢复之类的标准能力都被CNCF Serverless Workflow的规范所支持。 为解决实践中业务级的问题，CNCF Serverless Workflow规范增强了诸多重要功能： - 自动重试、密钥和常量； - 定义可插拔的表达语言，以便用户可以插入自己选择的表达语言； - 不同类型的超时，如全局超时或分支超时等； - 短时和长时工作流的支持； - 工作流执行期间的补偿处理，如撤销已经成功完成的工作或状态； - 休眠，如等待某种事件或状态。 此外，CNCF Serverless Workflow规范还提供了继续属性的功能，针对工作流在达到云平台运行限制后被迫停止，用户可以编排继续属性，停止当前工作流实例，启动新的工作流实例执行停止前的状态。  工作流逻辑说明图示 **提供自定义拓展能力** 除了上述核心的控制流逻辑，CNCF Serverless Workflow规范也提供了自定义扩展能力。目前社区规范提供两个拓展：关键性能指标和限流。 用户可以通过关键性能指标的扩展能力（如工作流的整体指标、事件的消费与生产指标、函数使用指标、工作流状态指标等）定义工作流，使用自定义指标衡量工作流的性能，对性能和成本进行增强。此外，用户也能够通过限流的拓展能力对调用进行速率的限制，这在无服务器领域尤为重要，比如函数调用并发的限制、调用事件数量的限制、工作流状态总数的限制、工作流执行期间转换的限制等。  拓展能力说明图示 **功能更全面，能支持更多复杂场景** CNCF Serverless Workflow Specification支持更多元素，比如：CloudEvent、OpenAPI、AsyncAPI、GraphQL、gRPC等开源事件和服务标准的集成。 - **在功能方面**，支持建模人工决策、定义超时和重试、定义并行执行逻辑和循环、做出基于数据或事件的决策、定义回调、编写强大的表达式、设置秘密和常量等。 - **在应用方面**，支持广泛的复杂场景，比如：网上车辆拍卖、网上订餐、付款处理、数据分析、错误通知、持续集成和部署等。 所以CNCF Serverless工作流规范更加全面，能支持更多复杂场景，也具备产品化更多新特性的潜力。基于CNCF Serverless Workflow 规范本身的优势，不仅能有效避免厂商锁定，也能助力企业创新。目前，已有国内外企业关注并使用此规范产品化。 # CNCF群策群力，华为云竭诚尽智 从KubeCon NA 2021大会发布的各项数据可以看出，当前社区处于初期快速的成长阶段。2021年全年，10多家不同公司参与社区贡献，社区整体取得了显著的成就，工作流规范也已更新至0.8版本。 社区在2021全年总共有500合入的PR、2K commits， CNCF Serverless Workflow Specification有超过200个新星关注的增长，去年实现了新星关注的100%增长，同时，社区的各类社交平台也受到广泛关注。在2021年KubeCon EU大会中，共计300+人参与CNCF Serverless Workflow项目的办公时间；190+人参加了2021年KubeCon NA北美大会社区项目的办公时间。 作为社区官方合作伙伴，以及CNCF Serverless Workflow的开源合作伙伴，华为云联合2012实验室华为元戎团队，提供持续的技术能力支撑，主要贡献包括： 1. Action支持重试和错误处理已合并到0.7版本； 2. 支持分支内部进行编排的想法，已被社区采纳，并规划在0.9版本中实现； 3. 发现并提出规范版本之间兼容性不足的问题，社区确认从0.8版本之后会确保向后兼容； 4. 帮助社区在0.7和0.8版本的发布做出了贡献，包括审查与规范相关的设计文档，审阅社区新提交的PR（拉取请求）和Issue. 作为 CNCF Serverless Workflow 社区官方合作伙伴，华为云与社区伙伴携手并进，共同推动无服务器计算领域的发展。 # FunctionGraph Workflow——更上一层楼 在繁荣向上的社区生态中，华为云以CNCF Serverless Workflow 规范为标准，联合2012实验室华为元戎团队共同打造了华为云FunctionGraph Workflow，为用户提供函数流管理功能，并支持可视化拖拽式的函数编排。 在使用FunctionGraph Workflow时，用户无需进行二次开发，只要通过可视化拖拽的方式，即可将多个独立的无服务器函数用顺序、分支、并行等方式轻松快速地编排一个完整的应用。  FunctionGraph Workflow 可视化编排示意图 同时，FunctionGraph Workflow提供监控和管理平台，用于诊断和调试应用，支持跟踪每次执行的状态，执行中的输入输出等，快速定位故障，用户可以轻松配置重试，处理异常分支。  FunctionGraph Workflow 监控管理平台示意图 目前，FunctionGraph Workflow 已应用于事务型业务流程编排、多媒体文件处理、数据处理流水线等场景。面向未来，华为云期望通过不断的技术突破，将华为云开源引擎打造为 CNCF Serverless Workflow 社区的默认实现，形成应用社区 Serverless Workflow规范产品化案例，并在社区内部共享。

原文链接：https://bbs.huaweicloud.com/blogs/335406NodeJS 后端开发09 多环境Profiling优雅根据不同环境自适应学委好久没有更新NodeJS专栏，还以为NodeJS冷门，没想到最近看到几个读者留言问怎么优雅的管理多环境的配置。太忙了，写篇短文简单展示一下原理。正好基于前篇 【NodeJS 后端开发 07 MySQL数据库连接池开发生产应用 】简单尝试了mysql库来连接数据库。本篇尝试一个更加优雅的方式，通过环境变量来控制程序动态加载不同的配置。这个搞Java的同学最清楚，比如我们开发springboot应用的时候会放置多个application.yml。然后部署的时候通过环境变量来选择配置。这个用NodeJS来做就更加简单了NODE_ENV=process.env.NODE_ENV console.log('NODE_ENV:', NODE_ENV)直接贴在node REPL 终端查看：process对象为Node上下文的内置对象，可以直接获取，这个对象管理了node进程相关的数据。比如 process.env就是我们获取环境变量设置的入口了（读者可以自行打印查看更多信息）。配置一个环境变量，重试代码export NODE_ENV=雷学委打开node的终端这里我们看到，设置的环境变量被进程内部读取到了。继续根据环境自适应的profiling。上面展示了设置不同变量代码中能够获取到该环境变量的值。安照这个机制，我们可以把配置文件按照下面进行命名，让程序加载不同的文件名，比如下面：[ ] config.dev.json[ ] config.testing.json[ ] config.prod.json然后只需要写一份应用代码：复制下面代码保存为app.js//雷学委Demo代码 const NODE_ENV=process.env.NODE_ENV || 'dev' console.log('NODE_ENV:', NODE_ENV) //定位当前目录下的config.<环境类型>.json const configPath = __dirname + '/config.' + NODE_ENV + '.json' console.log('configPath:', configPath) //加载并打印数据库的配置细节 const dbConfig = require(configPath) console.log('dbConfig:', dbConfig)运行代码在这：#开发环境启动应用 node app.js#测试环境启动应用 export NODE_ENV=testing && node app.js#生产环境启动应用 export NODE_ENV=prod && node app.js很轻松吧，一份代码根据不同的环境适配了。实际运行应用app.js的服务器，上面会配置环境变量NODE_ENV为对应的dev/testing/prod值。上面代码仅为原理展示。好了到这里读者应该能够懂得profling如何做了。（可以三连了）下面看看为什么。为啥搞这么多外部配置，直接写在代码里面根据主机名字加载不好么？一般企业会有大量的服务器，然后会把服务器划分为几类，比较典型的划分为：很多中大公司会有下面这样一个划分：这样能够把一个应用层层把关提拔到最上层的生产环境（production）。学委想对小白说的： 比如说一个游戏的新功能，往往会经过开发机器调试，然后大量测试，把大量的潜在的重要的bug解决了，提拔到预发布，最后到生产环境。这个过程通过一些列的自动化测试，回归测试，可以大大保证系统的质量。还有一种高端玩法就是灰度发布，加上这个制度，这就是我们常说产品平滑上线的流程了。这好像扯远了，产品发布这一套能再写亿篇！我们回到主题，通常就是只开发一份代码，发布到不同环境之后，程序动态的连接到正确的数据库，加载对应的数据，数据虽不同但是程序在任意环境的行为要绝对一致。这里配置外部化考量是：配置外部化可以减少代码跟环境的耦合而不是发布一个类型的环境，就得修改代码。特别是互联网/金融项目都会有严苛的质量把关，哪怕是修改一个标点符号，整个产品提升的过程都得从开发环境重新来过。因此，配置外部化很有必要。那么，应用能否跟外部环境毫无关联？比较有经验的朋友，可能会想匿名函数，或者亚马逊的lamda，或者serverless app（无服务器应用）如果业务没有任何环境区分，那就可以做到程序跟环境没有耦合，这就充分的说明了serverless的一个优点！（没有耦合，意味着随便拿一个云服务器部署，即可轻松实现弹性伸缩了，但这并非此文出发点，有机会再说）对了，学委还有这个可以关注长期阅读 =>雷学委趣味编程故事汇编或者=> 雷学委NodeJS系列持续学习持续开发，我是雷学委！编程很有趣，关键是把技术搞透彻讲明白。创作不易，请多多支持，点赞收藏支持学委吧！更多代码可以查看/Star： LearnNodeJS代码下载

>摘要：Serverless将是微服务的“封顶之作”，也是推动应用现代化的基石。本文分享自华为云社区《[【深入浅出，Paas之路】华为云.云享专家曹宗南： Serverless，引领云计算下一个阶段](https://bbs.huaweicloud.com/blogs/325811?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者： 我们都是云专家 。 2009 年，伯克利以其独特的视角发布了一篇文献，正式定义了云计算。自此，千行百业的 IT 基础设施开启上云之路。 2019年，伯克利在《Cloud Programming Simplified》预言： “Serverless计算将会成为云时代默认的计算范式，并取代Serverful（传统云）计算模式。” 2009-2019年，互联网技术飞速发展。在这期间，出于对计算机技术的兴趣，曹宗南大学期间选择了计算机专业，之后便开启了他的技术开发生涯。 只要对开发有所了解，都知道程序员和开源是密不可分的，曹宗南亦是如此。毕业之后的一次项目中遇到数据库开发相关的瓶颈，他在经过一番查询，发现开源项目分布式数据库中间件Mycat能够完美的解决遇到的问题。他表示，Mycat在使用的过程中，后端可以挂接N个普通的MySQL数据库，数据可以按照多种规则进行分布，对外表现的却像一个MySQL实例一样来使用，业务代码不需要做大的改动。  自此，曹宗南便对MySQL产生了极大的兴趣，逐渐的也从使用者到开源的贡献者。陆续给Mycat贡献了多数据库后端支持、动态平滑扩容、分片算法、压缩协议等多个核心特性，还参与Mycat线下技术峰会的演讲。“对Mycat源码也熟悉的像自己的掌纹一样清楚。”曹宗南说道。 # 触摸新技术时代的网红Serverless 在谈及现在的工作内容中，曹宗南提到了Serverless技术。正如开篇所提到伯克利在《Cloud Programming Simplified》中的预言，Serverless将成为云计算的下一代默认计算范式。 曹宗南解释道，Serverless架构是在微服务架构基础上的进一步延伸，按照业界通常的定义，Serverless = FaaS(Function as a Service) + BaaS(Backend as a Service)。相比微服务，FaaS将资源调度的粒度缩小到函数，针对无状态、短时处理任务，通过函数式编程方式，进一步降低了应用开发门槛，缩短了应用上线周期。 为了更好的便于理解，曹宗南从三个典型场景，解读了Serverless架构所具有的IT资源可根据需求弹性伸缩的特点。  场景一：Web类应用。典型的应用有小程序后端、Web后端、三方服务商对接、前端BFF等。这类应用使用函数编程可以极大简化开发流程，能够做到小时级交付； 场景二：IoT、媒体处理类应用，如实时的图片处理、实时的数据流处理、IoT的事件处理等。这是Serverless最典型的一类应用，特点是事件驱动+计算胶水层，计算胶水层的逻辑通过函数来实现，以事件驱动的方式执行服务，按需供给，开发者无需关注业务波峰波谷，节省闲时成本，最终降低运维的成本； 场景三：AI处理应用，如视频直播、AI推理、人脸识别、车辆识别等，这类应用的特征是基于各行各业的业务智能化，通常无法预知流量大小，需要基础设施能够做到底层资源无感，自动的快速弹缩而不影响业务层的处理。 随着在Serverless技术的研究和实践过程中发现，Serverless作为云计算下半场的计算范式，需要解决通用应用开发、原有应用系统无缝对接、支持异构硬件等问题，并且有完备的工具链、云服务，才能让更多的开发者享受Serverless带来的红利。 # 华为云FunctionGraph开启Serverless新时代 在华为全联接2021上，华为公司高级副总裁、华为云CEO、消费者云服务总裁张平安重磅发布了华为云FunctionGraph函数计算服务。 FunctionGraph是一款带编排能力的函数计算服务，提供了界面化管理、一站式的函数开发上线功能，支持6大类语言、支持10+类的函数触发器类型；拥有丰富的触发器类型，通过事件触发集成多种云服务，满足不同场景需求；根据请求的并发数量自动调度资源运行函数，实现按需极速弹性；函数运行实例出现异常，系统会启动新的实例处理后续的请求，实现秒级故障自愈。 曹宗南作为华为云FunctionGraph首席架构师，全程参与了FunctionGraph 2.0全新架构的设计和研发。针对FunctionGraph 2.0全新架构，他从5个特性做了诠释。 **• 特性1：丰富的函数开发语言及触发方式让设计更灵活**  支持Python、Java、Node.js、Go等常见的编程语言，也支持容器镜像和自定义运行时。函数调用支持同步和异步两种方式，最长支持12小时，可满足长时间任务的需求，大大突破传统Serverless的适用场景。 **• 特性2：可视化拖拽式函数流支持编排复杂业务场景**  支持通过图形化拖拽方式进行函数编排，支持并行分支、条件分支、子流程、循环、异常处理等，可以满足多函数场景下的快速编排需求。 **• 特性3：统一插件支持云上和云下的开发与调试**  如何对函数进行调试作为Serverless场景的一个难点，华为云针对云上和云下两个场景都提供了解决方案，而且作为业界首家支持多函数调试能力。 **• 特性4：Http函数让WEB服务近乎0成本改造，享受Serverless优势能力**  微服务和函数在未来几年会是一个共存的形态，当前存在着大量微服务应用，如何高效的支撑其Serverless化，让现有微服务快速享用到Serverless的优势能力，是一个待解决的问题。 针对Web服务，华为云推出API网关加FunctionGraph的Http函数方案，用户只需把原有的Web Server代码打包为一个Http 函数，即可完成Serverless化改造。该方案价值体现在多语言WEB框架支持方面，例如：Java - Spring Boot，Nodejs - Express等框架，这样对于开发的应用通过极小修改就是能完成Serverless 函数化改造。开发人员可以继续使用熟悉的开发框架和测试工具，降低开发人员学习负担。而且，改造后也无需额外的运维，简单配置即可实现100ms级自动弹性和灰度升级。 **• 特性5：函数支持在运行时动态指定资源，灵活调度节省成本**  图片压缩、水印处理、文档转换、视频转码是典型的事件触发，波峰波谷明显的场景，越来越多地使用Serverless 函数来开发业务。以视频转码为例，典型的处理流程如下：  视频文件的大小从MB到GB，不同编码格式和分辨率对转码需要的计算资源要求差别很大，为保证转码函数的性能，通常配置一个很大的资源规格，但是在低分辨率的（例如短视频）场景下，会造成资源浪费。Functiongraph提供了一种方案支持函数执行时可根据业务需要动态指定资源规格，最小化资源占用，可以给用户带来更精细的资源控制，更低的成本开销。 目前，在华为云Serverless场景落地方面，已全面实现了在移动端的应用实践。曹宗南举例道，2020年新型肺炎疫情牵动着全球人民的心，基于Serverless服务，华为负一屏快速上线“新型肺炎疫情实时播报”，实现了一天上线，资源利用率提升50%。 在视频处理应用场景中，华为视频前端基于函数开发，实现前端开发和后端开发解耦，前端界面逻辑变化不需要后端参与，开发上线效率提升100%以上，大幅减少前后端团队沟通协同，效率提升50%以上。 在海外的合作伙伴应用中，阿联酋海关基于Functiongraph的弹性收缩轻松应对业务波峰波谷，TCO成本较传统方案降低30%以上，较传统开发模式上线周期减少50%（6个月->3个月） # 最后 事实上，目前的Serverless发展已经远远超出了预期。对于云计算应用架构来说，“无服务器”时代的Serverless技术必将引领云计算下一个阶段。正如华为2012实验室分布式与并行软件Lab主任谭焜博士所说，Serverless将是微服务的“封顶之作”，也是推动应用现代化的基石。

2009 年，伯克利以其独特的视角发布了一篇文献，正式定义了云计算。自此，千行百业的 IT 基础设施开启上云之路。2019年，伯克利在《Cloud Programming Simplified》预言：“Serverless计算将会成为云时代默认的计算范式，并取代Serverful（传统云）计算模式。”2009-2019年，互联网技术飞速发展。在这期间，出于对计算机技术的兴趣，曹宗南大学期间选择了计算机专业，之后便开启了他的技术开发生涯。只要对开发有所了解，都知道程序员和开源是密不可分的，曹宗南亦是如此。毕业之后的一次项目中遇到数据库开发相关的瓶颈，他在经过一番查询，发现开源项目分布式数据库中间件Mycat能够完美的解决遇到的问题。他表示，Mycat在使用的过程中，后端可以挂接N个普通的MySQL数据库，数据可以按照多种规则进行分布，对外表现的却像一个MySQL实例一样来使用，业务代码不需要做大的改动。自此，曹宗南便对MySQL产生了极大的兴趣，逐渐的也从使用者到开源的贡献者。陆续给Mycat贡献了多数据库后端支持、动态平滑扩容、分片算法、压缩协议等多个核心特性，还参与Mycat线下技术峰会的演讲。“对Mycat源码也熟悉的像自己的掌纹一样清楚。”曹宗南说道。触摸新技术时代的网红Serverless在谈及现在的工作内容中，曹宗南提到了Serverless技术。正如开篇所提到伯克利在《Cloud Programming Simplified》中的预言，Serverless将成为云计算的下一代默认计算范式。曹宗南解释道，Serverless架构是在微服务架构基础上的进一步延伸，按照业界通常的定义，Serverless = FaaS(Function as a Service) + BaaS(Backend as a Service)。相比微服务，FaaS将资源调度的粒度缩小到函数，针对无状态、短时处理任务，通过函数式编程方式，进一步降低了应用开发门槛，缩短了应用上线周期。为了更好的便于理解，曹宗南从三个典型场景，解读了Serverless架构所具有的IT资源可根据需求弹性伸缩的特点。场景一：Web类应用。典型的应用有小程序后端、Web后端、三方服务商对接、前端BFF等。这类应用使用函数编程可以极大简化开发流程，能够做到小时级交付； 场景二：IoT、媒体处理类应用，如实时的图片处理、实时的数据流处理、IoT的事件处理等。这是Serverless最典型的一类应用，特点是事件驱动+计算胶水层，计算胶水层的逻辑通过函数来实现，以事件驱动的方式执行服务，按需供给，开发者无需关注业务波峰波谷，节省闲时成本，最终降低运维的成本； 场景三：AI处理应用，如视频直播、AI推理、人脸识别、车辆识别等，这类应用的特征是基于各行各业的业务智能化，通常无法预知流量大小，需要基础设施能够做到底层资源无感，自动的快速弹缩而不影响业务层的处理。随着在Serverless技术的研究和实践过程中发现，Serverless作为云计算下半场的计算范式，需要解决通用应用开发、原有应用系统无缝对接、支持异构硬件等问题，并且有完备的工具链、云服务，才能让更多的开发者享受Serverless带来的红利。华为云FunctionGraph开启Serverless新时代在华为全联接2021上，华为公司高级副总裁、华为云CEO、消费者云服务总裁张平安重磅发布了华为云FunctionGraph函数计算服务。FunctionGraph是一款带编排能力的函数计算服务，提供了界面化管理、一站式的函数开发上线功能，支持6大类语言、支持10+类的函数触发器类型；拥有丰富的触发器类型，通过事件触发集成多种云服务，满足不同场景需求；根据请求的并发数量自动调度资源运行函数，实现按需极速弹性；函数运行实例出现异常，系统会启动新的实例处理后续的请求，实现秒级故障自愈。曹宗南作为华为云FunctionGraph首席架构师，全程参与了FunctionGraph 2.0全新架构的设计和研发。针对FunctionGraph 2.0全新架构，他从5个特性做了诠释。• 特性1：丰富的函数开发语言及触发方式让设计更灵活支持Python、Java、Node.js、Go等常见的编程语言，也支持容器镜像和自定义运行时。函数调用支持同步和异步两种方式，最长支持12小时，可满足长时间任务的需求，大大突破传统Serverless的适用场景。• 特性2：可视化拖拽式函数流支持编排复杂业务场景支持通过图形化拖拽方式进行函数编排，支持并行分支、条件分支、子流程、循环、异常处理等，可以满足多函数场景下的快速编排需求。• 特性3：统一插件支持云上和云下的开发与调试如何对函数进行调试作为Serverless场景的一个难点，华为云针对云上和云下两个场景都提供了解决方案，而且作为业界首家支持多函数调试能力。• 特性4：Http函数让WEB服务近乎0成本改造，享受Serverless优势能力微服务和函数在未来几年会是一个共存的形态，当前存在着大量微服务应用，如何高效的支撑其Serverless化，让现有微服务快速享用到Serverless的优势能力，是一个待解决的问题。针对Web服务，华为云推出API网关加FunctionGraph的Http函数方案，用户只需把原有的Web Server代码打包为一个Http 函数，即可完成Serverless化改造。该方案价值体现在多语言WEB框架支持方面，例如：Java - Spring Boot，Nodejs - Express等框架，这样对于开发的应用通过极小修改就是能完成Serverless 函数化改造。开发人员可以继续使用熟悉的开发框架和测试工具，降低开发人员学习负担。而且，改造后也无需额外的运维，简单配置即可实现100ms级自动弹性和灰度升级。• 特性5：函数支持在运行时动态指定资源，灵活调度节省成本图片压缩、水印处理、文档转换、视频转码是典型的事件触发，波峰波谷明显的场景，越来越多地使用Serverless 函数来开发业务。以视频转码为例，典型的处理流程如下：视频文件的大小从MB到GB，不同编码格式和分辨率对转码需要的计算资源要求差别很大，为保证转码函数的性能，通常配置一个很大的资源规格，但是在低分辨率的（例如短视频）场景下，会造成资源浪费。Functiongraph提供了一种方案支持函数执行时可根据业务需要动态指定资源规格，最小化资源占用，可以给用户带来更精细的资源控制，更低的成本开销。目前，在华为云Serverless场景落地方面，已全面实现了在移动端的应用实践。曹宗南举例道，2020年新型肺炎疫情牵动着全球人民的心，基于Serverless服务，华为负一屏快速上线“新型肺炎疫情实时播报”，实现了一天上线，资源利用率提升50%。在视频处理应用场景中，华为视频前端基于函数开发，实现前端开发和后端开发解耦，前端界面逻辑变化不需要后端参与，开发上线效率提升100%以上，大幅减少前后端团队沟通协同，效率提升50%以上。在海外的合作伙伴应用中，阿联酋海关基于Functiongraph的弹性收缩轻松应对业务波峰波谷，TCO成本较传统方案降低30%以上，较传统开发模式上线周期减少50%（6个月->3个月）最后事实上，目前的Serverless发展已经远远超出了预期。对于云计算应用架构来说，“无服务器”时代的Serverless技术必将引领云计算下一个阶段。正如华为2012实验室分布式与并行软件Lab主任谭焜博士所说，Serverless将是微服务的“封顶之作”，也是推动应用现代化的基石。

感谢各位小伙伴对本次活动的大力支持，根据大家提交的课后习题和实践任务截图，在符合获奖条件的用户中，已根据活动规则抽出各奖项的获奖者，截图如下请各位获奖开发者在12月31日前完成领奖信息反馈，逾期未反馈领奖信息，将视为自动放弃领奖！反馈链接： https://devcloud.huaweicloud.com/expertmobile/qtn?id=dbc9fccc5bf44605b80955f78654ec9f 我们将在所有获奖者完整填写领奖信息后14个工作日内，统一发出奖品，敬请期待哦！为保护大家账号隐私，已对账号进行模糊处理，请大家仔细核对哦1. 通关王者奖2. 高阶大师奖3. 进阶达人奖4. 入门新生奖5. 探知小白奖说明：按要求完成该奖项所对应的预习期实践任务的开发者为93人，根据活动规则，抽取10位开发者获奖。6. 学习达人奖说明：该奖项奖品设置数量为50，按要求将预习期、入门期、进阶期、高阶期课后习题全部回答正确用户23人，小于50人，故23人全部获奖，恭喜大家！7. 邀请有礼奖说明：该奖项奖品设置数量为30，按要求邀请3位以上好友报名活动的用户为13人，小于30人，故13人全部获奖，恭喜大家！为保证活动公平公正，已对抽奖过程进行录屏，抽奖过程请参见如下链接，抽奖入围名单请见附件。https://res-static.hc-cdn.cn/cloudbu-site/china/zh-cn/Serverless/1640334810314091271.rar你是否有过如下困扰：资源利用率如何提升？业务暴增时如何扩容？如何解决运维中的难题？何时才能只聚焦应用创新，不用关心如何管理服务器？别急，无服务器时代已来，Serverless助你摆脱底层资源的管理困扰，专注应用创新，促进快速迭代~图灵奖获得者David A. Patterson和Spark共同创始人Ion Stoica，在19年伯克利的会议上发布Serverless将是下一代默认的计算范式。 那么究竟什么是Serverless？什么是FaaS和BaaS？不购买服务器如何构建应用呢？华为云一线大咖带你从0到1入门Serverless，体系化课程搭配场景化实践操作，更有无线耳机、华为音箱、京东卡等好礼等你拿哦~1. 活动时间：2021.11.16-2021.12.20；招募期&预习期：2021.11.16-2021.11.29；入门期：2021.11.30-2021.12.6；进阶期：2021.12.7-2021.12.13；高阶期：2021.12.14-2021.12.20；2. 适合人群：对Serverless感兴趣，饱受底层资源管理困扰，有志在无服务器时代弯道超车的开发者们3. 参与流程：(1) 活动报名 点此报名活动      邀请3位以上好友报名活动，即可获得抽奖资格，奖品为案例学院会员卡一张哦！奖品数量上限为30个，中奖概率（≤100%）为30/完成任务人数。(2) 添加小助手微信，回复“Serverless”加入学习群(3) 加入Classroom课堂，获取学习材料及实操任务指导文档，完成实践任务，按要求提交任务完成截图至Classroom课堂，获取抽奖资格；点此加入Classroom课堂(4) 审核截图，抽奖，公布获奖名单4. 任务完成截图提交规则：(1) 提交时间：2021年11月16日-2021年12月20日，由于各学员报名活动的时间不统一，完成任务的时间有早晚，为鼓励大家积极性，保证活动公平公正，所有实践任务完成截图的提交截止时间统一为2021年12月20日23:59，在此时间之前加入活动的学员均可提交任务完成截图。(2) 截图提交方式：进入Classroom课堂找到对应阶段学习课程，点击提交作业，上传截图即可；(3) 截图中需显示华为云中国站账号，社群助手将在实操指导文档中提供截图示例；(4) 活动结束后，社群助手将对所有截图内容进行审核，审核周期为3-5个工作日，未按要求上传截图的学员，将无法参与评奖；5. 奖励规则：本活动不仅可以跟随华为专家学习干货知识，更有免费奖品可以拿哦，详细获奖规则请见下图6. 活动注意事项：所有获奖用户名单将在活动结束后3个工作日内在本帖公示，请获奖用户按照反馈路径及时反馈获奖信息，活动结束且用户填写完整领奖信息后14个工作日内，将统一发出奖品，不额外收取任何费用。由于获奖用户自身原因（包括但不限于提供的联系方式有误、身份不符或者通知领奖后超过30天未领取等）造成奖品无法发送的，视为获奖用户放弃领奖；活动奖品颜色随机，且部分奖品数量有限发完即止，如对应奖品无库存会更换等价奖品；为保证活动的公平公正，华为云有权对恶意刷活动资源（“恶意”是指为获取资源而异常注册账号等破坏活动公平性的行为），利用资源从事违法违规行为的用户收回抽奖及奖励资格。本活动规则由华为云在法律规定范围内进行解释。华为云保留不时更新、修改或删除本活动规则的权利。本次活动回帖内容需满足华为云论坛发帖规范：https://bbs.huaweicloud.com/forum/thread-23077-1-1.html

获奖名单公布kswilad123445Regan Yue恭喜以上开发者，之前未填写获奖信息的开发者，请与11月5日16：00前完成获奖信息填写。为保证您顺利领取活动奖品，请您提前填写奖品收货信息，如您没有填写，视为放弃奖励。收货信息请【点击此处填写】活动奖励a. 奖励一：参与互动用户每人获得圆梦积分3分b. 奖励二：在所有参与互动用户中抽取3个幸运奖，奖品为《ModelArts人工智能应用开发指南》书籍1本。专家简介刘毅华为云PaaS服务产品架构师15年软件开发、架构设计从业经验，工作中主要从事大型企业级软件的架构与研发，在金融，医疗等领域具备多个项目的成功实践。持续跟踪 serverless, 云原生等软件开发前沿技术，为开发者提供了丰富的应用开发最佳实践。董鑫武华为云PaaS服务产品布道师23年软件开发、架构设计从业经验，先后从事电信业务支撑系统、企业级软件解决方案设计和应用开发，在智慧城市、智慧园区等领域具备多个项目的成功实践。深耕云原生、低代码等软件开发前沿技术，并应用于开发实践，为企业、高校等各类开发者提供了丰富的应用开发最佳实践。 直播简介     1.如何高效对接华为云服务，API/SDK/CLI工具和代码示例要怎么选择？ 2.数字化转型的深入，越来越多的应用将基于云开发和部署，软件需求越来越海量、零碎、善变，而专业的开发人员千金难求。如何高效地开发云原生的应用，解决传统模式开发效率低，上线慢等问题？ 3.Serverless技术和应用是业界热点，如何快速开发出Serverless应用？ 本次论坛华为云高级专家将为您详细解读 直播亮点1.了解云原生、Serverless应用开发的特点2.熟悉华为云原生、Serverless开发碰到的问题和解决方案3.熟悉云应用、Serverless开发的工具链4. 熟悉对接华为云的API/SDK/CLI、IDE插件等工具的使用5.了解华为云低代码开发平台AppCube应用场景及能力，以及AppCube给传统企业数字化转型带来的价值 直播时间9月25日  15:00活动时间9月22日—10月7日互动方式直播前您可以在本帖留下您感兴趣的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流，我们会在全部活动结束后对参与互动的用户进行抽奖。活动规则本次活动结束后，将由华为云工作人员将符合抽奖条件的用户名单导入至巨公摇号平台（https://www.jugong.wang/random-portal/）内，抽取各奖项，并截屏公示抽奖过程。如您不同意此抽奖规则，请勿参加本次活动。 Tips1、请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）。2、所有获得华为电子产品奖项的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。3、收货信息填写说明：1）为保证您顺利领取活动奖品，请您提前填写奖品收货信息，如您没有填写，视为放弃奖励。收货信息请【点击此处填写】2）填写时间截至2021年10月25日23:59。3）在HC2021开发者社区系列活动中完成一次填写即可。我们最终将会按照您填写的信息发放奖励。4、活动规则请戳https://bbs.huaweicloud.com/forum/thread-154048-1-1.html

【4月的一个周五傍晚，刚刚结束一场语音会议的明哥，拿起桌上的咖啡，一口灌了下去。同时，翻了翻摊在右手边的笔记本，思考即将抛给他的一些问题。在华为已经工作第15个年头的他，目前是华为云官网研发团队的技术负责人，看护着华为云对外的“门面”。 作为技术管理者，明哥有个小习惯，“每天给自己留一些静默时间，在这段时间内，尽量不处理邮件、工作信息，能够做一些代码开发、review、技术研究的工作。” 他还习惯把事务性的工作都安排在前半周，后半周能有相对完整的时间，和团队的架构师、设计师系统讨论比较大的技术方案。 在钻研技术这块，明哥喜欢往下走，去看它的底层运行机制，它的源码。他也是 “一万个小时定律”的拥趸者，始终坚信积累足够的时间和精力，一定能在技术上有所建树，触类旁通。 所以，他能和团队仅用半年多的时间，完成一次几乎不可能的挑战。再难，官网“门面”不能倒在华为南京研究所露天长梯的二层平台上，一直竖着一块海报板：二战中被打得像筛子一样、浑身弹孔累累的伊尔2飞机，依然坚持飞行，终于安全返回。两年前的下午，明哥双手环胸站在办公室的落地窗前，紧紧盯着这块海报，思绪却停在十分钟前接到的任务上：他的团队需要在有限的时间内，完成官网内容生产平台的全部自研重构，且达到业界领先的水平。 这是一次走出技术舒适圈的挑战，放弃他们非常熟悉的技术架构，一切从头开始，好比明明有一条高速公路通往终点，但是你不能走，你得自己新建一条。这期间，华为云官网团队既要保证日常业务的正常运转，按部就班解决各种业务需求，又要抽调出足够的人手搭建新的内容平台，时间紧、人手少、任务重。 在不断的技术研讨，重写代码，验证测试后，项目的最小可用版本完成了showcase，彼时大家都很有成就感，也觉得终于能缓一缓了。然而一个更紧急的任务再次抛向他们：为了快速催熟产品，接下来的大促期间将直接使用自研系统。此时离大促还有两个月，开发团队除了要分出一部分兵力生产页面（为了确保用户体验，页面要全新设计），还要补齐高并发、高可用、安全可信等产品化所必须的能力。通常，这样的能力一般至少需要3到6个月，才能打磨完善的差不多。 明哥和团队只有背水一战，那段时间里，任务板上写满了被拆分的工作细节，新的方案不断覆盖旧的版本，会议室里坐阵的技术专家走了一波，又新来一波……大家拒绝妥协，一门心思埋头往前冲。比如，为了保证生产出来的页面在任何情况下都不能丢，设计团队翻阅了大量资料，与安全、可用性、性能专家多次讨论和原型验证，然后选择了最‘冗余’的方案，最终成功应对多次突发情况，经受住了大促的考验。历时8个月，从项目启动到第一个基于自研的内容生产页面诞生，官网团队交出了一份漂亮的成绩单。 “挑战非常大，但我们成功了。”与此同时，他们还“顺带”开发了一个PQP页面质量平台，负责自动检查页面上线前的内容质量，包括页面的404、敏感字词、中英文单词的拼写、图标的设计元素是否符合规范等等。 从接手华为云官网开始，质量就是悬在明哥头上的达摩克利斯之剑。用他的话说，“质量这个东西，不出问题的时候大家不会觉得多重要，但凡发生问题，就会成为众矢之的，所谓善战之将无赫赫之功。” 如何保证页面质量稳定，这一点往往是不少前端技术人员忽视的。“我们找咨询公司，合作伙伴问了一圈，大家都没有这样的工具，更多的是靠流程保证，比如发现问题通知oncall，再逐层找到负责人。虽然管理手段能够运行下去，但效率太低了。” 所以，将这种“人拉肩扛”的问题处理方式，转化为工具能力，做成平台去赋能，再贯穿到整个页面的发布流程，是一件成就感与挑战并存的事情。 当前，PQP平台已在华为内部“开源”，包括华为官网在内的80多个网站都已经接入，用于看护网站的内容质量。 谈及质量，不仅是页面内容的质量，还有官网稳定性的质量。试想，12306的每一次崩溃，后面是多少用户的吐槽骂声。为了维护华为云官网的稳定性，他们也针对高可用做了多层保障，比如多副本的容灾备份，数据多活等等，在全球4个地区的6个机房都安置了华为云官网的服务器，并且采购了4家不同的CDN厂商规避可能出现的任何主客观风险。构建多个逃生通道，一键完成流量的快速切换。就像剥洋葱一样，剥开一层里面依然保证完好无缺。 “华为云官网是我们的门面，控制台、后台服务或许可以挂，但官网就像上甘岭的那面旗帜，哪怕是个光杆司令，我也不能倒，一定要竖在那里。”云原生藏在业务里门面不能倒，为了这个目标，华为云官网的架构以及生产发布流程也在不断优化完善中。 以前端框架为例，React性能强大且灵活，Angular有丰富的组件，Vue简洁易构建，选起来颇有些乱花渐欲迷人眼。 明哥也曾陷入选择何种技术框架的纠结中，团队经过一番讨论，选择了一个折中的方式——他们和web能力中心定下原则：基础能力团队维护一套主流技术框架和组件库，各业务团队有自己的选择权，可以直接使用，也可以根据需要选择其他技术栈，但核心是遵从统一的设计规范，达到即使不同技术栈生产的页面也能让用户无感知差异的效果。 正所谓好马配好鞍，让开发人员根据各自看护的业务特性找到最匹配的框架。但问题随之而来，如何将这些新、老技术栈，以及不同技术框架生产的页面放在一起呈现给用户？ 华为云引入了微前端框架，让各个小团队，不同的技术栈都能共生。 微前端的目的是低耦合，它把各模块之间的影响降到最低，各模块能按需使用不同的技术栈，从而降低技术栈切换的成本，确保产品平滑过渡，避免一刀切带来的质量风险。 同时，所有的服务都部署在容器里的，一切皆代码。诸如应用程序、中间件、底层操作系统都被打包成标准的包，不管在什么环境，什么时候部署，模块都是一样的，不会出现因为系统、中间件版本、配置不一致引发的研发环境和生产环境状态不同的情况。这也是持续交付、快速迭代的基础。从人拉肩抗的低效率开发，到如今标准的页面发布流程，华为云官网的架构也进入到一个新的阶段：后台采用微服务架构，前端采用微前端架构，页面上线遵守标准的DevOps流程，化繁为简，充分利用技术的特性，破除实际业务的瓶颈。 举个例子，以前的网站开发不管是页面功能，还是页面内容的变化，都绕不开发人员，网页上任何一个细微的变化都得去修改html代码或者C**。这种情况下，随便修改一个字，开发需求排下来，小半个月过去了。 为了让大家都能得到“解脱”，所以有了页面生产平台，可以让业务人员自助完成页面修改；有了可视化搭建，拖拽组件即可完成所见即所得的网页制作；有了系统的内容质量检测平台，能够保证页面的安全上线。通过IT化，让所有上线动作都高效可控，打通官网内容DevOps的最后一环。这也是明哥对于云原生的理解，“云原生本身并不能算一套架构，它更像是一个定义，一套方法论。 打开来看，云原生无非这几个关键元素：微服务、DevOps、持续交付、容器化。”目前，DevOps方面，华为云有一套统一的发布流水线平台，所有服务均通过这个平台发布到生产环境；持续交付方面，华为云官网有65%左右的特性是通过按特性独立发布的，每周都会有几百个特性发布到生产环境上。让**再飞一会儿康威定律里曾提到，组织的架构决定了整体的技术架构。由于华为云的前端和后端组织相对分离，双方各司其职，技术沟通中难免会产生一些小的摩擦。不过，当前端技术浪潮汹涌而来之时，它也在试图用技术去弥合人为原因造成的各种沟通问题。 以Node.js为例，通俗点说它是运行在服务端的JavaScript，可以让懂JS的前端人员写出简单的后端服务，完成一些接口的拼装。“通过Node.js，如果一个程序员针对一个简单的需求，从前端到后端都由他自己来实现，由于省去沟通成本以及同步版本发布的动作，效率能提升30%。” 明哥表示，这就是我们常说的“大前端”、“全栈开发者”。而全栈能力就是消解一些组织团队互相配合产生的损耗，减少损耗，自然可以给开发效率、模式带来质的提升。谈到开发效率的提升，时下大火的Serverless正在掀起一场云计算领域的革命，这场风暴也波及到了前端，对于此，明哥显得谨慎很多。 Serverless勾勒了一个不需要搭建环境、部署中间件，没有特定使用场景、业务类型，只需部署代码的世界。这是技术人员的“乌托邦”，但明哥认为当前的Serverless技术有一定的局限性。开发团队不可能只使用一种技术或者组件，而不少技术或者框架，是需要在中间件、操作系统层面进行分析调优工作，Serverless目前没有达到这个灵活性和适配性。华为云官网团队也尝试过应用Serverless提高开发效率，比如把一些后台执行不敏感、可用性要求较低的服务部署上去，再通过定时器触发，也能达到一定效果。但是只要涉及到全场景，尤其是多部件的解决方案，就不会考虑首选Serverless服务。 “可能我比较谨慎，有先进或者新的技术，习惯性观察一阵子，让**再飞一会， 技术成熟稳定后再跟上，那个时候也不晚。” 明哥在技术栈选择这条路上也走过不少弯路，他认为，前端团队选择技术栈一定要结合实际业务需求，再去观察技术栈的生态是不是持续演进中，人云亦云、好高骛远不可取，如果没有合适的，宁愿自研也好过妥协。 冲破技术标签，视野决定高度回望前端技术的迭代，可以说是瞬息万变，新的框架、组件库层出不穷，新的编程语言一波波袭来…… 涉猎不同技术栈的明哥一直在思索，技术的目的是什么？在建设华为云官网的过程中，他似乎找到了答案。 以JAVA为首的后端技术栈，在几十年的迭代中，无论是技术语言，还是框架都趋于稳定。相较之下，前端还朝着技术成熟曲线的峰顶狂奔中，未来也会逐渐从百花齐放过渡到一两个成熟稳定框架一统江山，一步步补全整个生态的阶段。目前一些主流框架本质上也是大同小异，选择一个领域或者技术栈深耕，愈往下探，愈会发现其中的一致性规律。 大浪淘沙中，明哥认为比较有潜力和探索空间的三个技术方向是沉浸式、智能化以及低码化。 首先是沉浸式的效果，所见即所得的前端正在追求更丰富的展现和互动形式。比如工业制造领域的仿真模拟，可以对孪生的数字模型进行各种测试验证。同样，在前端领域，也能把产品可视化地呈现在网站上，让用户直观地感知解决方案的运作模式。 说到这里，他在空气中比划了一下，“你想象把后台看不见摸不着的一些组网解决方案搬到前台，方案中的流程、数据流动都是可以看得到的，很神奇， 但也非常考验后端数据和前端渲染能力的结合，不过我们正在努力。” 第二个是智能化，一方面华为云官网团队会在搜索和推荐中进一步优化智能算法和策略，达到精准的千人千面智能化推荐，提升用户的注册转化率；另一方面，团队会在内容的智能生产方面，包括文章、图片、广告等，做出更多的探索，协助运营人员、业务人员生产出更高质量的内容。 第三个方向是低码化，现在多数业务人员可以自主生产简单的页面，涉及一些复杂页面才有开发人员介入。以后，无论是面向运营人员，还是最终用户，越来越多的页面、接口、流程都会通过低码化或者**化的方式实现。 前端新技术的出现，最终目的还是为了能够响应业务，快速地解决生产、运营的需求，这也是所有技术都在探索的方向。 到了这个阶段，大前端的范畴也在扩充，明哥也更习惯站在架构师的角度去看面前呈现的这些网页，观察它们背后的一系列逻辑。“但凡涉及到用户可感知的内容，其实都是大前端要关注的，对于前端人员来说，前端不仅是一个技术，它更像是一个目的。”最开始，前端这个概念在业界比较模糊，前端人员都自嘲“切图仔”，也没有现在流行的三大框架，混沌初开，大家都摸着石头过河。 这个时代已经一去不复还，如今的前端人员，技术是基础，在此之上的思维和视野则决定了技术的高度。 “比如大家常常在论坛上为哪个编程语言最好而争得面红耳赤。其实，囿于一个技术的优劣，就是在给自己贴标签。就像有的前端人员会纠结技术路线，认为写页面看不到发展空间，这是把自己困在‘前端’的标签里。”“如果你的定位是一个简单的开发，一项技能足矣。但想要成长，得学会跳出那个圈子，换种思路，比如以提高用户体验为目标，可以学的技术就不只是某一个框架或语言。在此过程中，将自身的技术能力和定位从开发人员向架构师，乃至CTO的标准去提升。” 心中有教堂，月亮和六便士，都可以拥有。福利时间到，欢迎大家踊跃留言互动，赢取我们精心准备的前端技术大礼包。 福利：看完华为云官网的业务实践，以及明哥对前端技术的思考，如果你也有业务或者技术上的疑惑，点击下方阅读原文，在评论区留言，明哥将空降评论区，现场答疑解惑。同时，有机会赢取前端大礼包一份：内含首次公开的华为云官网内部资料，以及明哥推荐书籍《领域驱动设计》一套。

为什么要做 Serverless 平台触发这件事情的原因有两部分，第一是趋势，因为前端发展趋势使得前端工程师的工程化效率正在降低，作为基础软件团队，需要思考能否从基础软件层面解决前端的困扰，第二部分是当前前端工程师正面临服务端渲染的问题。首先说趋势，体现在整个前端发展过程中。从以前的 Web 工程师，到前端工程师的职位的出现，当时还只是逻辑分工。第三阶段是前端工程师时代，是一个前后端分离的时代。到我们目前正在处于的前后端（BFF）时代，前端工程师需要去负责部分后端的数据。甚至有些公司已经到了全栈工程师的时代，前端工程师需要负责后端所有的数据。第二阶段和第三阶段，前端人员不需要关心后端资源，只需要把自己的代码写好，由后端或者是运维帮他们去做发布。但是目前所处的阶段，前端人员是需要去关心后端数据的，将来的全栈工程师时代，他们还需要去直接从数据库里边获取 / 操作数据，这个时候我们会发现，他需要操心低层的资源，因为他需要把他的程序跑在服务端的后端，而前端工程师实际上不擅长操作和运维后端资源，因此会使得前端工程师的工程化效率降低。第二点是我们当前正在面临的问题，因为前端工程师目前在做服务端渲染（SSR），采用这个技术的时候他需要自己申请机器，自己部署，同时他还得关注机器的状态，并且他还得时常地翻阅基础设施提供一些运维指南去做运维，其实这个事情是他们很不擅长的，并且对他们来说是一个负担。同时从后端运维的视角来看，前端工程师是在浪费资源。这有两个原因，第一，很多业务属于活动类型的；第二，前端工程师在申请机器的时候，他往往按照上限来预留资源，这就导致了大量的浪费。因此这就产生了“前端工程师在浪费资源”的问题。但其实前端工程师不是故意的，因为他们不擅长运维服务器。因此我们需要解决前端工程师正在面临的痛点。从前端工程师的角度，他们的核心诉求就是只写代码，聚焦核心业务，去创造核心价值，把一些服务端后端运维的事情完全交付给基础设施去做，他们不需要去 care 这个事情。Serverless 的先进理念，其精华正是复杂度转移，使得业务人员能够聚焦他的核心场景，所以我们想打造一款 Serverless 产品，来解决前端工程师当前的困扰。如何打造 Serverless 平台 技术选型打造 Serverless 平台之前，首先要对这个目标做拆解，然后再去做产品选型、技术选型。首先看目标拆解，第一点业务层的需求是即用即上，也就是说前端他想上线一个业务，他不需要去关心太多，他想什么时候上线就可以什么时候上线；第二点就是前端工程师不想去做后端资源的运维；第三点实际上不是前端工程师的需求，而是基础设施层面的一个需求，就是尽量地能支撑好业务，同时也能够省机器省钱。这相对应的目标拆解为：即用即上——需要在技术上具备一键部署的能力；免运维——需要把具体的运维沉淀到基础设施层；节省开支——要求我们这个业务状态相对来说是无状态的，具备高弹性的能力。因此我们的 Serverless 平台要能够集成 CI/CD，同时也能够进行容器化，工作在 Kubernetes 上，具备自动扩缩容的能力。再看产品选型。既然公有云 Serverless 做得这么成熟，我们能否直接采用公有云产品来满足我们业务开发需求？我们的回答是 NO，因为我们需要去满足一些定制化的用户需求，而公有云的 Serverless 产品会受到很多资源包括使用的一些限制；第二个因素是我们的业务存在一些环境依赖，前端所依赖的一些数据库、中间件，都是运行在公司的私有云环境中，这些东西公有云环境上都没有；第三点也是追求技术自由，避免厂商锁定。 所以，我们需要在私有云平台中打造自己的 Serverless 平台。在技术选型上，我们基于三个原因选型了 Knative。底层要基于 Kubernetes： 因为数帆对 Kubernetes 的运维手段比较成熟，本身有大量的业务运行在 Kubernetes 上，我们有专业的团队来做相应的支撑。基于镜像去构建 Serverless： 因为本身的业务是比较灵活多变的，会存在一些程序启动时间比较长的业务，这种业务不是很适合 FaaS。因此我们考虑让它把整个启动过程压缩，通过镜像打包的一种方式来去解决。另外我们还要求易扩展成 FaaS。这些 Knative 都能满足。背景深厚：Knative 后面还有 Google、IBM、Redhat 这些大厂作为支撑。 平台构建轻舟 Serverless 平台设计全景图如下，从下往上有基础设施层、服务层、应用编排层和业务层。其中我们比较关注的是应用编排层和服务层。整个 Serverless 平台工作在已有的基础设施之上，并且我们通过这个 Serverless 平台后端，把它所需要的资源纳入平台组件能力，比如说 CI/CD、Knative API 网关，把这些资源结合起来，满足我们 Serverless 的具体需求。轻舟 Serverless 平台具体的构成，从下图可以看到，Serverless 的核心，我们可以理解成额外做的核心组件，包括一个 Serverless 前端控制台和一个 Serverless 后端。这个核心负责把现有的一些组件联合起来：通过 CI 去完成镜像构建的需求；通过 Knative 去做部署；通过 API 网关去做具体业务的数据链路打通；同时还需要 Gitlab 来存储代码；为了更高的开发效率，需要集成 Web IDE，这样前端开发人员可以只在一个浏览器上就完成他所有的需求；同时为了运维能力，需要去支持平台层面的日志平台，以及监控告警的平台；还需要一些预警，就是 Serverless 跑批和预警的一些组件。轻舟 Serverless 平台在这样的构成下，它具体的流程，我们从业务开发者的视角来看，业务开发者先通过 Web IDE，或者是其他的本地开发工具来完成编码，再把代码 Push 到 GitLab 上去，然后就会触发构建镜像，或者他可以选择手动触发，或者是通过命令行触发。当然这一步也可以把相关的一些资源，降级的静态资源，构建到放到对象存储里面去。Serverless 控制台构建完镜像以后，会通过 Knative 的 Service 去发布这个程序。整个发布过程它会主动地拉取刚才构建的镜像，去做应用的部署和数据链路的打通。这就完成了整个业务的一键部署。一键部署的业务流量模型，首先流量从外网打到外层的基于 Envoy 的 API 网关，API 网关会把流量发给内层的 Knative 网关。随着访问压力的增大，我们要求它能够扩容；而随着资源处在访问的低档期，为了能腾出更多的资源，我们要求它具备缩容的能力。同时这个 Serverless 平台还必须考虑，当这一部分产生了异常的情况下，是否具备降级的能力。我们通过外层的 API 网关去做降级和和静态资源的获取，通过这种方式，如果 Serverless 平台或者 Knative 这一层出了问题，用户可以一键切到已经准备好的静态资源中，不至于让业务产生异常。 产品形态的思考打造 Serverless 平台还有很多必要的考虑。首先平台构建形态方面，为了满足用户的效率需求，我们支持了 FaaS 层平台；为了满足业务复杂又多变的需求，我们支持了传统工程的形态。其中 FaaS 形态最主要的目的是让我们的业务方，特别是前端开发者，可以完全在 Web 浏览器上编码、发布，也就是说他只要身边有一台电脑，通过浏览器就可以随时随地完成他的业务目标，不需要安装一些开发环境。除了这种方式以外，考虑传统使用者的诉求，我们也支持集成到 VS Code 中，同时还支持最传统的通过命令行直接构建 FaaS 的方式，当前我们支持的还只是 Node.js，这个是属于我们用得比较多的技术栈。对于传统工程形态这种方式，Knative 当前是支持的，这种方式最主要的作用是，用户不需要学习新知识就可以直接使用 Serverless，可以像以前一样开发代码，同时它的运营实施比较灵活。一些启动过程很慢的业务，也完全可以采用传统工程形态去做，这样不至于说这类业务没有办法在这个平台上运行。所以说，我们做了这两种产品形态来满足业务方在不同状况下的使用需求。 数据路径的适配因为 Knative 网关只能通过子域名的方式去做业务区分，而我们传统业务，特别是现有的很多线上业务，往往是使用 Host+Path 这种方式去做区分的。为了满足用户的这种使用习惯，我们当然可以修改 Knative 层的开源实现，但是开源又是在不断迭代的，我们考虑再三，做了一些框架结构，通过外置的一层 API 网关去做具体的 Host+Path 的区分，然后转换成 Knative 所支持的子域名方式去做应用区分。同时，我们引入外层的 API 网关还有另一个好处，当 Knative 这一层出问题时，我们可以通过这一层网关去做灰度降级，来保证业务的稳定性。当然，加一层外置网关也会导致数据链路变长，它从外层 API 网关，到内层 Knative 网关，再到 Activator 组件，甚至到 QueueProxy，最后才到业务容器。这样会导致 QPS 比较低，这方面后文我们会给出轻舟团队具体的解决办法。 平台能力的集成平台需要的日志、监控告警、BaaS 等能力，由于轻舟平台已有现成的封装，Serverless 平台直接集成。此外，为了适应 Serverless 这种业务场景，我们额外开发了一个预警的组件，去模拟前端业务方发布一个业务，发布之后把它给部署到 Serverless 平台上，然后检查它能否很好地完成扩缩容。Knative 的实践踩坑和优化接下来分享在打造轻舟 Serverless 平台的过程中，我们对选型的 Knative 这个开源组件所做的事情，主要分为三个部分，第一部分是我们在数据面上做了哪些东西，第二部分是我们在控制面做了哪些优化，第三部分是说使用了 Knative 组件，我们遇到了哪些问题，又是如何解决的。 数据面的优化我们在数据面做的主要工作是数据链路调优。上文也提到 Knative 整个数据链路比较长，我们通过对 Knative 的压测，确定 Knative 的性能有很大的问题。我们通过以下的 5 个步骤来做优化：在整个的数据路径上，把 Activator 从数据路径上去除，因为我们是面向 Web 场景，去除之后不会产生任何业务问题。把 Knative 做升级，从以前的 0.9 升级到 0.14。通过 1 和 2，整个 QPS 提升了大概 50%。为了满足我们一些核心业务对延迟或者是对高性能的需求，我们采用 Fast HTTP 优化了 QueueProxy，把 QueueProxy 的 CPU 使用率降了 50%，同时在降低 CPU 使用率的情况下，它的延迟也降了 30% 左右，QPS 也提升了 30%，也就说使用更少的 CPU，反而带来更多的 QPS 和更低的延迟效果。同时我们做了一个 Revision Deployment 级别的灰度，来降低修改 QeueuProxy 带来的业务风险。在第 3 步优化完 QueueProxy 以后，我们引入了的 Sockops 组件来做框架优化，通过 eBPF 技术实现 QueueProxy 和业务容器之间的 Sidecar 方式的链路优化，QPS 可以在之前的基础上再额外提升 20%，同时延迟降低 8% 左右。针对一些特殊业务需求，我们选型更高性能的容器网络，叫 SR-IOV 网络，来满足它的需求。从我们的实测来看，SR-IOV 容器网络在延迟方面比普通的容器网络大概要降低 10%，同时它的 QPS 是接近物理机的。通过这 5 个步骤，我们满足了不同的业务方的需求。一般来讲，做完 1 和 2 能满足差不多满足一半的业务需求，做完 3 和 4 基本上能满足绝大部分需求，第 5 步是满足一些特殊的业务场景的需求。 控制面的优化控制面上我们主要解决了 Knative ksvc Ready 时间变长的问题。Knative ksvc Ready 时间变长有两个原因。第一个原因是 Serverless Knative 网关，我们采用的是轻舟的 API 网关，它的控制面是依赖于 Pilot，而我们的业务集群又是和服务网格在一起运行的，在默认情况下，Knative 的 Pilot 能感知到服务网格的 VS、DR、SE 这些资源，这就导致了它去做一些无关的资源运算，从而 Knative ksvc Ready 时间变长。第二原因，Knative 有一个组件叫做 network-istio，这个组件需要对整个数据路径去做健康检查，只有在健康检查成功以后它才把 ksvc 置成 Ready 状态。但健康检查有一个特点，它是指数级别回退的，这就导致了如果 5 秒内它没有检查通过，它就只能在 10 秒内才能发现这个东西是健康的；如果它在 10 秒内还没有解决这个问题，检查出来业务已经 Ready 了，它就只能在 20 秒内才能发现业务已经 Ready，这就导致 ksvc Ready 时间变得更长。我们解决的办法有两种，第一种是针对于第一个问题，Knative 网关它只 care 自己的 Namespace 级别的资源，去做一些资源隔离，它不 care 同一个集群内的服务网格的相关的其他资源。第二种就是我们调整了 network-istio 健康检查回退机制，调整成前 20 秒内每秒钟检查一次，20 秒以后才进行指数级回退，通过这种方法防止 ksvc Ready 时间慢的问题。 遇到的困难和解法Knative 层我们主要遇到了如下的困难：Knative 的一个 Autoscaler 组件，它是不支持 HA 的，但是 Knative Autoscaler 组件是扩缩容的核心组件，因此这是业务无法忍受的。一个老生常谈的冷启动问题，我们经过实测，整个的冷启动过程需要 5 秒以上，如果算上拉镜像的时间，甚至可能需要 6~7 秒。做 Knative 适配的时候，和我们内部的容器网络有些冲突，它会导致 Knative 的一些 Webhook 启动失败。适配轻舟 API 网关的时候出现 503 问题。net-isito 组件做完健康检查以后它的连接不会释放，这就导致它的连接大量的堆积，最终导致业务异常。我们的解法如下：针对 Autoscaler 不支持 HA 的问题，我们通过 Pick Knativ0.19 这个版本的一些代码去解决。针对冷启动，我们通过一些预留和一个默认实例来避免冷启动。Webhook 这个问题，最主要是和我们内部容器网络的冲突，我们通过调整网络方式为 hostNetwork 来规避。适配轻舟 API 网关出现 503，最主要也是 Knative 本身的一些问题，因为网关的控制面上存在一些特殊符号，它没有办法识别，这种情况下 0.14 版本的 Network-isito 就没有办法继续往下工作，不过这个问题在 Knative0.15 得到了修复。健康检查连接不释放，这也在 Knative 0.15 得到了解决。当然我们在一开始踩这个坑的时候，Knative 社区还没有解决这些问题，后面我们解决完问题以后，发现社区也已经解决了。所以说我们也是通过检验了，因为我们是尽量地少动 Knative 本身的代码，也是通过这种升级的方式来解决的。    收益    目前轻舟 Serverless 平台在内部已经上线了大概 200 多个前端应用，当然在 2020 年的 Q4 我们也 Release 了一个商业化版本满足对外的需求。我们做完这个事情以后，前端人员的体验是怎么样的呢？首先，我们从前端人员那边收集到的数据，他们以前去部署环境，新员工可能要两周左右，老员工也要三天左右，有了 Serverless 平台，整个部署时间统一降低到三分钟内搞定。其次，因为 Serverless 平台的一些封装使得了前端人员不再需要关注后端资源，所以说他们从业务选型上，可以考虑一些服务端渲染的技术来提升业务的首屏体验。再次，从趋势上来说，免去运维的困扰更加符合前端趋势，这让前端人员可以轻松地去开发 BFF 层的一些需求，甚至可以支撑他们往全栈工程师去过渡，通过这些支持给前端提供一个更大的灵活度。未来展望展望未来，我们需要在公司内部业务场景继续打磨轻舟 Serverless 平台，让它变得更加稳定，功能更加强大，主要聚焦三个方面：首先我们会提升 Serverless 平台的产品能力，考虑使用 Knative 的 Eventing 组件，去融合我们的轻舟中间件、对象存储这些底层设施的资源，来满足业务更加多变的需求。其次是我们 Serverless 平台上线以后，前段时间业务方反馈它整个的调试化过程的效率降低了，所以我们打算提供一些本地的调试套件去解决调试的困扰。最后，我们会紧跟着 Knative 社区，关注 Knative FaaS Kn 的实现，同时也考虑去对接公有云的一些 Serverless Framwork，一些 API 规范标准，这样将来如果业务方有需求，它完全可以无感地从私有云平台上迁到公有云平台上，所以我们打算做这么一层封装。

Pagic + Vercel 极速搭建个人博客❝在中国功夫中，“天下武功，无坚不摧，唯快不破”，在编程的世界里，如何快速搭建一个属于自己的博客呢？那么 Pagic + Vercel 应该是个不错的选择！❞PagicPagic 是一个由 Deno + React 驱动的静态网站生成器。它配置简单，支持将 md/tsx 文件渲染成静态页面，而且还有大量的官方或第三方主题和插件可供扩展，也就意味着您可以自由地开发定制您喜欢的主题风格或者功能插件。相比其他静态网站生成器， Pagic有哪些优势呢？PagicVuePressHexoJekyllHugoSupport md✓✓✓✓✓React/Vue✓✓SPA✓✓Allow tsx in config✓...如此优秀的 Pagic 应该如何使用呢？首先，安装 Deno :# Shell (Mac, Linux):curl -fsSL https://deno.land/x/install/install.sh | sh然后，安装最新版本的 Pagic :deno install --unstable --allow-read --allow-write --allow-net --allow-run --name=pagic https://deno.land/x/pagic/mod.ts初始化 Pagic 项目：mkdir site && cd site && echo "export default {};" > pagic.config.ts && echo "# Hello world" > README.md运行 pagic build:pagic build --watch --serve现在您访问 127.0.0.1:8000 就能看到 「Hello world」 的页面：VercelVercel是一个用于静态站点和 Serverless 功能的云平台，完全符合您的工作流。它使开发人员能够托管网站和web服务，这些网站和服务可以即时部署、自动扩展，并且不需要任何监督，所有这些都不需要配置。部署到 Vercel 需要我们先在项目根目录创建 deploy-vercel.sh 文件：!/bin/sh# Install denocurl -fsSL https://deno.land/x/install/install.sh | sh# Install pagic/vercel/.deno/bin/deno install --unstable --allow-read --allow-write --allow-net https://deno.land/x/pagic/mod.ts# Pagic build/vercel/.deno/bin/deno run --unstable --allow-read --allow-write --allow-net --allow-run https://deno.land/x/pagic/mod.ts build然后在项目根目录创建 package.json :{    "scripts": {        "deploy:vercel": "sh deploy-vercel.sh"    }}Vercel 支持 Github、GitLab、Bitbucket 等方式进行登录：我使用 Github 比较多，因此我在Github 上新建一个仓库 pagic_template :然后将本地的代码提交到 Github：接下来，在 Vercel 网站完成以下步骤：在首页点击导入项目 (Import Project)填写仓库地址，从 Github 导入要部署的仓库，点击继续配置项目信息填写项目名，框架预设默认 Other 即可打包与输出配置，构建命令: npm run deploy:vercel 输出目录: dist (也可以根据自己的配置填写)点击部署，等待部署完成即可访问Blog目前， Pagic 支持三种主题： Default、DOC、Blog，我们尝试修改pagic.config.ts 文件开启 Pagic 的博客模式:export default {    theme: 'blog',    plugins: ['blog'],    title: 'pagic template',    description: 'Use this template to create a Pagic site with the blog theme.',    github: 'https://github.com/hu-qi/pagic_template',    blog: {        root: '/posts/',        social: {          github: 'hu-qi/pagic_template',          email: 'huqi@gpdi.com',          twitter: 'huqii',          v2ex: 'huqi',          zhihu: 'fashaoge'        }      }};在上边的代码中，我们为博客配置了 Title、description等参数，其中 social ，可配置我们的社交账号，默认支持 Github、Email、Twitter、V2ex、Zhihu,当然您也可以自己开发主题或者插件来自定义您想要的。接着我们开始完善博客中常用到的导航、分类、标签、外链等,这时我们需要添加一些目录，如about、archive、links等等，为了统一管理，我们将这些文件夹全部放置在 src目录下,我们的目录结构如下：site                          ├─ dist                       // output   ├─ src                        // input│  ├─ about                   │  │  └─ README.md            │  ├─ archives                │  │  └─ README.md            │  ├─ assets                  │  ├─ categories              │  │  └─ README.md            │  ├─ links                   │  │  └─ README.md            │  ├─ posts                   // maybe write somethings│  ├─ tags                    │  │  └─ README.md            │  └─ README.md               // homepage├─ README.md                  ├─ deploy-vercel.sh           ├─ package.json               └─ pagic.config.ts            配置方面，我们增加了 nav ，并把 srcDir 设置为 src ：export default {+   srcDir: 'src',+   nav: [+       {+         text: 'Homepage',+         link: '/index.html',+         icon: 'czs-home-l',+       },+       {+         text: 'Categories',+         link: '/categories/index.html',+         icon: 'czs-category-l',+       },+       {+         text: 'Tags',+         link: '/tags/index.html',+         icon: 'czs-tag-l',+       },+       {+         text: 'About',+         link: '/about/index.html',+         icon: 'czs-about-l',+       },+       {+         text: 'Archives',+         link: '/archives/index.html',+         icon: 'czs-box-l',+       },+       {+         text: 'Friends',+         link: '/links/index.html',+         icon: 'czs-link-l',+       },+     ],}在移动端， Pagic 也有不错的体验：接着我们在 posts 目录下以markdown的形式写文章，我们可以在 .md 文件头加一些字段以便进行分类统计，如：---title: Pagic + Vercel 极速搭建个人博客author: huqidate: 2021/02/04cover: 'https://assets.vercel.com/image/upload/v1595320886/front/home/globe-texture.jpg'categories:- Blogtags:- Deno- React- Pagic- Vercel---编写一些文章之后，我们的博客看起来很丰富了！此时，我们将代码提交到远程仓库就会自动部署到 Vercal，以后，我们每写一篇文章提交到远程仓库就 Vercal 就能自动部署更新，简直太棒了！感谢多多指教： https://github/hu-qi/pagic_template公众号： 胡琦WeChat： Hugi66

 摘要：Serverless 架构不是不要服务器了，而是依托第三方云服务平台，服务端逻辑运行在无状态的计算容器中，其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless 是什么我们在题目提出了一个问题，Serverless 架构是不是就不要服务器了？回答这个问题，我们需要了解下 Serverless 是什么。Serverless 架构近几年频繁出现在一些技术架构大会的演讲标题中，很多人对于 Serverless，只是从字面意义上理解，无服务器架构，但是它真正的含义是开发者再也不用过多考虑服务器的问题，但是并不代表完全去除服务器，而是我们依靠第三方资源服务器后端，从 2014 年开始，经过这么多年的发展，各大云服务商基本都提供了 Serverless 服务。架构是如何演进到 Serverless ？看看过去几十年间，云计算领域的发展演进历程。总的来说，云计算的发展分为三个阶段：虚拟化的出现、虚拟化在云计算中的应用以及容器化的出现。云计算的高速发展，则集中在近十几年。总结来说有如下的里程碑事件：通过虚拟化技术将大型物理机虚拟成单个的VM资源。将虚拟化集群搬到云计算平台上，只做简单运维。把每一个VM按照运行空间最小化的原则切分成更细的Docker容器。基于Docker容器构建不用管理任何运行环境、仅需编写核心代码的Serverless架构。从裸金属机器的部署应用，到 Openstack 架构和虚拟机的划分，再到容器化部署，这其中典型的就是近些年 docker 和 Kubernates 的流行，进一步发展为使用一个微服务或微功能来响应一个客户端的请求 ，这种方式是云计算发展的自然过程。这个发展历程也是一场 IT 架构的演进，期间经历了一系列代际的技术变革，把资源切分得更细，让运行效率更高，让硬件软件维护更简单。IT架构的演进主要有以下几个特点：硬件资源使用颗粒度变小资源利用率越来越高运维工作逐步减少业务更聚焦在代码层面Serverless 架构的组成Serverless架构分为 Backend as a Service(BaaS) 和 Functions as a Service(FaaS) 两种技术，Serverless 它是由开发者实现的服务端逻辑运行在无状态的计算容器中，它是由事件触发，完全被第三方管理的。什么是 BaaS?Baas 的英文翻译成中文的含义：后端即服务，它的应用架构由大量第三方云服务器和API组成的，使应用中关于服务器的逻辑和状态都由服务提供方来管理的。比如我们的典型的单页应用SPA和移动APP富客户端应用，前后端交互主要是以RestAPI调用为主。只需要调用服务提供方的API即可完成相应的功能，比如常见的身份验证，云端数据/文件存储，消息推送，应用数据分析等。什么是 FaaS?FaaS可以被叫做：函数即服务。开发者可以直接将服务业务逻辑代码部署，运行在第三方提供的无状态计算容器中，开发者只需要编写业务代码即可，无需关注服务器，并且代码的执行它是由事件触发的。Serverless的应用架构是将 BaaS 和 FaaS 组合在一起的应用，用户只需要关注应用的业务逻辑代码，编写函数为粒度将其运行在FaaS平台上，并且和BaaS第三方服务整合在一起，最后就搭建了一个完整的系统。整个系统过程中完全无需关注服务器。Serverless 架构的特点总得来说，Serverless 架构主要有以下特点：实现了细粒度的计算资源分配。不需要预先分配资源。具备真正意义上的高度扩容和弹性。按需使用，按需计费。由于 Serverless 应用与服务器的解耦，购买的是云服务商的资源，使得 Serverless 架构降低了运维的压力，也无需进行服务器硬件等预估和购买。Serverless 架构使得开发人员更加专注于业务服务的实现，中间件和硬件服务器资源都托管给了云服务商。这同时降低了开发成本，按需扩展和计费，无需考虑基础设施。Serverless 架构给前端也带来了便利，大前端深入到业务端的成本降低，开发者只需要关注业务逻辑，前端工程师轻松转为全栈工程师。Serverless 有哪些应用场景？应用场景与 Serverless 架构的特点密切相关，根据 Serverless 的这些通用特点，我们归纳出下面几种典型使用场景：弹性伸缩、大数据分析、事件触发等。弹性伸缩由于云函数事件驱动及单事件处理的特性，云函数通过自动的伸缩来支持业务的高并发。针对业务的实际事件或请求数，云函数自动弹性合适的处理实例来承载实际业务量。在没有事件或请求时，无运行实例，不占用资源。如视频直播服务，直播观众不固定，需要考虑适度的并发和弹性。直播不可能 24 小时在线，有较为明显的业务访问高峰期和低谷期。直播是事件或者公众点爆的场景，更新速度较快，版本迭代较快，需要快速完成对新热点的技术升级。大数据分析数据统计本身只需要很少的计算量，离线计算生成图表。在空闲的时候对数据进行处理，或者不需要考虑任何延时的情况下。开发者编写代码，目前支持的语言Java、NodeJS、Python等语言。把代码上传到函数计算上，上传的方式有通过 API 或者 SDK 上传，也可以通过控制台页面上传上传，还可以通过命令行工具Fcli上传。通过API&SDK来触发函数计算执行，同样也可以通过云产品的事件源来触发函数计算执行。函数计算在执行过程中，会根据用户请请求量动态扩容函数计算来保证请求峰值的执行，这个过程对用户是透明无感知的。函数执行结束。事件触发事件触发即云函数由事件驱动，事件的定义可以是指定的 http 请求，或者数据库的 binlog 日志、消息推送等。通过 Serverless 架构，在控制台上配置事件源通知，编写业务代码。业务逻辑添加到到函数计算里，业务高峰期函数计算会动态伸缩，这个过程不需要管理软硬件环境。常见的场景如视频、OSS 图片，当上传之后，通过进行后续的过滤、转换和分析，触发一系列的后续处理，如内容不合法、容量告警等。小结回到我们文章的题目，Serverless 架构不是不要服务器了，而是依托第三方云服务平台，服务端逻辑运行在无状态的计算容器中，其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless 无服务器架构有其适合应用的场景，但是也存在局限性。总得来说，Serverless 架构还不够成熟，很多地方存在不完善。Serverless 依赖云服务商提供的基础设施，目前来说云服务商还做不到真正的平台高可用。Serverless 资源虽然便宜，但是构建一个生产环境的应用系统却比较复杂。云计算还在不断发展，基础设施发服务日趋完善，开发者将会更加专注于业务逻辑的实现。云计算将平台、中间件、运维部署的责任进行了转移，同时也降低了中小企业上云的成本。让我们一起期待 Serverless 架构的未来。 本文分享自《【华为云专家原创】Serverless 架构就不要服务器了？》，原文作者：aoho。

准备工作1. 建议先 点击此处 下载.rar格式的压缩文件，只需经过一次解压即可得到 .tar 格式的镜像打包文件“docker-2048”哦。2. 建议先 点击此处 购买CCI 9元超值体验套餐包，游戏部署体验更佳哦！~下面来是完整操作步骤步骤一：创建命名空间命名空间（namespace）是kubernetes 的一个典型概念，是一种在多个用户之间划分资源的方法，适用于用户中存在多个团队或项目的情况。当前CCI服务提供两种类型的资源：“通用计算型”和“GPU型”。创建命名空间时需要选择资源类型，后续创建的负载中容器就运行在此类型的集群上。1. 登录云容器实例管理控制台，左侧导航栏中选择“命名空间”。2. 选择创建“通用计算型“命名空间。点击“一键创建”即可获得一个全新的命名空间（cci-auto-1548297057827），用于对即将部署的游戏应用进行管理。   步骤二 部署工作负载工作负载是对Pod的服务化封装，当前CCI服务中主要支持无状态负载、短任务负载、定时任务负载等。本例中游戏应用以无状态负载的方式作为一个长稳应用部署在CCI服务中。1.  在左侧导航栏中选择“工作负载”，在右侧选择上一个步骤创建的命名空间，单击“创建负载”。2. 配置无状态负载基本信息 a. 填写负载名称； b. 选择POD数量；当配置多个Pod时，云容器实例会自动在Pod间做负载均衡。此处建议POD数量不小于2，否则无法保证应用的HA能力。c. 填写负载描述信息。3. 容器设置a. 选择镜像。点击“上传镜像”、在容器镜像服务中选择“页面上传”，选择组织，选择镜像文件，上传已下载至本地的镜像文件“docker-2048”即可。上传完毕后，返回创建无状态工作负载页面刷新， 即可看到刚刚上传的镜像，点击“使用该镜像”b. 根据需要配置容器规格及高级设置（存储、环境变量、健康检查、生命周期、启动命令和ConfigMap）。本示例请保持默认值不变，然后单击“下一步”。4. 访问设置关于负载的访问设置，有如下3种选项：不启用：负载不提供外部访问方式，适合一些计算类场景，只需计算完存储结果即可，无需与外部通信。内网访问：负载之间通过“负载域名:负载端口”互相访问。公网访问：通过弹性负载均衡，从外部访问访问负载。本示例中我们的小游戏应用需要能够通过公网进行访问，此处选择公网访问。a. 参考界面提示在弹性负载均衡的界面购买增强型ELB。购买后点击界面的刷新即可选择对应的ELB实例使用。b. 选择“ELB协议”：TCP/UDP本例中，数字游戏应用的流量只需要做四层负载均衡，在TCP层进行流量转发到容器中的指定端口（80）即可。c. 选择“负载端口协议”：TCPd. 选择负载端口配置，此处ELB端口系统会根据当前选择的ELB实例的端口占用情况，自动推荐可用端口。容器端口和具体部署的应用开放端口有关，本例中该容器实例开放端口80。e. 点击下一步。5. 规格确认后，点击提交，单击“返回负载列表”。在负载列表中，待负载状态为“运行中”，负载创建成功，本游戏应用即部署完成。步骤三 获取游戏应用访问地址1. 单击负载名称，进入负载详情页面2. 选择“访问配置 > 公网访问”Tab页，拷贝公网访问地址（即“ELB IP地址:端口”），即可在浏览器中访问本游戏应用。