近年來，大家一直都在探討保險科技的應用，用技術改進保險系統(tǒng)的效率。以云計算服務、大數據、互聯網IT技術、AI等科技創(chuàng)新技術應用為引擎內核，實現保險業(yè)新模式、產品與服務創(chuàng)新。保險科技越來越成為保險公司技術革新的著力點，從實際工作來看，支撐這些科技創(chuàng)新應用真正形成生產力，保險公司的核心系統(tǒng)架構必須轉型。

陽光保險集團信息技術服務中心總經理 石運福

新形勢下核心系統(tǒng)面臨的新業(yè)務要求

　　互聯網電商、移動支付以及社交媒體等APP的融合發(fā)展，不僅改變了人民的生活，也改變了保險的生態(tài)，也使得傳統(tǒng)的保險核心系統(tǒng)面臨新的考驗。

　　1.面臨突發(fā)流量的考驗。社交媒體以及各類電商平臺的運營，積累了大量原來線下無法采集的數據，這些數據使得保險公司的產品可以低成本、快速連接會員對接人的需求，為精準營銷提供了無限可能。一旦產品戳中用戶需求痛點，極易實現單一產品的突破，這種突破必然引起保險核心系統(tǒng)流量的突發(fā)。

　　2.面臨7×24小時不間斷運營的考驗。互聯網大大提升了客戶的體驗期望，近期Fintech理念的興起不僅給了保險公司新的發(fā)展機會，也在一定程度上進一步提升了客戶對保險公司的期望。如何更快、更好地處理客戶的各類需求已成為基本需求，多渠道、全天候的服務要求也已成為保險公司的標配，這就需要核心系統(tǒng)7×24小時不間斷運營。

　　3.面臨更快、更好的服務壓力。許多保險標天然具備流動性，如果再疊加上即時生效要求，必然對核心系統(tǒng)提出了更高要求，特別是互聯網場景化的保險，對時效及穩(wěn)定性具有極為苛刻的需求。誰能處理得更快，誰就會帶來更好的體驗，誰就會獲得口碑。

　　綜上所述，平穩(wěn)應對突發(fā)流量處理且能夠提供快速穩(wěn)定的7×24小時運營服務是目前保險公司在新形勢下面臨的實際需求，也是核心系統(tǒng)架構轉型的著力點。

保險核心系統(tǒng)的架構著力點

　　傳統(tǒng)的保險業(yè)務處理，不會面臨流量突發(fā)的情況，其流量冗余可以按預期進行管理，對時效性具有一定的容忍度。在面臨數據準確性和一致性的嚴格要求之下，其設計主要依靠數據庫來保證，涉及數據變化的業(yè)務處理，會盡可能地放在一個事務里，由數據庫來保證數據的準確性和完整性。這種設計帶來以下問題。

　　1.業(yè)務能力依賴數據庫處理能力，擴展周期長。業(yè)務處理能力受限于數據庫的處理能力，在流量突發(fā)的情況下，數據庫的能力冗余是關鍵，一旦冗余能力不足，只能依靠數據庫的縱向升級來處理。這種更換周期短則數月，長則數年，處理時效不能滿足業(yè)務擴展要求，而且單一硬件的處理能力受限。

　　2.有價單證的業(yè)務號碼連續(xù)性限制了并發(fā)能力。保險單號碼受業(yè)務管理的要求，不僅有唯一性要求，而且還要滿足連續(xù)性要求，需要根據業(yè)務歸屬機構和使用時間產生單調遞增的序列號。這主要依靠數據庫的鎖機制來保證，當出現高并發(fā)時，就會產生很多數據庫行級鎖，單號生成一旦和業(yè)務交易綁定在一個事務里，極易引起業(yè)務系統(tǒng)的不穩(wěn)定。

　　這種依賴數據庫的設計對于流量穩(wěn)定在一個波動范圍的情況下，硬件的處理能力可以匹配這個波動，不會出現大的穩(wěn)定性問題。一旦面臨流量突發(fā)，其局限性就會大大暴露出來，系統(tǒng)很難實現7×24小時不間斷地穩(wěn)定快速運營目標。

　　因此，核心系統(tǒng)架構在新的發(fā)展形勢下，必須破除對數據庫的依賴。通過解決對數據庫事務的依賴和數據庫處理能力的依賴，才有可能實現在流量突發(fā)情況下提供7×24小時的快速穩(wěn)定運行能力保證。

數據架構轉型

　　擺脫對數據庫的強依賴，必須依據保險業(yè)務的業(yè)務特性對數據架構進行重新構建。數據庫數據覆蓋范圍越廣，所涉及的業(yè)務過程越多，事務就有可能越大，單一事務占用資源就越大，應對突發(fā)能力就越弱。解決數據庫的依賴問題，就要從解決單一數據庫過大問題開始（如圖1所示）。

圖1 大數據庫和單體應用拆分

　　1.長期數據和短期數據分離。場景類的保險需求，容易形成突發(fā)，但此類保險產品，大多是短頻交易，大部分的產品周期數據產生在外部，內部的處理要求相對簡單，因此適合與長期保險數據進行分離。

　　2.過程數據和結果數據進行分離。保單數據一般會經過詢價、報價、核保、繳費、出單、打單等眾多環(huán)節(jié)。其中間交互過程產生諸多數據，這類數據具備很強的“熱數據”特性，一般是在一個特定的時間范圍之內，超過這個范圍，其數據活性就大大減少，甚至基本不用。比如核保過程的流程類數據，提交、核保、打回等工作流數據，只在待核保期間具備活性，一旦拒保或者承保，這類數據就基本上失去活性。這類數據可以和保單類數據進行分離。

　　3.強一致性數據按業(yè)務特性進行串行化分離，降低事務復雜度。業(yè)務連續(xù)類單號依靠數據庫的鎖機制來保證，這類數據是并發(fā)處理的敵人，是處理突發(fā)流量的瓶頸。這類數據可以考慮和其他交易類數據拆離，形成單一的數據服務，從而提高單個號碼生成速度，減少資源需求，提高其并發(fā)特性。

　　從生命周期來看，投保數據和保單數據具備相似性，其差距主要在狀態(tài)數據，因此可以考慮將投保數據和保單數據進行分離。投保數據可能會進行頻繁的數據交互，而保單數據大多提供讀取服務，而且保單庫即使不工作，理論上可以從投保單庫重新生成，分離之后，更容易從各自業(yè)務特點實現7×24小時的設計。

　　4.根據讀寫特性分離數據。像配置類數據、代理協(xié)議類數據以及內部管理類數據，數據具備寫少讀多特性，主要提供讀，其寫入功能暫時失效對業(yè)務影響不大，因此適合將此類數據進行分離。分離之后，最大的好處是可以最小的成本實現雙活，以保證7×24小時運營。

　　5.外部數據和內部數據分離。保險業(yè)務一般都會使用外部數據，這類數據往往需要第三方來維護，這類數據適合單獨剝離出來，以避免對主要業(yè)務的影響。

應用架構轉型

　　根據新的數據架構設計，單一大型數據庫就會變成分類存放的數個小型數據庫，此時應用架構就可以按數據庫進行拆分，并實施應用服務化拆分，把緊耦合業(yè)務服務按照服務化思維進行拆分，從服務入口，到服務實現、服務數據庫、服務部署完全獨立。因此，新的應用架構需要根據數據源的分布重新編排，形成服務化架構（如圖2所示）。

圖2 完整的互聯網應用架構

　　1.數據庫之間耦合向應用服務轉變。應用和數據庫遵循單元化原則，進行DBLINK治理和數據源治理，避免跨庫操作。DBLINK加劇了數據庫之間的耦合，容易造成性能的互相影響。因此應該杜絕或者嚴格管理DBLINK的使用，將DBLINK類的功能變更為應用服務來提供。

　　2.讀寫功能分離，隔離“列表”類查詢功能。將時效性不強的讀功能和其他功能進行拆分，獨立部署，形成單獨的讀服務。查詢結果經常不可控，大的查詢結果使用大量的內存，一旦并發(fā)稍大，極易引起應用的崩潰，通過讀寫分離，可以控制故障的影響范圍。

　　3.引入消息系統(tǒng)，進行大事務串行化解耦。將可以一次生成的事務進行分割，引入高可靠消息系統(tǒng)進行異步處理，將大事務變成小事務，來提供系統(tǒng)吞吐。

　　4.前后端架構分離。前后端分離是指把業(yè)務展現和業(yè)務服務提供從一個大應用里剝離開，分項目進行開發(fā)測試部署。前端應用與后端應用邊界清晰，前端只使用后端提供的API進行數據交換，前端關注UI展現速度、兼容性、用戶體驗，可以根據業(yè)務的需求進行高頻次升級。后端提供完整的業(yè)務邏輯和數據處理，關注高并發(fā)、高可用、高性能，同時注重數據安全。

　　5.引入緩存架構，降低對數據庫資產的消耗。針對配置類數據，引入緩存架構，將對數據庫的訪問變成內存的應用訪問，將大大降低資源的消耗。通過大量緩存的使用，可以顯著提高擴展能力，提升系統(tǒng)的響應速度，降低系統(tǒng)負擔。從前端緩存到應用緩存，再到數據換錯，多層次的緩存，可以有效應對系統(tǒng)接入和處理能力的壓力。

　　6.構建統(tǒng)一的異步任務管理平臺，將定時任務按照標準化進行封裝，實現統(tǒng)一的監(jiān)控和治理。定時任務類功能一般是以處理數據為主，消耗大量的內存，運行時間較長，同步調用極易引起應用的崩潰，將此類功能剝離出來，可以有效隔離故障，降低對數據庫的影響。

　　7.動靜分離，分層部署。構建分布式對象存儲層，為靜態(tài)層的對象提供讀寫服務。影像類、電子保單類、文件類等處理獨立成單獨的對象服務，不僅僅可以提高安全性，而且可以引入CDN，提高業(yè)務的響應速度，減少網絡流量。

　　8.外部服務隔離。對于行協(xié)、稅務等實時交互的平臺，需要進行事務隔離，確保這類服務的異常不影響系統(tǒng)的整體服務。

　　9.讓應用逐步接管數據一致性。適度讓應用提供對數據一致性的保證，減少外鍵的使用，可以降低事務的復雜度，提高并發(fā)性。

　　10.構建統(tǒng)一的服務治理平臺。建設統(tǒng)一服務平臺，經過兩年多的摸索和結合互聯網技術，我們完成了統(tǒng)一的基于Ngnix的Web服務和負載均衡平臺。搭建了統(tǒng)一的服務治理平臺，包括服務路由、編排、灰度、降級、容災、全鏈路監(jiān)控。搭建了統(tǒng)一用戶會話平臺、統(tǒng)一日志輸出、分析監(jiān)控平臺、統(tǒng)一緩存平臺。集中平臺的搭建解耦了核心業(yè)務系統(tǒng)的關注點，讓核心業(yè)務系統(tǒng)關注業(yè)務的邏輯，流程，用戶處理，讓技術平臺解決技術的問題。

　　通過核心架構的轉型、落地實施，陽光保險新一代核心系統(tǒng)已經成功上線運行一年之久，取得了很好的效果。以上架構轉型的原則或者方法是我們在建設新一代時逐漸形成并行之有效的實戰(zhàn)經驗；同時良好的核心系統(tǒng)架構也是隨著業(yè)務需求和技術發(fā)展變化而持續(xù)演進的。希望本文能給大家?guī)�來一些思路方法，并在各自核心系統(tǒng)建設中有一定的指導和借鑒意義。

（文章來源：金融電子化雜志）

掃碼即可手機
閱讀轉發(fā)此文