金融雲原生漫談（五）｜如何打造更適合雲原生的數據存儲方案？
在金融行業數字化轉型的驅動下，國有銀行、股份制銀行和各級商業銀行也紛紛步入容器化的進程。
如果以容器雲上生產為目標，那麼整個容器雲平台的設計、建設和優化對於銀行來說是一個巨大的挑戰。如何更好地利用雲原生技術，幫助銀行實現敏捷、輕量、快速、高效地進行開發、測試、交付和運維一體化，從而重構業務，推動金融科技的發展，是個長期課題。
本期雲原生漫談，將和您一起探尋如何打造更適合雲原生的數據存儲方案。
近年來，金融服務形態經歷了巨大的變化。線上業務的興起，帶來了海量的數據接入和業務的不確定性。
數據系統管理彈性需求提升、數據系統訪問查詢需求提升，對數據存儲、處理、挖掘的性能、穩定性、可靠性都提出了更高的要求。除此之外，金融企業IT還要建立數據「敏態引擎」，能夠通過統一的編排系統配合業務上線，可以實現快速擴容。同時，存儲系統自身的自動化運維能力，也成為IT建設者關注的焦點……
那麼，雲原生時代，我們需要什麼樣的數據存儲方案？針對底層的IT基礎架構，和數據存儲環境挑戰，金融IT建設者們真實發問：
- 容器雲數據持久化存儲方案怎麼選？
- 容器雲的數據資源如何分配？
- 如何提升容器雲平台的數據一致性？
- 高並發情況下，如何實現故障快速恢復？
本篇文章將為您抽絲剝繭。
容器雲數據持久化存儲方案怎麼選？
首先，容器雲平台的底座主流是Kubernetes，所以從理論上來說，只要支援K8s CSI存儲介面的商用存儲產品，就可以選擇使用。
在實際生產環境中，NFS是最常見的協議，也是容器雲平台在數據持久化方面最簡單的實現方式。容器自身可以支援文件、塊、對象三類存儲形式。可以依據行內應用場景的需求，以及自身的運維能力，選擇最合適的存儲協議。
- 文件存儲：適合少量數據存儲、配置文件場景
- 塊存儲：適合資料庫等高性能場景（當然，也有一些文件存儲可以提供極高的性能，取決於存儲）
- 對象存儲：適合存放圖片、影片、網盤文件等場景，需要應用支援
Kubernetes是基於CSI插件的方式提供對於存儲實現擴展，不僅僅是存儲協議，具體存儲設備也需要提供對應的CSI才能實現與k8s最佳的融合。
另外，也可以考慮直接採用比較成熟的塊解決方案，例如TopoLVM，適用於中間件或數據服務相關場景，產品中也內嵌了Ceph提供分散式存儲能力，可實現存算一體或存算分離兩種使用場景。
容器雲的數據資源如何分配？
很多銀行在採用容器雲之後，應用數量急劇增加，然而資料庫資源怎麼分配才能輕鬆實現快速擴容，提高資源利用率呢？
首先，容器雲上各個業務應用的資料庫，可以由DBaaS平台提供。DBaaS平台提供了多種資料庫服務，譬如MySQL，分散式資料庫TDSQL、TiDB，Oracle, MongoDB，Redis等。
而互聯網應用，則一般選擇分散式資料庫服務，和Redis快取服務。
DBaaS平台提供資源管理和調度，經過迭代調優的調度策略，以及充足的資源池供應，避免了多個應用共存一套庫，資料庫單個節點的連接數可以輕鬆突破3000。
如何提升容器雲平台的數據一致性？
銀行高並發場景下，數據一致性非常重要，很多銀行都希望通過容器雲平台有效保證承載運行數據的一致性，實現快速擴容、故障快速恢復。
簡單來說，一致性問題應該分為業務一致性和數據一致性兩個方面：
通常，業務一致性應該由微服務或上層應用保證。 而數據一致性問題如果面對單一應用，應用層面會通過作業系統保證崩潰一致性，存儲層面會保證多lun的一致性及複製一致性。例如在某個場景下，資料庫的數據文件和日誌文件，分別存儲在兩個lun里，那麼通常資料庫會通過dependency write保證一定會先寫日誌再寫數據，但是存儲down機的瞬間，存儲是否能保證日誌文件和數據文件兩個lun是一致的，這是存儲對崩潰一致性的處理能力。同時，如果把兩個卷分別通過async/sync複製到遠端存儲，那麼就會涉及目標lun的複製一致性，即必須保證在某個時刻，哪怕發生了某種災難，遠端的兩個卷里的數據也是一致的。
在容器場景里，這兩種一致性問題的處理方式是不一樣的：
對於業務一致性，一般在微服務領域會處理分散式一致性問題，這點已經通過開源方案做得很好了，也有不少客戶會選擇此類方案；
對於數據一致性，這點上，單一容器內並不會有額外的處理，OS對崩潰一致性的處理並不會更好或壞，而存儲側的能力還需要存儲來解決。
但是還有一個相關的話題是應用狀態保留的問題，即「重啟一致性「，畢竟容器領域，重啟是常見現象，也可以拿出來分享：
容器平台採用 K8s的Statefulset工作負載來保證平台承載的應用數據的一致性，穩定的持久化存儲，即Pod重新調度後還是能訪問到相同的持久化數據，基於PVC來實現。
Statefulset 工作負載有以下特性：
- 穩定的網路標誌：即Pod重新調度後其Pod Name和Host Name不變，基於Headless Service（即沒有Cluster IP的Service）來實現；
- 有序部署，有序擴展：即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態），基於init containers來實現；
- 有序收縮，有序刪除（即從N-1到0）：容器雲平台一般採用HPA（Horizontal Pod Autoscaler）Pod自動彈性伸縮進行故障快速恢復，可以通過對Pod中運行的容器各項指標（CPU佔用、記憶體佔用、網路請求量）的檢測，實現對Pod實例個數的動態新增和減少。
現在中國容器雲產品在K8s 的工作負載支援方面都做得不錯，以靈雀云為例，我們在產品中使用K8s的Operator技術進行有狀態應用的部署、運維等能力，並且提供中間件的容器化服務 RDS 能力，是對數據服務（中間件、資料庫）的進一步增強。
高並發情況下，如何實現故障快速恢復？
隨著容器的不斷成熟，不管是人工還是自動化開發運維都已經有大量用戶實踐的案例，能夠實現在高並發時刻的快速擴容和故障恢復。
除了通過存儲保證數據一致性之外，建議還可以考慮進行：
- 應用的容器化改造，確保故障自愈。
- 應用的無狀態化改造，確保彈性伸縮與故障自愈。
- 應用的微服務化改造，確保業務一致性，降低對資料庫的要求，從而進一步降低存儲一致性的要求。
通過上述改造，將傳統的單體應用解耦，使與事務無關的業務邏輯並行運行，結合消息隊列 / 服務網格、關係型資料庫等，針對不同業務需求，可以分別實現數據的最終一致性和強一致性，打造更適合雲原生的數據存儲方案。
