設計有狀態的云原生網絡應用程序時最容易被忽視的 9 個問題
原文出自：CNCF （云原生基金會）Blog
原文作者：W. Watson
在設計有狀態的云原生應用程序，尤其是有狀態的云原生網絡應用程序時，必須確定哪種數據模型與系統的功能需求相匹配。當涉及到數據時，電信和網絡空間中的詞匯經常會混淆（例如，有像 tcp/ip 這樣的有狀態協議和像保存在數據庫中的有狀態數據）。當這些概念與云原生的非功能性需求（例如彈性和可用性）相結合時，混淆會更加嚴重。電信領域非常難以駕馭，因為需求通常在 RFP 中而不是在迭代敏捷開發周期中列出。以下九個問題在考慮云原生狀態時經常被忽略，所以我們特意通過本文提出來。
href="/"
正確性
在談論有狀態的應用程序時，正確性開始發揮作用。傳統上，關系數據庫管理系統 (RDBMS) 處理數據的正確性問題，但由于電信網絡組件的低延遲 (1 ms) 要求，一些 RDBMS 可能無法勝任該任務。
1) 您的系統必須得有多安全？
云原生系統和傳統應用程序之間的差異可以描述為安全性和活性之間的差異。安全性與正確性有關，因為它阻止了不希望發生的事情。換句話說，它對系統施加了約束。活躍度是系統返回到所需狀態的能力。云原生系統選擇頻譜的活性方面，也稱為反脆弱性，而不是安全性。
2）您需要強一致性嗎？
有一些問題，通常是在金融領域，需要強一致性。一個具體的例子，雙重支出的問題，或者確保資源沒有被使用兩次。
3）您能容忍寫入偏差數據嗎？
當不需要強一致性時，放松對正確性的約束通常可以提高其他屬性，例如性能。寫入偏差是指數據基于過時前提的決定寫入數據。這有時是可以容忍的，因為數據可以在寫入后修復。
4）您如何解決偏差數據？
允許寫入偏差的數據應基于寫入偏差的解決方案是否對您的模塊足夠好。例如，對于有時會亂序接收數據包的電話呼叫，丟棄數據包的解決方案（即首先寫入獲勝）通常是可以容忍的。對于同時添加了許多商品的購物車，但收到的寫入亂序或延遲，將商品原樣合并到購物車中的解決方案（例如，使用無沖突復制數據類型的解決方案）收到的也往往是可以忍受的。
表現
電信領域的網絡應用程序必須具備性能。一個常見的基本要求是網絡應用程序必須是“line speed”，這意味著任何軟件都不應干擾網卡的速度，此時網卡的速度可能為 400G。這對系統的瓶頸提出了很高的要求。
5) 系統的延遲敏感部分是否可以按任何順序應用更新，例如增量？
可以按任何順序應用的延遲敏感數據通常可以通過合并解決方案來解決，例如無沖突復制數據類型 (CRDT)。資源的遞增和遞減就是這樣的例子。
6）您的數據寫入量應該有多大？
使用寫入友好的數據模型（例如僅附加數據存儲）可帶來大量寫入數據的延遲優勢。如果您的數據模型支持，重讀數據可以從使用列數據庫中獲得延遲優勢。
7) 您的延遲應該要多少？
對于網絡應用程序（尤其是嚴重依賴的網絡組件），通常需要控制 1 毫秒延遲或以微秒為單位測量的延遲。這在傳統 DBMS 系統中很少需要。因此，在設計這些系統時，您確實需要詢問系統是否需要 1ms 的延遲響應時間。99%的延遲要求是什么？您有什么硬能力來保障維持這個延遲要求？
8) 用戶是分布式狀態嗎？
地理分布式狀態是挑戰也是機遇。挑戰來自尋找和實施足夠智能的地理復制和分區。機會來自于數據接近應用程序所帶來的延遲減少。
9) 您的系統必須有多安全？
如果受感染的節點沒有容錯能力，它可能會對您的共識算法造成嚴重破壞。如果受感染的節點請求成為Admin并繼續采取破壞性行動，它將使您的系統崩潰。
結論
如果您正在設計或準備在市場上購買有狀態的云原生系統，尤其是有狀態的云原生網絡應用程序，您最好問一問這些問題。最終，云原生系統的設計將根據您的答案，發生很大的偏差。
-----------------
如您的企業正打算做云原生轉型，希望下面的資料能對您有所幫助，點擊圖片，免費獲取>>
讓企業都能高效創新
企業云原生數字化創新平臺CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發者專屬一站式在線服務Methodot
