鑽石舞台

眾安保險是中國首家和規模最大的互聯網保險公司，銷售採用全互聯網形式進行產品銷售，不設線下代理，線上則主要通過自營、夥伴公司網站、渠道等方式獲取流量。通過積極提供個性化、定製化和智能化的保險品種，彌補了傳統保險公司產品能力的不足。

從業務角度來看技術層面時，為了滿足眾安保險的複雜業務場景和行業的專有特性，就會對技術側的流量治理產生了強烈的需求。本文將通過介紹眾安保險的一些業務場景與實踐案例，為大家帶來關於「互聯網保險」場景下的網關選型與落地操作。

開頭我們提到過，眾安保險作為國內第一家互聯網保險企業，提供非常多的保險品種，特別是像財產險。財產險的種類可謂是繁多，大家想到想不到的類型可能都會有，比如車險、碎屏險和健康險，還有日常常見的淘寶購物退運費險等等。

基本只要是大家生活中遇到的東西，都有可能會被設計成一種保險產品，所以互聯網保險場景下，險種產品之多是其比較有特色的背景。

雖然說互聯網保險的所有操作流程都在線上進行，是典型的互聯網 + 場景。它既有互聯網的高頻高並發或者說是一些爆款現象，也有像其它的低頻低並發場景。但它既有互聯網的流量特性，同時也還包含非常多的線下或者傳統保險的業務特性。

更準確地說，互聯網保險的很多場景入口依賴渠道進行，多渠道使得業務能夠進行更多能力的釋放。所以對於渠道流量的管理，也是互聯網保險在實現業務層面的重要一環。

如上圖中紅色和綠色部分，就屬於針對監管渠道或前置業務與核心業務分離的架構方式。在這裡對於安全層面也存在一些規範要求，包括兩地三中心的治理和針對中間件數據業務的隔離，對流量治理和安全性的要求相對是比較嚴格的。

考慮到真實使用場景，每家公司對於流量治理的層次和需求其實也各不相同。比如有些公司可能相對來講更希望網關更前置，僅作為邊緣網關角色，有些可能希望網關能夠處理南北流量或者是東西、南北流量共同治理。

這裡從一些共性角度（更貼近眾安保險的業務場景）大概整理出了以下幾個痛點跟解決方向，即當下業務場景內網關層面的不足以及之後想要彌補的動作方向。

而在網關部署的真實場景下，除了上述問題之外，還需要考慮整體業務需求與部署環節中多類型網關的適配。下圖展示的是在流量治理過程中的邏輯部署，主要涉及流量網關、微服務網關、統一運營網關、BaaS 網關和域網關。

在梳理清晰當下問題後，眾安保險的技術團隊開始將網關選型聚焦在一些比較成熟的開源產品之上，開始了新一輪的探索。

由於眾安保險在選型之初就框定了「開源產品」，所以在評估開源產品的層面，也從企業角度給出了一定的參考標準，並從這些角度給予了 Apache APISIX 最直接的肯定。

當然，除了對開源產品本身角度的評估外，眾安保險也對比了目前公司業務中仍在使用的 Kong 和 Traefik，同時也接觸了阿里雲分享的 MSE 產品等。

最終在以下項目中進行了全面的橫向對比，可以看到不管是在企業級的長期規劃還是短期規劃中，Apache APISIX 都能很好地滿足眾安的業務需求。

眾安保險目前正在業務內部逐步將底層產品 BaaS 化。由於是金融屬性，所以對於 BaaS 產品的落地要求會更高，需要將基礎架構產品與雲產品一樣實現統一標準的計量計費。

因為公司內部用到的所有產品，都需要實現財務報表式的監管要求。因此在這種場景下，就需要實名認證和相關審計功能，這裡就需要用到 Apache APISIX 的鑒權模塊了。也就是說公司內部的任何調用過程都需要被審計記錄，包括調用次數、發生的費用等。所以在這個過程中，Apache APISIX 強大的日誌相關功能也是起到了很好的支持。

同時在審計過程中也需要進行峰值審計的計算，這裡就會涉及到很多計費公式，這裡的計費公式里不僅有調用量，還有峰值等信息。所以基於 Apache APISIX 的功能支持也可以實現相關 Metrics 指標的呈現，從而為計量計費場景奠定堅實基礎。

具體的實現框架可以參考上圖，其中配置中心是一個純七層流量的協議，所以可以完全納入到計量計費體系中，包括 ES 以及 Apache APISIX 本身等。具體操作主要是基於 Apache APISIX 目前的結構做了一些定義，比如去調用幾個針對公司業務的需求，以及使用 Apache APISIX 的一些插件進行相關編排能力的實現。

面對眾安保險的多險種多渠道使用場景，多租戶多渠道的流量隔離也成為具備行業特徵的需求。而基於 Apache APISIX 的落地實踐中，眾安也針對多渠道場景下的要求與強管控進行了一些規劃。得益於 Apache APISIX 強大的流量編排和插件編排功能，為互聯網保險場景下提供了之前從未體驗過的流量精密控制效果。

比如有的業務方規模比較大，渠道也很大，就可能會把渠道單獨建立一個集群來用；但有些渠道規模較小，可能 10% 的規模是大的，但大部分都很小。基於這樣的場景，就可以嘗試將這些小渠道融合到一個網關實體或實例里，然後再進行共享。

當然這裡就會涉及到每個應用在接入的過程中，因為不同渠道會有不同的上下游去對接，就會產生不一樣的域名。基於這種場景的隔離（如下圖結構）稱之為一級隔離。

但當渠道對接進來後就需要進行後續相關操作，雖然流程是一模一樣但接下來業務的管控能力要求是與上邊提到的不同，所以就需要再對渠道進行二級隔離（如下圖結構所示）。通過這樣的一級隔離加二級隔離模式，就可以很好地解決了網關在多租戶多渠道中的流量隔離。

目前眾安保險不僅僅只有這一項業務，同時旗下還有非常多的子公司，在後續的推進過程中一定會面臨很多這樣多部門業務大規模的部署。所以在推進相關技術棧的時候，一定不是只由一個部門去主導，更多的是跨部門之間的共同協作，從而儘早實現 Apache APISIX 在眾安的落地部署。

目前眾安保險內部正在基於 Nacos 進行服務的無損上下線，所以在後續規劃中會將 Apache APISIX 與 Nacos 對接實現統一管理。這樣就可以將微服務通過路由方式對接到 Apache APISIX，達到無損或基於源數據的流量分發效果。當然也會繼續藉助 Apache APISIX 來完善 BaaS 的相關能力。

眾安保險內部目前是在進行自己平台的服務網格搭建，但因為業務發展迅速導致目前的服務網格運行狀態滿足不了當下業務落地空間。所以也在持續關注外部的服務網格產品，比如 Apache APISIX Service Mesh，或者是嘗試利用 Apache APISIX 與 etcd 的結合方案。

縱觀眾安保險在追求流量治理和一些落地規劃執行的過程中，不僅僅是把 Apache APISIX 作為一個邊緣網關角色去控制點狀流量，更多的則是基於整體架構進行流量的控制。即面向整個 DevOps 的全生命周期，進行諸如測試場景是否能提供測試能力或者多版本開發能力；生產側提供流量錄製、回放能力；大數據部門是否可以生產相關的沙箱環境，來評估更好的模型並進行域環境的隔離等能力。

希望在後續的落地實踐中，眾安保險可以基於 Apache APISIX 實現整體流量治理的完整落地，助力互聯網保險領域的流量管控與安全治理。