华为MetaERP资产核算系统使用华为云函数工作流FunctionGraph（基于元戎内核）微服务serverless化解决方案，实现了复杂企业应用MetaSaaS Serverless化，成本节约70%。资产核算是指在一定的财务周期，对企业拥有的房屋建筑物、机器设备、商标权和专利权等资产的取得、折旧和处置的会计核算，反映企业固定资产、无形资产的增减变动和价值分摊活动。华为资产核算产品，支撑企业资产从获取到处置全生命周期的管理和交易核算，在资产使用寿命内遵循会计准则和税法折旧的要求系统地计提资产折旧费用。华为集团资产核算场景非常复杂，具备以下四大特点：数据海量管理的固定资产和无形资产的数量多达200多万项；涉及国家多覆盖国际会计准则和全球170多个国家的会计准则和税法政策要求；业务流量不均衡平时业务流量少，月末结账场景流量巨大，特别是在季结、年结时，1~2小时内需完成200多万笔资产折旧、300多万的分录生成；原先业务是基于关系型数据库构建，这套架构能很好地解决数据一致性控制，但强依赖数据库性能，在业务数据流量不均衡的情况下，系统计算资源无法实现弹性伸缩。平日业务数据流量小时，系统资源大量闲置未得到有效利用，一旦遇到业务冲刺、月结等数据洪峰，系统资源又无法弹性扩容，导致业务数据积压，严重影响业务处理效率。服务弹性慢，业务峰值处理性能不足：在月底、年底结账期，批量导入导出等任务集中生成，服务CPU资源利用率会瞬间突增至50%到100%不等。服务弹性能力较弱，启动时延超过了1分钟，一旦出现预留资源不足的情况，极易影响业务性能，导致无法在1~2小时内完成百万级资产核算业务的处理；周期性集中处理型业务，预置资源利用率低：以批量上载、资源折旧两个业务为例，虽然平时很少使用，但为了保证服务随时可用，仍然需要保持最低配置在线，业务平均资源利用率不到2%。随着资产核算业务的不断演进、微服务数量增加，资源成本问题被进一步放大；业务上线周期长，运维压力大：业务开发人员不仅要关注业务逻辑，还要额外考虑高并发等极端场景的处理，开发工作量大，问题多。在业务上线前需提前采购、配置硬件资源，日常运行时，不同服务弹性策略不同，需投入大量精力进行资源类的运维工作。业务的版本上线时间达到月级，无法快速响应客户需求；为了进一步优化资源成本、简化服务开发，实现应用的现代化的转型，MetaERP资产核算业务决定采用华为云函数工作流 FunctionGraph试点Serverless化服务改造：1、全自动弹性，算力随叫随到，轻松应对流量波峰资产核算业务相关服务采用Java开发，改造为函数后，面临冷启动的问题。通过创新的进程级快照加速方案，应用直接从初始化后的快照进行运行环境恢复，从而跳过复杂的框架启动、业务初始化阶段，助力资产核算业务冷启动时间缩短到7秒，相比之前一分钟的启动时延，性能提升10倍。同时，FunctionGraph按请求并发量全自动弹性，无需再手动扩缩容，弹性速度实时匹配业务量，轻松应对流量波峰。2、无请求时不需启动业务实例，资源成本降低70%函数实例随请求自动扩缩容，在没有请求时，实例会缩容到0。基于此能力，针对批量上载、资源折旧类业务场景，减少了最小预置实例资源，资产核算业务Serverless化改造后常驻实例资源降低75%，月均资源消耗降低70%，收益显著。3、存量业务无缝迁移，新业务开发运维效率提升3倍资产核算存量业务基于SpringBoot等微服务框架开发，直接改造为原生函数方式工作量非常大。为此FunctionGraph提供了Springboot等框架兼容能力，服务只需集成统一SDK，并进行少量配置文件修改，即可完成改造，实现微服务平滑Serverless化。同时，对比传统微服务框架，FunctionGraph内置心跳检测、服务治理等能力，使能业务更聚焦。同时，新业务使用华为云函数工作流 FunctionGraph开发，可拆解粒度更小、开发并行度更高。函数本身依赖后端数据库、消息队列等服务，需要集成多个SDK才能实现访问，开发复杂度高。对此FunctionGraph提供了统一对接后端链接能力(ServiceBridge)，简化业务访问后端服务。ServiceBridge也天然具备弹性能力，当访问量激增时自动进行扩容。基于原生函数开发模式，可实现天级业务上线、免资源运维，以资产核算为例，业务上线时间从94人天(传统的应用构建流程)降低至30.5人天，大大提升了开发和运维效率。首战告捷持续推进MetaERP应用现代化华为云函数工作流FunctionGraph将持续打造通用Serverless技术竞争力，致力解决Java服务启动慢、弹性能力不足等问题，使能负载在硬件资源的“细粒度”复用，以提高资源的利用率。同时提供与“硬件无关”的编程抽象和系统服务，简化分布式应用的开发、部署和运维。MetaERP资产核算业务Serverless化后性能未劣化，常驻实例资源降低75%，月均资源消耗降低70%，成本优化收益明显。同时服务上线时间降至30.5人天，提升了开发运维效率。接下来，华为云函数工作流FunctionGraph将持续围绕“极简架构、极高质量、极低成本、极优体验”的目标，持续技术创新，助力MetaERP Serverless化，用技术力量提升企业服务质量、效率、体验。在2023年7月25日，由中国信息通信研究院（以下简称“中国信通院”）和中国通信标准化协会联合主办的2023可信云大会上，华为云函数工作流FunctionGraph凭借此最佳实践荣获“可信云2022-2023年度云原生-Serverless技术最佳实践”。转自华为云开发者联盟

近日，华为开发者大会2023（Cloud）在东莞成功举办，期间“全域Serverless化，引领下一代云计算新范式”专题论坛人气满满。华为云首席产品官方国伟携手业界专家、客户、伙伴，面向广大开发者，分享了在Serverless领域的前沿思考和实践。华为云致力于推进全域Serverless，通过核心产品全面的Serverless化，具有极简开发部署、极快自动弹性、极低成本消耗的优势，能够帮助企业缩短TTM从周到天、成本大幅降低、毫秒级扩容轻松应对流量洪峰，成就高质量增长的现代化企业，支撑千行百业应用现代化。华为云致力核心产品全面Serverless化华为云首席产品官方国伟介绍，华为云的目标是将各领域产品逐步Serverless化，包括函数工作流FunctionGraph、数据仓库GaussDB(DWS)、盘古大模型、AI开发生产线ModelArts、云数据库GaussDB(for MySQL)、事件网格EventGrid等产品，帮助企业缩短交付周期，提升上云效率，抢占市场先机。华为云Serverless以GP（General Purpose） Serverless为演进目标，在Serverless基础设施和基于元戎架构构建的分布式内核两方面做持续投入。应用托管运维提供了函数工作流FunctionGraph和云应用引擎托管CAE两种方式，支持Web应用、分布式Job应用、微服务应用等主流应用的全托管。大数据领域把数据作业流中的核心产品全部Serverless化，包括数据仓库GaussDB(DWS)，数据湖探索DLI，云搜索CSS等都提供了Serverless版本；机器学习领域提供了开箱即用的AI开发生产线ModelArts，按需进行分布式训练，自动化模型生成；数据库通过存算分离，提供了以应用为中心的Serverless版本；应用集成领域提供事件网格EventGrid，以不同形式进行应用、数据、消息的集成。通过全面的Serverless化，开发者可以搭建各种场景下的复杂应用，按需计费，无需运维基础设施，享受云技术红利。方国伟预告了华为云产品动态。下半年华为云将发布两个新产品：一个是CCE Autopilot，目标是降低用户负担；另一个是轻量容器实例，面向中小企业，帮忙用户方便使用CCE Autopilot。在面向Cloud Bursting场景，去哪儿网基于华为云Serverless容器打造了灵活上云新体验，带宽成本下降了90%，批创性能提升70%，该方案可广泛应用于互联网行业。华为云FunctionGraph 2.0 四大核心能力全新升级：Serverless应用中心、智能Serverless化底座、异构Serverless资源池、大文件加速技术等能力全新升级，AIGC应用开发将更高效。在车联网场景，某Top车企使用FunctionGraph将业务Serverless化，实现了毫秒级弹性，成本降低40%。同时，华为云CAE产品升级：微服务Serverless托管，运维效率提升50%、实现自动跨AZ的高可用能力；并将GaussDB(for MySQL) Serverless化，实现业务无感知的极致弹性。DataArts数据治理生产线核心服务Serverless化全新升级，增强了Serverless大数据平台DLI的弹性伸缩能力，让Spark、Flink、SQL作业集群可以共享同一个弹性资源池，降低了30%资源消耗。华为云函数工作流FunctionGraph：助力企业快速构建敏捷弹性的现代化应用华为云PaaS服务Serverless产品总监分享了“迈向Serverless，快速构建敏捷弹性的现代化应用”的主题演讲，推出Serverless应用中心，该中心提供大量Serverless应用模板，能够一键部署函数和周边依赖资源，节省部署时间，让开发人员快速上手使用函数、创建Serverless应用。同时，发布《华为大型应用Serverless化最佳实践》，详细介绍了华为财经系统Serverless化改造实现流程及收益。现代化应用体现在应用架构、应用价值、应用体验、应用生成、应用交付、应用安全六个方面。那么Serverless如何帮助企业实现应用现代化？“Serverless代表计算、架构、开发模式3条演进线的交汇点：架构模式的演进，让开发者不需要关注底层资源，获取更高的弹性；开发模式的演进，通过FunctionGraph，将代码上传到平台上，应用即可快速运行；计算模式的演进，让开发者做到服务器无感知。华为云函数工作流FunctionGraph是Serverless的首要产品形态，可以快速构建敏捷弹性的现代化应用。”华为云PaaS服务Serverless产品总监介绍。华为云函数工作流FunctionGraph已支撑千行百业进行应用现代化，在车联网现代化方面，实现了架构的自动灵活扩展，实现了高度自动化运维，大幅降低了成本。在AIGC行业现代化方面，构建了全新的Serverless应用中心，帮助开发者快速完成从0到1业务开发，5分钟高效部署和发布AIGC应用，研发效能提升80%，另外依托更智能的Serverless底座，实现毫秒级极致冷启动，性能大幅提升。最佳实践：华为MetaERP资产核算Serverless化后，资源成本降低70%华为MetaERP财经领域首席架构师韩骁分享了“资源成本降低70%！华为MetaERP资产核算的Serverless实践”，基于FunctionGraph能力，提供微服务serverless化解决方案，能实现复杂企业应用MetaSaaS Serverless化。在MetaERP改造上，针对CPU使用率低、典型洪峰、最低资源在线、所需资源降不下来等业务痛点，使用Serverless后，函数化改造后性能未劣化，降低资源成本明显，常驻实例资源降低75%，月均资源消耗降低70%；另外，开发和运维效率大幅提升，从94人天降到30.5人天。华为云Serverless容器：开箱即用，简化用户体验华为云云原生产品总监在“Serverless容器开箱即用，简化用户体验”的主题演讲中表示，云原生向分布式化和Serverless化演进，华为云通过持续Serverless化，云原生产品全面进入自动驾驶时代，目前，云原生Serverless容器已支持多场景业务负载灵活弹性扩容。依托Serverless的极致弹性能力，实现30秒扩容超2万核，微博热点事件平稳运行，帮助微博轻松应对全年50+次的突发流量浪涌。另外，CCE和CCI支撑深势科技打造了分布式多云调度平台，CCI作为Serverless容器服务，资源秒级开通、按需使用、降成本；长稳业务运行在CCE节点，批量计算任务运行在CCI，实现整体成本最优。成功案例：百果园基于CCI实现流量灵活治理，业务极速弹性深圳百果园实业（集团）技术总监付春分享了“百果园基于CCI实现流量灵活治理，业务极速弹性”的主题演讲。基于Serverless容器落地DevOps平台，实现微服务架构统一治理，开发效率提升30%，成本优化20%。华为云CCI是大规模高性能云原生Serverless容器资源底座，具备极致弹性、多元算力、按需计费、灵活弹性策略的特点；另外CCI支持对接CCE集群内安装的开源Istio插件，通过Istio控制面下发的流量治理策略，实现运行在CCE和CCI上的Pod业务流量统一治理；再基于华为云容器落地DevOps平台，通过UCS实现多云统一管理，百果园希望实现Business&DevOps&FinOps的模式。方国伟认为Serverless 技术将朝着更通用的方向发展，极大简化云计算的编程模型，让开发者无需再关注资源申请、环境搭建、负载均衡、扩缩容等服务器相关的底层操作，只要聚焦核心业务上层应用逻辑的开发创新与实现，这也为企业降本提质增效、数字化转型和应用现代化创造了无限可能。转自华为云开发者联盟

华为云Serverless最全参会攻略带您开启Serverless奇妙之旅！华为开发者大会2023 ( Cloud )倒计时4天！形式多高端峰会、专题论坛、扫地僧见面会、展览展示、CodeLabs训练营，从趋势到概念，从理论到实践，从“用耳听”到“用手写”，从观众席到讲台，一站式全流程体验Serverless技术。大咖多华为资深架构师、产品专家、技术专家畅谈函数计算、边缘函数计算、冷启动等热门话题。干货多华为内外部用户分享业务Serverless化最佳实践，同行业用户关注的“怎么做的”、“有什么效果”等话题首次揭秘。礼品多观看《全域Serverless化，引领下一代云计算新范式》现场直播抽取华为云定制礼品。扫描下方海报二维码或点击文末“阅读原文”预约现场直播!7月8日-9日，华为欧洲小镇溪村，带您开启Serverless奇妙之旅！

Serverless被业界称为云计算的下一个10年，“Serverless 简化了云计算的编程，其代表了程序员生产力的又一次的变革，如编程语言从汇编时代演变为高级语言时代。本体验营将带你了解无服务计算概念，学会如何基于Severless技术构建可用于个人学习以及生产开发的个人网站，一站式高效体验华为的云端应用开发！>> 点击快速报名活动<<

有两种方法收集服务构建器相关日志，选择一种即可（一种不行换另一种）：一、通过ManageOne运维面统一日志收集日志1、登录ManageOne运维面2、点击日常运维->统一日志->运维日志3、点击管理侧运行日志->新增日志下载任务4、收集movappservice日志：输入任务名称，选择自定义，选择收集日志的时间段。一次点击ManageOne->MOVAPPService->/var/log/oss/* /MOVAPPService/movappservice-* /log/root*,点击确定，执行任务5、收集mortsservice日志：输入任务名称，选择自定义，选择收集日志的时间段。一次点击ManageOne->MORTSService，选择/var/log/oss/* /MORTSService/heat-engine* 和/var/log/oss/* /MORTSService/heat-api*，点击确定，执行任务6、确认任务执行成功，点击下载，下载日志二、通过ManageOne运维面autoops执行MO0009编排收集日志1、登录ManageOne运维面2、点击日常运维->自动作业3、如题依次点击，执行mo-0009编排，收集movappservice和mortsservice日志4、输入要收集日志的时间段，要覆盖问题发生的时间，比如要收集2022年2月17日17:00-2022年2月18日17:00的日志，如图中填写即可。点击执行，收集日志5、确认编排执行成功，点击下载结果，下载日志

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 将会在更多领域发挥至关重要的作用。