4.4.4  技術架構

4.4.4.1  技術架構定義

        技術架構定義了實現整個系統所需的各種技術，包括開發類、過程管理類、執行環境類、運維支撐類、以及相關技術規範等。

        更確切地說，技術架構描述了在一個可以獨立部署的應用系統裡，應用、應用平臺、基礎設施之間的關係。

        在技術架構設計過程中，通常採用分層設計模式，把應用、平臺、基礎設施相對獨立地拆分為以下幾層：

        1.系統層，也叫基礎設施層，包括系統級的硬體、軟體兩層：

            底層硬體包括主機、各種伺服器、PC、儲存裝置、網路裝置等；

            第二層系統軟體包括各種作業系統、資料庫等；

        2.平臺層，通常包括兩層，也可以混合成一層：

            下層是中介軟體或技術平臺。中介軟體通常指的是廠家在系統層的基礎上提供的平臺軟體，例如IBM的WebSphere、BEA的Tuxedo等；技術平臺通常指的是使用者自己開發的平臺軟體；

            第二層是基於中介軟體之上的開發框架與執行環境生成平臺，包括各種生成環境與工具：如建模工具、視覺化開發工具、第四代開發語言等；

        3.應用層，包含所有的應用，處於整個技術架構框架的最上層。

        針對不同風格的資料架構和應用架構設計，其實現所需的技術棧是不同的。

        正如序言所述，分行特色業務雲平臺是分散式服務架構向微服務架構的演進，使用更細粒度的服務和一組設計準則來實現大規模的、複雜的系統設計，並非一個純粹的微服務架構風格的專案。

        為了專案後期能順利地遷移到微服務架構，此次的軟體開發完全按照微服務架構的標準進行技術標準的制定和技術選型。

        在進行微服務架構設計過程中，主要從以下幾個方面考慮：

 4.4.4.2  技術架構設計原則

4.4.4.2.1  系統執行時原則

        應用或服務在執行時，應該提供如下特徵：

 4.4.4.3  技術架構實踐

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

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.開發、執行環境

        一、WEB前端開發框架

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

        二、服務開發框架 

        後臺服務採用行方自主研發的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.基礎設施：面向運維的一些支援設施，無需額外開發，如統一應用監控中心、配置管理中心、服務註冊中心、異常處理平臺整合等。

        三、中介軟體和技術平臺

        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及以上；

        四、系統軟體平臺

            1.資料庫

                總行：DB2 10及以上；

                分行：根據分行具體情況任選其一：DB2、MySQL、Oracle；

            2.作業系統

                DB2資料庫伺服器：IBM AIX；

                其它伺服器：SUSE Linux；

        五、系統硬體平臺

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

        4.過程管理

        此次主要採用的過程管理工具如下：

            專案構建：Maven；

            版本控制：SVN；

            構件倉庫：Nexus；

            缺陷跟蹤：JIRA；

            程式碼審查：FishEye、Crucible；

            知識管理：Confluence；            

            持續整合、持續交付：Bamboo；

4.4.4.3.2  持續整合、持續交付

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

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

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

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

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

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

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

        持續整合、持續交付的基本流程如下：

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

            3.專人定期稽核提交的程式碼，把控程式碼質量。

            4.程式碼稽核完畢之後，觸發編譯過程，完成程式碼編譯。

            5.編譯完成，進行單元測試。要求每個類都要有單元測試，並且單元測試覆蓋率要達到一定的指標。單元測試要有帶Mock的模組內的整合測試。如果單元測試不通過，則統計後發郵件，抄送所有的人。

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

            7.如果採用私有云，並且使用docker容器，則需要編譯Dockerfile，使用Docker映象作為交付，能夠實現更好的環境一致性，保證原子的升級和回滾。

            8.每天下班前，當天的程式碼需要提交到庫中去，晚上會做一次統一的環境部署和整合測試。這個整合測試或者叫回歸測試每天晚上都做，都是在一個全新的環境中。如果某一天測試不通過，則會發郵件通知。

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

           10.UAT測試通過以後，準備上線到生產環境。建議採用灰度釋出或藍綠髮布機制，分批次釋出、切換流量。一般情況下，具有許可權的管理人員通過自動化指令碼進行部署。

        通過持續整合、持續交付這套完整的流程，層層保證質量，保證專案可以按時按質的完成，減少專案的實施風險。

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

  該系列文章已經在微信公眾號釋出，如果感興趣，請關注。

   以後更多知識通過該微信公眾號分享。