java分佈式技術平臺架構方案

1. CoolJava技術特點

   CoolJava的技術解決方案信息系統的穩定性、技術先進性、可拓展性，並且滿足未來繼續增長、業務變革、監管加強的潛在需求。追求系統快速開發迭代，CoolJava應用開發框架能3倍以上速度，完成系統開發。系統平臺具有較大的靈活調整空間，當有新的主數據類型、新的數據需求、新的數據結構、新的數據接口及流程等需求時，整體系統架構不需要重新構建，通過可擴展的架構方式即可滿足功能變化，前端數據錄入可根據數據模型自動構建信息錄入頁面，後端數據輸出靈活方便，與其它系統之間的接口易於修改和維護。

CoolJava系統平臺採用先進的分佈式微服務架構實現，利用容器化技術在實現集中部署，提供穩定、高效、靈活可擴展的高可用服務。

1. 技術架構

CoolJava系統平臺採用先進的、與主流互聯網公司相一致的分佈式技術架構，以微服務架構爲核心，整合關係型數據庫、NoSQL 數據庫、非結構化存儲等數據存儲方式，整合負載均衡、服務發現、動態路由等服務接入方式，整合桌面、瀏覽器、移動等多終端交互方式，提供穩定、獨立、高效、靈活可擴展的系統服務。分佈式技術架構將傳統的應用層重構爲基礎服務層、業務服務層和接入層，新增大數據服務、微服務管理服務、智能服務、併發控制服務、數據服務等基礎服務。CoolJava平臺的系統邏輯架構主要包括存儲層、業務服務層、接入層、等。如下圖所示：

系統總體功能架構分爲集成層、數據層、服務層、交互層。集成層提供與下游系統相關的數據接收、發送、監控等功能。

分佈式技術架構的主要特點包括：分佈式服務架構、分佈式存儲架構。分佈式服務架構主要通過基礎服務層、業務服務層、接入層實現，分佈式存儲架構主要通過基礎服務層的數據服務、存儲層實現，通過智能運維滿足自動化部署、可視化運維，通過敏捷交付實現 DevOps 功能支持開發、測試、部署工作的流程化和自動化同時提供持續集成，用戶單點登錄通過用戶層實現。

2.1分佈式服務架構

 

CoolJava系統平臺的分佈式服務架構主要包括微服務架構、容器化部署、異步消息、統一緩存服務等四個方面。

通過採用微服務架構使CoolJava系統平臺的應用利用 Docker  容器實現最佳部署。在容器化部署基礎上，通過 Kubernetes 根據容器的 CPU、內存等指標對系統自動進行擴縮，從而實現根據資源使用情況動態調整的應用資源調度架構。微服務間調用通過 Kafaka異步消息服務實現異步調用機制，基於 Redis 的分佈式緩存服務實現統一緩存管理。

2.1.1微服務架構

微服務作爲系統架構的一種設計風格是目前最先進、主流的系統架構，其主旨要求每個微服務實現一項或一些耦合度較高的業務功能，各微服務之間通過協作完成完整的業務流程。

CoolJava系統平臺的微服務基於 Spring Boot + Spring Cloud 框架構建，通過Eureka 實現微服務的自動註冊與發現。CoolJava系統平臺微服務構建的基本原則： 圍繞系統的某一項或一些耦合度較高的服務功能進行構建，每個服務都維護着自身的數據存儲、業務開發、自動化測試案例以及獨立部署機制。

由於微服務之間通過基於 HTTP 的 RESTful API 進行通信協作，數據傳輸採用 JSON 格式，所以微服務架構使CoolJava系統平臺具有良好的兼容性、靈活性、擴展性，支持快速使用新技術構建新的微服務。微服務架構相比傳統單體架構還具有錯誤隔離性的優勢，當某項微服務出現故障時不會影響整個系統的正常運行。

2.1.2容器化部署

CoolJava系統平臺在採用微服務架構的基礎上，通過 Docker、kubernetes  等實現CoolJava系統平臺微服務的容器化部署，根據各微服務的資源（CPU、內存等） 使用情況對運行容器進行彈性伸縮，實現微服務資源佔用的動態調配以及微服務器資源的合理分配。

 

CoolJava系統平臺在進行容器化部署的基礎上採用 Ingress 實現高可用負載均衡架構，爲每項微服務構建指定的負載環境，每個負載實現主備之間自動切換以實現負載高可用。

2.1.3異步消息

CoolJava系統平臺採用 Kafaka 等實現異步消息總線，微服務之間通過異步消息總線進行異步消息調用，通過微服務之間的異步消息機制實現應用解耦、流量削峯以及靈活擴展。

 

 

2.1.4統一緩存服務

CoolJava系統平臺採用 Redis集羣實現高可用分佈式緩存服務，根據業務需求與系統監控情況，通過動態啓用模型緩存、元數據緩存、主數據緩存、流程數據緩存， 系統會根據數據特點及緩存要求，確定緩存的方式與自動刷新的週期。

2.2分佈式存儲架構

CoolJava採用的分佈式存儲架構主要  有以下特點：

1. 擴展性和高性能：

Scale-Out 架構允許通過簡單地增加資源來提高存儲容量和性能，磁盤、計算和 I/O 資源都可以獨立增加，支持 10GbE 和 InfiniBand 等高速網絡互聯。彈性哈希（ElasticHash）解除了對元數據服務器的需求，消除了單點故障和性能瓶頸，真正實現了並行化數據訪問。

1. 高可用性

對文件進行自動複製，如鏡像或多次複製，從而確保數據總是可以訪問，甚至是在硬件故障的情況下也能正常訪問。自我修復功能能夠把數據恢復到正確的狀態，而且修復是以增量的方式在後臺執行，幾乎不會產生性能負載。並且採用操作系統中主流標準的磁盤文件系統（如 XFS）來存儲文件，因此數據可以使用各種標準工具進行復制和訪問。

1. 彈性卷管理

據儲存在邏輯卷中，邏輯卷可以從虛擬化的物理存儲池進行獨立邏輯劃分而得到。存儲服務器可以在線進行增加和移除，不會導致應用中斷。邏輯卷可以在所有配置服務器中增長和縮減，可以在不同服務器遷移進行容量均衡，或者增加和移除系統。

2.3技術框架

CoolJava技術方案以 Spring  Cloud 爲核心技術框架。Spring  Cloud 是目前業內比較成熟的、比較先進、應用最廣的微服務架構解決方案之一。具有多領域、跨行業、廣泛的成功案例，豐富的社區支持和開發人員。Spring  Cloud 的核心特性包括：分佈式/版本化配置、服務註冊和發現、路由、服務和服務之間的調、負載均衡、斷路器、分佈式消息傳遞等。

相對其它框架，它具有以下優勢：

• Spring Cloud 來源於 Spring，質量、穩定性、持續性都有充分保障

• Spirng Cloud 天然支持 Spring Boot，更加便於業務落地

• Spring Cloud 發展迅速，擁有大量的社區、技術支持

• Spring Cloud 對微服務周邊環境的支持力度最大Spring Cloud 是由多個組件構成的，其主要架構如下：

 

 

• Eureka

     Eureka 是 Spring Cloud 的最重要核心組件，負責服務的注與發現，提供了完整的Service Registry 和Service Discovery 實現。所有可以提供的服務都通過 Eureka 進行註冊和管理，方便後續的水平擴展、故障轉移等。同時 Eureka 提供均衡負載的功能和心跳檢測機制。

• Hystrix

在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致      “服務消費者”的不可用,並將不可用逐漸放大的過程。 在這種情況下就需要整個服務機構具有故障隔離的功能，避免某一個服務掛掉影響全局，即 Spring Cloud 中 Hystrix 組件。Hystrix 負責監控服務之間的調用情況，連續多次失敗進行熔斷保護。

• Hystrix dashboard,Turbine

負責監控 Hystrix 的熔斷情況，並給予圖形化的展示。

Hystrix-dashboard 是一款針對 Hystrix 進行實時監控的工具， 通 過 Hystrix Dashboard 我 們 可 以 直 觀 地 看 到 各 Hystrix Command 的請求響應時間, 請求成功率等數據。

Turbine 負責彙總系統內多個服務的數據並通過 Hystrix Dashboard 顯示。

• Spring Cloud Config

Spring Cloud Config 是一個解決分佈式系統的配置管理方案, 提供統一的配置中心服務，解決了隨着微服務增多引起的配置文件混亂。它包含了 Client 和 Server 兩個部分，Server 提供配置文件的存儲、以接口的形式將配置文件的內容提供出去，Client 通過接口獲取數據、並依據此數據初始化自己的應用。

• Spring Cloud Bus

Spring Cloud Bus 是輕量級的通訊組件,通過輕量消息代理連接各個分佈的節點，廣播狀態的變化（例如配置變化）或者其它的消息指令。當配置文件發生變化的時候，通知各服務去獲取最新的配置信息。

• 網關服務

在微服務架構模式下，後端服務的實例數一般是動態的，對於客戶端而言很難發現動態改變的服務實例的訪問地址信息。因此在基於微服務的項目中爲了簡化前端的調用邏輯，通常會引入API Gateway 作爲輕量級網關，同時 API Gateway 中也會實現相關的認證邏輯從而簡化內部服務之間相互調用的複雜度。Zuul 是 Spring Cloud 框架中 API Gateway 的落地實現，負責轉發所有對外的請求和服務， 起到 API 網關的作用。

• 鏈路追蹤、日誌服務

隨着服務的增多，調用鏈路的深度和廣度都會成倍增加。對調用鏈的分析工作也就越發複雜。在 Spring Cloud 架構下，我們通過Sleuth+Zipkin 進行鏈路監控，記錄所有的請求數據，方便我們進行後續分析。

2.4部署架構

2.4.1邏輯架構

CoolJava系統平臺採用雲環境發佈，且綜合考慮本項目所覆蓋業務重要性程度， 要求整個系統在設計過程中必須保證較高的可用性，以保證重要應用具有較高的業務連續性。在系統物理架構的設計時需要遵循以下原則：

 

 

系統工具：

  定時任務、可視化報表、通用時間字符串處理、mapper文件自動加載，連接池監視、接口API，單元測試。

 

 

 

中間件：

  消息隊列kafa/zookeeper，分佈式redis緩存。

集成異步消息處理中間件：Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它可以處理消費者在網站中的所有動作流數據。 這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網絡上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行加載機制來統一線上和離線的消息處理，也是爲了通過集羣來提供實時的消息。

 

2.5.3框架亮點

• 硬件設備的高可用性。建議在整個系統中，要求所有重要設備的關鍵部件必須具有冗餘設計。主要包括硬件設備的電源、風扇模塊，存儲設備的控制器、緩存模塊，磁盤陣列中的磁盤鏡像等。
• 系統關鍵服務器的高可用性。系統關鍵服務器採用雙機設置的建設方式。在雙機模式下，當一臺服務器出現問題時，另一臺服務器可以在極短時間內接管原服務器工作負載，保證業務不會因硬件設備故障中斷。
• 數據庫系統的高可用性。關鍵數據庫系統應採用實時應用集羣技術，在提升系統可用性的同時實現數據庫系統的負載均衡效果。
• 系統及設備擴容能力。系統架構設計需考慮未來業務增長的潛在需求，在進行整體架構設計和關鍵設備選擇時，一方面需要爲業務發展留出一定的餘量，另一方面需要所選設備和系統系統架構應具有良好的平滑擴展能力。
• 備份系統設計。系統建設過程中，必須考慮由於人爲或不可抗因素而造成的系統損傷、數據丟失情況。爲降低因數據丟失所造成的損失，在系統架構設計時同步考慮備份系統設計。
•  

• 2.4.2物理架構

  應用服務器間通過本地交換機互聯形成應用集羣，結構化和非結構化數據採用磁盤陣列存儲，存儲設備和應用服務器間使用高速交換機連接，通信支持10Gbit/s以太網（萬兆以太網）。

  應用集羣連接核心交換機、負載均衡爲用戶提供服務，內網用戶可直接訪問。外網用戶或外網系統訪問系統服務，必須經過防火牆認證。

• 1.  Cool Java 應用開發框架

• 2.5.1框架說明

  Cool Java概念：

    CoolJava是一款快速開發模塊化腳手架，提供以Spring MVC爲模型視圖控制器和springboot兩種版本，通過cooljava屏蔽數據庫差異，提高系統兼容性。開箱即用，代碼快速生成，使用培訓成本及低。前後端分離設計，基於組件化開發方便移動端調用，複用。

  2.5.2功能說明

  系統管理功能：

    代碼生成器、菜單管理、用戶管理、角色管理、機構管理、文件管理、字典管理、權限管理。

• 角色管理：角色菜單權限分配，權限精確到按鈕。
• 菜單管理：自定義增刪改系統菜單，操作權限，按鈕權限標識等。
• 字典管理：對系統中經常使用的一些較爲固定的數據進行維護。
• 代碼生成：CoolJava提供了功能強大的表單開發工具集，通過它，我們可以快速地開發出一個數據輸入表單界面，實現表單數據的增刪改查流程等基本的功能而不需要寫代碼，該工具能自動生成前後端源代碼，我們再在源代碼基礎上進行簡單的修改，即可實現其他的一些高級的功能。生成代碼框架基於多種設計模式，屏蔽了J2ee的底層技術，程序員只需關注實際業務開發。
• Quartz調度框架：前端可視化配置定時任務。
• 可視化報表：讓數據結果清晰明瞭的進行呈現。
• Druid連接池：開源平臺上一個數據庫連接池實現，它結合了C3P0、DBCP、PROXOOL等DB池的優點，同時加入了日誌監控，可以很好的監控DB池連接和SQL的執行情況，可以說是針對監控而生的DB連接池，據說是目前最好的連接池。
• swagger接口API：自動生成接口文檔和客戶端服務端代碼，方便調試。
• • 提供在線功能代碼生成工具，提高開發效率及質量。
  • 封裝完善的用戶、角色、菜單、機構、數據字典、在線定時任務、數據報表等基礎功能。
  • 集成簡易報表工具，可極其方便的切換圖表類型、生成報表圖片。

   

• 頁面校驗自動生成(必須輸入、郵箱校驗、手機號校驗等)。

• 專業接口對接機制，集成swagger-ui在線接口文檔，Jwt token安全驗證，方便客戶端對接。

• 提供各種系統監控，實時跟蹤系統運行情況。

• 支持菜單動態路由。

• 操 作權限控制精密細緻，對所有管理鏈接都進行權限驗證，可控制到按鈕。

• 提供常用工具類封裝，日誌、緩存、驗證等。

• 利用ehcache框架對經常調用的查詢進行緩存，提升運行速度。

• 統一查詢分頁處理。

• 採用分層設計：（數據庫層，數據訪問層，業務邏輯層，展示層）層次清楚，低耦合，各層必須通過接口才能接入並進行參數校驗，保證數據操作的安全。

• 登錄用戶密碼進行MD5散列加密，此加密方法是不可逆的。保證密文泄露後的安全問題。

• API接口文檔內容詳細，極大的減少了前後端的溝通成本，同時確保代碼與文檔保持高度一致，極大的減少維護文檔的時間。

 

2.5.4技術框架

後端技術框架：

核心框架：Spring Framework 4.1

視圖框架：Spring MVC 4.1

持久層框架：Mybatis 3.1.1

安全框架：Apache Shiro 1.3.2

數據庫連接池：Alibaba Druid 1.0

接口測試框架：Swagger2

項目構建管理：Maven

日誌管理：SLF4J 1.7.7、Log4j 1.2.17

定時框架：Quartz 2.0.1

模板引擎：Freemarker 2.3.1

其他：JUnit4、Kafka、Zookeeper、Dubbo、Jackson 、Ehcache

前端技術框架：

JS框架：jQuery

前端頁面框架：Layui

富文本編輯器：UEditor

樹結構控件：jQuery zTree

技術實現

 

CoolJava平臺作爲信息系統規劃中“雲+網+端”、“微服務”、“自主可控”、“技術先進”的整體要求，以 Java 爲核心開發語言，遵守 J2EE 開發標準，以 Spring Boot + Srping Cloud 爲主的微服務技術框架，結合 Activiti 作爲流程引擎。

 

3.1圖形化元數據管理

     圖形化的操作爲用戶提供快速、方便、簡潔的自主業務維護途徑，避免了傳統系統通過代碼修改、版本發佈應對業務變更的落後方式。節省了版本開發、系統測試時間，使得用戶可以專注於業務需求，從技術上保證了用戶可以快速響應業務變更，提升了用戶工作效率。

元數據，作爲描述數據的數據，數據模型使得主數據具備了較高的擴展能力， 可根據業務的發展需要增加新的元數據類型或更新現有數據模型，以應對新的業務需求；流程定義，可以讓用戶方便、快捷的調整業務審批流程、審批權限。

圖形化的元數據管理，使得用戶更加方便的調整業務。

模型管理

    模型管理主要包含數據建模。當業務發展，需要新增某類型的數據時，用戶可根據業務需要，在系統自行維護，無需系統版本更新，其具體流程爲：

數據建模→流程審批→模型發佈→數據維護

其中數據建模，用戶通過系統頁面直接進行主數據模型構建模型屬性可動態添加，並可對數據類型、數據長度、數據精度、編碼規則、是否爲空、默認值等屬性進行配置。

流程引擎

   流程管理，採用業內先進的 Activiti 流程引擎，並採用微服務設計思想，流程系統可獨立部署，爲CoolJava平臺提供通用的流程服務，流程數據與業務數據完全解耦，所有流程在流程中心數據庫進行統一管理、統一監控。

菜單管理

平臺提供了功能菜單的可視化管理功能，可動態對系統菜單進行配置，可定義菜單顯示名稱、路徑、增加功能權限控制等功能。

菜單可以針對角色、用戶組、用戶等分別進行獨立授權。

 

1. HTML5 應用平臺

 

 

 

系統平臺前端顯示層基於 HTML5 標準開發，主要包含表單設計器、表單解析引擎、腳本解析引擎、事件驅動機制、RPC 通信、對象傳輸序列化機制、表單響應式顯示等功能，支持 IE、Edge、Chrome、FireFox、Safari 等主流瀏覽器。

HTML5 平臺的核心技術主要包括：將表單定義爲統一的爲標準 JSON 格式， 使其可跨平臺解析表單設計器設計的表單（解析成 HTML5 表單界面）；動態執行 JavasSript 的腳本引擎，根據表單上下文，動態執行腳本；HTML5 客戶端與服務器端的 RPC 通信機制；HTML5 客戶端與服務器端數據對象的映射及序列化和反序列化數據的傳輸機制；事件驅動模型的處理，通過增、刪、改等事件保證數據的一致性；HTML5 組件佈局根據設備分辨率按百分比顯示的問題。

 

 

 

 

3.3移動應用平臺

 

採用了 React+HTML5 輕應用與原生開發相結合的技術路線，具有快速可視化開發、 快速交付、易於集成的特點，滿足企業移動制單、移動審批、移動報表展示等所有移動辦公業務場景需求。

功能介紹

移動應用開發平臺提供可視化開發表單設計器，通過可視化開發方式設計移動業務表單，生成 HTML5 或原生業務表單。設計器提供列表、日曆、佈局、報表等多種業務組件，可快速定製可視化界面。

技術架構

移動開發平臺集成了多引擎開發技術、基於 Android 系統的碎片化保活技術、分佈式內存數據庫性能優化技術、分佈式消息服務技術、基於微服務的多業務集成技術以及流媒體服務適配技術等，採用 SOA 架構設計，建立了移動端快速開發的應用平臺，實現數據、業務等信息融合，構建覆蓋多業務領域的移動端應用。其技術架構如下圖：

 

 

框架（Mobile FrameWork）

數據層是移動開發平臺的基礎。主要包括遠程服務調用、數據對象管理、消息服務、組件管理、視圖管理、設備管理等。

 

組件是平臺的中間層，是定製化組件工具的核心部分，提供先進的配置化、可複用的組件。組件主要包括業務組件、分析組件、模型組件、樣式組件、適配器組件、Action 組件、以及存儲消息組件等。

 

 

應用層是業務邏輯層，是針對不同業務需求目標研發並實現的功能模塊。基於模型設計器、服務編排設計器、流程設計器和表單設計器中實現具體業務邏輯， 完成業務功能。

移動開發平臺分爲操作系統層、開源庫、核心層、應用層幾大部分。其中，

操作系統目前支持 IOS、Andriod 兩個平臺。

        應用層負責解析服務端發來的各類單據，實現良好的展示。單據可能包含多條明細，或包含附件文件，應用層都可以支持下載查看。

3.4技術實現原理

平臺採用了多引擎開發技術路線，集成了 HTML5 和 React Native 開發引擎，集多種開發方式優點於一體,設計統一的調用規範與封裝方式，實現統一集成開發，使各技術開發的組件在移動應用平臺中風格一致，解決基於 Android、iOS 移動平臺各種開發技術只能獨立開發移動應用，無法統一開發移動應用的問題，實現移動平臺多種語言共同開發的效果。

 

 

• 組件（Mobile Component）
• 應用

 

 

（1）HTML5 開發引擎

移動應用開發平臺充分利用 Android 端 WebView 的特性，對其屬性與協議方法進行管理控制，充分利用 WebView 的高度定製性，完成 Android 端WebBrowser 組件的封裝，實現Android 端使用WebBrowser 組件加載HTML5 界面時，內存佔用量小，快速、穩定。移動應用開發平臺實現了在線或離線 HTML5 網頁的統一加載，減少 HTML5 網頁的緩存文件，提高加載 HTML5 網頁的穩定性。

移動應用開發平臺通過HTML5 開發引擎對Android 和iOS 統一開發規範。統一 HTML5 網頁離線路徑，統一放置到資源文件下的 html 文件中，方便對離線網頁的管理。通過統一的加載接口便捷、高效的加載離線 HTML5 網頁，加快開發速度與降低開發難度。平臺通過定義 WebBrowser 規範，實現統一的原生加載 HTML5 網頁的按需加載規則，實現 HTML5 引擎對 HTML5 網頁的按需加載，不加載多餘內容，使原生加載 HTML5 網頁更流暢，降低加載 HTML5 網頁導致的內存消耗，解決傳統方式加載 HTML5 時內存泄露的問題，使用戶對加載HTML5 時的體驗更友好。

 

（2）ReactNative 開發引擎

移動開發平臺集成 React Native 運行時環境，定義 React Native 與原生

（Android、iOS）交互規範，優化 RCTBridge，基於 RCTBridge 開發 317 個原生功能接口，如調用原生文件系統、獲取 GPS 信息、原生攝像頭接口、原生相冊接口、原生通訊錄接口數據庫接口等，解決無法調用底層定位、相冊、通訊錄等接口的難題，統一 Android 和iOS 對React Native 的調用接口，解決 React Native 原生功能較少問題。通過將 React Native 的 JS 文件與圖片資源，放入應用本地存儲（iOS 爲沙盒、Android 爲資源文件下），實現離線加載。在 React Native 部分需求發生變化時，只需更新下載應用資源文件，無需升級 APP 就能達到程序的更新，並實現 React Native 代碼熱更新功能，解決代碼動態更新的難題。對 ReactNative 進行組件化處理，由 ReactNative 引擎進行統一管理， 實現對組件生命週期的控制，平臺對 ReactNative 界面的加載速度較傳統ReactNative 加載方式提高 20%。

3.5多語言支持

針對多語言提供了完整的解決方案，主要包括對資源文件、主應用界面、功能菜單、後臺服務、主數據等模塊的多語言支持。

1. 資源文件多語言

系統登錄界面和首界面具有語言選擇功能，當選擇了不同的語言後，系統可以根據當前語言類型切換顯示對應的背景圖片、標題圖片等資源文件，平臺提供資源文件配置功能，用戶通過簡單的配置就可以實現對資源文件的多語言配置。

1. 應用界面多語言

前端應用界面的語言文字需要根據本地環境或選擇的語言進行顯示，平臺支持通過增加 properties 多語言配置文件的方式擴展多語言的支持。

1. 功能菜單多語言

系統功能菜單是通過 XML 文件的形式定義的，可以根據語言種類定義多種類型的功能菜單 XML 文件，菜單文件名以語言類型爲後綴，功能菜單顯示時會根據語言類型加載對應的菜單配置文件，實現功能菜單的多語言顯示。

1. 後臺服務多語言

平臺提供後臺服務的多語言開發規範，按照開發規範開發的後臺服務插件，支持多語言的靈活擴展，某些場景下，後臺服務需要給客戶端返回友好的提示信息，符合開發規範的後臺服務會根據前端語言類型返回對應的多語言提示信息。

1. 多語言

針對需要提供多語言支持，平臺提供了創建多語言表的功能，多語言表記錄需要多語言處理的列數據，主數據加載時，系統會根據語言類型加載對應的多語言類數據。

此外，平臺還提供了多時區、多幣種的支持，具體的業務功能可以靈活配置啓用。

3.6雲管理平臺

通過雲管理平臺，以集中統一方式管理物理機、虛擬化平臺、以及運行在其上的應用羣，能夠在不影響系統應用正常運行的情況下，快捷的實現應用的動態拆分、整合、遷移、部署、下線、數據同步、資源調度、彈性擴展等操作。

3.6.1系統功能

基於微服務架構和 Docker 容器技術的雲平臺提供一套服務快速開發、部署、運維管理、持續開發、持續集成的流程。平臺提供基礎設施、中間件、數據服務、雲服務器等資源，開發人員只需要關注業務代碼並提交至平臺代碼庫，完成必要的配置，系統會自動構建、部署，實現應用的敏捷開發、快速迭代。在系統架構上，雲平臺主要分爲微服務架構、Docker 容器技術、雲資源管理、DveOps 四部分。

微服務訪問大致路徑爲：外部請求 → 負載均衡 → 服務網關（GateWay）

→ 微服務 → 數據服務/消息服務。服務網關和微服務都會用到服務註冊和發現來調用依賴的其他服務，各服務集羣都能通過配置中心服務來獲得配置信息。

基於 Spring Cloud 的微服務思想架構設計，把一個大型的單個應用程序和服務拆分爲數個微服務，每個服務以獨立的方式在輕量級容器中運行，同時提供標準統一的 REST 調用接口，以 JSON 的方式傳輸數據，它可以做到每種服務可單獨進行開發與運維互不影響，輕量級容器可以自動快速分佈式佈署。

 

1. 架構設計

 

由於系統的每個服務都比較簡單，只專注於一個特定的功能，佔用資源少、運行效率高；微服務架構保證了系統的鬆耦合，可使用持續集成工具進行靈活的自動集成部署；微服務間通過 Restful 標準接口通訊，易於擴展，提高了系統擴展及集成的靈活性，可充分使用雲平臺統一管理微服務，降低運維難度。

採用服務組合的方式來構建一個應用，服務獨立部署在不同的容器中，不同服務通過一些輕量級交互機制 HTTP Resource API 來通信，服務可獨立開發、獨立運維、獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的編程語言來實現，但是都需要遵守明確的標準技術規範。

4.1架構特徵

1. 原子服務: “高內聚，鬆耦合”，  服務被設計爲功能相對獨立，儘量不依賴其他服務的獨立功能提供者;微自治：服務足夠小，功能單一，可以獨立打包、部署、升級、回滾和彈性伸縮，不依賴其他服務，實現局部自治；
2. 服務是可組合、可編排的：多個服務可能被編排組合成一個新的服務，這允許不同邏輯抽象的自由組合，促進服務的複用, 以面向微服務編排的理念爲上層業務快速定製應用；
3. 易維護：微服務應用側重於應用的實時監控，每個單獨的服務設置精密的監控和記錄，這些服務包括在 dashboard 上顯示服務啓用/宕機狀態，以及各種相關的運營和業務指標，一旦出現異常能精準定位，觸發跟進和調查；
4. 高恢復能力：因爲每個服務是獨立的，與其他服務是完全解耦的，獨立的運行可以立即提供與其他組件中的故障獨立的恢復能力。

 

4.2架構優勢

1. 每一個微服務只專注於一個特定的功能，佔用資源少、運行效率高。
2. 由於每一個微服務只專注一個特定的功能,與其他系統功能完全解耦, 這種架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供 API 服務。
3. 微服務架構模式使得每個微服務可以進行獨立部署、運維，開發者不再需要協調其它的資源來配合本次服務的部署。
4. 微服務架構模式使得每個服務獨立擴展。你可以根據每個服務的規模來進行合理的資源分配，比如流程中心壓力比較大，可以單獨給流程中心微服務單獨增加資源。
5. 微服務架構可彈性擴展資源，這樣便能在無運維人員介入的情況下實現自動調整計算資源，當訪問量上漲時增加計算能力，而當訪問量下降時減小計算能力，既保障了系統的穩定性與高可用性，又節約了計算資源成本。
6. 微服務運行在 docker 容器中，Docker 容器幾乎可以在任意的平臺上運行，所以微服務具有很高的移植性，可以快速在移植到物理機、虛擬機、公有云、私有云等異構平臺中，並以接近實時的速度實現負載的動態管理，快速擴容應用和服務。
7. 微服務間通過 Restful 標準接口進行通訊，易於擴展，提高了系統擴展及集成的靈活性。

   4.3雲資源管理

    

   4.3.1主要功能

    

   雲管理平臺對於同構異構分散多地的雲資源通過 kubernetes、Docker 等技術對集羣集中統一管理、任務統一調度、容器統一管理，確保各類資源隨着應用的需求動態調度，同時簡化應用程序的開發、部署難度，實時的採集系統運行過程中的日誌信息。雲管理平臺主要包括如下四部分：

   爲整個數據中心提供分佈式調度與協調功能，統一協調各類資源，實現數據中心級的彈性伸縮能力。實現高可用性、容災，雲平臺所有組件採用分佈式架構， 應用跨機房分佈式調度。自動爲宕機服務器上運行的節點重新分配資源並調度， 保障業務不掉線，做到故障自愈。

   對於基礎架構和應用編排問題，雲管理平臺提供一系列自動編排工具，能夠實現應用部署的整個過程的自動化，滿足了開發測試過程中快速創建開發測試環境需求和運維中一鍵快速擴容縮容、自動故障恢復等場景的自動化需求。

   對於環境創建準備慢的問題，雲管理平臺提供了以容器爲基礎封裝各類應用和運行環境，實現資源的高效利用率，數據中心操作系統相較於虛擬機有着基於CPU、內存的更細粒度的資源調度，多個計算框架或應用程序可共享資源和數據， 提高了資源利用率。

   提供雲管理平臺的門戶。對雲框架層各個組件產生的日誌，通過聚合、緩存、流式處理。爲節點提供組件的包管理，爲集羣提供包管理。提供身份認證和權限管理。

   4.3.2技術路線

    

8. 集羣管理資源整合，提高資源利用率。通過 kubernetes 分佈式系統來管理資源和任務，統一調度管理分佈式集羣的計算資源、網絡資源、存儲資源， 將物理資源整合成“巨型計算機”；通過 kubernetes 將“小云“整合成”大雲”。
9. 調度管理，調用 kubernetes 創建運行的任務 Job，並且對任務進行啓動、停止等管理。
10. 容器化，通過 Docker 將應用容器化。通過 Docker 實現以容器爲基礎封裝各類應用和運行環境，實現應用的快速發佈。
11. 跨平臺，通過容器鏡像（Docker Registry）倉庫，實現應用的跨平臺部署和運行。
12. 容錯與擴展， 更高效的管理系統， 支持應用的橫向擴展；通過對 kubernetes 的任務進行統一的調度管理，實現服務的長時間運行及對服務運行狀態的監控，同時實現服務的擴縮容，如果一臺服務器發生故障， 它的工作負載可以自動遷移到別的地方。
13. 對於雲平臺產生的日誌，通過 Fluentd 採集，發送到 ElasticSearch 創建索引，對日誌進行統一的管理分析。通過 kibana 構建圖形化界面查看日誌。

14. 4.4系統技術架構

    系統主要包括四層：

15. 基礎組件，主要包括日誌及監控模塊，組件的日誌信息、日誌的聚合、組件監控；網絡模塊，四層虛擬 IP 的管理、端口映射服務；以及安裝systemd服務單元，爲每個主機建立指定角色。
16. 平臺框架，包括集羣的管理，服務的編排，安全管理，以及容器的運行時環境。
17. 應用容器化層，通過 Docker 技術以應用爲單元進行“集裝封箱”。
18. 門戶，包括服務管理、節點管理、網路管理、安全管理、系統設置等。

19.  

    4.4.1服務網關（GateWay）

    外部請求經過ELB 負載均衡後路由到GateWay 集羣中的某個GateWay 服務，由 GateWay 服務轉發到微服務。API 網關服務主要有以下基本能力：

    動態路由：動態的將請求路由到所需要的後端服務集羣。雖然內部是複雜的分佈式微服務網狀結構，但是外部系統從網關看就像是一個整體服務，網關屏蔽了後端服務的複雜性。

    限流和容錯：爲每種類型的請求分配容量，當請求數量超過閥值時拋掉外部請求，限制流量，保護後臺服務不被大流量沖垮；黨內部服務出現故障時直接在邊界創建一些響應，集中做容錯處理，而不是將請求轉發到內部集羣，保證用戶良好的體驗。

    身份認證和安全性控制：對每個外部請求進行用戶認證，拒絕沒有通過認證的請求，還能通過訪問模式分析，實現反爬蟲功能。

    監控：網關可以收集有意義的數據和統計，爲後臺服務優化提供數據支持。訪問日誌：網關可以收集訪問日誌信息，比如訪問的是哪個服務？處理過程

    （出現什麼異常）和結果？花費多少時間？通過分析日誌內容，對後臺系統做進一步優化。

    4.4.2服務註冊與發現

    通過 Spring Cloud 體系中的 Eureka 組件提供了服務註冊與發現機制，服務的提供方要註冊報告服務地址，服務調用方要能發現目標服務。微服務架構中使用了 Eureka 組件來實現服務的註冊與發現。所有的微服務（通過配置 Eureka 服務信息）到 Eureka 服務器中進行註冊，並定時發送心跳進行健康檢查，Eureka默認配置是 30 秒發送一次心跳，表明服務仍然處於存活狀態，發送心跳的時間間隔可以通過 Eureka 的配置參數自行配置，Eureka 服務器在接收到服務實例的最後一次心跳後，需要等待 90 秒（默認配置 90 秒，可以通過配置參數進行修改）後，才認定服務已經死亡（即連續 3 次沒有接收到心跳），在 Eureka 自我保護模式關閉的情況下會清除該服務的註冊信息。所謂的自我保護模式是指， 出現網絡分區、Eureka 在短時間內丟失過多的服務時，會進入自我保護模式， 即一個服務長時間沒有發送心跳，Eureka 也不會將其刪除。自我保護模式默認爲開啓，可以通過配置參數將其設置爲關閉狀態。

    Eureka 服務以集羣的方式部署，集羣內的所有 Eureka 節點會定時自動同步微服務的註冊信息，這樣就能保證所有的 Eureka 服務註冊信息保持一致。那麼在 Eureka 集羣裏，Eureka 節點是如何發現其他節點的呢？我們通過 DNS 服務器來建立所有 Eureka 節點的關聯，在部署 Eureka 集羣之外還需要搭建 DNS 服務器。

    當網關服務轉發外部請求或者是後臺微服務之間相互調用時，會去 Eureka 服務器上查找目標服務的註冊信息，發現目標服務並進行調用，這樣就形成了服務註冊與發現的整個流程。

    4.4.3微服務部署

    微服務以鏡像的形式，運行在 Docker 容器中。Docker 容器技術讓我們的服務部署變得簡單、高效。傳統的部署方式，需要在每臺服務器上安裝運行環境， 如果我們的服務器數量龐大，在每臺服務器上安裝運行環境將是一項無比繁重的工作，一旦運行環境發生改變，就不得不重新安裝，這簡直是災難性的。而使用Docker 容器技術，我們只需要將所需的基礎鏡像（jdk 等）和微服務生成一個新的鏡像，將這個最終的鏡像部署在 Docker 容器中運行，這種方式簡單、高效， 能夠快速部署服務。每個 Docker 容器中可以運行多個微服務，Docker 容器以集羣的方式部署，使用 Docker 雲資源管理平臺對這些容器進行管理。我們創建一個鏡像倉庫用來存放所有的基礎鏡像以及生成的最終交付鏡像，在鏡像倉庫中對所有鏡像進行管理。

    4.4.4服務容錯

    使用 Spring Cloud 微服務架構中 Hystrix 組件來進行容錯處理。Hystrix 是 Netflix 的一款開源組件，它通過熔斷模式、隔離模式、回退（fallback）和限流等機制對服務進行彈性容錯保護，保證系統的穩定性。

    熔斷模式：熔斷模式原理類似於電路熔斷器，當電路發生短路時，熔斷器熔斷，保護電路避免遭受災難性損失。當服務異常或者大量延時，滿足熔斷條件時服務調用方會主動啓動熔斷，執行 fallback 邏輯直接返回，不會繼續調用服務進一步拖垮系統。熔斷器默認配置服務調用錯誤率閥值爲 50%，超過閥值將自動啓動熔斷模式。服務隔離一段時間以後，熔斷器會進入半熔斷狀態，即允許少量請求進行嘗試，如果仍然調用失敗，則回到熔斷狀態，如果調用成功，則關閉熔斷模式。

    隔離模式：Hystrix 默認採用線程隔離，不同的服務使用不同的線程池，彼此之間不受影響，當一個服務出現故障耗盡它的線程池資源，其他的服務正常運行不受影響，達到隔離的效果。例如我們通過 andThreadPoolKey 配置某個服務使用命名爲 TestThreadPool 的線程池，實現與其他命名的線程池隔離。

    回退（fallback）：fallback 機制其實是一種服務故障時的容錯方式，原理類似 Java 中的異常處理。只需要繼承 HystixCommand 並重寫 getFallBack()方法，在此方法中編寫處理邏輯，比如可以直接拋異常（快速失敗），可以返回空值或缺省值，也可以返回備份數據等。當服務調用出現異常時，會轉向執行getFallBack()。有以下幾種情況會觸發 fallback：

    （ 1 ） 程 序 拋 出 非 HystrixBadRequestExcepption 異 常 ， 當 拋 出HystrixBadRequestExcepption 異常時，調用程序可以捕獲異常，沒有觸發fallback，當拋出其他異常時，會觸發 fallback；

20. 程序運行超時；
21. 熔斷啓動；
22. 線程池已滿。

23. 限流： 限流是指對服務的併發訪問量進行限制，設置單位時間內的併發數，超出限制的請求拒絕並 fallback，防止後臺服務被沖垮。

    Hystix 使用命令模式： HystrixCommand 包裝依賴調用邏輯，這樣相關的調用 就 自 動 處 於 Hystrix 的 彈 性 容 錯 保 護 之 下 。 調 用 程 序 需 要 繼 承HystrixCommand 並將調用邏輯寫在 run()中，使用 execute()（同步阻塞）或queue()（異步非阻塞）來觸發執行 run()。

    4.4.5動態配置中心

    配置中心提供了集中式配置管理功能，基於 docker 部署模式的微服務啓動時，根據服務類型及運行環境標誌，動態的從配置中心獲取對應配置，同時監聽配置中心配置修改操作。配置中心提供 UI 管理功能，系統管理員可以在配置中心管理界面修改微服務配置，配置發佈後，會實時將配置文件推送給相應的微服務應用，實現微服務的動態配置。

    4.4.6微服務追蹤

    微服務追蹤機制，通過微服務追蹤日誌可快速定位問題、故障節點、分析調用耗時等。目前支持 Sleuth+Zipkin 等服務追蹤框架。

    4.4.7日誌中心

    日誌集中存儲處理方案，以提升日誌管理規模和管理效率。可分佈式管理各微服務應用日誌，快速定位日誌內容。

    4.4.8灰度發佈

    提供灰度發佈配置機制，支持基於 Docker 容器化微服務部署架構下的灰度發佈機制。

    灰度發佈系統可以部分用戶或單位優先使用新版本系統，另一部分用戶仍然使用歷史穩定版本，當新版本系統出現故障，這部分用戶或單位可快速切換至歷史穩定版本，降低風險影響範圍，如系統正常運行，可擴大用戶使用範圍；

    灰度發佈可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，實現程序有序和自動化升級。

    4.5高併發與高性能處理

    平臺基於微服務架構思想設計，採用容器化的分佈式部署模式，在系統接入層、應用服務層、數據存儲層均採用分佈式負載，同時採用消息機制實現異步通信提高系統併發，並且增加限流保護與熔斷機制確保系統的穩定性，保證了高併發處理能力。利用緩存數據庫、MQ、並行計算、前端緩存等技術保證了系統的高性能。

    4.5.1高併發處理

    系統的接入端採用負載均衡策略，有效分散、平衡用戶的請求，提高系統接入層的併發能力；通過 Docker、kubernetes 等實現根據各微服務的資源（CPU、內存和 TPS 等）使用情況對運行容器進行彈性伸縮，保障應用層的系統併發能力；系統間調用採用 MQ 實現消息通信的異步化處理，達到高併發情況下流量消峯的目的；採用 Redis 等緩存技術，將系統中使用頻率高、相對靜態的數據進行緩存，避免每次使用數據時訪問數據庫，數據緩存有效保障了系統併發能力； 數據庫採用分佈式集羣部署、分庫、分表、讀寫分離等多種方式，提高數據庫併發處理能力。

    通過以上措施，確保系統對高併發的要求，滿足系統併發用戶的數量要求， 同時根據用戶的增加能夠隨時進行資源動態擴展進一步提高系統併發。

     

    4.5.2高性能保障

    系統的接入端採用負載均衡策略，針對每項服務分別搭建的集羣環境，可有效分散、平衡用戶的請求，確保接入層每個請求的快速響應；採用 MQ 實現消息通信的異步化處理，避免系統間調用的相互等待，降低系統間的耦合度，保障前端用戶反饋的響應速度；採用 Redis 等緩存技術，將使用頻率高、相對靜態的數據進行緩存，避免每次使用數據時訪問數據庫，從而提高系統的處理效率，縮短每次訪問系統的佔用時間；針對數據需要實時處理且併發量高的情況下，通過採用 Storm 技術，搭建 Storm 集羣服務，實現數據的實時處理，通過使用利用流式計劃數據處理計算實現查詢數據的事前準備，確保用戶查詢時的響應速度； 充分利用 HTML5 的客戶端 indexDB 數據庫，實現表單、元數據、關鍵指標等數據的預加載和緩存。此外，客戶端採用虛擬 DOM、服務器端渲染等多項技術保證了前端的渲染效率，提高頁面的相應時間。

24. 集成方案

25. 5.1集成架構設計

    CoolJava技術方案與他系統間集成方式主要通過 ESB 進行集成，數據量大的情況下通過 ETL 方式進行集成，比如：主數據導入、與 BI 報表系統間的集成。CoolJava平臺與其他系統間集成必須遵循統一的數據集成標準和規範。

    5.2平臺集成能力

    平臺基於微服務架構，提供的接口符合標準的 REST 規範，數據使用 JSON 格式傳輸，可與其他系統無縫集成。平臺提供企業服務總線 ESB，具有靈活的集成接口定製功能，日誌採用異步方式存儲於 ElasticSearch 中，有效的保證了系統集成性能。此外，平臺還支持應用服務註冊與發現、MQ 異步消息通信等多種方式與其它系統進行集成。

    5.3核心服務組件

    組件總體概述

26. 組件設計思路

27. 核心服務組件設計包括以下內容：

28. 系統對外提供相關的實時訪問接口，具體接口規範參考“接口技術規範”文檔內容。
29. 提供直接可用的粗粒度的、細粒度的的服務。不僅包括業務邏輯簡單、無須事務支持的服務，還應包括要求事務支持、邏輯複雜的服務。服務除了包含基本的 CRUD 操作外，還提供的鎖定/解鎖、合併、疑似查詢、編碼分配等服務。同時還支持對原子服務進行封裝並組合成新的、複雜的服務。
30. 滿足相應的校驗規則要求，其中數據格式校驗主要通過接口報文約束實現，其他的業務邏輯校驗在服務裏面實現。
31. 對於業務數據的新增操作，必須滿足相應的唯一識別要求。
32. 對於業務數據的修改操作，必須滿足相應的覆蓋原則要求。
33. 對於疑似查詢疑似發現操作，必須滿足相應的疑似發現原則要求。
34. 編碼分配服務，滿足預定義的編碼規則，編碼規則由數據標準管理裏
35. 面的編碼管理功能模塊進行維護，具體參考數據標準管理相關章節。
36. 保存的歷史數據，對核心數據，都需要保留數據新增、修改、刪除、鎖定、解鎖的歷史。
37. 需要記錄所有的操作日誌以及異常出錯的情況，以便後續跟蹤。
38. 提供相關的管理功能，如批量處理管理、日誌管理等

39.  

40. 組件服務框架概述

41. 服務框架採用分層的設計思想，在不同的層提供對應的功能模塊，做到層級的隔離和解耦，同時可以提高複用性。服務框架分層模型劃分爲如下三層： WebService 接入層，系統基礎組件層，組合服務提供層。

     (—）WebSerice 接入層

42. 提供 WebService 的 SOAP 報文方式接入；
43. 請求報文和應答報文的完整日誌記錄；
44. 生成流水號，用來標準這次請求的相關操作；
45. 報文解析，負責把 SOAP 報文轉換爲對象結構；
46. 身份認證，根據報文中傳遞過來的身份信息，可以進一步做身份認證；
47. 異常控制，當接入層或者後面的服務調用出現異常後，可以做異常統一捕獲與控制，返回更友好的信息給調用方。

48.  (二）系統基礎組件層

49. 提供統一的訪問組件，JMS 訪問組件，JDBC  數據庫訪問組件，日誌模塊，系統參數模塊。組合服務提供層
50. 組合服務提供層：其中又分核心服務提供模塊，內部組合服務模塊， 業務公共組件模塊；
51. 核心服務包含對外暴露的七大服務，提供對外調用的接口，複合對象的拆分和組裝等；
52. 內部組合服務模塊，提供複合對象父對象的服務封裝；
53. 業務公共組件模塊，提供數據校驗，數據清洗，數據版本識別組件。

54.  

    5.4發佈訂閱組件

    發佈訂閱機制介紹

55. 異步服務請求

56.  

    基於異步的服務請求經由 ESB 的處理過程，以下是詳細的步驟說明：

57. 服務請求方發起服務調用請求，並同步等待一個通訊應答；
58. ESB 接收到服務請求方的服務調用請求後，立即同步返回給服務請求方一個通訊應答；
59. ESB 同時調用服務提供方的服務，並同步等待調用結果；
60. 服務提供方將處理結果同步返回給 ESB；
61. ESB 通過服務請求方提供的回調服務，異步將處理結果返回服務請求方；
62. 服務請求方收到處理結果後，同步返回給 ESB 一個通訊應答。
63. 同步服務請求

64. 基於同步的服務請求經由 ESB 的處理過程，以下是詳細的步驟說明：

65. CoolJava技術方案請求調用 ESB，並將相關請求數據發送給 ESB；
    1. ESB 接收到調用請求後，調用CoolJava技術方案服務接口，將相關參數發送給CoolJava技術方案；
    2. CoolJava技術方案接收到調用請求後，進行業務相關處理，同步返回響應信息；
    3. ESB 將響應結果同步返回給CoolJava技術方案。

66.  

67. 架構設計說明

68.  

    邏輯架構主要包括以下幾個部分：

69. 發佈適配器

70. 發佈適配主要負責接收 SOAP/HTTP 請求，ESB 將通過發佈適配器對外提供發佈訂閱模式的 Web 服務。

71. 發佈訂閱引擎

72. 發佈訂閱引擎從隊列中讀取消息，並對其進行 Pub 處理，Pub 處理完成後對前端適配器發送處理響應報文。

73. 訂閱適配器

74. 訂閱適配器主要實現 ESB 與訂閱方系統之間的報文/協議轉換。

    5.5門戶系統集成方案

    基於微服務架構研發，對外提供 REST 接口服務，以 JSON 數據格式進行交互，應用基於 B/S 架構部署，可通過 https 協議訪問，前端頁面採用 HTML5 技術開發，支持 IE、Chrome、Firefox、Safari 等主流瀏覽器，支持統一用戶集成、統一認證集成、統一待辦集成、移動集成、統一UI 規範，可與門戶系統無縫集成。

    5.5.1統一用戶集成

    提供統一用戶集成方案，可通過配置的方式啓用用戶中心基礎數據同步功能。平臺提供了用戶中心查詢數據與系統組織基礎數據表的映射配置功能，系統根據配置調用用戶中心提供的 REST 服務接口，查詢組織機構、部門、人員、用戶等基礎數據，根據數據配置映射關係將數據轉換本地數據並插入業務系統數據庫，平臺本地數據編號和用戶中心數據編號保持一致，保證了數據增、刪、改的同步。此外，平臺通過權限控制，只允許添加運維所需的私有賬號，其他所有用戶賬號與用戶中心保持同步。

    用戶同步方式提供了定時同步和手動同步兩種解決方案：

     

75. 定時同步

76. 根據統一用戶管理系統提供的 Rest 接口及參數要求開發用戶信息同步插件， 平臺提供定時任務配置功能，可根據需求配置定時任務執行時間間隔，系統自動增量同步用戶管理系統基礎數據信息。

77. 手動同步

78. 平臺提供手動同步基礎數據功能，用戶可以通過手動點擊用戶同步按鈕，觸發數據同步操作，完成當前業務系統的基礎數據更新。

     

    5.5.2統一認證集成

    自身支持 SSO 單點登錄系統，通過配置就可以啓用統一認證。此外，平臺登錄驗證模塊提供可擴展驗證機制，可以任意擴展登錄驗證方式，可以輕易集成其他統一認證系統，當用戶第一次訪問應用系統的時候，由於還沒有登錄，平臺通過認證校驗過濾器將請求重定向到認證系統中進行登錄，根據用戶提供的登錄信息，認證系統進行身份效驗，如果通過效驗，返回給用戶一個認證的憑據

    （ticket），用戶再訪問別的應用的時候就會將這個憑據帶上，作爲自己認證的憑據，應用系統接受到請求之後會把憑據送到認證系統進行校驗，檢查憑據的合法性，如果通過校驗，用戶就可以在不用再次登錄的情況下訪問其它應用系
    5.5.3流程任務集成。

     工作流引擎在節點產生任務時，會派發任務生成事件，具有高可擴展性，通過監聽業務流程節點產生的事件，獲取生成的待辦任務信息，通過異步的方式調用 Rest 或 Web Service 接口，將待辦任務信息傳送至企業門戶，同時記錄任務的傳送狀態，如果傳送失敗，系統利用定時重傳機制重新傳送待辦任務信息，增強任務傳遞的及時性和完整性，重傳超過 3 次，則發送傳送失敗消息通知系統管理人員。用戶通過企業門戶打開待辦時，調用待辦任務的處理界面進行處理，處理完成後，根據用戶的處理情況將待辦完結信息發送到企業門戶，已完結任務信息在企業門戶不再顯示。

    推送待辦任務到門戶統一待辦庫之後，觸發門戶系統的消息發送機制，給相關用戶發送短信、郵件等提醒信息。

    
     

    5.5.4消息集成

    平臺系統提供了消息中心集成模塊，可以通過配置的方式啓用消息中心集成

    服務，系統可以根據業務需求調用消息集成模塊發送消息通知。發送消息通知的消息通道是可配置的，用戶可以根據具體業務需求，選擇門戶通知消息，移動門戶消息、短信、郵件中的一個或多個消息通道，發送給相關的人員。此外，系統具有自定義消息模板的功能，用戶可以根據業務場景自定義消息模板，提供個性化的消息內容格式。

     

    5.6集成技術規範

    5.6.1數據傳輸規範

    任何與CoolJava平臺進行集成必須通過 ESB 進行，系統集成雙方需在 ESB 註冊各自服務接口

    數據傳送以標準的 XML 報文進行，報文 Header 中需包含請求系統、用戶名和密碼等信息，業務報文內容需要進行統一進行加密，集成雙方系統必須遵循CoolJava平臺制定的數據集成規範。

    5.6.2統一 UI 規範

    CoolJava系統平臺給的 PC 端和移動端顯示界面均採用 HTML5+CSS 技術開發, 前端可視組件的開發全部基於皮膚分離的原則原則，將業務邏輯組件與皮膚樣式分離，實現了完全隔離，在不影響業務邏輯的基礎上，可根據 UI 規範，使用 CSS3 快速定義顯示風格，實現皮膚的動態切換。

     

79. 軟件技術說明

80. 6.1操作系統

    推薦系統：CentOS 7.4 x64

    6.2數據庫

    分類	軟件名稱	收費情況	備註
    關係數據庫	MySQL 5.7+	免費
    緩存數據庫	Redis 4.0+	開源免費

     

     6.3其他支撐軟件

       

    分類	軟件名稱	收費情況	備註
    雲平臺管理	docker-ce 18.03	開源免費
    	DockerRegister	開源免費
    	kubernetes 1.10+	開源免費
    	Spring boot 2.0+	開源免費
    	Nginx1.10+	免費	動態反向代理
    	Eureka 1.9.0+	免費	服務註冊發現
    	Spring cloud Finchley.SR1	開源免費
    大數據	Apache Spark or Hadoop
    JVM	OpenJDK1.8+	開源免費
    應用容器	Tomcat 8.5+	開源免費
    消息隊列	RabbitMQ	開源免費
    	kafka	開源免費
    服務器監控	Promethues 2.0+

     

    6.4系統擴展性

     

    依託CoolJava平臺先進的分佈式技術架構與靈活快速的開發平臺，可以滿足現有業務場景與技術要求。在未來有新的業務場景、新的業務品種、新的數據需求、新的數據結構、新的數據接口、新的業務流程、新的報表需求、新的模板等需求時，通過開發平臺能夠完成新增系統、新增功能、新增應用、新增表單、新增流程、新增接口、新增錄入項、新增輸出方式等過程的快速實現。在未來出現業務量增大、用戶量增大、系統請求增大、數據量增大等情況時，通過分佈式技術架構能夠實現系統動態擴展。

    CoolJava平臺的系統擴展性體現在三個方面：系統功能快速擴展、用戶配置按需擴展、系統資源動態擴展。

     

    6.5系統功能快速擴展

             隨着業務的快速發展，當由於新的業務需求，對CoolJava平臺提出新增系統、新增功能、新增應用、新增流程、新增接口等快速擴展需求時，通過CoolJava平臺能夠快速實現。

81. 新增業務類型

82.  

    對於新增類型的需求通過系統提供的模型管理實現，由系統運維或開發人員將新增模型信息進行配置。定製完模型信息後，可通過CoolJava平臺，使用新增模型增加新類型的數據。

83. 新增審批流程

84.  

    對於新增流程的需求通過 activiti 提供的流程管理實現，由系統運維人員將新增的流程配置到系統。系統流程配置可以根據用戶需求隨時進行新增業務流程的添加。

     

85. 新增接口

86.  

    對於新增接口的需求通過接口配置實現，由系統運維人員或開發人員將新增的接口配置完後發佈到集成中心。

    6.5.1用戶配置按需擴展

     

    隨着業務流程的不斷髮展與優化，針對CoolJava平臺的流程調整、界面調整、新增字段、新增數據項、新增輸出格式的需求會隨時出現，針對這些用戶配置的調整需要，通過CoolJava平臺的系統配置管理功能，能夠快速按需擴展與靈活調整。

    6.5.2系統資源動態擴展

    CoolJava平臺採用微服務化的分佈式架構，通過 kubernetes 等實現對 Docker 化部署的應用的管理，實現根據系統資源的佔用情況彈性收縮實現應用層的動態擴展。CoolJava平臺數據訪問通過統一的數據分佈服務，根據業務要求可以靈活配置擴展數據庫而無需進行功能開發，實現了數據存儲層的靈活可擴展。

     

    6.6系統性能特點

    高併發：

    CoolJava平臺採用分佈式部署方式，在系統接入層、應用服務層、數據存儲層均採用分佈式負載模式，同時採用消息機制實現異步通信提高系統併發，並且增加限流保護與熔斷機制確保系統的穩定性。

87. 接入層負載

88. 系統的接入端採用負載均衡策略，F5 作爲負載的主接入端支持 100 萬用戶的同時訪問，針對每項服務分別搭建的集羣環境，前端通過 Ingress 作爲負載接入端，每個 Ingress 接入端與 F5 的主接入端相連。採用負載均衡策略可有效分散、平衡用戶的請求，提高系統接入層的併發能力。

89. 應用資源彈性伸縮

90. 通過 Docker、kubernetes 等實現根據各微服務的資源（CPU、內存和 TPS 等）使用情況對運行容器進行彈性伸縮，保障應用層的系統併發能力。

91. 利用緩存服務

92. 採用 Redis 等緩存技術，將CoolJava平臺中使用頻率高、相對靜態的數據進行緩存，像CoolJava平臺中使用的主數據、配置數據、用戶基本信息、控制規則數據等進行緩存，避免每次使用數據時訪問數據庫，由於緩存服務採用負載架構從而保障了系統併發能力。

93. 利用異步消息服務

94. 採用 Kafaka 實現消息通信的異步化處理，達到高併發情況下流量消峯的目的。在系統間或不同系統模塊間的單據狀態的變化時均採用異步消息處理機制，避免系統間調用的相互等待，同時異步消息服務採用負載架構從而保障了系統併發能力。

95. 數據庫負載

96. 數據庫採用 RAC 方式部署提供靈活的橫向擴展能力，同時提供統一的數據訪問服務，支持按年度、組織架構等維度進行數據庫橫向分佈，支持定期對數據進行歸檔，確保每個數據庫的訪問量在一定範圍之內，同時確保整個系統的數據庫的訪問量滿足併發要求。對於非結構化存儲採用分佈式負載部署方式，並且支持根據業務需要動態擴展，確保訪問量滿足併發要求。

    通過以上措施，確保系統對高併發的要求，滿足CoolJava平臺併發用戶的數量要求，同時根據用戶的增加能夠隨時進行資源動態擴展進一步提高系統併發。

    可追溯：

    系統所有模塊與功能均通過統一的開發平臺構建，發平臺針對基礎數據確保實現一直保存，同時提供統一的數據修改痕跡記錄機制。針對元數據、主數據、流程數據、業務交易數據等數據進行變更時，詳細記錄變更前內容、變更後內容、變更時間、變更人等信息。

    通過統一數據訪問服務，數據進行歸檔以後進行查詢時，能夠根據數據的歸檔情況實時調用歸檔數據進行查詢展示。

    高性能：

    根據業務功能的應用場景，結合用戶的規模、功能的使用頻率、週期性影響、用戶體驗、響應時間要求等多方面因素，採用多種技術手段保證系統在高併發下的高性能。

97. 負載均衡

98. 系統的接入端採用負載均衡策略，F5 作爲負載的主接入端支持 100 萬用戶的同時訪問，針對每項服務分別搭建的集羣環境，前端通過 Ingress 作爲負載接入端，每個 Ingress 接入端與 F5 的主接入端相連。採用負載均衡策略可有效分散、平衡用戶的請求，確保接入層每個請求的快速響應。

99. 緩存服務

100. 採用 Redis 等緩存技術，將CoolJava平臺中使用頻率高、相對靜態的數據進行緩存，像CoolJava平臺中使用的主數據、配置數據、用戶基本信息、預算管控規則數據等進行緩存，避免每次使用數據時訪問數據庫，從而提高系統的處理效率，縮短每次訪問系統的佔用時間。

101. 應用 Storm

102. 針對數據需要實時處理且併發量高的情況下，通過採用 Storm 技術，搭建Storm 集羣服務，實現數據的實時處理，通過使用利用流式計劃數據處理計算實現查詢數據的事前準備，確保用戶查詢時的響應速度。

103. 前端技術

104. 充分利用 HTML5 的客戶端 indexDB 數據庫，實現表單、元數據、關鍵指標等數據的預加載和緩存。此外，針對超過一定數據量的數據加載請求採用懶加載技術、虛擬 DOM、服務器端渲染等多項技術。

     通過負載均衡、應用分佈式架構、應用雲計算等多項技術，使用CoolJava平臺內網與外網同時支持 2000 個併發以上，提出業務申請在 1 秒以內完成，數據查詢

     在 3 秒以內完成，批量接口或指數據處理在 5 秒以內完成。

     高可用：

     CoolJava平臺採用分佈式部署方式，基於微服務架構方式實現，在系統接入層、應用服務層、數據存儲層均採用雙活機制，同時對服務間的調用增加熔斷機制， 達到設定閥值時對服務功能進行降級處理，避免系統出現雪崩，實現系統的高可用。

105. 集羣部署

106. CoolJava平臺的各模塊均採用 Kubernetes+Docker 方式發佈，每一項功能服務採用集羣方式部署，每項集羣服務通過 Ingress 作負載均衡。

107. 故障隔離

108. 根據部署的多個集羣服務，每個集羣服務都以 Ingress 作負載，同時配置Keepalived 功能，實現對故障節點的實時監測與故障隔離，從而保證不間斷提供服務。

109. 過載保護

110. 系統根據具體的業務場景，對於服務間的調用可能存在大併發情況下，增加過載保護機制，當系統檢測到系統的資源相關指標到達設定的閥值時，新發起的服務請求直接返回，從而保護系統服務不至於過載而停止響應；同時當系統檢測到資源降下來後，自動關閉過載保護機制。

111. Mysql數據庫採用MHA高可用方案

112.        MHA（Master High Availability）是一套優秀的作爲MySQL高可用性環境下故障切換和主從提升的高可用軟件。在MySQL故障切換過程中，MHA能做到在0~30秒之內自動完成數據庫的故障切換操作，並且在進行故障切換的過程中，MHA能在最大程度上保證數據的一致性，以達到真正意義上的高可用。

113. oracle數據庫採用 RAC

114. 所有CoolJava系統平臺數據均保存在數據庫中，爲了避免數據庫出現單點故障， Oracle採用數據庫的 RAC 技術，從而提高數據庫存儲的可用性。

115. 非關係數據存儲採用分佈式存儲

116. 涉及影像文件、標籤化數據、緩存的主數據、配置數據、規則數據等均採用Redis、MongoDB 等非關係型數據存儲方式，採用的軟件技術自身已採用分佈式部署方式，在系統使用時，針對採用的這些軟件技術部署的節點數多於 3 個即可保證非關係型的存儲服務的高可用性。

     綜上通過以上技術方案的實施，確保系統的年平均無故障運行時間在 99.9%以上，每年因系統本身問題導致的宕機次數小於 1 次，因系統本身問題出現故障時的恢復時間小於 1 小時。

      

117. 備份恢復解決方案

118. 數據保護系統一體化設備，部署簡單，功能強大，爲企業避免存儲集中後的單點故障，實現數據容災、應用容災、文檔共享安全管理的統一整體解決方案。

119.  本地數據生產中心

120. •通過光纖傳輸的數據遷移器，將數據直接寫入磁帶設備中，實現FC-SAN或IP-SAN環境下的數據備份，備份源點經過光纖交換機寫入到磁帶設備，進而實現高速備份。

     •驅動器技術，實現多源點、跨平臺複雜環境下的FC-SAN方式備份，多平臺的備份主機將備份數據寫入一個磁帶驅動器，從而實現集中、統一的備份和恢復工作。

     •認證與加密：提在線數據備份過程中採用128位加密，如訪問和授權控制、磁盤和磁帶加密、廣域網傳輸加密方法，配合磁帶驅動器的加密技術，可以管理加密磁帶驅動器的密鑰，提高磁帶備份的安全性。

     •D2D2T：先進的磁帶讀寫技術、磁帶庫機械手控制技術，兼容各主流物理/虛擬磁帶庫，採用磁盤備份時，數據同樣以磁帶格寫入磁盤，從而輕鬆實現磁盤到磁盤再到磁帶的數據備份。

121. 支持公有云、私有云異地容災

122. •提供遠程容災備份功能。可選擇定時和實時兩種技術來實現遠程數據保護功能。在定時模式下，可自主選擇複製時間間隔;在實時模式下，可實現兩地之間的數據完全一致。

     •支持一對一、多對一、一對多、多對多的不同廣域網容災範圍。採用數據壓縮、斷點續傳、流量控制和雙向緩衝技術，以及重複數據刪除，減少網絡通信流量90%，提高了數據傳輸的穩定性和效率。物理位置分離的兩臺、多臺服務器可以相互容災備份，一旦災難發生，在異地的數據備份並不會受到波及，確保數據安全。

     •D2D2T：先進的磁帶讀寫技術、磁帶庫機械手控制技術，兼容各主流物理/虛擬磁帶庫，採用磁盤備份時，數據同樣以磁帶格寫入磁盤，從而輕鬆實現磁盤到磁盤再到磁帶的數據備份。

     •恢復測試和災備演練：支持建立備份容災的物理機或者虛擬機。該功能還可以用於恢復測試和災備演練，隨時驗證備份數據的有效性。

      

123.  NAS備份方式

124. NAS（Network Attached Storage：網絡附屬存儲）是一種將分佈、獨立的數據整合爲大型、集中化管理的數據中心，以便於對不同主機和應用服務器進行訪問的技術。按字面簡單說就是連接在網絡上，具備資料存儲功能的裝置，因此也稱爲“網絡存儲器”。它是一種專用數據存儲服務器。它以數據爲中心，將存儲設備與服務器徹底分離，集中管理數據，從而釋放帶寬、提高性能、降低總擁有成本、保護投資。其成本遠遠低於使用服務器存儲，而效率卻遠遠高於後者。

     根據我公司實際情況，將來採用的備份機制是，在需要定期備份的數據服務器上安裝sshserver + rsync 軟件，指定需要備份的數據的目錄，設定同步週期，通過ssh+rsync加密協議定期的把服務器上的數據備份到NAS服務器上。

     各個系統通用備份方法，重要文件異地機房備份，對大數據、不能中斷系統採用分佈式，集羣部署，能隨時恢復。

      

     備份內容	備份方式	最長備份週期
     操作系統（windows Linux）	生成系統快照	1天
     數據庫	數據庫採用Mysql/oracle，oracle配置爲rac或者主備，mysql配置爲集羣或者主備	1小時
     附件(圖片，視頻，文件)	Ssh+rsync加密備份，磁盤陣列	1天
     應用程序	Git/svn	1天

125. Linux下oracle備份方案

126. 兩臺服務器，包含正式環境服務器跟備份服務器，正式環境每天凌晨3點定時通過exp導出全庫，再用rsync傳輸至備份服務器存檔

127. 實現scp免密碼傳輸

128. 直接運行scp傳輸命令，會提示輸入密碼，要實現無人值守定時運行，就需要讓兩臺服務器的交互能夠自動免密，在此通過建立ssh信任關係的方法來實現
     在正式服務器上執行ssh證書生成命令

     ssh-keygen -t rsa

     遇到提示一路回車

     運行完畢後，在/root/.ssh目錄下會生成id_rsa，id_rsa.pub兩個文件

     登錄備份服務器，在用戶對應.ssh目錄（如/root/.ssh）下新建authorized_keys文件，將正式服務器id_rsa.pub文件的內容追加進去

     在正式服務器上隨意新建一個文件，測試scp傳輸

     scp ./aaa [email protected]:/root/

     現在已經不需要輸入密碼了，scp免密碼傳輸已經成功

129. 文件備份方案

130. 日常工作中有很多的備份工作，rsync是一個很不錯的工具，嘗試使用基於ssh免密登陸的方式進行備份，是可行且方便的方法，可用於備份系統，oracle，程序，附件，媒體等文件

     1.A主機root用戶對B主機root用戶做ssh免密登陸，此過程不再贅述，請參考上述oracle備份步驟。

     2.A主機安裝rsync命令：yum install rsync -y

     3.在A主機根目錄下創建/ceshi目錄，B主機根目錄下也創建/ceshi目錄，並touch一些測試文件。

     4.執行命令：rsync -a -e "ssh" 192.168.249.145:/ceshi/ /ceshi/，並檢查本地/ceshi目錄，如果被備份主機的ssh端口修改過，則修改爲"ssh -P XXXX"

     這樣，便將192.168.249.145主機上/ceshi目錄下的所有文件同步到了本地目錄下的/ceshi，需要注意的是192.168.249.145:/ceshi/  ，這個/，如果有，則表示同步文件目錄下的所有文件，如果沒有/，則表示下載改目錄，-a的意思是不改變文件屬主，權限等信息。

     5.應用範圍：可以使用rsync對數據庫的備份文件，或者其它需要進行備份的數據進行同步，最後，值得一提的是，rsync實現的是自動對比文件的備份，被備份目錄是備份目錄的子集，自動實現差異備份。

131. 災難恢復

132. 系統出現故障，導致不能運行的時候，需要有排除故障的預案，以便於及時解決故障並迅速使系統正常運行，下面對可能出現的故障進行列舉，並提出故障排除方式。

     故障類型	故障點	備份系統排除恢復方案
     硬件故障	電源、內存等非存儲相關設備故障	確定故障點，更換故障配件，如果故障配件沒有備份配件，聯繫服務器生產廠家，讓其及時提供； 如果配件發貨週期較長，可考慮把同類型服務器的配件暫用替換下，先把數據拷貝出來，然後在其他備用服務器上安裝程序，以及恢復數據，使系統儘快的先恢復起來。
     	硬盤或者磁盤陣列故障	如果出現一塊硬盤壞了，可以通過替換相同類型的硬盤，服務器自帶Raid5功能，將自動修復。 如果多塊硬盤出現故障，數據無法讀取的時候，首先查找備份文件，如果備份文件較新，比如是一天內的備份數據，此時評估下丟失的數據是否重要或者可以通過其他方式恢復，如果不重要或者可以通過重新錄入恢復，則用備份服務器上的數據進行數據恢復；如果數據重要，則可以請專業磁盤數據恢復公司的人過來進行數據恢復。
     軟件故障	操作系統故障	Vmware通過備份的快照快速恢復。Docker通過docker快照備份
     	應用程序故障	可以聯繫應用程序開發，要求進行售後支持，通過svn或者git根據安裝程序代碼版本通過Jenkins  完成自動化部署。
     數據恢復	數據庫	Oracle通過dmp文件或歸檔回，復，mysql通過bin_log恢復
     	文件	本機通過掛載直接恢復，本地局域網通過rsync快速恢復，遠程通過ssh+rsync快速恢復

      

133. 備份數據清理

134. 根據需求和數據量大小，可在備份服務器定時刪除舊數據。

     #!/bin/bash
     #刪除60天以上備份文件
     location=/data/backup
     find $location  -mtime +60 -print | xargs rm -r