分享某國有大型銀行統(tǒng)一開發(fā)平臺的建設歷程，重點介紹其當前正在建設的微服務開發(fā)平臺中的關鍵點和實踐經(jīng)驗。

轉載本文需注明出處：微信公眾號EAWorld。

引言：

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

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

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

目錄：

1、統(tǒng)一開發(fā)平臺建設歷程
2、微服務架構落地的關鍵點
3、基于平臺應用實踐
4、總結

1.統(tǒng)一開發(fā)平臺建設歷程

建設背景

在經(jīng)濟新常態(tài)下，國內(nèi)商業(yè)銀行正面臨持續(xù)加深的市場化改革和互聯(lián)網(wǎng)金融大潮的雙重挑戰(zhàn)。同時，國家日益重視銀行業(yè)信息科技風險防范和管理工作，提出信息系統(tǒng)“安全、可控”的戰(zhàn)略目標。為應對新經(jīng)濟形勢下的新挑戰(zhàn)和“自主、可控”的新任務，銀行業(yè)需要從以下兩方面來提高自身IT建設能力：

第一，在IT管理層面，銀行需要建立統(tǒng)一管控體系，實現(xiàn)項目集中化管理、提升自主掌控能力，降低系統(tǒng)運行和維護風險；
第二，在架構層面，銀行需要統(tǒng)一的技術路線、技術架構和數(shù)據(jù)標準，不斷積累可復用的企業(yè)資產(chǎn)，提升系統(tǒng)快速交付能力。

建設過程

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

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

但是傳統(tǒng)的SOA項目開發(fā)周期長，彈性伸縮能力弱，系統(tǒng)內(nèi)外間耦合程度高，無法從根本架構上滿足銀行向互聯(lián)網(wǎng)銀行轉變的需求。作為銀行自主創(chuàng)新的核心，Java開發(fā)平臺技術架構亟待轉型。所以從2018年起，借助我們的新一代微服務開發(fā)平臺，實現(xiàn)技術架構升級，并引入Devops提升系統(tǒng)開發(fā)運維一體化能力。

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

微服務落地關鍵技術選型

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

其中以
Eureka作為服務注冊中心
SpringBoot作為服務容器
SWAGGER作為在線文檔自動生成+功能測試
Apollo作為配置中心，來提供配置的熱更新功能
使用Vue+IviewUI來支撐前端工程模塊化的開發(fā)
使用Skywaking作為微服務的監(jiān)控

前后端分離明確分工

在開發(fā)方式上，使用前后端分離的開發(fā)模式。在傳統(tǒng)的開發(fā)模式中，開發(fā)人員急需要關注后端邏輯的開發(fā)，還需要關注前端頁面的開發(fā)，開發(fā)職責比較混亂。

前后端分離的開發(fā)模式：前端傾向于呈現(xiàn)，著重處理用戶體驗相關的問題；后端則傾向于業(yè)務邏輯、數(shù)據(jù)處理和持久化等。在設計清晰的情況下，后端只需要以數(shù)據(jù)為中心對業(yè)務處理算法負責，并按約定為前端提供 API 接口；而前端使用這些接口對用戶體驗負責。

與此同時，前端可以根據(jù)用戶不同時期的體驗需求迅速改版，后端對此毫無壓力。同理，后端進行的業(yè)務邏輯升級，數(shù)據(jù)持久方案變更，只要不影響到接口，前端可以毫不知情。

在前后端分離的開發(fā)模式下，前端和后端應該以前端為主導。為什么呢？因為前端開發(fā)人員會受到項目/產(chǎn)品經(jīng)理或客戶的直接影響：這個地方應該放個按鈕，那個操作應該這么進行等等。前端還要與美工對接：這樣的設計不好實現(xiàn)，是否可以改成那樣。客戶要求必須這么操作，但是這個設計做不到，所以前端還要跟后端對接：對于某些應用，甚至是多個后端。因此前端可以成為項目溝通的中心，比后端更合適承擔主導的角色。

高可靠高可用確保服務穩(wěn)定

在微服務架構下，所有的服務均為無狀態(tài)的。所謂的無狀態(tài)是指對單次請求的處理，不依賴其他請求；也就是說，處理一次請求所需的全部信息，要么都包含在這個請求里，要么可以從外部獲取到（比如說數(shù)據(jù)庫），服務器本身不存儲任何信息。使用無狀態(tài)的服務， 服務實例可以進行多節(jié)點的實例的部署。

在我們的微服務架構中所有的服務節(jié)點均使用MM雙節(jié)點配置，并可以進行多節(jié)點擴展，來達到服務的高可用高可靠。

持續(xù)發(fā)布，快速發(fā)布微服務應用

在微服務的架構下，持續(xù)發(fā)布我們面臨的兩大問題：

1、部署流程的多樣性
2、應用會被拆分成多個微服務，部署到多n個節(jié)點。如何做到微服務的持續(xù)發(fā)布，快速響應

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

其次我們通過定義發(fā)布流水線，用戶進行發(fā)布流程編排，直接設置環(huán)境中部署任務（在部署任務中設置具體的組件部署方式，部署配置）、編排環(huán)境的順序等進行自由的持續(xù)發(fā)布。

多策略部署，實現(xiàn)應用快速切換

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

1、滾動升級做灰度發(fā)布，對外接口保持不變
2、藍綠切換，對外接口不變
3、API多版本，對外接口發(fā)生變化

3.基于平臺應用實踐

Yes Or No, 微服務架構的優(yōu)勢與挑戰(zhàn)?

第一個需要思考的問題，就是我該不該采用微服務架構來實施這個項目?；卮鹪摬辉?，首先來看看微服務架構有那些優(yōu)勢，對我提出了哪些要求，我需不需要它的這個優(yōu)勢，又能否解決它的問題。

微服務的優(yōu)勢很明顯，顯著的有以下幾點：

1、微服務業(yè)務功能簡單，功能邊界清晰，易于開發(fā)、理解和維護
2、每個服務可以由專門的開發(fā)團隊開發(fā)，自由選擇技術棧，如數(shù)據(jù)庫、編程語言
3、服務間調(diào)用采用的API接口，只要接口不變，內(nèi)部調(diào)整對其他微服務透明
4、微服務無狀態(tài)部署，通過注冊中心自動發(fā)現(xiàn)，可以新增或者移除服務實例按需彈性伸縮，橫向擴展很容易
5、單個微服務十分輕量，啟停速度很快，且便于持續(xù)自動化部署
6、每個微服務都是獨立部署，技術棧選擇自由，所以可以獨立演進

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

1、開發(fā)測試階段，因為涉及服務依賴，而依賴服務如果沒有就緒，需要編寫Mock或者擋板
2、微服務架構是天生的分布式架構，而分布式有它固有的復雜性，如網(wǎng)絡延遲、分布式事務、容錯等
3、微服務數(shù)量多，分散在眾多節(jié)點上，對他們的運維監(jiān)控成本大幅提升
4、雖然發(fā)布單個微服務很容易，但是一個微服務項目往往包含眾多微服務實例，且服務依賴對服務啟動順序有要求，整個應用的發(fā)布相比單體應用反而要復雜
5、一個業(yè)務請求牽涉多個服務間調(diào)用，出現(xiàn)問題后，如果沒有集中日志收集、調(diào)用鏈路跟蹤，定位問題相比單體應用要困難的多

Yes Or No, 那些系統(tǒng)適合采用微服務架構？

根據(jù)上述微服務架構的優(yōu)點和要求，我們可以知道微服務架構并不是萬能的，有它適合采用的系統(tǒng)，這些系統(tǒng)包括：

1、對于業(yè)務流程較為復雜，且業(yè)務會逐漸變得更加復雜的系統(tǒng)，單體應用將十分龐大，后期難以修改和維護，應考慮使用微服務架構。
2、為了滿足業(yè)務需求，項目中引入了眾多的技術棧，中間件，單體應用會給開發(fā)者帶來很大的困擾，應考慮將應用拆分成多個獨立部署的采用最優(yōu)技術棧實施的微服務。
3、高并發(fā)的，有高可用和彈性伸縮需求的系統(tǒng)，往往是那些面向龐大數(shù)量互聯(lián)網(wǎng)用戶的平臺類、交易類系統(tǒng)，應考慮利用微服務架構便于橫向擴展和彈性伸縮的特性。
4、單體應用版本發(fā)布成本高，而單個微服務的變更和發(fā)布都很容易，那些有高頻率版本發(fā)布需求的系統(tǒng)，應使用微服務架構。
5、沒有數(shù)據(jù)實時強一致要求，可接受數(shù)據(jù)最終一致的系統(tǒng)，可使用微服務架構。

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

經(jīng)過一番比對，這個項目適合采用微服務架構。那么該怎么對項目進行服務拆分呢，拆分到什么粒度為止呢？

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

1、按照業(yè)務拆分

按照業(yè)務來拆分微服務是很自然的，將同類業(yè)務劃歸一個微服務，有利于開發(fā)人員理解需求和開發(fā)（不同的業(yè)務由不同的開發(fā)人員來開發(fā)），同時清晰的功能邊界天生具有高內(nèi)聚的優(yōu)點，避免了微服務間頻繁的遠程調(diào)用，提升了性能和穩(wěn)定性。

2、按照請求數(shù)拆分

某些服務被頻繁調(diào)用，而某些服務很少被調(diào)用，頻繁調(diào)用的服務可考慮與很少被調(diào)用的服務隔離出來獨立部署。

3、常變與不變

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

4、避免過度拆分

如果發(fā)現(xiàn)某些服務頻繁的相互調(diào)用，說明這兩個服務所屬的業(yè)務由很緊密的耦合關系，考慮合并為一個服務。

5、避免分布式事務

如果服務間存在多方更新的情況，即A調(diào)用B，A又調(diào)用C或者B又調(diào)用C，B和C均要更新數(shù)據(jù)庫，且B和C要求同時成功或者同時失敗，則出現(xiàn)了多方更新，應考慮合并B和C。

How,微服務怎么開發(fā)？

微服務劃分完了，是不是可以進入開發(fā)了呢？ 進入開發(fā)前，首先要看一看平臺提供了那些基礎能力，這些是不需要重復去開發(fā)的。
我們目前在這家銀行正在建設的微服務開發(fā)平臺，建設有包括微服務開發(fā)IDE、服務注冊中心、配置中心、API網(wǎng)關、認證鑒權中心、日志中心、管理監(jiān)控中心等基礎服務組件，項目組只需關心自身業(yè)務微服務的開發(fā)。
采用敏捷開發(fā)模式，每個微服務組件開發(fā)由1到2人負責，每日通過持續(xù)集成日構建，快速迭代開發(fā)。
公司客戶營銷項目也是基于微服務開發(fā)平臺進行建設，建設中做了以下約定：
1、前后端分離+Rest通信，前端采用Vue，后端采用Spring Boot，Rest+Json通信；
2、使用平臺提供的API網(wǎng)關統(tǒng)一接入，前后端通信、系統(tǒng)間的服務調(diào)用都要經(jīng)過API網(wǎng)關，網(wǎng)關上做負載、限流、調(diào)用認證鑒權中心服務做用戶身份認證和權限校驗；
3、Rest服務返回的對象統(tǒng)一，包含Http Status狀態(tài)碼和消息體，Service和Ctroller直接拋出業(yè)務異常，業(yè)務異常統(tǒng)一為一種類型的運行時異常，通過Spring MVC的統(tǒng)一異常處理機制，向前端返回狀態(tài)為200包含異常提示信息的結果（之所以返回200，是因為業(yè)務異常屬于用戶輸入導致的，服務正常工作，避免熔斷計數(shù)和降級）；
4、采用JWT+Redis做身份認證和權限校驗，JWT token在HTTP Header中傳遞，Redis中存放注銷后的token，解決用戶注銷后Token未過期的問題。 并且在網(wǎng)關上增加攔截器，對用戶Token做過半刷新；
5、對數(shù)據(jù)庫做了拆分，微服務訪問自己的數(shù)據(jù)庫。 數(shù)據(jù)源配置存在配置中心集中管理，但是不做熱更新，需要微服務重啟后才能生效。

How,微服務怎么測試？

開發(fā)伴隨著測試，沒有經(jīng)過測試的代碼等于是無效代碼。微服務的測試與單體應用不同，前后端、服務間都是Rest接口，如果A服務依賴了服務B，而服務B還沒有開發(fā)完成怎么辦？

公司客戶營銷項目時，微服務之間有依賴關系，為了不受依賴服務的制約，在雙方商定好Rest接口后，由服務提供方開發(fā)Mock服務，供消費方使用， Mock服務同樣注冊到注冊中心。

開發(fā)人員使用Postman自測自己開發(fā)的服務。

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

開發(fā)后期，測試人員利用LoadRunner和Jmeter做壓力測試。

How,微服務怎么發(fā)布？

在該銀行公司客戶營銷項目建設過程中，使用我們的Devops平臺，對微服務做每日構建和自動發(fā)布。

Devops平臺在開發(fā)測試環(huán)境上搭建一套，為不同項目組開通租戶即可使用。Devops持續(xù)集成的技術棧使用的是Jenkins+Maven+Nexus+SonarQube。在Devops前端頁面上創(chuàng)建自動部署計劃，利用Ansible腳本，將打出的部署包自動部署在目標機器上，自動啟動。

前端項目自動發(fā)布在Nginx，后端微服務打包成Fatjar發(fā)布到目標服務器上，利用Spring Boot內(nèi)置容器Tomcat啟動。

#目前這套環(huán)境僅在開發(fā)測試環(huán)境上使用。

How,微服務怎么監(jiān)控？

公司客戶營銷項目利用平臺提供的日志中心（ELK技術棧）做日志集中收集和分析。 平臺自動記錄全局流水號、請求流水號和響應流水號到日志文件，F(xiàn)ilebeat與微服務部署在一起，收集到的日志首先發(fā)送到Kafka集群，Logstash從Kafka獲取日志記錄，經(jīng)過過濾、加工（補充了幾個索引字段，如類型）后發(fā)送到ElasticSearch，最后從Kibana上呈現(xiàn)。

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

對于項目中自定義的一些業(yè)務監(jiān)控，項目組自行組裝消息發(fā)送到ＭＱ，利用該銀行自有的業(yè)務監(jiān)控平臺，集中展示。

4.總結

微服務架構是當前互聯(lián)網(wǎng)公司普遍采用的技術架構，且正在快速地延伸到互聯(lián)網(wǎng)金融行業(yè)。微服務架構技術優(yōu)勢明顯，但技術門檻較高，我們的新一代微服務開發(fā)平臺整合一系列優(yōu)秀開源技術，形成一套微服務架構落地的最佳實踐，幫助某銀行安全快速地實現(xiàn)了技術架構的一次轉型升級。