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

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

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

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

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

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

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

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

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

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

看下面的圖，例如：

Serial serverless approach

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

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

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

Parallel Serverless approach

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

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

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

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

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

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

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