江苏龙网

  1. 首页 > 人文 > >

开发运维配置繁杂，是时候给应用架构做减法了

“Lessismore”是路德维希·密斯·凡德罗在建筑领域提出的观点 ， 近些年来 ， 这一观点不断被用于生活中的其他领域 。 在软件开发世界中 ， 也有对“Lessismore”这一观点的架构理念 ， 这就是如今逐渐盛行的“Serverless架构” 。
十多年前 ， 主流的应用架构都是单体应用 ， 当时的开发者们既要关注所需的计算、存储资源 ， 还要关注最底层的服务器等资源 ， 同时当企业业务规模开始激增 ， 导致开发和运维难度更大 。 随着容器技术的衍生及应用 ， 虽然用户可以从对基础服务器关注中抽离出来 ， 但其投入的运维精力依然绕不开的是与业务相关的CPU、内存、网络等资源 。
如今在资源投入、架构理念、架构模式向越来越精简 ， 越来越“物尽其用”的演进中 ， Serverless可以说是“Lessismore”的最佳实践 。 它让开发人员不再操心运行所需的资源 ， 精简自己的开发流程 ， 将关注点重点放在产品代码、业务逻辑上 ， 同时只需为实际消耗的资源付费 。 它使得程序开发架构中只保留了重要的、有价值的资源；其余的资源要么从开发主体中精简剔除 ， 要么隐藏在选择性可见的界面中 ， 用户随用随取 。
1Serverless是“速度”与“激情”的再现Serverless是随着云计算、虚拟化的延伸发展历程演进而来的 。 有人说 ， 未来将是Serverless的天下 。 那么 ， Serverless究竟有哪些优势 ， 使得它受到开发者们如此高的重视呢？
节省维护成本 ， 可实现自动伸缩
首先 ， Serverless是一个基于云的服务 ， 服务提供者帮助处理了服务器端的基础IT工作 ， 比如把云部署从x86机器码（99%的云计算机使用x86指令集）提升到了高级语言层面、管理操作系统、数据库版本升级等等 。 因而开发者们只要编写代码并部署它即可 ， 不需要处理任何后端服务器的任务 。
同时 ， 相比于传统的非Serverless架构 ， 这种架构模式带来的另一大优势是 ， 开发者无需为过度配置或意外的负载峰值提前做好分配计划 。 因此 ， 在企业级架构侧常常会遇到的服务伸缩性等问题 ， Serverless也可以做到自动伸缩 ， 或方便开发者对容量进行简单的手动设置 。
节省人工成本 ， 复杂工作都可以交给机器
一方面 ， Serverless有相对标准的编程环境 ， 减少了对服务器和容器部署所耗费的操作成本 。 另一方面 ， 在所有的应用程序架构中 ， Serverless应用程序拥有的代码量最少 ， 且恰当的Serverless架构在相互依赖性上较少 。
对于开发者来说 ， 这意味着更少的开发逻辑 ， 用更少的代码来定义开发、测试、部署、运维 。 另外从应用程序角度来看 ， 无服务器的功能基本上是一种外部服务 ， 它不需要紧密集成到应用程序的容器生态系统中 。
缩短交付时间与周期 ， 节省开发成本
随着产品及软件版本迭代周期的速度越来越快 ， 一些云厂商在面向客户的咨询调研中发现 ， 越来越多的客户已不满足于缩短开发与测试的周期 ， 而是需要更短的交付周期——从新产品或功能的概念化到以MVP部署到生产环境的整个时间 。
在应对该问题的解决方案上 ， Serverless提供了巨大的作用 。 部分客户在使用该架构及应用程序后 ， 能实现在几天时间内完成项目的部署 。
总的来说 ， Serverless可以称得上是当前各类新架构中“激情与速度”的再现——在降低人工成本、降低风险、降低基础设施成本、提高扩展性、缩短交付时间上 ， 都形成了绝对的杠杆力 。 目前 ， Serverless的适用场景非常广泛 ， 或者说它或将成为大多数交付链中的一部分 。
不过 ， 必须要提的一点是 ， Serverless所具备的优势并不等于它是万能的 。 很多开发者基于对Serverless优势的理解 ， 容易陷入“它是容器替代方案”的认知误区 。 而实际上 ， Serverless与容器针对的是不同的用户需求 。
2AWSServerless的基础技术革新之旅1.Lambda开启Serverless商业化进程Serverless商业化进程的真正开启 ， 起源于AWS在2014正式推出的AWSLambda计算服务 。 随后 ， 各大巨头也都相继推出了相关服务 ， 遂而将Serverless的市场竞争推向白热化 ， Serverless是云服务商提供云服务能力的试金石 ， 如何兑现向客户承诺的Serverless构建能力 ， 需要云服务商的众多云服务能力作为支撑 。
Lambda的诞生 ， 可以说是云计算技术的一次跃进式发展 。 正如上文所说 ， 让开发者从对虚拟机、服务器机群容量、集群扩展这些细碎的关注点中抽离出来 ， Lambda帮助其真正实现了按需执行、按需计费、按需自动弹性扩展和高可用能力 。
值得一提的是 ， 一些人更喜欢用缩写FaaS(FunctionasaService ， 函数即服务)来描述Lambda这类技术 ， 对于无服务器技术来说 ， FaaS只是无服务器技术和架构中必须提供的众多能力中的一种 。 但Lambda是FaaS的典型代表 ， 它允许用户仅仅上传代码而无需提供和管理服务器 ， 由它负责代码的执行、高可用扩展 ， 支持从别的AWS服务或其他Web应用直接调用等 。
Lambda能和大量的AWS服务进行整合 。 这里 ， 我们将AWSLambda放在若干个实际应用场景中 ， 来向开发者们解释 ， 基于它 ， 能构建哪些内容 ， 并如何和AWS的其他服务进行联动应用 ， 加速开发 。
数据处理与操作
Lambda和AWS服务非常适用于构建用于处理数据的事件驱动管道 。 开发者可以使用AWSLambda执行代码以响应数据更改、系统状态变化或用户操作等触发器 ， AWS中的S3、AmazonDynamoDB、Kinesis、SNS和CloudWatch等服务 ， 都可以作为Lambda的直接触发“机关” 。
在数据处理管道中 ， 许多用户会遇到数据上传后需要得到立即处理的场景 ， 例如需要将视频从一种格式转换成另一种格式 ， 或者即时调整图像大小以匹配不同设备 。 Lambda则可以实现实时创建缩略图、转换视频代码、聚合和筛选数据等 ， 并且可以由S3或Kinesis触发 。
开发运维配置繁杂，是时候给应用架构做减法了
文章图片

一个模拟数据处理流中 ， Lambda在各环节中的作用示意实时数据流处理
很多AWS用户会使用Lambda和Kinesis处理实时流数据 ， 从而跟踪应用程序活动、处理事务处理顺序等 。 其中 ， Kinesis服务可以对数据（如日志、系统事件、用户点击等）的摄入进行处理 ， Lambda函数则可以对数据流中的新记录做出反应 ， 并能快速处理、保存或丢弃数据 。
Lambda和Kienesis的组合很适合会产生大量需要被分析、汇总并存储数据的应用程序 。 在应用程序产生的大量数据中 ， Lambda可以随负载自动扩展和缩减 ， 月度处理数据点可达百亿级 。
后端
Lambda还被用于构建无服务器后端 ， 以处理Web、移动、物联网（IoT）和第三方API请求 。 在很多客户场景中 ， 可能会通过无服务器架构将前端直接连接到数据库 ， 允许前端与服务进行安全通信 ， 这里面只要通过APIGateway ， 即可调用Lambda函数 ， Lambda函数可以执行自定义任务并与其他服务通信 。
2.Fargate与Firecracker的诞生——Lambda在“进化”Lambda所具备的丰富特性和应用场景的背景 ， 让其成为一度流行于FaaS届的、可以称得上完美的方案 。 实际上 ， Lambda当然也存在一些缺点与问题 。 例如迁移难度大、自动扩展性差、应用语言种类较少、计算规模受限、冷启动（函数未被运行一段时间后需要重新启动容器运行 ， 而造成的函数调用被延迟）、不断膨胀的代码库维护等 。
直至2017年年底的AWSre:Invent大会上 ， AWS宣布针对容器的无服务器计算引擎推出AWSFargate ， 云计算技术尤其是Serverless架构和应用的演进 ， 才算真正迎来了一次新的机遇点 。
Fargate不仅可以抽象出运行容器的服务器 ， 还可以提供服务器编排的抽象 ， 作为容器的免编排计算 。
这也意味着 ， 当K8s等容器编排工具的使用度越来越高 ， 乃至成为开发中的一项“基础设施”时 ， 开发者们可以将创建和管理容器的事情交给云服务商（Fargate）来处理 ， 就好像今天的服务器虚拟化一般 ， 容器也越来越“隐形” 。
此外 ， 相比于Lambda在自动伸缩、灵活定制资源等特征 ， Fargate还可以通过与其他AWS服务（包括AmazonCloudWatchContainerInsights）的内置集成获得开箱即用的可观测性 。 Fargate可以让开发者通过具有开放式界面的大量第三方工具来收集指标和日志 ， 从而监控应用程序 。
随后2018年的AWSre:Invent大会上 ， AWS又开源了Firecracker——AWS容器安全沙箱的基础组件 。 它是AWS针对无服务器计算设计的虚拟化技术（利用KVM的新虚拟化技术 ， 专门用于创建和管理多租户容器以及基于函数的服务） 。 目前 ， Firecracker已为Lambda和Fargate在内的多个高容量AWS服务提供支持 。 Firecracker诞生的内因 ， 也是Lambda演进的结果 。
从Lambda到Fargate ， 再到Firecracker ， 显示了AWS在Serverless架构等"基础服务"方面的革新能力 。 对于用户而言 ， 这些服务的提供 ， 正在让开发者逐步对其带来的安全、高性能、低开销等特性感知更加明显 。
3更多服务及工具 ， 帮助开发者更高效地上手Serverless当然 ， 除了Lambda、Fargate这类计算类服务外 ， AWS可提供与之相关各个维度的一系列完全托管的服务 。 开发者可以使用这些托管服务构建和运行无服务器应用程序 ， 从而解决一些特定问题 。 这里 ， 我们列出了一份服务清单：
开发运维配置繁杂，是时候给应用架构做减法了
文章图片

以上分类及工具清单来源于AWS官网（https://aws.amazon.com/cn/serverless/）有了AWS上述服务的支持 ， 开发者无需为后端组件（如计算、数据库、存储、流处理、消息排队等）预置、维护和管理服务器 。 同时 ， 应用程序的容错能力和可用性也可以变得更强 。
此外 ， AWS及合作伙伴生态系统也在开发者工具上提供了多样化使用组合 ， 包括框架、软件开发工具包、IDE插件和监控解决方案等 。
例如框架层面 ， AWS兼容了AWSSAM（用简单方式定义Lambda函数、API、数据库以及事件源映射)、Apex、Chalice等近十款AWS自研、开源或第三方的框架供开发者使用 。 持续集成和部署层面 ， AWSCodePipeline、AWSServerlessApplicationModel、AWSCodeBuild等一系列工具可以帮助开发者自动化构建、测试和部署无服务器应用程序 。 监控及日志记录与诊断层面 ， 也有AmazonCloudWatch和AWSX-Ray等辅助进行函数性能监控或故障排除 。
归纳来看 ， 无论是扩充提供不同的服务还是丰富的开发者工具 ， AWS都是尽可能地帮助开发者在应用Serverless架构的过程中 ， 降低其遇到不同场景下处理复杂问题的难度 ， 从而让为“高效”而生的Serverless技术能更高效的让开发者上手 ， 更高效的解决问题 ， 从而带来更高效地用户体验 。
最后要提的是 ， Serverless是利用云的要素帮助用户实现价值交付的颠覆式创新 。
因为用户价值交付涉及方法论、开发者工具、应用交付体系、商业模式设计等多个维度 ， 所以Serverless是顶层设计的产物 。 它并不是任何企业在任何场景下都必须要“跟风”应用的时髦技术 ， 毕竟它从真正诞生到至今应用 ， 还只有短短6年而已 。 开发者们一定要选最合适 ， 而非最流行的架构方式 。
【开发运维配置繁杂，是时候给应用架构做减法了】而一旦当你下定决心全面应用Serverless ， 也一定要在这项新兴技术得到普及之前 ， 学会借助实用的服务或工具来应对复杂问题 ， 进而帮助你更快地创建高效、高性能的新架构及软件系统 ， 让你的“酷想法”更快成真 。


    推荐阅读


    上一篇：心理学测试：和男神约会，你绑哪个发圈？测你会不会和暗恋的人在一起？

    下一篇：温网停赛，想跟费德勒来场单打？AI可以帮你安排一切