微服務架構設計實踐系列之十：技術架構

分行特點業務雲平臺在實施過程當中，因爲項目進度、技術棧、研發團隊等方面的約束，基礎實施前期採用虛擬服務器集羣，後期遷移到行方私有云，技術棧中的其它部分會根據具體狀況有所微調，但基本不變。所以，在進行技術架構設計過程當中，首先提供一個基於虛擬服務器集羣的整體技術體系，而後再提供一個採用雲部署的部署方案。

4.4.4.3.1 整體技術體系

分行特點業務雲平臺的整體技術體系包括在項目整個生命週期過程當中，軟件開發人員須要遵循的技術規範，所使用的開發工具，開發、運行、運維過程當中的技術、以及貫穿整個軟件生命週期的過程管理工具。

依據微服務架構的關注點，結合行方目標業務量、研發團隊規模、已有技術平臺、開發語言約束（Java）等因素，因此，分行特點業務雲平臺的Java技術棧的技術選型以下：

1.服務框架

 選擇Dubbo做爲分佈式服務框架，Tesla平臺已經集成Dubbo；

 Dubbo提供了高性能和透明化的RPC遠程服務調用方案，以及服務治理方案；

2.運行時支撐服務

 服務註冊中心：採用Zookeeper做爲服務註冊中心；

 服務網關：自主實現API網關，實現通信協議解析，安全認證，流量控制，數據轉換，協議轉換等功能；

 配置中心：自主實現基於DisConf的配置中心；

 負載均衡：基於F5的硬負載，Dubbo提供的軟負載等；

3.服務部署平臺

 支持灰度發佈；

 基於行方私有云的容器調度、租戶資源治理；

 半自動化的服務發佈流程（後面詳細描述）；

4.服務運行平臺

 第一階段基於Linux虛擬機的集羣部署；

 後期遷移到私有云，基於docker容器集羣部署；

5.服務安全

 基於角色的認證受權機制；

 引入數字證書，對通信數據進行簽名、驗籤，保證用戶的身份認證、通信信息的完整性；

 經過數字簽名和數字時間戳，保證業務操做的不可抵賴性；

6.服務容錯

 基於Dubbo實現服務的開關、限流、降級、超時等；

7.服務監控

 基於Logback分級記錄系統運行日誌、業務操做日誌，並按期同步到日誌歸檔平臺；

 經過自定義Spring註解實現服務調用鏈日誌記錄；

 集成到Tesla監控平臺，實現分行特點業務雲平臺運行狀態的監控；

8.後臺服務

 引入ZDAL，實現分佈式數據訪問層，支持分庫分表；

 基於Quartz自主實現自動任務調度；

 自主實現本地內存緩存，採用Redis實現分佈式數據緩存；

綜合以上內容，分行特點業務雲平臺的整體技術體系以下圖所示：

1.開發工具

這次主要採用的開發工具以下：

 IDE:Spring Tool Suite；

 SDK:JDK1.7及以上；

 單元測試：Junit、Mockito；

 集成測試：待定；

 性能測試：JMeter、LoadRunner；

 代碼生成器：自主研發的CodeGenerator；

 業務流程設計器：自主研發的Activit Designer；

2.技術規範

這次涉及的技術規範主要以下：

 平臺開發規範；

 接口設計規範；

 數據庫設計規範；

 統一返回碼規範；

 日誌規範；

 過程管理規範；

 QA規範；

 投產運維規範；

3.開發、運行環境

1、 WEB前端開發框架

WEB前端採用Tesla平臺自主研發的TESLA-UI框架，該框架採用時下比較流行的MVVM設計模式，使用SeaJS進行JavaScript模塊化管理，提供了基於JQuery的UI組件庫和UI皮膚庫，以及基於HTML的佈局模板，適用於企業管理類型前臺頁面的開發。

2、服務開發框架

後臺服務採用行方自主研發的Tesla平臺，該平臺採用「微內核」+「組件」設計，穩定的內核保證系統的健壯性，豐富的組件保證系統的靈活性、擴展性。

TESLA定義了良好的擴展機制和統一的模塊交互機制，可以定製化地爲應用系統提供各類基礎功能，例如：IoC容器、數據訪問、MVC框架、緩存、工做流、服務編排、系統集成、服務治理等等。

TESLA融合了諸多互聯網領域的技術，包括高併發的Web服務端技術（WebX、SpringExt）、服務化架構下的服務治理技術（Dubbo）、大數據量分庫分表技術（ZDAL）、分佈式緩存技術（Redis、Memcached）、高性能數據源鏈接池技術（Druid）、分佈式配置管理技術（Disconf）等等。

另外，TESLA具備應對金融領域業務系統複雜性的能力，在業務快速集成與分佈式事務數據一致性處理上作了不少支持。

TESLA框架分層以下：

1.渠道層：負責接收客戶端發來的請求，不一樣的協議能夠啓用不一樣的渠道，好比有http、webservice、Socket等。

2.業務功能層：抽象業務功能處理的概念，Function表明一個業務功能，Filter是過濾器（能夠設置在不一樣的做用域，好比Function級別，Function組級別，整個應用級別）、Action是Function中執行的每個活動，Context是整個架構的數據載體，PamameterProcesser是參數處理器，用於參數進行校驗和轉換。

3.服務成層：Tesla採用「微內核」+「組件」設計，全部的服務組件都在這一層，都是開發中經常使用的一些基礎功能，好比分頁、緩存、工做流引擎、服務編排引擎、序列號生成器等。

4.集成層：負責和外部系統進行交互，RPC調用、Ftp、消息中間件等，同時歸入到服務治理體系。

5.開發工具集：全棧代碼生成器，服務客戶端代碼生成器、業務流程設計器等。

6.數據訪問層：負責DAO數據庫SQL操做（基於Mybatis）、管理數據庫鏈接池、事務、基於ZDAL進行分庫分表。

7.基礎設施：面向運維的一些支持設施，無需額外開發，如統一應用監控中心、配置管理中心、服務註冊中心、異常處理平臺集成等。

3、中間件和技術平臺

1.應用服務器

 開發環境、單元測試環境：Tomcat7及以上；

 集成測試環境、UAT測試環境、生產環境：Weblogic10；

2.WEB服務器

 開發環境、單元測試環境：Tomcat7及以上；

 集成測試環境、UAT測試環境、生產環境：Apache，Nginx；

3.分佈式數據一致性管理

 Zookeeper;

4.緩存

 Redis

5.容器

 Docker

6.JVM

 開發環境、單元測試環境：Sun Hotspot 1.7及以上；

 集成測試環境、UAT測試環境、生產環境：JRockit 7及以上；

4、系統軟件平臺

1. 數據庫

總行：DB2 10及以上；

分行：根據分行具體狀況任選其一：DB二、MySQL、Oracle；

2. 操做系統

DB2數據庫服務器：IBM AIX；

其它服務器：SUSE Linux；

5、系統硬件平臺

1. 使用行方現有的虛擬化服務器；

4.過程管理

這次主要採用的過程管理工具以下：

 項目構建：Maven；

 版本控制：SVN；

 構件倉庫：Nexus；

 缺陷跟蹤：JIRA；

 代碼審查：FishEye、Crucible；

 知識管理：Confluence；

 持續集成、持續交付：Bamboo；

4.4.4.3.2 持續集成、持續交付

上述章節介紹了分行特點業務雲平臺的整體技術體系，在此，針對貫穿整個項目實施過程，保證項目質量、項目實施進度，減小項目實施風險的軟件過程管理中的持續集成和持續交付的流程進行詳細地說明，以便指導和約束整個軟件實施過程。

正如本文《軟件架構設計思想》章節中描述的，架構的本質就是經過「分「與」合「的手段，對系統進行有序化重構，不斷減小系統無序的程度，使系統不斷進化。

從一個簡單的單體應用到分佈式應用，再到更爲複雜的微服務架構，除了關心如何拆、怎麼拆的問題，還必須關注如何控制拆的風險、如何保證代碼質量、如何保證功能符合用戶需求等。

解決上述問題的手段就是集成，從一開始就集成，而且不斷的集成，反覆的將拆分的子系統、模塊、組件從新組合，看看是否可以順利組合起來，而且保證功能的不變。

實現上述不斷地集成以及成果物交付的過程就是持續集成和持續交付：

1.持續集成：指對代碼的提交，構建，測試的過程，這是一個持續、反覆的過程。

2.持續交付：指將集成好的交付物，例如war、jar或者容器鏡像，部署在聯調環境，或者預發環境的過程。

如下是本項目採用的一個持續集成、持續交付的過程，研發團隊在項目實施過程當中要嚴格遵照：

持續集成、持續交付的基本流程以下：

1. 代碼開發，完成分配的任務。

2. 天天提交代碼，下降代碼集成的風險。採用SVN的提交方式，後提交者有責任去merge，保證代碼的編譯經過和測試經過。

3. 專人按期審覈提交的代碼，把控代碼質量。

4. 代碼審覈完畢以後，觸發編譯過程，完成代碼編譯。

5. 編譯完成，進行單元測試。要求每一個類都要有單元測試，而且單元測試覆蓋率要達到必定的指標。單元測試要有帶Mock的模塊內的集成測試。若是單元測試不經過，則統計後發郵件，抄送全部的人。

6. 單元測試經過之後，上傳成果物（war、jar或其它）至Nexus私服。

7. 若是採用私有云，而且使用docker容器，則須要編譯Dockerfile，使用Docker鏡像做爲交付，可以實現更好的環境一致性，保證原子的升級和回滾。

8. 天天下班前，當天的代碼須要提交到庫中去，晚上會作一次統一的環境部署和集成測試。這個集成測試或者叫回歸測試天天晚上都作，都是在一個全新的環境中。若是某一天測試不經過，則會發郵件通知。

9. 一個週期完畢，進行UAT測試。若是測試不經過，則會發郵件通知，開發人員要及時更正。

10.UAT測試經過之後，準備上線到生產環境。建議採用灰度發佈或藍綠髮布機制，分批次發佈、切換流量。通常狀況下，具備權限的管理人員經過自動化腳本進行部署。

經過持續集成、持續交付這套完整的流程，層層保證質量，保證項目能夠按時按質的完成，減小項目的實施風險。

微信掃一掃，關注該公衆號

該系列文章已經在微信公衆號發佈，若是感興趣，請關注。

之後更多知識經過該微信公衆號分享。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。