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

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

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

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

Newman講到，服務網格（service meshes），例如Istio或者Linkerd，也許能夠幫助解決這些問題。它們可以作為持久化的狀態代理，而這些狀態能夠協調微服務函數間的負載。

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

Newman也提到了許多人在選擇一家FaaS（Function-as-a-Service）供應商時所關心的問題，而這些問題也涵蓋在最新的InfoQ eMag中。將討論內容從如何鎖定一家供應商，轉變為理解（以及接受）每個FaaS實現在提高運行速度（負載越少速度越快）和遷移成本（跨FaaS供應商的工具集越相似，成本就越少）之間的權衡，是解決這個問題的關鍵。

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