近年來，隨着雲計算、大數據、移動互聯網、「聯網+」等技術的飛速發展，我們身邊的每個行業都在發生着巨大的變化。
保險行業也面臨着競爭加劇、創新加速的局面，尤其是去年保監會提出所有保險公司都要實施雙錄系統，即投保時需要錄音錄像，這些變化對保險企業的信息系統提出了越來越高的要求。
本文從數據的存儲、傳輸以及應用封裝等角度分析了保險行業面臨的挑戰，並基於 QingCloud 完整的企業級雲計算平臺和服務，提出了相應的建議架構和解決方案。
目前保險行業用戶的數據主要有以下四種：
第一種數據，雙錄系統即將成爲行業規範，而雙錄系統一定會涉及到音視頻文件。當雙錄系統上線後，會產生海量的音視頻文件，這些文件如何存儲與處理是保險行業必須面對的問題；
第二種數據，保險公司在覈保、理賠的時候會涉及到非常多的圖片上傳和下載。同時，在保險公司日常的 OA 系統裏，發生報銷時發票的上傳和下載也會產生大量圖片；
第三種數據，很多保險公司都會涉及到文件分發與文件共享，其中包括平時的報價文檔、險種發放以及一些保險公司宣傳的材料。這些數據將會在各個公司之間、公司內部的部門之間進行文件的傳遞和共享；
第四種數據，大部分保險公司的核心業務系統和非核心業務系統都會使用關係型數據庫，很多客戶的非核心業務系統，基本上都會沿用傳統的關係型數據庫，而且大都會沿用核心系統的數據庫體系。
以上這些數據大致可以分爲兩大類：結構化數據和非結構化數據。其中，保險行業用戶的結構化數據主要有兩類：
一是 Oracle 數據庫，基本上 90% 的保險公司核心和非核心數據庫都是 Oracle；
二是微軟 SQL Server，有一部分保險公司會使用。目前，這兩個數據庫基本上覆蓋了 95% 的保險行業客戶。
除了數據庫之外，其他的都是非結構化數據。非結構化數據的範圍很廣，包含音頻文件、視頻文件、圖片文件、電子保單、電子發票、郵件歸檔和共享文檔等。
音視頻文件：在沒有雙錄系統之前，其實在壽險做覈保時也會有部分的錄音錄像，但那時還沒有行業規範。在行業規範出來之後，音視頻文件一定是數量驟增，且容量會急劇增長；
圖片文件、電子保單、電子發票：這是保險行業核心業務系統中必然會生成並使用的文件與數據；
郵件歸檔：在目前一些中大型的保險公司可能會涉及到的，從保險公司覆蓋的人員來說，人員很廣泛，勢必對郵件系統的壓力也會很大，一定要對當前的郵件做一個備份，對之前的郵件做歸檔，此部分對存儲空間的消耗量非常巨大；
文件共享：對於保險公司來說，文件到底基於什麼樣的方式分發給員工、用戶或者其它的公司，這也是很重要的部分。
保險行業流行的存儲解決方案及問題
從目前這兩部分數據的數量和容量上來看，非結構化數據是最多的，但從核心業務系統的重要性來說，結構化數據（保險公司的核心數據庫）也是非常重要的。針對這些數據，目前有兩種比較流行通用的解決方案：
針對結構化數據，目前最流行的解決方案就是通過 SAN 存儲和 NAS 存儲。
目前，無論是新成立的保險公司還是一些比較傳統的大中型保險公司，一定會有 SAN 和 NAS 這兩套存儲系統，而且上面跑的一定是保險公司的核心數據庫，無論是 Oracle 還是 SQL Server。但這兩個數據庫有一個重要問題 —— 所有數據庫不能區分是核心系統還是周邊業務系統，多數情況下，都運行在同一個存儲集羣上。
針對非結構化的數據，大部分用戶是用 NAS 存儲接虛擬帶庫的方式來實現的。
之所以後面有個虛擬帶庫，是因爲 NAS 的容量沒有辦法承載如此巨量的音視頻文件，這兩個文件佔空間非常大。
這兩種解決方案是目前保險公司內部正在使用的典型存儲方案，但這兩種存儲方案也存在着一系列問題：
一是綜合成本高，集中存儲的價格都很貴。
二是擴容難度大。
從擴容的角度來說，SAN 的擴容對業務系統是不透明的，需要憑業務系統才能做這個事情；週期比較長，一個 SAN 的擴容如果數據量少一週可以搞定，數據量更多的話擴容的週期就更長。
三是權限控制難。
從權限的角度來說，在一個 SAN 存儲集羣有多個數據庫運行，勢必要對存儲集羣進行分區隔離，滿足多個數據庫庫獨立運行，雖然權限控制比較複雜，但至少 SAN 存儲這個層面做的還好，它主要的問題體現在文件共享上面，很多保險公司做文件共享會通過兩種方式：
第一種是將需要共享的文件都放在 FTP 上面，但這個權限只能通過 FTP 的賬號去控制，這樣做權限粒度會很粗，而且不能區分部門、文件；
第二種是用 Windows 共享，很多 IT 部門內部做一些軟件的共享或者文檔的共享都是通過此類方法。這種方法一般是通過 NAS 或者更多的基於虛擬機內部的一個大磁盤，要做到權限很明確基本不可行。
四是運維強度高。
系統中既有 NAS、SAN，又有虛機或物理機上磁盤的共享，這對運維的壓力非常大，各種各樣的存儲都需要了解，出現任何問題必須能快速處理，這與我們目前統一化基礎設施或者統一規劃是背道而馳的。
數據存儲的建議架構
針對以上這四點問題，青雲QingCloud 可以做什麼呢？
第一，針對結構化數據，QingCloud 提供了 Flash SAN 存儲解決方案。
雖然很多人現在已經用了 SAN 存儲，從使用難度或使用習慣來說會有一個延續性，可能他們會繼續使用 SAN，但 IT 系統架構升級轉型的方向是通用化+分佈式，我們的建議是不與趨勢爲敵，再繼續使用 SAN 不是不行，但對業務的支撐和擴展一定會有瓶頸；
QingCloud Flash SAN 可以做到超大容量存儲，一個卷可以超過 100TB，目前 Oracle 數據庫的單表也就在 30-40TB 左右，100TB 從容量上看完全是足夠的。
使用 SAN 一定是對存儲的 IO 或 IOPS 要求極高，QingCloud Flash SAN 的存儲性能單個 volume 可以達到 10 萬 IOPS。同時，在如此之高的 IOPS 下，整個存儲的延遲可以做到 200 微秒。(這個數據是在採用三副本的前提下實現的，如果副本數量更低，綜合性能還會更高。)
QingCloud 所做的整個存儲完全是基於純軟件自行開發的，例如 QingCloud 開發了高度優化的存儲協議棧，可以直接對接到底層存儲資源，網絡資源並沒有用 FC，使用的是標準的以太網，一端可以兼容 TCP 網絡，而後端的存儲副本同步採用的是 RDMA 網絡（即超低延遲網絡）來實現的。
QingCloud 整個集羣的容量和性能可以通過逐步增加 Flash SAN 存儲節點的方式來 Scale Out。
從 QingCloud 與多個保險公司交流和使用的情況來看，完全的雲架構不太現實，而用戶從現有的傳統 IT 架構分離出一部分做成 Flash SAN 或者分佈式存儲方案是可行的，混合架構已成爲必然。
這種方案適用於兩個場景：
有一些非核心的數據庫，雖然用 Oracle 數據庫或微軟的 SQL Server，但完全可以把它從核心的存儲上面遷移出來，部屬在分佈式 Flash SAN 之上；
現在很多保險公司都在做兩地三中心的同城容災或異地容災。從設計角度來講，容災中心是承載用戶所有業務在出現災難時承載業務的，而從理論上來講，大部分容災設計應該按照 1：2 的比例來分，也就是說按照生產中心 50% 的容量去設計，Flash SAN 完全可以作爲異地容災中心存儲方案來使用。
這樣有兩個好處：第一，它的成本不高，比傳統 FC SAN 的綜合成本要低很多。第二，它完全可以沿用用戶之前在傳統 FC SAN 上面業務系統的部署方法和使用方法，在使用上沒有任何差異。
第二，針對非結構化數據，QingCloud 提供了對象存儲解決方案。
從保險行業的數據來看，圖片、音視頻的增長一定會越來越多。針對如此海量的數據，未來一定會有新的業務系統來調取，而要針對原始數據做分析和處理，存儲一定不能是一個封閉的空間。
對象存儲具備開放自由的能力，具有多個開放的 API 接口，可以對接到 Hadoop 集羣、Spark 集羣，任何系統都可以與它無縫的對接。
對應到傳統保險行業用戶的業務系統中，雙錄系統、人壽險系統的音視頻文件，車險系統、辦公 OA 及報銷系統的圖片文件，企業網盤、郵件歸檔、企業 OA 裏的郵件與文檔管理，後端的存儲採用對象存儲無疑是最佳的方案。
QingCloud 本身是運營公有云的，在設計對象存儲的時候採取了多區部屬的概念，而不僅僅侷限於用戶的某一個數據中心，每一個區都是一個分佈式的架構，所以它可以支撐廣域網級的部屬方案。而在一個集羣之內，QingCloud 的對象存儲也具備很好的橫向擴展能力。
橫向擴展能力主要體現在三個方面：
第一是接入，其實傳統的存儲系統無論是 SAN 還是 NAS 都具備存儲網關或者機頭，機頭是有吞吐或者 IO 上限的，一個集羣所有的吞吐能力是通過機頭來表現的。
但如果整個存儲系統的能力都限制在一個存儲網關上，那後端再多的存儲空間或存儲能力都發揮不出來。QingCloud 通過分佈式的訪問層或者接入系統無限擴展存儲的接入能力，每個集羣可以水平橫向擴展，提升整體的接入的 IO，集羣數量沒有限制。
第二是索引，所有數據都是有索引錄入的，隨着用戶數據的增多，數據的目錄層級也會變得非常多。
如何快速定位到這個文件所在的位置，同時不會由於整個系統規模的龐大導致檢索的時間很長呢？其實通過 QingCloud 索引子系統就能保證所有的響應速度能夠達到用戶業務系統所要求的最低水平。
第三是數據，QingCloud 的數據存儲目前採用了三副本的數據保護，理論上來說三副本可以達到很高的數據可靠性，基本上數據放在 QingCloud 對象存儲上一定是不會丟的，同時用戶還可以通過水平擴展的方式增加存儲節點來擴充整個存儲的容量。
雲端傳輸的建議架構
從業務系統的角度來說，存儲只是其中一個方面。如何將數據傳輸到存儲集羣中（如對象存儲、Flash SAN），這又涉及到傳輸方面的問題，QingCloud 提供了以下三個方面的解決方案：
第一個是專線，大部分保險公司都會用。
專線爲客戶數據中心或辦公場所提供安全可靠的互聯網接入服務，QingCloud 可以提供最高 1GB 的單線（電信、聯通、移動任選其一）或多線 BGP 線路。異地的專線可以是 SDH 或 MSTP，MSTP 是比較新的方式，最早可以用 VPN、裸纖或者基於互聯網接入到 QingCloud 的接入點來提供；
第二是骨幹網。
目前 QingCloud 北京區域的骨幹網是一個環網，從用戶任意一個辦公區域或者數據中心都可以接入 QingCloud 的接入節點，通過 QingCloud 骨幹網你可以很快地連接各個數據中心或者各個辦公區、各個用戶。
另一方面，用戶也可以通過 QingCloud 的骨幹網將自己分佈於北京各個地區或者分佈於北京、上海、廣州等異地的數據中心有效地互聯互通。
數據的傳輸要做到開源節流，開源可以通過專線、骨幹網各種鏈路實現提升帶寬互聯互通的能力，那麼如何節流呢？QingCloud CDN 就可以幫助用戶節省帶寬，提升帶寬的使用效率。
CDN 可以在用戶與業務服務器所在地域間物理距離較遠，需要進行多次網絡轉發，傳輸延時較高且不穩定時，對一些比較大的沒有狀態的數據（如視頻、圖片、音頻等）提供臨時的存儲位置，來綜合地提升互聯網業務中的訪問效率。
雲端運管的建議架構
前面提到了數據的存儲和傳輸，那如何將這些數據組合成上層的應用呢？這需要企業從 IT 系統架構和運維方面轉變思維。
首先，不應再侷限於基礎資源的交付。
從泰康的實踐就可以看到這個變化，最早泰康對 QingCloud 的使用僅僅侷限於 IaaS 層，如虛機、塊存儲、VPC 網絡等資源，但現在泰康已經更多偏向 PaaS 層的使用。
其次，需要轉變目前發佈系統與雲平臺的鬆耦合狀態。
保險業每個用戶都有一套統一的發佈管理系統，業務系統要上線、要迭代，需要對接到雲平臺，大多數用戶希望和雲平臺之間是鬆耦合的狀態，但 QingCloud 認爲應用的發佈系統或生命週期管理應該和雲保持一種緊耦合的狀態。
從運維的角度來講，無論技術的運維還是傳統的運維可能更關心硬件，如服務器、網絡設備、存儲設備等，但由於軟件定義技術的出現，使得大部分運維人員不需要再關注硬件，而是聚焦於業務系統本身。
AppCenter 2.0 就滿足了以上三個轉變的需求。QingCloud AppCenter 是一個雲計算環境中的應用交付與運營管理平臺，同時包含一整套用來開發雲應用及雲化已有應用的框架。
讓應用提供商和開發者可以從資源層管理的複雜性中脫離出來，從而更高效地開發、部署、運維及管理所提供的應用，讓用戶可以便捷地選擇需要的應用來構建和管理自身的業務。
AppCenter 與雲平臺做到了緊耦合的狀態，爲了實現這點，QingCloud 主要做了以下幾項工作：
第一，模板化。所有的業務系統都做成標準化的，只有標準化才能統一和自動化，沒有標準化運維起來難度極高。基於模板，我們可以將業務系統抽象出來，形成一個標準的模板，大幅降低雲端應用開發、部署及運營複雜度；
第二，可視化。可視化是以應用爲粒度的可視化編排功能，提供全新的複雜業務系統構建模式。實現可視化後，用戶無需再關注底層資源情況，可以將更多精力關注到業務系統的構成上；
第三，高性能。基於 AppCenter 開發的應用完全構建於青雲QingCloud IaaS 平臺之上， 充分享受青雲QingCloud 提供的高性能計算資源、調度管理、SDN 2.0 與 SDS 2.0 支持。此外，QingCloud 還在私有云環境中，提供基於容器的解決方案。從前，QingCloud 大部分業務系統都是基於虛機實現的， 而虛機的性能是有一定損耗的，但容器可以提供媲美物理機的性能。AppCenter 既可以支持虛擬機，也可以支持容器技術。
同時，AppCenter 支持基於 KVM / Docker / LXC 三種技術體系構建應用，並提供完整的應用編排與管理能力，實現對異構資源的統一管理；兼容 Kubernetes、 Mesos 及 Docker Swarm 等主流容器管理框架，幫助用戶基於主流框架實現容器應用編排及 DevOps 持續交付。
前面提到過，發佈系統一定要與雲平臺實現緊耦合，AppCenter 可以對底層的所有資源實現智能、快速的應用調度，如應用發佈、擴容、配置變更這些工作不再需要運維人員去調整底層的資源，只需將代碼上傳到 AppCenter，AppCenter 就會對所涉及到的組件做出智能的調度和分配。