不去談一些虛的上價值的東西東西，作為技術人直面主題，講解下我對行業系統建設的理解以及對整個行業系統建設的規劃

行業系統建設現狀

1. 傳統架構
中科軟的核心系統是目前市場上主流的壽險公司保險系統建設解決方案，無論是系統成熟度以及監管信任度上都是絕對的龍頭老大，外資保險公司喜歡選擇易保，而國內大的保險公司一般都會選擇自研，這些自研的核心系統或多或少都會借鑒中科軟的系統建設經驗。而大部分中小型保險公司都會選擇中科軟的核心業務系統。傳統架構大部分都是基于如下架構建設：

一般分為核心系統、外圍系統、渠道系統和數據平臺，核心系統在這個架構下作用非常重要，所有的業務邏輯、業務流程包括收付費、財務數據加工、上報數據加工都是在核心系統完成，可以算是大核心系統，外圍系統主要就是一些影像、單證、增值稅、資金平臺和代理人銷管系統，渠道系統主要就是電商平臺、銀保通、經代通、保單導入平臺等；而一些和數據處理相關的系統主要就是監管平臺、BI系統和財務系統，中間可能還會加設一個所謂的數據交換平臺來做這些數據導入導出、格式轉換清洗的工作。行業內大部分壽險系統架構都是在這個架構下衍生而來，包括現在的阿里雙中臺架構、騰訊的三核心。這個架構后續面臨的問題也比較明顯，就是核心系統承載著過多的邏輯和任務，導致核心系統自己成為了單點風險、成為了瓶頸，起初可能通過負載均衡（Nginx）來解決一些性能問題和高可用問題，但隨著核心系統承載的功能越來越多，簡單的負載已經無法支持高可用的問題了，所以就有了后續的“核心減肥”。

2. 輕核心、大外圍
隨著“核心減肥”概念的推廣，“輕核心、大外圍” 是很多保險公司該一階段的建設方案：讓核心系統專注于核心業務，更多的流程規則前置，交由上層的渠道和外圍系統承接，伴隨著業務架構的變化，技術架構也在同步升級，微服務成為很多外圍系統架構選擇的寵兒，逐漸就演化成了業務中臺。
同時數據加工處理的類的工作也逐步抽象，隨著hadoop技術的成熟，也逐漸形成了大數據平臺的方案，財務、監管、BI都是基于大數據平臺的能力進行建設，保險公司逐步將數據平臺的建設與業務平臺分離開來，形成了自己的保險數據平臺。隨著AI技術的發展，數據與AI的結合越來越緊密，有些公司會將AI算法作為數據平臺的一個組件，也有一些公司會分為數據平臺和AI平臺。

技術服務于業務，隨著業務架構的升級，技術架構也在同步變化，云原生、微服務就是這個時候融入進了保險系統的建設方案中。隨著技術復雜度的提升，依賴很多的專業中間件產品或者開源框架，于是就有了技術中臺或者能力中臺的概念，將這些技術能力進行封裝，通過技術中臺直接為業務系統提供服務，讓業務研發專注于業務，也就形成了如下的架構方案：

是不是和阿里的雙中臺架構很像啊 ，這個是一個相互影響的過程，畢竟當時阿里的技術在行業內如日中臺，開源產品和技術布道都做的非常不錯，保險行業的技術迭代恰好趕上了阿里的中臺概念推廣，所以也就逐漸形成了雙中臺的解決方案。說實話當時我也是受了一個阿里云的架構師指導，形成了建設保險電商中臺的想法并開始實踐。當然阿里有阿里的問題，當時并沒有被他們的EDAS打動，而是選擇了在dubbo的基礎上進行二次開發形成自己的微服務框架，后續隨著springcloud的出現，也逐步轉移到了springcloud的產品體系中。

3. 服務化轉型，走向云原生架構

隨著保險公司系統架構的復雜加上云廠商為了推廣自己的產品，云原生架構成為了目前行業比較推崇的解決方案，用來承載微服務架構以及提供高可用高并發的解決方案確實是一個不錯的選擇， 但云原生是否真的是必要的，是否這的是保險公司的必然選擇？如果廠商給保險公司設定的場景和前提都是正確的，那么云原生確實是一個不錯的方案選擇。只有保險公司自己才知道自己的真實需求，廠商通常只是想銷售產品，抓住商機去推銷自己的方案和產品，所以還是需要保險公司技術部自己來去規劃和分析。撇開技術選型和需求分析不談，下面就聊聊云原生架構 ，下面是CNCF就云原生的定義：
首先微服務 + 容器 是云原生的一個重要要素，并不是使用了微服務就達到了云原生的要求，DevOps是一個重要的因素，而且微服務和容器只能在軟件層級保證高可用和彈性擴容，基礎架構的方案也是云原生的重要依賴之一（不是說一定要上云，良好的虛擬化支持一樣可以提供一個高可靠、可擴展的基礎架構）。 那么云原生的架構可以簡單的表示如下圖 ：

保險公司系統是否所有系統都適合云原生架構？ 云原生架構帶來的弊端是什么？我們要如何從組織架構、研發體系、運維管理體系去與之相適配？我們的管理能力、研發能力是否可以跟上，相應的人才我們是否可以留住，團隊穩定性和人力成本增加我們要如何面對 ？這些都是保險公司需要考慮面對的內容，那么接下來我們首先看下保險公司的系統都有哪些需求，以及云原生的系統架構規劃要面臨什么樣的挑戰。
結合之前分析的保險公司的系統中臺架構，再考慮到歷史遺留系統以及一些財務、監管、稅收相關的系統限制，必須要保留一部分傳統架構的系統運行，可以得出以下一個稍微細化的保險公司系統架構概圖：

補充說明： 最右下角的PaaS服務主要是指的外部依賴的PaaS服務，比如一些影音視頻相關的、AI智能相關的、人臉核身相關的PaaS服務。左下角的管理系統則是指的一些歷史系統以及增值稅、財務、OA這類的傳統架構應用，有些事集中式的SSH架構，有些都不是java體系，比如.Net\PHP\C++等，這些多數都是內部管理系統，所以我們必須要為這些系統的運行提供一個個服務支撐。

保險系統建設目標假想

另外我們必須還要考慮的一個問題就是成本問題，微服務是帶來了應用解耦，帶來了彈性擴容，帶來了服務瘦身，但也同時加大了系統研發成本、交流溝通成本、架構復雜度、維護復雜度、外包人員要求的增加。所以我個人認為在規劃系統建設的時候，無論是否采用云原生，都要保留一套開發簡單、維護方便的集中式架構作為選擇，否則就會出現大炮打蚊子的情況。所以不管保險公司新一代架構采用什么方案，個人認為研發框架需要準備至少4套架構： 云原生的微服務框架、單體應用開發框架、管理平臺研發框架、前端研發框架（包含移動開發框架）。再加上歷史的遺留系統框架，所以一個保險公司的系統面臨7、8個開發框架是很常見的事情。

那么我們得到一個結論： 保險系統建設需要針對不同的業務需求和場景提供不同的適配研發架構，才能將研發效能最大化。

撇開對傳統架構的兼容，對不同場景的兼容問題，我們需要一個什么樣的系統呢？也就是說我們要明確需求，所以我對我自己的設計的系統提供了一個基于自己對保險的理解，制定了一個假設的系統建設需求。 傳統的保險業務主要靠的是代理人推廣，保險的系統只要提供出單支持、在線服務支持、代理人展業支持即可，所以保險公司的系統主要就是在業務流程建設上投入。隨著保險業務的發展，對保險營銷、保險客戶運營的需求日益增加，對數據資產、營銷服務、產品形態的系統支持日益重要，同時銀保監對行業合規以及數字化的監管日趨嚴格，所以我將保險的業務系統分為了產品中心、營銷中心、運營中心和監管中心。我們傳統的業務流程建設歸于運營中心，產品中心也是衍生自核心系統的產品定義模塊，監管中心也是從核心系統中監管報表以及一些上報平臺擴展而來，基于這個目標后續我們會對整個產品方案進行展開，進行方案完善，需求目標如下圖：

以上是我個人的一些理解和淺見，與大家分享。歡迎各位提出寶貴建議，不當之處也歡迎指導指正。

總結

以上是生活随笔為你收集整理的三津谈保险系统建设（一）： 现状分析和建设目标规划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。