2018年互聯網保險服務治理的實踐和挑戰.pdf

1、01020301垂直應用架構RPC架構SOA服務化架構微服務架構階段：一般出現在業務發展初期，業務功能單一，業務量小?？蚣埽航浀涞腗VC三層架構模型展示層(VIEW)JSP、JS、HTML、CSS控制層(CONTROL)STRUCTS、SpringMVC模型(MODEL)業務邏輯及數據ALL IN ONE用戶與之交互的界面負責web請求的分發業務邏輯的主要實現PROCESS1TOMCATPROCESS2TOMCATPROCESS3TOMCATF5/A10|Nginx維護成本高，部署效率低，團隊協作效率差，導致系統可靠性變差（一個進程里面，一旦有接口出現故障、內存泄漏等會影響整個節點的宕機），新

2、功能上線周期變長（耦合太多）。RPC全稱是Remote Procedure Call，是一種進程間通信方式，允許像調用本地服務一樣的調用遠程服務，一定程度上做到了公共服務的重用。支撐這種架構的框架就是RPC框架。業界流行的開源的RPC框架：1、FaceBook主導開發 Apache Thrift；2、Hadoop子項目 Avro-RPC；3、Caucho提供的Hessian；4、Google開源的gRPC（HTTP/2、protobuf）；RPC原理主要技術包括：序列化、socket通信、動態代理、反射機制。組成：服務提供者：運行在服務端，負責服務接口的定義和實現。服務發布者：運行在RPC服務

3、端，負責將本地服務發布成可遠程調用的服務。本地服務代理：運行RPC客戶端，負責通過代理調用遠程服務，將返回結果封裝好供本地消費者使用。PROCESS1Con/ProF5/A10|NginxPROCESS2Con/ProPROCESS3Con/ProPROCESS4Con/ProPROCESS5Con/ProPROCESS6Con/ProRPC框架的特點：簡單、高效、通用，是SOA架構發展的底層技術支撐。RPC架構的特點：一定程度上提高了服務的重用性，但是消費者調用服務提供者配置管理困難，并且消費者無負載均衡控制，調用關系梳理困難。SOA是面向服務架構，是一種粗粒度的、以服務為中心的架構，業界流

4、行的框架：1、Dubbo/Dubbox（阿里/當當開源）2、HSF（阿里商業版）3、DSF（華為商業版）4、Coral Service（亞馬遜內部）5、Spring Cloud（pivotal開源/商業版）PROCESS1Con/ProF5/A10|NginxPROCESS2Con/ProPROCESS3Con/ProPROCESS4Con/ProPROCESS5Con/ProPROCESS6Con/Pro服務注冊中心服務治理SOA框架的特點：在服務注冊中心的協助下實現了，服務自動發現、統一配置、可配置的服務路由、可配置的集群容錯機制、服務治理等；服務治理也是依賴服務注冊中心實現的，和具體的服

5、務消費者和提供者是松耦合的；服務治理包括：服務運行態管控、服務生命周期管理、服務監控、服務安全、服務故障快速定位等功能，為運維工作提供了極大的便利。一種架構風格、架構模式服務能夠獨立構建、獨立 部署、獨立擴展松耦合、單一職責、基于限界上 下文的一種SOA的落地實現基于Devops，面向運維的架構需要團隊組織、文化的調整和完 善的自動化工具實施中體現為：受業務驅動，不 斷演進的架構微服務開發簡單技術棧靈活服務獨立運維復雜監控困難按需擴展數據一致性問題重復代碼集成測試復雜用Scale Cube方法設計應用架構，將應用服務按功能拆分成一組相互協作的服務。每個服務負責一組特定、相關的功能。每個服務可以

6、有自己獨立的數據庫，從而保證與其他服務解耦。1、聚合器微服務設計模式2、代理微服務設計模式3、鏈式微服務設計模式4、分支微服務設計模式5、數據共享微服務設計模式6、異步消息傳遞微服務設計模式02SC-Config：配置管理開發工具包SC-Bus：事件、消息總線SC-Netflix：提供的開發工具包，其中包括Eureka、Hystrix、Zuul、Archaius等SC-Cloud Foundry：通過Oauth2協議綁定服務到CloudFoundrySC-Sleuth：日志收集工具包SC-Data Flow：大數據操作工具SC-Security：安全工具包SC-Consul：服務發現與配置工具

7、SC-Zookeeper：用于使用zookeeper方式的服務注冊和發現SC-Stream：數據流操作開發包SC-CLI：命令行客戶端微服務的核心要素在于服務的發現、注冊、路由、熔斷、降級、分布式配置等。從整體架構上來看，二者模式接近，都需要服務提供方，注冊中心，服務消費方核心要素核心要素DubboDubboSpringCloudSpringCloud服務注冊中心Zookeeper、RedisNetflix Eureka服務調用方式RPCREST API服務網關無Netflix Zuul斷路器不完善Netflix Hystrix分布式配置無Config分布式追蹤系統無Sleuth消息總線無Bu

8、s數據流無Stream批量任務無TaskDubbo 只是實現了服務治理，而 Spring Cloud 各子項目分別覆蓋了微服務架構下的眾多部件，服務治理只是其中的一個方面。DubboSpringCloud每個微服務定義各自的 Interface 接口；調用方應用對微服務提供的抽象接口存在強依賴關系；開發、測試、集成環境都需要嚴格的管理版本依賴通過 xml 配置方式即可接入 Dubbo，對程序無入侵服務提供方和服務消費方通過 Json 方式交互；消費方和提供方無接口依賴；通過注解方式來實現服務配置，對于程序有一定入侵服務依賴03易安-互聯網保險公司：我司的信息系統在建立之初采用分布式架構，通過異

9、步化項目多期的實施已全部實現前中后臺在業務和技術上的解耦。中臺作為B端和C端業務承接、處理、轉換以及數據落地的平臺，正逐漸替換傳統的保險核心系統。再加上產品工廠和數據中心，信息系統形成“兩大中心，一個平臺”的總體架構。產品工廠中臺核心數據中心自建平臺網關ISSUEISSUE 0 01 1ISSUEISSUE 0 02 2ISSUEISSUE 0 03 3ISSUEISSUE 0 04 4分布式架構管理問題越來越突出？服務間的依賴關系復雜？服務頻繁上下線？服務監控不足？?急需一個服務治理框架來精細化的管理各個服務，保證整個平臺的穩定、可控。微服務基礎架構服務框架運行時支撐服務服務安全后臺服務服務

10、容錯服務監控服務部署平臺1、中臺系統技術架構升級（spring boot化）、框架建設2、服務治理中心、負載均衡、熔斷器相關功能；3.服務監控建設4.建設中臺統一頁面管理系統StepStep 01 01StepStep 0 02 2StepStep 0 03 31、分布式配置管理中心2、統一API網關3、接口拆分4、服務拆分5、服務容錯1、定制化服務監控系統及完善2、擴大服務治理范圍3、服務部署平臺完善4、服務進一步細化拆分5、統一配置管理工作臺建設6、.A10zuulConsumer1A10EUREKAEUREKAzuulHTTP/HTTPSAPI GatewayEUREKAConsumer

11、2Consumer3Provider1Provider2Provider3Invoker訂閱發布Redis集群數據庫集群ZKMQ收發消息服務治理項目一、二期：1、基本完成對現有系統的功能定位，對不符合當前系統定位的完成功能或單獨建立系統，盡量減少內部流量的逆向流動、環狀流動，使得整個流量基本呈現從上到下、從左到右的流動。2、建立統一API網關，統一服務入口、建立分布式配置管理中心，統一配置文件的管理。完成基本的服務監控，注冊中心、軟負載、熔斷器等功能，同時完善人才技術積累。服務治理項目三、四期：1、實現真正的業務流程可配置化，不同的業務線都可通過“業務調度中心”配置各節點所需的服務。2、中臺的

12、產品開發工作變成搭建一個“業務前端入口”模塊的微服務，這個微服務只是簡單組織特殊產品的業務流程。3、中臺允許灰度發布及多版本發布。4、完善的統一配置管理工作臺系統，提供對整個中臺服務的監控、管理、調度等功能。先技術、后業務由于業務功能復雜，業務變化較快，所以我們先以技術為主，搭建好服務治理的“架子”，然后在這個“架子”里完成服務的梳理、拆分。鑒于我們服務治理的人才儲備不足，對服務治理的方向不夠明確，因此需要在小范圍內快速試錯。培養服務治理人才梯隊小步快跑、小范圍嘗試一期的一個重點就是要培養起自己的服務治理人才梯隊，為后續的建設打好技術基礎。構建好項目對象模型，目錄結構maven標準化，統一ja

13、r開源jar包版本，使用maven管理系統的生命周期。MAVEN標準化引入spring boot，盡量使用starter組件來重構mybatis/druid/shiro/spring MVC等框架的集成方式，管理好系統配置，為服務治理作準備。Spring boot化由于spring boot項目對war包發布的方式不太友好，因此我們將使用嵌入式tomcat通過jar包的方式來部署系統，同時也為以后的容器化打下基礎。部署JAR包化一迭代在以上總體思路的指導下，我們決定選取中臺的10個系統，分兩個迭代完成服務治理一期的工作：一迭代主要是對單個系統的架構改造，不改變系統的業務邏輯、系統的部署拓撲，以

14、及系統間的調用關系。二迭代的工作內容也分為兩個相關獨立的部分：是服務的注冊及服務間調用的改造；整合中臺10個系統的頁面管理功能，建設統一頁面管理系統。前端改造搭建中臺頁面管理系統，整合中臺其它系統的頁面管理功能，使其它系統“專心”地提供業務接口。在該系統上我們嘗試性的使用thymeleaf來替換掉 JSP，一方面是因為spring boot對thymeleaf的兼容性更好，另一方面也是因為thymeleaf可以更好的做前后端分離，而我們沒有選擇像vue這樣的框架也是因為thymeleaf更容易上手，從JSP往thymeleaf遷移的成本更小。后端改造搭建服務注冊中心，實現服務注冊功能，同時集成

15、了客戶端負載均衡Ribbon，熔斷器Hystrix，web服務客戶端Feign。我們還加入了Turbine來集中觀察服務的負載情況，加入了Spring cloud Admin來監控服務的基礎信息。由于一期服務治理實施的系統范圍有限，對于沒有實施服務治理的系統接口，我們仍然使用Http Client來調用，其負載均衡通過硬負載來實現。服務治理（一期）二迭代分為兩個相對獨立的部分：DYSUB(QUNAR)DYSUB(TC)DYSUB(XC)WSPRDTOPENENPAYOUTPAYPUBSTASKORDERTRANSDYSUBUSERMAILS當前系統架構：問題：1、系統功能定位不明確，導致服務間

16、依賴關系復雜，業務功能過于集中在某些系統上。2、正是因為業務功能過于集中，無法針對特定業務做中間件及JVM層的優化。3、系統管理功能和業務接口耦合在同一個系統，管理功能出現變更也會影響到業務接口。3、缺少統一API網關，導致大部分接口服務直接暴露在外網。4、缺少業務監控能力，生產問題難以及時發現。DMZDMZ區區統一配置管理統一配置管理中臺核心中臺核心基礎服務基礎服務協議轉換協議轉換TASKSCADMINMVIEWAUTHCONFIGSCEUREKASCCONFIGTURBINEQUNARTCXCDYSUBWSPRDTAUTHENPAYORDERTRANSUSERMAILSPDMSSERVER

17、SMSOPENEPOLICYVIEWEINVOCEVIEWZUULPAYVIEWOUTPAY服務治理（二期）后業務架構：變化：1、基本梳理出各系統功能邊界，明確系統定位。2、對于當前業務功能過于集中的系統進行拆分，保證系統的穩定、可控。3、提取各系統的管理功能。4、拆分出對外展示的頁面和業務接口，把業務接口隱藏到內網。5、通過服務治理的技術建設，在服務治理上搭建一套比較完整的業務監控系統，做到能預見性的發現系統問題。DMZDMZ區區統一配置管理平臺統一配置管理平臺鑒權鑒權產品業務產品業務中臺核心中臺核心協議轉換協議轉換基礎服務基礎服務權限校驗1.0ENPAYICSORDERTRANSUSERP

18、DMSSERVERQUNARTCXCWSPRDTCOMMON權限校驗2.0加/解密1.0郵件服務1.0短信服務1.0取號器1.0冪等校驗1.0 黑名單1.0電子保單1.0保費計算1.0投保份數1.0FTP服務1.0OPENEPOLICYVIEWEINVOCEVIEWZUULPAYVIEWOUTPAYTASKSCADMINMVIEWAUTHCONFIGSCEUREKASCCONFIGTURBINE服務治理（三四期）后業務架構：變化：1、進一步實現對業務系統的拆分，基本完成系統的微服務化。2、構建統一API網關，實現服務路由。3、在該業務架構的基礎上搭建統一調度中心，實現業務流程的可配置化，基本達到產品對接“零開發”。4、進一步完善業務監控系統，系統問題基本可以全部通過監控預警。5、擴大服務治理范圍，實現全部系統的微服務化。DMZDMZ區區統一配置管理平臺統一配置管理平臺業務入口業務入口服務組服務組中臺核心中臺核心協議轉換協議轉換基礎服務基礎服務