【譯】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」
轉載請註明。
微信掃一掃關注公衆號。