Serverless架構或Serverless計算是軟體架構風格向分散式系統發展結果，而當前建立一個系統的標準是面向服務架構(SOA)或者是SOA之微服務架構。

在微服務架構中，應用/服務被開發出來然後部署，每個服務組相關一些函式，在Serverless架構中，函式是被開發並部署到獨立的平臺，這個平臺會照顧執行這些函式響應一些事件，舉例：當有HTTP請求訪問時，也許有一個函式計算計算出一個響應結果，或當一些東西寫入到資料庫式，會有一個專門函式來執行。

乍一看，這就讓人想起了傳統的儲存過程，與儲存過程相反，Serverless架構中的函式不僅僅限制於資料庫操作事件，每個函式能夠被不同程式語言實現，更遠，也沒有保證同樣函式總是在同一個伺服器上執行。

下面看看Serverless的目標和優缺點權衡。

低運營成本
微服務架構中的服務需要一直執行，實際上，在高負載情況下每個服務都不止一個例項，這樣才能完成高可用性，在Serverless架構中則是沒有事件發生時不會有服務執行，主機平臺會只有在需要時才會執行相應的函式，按照雲端計算pay-as-you-go原則，如果沒有東西執行，你就不必付款。

在Serverless架構中，擴充套件和自動擴充套件是沒有問題的，當負載增加，會讓受影響的函式以並行方式執行得更頻繁。

彈性配置也在Serverless架構中很有效率，對於傳統的雲端計算環境你會說：
“我願意買3G記憶體，然後以後暫時就不需要再擴充套件了”。
而現在你會說：
“我會為X型別的30000個事件付費，為Y型別的5000個事件付費，然後以後暫時就不需要再擴充套件了”。

很明顯，Serverless計算針對資源的使用是有效率的，特別具有運營的可操作性。

風險1：廠商鎖定
平臺會提供Serverless架構給大玩家，比如AWS Lambda，執行它需要使用AWS指定的服務，比如API閘道器，DynamoDB，S3等等，一旦你在這些服務上開發一個複雜系統，你會粘牢AWS，以後只好任由他們漲價定價了。

複雜性和低聚合
多少年來，軟體工程師為高聚合和低複雜性奮鬥，領域驅動設計和微服務是完美的配合，因為他們總結過去多少年的軟體工程經驗。

如果開發者忽視這些經驗教訓是會有風險的，特別是在構建Serverless架構時，它們會遭遇不可維護的函式地獄，在這個情況下，低運營成本優勢也許會被更高維護成本超過。

轉載：http://www.jdon.com/48121