我对无服务器的一些想法

无服务器 AWS Azure 事件驱动的架构

摘要：

本文作者探讨了自己参加2017年4月奥斯丁Serverlessconf大会过程中的感想，以及无服务器计算这项技术的发展趋势和目前所面临的问题。

正文：

我想通过本文简单谈谈自己对奥斯丁Serverlessconf大会上所涉及主要议题的看法。这次活动让我受益匪浅，还见到了不少行业牛人，万分感谢A Cloud Guru举办的这次活动。此外我还领到了很多新T恤，吃了美味的甜甜圈，拜访了住在奥斯丁的亲友们。

总的感想如下。

什么是“无服务器”？

Serverlessconf的所有与会者依然还在忙着给“无服务器”下定义，并达成了一些共识：

1. 无服务器不仅仅是函数即服务 (FaaS, Functions As A Service)，还包含诸如数据库、身份验证、API网关、编排，甚至具体到某一领域的其他服务，例如视频转码即服务或认知服务。总的来说，所有与这些服务有关的基础架构都不需要我们自行管理。
2. 无服务器意味着（近似于）100%的利用率。如果和PaaS相比的话，PaaS应用程序要么以特定的规模运行，要么以非常慢的速度进行伸缩，但会因为伸缩操作本身造成一定的开销（例如有未使用的实例处于闲置状态，等待接受请求）。作为对比，如果无服务器服务暂不使用，此时不会产生任何成本，但如果有必要可以（几乎）瞬时伸缩至数百万用户，服务的成本直接取决于使用量。

事件驱动，而非数据驱动

会上的另一个重要议题是：无服务器应用促成了一种围绕事件本身，而非围绕数据来设计的架构。将应用程序订阅到某个事件队列，这是管理服务通信的一种好方法，借此我们可以轻松地为现有队列添加新服务，或修改/添加功能，而不需要将数据流直接绑定给应用，进而产生强耦合。

Rob Gruhl介绍了Nordstrom公司正在从事的一个有趣项目：他们正在通过一个集中且统一的事件日志管理零售系统内部的数据流动。应用程序可以通过流生成和使用事件，任何需要对当前状态获得高性能视图的应用程序均可订阅至事件流，借此构建自己的状态数据库（一种数据库视图）。随后即可根据需求为请求提供服务。同时这些应用还可生成供其它服务使用的事件。这样的方式彻底避免了为实现某些状态的中心化存储而使用核心数据库系统的做法，可在改善伸缩性的同时实现微服务之间的解耦。

他们提供了一个名为Hello Retail的演示应用，摄影师可以借助该应用为新产品拍照。当新产品加入后，系统会从已知摄影师清单中选择一位摄影师，发送手机短信请求对方拍摄新照片。当摄影师（用短信）回复后，系统会开始处理照片，将其加入图库，随后注册为新产品对应的照片。

Nordstrom所开发Hello Retail应用的架构（来源：https://read.acloud.guru/announcing-the-winners-of-the-inaugural-serverlessconf-architecture-competition-1dce2db6da3 ）

详情可参阅GitHub上的Hello Retail项目页面。

来自Capital One的Srini Uppalapati介绍了Capital One的核心金融系统，他们目前正在将这套系统迁移到云端，并且这一过程中大量使用了无服务器相关技术。他们核心交易系统的迁移主要分为两个阶段：

1. 循序渐进撤销通过大型机系统执行的读取操作：逐渐将大型机系统产生的事件以流的形式发送至云端数据库，并供面向用户的应用和数据科学家使用。
2. 消除消费者应用中的写操作，将核心业务逻辑搬入云端。

目前他们已经完成了第一阶段的任务。在Srini所介绍的架构中，他们使用AWS Lambda对老数据以及来自大型机的实时事件进行批处理，并将数据装入S3以便归档，消费者应用使用了DynamoDB，分析工作使用了Redshift。

这个系统在架构和应用层面有一些极为有趣的特点，直接使用“一手”事件是一种对逻辑和状态进行解耦的强大方法：单向数据流使得一切变得更简单。在应用层面上，以ELM架构和React/Redux为例，通过迁入云端，我们可以将云函数与核心事件流配合使用，打造实用的大规模云应用程序。

企业正在快速接受

上文曾经提到，Nordstrom和Capital One正在通过几个重要项目证明无服务器技术在企业领域的运用前景。最令我吃惊的是，Serverlessconf大会上还提到了很多其他正在这样做的大企业，他们正在快速接受无服务器技术。

我认为，他们能如此快接受这种技术，原因之一在于很多企业已经开始迁往云端，既然云供应商提供了无服务器相关产品，并且这种技术可以进一步降低成本，他们自然会愿意接受。例如Capital One的Srini介绍说，通过使用云端无服务器技术，他们大幅节约了成本。目前交易中心每年运营成本约为9.5万美元（考虑到客户数高达4500万，这样的成本已经相当低了）。

为了满足企业的这类需求，不仅AWS，目前所有云供应商都在无服务器产品方面进行了巨大的投入。其他云供应商（Google、微软，以及IBM）也介绍了自家的FaaS和无服务器编排产品。

无服务器计算造就的现代化敏捷

Mike Roberts通过一场精彩的演讲介绍了应用开发者如何借助无服务器技术变得更加以客户为中心，而无须过度关注技术问题本身。现代化敏捷（塑造更出色的人员，持续不断地提供价值，让安全成为先决条件，更快速地尝试和学习）在无服务器技术的帮助下变得更易于实现，开发者再也不需要重新解决已被其他开发者解决了无数遍的相同问题（如何进行身份验证，如何伸缩等），这样他们就可以更专注地为自己的客户提供价值。借此，生产发布再也不需要耗费数天甚至数周时间，几小时就够了。

考虑到：

“我们的大部分想法其实都很糟糕” — Jeff Patton

我们应当尽可能尝试更多想法。感谢无服务器技术，“试错”成本得以大幅降低！

无服务器技术在这方面已经有很多成功先例，例如Marcia Villalba介绍了Toons.tv是如何迁移至无服务器技术的。他们在面向云环境重新设计架构后，成本大幅降低，而这一切都是由几名不熟悉无服务器技术的工程师组成的小团队，在几个月的时间里顺利完成的。Marcia认为他们的成功主要归功于每周一次的研讨会，大家借此交流讨论新技术的学习心得，并通过测试进行概念验证。

相关工具正在逐渐完善

有一种普遍共识认为，相比云供应商提供的服务，周边工具的发展有些落后了。Florian Motlik详细介绍了AWS CLI工具的不足之处。其他云供应商也面临类似情况，他们往往在无服务器运行时方面投入巨大，但总是会忽视部署、监视和本地测试等过程中必不可少的工具。

基本上，这也意味着用户与云供应商之间的任何交互都必须通过第三方工具进行，例如没人会通过AWS CLI进行无服务器部署，大家更愿意通过第三方技术将云供应商生硬的接口抽象为简单易用的应用程序部署框架（例如Serverless Framework、claudiaJS，以及适合新手的zappa）。

为了解决这种问题，AWS发布了Serverless Application Model (SAM)。SAM是一种CloudFormation之上的抽象层，可大幅简化Serverless Applications的创建工作，但AWS CLI在这方面依然不够成熟（个人观点）。

很多人还认为，无服务器应用的监视和调试方面也缺乏必要的支持，面对基于事件的架构更是如此（“我的函数无法运行但不知道原因！”以及“为什么不能对运行中的无服务器函数进行实时调试？？”）。

我这并不是在抱怨缺乏交互式调试能力，因为交互式调试实际上可能是一种反面模式 (Anti-pattern)，但如果你想要这样做，微软已经支持通过Visual Studio或Visual Studio Code对Azure云函数进行实时调试（虽然演示过程看着有点不靠谱）。如果想避免交互式调试，那就写单元测试吧。

另外，所有云供应商都开始在监视方面发力。Amazon X-Ray就是一种非常实用的监视技术，通过与AWS SDK集成，可提供有关集成点，即实时架构示意图的实时图表(Live graph)和分析能力。如果你在自己的服务调用中使用了AWS SDK，基本上就可以免费使用该技术。

讨论的另一个重点在于，很多团队依然在探寻无服务器应用开发的最佳模式。传统上，我们很容易理解特定应用所涉及的相关领域，因为所有内容都位于同一个服务器实例中。你可以启动一个本地实例，准备好所有依赖项，开发过程中在本地执行各种探索式测试。然而对于无服务器开发，通常我们会被紧密绑定至云供应商（服务越“微型”，绑定的程度越高），为了测试应用能否端到端运行，通常还需要对应用程序进行实际的部署（可能会涉及多个云服务组件），甚至要在开发过程中进行部署。很多因素会要求我们必须能够在本地进行探索式测试，但如何对测试中的应用进行隔离，目前并没有任何行之有效的模式，通常到最后我们往往会面对一系列同时在本地和云端运行，“拼凑”出来的测试应用。这方面目前已经有了一些解决方案，例如Atlassian AWS Local Stack，可以在用户的本地计算机上提供一套功能完备的AWS栈。然而为何要用它，而不是直接部署到开发环境，这个问题依然存在争议。

无服务器的编排

无服务器计算还面临一个大问题：难以通过编排大量Lambda函数进而在云中创建数据管道。事件流是将Lambda函数连接在一起的一种方法，然而通常我们还需要更高级的功能，例如等待条件或并行处理能力。

AWS和Azure都曾演示过自己的无服务器编排技术：AWS Step Functions，以及Azure Logic Apps，这两种技术看起来都很有吸引力。

Azure Logic Apps提供了超过250种适用于其他Azure产品，以及第三方产品的连接器。虽然华丽的用户界面让我觉得它不太靠谱，但该技术以JSON形式的脚本DSL支撑，演示效果很出彩，他们将实时推文连接到了微软的情绪分析服务，借此围绕特定话题实时进行了推文情绪分析……所有操作均在45分钟的演示内完成（当然很多代码是复制粘贴的）。

我还不太确定该如何以足够可靠的方式应用这些工作流编排服务（如何对其进行测试和部署？），不过感觉上它们会成为无服务器技术不可分割的一部分。

我很想亲自见证这些工作流服务如何进一步完善成为功能完备的平台。如果有更好的语言（例如JavaScript或Swift）可以编译为“AWS云计算机语言”，并直接在某种抽象的计算层上运行，又何必使用JSON DSL来写脚本。随后可由AWS管理所有底层服务器及其状态，用户无需考虑任何有关最长运行时间或最大内存数的限制，只需要严格按照用量来付费。

作者：Will James，阅读英文原文：State of Serverless