【译】Serverless架构 - 6

原文：

https://martinfowler.com/arti...

上次说到什么不是Serverless，这次继续。

与PaaS比较

上面的Serverless FaaS函数功能跟12-Factor应用很像，他们是否只是另外一种形式的‘Platform as a Service’(PaaS) ，跟Heroku（http://www.heroku.com/） 一样呢？我们引用一下Adrian Cockcroft的回答。

换句话说大多数PaaS应用没有设计成响应每个请求时让整个应用上上下下的，这正是FaaS平台正在做的事。

OK，但那又怎么样，如果我已经是一个不错的12-Factor应用（http://12factor.net/processes）
的开发者了，这跟我现在正在写的代码没什么区别。 确实是这样，但这有一个很大的不同就是你如何运维你的应用。自从我们都是DevOps工程师，我们现在都是开发和运维一起思考了对吧？

FaaS和PaaS核心的运维上的区别就是伸缩。在大多数PaaS上你仍然需要思考如何伸缩，例如在Heroku上你需要想要运行多少Dynos。在FaaS应用里这个完全是透明的。即使你将你的PaaS应用设置成自动伸缩了，你仍然不能在每个独立的请求这个级别做伸缩（除非你有一个经过量身定制的流量控制），而且FaaS在涉及到成本是更有效率。

有这个优点，你还会使用PaaS吗？有很多原因可能会影响这个问题，比如工具，API网关的成熟度。未来在PaaS中实现的12-Factor应用可能会使用一个内置只读缓存来优化，这在FaaS函数功能中是没有的。

与容器比

一个使用Serverless Faas的原因是它可以避免在操作系统级别或更低的级别管理处理器计算资源。 平台即服务（像Heroku）是另外一种，我在上面解释过Serverless FaaS与PaaS的不同。另外一种流行的进程抽象是容器，Docker（https://www.docker.com/） 是这种技术很明显的例子。我们可以看到用容器作为主机托管的流行趋势，例如Mesos（http://mesos.apache.org/） 和Kubernetes（http://kubernetes.io/） ，将操作系统级部署抽象成独立应用。更进一步还有像Amazon ECS（https://aws.amazon.com/ecs/） 和Google Container Engine（https://cloud.google.com/cont...） 这样的云托管容器平台，像Serverless FaaS，避免让团队管理他们自己的服务器系统。

对PaaS主要的争议还是在容器上 - Serverless FaaS的伸缩是自动管理，透明，细粒度的。容器平台不支持这种方案。

还有就是在过去几年里大规模流行的容器技术看起来还不成熟。这并不是说Serverless FaaS已经成熟了，但具体选哪个还是在议事日程上。

我承认，随着时间过去这些争议可能慢慢消失。尽管无须管理自动伸缩的容器平台跟Serverless FaaS还不在一个级别上，我们可以看到Kubernetes的‘水平自动伸缩Pod’正在向这方面努力。可以想象一些智能化流量分析模式会被引入到特性中，就像更多的负载度量模式。未来Kubernetes的快速革命可能会在不远的将来带来更简单，稳定的平台。

如果我们看到Serverless FaaS与托管容器在管理和自动伸缩上的差距缩小，可能最终选择会变成在风格和应用类型上。例如FaaS可能在每个应用组件对应若干事件类型时适合作为事件驱动风格的选择，而容器适合在许多不同入口点时作为同步请求驱动的组件。我期望在五年内多数应用和team会同时使用两种架构方式，看到这种变化是很有趣的。

---

本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。
微信扫一扫关注公众号。