微服務架構轉型升級

時間 2019-11-17

原文原文鏈接

轉基於統一開發平臺的微服務架構轉型升級之路 | 某國有大型銀行案例

原創：田健 EAWorld 1周前

引言：前端

某銀行是一家國有大型銀行，從2016年開始採用了咱們的SOA開發平臺做爲基礎Java開發平臺。web

2018年，咱們發佈了新一代微服務開發平臺EOS Platform 8，而其正在謀求技術架構轉型升級，正好藉助咱們的新一代微服務開發平臺，對已有的SOA架構技術平臺進行升級。算法

做爲該銀行Java開發平臺項目的架構師，本文我爲你們分享其統一開發平臺技術架構轉型升級的歷程，並結合銀行重點項目——公司客戶營銷系統的案例，向你們講述微服務項目建設的一些實踐經驗，但願給正在或即將進行微服務架構轉型的企業獲得一些啓發。數據庫

目錄：編程

一、統一開發平臺建設歷程
後端

二、微服務架構落地的關鍵點安全

三、基於平臺應用實踐服務器

四、總結網絡

1.統一開發平臺建設歷程

建設背景
架構

在經濟新常態下，國內商業銀行正面臨持續加深的市場化改革和互聯網金融大潮的雙重挑戰。同時，國家日益重視銀行業信息科技風險防範和管理工做，提出信息系統「安全、可控」的戰略目標。爲應對新經濟形勢下的新挑戰和「自主、可控」的新任務，銀行業須要從如下兩方面來提升自身IT建設能力：

第一，在IT管理層面，銀行須要創建統一管控體系，實現項目集中化管理、提高自主掌控能力，下降系統運行和維護風險；

第二，在架構層面，銀行須要統一的技術路線、技術架構和數據標準，不斷積累可複用的企業資產，提高系統快速交付能力。

建設過程

該銀行在自主創新上起步很早，長期以來一直堅持走國產化和開源軟件的道路。

該銀行自2016年開始圍繞普元EOS+BPS+BIIP進行SOA架構Java開發平臺建設；2017年初發布Java開發平臺1.0版本，截止到2018年，已經由40多個系統基於Java開發平臺建設和上線運行； 2017~2018年，圍繞Java開發平臺，建設開發運維標準規範、技術可研標準規範、開源技術選型標準規範、培訓及考試認證體系。

可是傳統的SOA項目開發週期長，彈性伸縮能力弱，系統內外間耦合程度高，沒法從根本架構上知足銀行向互聯網銀行轉變的需求。做爲銀行自主創新的核心，Java開發平臺技術架構亟待轉型。因此從2018年起，藉助咱們的新一代微服務開發平臺，實現技術架構升級，並引入Devops提高系統開發運維一體化能力。

2.微服務架構落地的關鍵點

微服務落地關鍵技術選型

在當前市面上存在多個流行的微服務框架，要在框架中選擇一款適合本身的微服務框架。在普元，經過對多個微服務框架進行比較，最終選擇了SpringCloud做爲基礎的微服務框架。

其中以

Eureka做爲服務註冊中心
SpringBoot做爲服務容器
SWAGGER做爲在線文檔自動生成+功能測試
Apollo做爲配置中心，來提供配置的熱更新功能
使用Vue+IviewUI來支撐前端工程模塊化的開發
使用Skywaking做爲微服務的監控

先後端分離明確分工

在開發方式上，使用先後端分離的開發模式。在傳統的開發模式中，開發人員極須要關注後端邏輯的開發，還須要關注前端頁面的開發，開發職責比較混亂。

先後端分離的開發模式：前端傾向於呈現，着重處理用戶體驗相關的問題；後端則傾向於業務邏輯、數據處理和持久化等。在設計清晰的狀況下，後端只須要以數據爲中心對業務處理算法負責，並按約定爲前端提供 API 接口；而前端使用這些接口對用戶體驗負責。

與此同時，前端能夠根據用戶不一樣時期的體驗需求迅速改版，後端對此毫無壓力。同理，後端進行的業務邏輯升級，數據持久方案變動，只要不影響到接口，前端能夠絕不知情。

在先後端分離的開發模式下，前端和後端應該之前端爲主導。爲何呢？由於前端開發人員會受到項目/產品經理或客戶的直接影響：這個地方應該放個按鈕，那個操做應該這麼進行等等。前端還要與美工對接：這樣的設計很差實現，是否能夠改爲那樣。客戶要求必須這麼操做，可是這個設計作不到，因此前端還要跟後端對接：對於某些應用，甚至是多個後端。所以前端能夠成爲項目溝通的中心，比後端更合適承擔主導的角色。

高可靠高可用確保服務穩定

在微服務架構下，全部的服務均爲無狀態的。所謂的無狀態是指對單次請求的處理，不依賴其餘請求；也就是說，處理一次請求所需的所有信息，要麼都包含在這個請求裏，要麼能夠從外部獲取到（好比說數據庫），服務器自己不存儲任何信息。使用無狀態的服務，服務實例能夠進行多節點的實例的部署。

在咱們的微服務架構中全部的服務節點均使用MM雙節點配置，並能夠進行多節點擴展，來達到服務的高可用高可靠。

持續發佈，快速發佈微服務應用

在微服務的架構下，持續發佈咱們面臨的兩大問題：

一、部署流程的多樣性

二、應用會被拆分紅多個微服務，部署到多n個節點。如何作到微服務的持續發佈，快速響應

首先咱們將任務進行原子化（如：組件的編譯、打包、數據初始化、部署等每一項定義爲一個任務），這些任務可進行任意的編排。

其次咱們經過定義發佈流水線，用戶進行發佈流程編排，直接設置環境中部署任務（在部署任務中設置具體的組件部署方式，部署配置）、編排環境的順序等進行自由的持續發佈。

多策略部署，實現應用快速切換

針對微服務應用的快速切換，咱們提供多策略的部署方式：

一、滾動升級作灰度發佈，對外接口保持不變

二、藍綠切換，對外接口不變

三、API多版本，對外接口發生變化

3.基於平臺應用實踐

Yes Or No, 微服務架構的優點與挑戰?

第一個須要思考的問題，就是我該不應採用微服務架構來實施這個項目。回答該不應，首先來看看微服務架構有那些優點，對我提出了哪些要求，我需不須要它的這個優點，又可否解決它的問題。

微服務的優點很明顯，顯著的有如下幾點：

一、微服務業務功能簡單，功能邊界清晰，易於開發、理解和維護

二、每一個服務能夠由專門的開發團隊開發，自由選擇技術棧，如數據庫、編程語言

三、服務間調用採用的API接口，只要接口不變，內部調整對其餘微服務透明

四、微服務無狀態部署，經過註冊中心自動發現，能夠新增或者移除服務實例按需彈性伸縮，橫向擴展很容易

五、單個微服務十分輕量，啓停速度很快，且便於持續自動化部署

六、每一個微服務都是獨立部署，技術棧選擇自由，因此能夠獨立演進

但一樣的它也給項目實施和運維人員提出了更高了要求：

一、開發測試階段，由於涉及服務依賴，而依賴服務若是沒有就緒，須要編寫Mock或者擋板

二、微服務架構是天生的分佈式架構，而分佈式有它固有的複雜性，如網絡延遲、分佈式事務、容錯等

三、微服務數量多，分散在衆多節點上，對他們的運維監控成本大幅提高

四、雖然發佈單個微服務很容易，可是一個微服務項目每每包含衆多微服務實例，且服務依賴對服務啓動順序有要求，整個應用的發佈相比單體應用反而要複雜

五、一個業務請求牽涉多個服務間調用，出現問題後，若是沒有集中日誌收集、調用鏈路跟蹤，定位問題相比單體應用要困難的多

Yes Or No, 那些系統適合採用微服務架構？

根據上述微服務架構的優勢和要求，咱們能夠知道微服務架構並非萬能的，有它適合採用的系統，這些系統包括：

一、對於業務流程較爲複雜，且業務會逐漸變得更加複雜的系統，單體應用將十分龐大，後期難以修改和維護，應考慮使用微服務架構。

二、爲了知足業務需求，項目中引入了衆多的技術棧，中間件，單體應用會給開發者帶來很大的困擾，應考慮將應用拆分紅多個獨立部署的採用最優技術棧實施的微服務。

三、高併發的，有高可用和彈性伸縮需求的系統，每每是那些面向龐大數量互聯網用戶的平臺類、交易類系統，應考慮利用微服務架構便於橫向擴展和彈性伸縮的特性。

四、單體應用版本發佈成本高，而單個微服務的變動和發佈都很容易，那些有高頻率版本發佈需求的系統，應使用微服務架構。

五、沒有數據實時強一致要求，可接受數據最終一致的系統，可以使用微服務架構。

How,單體到微服務怎麼拆？

通過一番比對，這個項目適合採用微服務架構。那麼該怎麼對項目進行服務拆分呢，拆分到什麼粒度爲止呢？

18年初，某銀行使用微服務開發平臺建設公司客戶營銷項目，首先面臨的問題就是微服務如何拆分，結合咱們的經驗，提出瞭如下5個拆分原則：

一、按照業務拆分

按照業務來拆分微服務是很天然的，將同類業務劃歸一個微服務，有利於開發人員理解需求和開發（不一樣的業務由不一樣的開發人員來開發），同時清晰的功能邊界天生具備高內聚的優勢，避免了微服務間頻繁的遠程調用，提高了性能和穩定性。

二、按照請求數拆分

某些服務被頻繁調用，而某些服務不多被調用，頻繁調用的服務可考慮與不多被調用的服務隔離出來獨立部署。

三、常變與不變

某些服務可能很頻繁的因需求的變動而頻繁發佈新版本和上線，爲避免影響那些不變的服務，這些頻繁變化的服務應當隔離出來獨立部署。

四、避免過分拆分

若是發現某些服務頻繁的相互調用，說明這兩個服務所屬的業務由很緊密的耦合關係，考慮合併爲一個服務。

五、避免分佈式事務

若是服務間存在多方更新的狀況，即A調用B，A又調用C或者B又調用C，B和C均要更新數據庫，且B和C要求同時成功或者同時失敗，則出現了多方更新，應考慮合併B和C。

How,微服務怎麼開發？

微服務劃分完了，是否是能夠進入開發了呢？進入開發前，首先要看一看平臺提供了那些基礎能力，這些是不須要重複去開發的。

咱們目前在這家銀行正在建設的微服務開發平臺，建設有包括微服務開發IDE、服務註冊中心、配置中心、API網關、認證鑑權中心、日誌中心、管理監控中心等基礎服務組件，項目組只需關心自身業務微服務的開發。

採用敏捷開發模式，每一個微服務組件開發由1到2人負責，每日經過持續集成日構建，快速迭代開發。

公司客戶營銷項目也是基於微服務開發平臺進行建設，建設中作了如下約定：

一、先後端分離+Rest通訊，前端採用Vue，後端採用Spring Boot，Rest+Json通訊；

二、使用平臺提供的API網關統一接入，先後端通訊、系統間的服務調用都要通過API網關，網關上作負載、限流、調用認證鑑權中心服務作用戶身份認證和權限校驗；

三、Rest服務返回的對象統一，包含Http Status狀態碼和消息體，Service和Ctroller直接拋出業務異常，業務異常統一爲一種類型的運行時異常，經過Spring MVC的統一異常處理機制，向前端返回狀態爲200包含異常提示信息的結果（之因此返回200，是由於業務異常屬於用戶輸入致使的，服務正常工做，避免熔斷計數和降級）；

四、採用JWT+Redis作身份認證和權限校驗，JWT token在HTTP Header中傳遞，Redis中存放註銷後的token，解決用戶註銷後Token未過時的問題。而且在網關上增長攔截器，對用戶Token作過半刷新；

五、對數據庫作了拆分，微服務訪問本身的數據庫。數據源配置存在配置中心集中管理，可是不作熱更新，須要微服務重啓後才能生效。

How,微服務怎麼測試？

開發伴隨着測試，沒有通過測試的代碼等因而無效代碼。微服務的測試與單體應用不一樣，先後端、服務間都是Rest接口，若是A服務依賴了服務B，而服務B尚未開發完成怎麼辦？

公司客戶營銷項目時，微服務之間有依賴關係，爲了避免受依賴服務的制約，在雙方商定好Rest接口後，由服務提供方開發Mock服務，供消費方使用， Mock服務一樣註冊到註冊中心。

開發人員使用Postman自測本身開發的服務。

版本發佈人員專人負責每日構建，利用Jekins+Maven+SonaQube自動執行單元測試和代碼檢查。

開發後期，測試人員利用LoadRunner和Jmeter作壓力測試。

How,微服務怎麼發佈？

在該銀行公司客戶營銷項目建設過程當中，使用咱們的Devops平臺，對微服務作每日構建和自動發佈。

Devops平臺在開發測試環境上搭建一套，爲不一樣項目組開通租戶便可使用。Devops持續集成的技術棧使用的是Jenkins+Maven+Nexus+SonarQube。在Devops前端頁面上建立自動部署計劃，利用Ansible腳本，將打出的部署包自動部署在目標機器上，自動啓動。

前端項目自動發佈在Nginx，後端微服務打包成Fatjar發佈到目標服務器上，利用Spring Boot內置容器Tomcat啓動。

#目前這套環境僅在開發測試環境上使用。

How,微服務怎麼監控？

公司客戶營銷項目利用平臺提供的日誌中心（ELK技術棧）作日誌集中收集和分析。平臺自動記錄全局流水號、請求流水號和響應流水號到日誌文件，Filebeat與微服務部署在一塊兒，收集到的日誌首先發送到Kafka集羣，Logstash從Kafka獲取日誌記錄，通過過濾、加工（補充了幾個索引字段，如類型）後發送到ElasticSearch，最後從Kibana上呈現。

採用開源軟件Skywalking實現微服務調用鏈路跟蹤、服務進程JVM、線程和負載的監控。平臺提供了管理監控頁面，從ElasticSearch中獲取監控信息，在Governor頁面呈現。

對於項目中自定義的一些業務監控，項目組自行組裝消息發送到ＭＱ，利用該銀行自有的業務監控平臺，集中展現。

4.總結

微服務架構是當前互聯網公司廣泛採用的技術架構，且正在快速地延伸到互聯網金融行業。微服務架構技術優點明顯，但技術門檻較高，咱們的新一代微服務開發平臺整合一系列優秀開源技術，造成一套微服務架構落地的最佳實踐，幫助某銀行安全快速地實現了技術架構的一次轉型升級。

精選提問：

問1：Eureka不更新了，爲何還選這個？

答：Eureka 用的是1.x版本，2.x的版本再也不開源，可是咱們目前不須要他。

問2：選擇Skywalking有作過選型評估嗎？

答：Skywalking與Pinpoint作過技術選型，在功能上Skywalking更強，好比Skywalking能夠作到方法級的調用鏈路跟蹤，Pinpoint只能作到系統級。

問3：Devops平臺與技術開發平臺是如何有機結合的？

答：DevOps平臺與技術開發平臺並無直接的關聯關係。技術開發平臺更多關注的是開發階段，而DevOps是關注整個軟件生命週期。DevOps平臺可使用技術開發平臺的相關資源（好比使用源代碼、相關文檔等），將這些成果進行後續操做（好比源代碼的的編譯打包，進行持續發佈等等）。

問4：不要logstash直接用Filebeat能夠嗎？