如果設計不當，一切都會有怪癖

無服務器是業(yè)界最新的流行語之一-但是，就像技術上的任何事物一樣，如果設置不正確，您的開發(fā)投資可能像紙牌屋一樣崩潰。

現(xiàn)在，所有主要的云播放器都提供某種無服務器架構支持-帶有Lambda的AWS，帶有云功能的Google和帶有Azure功能的Microsoft。 還設計和創(chuàng)建了開源的免費Serverless框架，以幫助開發(fā)人員自動化其流程并創(chuàng)建更好的無服務器代碼。

無服務器背后的理由是，它是事件驅(qū)動的，具有自動擴展的能力，而無需基礎架構的設置或干預。 但是，人們經(jīng)常問的一個問題是：健壯的無服務器架構是什么樣的？

整合，隔離和事件驅(qū)動

很容易陷入為任何可能的事情編寫函數(shù)的陷阱。 對于無服務器，很容易啟動執(zhí)行工作的功能。 可以通過自動計時作業(yè)激活該作業(yè)，可以通過網(wǎng)關，數(shù)據(jù)更改和代碼管道活動來觸發(fā)該作業(yè)。

盡管這對于孤立的案例來說聽起來很棒，但是在無服務器環(huán)境中的大型應用程序要求架構師將整個預期事件和設計功能視為一個模塊化網(wǎng)絡。

在某種程度上，以無服務器方式構建應用程序是一種解構的軟件開發(fā)方法。 它可以部分啟動而無需依賴，并提供快速的問題解決方案。

健壯的無服務器架構強制執(zhí)行一定的代碼壓縮和模塊化，以最大程度地減少相互依賴性。 它的無狀態(tài)性使功能彼此斷開，并且持久性數(shù)據(jù)源成為真實性的唯一空間。

如果發(fā)生故障，鏈接功能會導致串行多米諾骨牌效應。 對功能之間的關系采用并行方法可減輕這種風險。

看下面的圖，例如：

Serial serverless approach

上面的流程是默認的，我們中的一些人在創(chuàng)建無服務器代碼時可能會陷入其中。 這是因為在傳統(tǒng)的依賴注入模型中，一個函數(shù)觸發(fā)另一個函數(shù)很容易想到。 如果要求合理，我們可以遞歸進行。 但是，當將其應用于無服務器應用程序時，流程中斷最終會導致沒有應急計劃的結果中斷。

這是因為串行方法不能滿足每個功能真正獨立的需要。 上述方法的觸發(fā)器是調(diào)用另一個的無服務器功能，這意味著它有可能沿管道傳遞數(shù)據(jù)而無需驗證或進行適當?shù)臓顟B(tài)管理。

看下圖。 它具有相同的三個無服務器功能，但它們通過有狀態(tài)觸發(fā)器相互連接。

Parallel Serverless approach

這種方法可能看起來更復雜，但是如果您查看潛在的斷點在哪里，它們是基于觸發(fā)器而不是函數(shù)。

實施遞歸時，觸發(fā)器基于持久性內(nèi)容，而不是可能會丟失輸出的臨時空間。

該體系結構還允許運行多個代碼。 無服務器及其相關的無表數(shù)據(jù)存儲很便宜。 在某種程度上，這是因為它的初始設計是為了大量使用。

雖然第一個圖一次運行一個功能以觸發(fā)另一個功能，因此似乎使用了較少的計算能力，但第二個圖允許兩個功能以隔離的方式運行，但仍通過數(shù)據(jù)觸發(fā)器保持連接。

對于健壯的無服務器架構，代碼的結構取決于開發(fā)人員為更大的視圖創(chuàng)建隔離的解決方案的能力。 該代碼本質(zhì)上通常是功能性的，因為可重用性取決于其處理數(shù)據(jù)的能力而無需基于類的藍圖。

針對大型軟件的健壯的無服務器架構會考慮潛在的中斷和可能丟失數(shù)據(jù)的位置。 通過圍繞永久性集中觸發(fā)器，它解決了此問題，并降低了由于無服務器的短暫性而導致的風險。

功能并行是可用于健壯的無服務器體系結構的體系結構方法之一。 關于觸發(fā)器，實現(xiàn)永久性是數(shù)據(jù)保護和驗證的一種好習慣。 這也是處理無服務器預期的無狀態(tài)性的一種方法。