Sam Newman是一位獨立咨詢顧問，也是《Building Microservices》這本書的作者。他在倫敦舉行的Velocity大會上發(fā)表演講，討論了關于在一些同時依賴無服務器架構和傳統(tǒng)基礎設施的混合系統(tǒng)中所面臨的挑戰(zhàn)。尤其是，Newman重點討論了無服務器架構如何改變了我們關于系統(tǒng)彈性的概念，以及兩個體系同時存在于一個高負荷系統(tǒng)內(nèi)會發(fā)生怎樣的沖突。

系統(tǒng)彈性在傳統(tǒng)服務系統(tǒng)中依賴于狀態(tài)來控制（例如，在任何時間點用數(shù)據(jù)庫連接池，來及時調(diào)節(jié)和控制訪問數(shù)據(jù)庫的請求數(shù)量）。在這種系統(tǒng)中，系統(tǒng)穩(wěn)定性通過控制輸入負載并把這些負載均衡到多個系統(tǒng)實例中來維持。但是，在短暫的函數(shù)（lambdas）中沒有地方來存儲這些控制狀態(tài)，因此在函數(shù)隨著負載自動擴展與后端數(shù)據(jù)庫擴展之間需要一個平衡機制。

自動擴展的云數(shù)據(jù)庫，例如亞馬遜的DynamoDB或者谷歌的Bigtable，很適合無服務器架構。但是Newman指出，大多數(shù)系統(tǒng)依賴傳統(tǒng)數(shù)據(jù)庫，因此簡單地在一個遺留的系統(tǒng)中嫁接無服務器函數(shù)可能會導致嚴重的后果。Newman強調(diào)，即便是作為無服務器架構典范之一的Bustle也面臨過許多前所未有的挑戰(zhàn)。盡管他們特意給任意一個Redis節(jié)點設置了一個1000 lambda連接數(shù)的限制（可以處理10倍那個數(shù)量的連接），但是他們?nèi)匀话l(fā)現(xiàn)一些失效的節(jié)點，因為據(jù)傳聞說，lambda函數(shù)似乎在連接停止后也會保持連接存活長達3分鐘。Bustle的工程師不得不深入研究Redis內(nèi)部工作機制來修復這個問題（強制這些僵尸連接更快地超時）。Newman說，這也突出了無服務器架構系統(tǒng)與非無服務器架構系統(tǒng)在處理負載和系統(tǒng)彈性的方式上的不協(xié)調(diào)。

Newman提到的另一個挑戰(zhàn)是，通常被用在微服務中來處理失敗的下游服務，能夠有效降低負載從而讓整個系統(tǒng)更具彈性的斷路器（circuit breakers），是依賴于維護跨多個請求的狀態(tài)來實現(xiàn)的。例如，一旦下游服務恢復穩(wěn)定，斷路器就能夠自我關閉。

Newman講到，服務網(wǎng)格（service meshes），例如Istio或者Linkerd，也許能夠幫助解決這些問題。它們可以作為持久化的狀態(tài)代理，而這些狀態(tài)能夠協(xié)調(diào)微服務函數(shù)間的負載。

最后，從安全角度來看，函數(shù)是運行在容器中的，因此很容易受到攻擊，因為一個容器可以侵入到另一個運行在同一臺主機上的容器。但是，如果函數(shù)運行所在的容器存活的時間很短，這種攻擊就會變得很困難，因為不能在函數(shù)結束后進行攻擊。諸如Guy Podjarny等安全專家警告說，無論如何，無服務器架構都將安全隱患轉移到了應用層級別，并且如果沒有正確的安全措施，一長串的函數(shù)鏈調(diào)用很可能會受到攻擊。

Newman也提到了許多人在選擇一家FaaS（Function-as-a-Service）供應商時所關心的問題，而這些問題也涵蓋在最新的InfoQ eMag中。將討論內(nèi)容從如何鎖定一家供應商，轉變?yōu)槔斫猓ㄒ约敖邮埽┟總€FaaS實現(xiàn)在提高運行速度（負載越少速度越快）和遷移成本（跨FaaS供應商的工具集越相似，成本就越少）之間的權衡，是解決這個問題的關鍵。

查看英文原文：Serverless Challenges in Hybrid Environments