引言：
2018年，我們在人保壽險進行了微服務平臺建設。針對保險行業，微服務建設有哪些需求，我們又是如何應用DevOps理念的，本文我就和大家分享一下我們在人保壽險的微服務建設之路。希望通過本文，大家能夠撥雲見日，真正的使DevOps成為企業生產力增長的助推器。
目錄：
一、項目建設背景
二、平臺技術棧及架構解析
三、通過DevOps對微服務應用進行CI/CD
四、總結
項目建設背景
根據保險行業發展趨勢，目前保險交易已經呈現高頻化、碎片化、場景化等特點，對系統的處理能力、容量、業務連續性、需求相應速度、運維響應速度提出了更高的要求。為了提高項目建設的效率、質量、安全性、技術水平，縮短項目建設週期，降低項目建設成本，進而更好的支持業務與技術的發展與創新，人保壽險急需建設應用和服務的技術標準和分佈式的應用平臺。
那麼建設分佈式的應用平臺有什麼好處呢？
1.分佈式應用架構解決了服務器性能的問題。單臺服務器的性能畢竟有限，綜合利用多個節點的處理能力，才能提高整體的服務能力。
2.將不同的業務模塊部署在不同的服務器上，或者同一個業務模塊分拆多個子業務，再部署在不同的服務器上，以此來解決高併發的問題。這樣一來，模塊的內聚性更高，更多的關注自身業務，模塊與模塊間耦合度更低，減少了業務複雜度。
3.分佈式應用平臺對分佈式應用有結構化的管理，相比傳統的管理模式，大大減輕了運維人員的負擔，應用配置的修改發佈可以通過友好的可視化頁面輕鬆完成。
4.分佈式應用平臺同時解決了分佈式應用的監控告警問題，對每一個應用服務進行實時的監控，出現問題能夠立刻進行告警通知、第一時間響應。
平臺技術棧及架構解析
經過項目初期的調研與考察，在人保壽險確定的平臺架構技術如下：
分佈式平臺主要以Spring Cloud組件為技術支撐，主要用到Eureka作為註冊中心、Feign用來做服務調用客戶端、Ribbon來進行客戶端的負載均衡，Hystrix用來作熔斷、限流和降級。搭配配置中心Apollo、斷路器監控中心Hystrix-dashboard 和Turbine，形成一套完整的分佈式微服務架構。
（人保壽險DevOps項目平臺技術棧）
在日誌的採集和處理方面，我們採用了常見的ElasticSearch+Logstash+Kibana的架構，利用ELK一站式解決方案的便利性，為整個平臺提供監控。至於開發測試階段的持續集成、持續部署，我們通過DevOps+Maven+Git/SVN來完成。
（人保壽險DevOps項目分佈式平臺技術架構）
分佈式應用邏輯架構總共由以下這幾部分組成：
（1）服務網關API Gateway，在微服務架構中，所有的服務都變成了一個個細小的API，API Gateway作為整體架構的重要組件，它負責對應用的API進行統一的管理
（2）微服務平臺，微服務平臺負責應用服務的註冊發現、負載均衡、應用配置的管理、服務調用鏈的監控和告警
（3）PaaS平臺，PaaS作為業務基礎平臺，負責提供公共的各類中間件服務
（4）管理門戶，提供友好的可視化界面對應用服務進行登記、配置管理、授權以及日誌監控
（5）DevOps，高效自動化地完成微服務應用的持續構建和持續部署。
（6）SDK，為了在應用系統技術架構上形成統一的技術標準規範和統一的規劃，彌補應用開發和運行缺乏的技術平臺短板，我們向人保提供了SDK腳手架以及開發手冊，降低了開發分佈式應用的門檻，有效縮短了項目的進度
（7）流程和規範的制訂，讓項目的全生命週期得到管控，項目在持續構建的過程中不斷精益提升，在持續發佈的過程中始終可以提供可用的穩定的介質版本
（人保壽險微服務平臺部署架構）
在人保壽險微服務平臺中，我們明確了用域-系統-應用架構來進行微服務管理的部署模式。
針對人保壽險不同業務領域，例如壽險域、車險域分為不同域進行業務隔離；
每個域下根據公司的業務板塊創建業務系統，業務系統這個定義在不同的客戶處有不同的定義，有的叫項目、有的叫系統群，實質上都是由一組微服務應用構成的；
業務系統下部署微服務器應用，每個應用部署多個應用實例形成高可用，共同來支撐業務。
通過DevOps對微服務應用進行CI/CD
（DevOps對微服務應用進行CI/CD）
通過DevOps進行分佈式應用的構建，可以很方便地進行項目構建、發佈流水線的編排，可以讓開發人員將更多的工作重心放在代碼業務邏輯上，大大提高了生產效率和質量，解放了開發運維人員的生產力，減少了手工的重複勞動，避免了因為操作不當帶來的損失。
對於人保壽險微服務應用進行持續集成和發佈，我們很好地利用了DevOps的特點，本期項目DevOps的目標是通過CI\CD，對微服務類應用進行自動構建、自動發佈、自動部署，減輕開發人員運維人員的負擔，提高項目的效率和質量。
持續集成
持續集成模塊的功能主要有代碼庫管理、構建定義管理以及構建實例管理等。在構建定義管理模塊中，DevOps平臺將構建任務分成了四種類型：
編譯類任務：Maven、Ant、Gradle、純前端構建等
測試類任務：Sonarqube、Jmeter、Selenium等
打包類任務：Npm、Archive、Docker等
其他工具類任務：Copyfile、Shell、介質提交到Nexus倉庫、介質上傳二方庫等。
在每個構建定義上可以選擇若干個需要的構建任務，通過原子步驟編排，組裝成一個完整構建流程。代碼提交時觸發構建（支持gitlab、github、svn等常用代碼庫版本管理工具）、日構建等不同的構建觸發策略等，支撐了持續集成的完整鏈路打通。
自動化部署
針對人保壽險的微服務應用，DevOps定製化了一套持續集成的構建定義。
（1）首先從代碼庫拉取代碼，支持從Git，SVN拉取
（2）接著是構建，可以使用maven、ant、gradle構建，前端支持npm構建
（3）然後通過SonarQube進行代碼的質量檢測，生成質量報告
（4）最後進行編譯介質的發佈，在部署機遠程執行腳本進行介質的發佈
總結
截止到現在，人保壽險的一體化項目、微信項目、大數據項目都已經使用DevOps進行項目的持續集成、持續部署了，每天進行近百次構建，大大提升了工作效率，得到了客戶的一致好評。隨著DevOps的推廣，將來會有更多的項目對DevOps進行使用。 那麼，怎麼才能更好的編排構建流水線？怎麼才能讓DevOps更貼近我們的業務，更好地與分佈式平臺整合？自動化運維的路還很長，而做好DevOps，就是向自動化運維邁進的第一步。
關於作者：李燕鵬，普元研發工程師，曾參與萬達DevOps、國開PaaS容器雲、人保壽險微服務等項目，對雲計算相關技術有濃厚的興趣，熟悉Spring boot, k8s，docker等技術。
關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享
閱讀更多 EAWorld 的文章
