【译】Serverless架构 - 3
原文：
消息驱动型应用
后台数据处理服务是一个不同的例子。 你要写一个需要快速响应UI请求的以用户为中心的应用， 但是你又想捕捉发生的各种不同类型的活动。让我们想一下在线广告系统 - 当一个用户点击时你想要非常快速的把它们转向到他们的目标广告，但同时你也需要拿到点击发生的数据以便于给广告商充值。（这个例子可不是假设的 - 我在Intent Media的前团队最近正在做这样的设计。）
传统上，架构可能看起来是这样的。‘广告服务器’同步地响应用户 - 在这个例子中我们可不关心交互 - 而他也会用‘点击处理器’向频道发送一条异步处理消息以便于更新数据库，例如去扣减广告商的预算。
在Serverless的世界看起来是这样的：
这里的架构跟我们之前那个例子有一点不同。我们将一个长存活周期的消费者应用替换成了厂家给我们提供的可以跑在事件驱动上下文中的FaaS函数。记住厂家同时提供MessageBroker和FaaS环境 - 这两个系统紧密捆绑在一起。
FaaS环境也可以用启动多个函数代码副本的方式来处理并行的点击 - 取决于我们如何写原始的处理逻辑，这是一个我们需要考虑新概念。
拆解‘函数即服务’
我们已经说了很多FaaS的主意，但现在是时候深入讲下它到底是什么意思了。我们可以先看一下Amazon Lambda产品的公开介绍 https://aws.amazon.com/lambda/。我加了一些注释，会在下面讲解。
AWS lambda可以让你在不需要管服务器的情况下跑代码。(1)… 用Lambda，你可以运行各种类型的应用或后台服务(2) - 全都是0管理配置。只需要上传你的代码并让Lambda来管让你的代码高可靠的运行(3)并伸缩(4)的事。你可以设置让你的代码被其他AWS服务(5)自动触发或者直接从任何web或移动应用调用。
1.基本上FaaS就是运行后端代码并不需要管理你自己服务器或你自己服务端应用的系统。第二个部分 - 服务端应用 - 是一个与像容器和PaaS（平台即服务）这样现代架构模式的关键不同。
如果我们回到之前点击处理的例子，FaaS做的就是替换点击处理服务器（可能是个物理服务器，），换成一些不需要实际服务器或者一直运行应用的东西。
2.FaaS可以不需要对某种框架或类库做编码。如果用语言和环境来实现FaaS函数功能的话一般就是常规的应用。例如AWS Lambda函数可以在Javascript，Python和任何JVM语言（Java, Clojure, Scala等）中被实现成‘一级类’。总之你的Lambda函数可以执行任何被任何绑定了其部署描述的进程，这样你可以用任何语言最终编译成一个Unix进程（参考后面的Apex）FaaS函数确实有明显的架构限制，特别是当它遇到状态和执行周期，这个我们后面会说。
让我们再想一下我们的点击处理例子 - 唯一需要更改并移动到FaaS的是‘主方法/启动’代码，这处需要删除，并且这个会变成顶层消息处理器（’消息监听借口’实现），但这只是对方法签名的一点改变。其他所有的代码（例如对数据库写数据的）在FaaS世界没有什么不同。
3.既然我们没有服务器程序要跑，部署跟传统系统非常不同 - 我们上传代码到FaaS提供商并且让它做其他所有事情。现在这基本上就是让你上传一个新的代码定义（例如zip或JAR文件），并且调用一个合适的API来初始化更新。
4.水平扩展是完全自动的，由供应商管理弹性。如果你的系统需要并行处理100个请求，供应商会处理而你不需要任何额外配置。FaaS供应商用‘计算容器’短暂执行你的函数方法并且根据运行时需求来销毁。
让我们回到点击处理。比如我们今天运气很好，用户像比平常点击了10倍的广告量。我们的点击处理应用能处理吗？比如我们是否对能一次能处理很多消息的场景进行编码？甚至我们只用运行一个应用实例够不够？我们能否运行自动扩展运行多个处理程序或者我们需要手动更改配置吗？在FaaS上你需要在写行数方法时先考虑并行，但在这之后FaaS供应商会自动处理所有扩展伸缩需求。
5.FaaS的函数方法是由厂家定义的事件类型来触发的。在亚马逊AWS上这包括了S3（文件）更新，时间（计划任务）和被发送到消息总线的消息（如Kinesis）。你的函数需要为你绑定的消息源提供特定的参数。在点击处理器中我们假设我们使用了支持FaaS的消息分发者。如果我们需要换一个，那么需要连消息生产者也要改。
6.大多数厂商允许函数方法可以被进入的http请求触发并作为响应，这很像一种API网关。（如AWS API Gateway, Webtask)。在我们宠物商店里作为‘搜索’和‘下单’的函数功能。
文章来自微信平台「麦芽面包」
微信公众号「darkjune_think」转载请注明。
微信扫一扫关注公众号。
