轉載本文需註明出處：EAWorld，違者必究。
 

引言：

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

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

作為該銀行Java開發平臺專案的架構師，本文我為大家分享其統一開發平臺技術架構轉型升級的歷程，並結合銀行重點專案——公司客戶營銷系統的案例，向大家講述微服務專案建設的一些實踐經驗，希望給正在或即將進行微服務架構轉型的企業得到一些啟發。
 

目錄：

1、統一開發平臺建設歷程
2、微服務架構落地的關鍵點
3、基於平臺應用實踐
4、總結
 

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雙節點配置，並可以進行多節點擴充套件，來達到服務的高可用高可靠。
 

持續釋出，快速釋出微服務應用

在微服務的架構下，持續釋出我們面臨的兩大問題：

1、部署流程的多樣性
2、應用會被拆分成多個微服務，部署到多n個節點。如何做到微服務的持續釋出，快速響應

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

其次我們通過定義釋出流水線，使用者進行釋出流程編排，直接設定環境中部署任務（在部署任務中設定具體的元件部署方式，部署配置）、編排環境的順序等進行自由的持續釋出。
 

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

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

1、滾動升級做灰度釋出，對外介面保持不變
2、藍綠切換，對外介面不變
3、API多版本，對外介面發生變化
 

3.基於平臺應用實踐

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

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

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

1、微服務業務功能簡單，功能邊界清晰，易於開發、理解和維護
2、每個服務可以由專門的開發團隊開發，自由選擇技術棧，如資料庫、程式語言
3、服務間呼叫採用的API介面，只要介面不變，內部調整對其他微服務透明
4、微服務無狀態部署，通過註冊中心自動發現，可以新增或者移除服務例項按需彈性伸縮，橫向擴充套件很容易
5、單個微服務十分輕量，啟停速度很快，且便於持續自動化部署
6、每個微服務都是獨立部署，技術棧選擇自由，所以可以獨立演進

但同樣的它也給專案實施和運維人員提出了更高了要求：

1、開發測試階段，因為涉及服務依賴，而依賴服務如果沒有就緒，需要編寫Mock或者擋板
2、微服務架構是天生的分散式架構，而分散式有它固有的複雜性，如網路延遲、分散式事務、容錯等
3、微服務數量多，分散在眾多節點上，對他們的運維監控成本大幅提升
4、雖然釋出單個微服務很容易，但是一個微服務專案往往包含眾多微服務例項，且服務依賴對服務啟動順序有要求，整個應用的釋出相比單體應用反而要複雜
5、一個業務請求牽涉多個服務間呼叫，出現問題後，如果沒有集中日誌收集、呼叫鏈路跟蹤，定位問題相比單體應用要困難的多
 

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

根據上述微服務架構的優點和要求，我們可以知道微服務架構並不是萬能的，有它適合採用的系統，這些系統包括：

1、對於業務流程較為複雜，且業務會逐漸變得更加複雜的系統，單體應用將十分龐大，後期難以修改和維護，應考慮使用微服務架構。
2、為了滿足業務需求，專案中引入了眾多的技術棧，中介軟體，單體應用會給開發者帶來很大的困擾，應考慮將應用拆分成多個獨立部署的採用最優技術棧實施的微服務。
3、高併發的，有高可用和彈性伸縮需求的系統，往往是那些面向龐大數量網際網路使用者的平臺類、交易類系統，應考慮利用微服務架構便於橫向擴充套件和彈性伸縮的特性。
4、單體應用版本釋出成本高，而單個微服務的變更和釋出都很容易，那些有高頻率版本釋出需求的系統，應使用微服務架構。
5、沒有資料實時強一致要求，可接受資料最終一致的系統，可使用微服務架構。
 

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

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

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

1、按照業務拆分

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

2、按照請求數拆分

某些服務被頻繁呼叫，而某些服務很少被呼叫，頻繁呼叫的服務可考慮與很少被呼叫的服務隔離出來獨立部署。

3、常變與不變

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

4、避免過度拆分

如果發現某些服務頻繁的相互呼叫，說明這兩個服務所屬的業務由很緊密的耦合關係，考慮合併為一個服務。

5、避免分散式事務

如果服務間存在多方更新的情況，即A呼叫B，A又呼叫C或者B又呼叫C，B和C均要更新資料庫，且B和C要求同時成功或者同時失敗，則出現了多方更新，應考慮合併B和C。
 

How,微服務怎麼開發？

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

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

採用敏捷開發模式，每個微服務元件開發由1到2人負責，每日通過持續整合日構建，快速迭代開發。

公司客戶營銷專案也是基於微服務開發平臺進行建設，建設中做了以下約定：

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

2、使用平臺提供的API閘道器統一接入，前後端通訊、系統間的服務呼叫都要經過API閘道器，閘道器上做負載、限流、呼叫認證鑑權中心服務做使用者身份認證和許可權校驗；

3、Rest服務返回的物件統一，包含Http Status狀態碼和訊息體，Service和Ctroller直接丟擲業務異常，業務異常統一為一種型別的執行時異常，通過Spring MVC的統一異常處理機制，向前端返回狀態為200包含異常提示資訊的結果（之所以返回200，是因為業務異常屬於使用者輸入導致的，服務正常工作，避免熔斷計數和降級）；

4、採用JWT+Redis做身份認證和許可權校驗，JWT token在HTTP Header中傳遞，Redis中存放登出後的token，解決使用者登出後Token未過期的問題。 並且在閘道器上增加攔截器，對使用者Token做過半重新整理；

5、對資料庫做了拆分，微服務訪問自己的資料庫。 資料來源配置存在配置中心集中管理，但是不做熱更新，需要微服務重啟後才能生效。
 

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.總結

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



關於作者：田健，現任普元架構師，長期致力於IT技術研究、產品設計與開發、架構諮詢等工作，先後主導北京銀行資料治理平臺、國家開發銀行分散式服務框架、郵儲銀行統一開發平臺等專案的設計和開發工作。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享