項目總體概述建設背景為有效落實集團公司全面深化改革的指導意見，按照《全面推進深化改革的通知》的要求，推進IT深化改革，既要立足當前，提升運營效率，服務好企業(yè)的改革發(fā)展，又要抓住機遇，從IT架構、IT研發(fā)與運營、IT人才激勵等方面系統(tǒng)地推進改革，解決IT體系中存在的突出矛盾和根本問題，支撐企業(yè)的轉型發(fā)展，集團公司在深入研究的基礎上，制定了企業(yè)IT深化改革實施方案。企業(yè)IT深化改革實施方案提出，在服務好企業(yè)全面深化改革的同時，要抓住改革的機遇，系統(tǒng)化地推進IT自身的改革，并將兩者有機的融為一體，相得益彰。具體目標是：以互聯(lián)網(wǎng)思維變革企業(yè)的IT體系，構建以客戶為中心的全網(wǎng)集中、開放的云化IT架構，建立核心架構自主掌控的開放式IT研發(fā)體系和全網(wǎng)一體化管理的集約化IT運營體系，通過市場化機制組建充滿活力的IT研發(fā)和運營隊伍，推動企業(yè)全面深化改革，使IT成為企業(yè)核心競爭力。企業(yè)IT深化改革的目標是構建集中、開放、云化的互聯(lián)網(wǎng)化IT架構，實現(xiàn)這一目標的關鍵是聚焦兩大關鍵任務協(xié)同快速推進。一是通過自主研發(fā)，建成穩(wěn)定高效、開源開放、可持續(xù)演進的IT云服務能力平臺（以下簡稱“IT云平臺”）；二是基于IT云平臺的技術架構和集成能力，合作伙伴以低技術門檻快速開發(fā)構建CRM、計費等IT核心生產應用。平臺與應用之間不斷磨合、迭代優(yōu)化，最終形成平臺自主掌控、應用百花齊放的良性平臺生態(tài)。為此，企業(yè)信息化事業(yè)部遵照集團公司領導指示，啟動了IT云平臺一期工程建設。根據(jù)IT云平臺自主研發(fā)的要求，同時考慮到IT研發(fā)中心編制及人員逐步到位，平臺一期工程由IT研發(fā)中心牽頭，多家主業(yè)公司參與，完成了10個關鍵組件的研發(fā)，功能、性能指標均達預期。經(jīng)過專家進行評審，一致認為IT云平臺（一期工程）已基本具備承載應用的能力，有必要在現(xiàn)網(wǎng)生產系統(tǒng)開展應用試點，通過試點加快平臺成熟穩(wěn)定，同時啟動IT云平臺二期研發(fā)工作，進一步提升平臺能力。平臺現(xiàn)狀業(yè)務功能現(xiàn)狀一期工程在內蒙古云基地新建了一套IT云服務能力平臺，搭建新一代IT系統(tǒng)的PaaS層，主要建設平臺基礎能力組件，包括數(shù)據(jù)中間件組件、消息中間件組件、負載均衡組件、工作流引擎組件、分布式協(xié)調管理服務組件、事件驅動框架組件、安全中心組件、監(jiān)控與日志中心組件；同時在新建的IT云服務能力平臺上開發(fā)交易密集型應用原型和計算密集型應用原型，開展部分智慧運營平臺應用場景的功能和性能驗證，通過原型驗證評估IT云服務能力平臺近期承載集約智慧運營平臺核心應用的技術可行性和能力成熟度。系統(tǒng)架構如下圖所示：企業(yè)IT云服務能力平臺為新一代集中、開放、云化IT架構的PaaS層。其采用開放架構，高性能、可擴展，數(shù)據(jù)一點生成、全局共享，基于同一的底層平臺架構承載核心業(yè)務系統(tǒng)應用。具有平臺與應用解耦、硬件與軟件解耦、基礎設施云化，平臺持續(xù)演進、核心架構自主掌控、應用快速構建等特點。平臺提供統(tǒng)一數(shù)據(jù)服務、計算框架、共享業(yè)務組件組件等面向開發(fā)者的通用能力，提供平臺運維配套設施。應用基于平臺提供的框架，調用、組裝云平臺能力并進行業(yè)務開發(fā)，提供面向最終使用者的能力；應用受平臺框架和規(guī)范約束。IT云服務能力平臺近期優(yōu)先實現(xiàn)智慧運營平臺域集約化核心應用的承載。本期先行加載智慧運營平臺域部分交易密集型和計算密集型應用驗證平臺功能與性能需求。組網(wǎng)現(xiàn)狀IT云服務能力平臺現(xiàn)部署在內蒙古信息園數(shù)據(jù)中心A5機樓，系統(tǒng)硬件設備由IT資源池內蒙古節(jié)點提供，整個IT資源池內蒙古節(jié)點組網(wǎng)架構如下圖所示：其中IT云服務能力平臺部署于區(qū)域2，組網(wǎng)部署示意圖如下所示，匯聚網(wǎng)絡內部采用二層網(wǎng)絡互聯(lián)，服務器采用萬兆網(wǎng)絡連接接入交換機，滿足高性能高吞吐量需求。設備現(xiàn)狀IT云服務能力平臺現(xiàn)部署在內蒙古信息園數(shù)據(jù)中心A5機樓,設備配置情況如下表所示：表2-1互聯(lián)網(wǎng)不良信息內容檢測管理系統(tǒng)設備現(xiàn)狀類別序號設備類型用途數(shù)量單位配置要求硬件1物理PC服務器數(shù)據(jù)層管理服務器6臺4路8核，256GB內存，10*600GSAS硬盤（轉速10K）2物理PC服務器DSQL服務器（6臺）、SYNC服務器（6臺）、計算框架服務器（5臺）、分布文件系統(tǒng)管理服務器（2臺），原型應用服務器（計算密集型23臺、交易密集型19臺）、運維管理服務器（1臺）62臺4路8核，512GB內存，10*600GSAS硬盤（轉速10K）3物理PC服務器原型驗證數(shù)據(jù)庫服務器（計算密集型14臺，交易密集型20臺）34臺4路8核，512GB內存，10*600GSAS硬盤（轉速10K），PCI-E卡3.2TB，4物理PC服務器HBASE（6臺）、分布式文件系統(tǒng)服務器（34臺）40臺2路8核，128G內存，12*3TSATA硬盤轉速72005虛擬機研發(fā)管理服務器5臺2路8核，64G內存，1T硬盤6虛擬機研發(fā)管理數(shù)據(jù)庫服務器機1臺4路8核，64G內存，1T硬盤流程現(xiàn)狀當前CRM已包含各種業(yè)務登記單、營銷規(guī)則、終端核銷單、積分兌換單等紙質文件全部電子化；業(yè)務稽核電子化：實現(xiàn)對業(yè)務稽核的電子化操作；文件存儲電子化：實現(xiàn)單據(jù)存檔的自動化、電子化，倉儲管理系統(tǒng)化；移動設備的無紙化影像采集和電子簽名；電子業(yè)務受理單管理、電子稽核管理、電子模版管理、電子簽章管理、組織構架管理等管理功能；在營業(yè)廳和移動設備上實現(xiàn)了電子業(yè)務受理單生成、電子簽章、客戶簽名采集、客戶證件采集、營銷規(guī)則匹配等業(yè)務功能。2017年2月對無紙化系統(tǒng)進行了相關的擴容和優(yōu)化工作，“中小渠道”受理訂單接入無紙化、政企CRM營業(yè)無紙化受理優(yōu)化、代理商門戶翼受理無紙化優(yōu)化、實名制拍照功能優(yōu)化、移動端能力提升、無紙化平臺渠道維度信息優(yōu)化、集團產品本地無紙化平臺歸檔、電渠無紙化歸檔優(yōu)化、CRM的合同與受理資產掛鉤等。2018年6月在現(xiàn)有的營業(yè)廳無紙化平臺功能和能力上進行進一步優(yōu)化擴容，實現(xiàn)無紙化平臺優(yōu)化、電渠無紙化優(yōu)化、無紙化營銷規(guī)則調整優(yōu)化、移動端能力提升、營業(yè)廳前端程序升級改造、云桌面無紙化改造、新增實名影像人臉系統(tǒng)自動比對功能、實名拍照場景優(yōu)化、結對甩單優(yōu)化、實名拍照功能優(yōu)化、版本升級、無紙化平臺業(yè)務檔案存檔功能優(yōu)化、開放渠道人證合一影像數(shù)據(jù)提取等功能優(yōu)化。建設目標及需求用戶體驗組件根據(jù)智慧運營平臺應用界面設計的現(xiàn)狀分析以及未來集團基于云平臺的全國集中智慧運營平臺應用的原型研發(fā)的要求，智慧運營平臺應用原型的UE/UI設計需要完成覆蓋智慧運營平臺全業(yè)務的場景設計，主要包括訂單類場景、客戶類場景、計費賬務類場景、客戶管理類場景、批量受理類場景、員工類場景等的設計需求。當前智慧運營平臺設計中，產品在提高用戶與產品交互過程的體驗的同時，保證要產品能夠成功的定向對用戶傳達其價值，通過從增強產品的可用性，簡化操作，增加使用愉悅感，三方面改善客戶與產品間的交互體驗，從而提高用戶滿意度和使用體驗。統(tǒng)一數(shù)據(jù)訪問引擎（數(shù)據(jù)中間件）優(yōu)化當前智慧運營平臺系統(tǒng)將支持T級業(yè)務數(shù)據(jù)存儲，傳統(tǒng)單庫已經(jīng)無法滿足當前飛快的數(shù)據(jù)存儲和響應要求，使用分布式數(shù)據(jù)庫系統(tǒng)勢在必行，但是當前企業(yè)內的分布式系統(tǒng)在配置和生產使用過程中依然存在一些不足需要完善。提供一個數(shù)據(jù)庫分庫分表中間層，采用數(shù)據(jù)庫代理方式，形成分布式數(shù)據(jù)庫中間件解決方案，解決分布式系統(tǒng)數(shù)據(jù)庫分庫分表帶來的數(shù)據(jù)透明訪問難題。消息中間件優(yōu)化一般，我們認為消息中間件是指支持與保障分布式應用程序之間同步/異步收發(fā)消息的中間件。消息是分布式應用之間進行數(shù)據(jù)交換的基本信息單位，分布式應用程序之間的通信接口由消息中間件提供。其中，異步方式指消息發(fā)送方在發(fā)送消息時不必知道接收方的狀態(tài)，更無需等待接收方的回復，而接收方在收到消息時也不必知道發(fā)送方的目前狀態(tài)，更無需進行同步的消息處理，它們之間的連接完全是松耦合的，通信是非阻塞的，這種異步通信方式是由消息中間件中的消息隊列及其服務機制保障的。消息中間件是在消息的傳輸過程中保存信息的容器。消息中間件在將消息從源頭到達它的目標時充當中間人的作用。隊列的主要目的是提供路由并保證消息的傳遞；如果發(fā)送消息時接收者不可用，消息隊列會保留消息，直到可以成功地傳遞它為止，當然，消息隊列保存消息也是有期限的。本期工程主要對API、Broker消息節(jié)點實現(xiàn)、命令行與運維平臺進行優(yōu)化與完善。在對API、Broker消息節(jié)點實現(xiàn)方面，需要進行消息去重處理，在一期項目中已經(jīng)實現(xiàn)了消息獲取，但是存在大量的重復消息，但是在分布式架構下，單純依賴消息中間件難以實現(xiàn)完全去重，建議采用消息中間件增加消費去重處理+應用冪等性+運維手段結合的方式來達到消息完全不重復的目的。提供相應的告警機制處理消息簽收超時，同時對客戶端返回中間狀態(tài)提供相應機制確保消息結果的正確性；當增加新的消息隊列時，能夠增加新的對應的消費端；提供無序模式下消息跳躍性簽收處理功能等。完善運維平臺，為提高對消息中間件的使用體驗，增加消息數(shù)量、消費深度等信息查詢、節(jié)點、生產者、消費者在線監(jiān)控，實現(xiàn)對消息積壓及吞吐量的監(jiān)控，增加關鍵操作日志方便查看用戶操作，增加消息回溯及綜合查詢功能。另外支持消息中間件接入易監(jiān)控平臺。交易密集型應用原型優(yōu)化本期工程在內蒙古云基地現(xiàn)有IT云服務平臺基礎上，驗證平臺基礎能力組件，包括數(shù)據(jù)中間件組件、消息中間件組件、負載均衡組件、工作流引擎組件、分布式協(xié)調管理服務組件、事件驅動框架組件、安全中心組件、監(jiān)控與日志中心組件；同時在原有基于IT云服務能力平臺上開發(fā)的交易密集型應用原型和計算密集型應用原型，開展部分智慧運營平臺應用場景的優(yōu)化和驗證，通過原型驗證進一步評估IT云服務能力平臺近期承載集約智慧運營平臺核心應用的技術可行性和能力成熟度。本期工程主要建設內容包括：1)IT云服務能力平臺基礎能力驗證。IT云平臺為新一代集中、開放、云化IT架構的PaaS層，采用開放架構，高性能、可擴展，數(shù)據(jù)一點生成、全局共享，基于同一的底層平臺架構承載核心業(yè)務系統(tǒng)應用。本期建設內容包括數(shù)據(jù)中間件組件、消息中間件組件、負載均衡組件、工作流引擎組件、分布式協(xié)調管理服務組件、事件驅動框架組件、安全中心組件、監(jiān)控與日志中心組件。2)智慧運營平臺部分應用組件原型的優(yōu)化與場景驗證，用于進一步驗證IT云平臺的基礎能力。本期建設內容為選取部分智慧運營平臺應用的典型場景，開展部分場景功能優(yōu)化和驗證，包括分布式交易密集型和計算密集型的部分應用在云平臺架構環(huán)境下的功能健壯性和性能穩(wěn)定性。原型驗證涉及關鍵技術包括分布式文件系統(tǒng)、分布式數(shù)據(jù)庫、分布式緩存、數(shù)據(jù)中間件、消息中間件、負載均衡、工作流引擎、分布式協(xié)調管理服務、事件驅動框架、運維框架等。通過原型驗證評估IT云服務能力平臺近期承載集約智慧運營平臺核心應用的技術可行性和能力成熟度，為智慧運營平臺集約推進策略決策提供技術參考。監(jiān)控中心優(yōu)化本期工程主要新增部分功能，進一步完善監(jiān)控中心能力。新增分布式服務追蹤能力：收集分布式系統(tǒng)調用棧，并對調用鏈數(shù)據(jù)進行分析處理，處理的調用信息統(tǒng)一存貯；隨著業(yè)務發(fā)展，系統(tǒng)拆分導致系統(tǒng)調用鏈路愈發(fā)復雜一個前端請求可能最終需要調用很多次后端服務才能完成，當整個請求變慢或不可用時，我們是無法得知該請求是由某個或某些后端服務引起的，這時就需要解決如何快讀定位服務故障點，以對癥下藥。于是就有了分布式系統(tǒng)調用跟蹤的誕生。新增基礎數(shù)據(jù)管理能力，統(tǒng)一存貯應用信息及主機信息；統(tǒng)一存貯應用信息及主機信息,根據(jù)系統(tǒng)大小不同，每一部分的結構又有一定變化。譬如，對于大規(guī)模分布式系統(tǒng)，數(shù)據(jù)存儲可分為實時數(shù)據(jù)和全量數(shù)據(jù)兩部分，實時數(shù)據(jù)用于故障排查（TroubleShooting），全量數(shù)據(jù)用于系統(tǒng)優(yōu)化；數(shù)據(jù)收集除了支持平臺無關和開發(fā)語言無關系統(tǒng)的數(shù)據(jù)收集，還包括異步數(shù)據(jù)收集（需要跟蹤隊列中的消息，保證調用的連貫性），以及確保更小的侵入性；數(shù)據(jù)展示又涉及到數(shù)據(jù)挖掘和分析。雖然每一部分都可能變得很復雜，但基本原理都類似。新增WEB界面，提供標準化方式展示監(jiān)控數(shù)據(jù)；Zipkin的基礎架構UI組件，基于API組件實現(xiàn)的上層應用。通過UI組件用戶可以方便而有直觀地查詢和分析跟蹤信息。新增數(shù)據(jù)開放能力，為應用開發(fā)個性化監(jiān)控界面提供監(jiān)控數(shù)據(jù)獲取。在SpringCloudSleuth中對Zipkin的整合進行了自動化配置的封裝，所以我們可以很輕松的引入和使用它。分布式WEB項目建設隨著Internet/Intranet的普及和飛速發(fā)展,充分利用網(wǎng)絡資源、縮小時空地域限制,在互聯(lián)網(wǎng)上進行并行分布式處理,將成為今后計算機應用發(fā)展的一個重要方向，并且隨著業(yè)務越拆越小，應用系統(tǒng)整體復雜程度呈指數(shù)級上升，由于所有應用要和所有數(shù)據(jù)庫系統(tǒng)連接，最終導致數(shù)據(jù)庫連接資源不足，拒絕服務。所以公共的應用模塊被提取出來，部署在分布式服務器上供應用服務器調用。使用基于Web的分布式應用系統(tǒng)，用戶只要有標準的Browser(瀏覽器)軟件，即可訪問和使用計算機應用系統(tǒng)，而且用戶的計算機系統(tǒng)可以不受硬件平臺的限制。而這些服務之間的調用就要考慮網(wǎng)絡，負載，緩存，配置等問題。本期工程主要對分布式WEB項目涉及的DNS、負載均衡、網(wǎng)頁緩存、文件中心、Session管理、配置管理及監(jiān)控等功能進行建設。分布式數(shù)據(jù)庫企業(yè)在支撐系統(tǒng)建設中一直以來采用Oracle數(shù)據(jù)庫，并利用小型機和高端存儲設備提供高性能的數(shù)據(jù)處理和存儲服務。隨著業(yè)務的不斷發(fā)展，數(shù)據(jù)量和業(yè)務量呈爆發(fā)性增長，傳統(tǒng)的集中式Oracle數(shù)據(jù)庫架構在擴展性方面遭遇瓶頸。傳統(tǒng)的商業(yè)數(shù)據(jù)庫軟件(Oracle、DB2)，多以集中式架構為主，其最大特點就是將所有的數(shù)據(jù)都集中在一個數(shù)據(jù)庫中，依靠大型高端設備來提供高處理能力和擴展性。集中式數(shù)據(jù)庫的擴展性主要采用向上擴展(Scaleup)的方式，通過增加CPU、內存、磁盤等方式提高處理能力。這種集中式數(shù)據(jù)庫的架構，使得數(shù)據(jù)庫成為了整個系統(tǒng)的瓶頸，已經(jīng)越來越不適應海量數(shù)據(jù)對計算能力的巨大需求。為解決此問題，本期工程總結業(yè)界基于Mysql的高可用數(shù)據(jù)庫集群方案基礎上提出了TeleDB數(shù)據(jù)高可用方案。分布式數(shù)據(jù)庫系統(tǒng)通常使用較小的計算機系統(tǒng)，每臺計算機可單獨放在一個地方，每臺計算機中都可能有DBMS的一份完整拷貝副本，或者部分拷貝副本，并具有自己局部的數(shù)據(jù)庫，位于不同地點的許多計算機通過網(wǎng)絡互相連接，共同組成一個完整的、全局的邏輯上集中、物理上分布的大型數(shù)據(jù)庫。服務框架企業(yè)集團正在推進IT架構互聯(lián)網(wǎng)化改革并推進智慧運營平臺系統(tǒng)集中工程，智慧運營平臺集中架構采用全分布式架構，新架構各業(yè)務系統(tǒng)及平臺組件大量采用REST協(xié)議開發(fā)系統(tǒng)間接口。本組件“服務框架”實現(xiàn)大量分布式服務的統(tǒng)一治理，為應用提供標準的運行容器，設計統(tǒng)一的接口協(xié)議，并為應用服務提供統(tǒng)一入口、服務路由、訪問控制、負載均衡、高可用、安全認證、服務監(jiān)控及審計日志等基礎能力服務，并為服務提供統(tǒng)一服務目錄。DFS企業(yè)全國話單文件數(shù)據(jù)量非常大，計費系統(tǒng)在實時處理話單的時候文件很碎，會產生巨大數(shù)量的小文件。巨大數(shù)量的小文件會給HDFS帶來巨大的沖擊，HDFS存貯不適合存放小文件，應專門為小話單文件設計存貯方案。本方案采用將多個邏輯小文件合并成一個物理大文件方式實現(xiàn)小文件在HDFS上存貯，該方案可以使用在任何需要用HDFS存貯小文件場景。開發(fā)DFS文件系統(tǒng)，核心功能包括元數(shù)據(jù)管理及數(shù)據(jù)存貯管理，并提供與HDFS一致的開發(fā)API，支持C++/JAVA語言對文件進行讀寫操作；支持Mapreduce并行處理框架；支持REST方式調用。為配套平臺監(jiān)控，需要將指標推送到監(jiān)控中心。提供文件系統(tǒng)相關配套，包括文件操作命令集及文件系統(tǒng)健康檢查。結構化數(shù)據(jù)服務隨著企業(yè)流量經(jīng)營的逐步深入，無論企業(yè)內部還是外部用戶對流量使用的服務需求日趨強烈。在處理用戶流量相關投訴時，基于現(xiàn)有的客服系統(tǒng)手段難以解釋用戶何時、何地訪問哪些網(wǎng)址或應用導致高流量；面對計費爭議，企業(yè)也無法提供流量產生的依據(jù)，只能協(xié)商退還費用。所以，建設并完善移動用戶上網(wǎng)記錄查詢功能（包括上網(wǎng)流量詳單及更詳細的流量軌跡記錄查詢），通過對用戶上網(wǎng)內容的解析實現(xiàn)洞察用戶、分析用戶上網(wǎng)行為，以支撐流量經(jīng)營、流量服務。流量軌跡記錄數(shù)據(jù)量十分巨大，據(jù)統(tǒng)計全國每天數(shù)據(jù)量約20T，如果提供6月在線數(shù)據(jù)查詢，總數(shù)據(jù)量達4PB，基于現(xiàn)有技術方案，無法提供如此巨大數(shù)據(jù)在線實時查詢。本期組件“結構化數(shù)據(jù)服務”，基于多個開源技術組件設計數(shù)據(jù)結構及存貯方案，滿足超大量數(shù)據(jù)存貯，并提供實時查詢接口，為“流量軌跡數(shù)據(jù)實時查詢”提供解決方案，同時支持SQL及MapReduce并行處理框架。密集型計算框架為貫徹企業(yè)深化改革的要求，落實IT深化改革的具體舉措，構建集中、開放的云化IT架構，按照集團公司領導對簽報《關于以互聯(lián)網(wǎng)思維實現(xiàn)核心業(yè)務系統(tǒng)（智慧運營平臺）集中的建議》（2014【351】號）的指示精神，企業(yè)信息化事業(yè)部計劃采用平臺加應用的方式構建全網(wǎng)統(tǒng)一的IT云服務能力平臺以及基于云平臺的全國集中智慧運營平臺應用的原型研發(fā)。在2015年IT云服務平臺關鍵技術專題能力建設中，提出了建設密集計算框架，用于解決集約計費面臨的海量數(shù)據(jù)計算的問題。基于IT云服務能力平臺的集中計費系統(tǒng)技術架構示意如下圖所示，主要實現(xiàn)采集分發(fā)節(jié)點、計費節(jié)點部分基本功能原型，驗證平臺的分布性能、故障恢復、平滑擴展等問題。分布式事務系統(tǒng)使用分布式數(shù)據(jù)庫（TeleUDAL+TeleDB）后，一個事務如果涉及到多個物理數(shù)據(jù)庫節(jié)點操作，可能會出現(xiàn)部分物理節(jié)點處理成功、部分失敗的中間狀態(tài)，按照傳統(tǒng)的數(shù)據(jù)庫操作方式無法保障數(shù)據(jù)的一致性及可用性，這就是我們在分布式數(shù)據(jù)庫中需要解決的分布式事務問題。在分布式數(shù)據(jù)庫中，事務邊界越大(或者單個SQL所執(zhí)行的數(shù)據(jù)分片數(shù))，那么系統(tǒng)的鎖沖突概率越高，系統(tǒng)越難以擴展，性能越低。因此，若想將系統(tǒng)做到很好的擴展性，那么一個最重要的原則就是想辦法劃小事務邊界，并盡可能讓事務的邊界限制在單臺機器內?？s小事務邊界的方式，主要有以下三類：第一種方式：事務邊界本來就很小比如，按照某個切分條件，數(shù)據(jù)分布均勻，并且事務邊界只在單機內，那么這個事務就是單庫事務，目前TeleUDAL已支持單庫事務。第二種方式：使用基于消息的最終一致模型，將強一致事務變?yōu)樽罱K一致事務將一個大的事務拆解成多個單庫事務，分別處理，使用異步消息+冪等性來保障數(shù)據(jù)的最終一致性，此方式由應用自行處理。第三種方式：謹慎的使用分布式事務使用最終一致性事務，一般只能解決90%的業(yè)務場景，剩下的一些場景，可能還是需要使用分布式事務方式完成。但分布式事務必然帶來非常多的性能問題，因此，我們只建議在不得不使用分布式事務的時候，才使用。對于第三種方式，我們需要結合TeleUDAL及TeleDB現(xiàn)有功能研發(fā)分布式事務組件，為應用系統(tǒng)提供分布式事務解決方案。分布式任務調度系統(tǒng)任務定時調度是指基于給定時間點、給定時間間隔或者給定執(zhí)行次數(shù)自動執(zhí)行任務。目前業(yè)界存在的幾種任務定時調度，主要采用Timer，SpringTask,ScheduleExecutorService，Quartz等技術實現(xiàn)。作為分布式集群環(huán)境的定時任務調度系統(tǒng)，目前開源方案主要有easySchedule、elastic-job、ligth-task-scheduler、uncode-schedule，但都存在一定的不足。easySchedule自2012年之后已不再維護，同時只支持HTTP任務。elastic-job是一個無調度中心的分布式彈性作業(yè)框架，作業(yè)運行的狀態(tài)數(shù)據(jù)保存在Zookeeper節(jié)點，在作業(yè)量較大的情況，嚴重影響調度的實時性和準確性；同時運維平臺操作不方便，功能較簡單，缺乏監(jiān)控、統(tǒng)計、告警的能力。ligth-task-scheduler的實現(xiàn)參考了dubbo架構，采用眾多技術，存在過度設計的情況；同時架構上分成了4種不同類型的節(jié)點，提高了部署和運維的難度；缺乏統(tǒng)一的任務配置功能。uncode-schedule是基于zookeeper+springtask/quartz的分布式任務調度組件，確保所有任務在集群中不重復，不遺漏的執(zhí)行。支持動態(tài)添加和刪除任務。但存在任務的開發(fā)必須依賴于springtask的限制。在線交易應用框架在線交易應用框架包括開發(fā)者門戶、應用引擎以及在線交易定制引擎三方面內容。其中：開發(fā)者門戶功能主要是實現(xiàn)對應用的開發(fā)、構建、部署的跟蹤管理；應用引擎功能主要是對現(xiàn)有云平臺的公共組件進行封裝，提供給應用調用使用；在線交易定制引擎是根據(jù)應用公共特點，在應用引擎基礎之上，針對各類應用公共特征而定制的一套組件庫和服務庫，以快速支撐各類應用功能。跨IDC數(shù)據(jù)同步功能跨IDC數(shù)據(jù)復制的目的通過加速數(shù)據(jù)復制控制數(shù)據(jù)沖突時間范圍來減少IDC間的不一致數(shù)據(jù)?？鏘DC數(shù)據(jù)同步是一種集數(shù)據(jù)遷移、數(shù)據(jù)實時同步于一體的數(shù)據(jù)傳輸服務。解決遠距離、毫秒級異步數(shù)據(jù)傳輸難題?？鏘DC數(shù)據(jù)同步組件主要包括以下應用場景：異構數(shù)據(jù)遷移，增量數(shù)據(jù)同步，災備系統(tǒng)。數(shù)據(jù)能力開放企業(yè)集團正在推進IT架構互聯(lián)網(wǎng)化及智慧運營平臺系統(tǒng)集中工程，智慧運營平臺系統(tǒng)集中后，各類業(yè)務數(shù)據(jù)如客戶資料、用戶詳單等數(shù)據(jù)隨著系統(tǒng)集中而集中。數(shù)據(jù)隨著集中后，省級系統(tǒng)及合作伙伴等存在數(shù)據(jù)使用需求，要求集中后系統(tǒng)具備向數(shù)據(jù)需求方提供數(shù)據(jù)能力。另外，智慧運營平臺域內部系統(tǒng)之間也存在數(shù)據(jù)共享需求。由于數(shù)據(jù)分散在集中后的各子系統(tǒng)，數(shù)據(jù)形態(tài)各異，大小不一，數(shù)據(jù)開放需要考慮數(shù)據(jù)開放協(xié)議、數(shù)據(jù)安全、認證及數(shù)據(jù)轉換等問題。如果由各子系統(tǒng)獨立開放接口，會造成域內系統(tǒng)間、省級系統(tǒng)和合作伴系統(tǒng)依賴混亂，不利于統(tǒng)一協(xié)議及管理數(shù)據(jù)安全。數(shù)據(jù)能力開放平臺就是為了解決集團集中智慧運營平臺域內子系統(tǒng)間數(shù)據(jù)共享、向省級系統(tǒng)及合作伙伴實現(xiàn)數(shù)據(jù)開放。分布式緩存隨著業(yè)務發(fā)展，需要緩存的數(shù)據(jù)越來越大，例如計費系統(tǒng)緩存的客戶資料數(shù)據(jù)已達到T以上，這些數(shù)據(jù)目前集中部署在小型機的共享內存上，數(shù)據(jù)規(guī)模已經(jīng)達到單臺主機的內存瓶頸,后續(xù)擴容成本高昂。且在大規(guī)模并發(fā)訪問情況下，系統(tǒng)速度慢和數(shù)據(jù)利用率低的問題大大制約了整體系統(tǒng)性能;目前迫切需要引入分布式緩存技術，解決以下關鍵性問題：1.將已有部署在小型機的巨大的共享內存，分別部署到多臺pcserve上；形成分布式緩存，節(jié)約成本，又便于應用分布化；2.業(yè)務不斷增長的數(shù)據(jù)實時擴展需求,系統(tǒng)彈性伸縮性瓶頸;3.大規(guī)模并發(fā)的數(shù)據(jù)I/O性能瓶頸，減輕數(shù)據(jù)庫的負載壓力，提高事務吞吐率、降低系統(tǒng)延時。項目技術方案總體建設技術方案總體概述系統(tǒng)各項技術應遵循企業(yè)相關標準和技術體制；我方應向甲方提供完整、最新而成熟的系統(tǒng)軟硬件等技術和產品，并需經(jīng)過企業(yè)的測試驗證。其各項技術應保證具有開放性、可移植性、兼容性和可擴展性。系統(tǒng)配置的軟件和硬件設備提供開放的應用接口，可以方便地與其他廠家同類型應用系統(tǒng)進行軟、硬件平臺互連，便于系統(tǒng)未來的擴展；我方應提供快速、有效、功能全面的網(wǎng)絡管理系統(tǒng)，包括軟硬件管理服務模塊和專用工具，具有設備配置、統(tǒng)計分析、告警等管理功能；并具備向上連接到集團網(wǎng)管的能力；本項目涉及的軟硬件設備提供商可能不只一家，因此在遵循本技術規(guī)范的基礎上，要求我方應與各設備提供商在系統(tǒng)集成方面提供充分的合作和技術支持；在工程實施中，不同的承建系統(tǒng)集成商由甲方統(tǒng)一協(xié)調，各設備提供商須積極配合，涉及到的互連接口，必須提供具體技術細節(jié)資料；我方提供的應用軟件保修期兩年，保修期自買賣雙方簽訂終驗證書之日起開始計算。系統(tǒng)設計企業(yè)IT基礎架構云服務能力擴容建設項目在總體設計上應滿足以下要求：規(guī)范和標準符合性：系統(tǒng)應符合其他IT相關規(guī)范標準、符合企業(yè)IT云服務能力平臺規(guī)范及各項工程項目標準。技術先進成熟性：采用成熟、合理、先進的技術，在選用系統(tǒng)組件（中間件等）時要在保證其成熟性和可靠性的同時保證系統(tǒng)建設的適度先進性。安全性和可靠性：系統(tǒng)針對主機、數(shù)據(jù)庫、網(wǎng)絡、應用等各層次要制定相應的安全策略和可靠性策略，保障系統(tǒng)的安全性和可靠性，應用軟件應具有處理各種非正常狀態(tài)和事件的能力。開放性：系統(tǒng)應采用多層開放式體系結構，具有清晰的體系結構。提供靈活的二次開發(fā)手段，在面向對象的業(yè)務組件應用框架上，能夠在不影響系統(tǒng)情況下快速開發(fā)新業(yè)務，同時提供方便地對業(yè)務進行修改和動態(tài)加載的支持。系統(tǒng)集成靈活性：系統(tǒng)采用基于工業(yè)標準，如LDAP、WEBSERVICE、J2EE、XML、HTTP、SSL、JSON等技術，與集團相關業(yè)務平臺或系統(tǒng)對接并集成。松耦合和可擴展性：系統(tǒng)應具有良好的伸縮性，可以隨業(yè)務規(guī)模的增長平滑擴展；要能夠支持多個層面的可擴展性，通過負載平衡、快速開發(fā)/重組、業(yè)務參數(shù)配置等多個方面使得系統(tǒng)可以支持企業(yè)未來不斷變化的業(yè)務需求。系統(tǒng)體系結構設計遵循松耦合、模塊化的原則，采用軟件總線、組件設計方式以保證應用系統(tǒng)的靈活性，適應個性化的需求；我方保證對外接口的開放性，支持與不同廠商設備間的互連（包括支撐系統(tǒng)、業(yè)務平臺等）；我方應滿足系統(tǒng)在大業(yè)務量下的實時、并發(fā)處理的性能要求；我方應提供設備的在線擴容，包括在線擴展CPU、內存，及擴展集群點；我方所提供系統(tǒng)采用集中式結構（分布采集、集中處理、集中存儲），同時提供一定的分級分權管理機制；我方在建議書應對系統(tǒng)所采用的體系結構、采用的技術、實現(xiàn)方式、編程語言進行詳細的闡述；我方所提供系統(tǒng)應進行良好的分層和封裝，并在建議書中對軟件分層和封裝進行詳細說明。系統(tǒng)質量保障系統(tǒng)可靠性我方向需求方提供成熟的、穩(wěn)定、容錯性和易恢復性俱佳的系統(tǒng)。在我方的應標書中應明確指明其系統(tǒng)的MTTR和MTBF指標（分軟、硬件）。排除人為誤操作因素，由應用系統(tǒng)自身原因導致的系統(tǒng)崩潰故障,平均無故障時間（MTBF）應大于365天，平均修復時間（MTTR）應小于4小時。排除人為誤操作因素，由應用系統(tǒng)自身原因導致的系統(tǒng)錯誤故障,平均無故障時間（MTBF）應大于100天，平均修復時間（MTTR）應小于30分鐘。隨系統(tǒng)提交的技術文件必須明確標識出所實現(xiàn)的可度量的功能和性能指標。應用系統(tǒng)必須支持連續(xù)7×24小時不間斷地工作，應用軟件中的任一構件更新、加載時，在不更新與上下構件的接口的前提下，不影響業(yè)務運轉和服務。系統(tǒng)必須采用增量備份和全備份相結合的方式定期備份重要的系統(tǒng)數(shù)據(jù)。應用系統(tǒng)在業(yè)務處理高峰時，各主機設備的內存利用率應該不大于70%，CPU平均空閑率不低于30%。應用系統(tǒng)必須支持負載均衡能力，支持應用部署在多臺服務器上，避免應用系統(tǒng)的單點故障。應用系統(tǒng)應具有良好的并行處理機制，對存取沖突的競爭具有有效的仲裁和加鎖機制，充分保證事務處理的完整性，并降低系統(tǒng)I/O開銷，提高并發(fā)用戶查詢和存取的性。系統(tǒng)具備完備的功能性系統(tǒng)應依據(jù)本規(guī)范書實現(xiàn)完善、準確的功能。系統(tǒng)具備完整性和安全性系統(tǒng)提供有效的安全保密措施，確保系統(tǒng)和數(shù)據(jù)資源的安全，防止對系統(tǒng)資源的非法侵入，入侵檢測系統(tǒng)應對違背安全事件記錄并報警；我方應提供有關網(wǎng)絡安全的詳細說明，公網(wǎng)上傳輸?shù)臄?shù)據(jù)，必須以國家標準的加密算法加密，并在應標書列出算法及相關軟件列表。系統(tǒng)應該充分利用防火墻、安全證書、SSL等數(shù)據(jù)加密技術保證系統(tǒng)與數(shù)據(jù)的安全。通過防火墻（硬件防火墻）對進入內部網(wǎng)絡的數(shù)據(jù)包進行掃描過濾，能夠根據(jù)用戶、IP地址、訪問類型等方式進行訪問規(guī)則限制。系統(tǒng)必須能夠對常見的入侵行為進行判斷并阻止。提供地址翻譯功能，屏蔽網(wǎng)絡內部細節(jié)，防止外部黑客利用IP探測技術發(fā)現(xiàn)內部網(wǎng)絡結構和服務器真實地址，從而實現(xiàn)有針對性的攻擊。系統(tǒng)必須能夠對網(wǎng)絡通訊進行監(jiān)控，及時發(fā)現(xiàn)任何來自于網(wǎng)絡內部或外部的黑客入侵或可疑的訪問行為，并做到及時報警與阻斷。我方提供的方案必需保證傳輸安全，網(wǎng)絡層需認證報文的來源，防止攻擊者利用偽裝地址來發(fā)送報文，確保報文在網(wǎng)絡中傳輸時沒有發(fā)生變化，確保報文內容在傳輸過程中未被讀取，確保未授權方不能讀取報文的內容，確保認證報文沒有重復，避免攻擊者通過重發(fā)截獲的認證報文來干擾正常的通信。系統(tǒng)必須周期性地備份系統(tǒng)文件（不含文件傳輸?shù)慕涌诰彌_區(qū)，緩沖區(qū)中的內容備份在系統(tǒng)接口數(shù)據(jù)備份的章節(jié)描述），能夠在系統(tǒng)崩潰后快速修復系統(tǒng)文件。不同的操作員具有不同的數(shù)據(jù)訪問權限和功能操作權限，系統(tǒng)管理員應能對各操作員的權限進行配置和管理。系統(tǒng)必須支持對系統(tǒng)運行所必須的用戶名與密碼周期性更改的要求。系統(tǒng)必須強制實現(xiàn)操作員口令安全規(guī)則，如限制口令長度、限定口令修改時間間隔等，保證其身份的合法性。系統(tǒng)必須支持操作失效時間的配置。當操作員在所配置的時間內沒有對界面進行任何操作則該應用自動失效。系統(tǒng)必須提供完善的審計功能，對系統(tǒng)關鍵數(shù)據(jù)的每一次增加、修改和刪除都能記錄相應的修改時間、操作人和修改前的數(shù)據(jù)記錄。系統(tǒng)的審計功能必須提供根據(jù)時段、操作員、關鍵數(shù)據(jù)類型等條件組合查詢系統(tǒng)的審計記錄。系統(tǒng)的審計功能必須提供針對特定關鍵數(shù)據(jù)查詢歷史審計記錄。系統(tǒng)易用性系統(tǒng)應易于安裝和使用，具備風格一致的用戶界面，且為中文操作界面,為方便使用，系統(tǒng)應設置導航欄等內容。系統(tǒng)應能在瀏覽器中完成基本管理任務，對用戶輸入錯誤應盡早發(fā)現(xiàn)和提醒系統(tǒng)應具備完善的聯(lián)機幫助功能。隨系統(tǒng)提交的產品文件必須包括完善的、針對不同級別用戶的應用系統(tǒng)培訓教材、培訓考題及培訓考核方法建議。廠家可以通過對產品頒發(fā)資格認證證書的方式，以確認用戶對該產品的某個操作級別的使用資格。對于業(yè)務熟練并且熟悉電腦操作的普通用戶，應該可以通過現(xiàn)場培訓，即可熟練掌握應用系統(tǒng)基本功能的操作技能。對于系統(tǒng)管理員，應該可以通過不超過累計兩周的培訓，即可熟練掌握應用系統(tǒng)管理相關功能的操作技能。應用系統(tǒng)必須提供一致性的圖形用戶界面風格。應用系統(tǒng)對普通用戶的操作界面應該以B/S方式實現(xiàn)。應用系統(tǒng)應該支持操作員登錄系統(tǒng)后，不超過三次鼠標的點擊，即可訪問到業(yè)務所需功能。應用系統(tǒng)必須支持同時打開多個管理窗口以對不同任務進行并行的操作。應用系統(tǒng)應該支持在一個業(yè)務過程中的所有功能界面都有返回上一個操作的快捷鏈接。應用系統(tǒng)應該支持通過鍵盤即可完成一個界面窗口內的主要操作。應用系統(tǒng)應支持通過Tab鍵或回車鍵可訪問到同一個窗口的所有控件對象。應用系統(tǒng)應該支持對于常用功能設置快捷鍵以方便功能間的切換；快捷鍵的功能定義在全系統(tǒng)保持一致。應用系統(tǒng)必須采用分頁機制顯示查詢結果，并顯示返回的記錄數(shù)目、當前頁和總頁數(shù)。應用系統(tǒng)發(fā)現(xiàn)用戶提交有誤信息，必須以彈出窗口的形式明確提示用戶錯誤的原因，并把界面控制焦點置于發(fā)生錯誤的控件對象上。應用系統(tǒng)的操作界面必須用“*”明確標識出必填的輸入信息。當應用系統(tǒng)正在執(zhí)行用戶提交的請求而無法返回時，必須明確標識系統(tǒng)處于繁忙階段。系統(tǒng)可維護性具備完備的數(shù)據(jù)備份和恢復機制。系統(tǒng)具備方便且可定期執(zhí)行、分析結果的業(yè)務測試功能。系統(tǒng)應易于修改，對某一個模塊的修改，不影響其他模塊的正常運行。系統(tǒng)應易于擴展，新增服務時要求對系統(tǒng)做盡可能少的修改。系統(tǒng)應具備自管理和監(jiān)控功能，能夠實時監(jiān)控各模塊的執(zhí)行。我方提供的系統(tǒng)應具備利用甲方已有時間同步系統(tǒng)進行時間同步和時間自動調整的功能。我方提供的系統(tǒng)應具備在線升級協(xié)議及版本的功能，在不中斷業(yè)務的情況下支持對系統(tǒng)外部接口協(xié)議進行在線升級、對修改后的系統(tǒng)版本進行在線升級。系統(tǒng)在運行過程中所發(fā)生的任何錯誤都應該有明確的錯誤編號，并能在系統(tǒng)的相應維護手冊中查到錯誤處理方法與步驟。應用系統(tǒng)應該支持通過統(tǒng)一的圖形界面，監(jiān)控各應用構件的運行狀態(tài)。應用系統(tǒng)必須支持通過統(tǒng)一的圖形界面，能夠監(jiān)控到應用系統(tǒng)所有的報警、異常信息。應用系統(tǒng)應該采用構件化設計思想，系統(tǒng)框架與業(yè)務邏輯分離；要求具備開放的體系結構。應用系統(tǒng)應該支持通過統(tǒng)一的圖形界面能夠訪問到系統(tǒng)各構件、合約的版本信息及相應功能說明。系統(tǒng)完備性我方根據(jù)本規(guī)范書要求提出的方案及設備配置，必須能完成網(wǎng)絡連接及所有要求的功能，不存在電纜、網(wǎng)卡或其它附件的短缺，不存在本期工程設備和軟件性能不滿足業(yè)務需求和系統(tǒng)功能的情況，否則我方須在兩周內免費補齊所缺設備和軟件。系統(tǒng)可擴展性系統(tǒng)應可以隨時增加網(wǎng)絡設備或模板來擴展整個網(wǎng)絡,可以不增加任何投資，通過選擇通訊協(xié)議和接入通信速率來提高網(wǎng)絡傳輸速度，降低系統(tǒng)運行費用。應易于擴容和維護。能支持平滑無中斷在線擴容或新增業(yè)務。系統(tǒng)可測試性隨系統(tǒng)提交的技術文件必須明確標識出所實現(xiàn)可度量的功能和性能指標。我方應有固定的測試工程師進行專門的測試工作，每次新功能測試完成后，應提供詳細的測試文檔，包括測試的用例、方法及其結果等，交付局方人員作驗收測試。測試結果應符合實際，測試未通過的項目應及時反饋并進行修改。系統(tǒng)可移植性應用系統(tǒng)應該不需改動或盡可能少的改動就可以在不同的主流UNIX服務器（如IBM、HP、SUN等）或PCserver服務器（包括虛擬機）上方便地移植。系統(tǒng)必須對于存儲設備、備份設備及各種網(wǎng)絡設備具有完全無關性。應用系統(tǒng)必須支持在不同主流數(shù)據(jù)庫平臺（ORACLE、Informix、sybase等）間的移植。移植時不允許修改業(yè)務邏輯構件，應該盡可能少地修改直接操作數(shù)據(jù)庫的信息服務構件。應用系統(tǒng)必須支持在不同主流中間件平臺（如Weblogic、Websphere等）間的移植。系統(tǒng)易安裝性應用系統(tǒng)應該提供圖形化的安裝與配置界面。應用系統(tǒng)必須支持客戶端軟件版本的自動升級。功能可擴展性IT內控補充細則我方提供的系統(tǒng)必須符合企業(yè)內控的要求，要求至少支持但不限于以下要求。提供多種管理員角色系統(tǒng)管理員：系統(tǒng)管理員負責對該系統(tǒng)所涉及的硬件和軟件配置的集中管理，包含性能管理、故障配置、安全管理、配置管理和統(tǒng)計功能等。日志管理員：日志管理員負責檢查業(yè)務平臺應用程序、操作系統(tǒng)和數(shù)據(jù)庫層面安全日志記錄（含對于重要的數(shù)據(jù)增、刪、改操作），監(jiān)督系統(tǒng)管理員和業(yè)務管理員執(zhí)行的敏感操作，可通過瀏覽管理員操作日志來取得系統(tǒng)的所有管理操作信息。業(yè)務管理員：業(yè)務管理員負責對該系統(tǒng)所提供的業(yè)務的管理，如業(yè)務流程管理、業(yè)務排行管理、業(yè)務版面管理、業(yè)務接入管理、業(yè)務內容接入管理、業(yè)務合作管理業(yè)務發(fā)展數(shù)據(jù)和使用情況的分析和統(tǒng)計管理等。系統(tǒng)的數(shù)據(jù)備份和數(shù)據(jù)恢復管理系統(tǒng)應提供安全可靠的聯(lián)機數(shù)據(jù)備份功能；我方應提供有關數(shù)據(jù)備份的詳細說明，根據(jù)局方的備份要求，提出具體的備份機制建議，包括備份方式、備份周期、備份介質、備份保留時間和相關軟件的列表，備份策略的制定必須充分考慮到出現(xiàn)異常時數(shù)據(jù)的恢復。我方應根據(jù)1）中對備份的需求以及系統(tǒng)現(xiàn)狀，提出備份配置方案，并進行詳細的說明。對業(yè)務平臺的備份，系統(tǒng)必須提供和保留備份日志（自動或手工記錄方式），以便運維人員每日復核備份日志，以發(fā)現(xiàn)備份錯誤或其它異常現(xiàn)象。能夠在線完成數(shù)據(jù)備份和恢復的功能。日志管理和監(jiān)控功能日志包括系統(tǒng)運行日志、系統(tǒng)和業(yè)務管理員操作日志兩個部分。日志由平臺系統(tǒng)生成，并自動進行存檔保存。日志應分為幾種級別，由高至低，較低級別的日志是較高級別的子集合。系統(tǒng)具備自動監(jiān)控或人工監(jiān)控業(yè)務平臺的生產環(huán)境的工具和功能，及時發(fā)出系統(tǒng)故障告警，短信、郵件、信息提示等多種方式告警。必須提供自動或人工記錄方式的監(jiān)控結果日志保存功能。信息系統(tǒng)的邏輯訪問和物理訪問在系統(tǒng)中采用用戶身份的驗證機制，對系統(tǒng)的訪問必須使用用戶名和密碼或者其他身份驗證機制（例如USBKEY），而且每個用戶帳號被授予唯一的用戶。系統(tǒng)維護部門對訪問系統(tǒng)（包括操作系統(tǒng)、數(shù)據(jù)庫和應用程序層面）的用戶（含超級用戶）制定密碼政策，并根據(jù)密碼政策在系統(tǒng)固化相應的設置，以避免用戶使用安全級別低的密碼。密碼政策應包括:用戶密碼長度最低位數(shù)的規(guī)定，密碼定期更換的規(guī)定，不得使用最近的密碼。對于使用密鑰棒或動態(tài)密碼卡的系統(tǒng)，需要配合使用由用戶掌握的PIN碼。獨立于系統(tǒng)管理員的日志管理員負責每周檢查平臺應用程序、操作系統(tǒng)和數(shù)據(jù)庫層面安全日志記錄（含對于重要的數(shù)據(jù)增、刪、改操作），發(fā)現(xiàn)異常現(xiàn)象應于3日內跟進或上報。安裝平臺應用程序、操作系統(tǒng)和數(shù)據(jù)庫的硬件設備存放在安全的機房中。所有出入口均具備電子門禁系統(tǒng)或門鎖的保護。只有經(jīng)授權的人員可對存放平臺設備的計算機機房和設備進行物理訪問。對機房的訪問授權須經(jīng)系統(tǒng)維護部門主管審批。非授權人員出入機房必須由機房工作人員陪同。人員進出機房會在機房門禁系統(tǒng)或機房進出日志中留下記錄。對IPv6的支持我方提供的軟硬件應能支持IPv4/IPv6雙棧（需支持IPv6功能，支持IPv6終端用戶的訪問，提供基于IPv6的業(yè)務），如暫時不能支持，我方應承諾免費升級至支持IPv4/IPv6雙棧的版本。對云計算的支持我方提供的軟件應能支持云計算技術，如暫時不能支持，我方應承諾免費升級至支持云計算技術的版本。詳細建設技術方案在以下功能要求中，如果系統(tǒng)需進行周期性操作，要求實現(xiàn)周期可配置；如不特別說明，系統(tǒng)所配置的缺省參數(shù)均為本規(guī)范書所提出的要求?？傮w設計總體架構主要架構說明：應用展現(xiàn)層Pdf編輯器使用了VC的MFC框架實現(xiàn)，雙屏監(jiān)控及廣告播放采用.net的c#實現(xiàn)。頁面展示主要是通過客戶端瀏覽器給客戶提供服務的，此部分采用了jsp動態(tài)頁面技術，jquery腳本語言（基于javascript），easyUIFramework提供的前段布局樣式。中間件層中間件層主要實現(xiàn)了請求的控制及轉發(fā)，給客戶展現(xiàn)的數(shù)據(jù)封裝等工作。此部分采用了Nginx。管理及服務層在管理及服務層中是實現(xiàn)了系統(tǒng)的主要業(yè)務邏輯，系統(tǒng)通過業(yè)務邏輯層訪問數(shù)據(jù)層，實現(xiàn)業(yè)務處理的事務性，異步性等許多與需求密切相關的業(yè)務。同時，業(yè)務邏輯子層又對外提供了一個統(tǒng)一的接口，調用者無需了解業(yè)務邏輯的具體實現(xiàn)。此部分主要采用了spring的業(yè)務Bean的方式，統(tǒng)一用spring容器托管，給對外提供的接口方面采用了ApacheCXF開源的Services框架。應用安全層主要定義object與RDB（表）的映射關系，用xml格式保存映射關系。通過數(shù)字證書托管、密鑰存儲、數(shù)字簽名及加密算法實現(xiàn)。數(shù)據(jù)庫層數(shù)據(jù)訪問子層是為業(yè)務邏輯子層提供數(shù)據(jù)訪問接口，此部分采用了Hibernate框架，通過Hibernate，一方面實現(xiàn)了ORM映射，另一方面可以實現(xiàn)數(shù)據(jù)庫的無縫遷移。系統(tǒng)流程系統(tǒng)數(shù)據(jù)流程見下圖：功能架構服務平臺是云化IT架構的核心組成部分，基于統(tǒng)一的共享PaaS使能平臺，可以面向企業(yè)不同域的業(yè)務系統(tǒng)，實現(xiàn)統(tǒng)一的技術架構、統(tǒng)一的運營體系、統(tǒng)一的運維團隊，以及組件的分布部署。PaaS平臺平臺技術以微服務和DevOps為核心理念提供統(tǒng)一的技術架構和運營體系，平臺向上提供分布式服務框架與分布式基礎技術組件，簡化開發(fā)分布式微服務應用的過程，提升開發(fā)微服務應用的效率，降低開發(fā)微服務應用的技能要求。向下提供多租戶管理能力，開發(fā)運維門戶，DevOps系統(tǒng)，管理調度等能力，形成應用從開發(fā)到運維的生命周期閉環(huán)管理，功能架構圖如下。建設原則本工程在建設過程中需要從系統(tǒng)的先進性、可擴展性、安全可靠性、投資保護原則等諸多方面給予全面的考慮：先進性、標準性原則本工程新增設備應具有國際先進性，應符合國內外相關標準、規(guī)范。安全、可靠性本工程新增設備應具備高度的安全、可靠性。大容量原則本期系統(tǒng)的建設在設備配置、系統(tǒng)規(guī)模等方面應滿足大容量、適度超前的原則，綜合考慮本期以及未來可能建設的OSS域相關系統(tǒng)的需要。投資保護原則本工程的建設應盡量利用現(xiàn)網(wǎng)及集團同期建設的企業(yè)2016年集團云資源池內蒙節(jié)點A擴容工程的軟硬件設備，以降低建設成本，充分保護企業(yè)原有的投資。建設方案用戶體驗組件用戶體驗是人對于使用一個產品、系統(tǒng)、服務時的預期和反應。從廣義上來看，體驗的主體是人，客體可以是一切物體和事情，媒介是我們的感官；當我們的感官作用在一切事物上，會產生相應的心理行為，比如預期，比如反饋，比如情緒，這所有的一切一起作用，形成了用戶體驗過程。用戶體驗設計的目標是逐步不斷提升用戶滿意度，對于用戶而言，永遠沒有所謂“最滿意”的說法，只有“相較于上一次體驗更滿意”.所以除非定義一種可量化的終極滿意度模型作為指標參照，否則用戶體驗設計是一個永遠都有優(yōu)化空間的過程。用戶體驗設計是圍繞過程的設計，當前智慧運營平臺項目改造中，優(yōu)秀的用戶體驗組件不僅要好看而且要好用，不僅僅是視覺上高端大氣上檔次，使用上也要給人以暢快淋漓，一氣呵成之感。為了提供當前系統(tǒng)的用戶體驗并保證智慧運營平臺系統(tǒng)交互體驗規(guī)范統(tǒng)一，本次組件設計需要遵循以下準則：組件色系風格統(tǒng)一，在整個智慧運營平臺系統(tǒng)中，主色調推薦使用藍色商務色系，正確使用綠色，警告使用藍色，重要警告使用紅色；操作按鈕也藍色為主。示例如下圖：

全系統(tǒng)中布局和導航設計規(guī)范統(tǒng)一，符合互聯(lián)網(wǎng)用戶使用習慣?？刂茊未伪韱蔚拇笮?，對于負責的業(yè)務表單數(shù)據(jù)，建議分步或分組進行，降低用戶受挫感并支持單步表單保存提高使用體驗。示例如下：

操作和交互行為規(guī)范統(tǒng)一，提供常用的行為組件模型，操作行為流程各子系統(tǒng)中進行規(guī)范統(tǒng)一，包括導航、菜單和切換返回的布局位置要協(xié)調統(tǒng)一。重要操作需再次確認并警告突出，關鍵業(yè)務數(shù)據(jù)操作時，一定要對用戶進行足夠的提醒，避免人為誤操作。示例如下：

提供豐富完善的擴展組件,除了提供統(tǒng)一布局導航和常用表單組件外，并提供豐富的高級擴展組件，如日歷、時間軸、圖表等統(tǒng)計組件。用戶體驗組件除了滿足視覺和交互要求外，同時要保證自身的代碼質量并要降低開發(fā)人員的使用成本：代碼質量高，功能豐富，API靈活友好，快速的交互相應，細致、漂亮的UI，完整的的文檔和開發(fā)擴展支持。設計原則1.對比（Contrast）對比的基本思想是，要避免頁面上的元素太過相似。如果元素（字體、顏色、大小、線寬、形狀、空間等）不相同，那就干脆讓它們截然不同。要讓頁面引人注意，對比通常是最重要的一個因素，正是它能使讀者首先看這個頁面。2.重復（Repetition）讓設計中的視覺要素在整個作品中重復出現(xiàn)?？梢灾貜皖伾⑿螤?、材質、空間關系、線寬、字體、大小和圖片，等等。這樣一來，既能增加條理性，還可以加強統(tǒng)一性。3.對齊（Alignment）任何東西都不能在頁面上隨意安放。每個元素都應當與頁面上的另一個元素有某種視覺聯(lián)系。這樣能建立一種清晰、精巧而且清爽的外觀。4.親密性（Proximity）彼此相關的項應當靠近，歸組在一起。如果多個項相互之間存在很近的親密性，它們就會成為一個視覺單元，而不是多個孤立的元素。這有助于組織信息，減少混亂，為讀者提供清晰的結構。色彩和布局主色調推薦使用藍色商務色系，正確行為使用綠色，警告行為使用藍色，重要警告行為使用紅色。我們推進使用以下顏色作為設計和開發(fā)規(guī)范，以保證頁面和組件之間的視覺一致。藍色作為主色調LightPrimary常用于hover，DarkPrimary常用于active，顏色參照如下：輔助色是具有代表性的顏色，常用于信息提示，比如成功、警告和失敗。中性色常用于文本、背景、邊框、陰影等，可以體現(xiàn)出頁面的層次結構。整體頁面布局上，一般主導航放置于頁面的頂端，從左自右依次為：logo、一級導航項、輔助菜單（用戶、設置、通知等）。通常將內容放在固定尺寸（例如：1200px）內，整個頁面排版穩(wěn)定，不受用戶終端顯示器影響；上下級的結構符合用戶上下瀏覽的習慣，也是較為經(jīng)典的網(wǎng)站導航模式。頁面上下切分的方式提高了主工作區(qū)域的信息展示效率，但在縱向空間上會有一些犧牲。此外，由于導航欄水平空間的限制，不適合那些一級導航項很多的信息結構。示例如下：導航菜單導航菜單基于以下準則進行設計：一級導航和末級的導航需要在可視化的層面被強調出來；當前項應該在呈現(xiàn)上優(yōu)先級最高；當導航收起的時候，當前項的樣式自動賦予給它的上一個層級；左側導航欄的收放交互同時支持手風琴和全展開的樣式，根據(jù)業(yè)務的要求進行適當?shù)倪x擇。菜單示例如下：

字體和圖標框架組件中，對CSS對字體進行統(tǒng)一規(guī)范，力求在不同平臺、瀏覽器下能顯示出其最佳的效果。當前智慧運營平臺系統(tǒng)中，中文字體推薦優(yōu)先使用微軟雅黑?？蚣芙M件中提供豐富的針對智慧運營平臺和企業(yè)業(yè)務系統(tǒng)的字體圖標庫，以滿足各中心引擎業(yè)務開發(fā)的要求。示例如下：按鈕當前系統(tǒng)中按鈕的設計規(guī)范如下：將按鈕放在用戶希望看到的地方，用戶對于頁面交互其實是有基本的感知和期望的，也就是說用戶對于按鈕的位置是有個基本的認知的。不要讓用戶到處找按鈕，它最好在用戶所期望的位置出現(xiàn)。按鈕上應該加上相應操作的標簽，當按鈕的文本標簽上的內容寫的太過于寬泛，或者使用帶有誤解的內容，可能會讓用戶感到迷惑。每個標簽上的文本標簽都應該盡量準確，簡明直接地介紹清楚它的真實功能。按鈕應該擁有合理的尺寸，按鈕的大小應該反映出屏幕上這一元素的優(yōu)先級，更大的按鈕應該意味著更重要的交互。注意按鈕的次序，按鈕的順序應該反映出用戶和界面之間交互的屬性，問問自己用戶期望在屏幕上看到什么樣的順序，或者說什么樣的順序更合理，然后進行相應的設計。避免使用太多按鈕，當你提供太多的選擇的時候，用戶往往會無所適從。按鈕類型有：默認按鈕、主按鈕、虛線按鈕、文字按鈕以及四種顏色按鈕。示例如下：圖標按鈕示例如下：按鈕狀態(tài)示例如下：表單表單按照由小到大，由靜到動的策略進行設計。表單之所以復雜，很重要一點是來源于它所服務業(yè)務（特別是后臺產品）的復雜度。各種業(yè)務邏輯的組合，不同“層級”的信息透出，一大達到一定的復雜度就會導致混亂，最后失控。為了讓我們自己先不混淆，我們需要把表單的最小單元、單元組合、靜態(tài)展示、動態(tài)反饋拆開分別一步步的遞進處理。表單示例如下：表格表格的設計集中體現(xiàn)在可視化（可讀性）和易操作兩個方面，好的數(shù)據(jù)表格允許用戶對信息進行快速的掃描、查詢、過濾、分析等操作，以獲取深刻認知并快速準確完成目標任務。其基本設計原則是“全面整合并呈現(xiàn)業(yè)務數(shù)據(jù)，提供順暢閱讀體驗，便于用戶發(fā)掘重要信息，進行便捷操作”，簡而言之，即“滿足業(yè)務需求+符合用戶心智模型”。表格示例如下：標簽標簽用于對不同維度進行簡單的標記和分類，標簽的增加要在視覺上起到輔助作用，同時又不會讓整個頁面變得很有負擔，因此大多都是對比色或者飽和度比較高的顏色。標簽示例如下：提示層提示層示例如下：擴展組件擴展組件示例如下：統(tǒng)一數(shù)據(jù)訪問引擎（數(shù)據(jù)中間件）優(yōu)化提供一個數(shù)據(jù)庫分庫分表中間層，采用數(shù)據(jù)庫代理方式，形成分布式數(shù)據(jù)庫中間件解決方案，解決分布式系統(tǒng)數(shù)據(jù)庫分庫分表帶來的數(shù)據(jù)透明訪問難題。整體功能架構如下圖所示：圖功能架構圖DBProxy：UDAL的核心組件，是一個實現(xiàn)了mysql協(xié)議的Sever進程，前端用戶可以把DBProxy看成數(shù)據(jù)庫代理，可用mysql客戶端工具或命令行方式直接訪問，其后端以mysql原生協(xié)議與多個mysql數(shù)據(jù)庫進行通信，也可以用jdbc協(xié)議與大多數(shù)主流數(shù)據(jù)庫服務器通信，DBProxy的核心功能是分庫分表并對應用層屏蔽分庫分表帶來的訪問難題。網(wǎng)絡通訊：提供高并發(fā)、低延遲的網(wǎng)絡通訊。MySQL協(xié)議適配：采用MySQL開源協(xié)議，實現(xiàn)前后端網(wǎng)絡請求的協(xié)議格式。SQL解析：解析SQL語句文本，為節(jié)點路由計算提供依據(jù)對象。分庫分表數(shù)據(jù)路由：通過用戶配置的分庫策略，計算數(shù)據(jù)存取的數(shù)據(jù)庫節(jié)點。SQL執(zhí)行：實現(xiàn)單語句、多語句并發(fā)執(zhí)行SQL功能。SQL結果匯聚：對語句多節(jié)點執(zhí)行的結果進行接收并做二次計算，得到多節(jié)點情況下的正確結果。全局序列：實現(xiàn)全局唯一序列。事務控制：同一個事務內的SQL由同一個鏈接進行處理，保證事務原子性。讀寫分離：提供數(shù)據(jù)庫節(jié)點的讀寫分離功能。由分庫分表中間件根據(jù)配置動態(tài)判斷。安全控制：SQL語句攔截過濾，權限認證等。GiServer：切片索引服務進程，是為了提升非分片鍵查詢（select語句）時的效率（避免廣播查詢）而開發(fā)的，與數(shù)據(jù)庫的索引沒有任何關系，是完全不同的兩個概念，GiServer是切片索引數(shù)據(jù)的生產者，真正的消費者是DBProxy進程，假設客戶表是以cust_id進行分表的，但應用需要通過客戶身份證來查詢客戶信息，如果沒有切片索引，則DBProxy會將查詢語句廣播到所有節(jié)點執(zhí)行，接收到執(zhí)行結果進行匯聚后再返回給應用，如果建立了切片索引，則DBProxy首先會根據(jù)身份證號碼從切片索引中查詢到對應的cust_id，再根據(jù)分片算法定位到cust_id對應的分片，這樣就避免了廣播查詢。運維管理平臺：提供完善的配置、發(fā)布和運維管控平臺。配置功能及發(fā)布：提供在線配置功能、實時發(fā)布，無須重啟服務，保證不中斷在線調 整服務。服務發(fā)布啟停：提供分庫分表中間件服務的發(fā)布和啟停功能。服務監(jiān)控報警：提供CPU、內存、IO、連接數(shù)、慢SQL、TOPSQL等監(jiān)控，對于超過閥值提供報警功能。運維操作功能：提供在線查看數(shù)據(jù)、數(shù)據(jù)遷移同步、限制應用鏈接、安全檢測等日常運維管理操作。統(tǒng)一數(shù)據(jù)訪問層技術架構如下圖所示：圖技術架構圖基于NIO技術提供高并發(fā)、低延遲的網(wǎng)絡通訊。采用MySQL開源協(xié)議，實現(xiàn)前后端網(wǎng)絡請求的協(xié)議格式。采用druid開源項目，解析SQL語句文本，為節(jié)點路由計算提供依據(jù)對象。實現(xiàn)取模、一致性哈希等算法，通過用戶配置的分庫策略，計算數(shù)據(jù)存取的數(shù)據(jù)庫節(jié)點?；趜ookeeper存放DBProxy、GiServer等的配置信息及利用zookeeper的分布式一致性實現(xiàn)全局唯一序列。依賴外部組件分布式緩存，存放切片索引數(shù)據(jù)。全局序列由于分庫分表的主鍵ID保存在不同的數(shù)據(jù)庫，為了保證全局序列號的唯一性，需要統(tǒng)一提供全局序列號的維護來保證序列號的唯一性。系統(tǒng)提供全局sequence，并且提供包含本地配置和數(shù)據(jù)庫配置等多種實現(xiàn)方式。本地配置方式，將sequence配置到文件中，當使用到sequence中的配置后，獲取配置文件中sequence當前的值。數(shù)據(jù)庫方式，在數(shù)據(jù)庫中建立一張表，存放sequence名稱(name)，sequence當前值(currentvalue)，步長(incrementint類型每次讀取多少個sequence，假設為K)等信息，Sequence獲取步驟：

a)當初次使用該sequence時，根據(jù)傳入的sequence名稱，從數(shù)據(jù)庫這張表中讀取current-value，和increment到系統(tǒng)中，并將數(shù)據(jù)庫中的current-value設置為原current-value值+increment的值。

b)系統(tǒng)將讀取到current-value和increment作為本次要使用的sequence值，下次使用時，自動加1，當使用increment次后，執(zhí)行步驟a)相同的操作。

c)系統(tǒng)負責維護這張表，用到哪些sequence，只需要在這張表中插入一條記錄即可。若某次讀取的sequence沒有用完，系統(tǒng)就停掉了，則這次讀取的sequence剩余值不會再使用。本地時間戳方式，ID=64位二進制(42(毫秒)+5(機器ID)+5(業(yè)務編碼)+12(重復累加)，換算成十進制為18位數(shù)的long類型，每毫秒可以并發(fā)12位二進制的累加。分布式ZKID生成器，基于ZK與本地配置的分布式ID生成器，ID結構：long64位，ID最大可占63位：*|currenttime(微秒時間戳38位,可以使用17年)|cluster-Id（機房或者ZKID，通過配置文件配置5位）|instance-Id（實例ID，可以通過ZK或者配置文件獲取，5位）|thread-Id（線程ID，9位）|increment(自增,6位)。應用自定義方式，有上層平臺框架提供公共的應用服務全局序列支持。事務控制分布式事務處理（DistributedTransactionProcessing，DTP）指一個程序或程序段，在一個或多個資源如數(shù)據(jù)庫或文件上為完成某些功能的執(zhí)行過程的集合，分布式事務處理的關鍵是必須有一種方法可以知道事務在任何地方所做的所有動作，提交或回滾事務的決定必須產生統(tǒng)一的結果（全部提交或全部回滾）。X/Open組織定義了分布式事務處理模型。X/OpenDTP模型（1994）包括應用程序（AP）、事務管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。一般，常見的事務管理器（TM）是交易中間件，常見的資源管理器（RM）是數(shù)據(jù)庫，常見的通信資源管理器（CRM）是消息中間件，下圖是X/OpenDTP模型：一般的編程方式是這樣的：配置TM，通過TM或者RM提供的方式，把RM注冊到TM?？梢岳斫鉃榻oTM注冊RM作為數(shù)據(jù)源。一個TM可以注冊多個RM。AP從TM獲取資源管理器的代理（例如：使用JTA接口，從TM管理的上下文中，獲取出這個TM所管理的RM的JDBC連接或JMS連接）AP向TM發(fā)起一個全局事務。這時，TM會通知各個RM。XID（全局事務ID）會通知到各個RM。AP通過1中獲取的連接，直接操作RM進行業(yè)務操作。這時，AP在每次操作時把XID(包括所屬分支的信息)傳遞給RM，RM正是通過這個XID與2步中的XID關聯(lián)來知道操作和事務的關系的。AP結束全局事務。此時TM會通知RM全局事務結束。開始二段提交，也就是prepare-commit的過程。XA協(xié)議，指的是TM和RM之間的接口，其實這個協(xié)議只是定義了XA_和AX_系列的函數(shù)原型以及功能描述、約束和實施規(guī)范等。至于RM和TM之間通過什么協(xié)議通信，則沒有提及，目前知名的數(shù)據(jù)庫，如Oracle,DB2等，都是實現(xiàn)了XA接口的，都可以作為RM。Tuxedo、TXseries等事務中間件可以通過XA協(xié)議跟這些數(shù)據(jù)源進行對接。JTA是符合X/OpenDTP的一個編程模型，事務管理和資源管理器支架也是用了XA協(xié)議。下面兩個圖片分別給出了XA成功與失敗的兩種情況，首先是XA事務成功的流程圖：然后，是XA事務失敗的流程圖：安全控制數(shù)據(jù)庫中間件的安全控制主要由SQL攔截和權限認證實現(xiàn)。SQL攔截是一個比較有用的技術，用戶可以寫一個java類，將傳入的SQL進行改寫然后再去執(zhí)行，此技巧可以完成如下一些特殊功能：捕獲和記錄某些特殊的SQL；記錄SQL查找異常；出于性能優(yōu)化的考慮，改寫SQL，比如改變查詢條件的順序或增加分頁限制；將某些SelectSQL強制設置為Read模式，走讀寫分離；攔截所有SQL做智能分析，自動監(jiān)控節(jié)點負載，自動優(yōu)化路由，提供數(shù)據(jù)庫優(yōu)化建議。SQL攔截的原理是在路由之前攔截SQL，然后做其他處理，完了之后再做路由，執(zhí)行,如下圖所示：權限認證支持租戶、用戶隔離，支持平臺權限和精細顆粒權限控制。分片規(guī)則分片枚舉

通過在配置文件中配置可能的枚舉id，自己配置分片，本規(guī)則適用于特定的場景，比如有些業(yè)務需要按照省份或區(qū)縣來做保存，而全國省份區(qū)縣固定的，這類業(yè)務使用本條規(guī)則。固定分片hash算法

本條規(guī)則類似于十進制的求模運算，區(qū)別在于是二進制的操作,是取id的二進制低10位，即id二進制&1111111111。此算法的優(yōu)點在于如果按照10進制取模運算，在連續(xù)插入1-10時候1-10會被分到1-10個分片，增大了插入的事務控制難度，而此算法根據(jù)二進制則可能會分到連續(xù)的分片，減少插入事務事務控制難度。范圍約定

此分片適用于，提前規(guī)劃好分片字段某個范圍屬于哪個分片取模，此規(guī)則為對分片字段求摸運算。按日期（天）分片

此規(guī)則為按天分片。取模范圍約束

此種規(guī)則是取模運算與范圍約束的結合，主要為了后續(xù)數(shù)據(jù)遷移做準備，即可以自主決定取模后數(shù)據(jù)的節(jié)點分布。截取數(shù)字做hash求模范圍約束

此種規(guī)則類似于取模范圍約束，此規(guī)則支持數(shù)據(jù)符號字母取模。應用指定

此規(guī)則是在運行階段有應用自主決定路由到那個分片。截取數(shù)字hash解析

此規(guī)則是截取字符串中的int數(shù)值hash分片。一致性hash

一致性hash預算有效解決了分布式數(shù)據(jù)的擴容問題。按單月小時拆分

此規(guī)則是單月內按照小時拆分，最小粒度是小時，可以一天最多24個分片，最少1個分片，一個月完后下月從頭開始循環(huán)。每個月月尾，需要手工清理數(shù)據(jù)。范圍求模分片

先進行范圍分片計算出分片組，組內再求模優(yōu)點可以避免擴容時的數(shù)據(jù)遷移，又可以一定程度上避免范圍分片的熱點問題綜合了范圍分片和求模分片的優(yōu)點，分片組內使用求模可以保證組內數(shù)據(jù)比較均勻，分片組之間是范圍分片可以兼顧范圍查詢。最好事先規(guī)劃好分片的數(shù)量，數(shù)據(jù)擴容時按分片組擴容，則原有分片組的數(shù)據(jù)不需要遷移。由于分片組內數(shù)據(jù)比較均勻，所以分片組內可以避免熱點數(shù)據(jù)問題。日期范圍hash分片

思想與范圍求模一致，當由于日期在取模會有數(shù)據(jù)集中問題，所以改成hash方法。先根據(jù)日期分組，再根據(jù)時間hash使得短期內數(shù)據(jù)分布的更均勻優(yōu)點可以避免擴容時的數(shù)據(jù)遷移，又可以一定程度上避免范圍分片的熱點問題要求日期格式盡量精確些，不然達不到局部均勻的目的冷熱數(shù)據(jù)分片

根據(jù)日期查詢日志數(shù)據(jù)冷熱數(shù)據(jù)分布，最近n個月的到實時交易庫查詢，超過n個月的按照m天分片。自然月分片

按月份列分區(qū)，每個自然月一個分片，格式between操作解析的范例。路由分發(fā)路由能保證sql轉發(fā)到正確的節(jié)點。轉發(fā)的范圍是剛剛好，不多發(fā)也不少發(fā)。多發(fā)會出現(xiàn)兩種問題：浪費性能和找不到表。比如一個select*fromorderswherepro=‘wuhan’這個語句，只有dn1節(jié)點，能查到數(shù)據(jù)，如果將語句同時轉發(fā)到dn1、dn2、dn3三個節(jié)點，這樣的范圍就多發(fā)了，性能上是一種浪費。如果新增了一個節(jié)點dn4，但是orders的datanode范圍只是dn1,dn2,dn3，如果同時轉發(fā)到dn1、dn2、dn3、dn4四個節(jié)點，則發(fā)到dn4執(zhí)行時會返回tableordersnotexists。少發(fā)則會出現(xiàn)結果集不全的問題，如select*fromorders如果只轉發(fā)到dn1，只會返回dn1上的結果集，dn2、dn3上的結果集得不到。單表路由計算流程如下圖：多表路由計算中有子流程“單表路由計算”，這個子流程引用了上面的單表路由計算流程，多表路由計算流程如下：消息中間件本期工程整體功能架構如下圖所示：圖STYLEREF2\s4.2SEQ圖\*ARABIC\s28功能架構圖如圖中所示，本期工程主要對API、Broker消息節(jié)點實現(xiàn)、命令行與運維平臺進行優(yōu)化與完善。系統(tǒng)技術架構如下圖所示：圖技術架構圖其中，Producer/consumer與server，broker建立并維持長連接，broker將系統(tǒng)狀態(tài)，服務統(tǒng)計通過心跳傳送給nameserver，供客戶端訪問獲取。消息重復處理在實際CRM、計費需求中，部分業(yè)務場景如：訂單，不能有重復消息，因此需要進行消息去重處理。在分布式架構下，單純依賴消息中間件難以實現(xiàn)完全去重，因此采用消息中間件增加消費去重處理+應用冪等性+運維手段結合的方式來達到消息完全不重復的目的。發(fā)送階段，消息中間件對網(wǎng)絡超時等不確定失敗進行記錄。方便運維排查重復。消費階段，通過在服務端記錄消息的消費狀態(tài)，避免消息被重復消費與簽收客戶端返回中間狀態(tài)處理消息中間件是通過持久化磁盤和主備機制來保證消息高可靠不丟失。當前消息中間件支持同步/異步刷盤，以及主從節(jié)點的同步/異步復制模式。在強同步模式下，生產者發(fā)送消息到消息中間件可能存在如下中間狀態(tài)：1、主節(jié)點刷盤超時(FLUSH_DISK_TIMEOUT)2、主節(jié)點寫Slave超時(FLUSH_SLAVE_TIMEOUT)3、寫Slave失敗(SLAVE_NOT_AVALIABLE)4、生產者與Broker之間網(wǎng)絡超時上述狀態(tài)之所以稱為中間狀態(tài)，是因為消息中間件發(fā)送消息并非強一致性的事務，因此出現(xiàn)上述狀態(tài)時，消息可能成功，也可能失?。粸榱舜_保應用消息處理邏輯，消息中間件需要有對應上述狀態(tài)的處理機制。增大超時時間,減少超時錯誤對于超時狀態(tài)：增加超時消息確認機制，嘗試查詢服務端，確認消息是否成功，如果成功返回成功，如果失敗返回失敗，如果無法確定，則返回timeout，并記錄異常消息對于其他中間狀態(tài)（刷盤，寫slave超時，寫slave失?。喊l(fā)送失敗，提供明細錯誤碼，供應用根據(jù)可靠性要求選擇處理，并記錄異常消息，告警并人工介入，進行主備切換或者禁寫broker（提供處理腳本和文檔說明）。消息簽收超時處理當前CtgMQ中，沒有消費超時的處理，即如果消息派發(fā)給應用消費，但應用不返回消費結果也不拋異常，那消息中間件會一直等待消息完成，而此種情況下，無序/有序消費都會出現(xiàn)堆積，堵塞所在同一消息分區(qū)的后續(xù)消息的消費。據(jù)了解，阿里的設計初衷是考慮到此類情況一般都是應用邏輯發(fā)生問題，必須應用告警（應用自身告警，或根據(jù)堆積量告警）介入處理，因此MQ自身不提供處理機制。計費應用提出，希望能夠提供機制，保證在消息處理無法返回（如消息數(shù)據(jù)、邏輯等問題導致消息處理線程卡?。┑那闆r下，能夠繼續(xù)后續(xù)消息的消費。提供可選的簽收超時處理機制打開超時處理，自動簽收超時消息。按GroupId分片有序場景隊列擴容需求隊列按GroupID多分片部署，消息有序，訂單按照CustID取模分發(fā)到不同的分區(qū)。隊列在線擴容后，可能相同CustID的不同訂單同時在新、老分片都存在，可能導致消息短暫無序，在嚴格要求消息有序場景下，需要有相應機制處理；消息中間件隊列擴容過程中，由于消息新老分發(fā)規(guī)則變更，可能出現(xiàn)消息無序。建議解決方案為通過運維手段，在擴容前暫停消息寫入，待隊列消息全部消費完成后再擴容，最后恢復消息生產消息中間件運維控制臺增加功能：監(jiān)控隊列深度停止和恢復生產消息寫入創(chuàng)建新隊列在線擴容通過運維控制臺手工進行，具體操作步驟為：停止需要擴容的隊列消息寫入；查看隊列深度，直至全部消息消費完成；隊列深度為零后，創(chuàng)建新的隊列；新增加消費端應用啟動；恢復生產消息寫入，擴容完成。消費者擴容當增加新的消息隊列時，希望能增加新的對應的消費端。消息中間件提供按Topic查詢隊列使用明細API，應用調用該API可以獲取該Topic下的隊列情況，靈活對應消費端。提供《消費線程機制說明文檔》，詳細說明消息中間件消息消費線程機制。單隊列不同業(yè)務類型消息消費需求計費應用單個隊列中可能存在不同業(yè)務類型的消息，希望能夠相互之間不影響消息的消費，一個業(yè)務的消息不消費、簽收，不會影響其他類型業(yè)務消息的處理。能夠對不同類型的消息，設置不同的tag，不同消費者指定tag消費。從而相互不影響支持跳躍簽收，由應用的邏輯來處理不同類型業(yè)務消息。提供無序模式下消息跳躍性簽收處理功能計費應用一個隊列中可能包含多個分片的消息，導致部分消息之間存在順序依賴，但是并不是完全順序。消息中間件現(xiàn)有的機制，在消費客戶端保存了一些消費相關狀態(tài)，因此1) 由于客戶端可能頻繁重啟和數(shù)量變化，以及MQ的rebalance機制，這些狀態(tài)可能會丟失，從而可能導致狀態(tài)丟失后的消費重復2) 滑動窗口機制下，如果消息長時間不簽收，將導致無法消費后續(xù)消息，否則存在大量消息重復的風險此問題的本質是當前MQ實現(xiàn)為了性能和設計簡化，沒有對每條消息記錄狀態(tài)，而只是記錄一個標量的消費進度，導致客戶端需要記錄額外的狀態(tài)，而客戶端可靠性較低(尤其是在測試環(huán)境下)。服務端存儲消費狀態(tài)，保證客戶端重啟或變化不丟失狀態(tài)增加滑動窗口，保證消息不簽收情況下，仍能繼續(xù)拉取新消息。用戶名密碼接入認證API在創(chuàng)建連接的時候，做用戶名密碼認證，認證通過才可以發(fā)送和消費消息服務端增加用戶名、密碼配置文件，保存加密后的認證信息客戶端初始化時，連接服務端將用戶名密碼加密發(fā)往服務端認證，認證成功才能進行后續(xù)的發(fā)送和消費操作動態(tài)增減nameserver為了保證消息中間件nameserver模塊的高可用，nameserver可能包含多個進程，且可能動態(tài)調整增減。希望能夠有機制設置并在運行過程中自動調整?；赗ocketMQ的http方式獲取nameserver地址，并與管理控制臺結合，在創(chuàng)建集群后，能夠自動生成http服務地址，并可用于API使用。增加相應配置的校驗完善連接管理，關閉不存在的服務連接完善監(jiān)控平臺為了提高消息中間件的使用體驗，MQ管理臺需要進行優(yōu)化與完善。消息數(shù)量、消費深度等信息查詢Broker服務擴容、縮容流程節(jié)點、生產者、消費者在線監(jiān)控消費積壓監(jiān)控消息吞吐量監(jiān)控消息回溯批量創(chuàng)建主題重置消費進度增加關鍵操作日志方便查看用戶操作刪除topic和消費組關系消息回溯消息綜合查詢。監(jiān)控運維提升支持監(jiān)控中心對接，支持應用運營平臺對接。支持消息中間件接入易監(jiān)控平臺支持消息隊列監(jiān)控支持消息隊列查詢提供消息中間件概況信息點指標完善版本自動發(fā)布和自動測試流程梳理測試、發(fā)布流程，并進行自動化，減少人工測試、發(fā)布過程中的錯誤。版本自動發(fā)布：提交某個版本最終代碼后，補充相應的部署文檔、API說明文檔、changlog說明以后，可以通過jenkins自動完成版本的編譯、部署、自動化測試和發(fā)布最終版本等工作。最終獲取的發(fā)布包不用做修改可以直接發(fā)送給客戶使用。自動測試流程：通過jenkins定期根據(jù)主干代碼編譯、部署消息中間件，同時運行自動化測試用例進行測試。當發(fā)現(xiàn)缺陷時，模擬缺陷的場景補充自動化測試用例。多集群的主備自動切換，備機自動拉起支持MQbroker服務的自動切換與備機自動拉起。Broker分組的備機故障后，可以自動拉起B(yǎng)roker分組的的主機故障后，從broker升主后可以繼續(xù)對外提供服務整個broker分組中的機器被重啟后broker可以重新被拉起。主備切換過程中不一致數(shù)據(jù)的回滾主備切換前主從數(shù)據(jù)不一致，主從切換后可以對不一致的數(shù)據(jù)進行回滾。支持主從切換過程中新從上面的多余Commitlog、ConsumeQueue等消息數(shù)據(jù)回滾、消費進度和消費狀態(tài)數(shù)據(jù)的回滾。支持從升主后消息數(shù)據(jù)和消費進度數(shù)據(jù)不一