【译】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」
转载请注明。
微信扫一扫关注公众号。