原文：
我不会讲第二个领域因为这个比较新， 跟我们通常想的技术架构很不同， 并且已经被Serverless大肆宣传。
这些概念很相关，而且会重叠。 一个好例子是Auth0 - 它开始是BaaS ‘验证即服务’， 但带着Auth0的Webtask(https://webtask.io/)就变成了FaaS领域。
在很多开发‘BaaS’类型应用的例子里， 特别是当开发一个基于web面向移动的‘富’应用， 你仍然需要很多服务端功能。 FaaS函数功能很适合这个场景， 特别是当他们被整合到一些你已经在使用的BaaS服务中。 这种功能例子包括数据校验（保护客户不被冒名顶替）和计算集中型的处理（例如图片或视频操作）
一组例子
UI驱动型应用
让我们想一下具有服务端逻辑的传统3层面向客户端的系统。一个好例子是典型的电商应用（我敢说是一个在线宠物商店吗？）
传统上这个架构会是这个样子的， 我们可以说它是服务端用Java实现的， 并且客户端上使用HTML/Javascript组件：
在这种架构中客户端可以是非智能的，而大部分系统逻辑 - 验证，页面导航，搜索，事物 - 都在服务器上实现。
而一个Serverless架构上可能看起来是这样的：
这是一个极度简化的视图，尽管这样还是有很多巨大的变化能看到。请记住这不是一个推荐的架构，我只是用这个作为解释Serverless概念的工具！
我们删掉了原应用中的验证逻辑并且用第三方的BaaS服务来替换。
另一个使用BaaS的例子，我们需要允许客户端直接访问一系列我们数据库的子集（如AWS Dynamo）。跟从服务器上访问数据库比，对于客户端访问数据库我们有一个完全不同的安全模型。
以上两个点很明显的引出了第三点 - 一些曾经在宠物商店服务器端的逻辑现在在客户端了，例如对用户session的追踪，理解应用的UX结构（例如页面导航），读取数据库并将其放入有用的视图。 客户端事实上变成了一个单页应用https://en.wikipedia.org/wiki...。
一些UX相关的功能我们打算放在服务器，例如如果他是计算敏感型的或需要访问大量数据的。一个例子就是‘搜索’。对于搜索特性我们可以实现一个FaaS功能来从API网关（后面解释）响应http请求，来取代一个一直在运行的服务。 我们可以同时在客户端和服务器端拥有功能逻辑，从一些数据库读取产品数据。
如果之前服务使用Java实现，而AWS Lambda（在这个例子里我们的FaaS提供商）支持用Java实现的函数功能，我们可以把原来宠物商店服务器短的搜索代码无缝迁移到宠物商店的搜索函数中而不用全部重写代码。
最后我们会用另一个FaaS函数功能替换我们的‘购买’功能，并且选择将其放在服务器端以保证安全，而不是在客户端重新实现。这个也会被设在API网关之后。
本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。
微信扫一扫关注公众号。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。