引言：
某銀行是一家國有大型銀行，從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.總結
微服務架構是當前互聯網公司普遍采用的技術架構，且正在快速地延伸到互聯網金融行業。微服務架構技術優勢明顯，但技術門檻較高，我們的新一代微服務開發平臺整合一系列優秀開源技術，形成一套微服務架構落地的最佳實踐，幫助某銀行安全快速地實現了技術架構的一次轉型升級。
精選提問：
問1：****Eureka不更新了，為什么還選這個？
答：Eureka 用的是1.x版本，2.x的版本不再開源，但是我們目前不需要他。
問2：****選擇Skywalking有做過選型評估嗎？
答：Skywalking與Pinpoint做過技術選型，在功能上Skywalking更強，比如Skywalking可以做到方法級的調用鏈路跟蹤，Pinpoint只能做到系統級。
問3：****Devops平臺與技術開發平臺是如何有機結合的？
答：DevOps平臺與技術開發平臺并沒有直接的關聯關系。技術開發平臺更多關注的是開發階段，而DevOps是關注整個軟件生命周期。DevOps平臺可以使用技術開發平臺的相關資源（比如使用源代碼、相關文檔等），將這些成果進行后續操作（比如源代碼的的編譯打包，進行持續發布等等）。
問4：****不要logstash直接用Filebeat可以嗎？
答：用Logstash是為了使用Logstash上豐富的插件，沒有日志過濾需求的話，可以不使用。
問5：日志的索引和調用鏈監控的traceid是怎么關聯的？
答：目前全局流水號記錄在了日志里，業務調用鏈路里的所有微服務的日志統一發往同一個MQ隊列，由Logstash生成索引日志名。
