1、下一代智慧政務云平臺方案建議書目 錄第一章 電子政務云平臺101.1 云平臺建設目標101.2 云平臺建設原則101.3 總體架構111.4 IT基礎設施配置121.5 軟件列表13第一章 IAAS基礎設施云平臺設計151.1 總體規劃151.2 網絡規劃171.3 自動部署181.3.1 自動部署思想191.3.2 方案優勢211.4 統一管理211.4.1 統一監控211.4.1.1 統一監控架構221.4.1.2 監控方案優勢231.4.2 網絡流量控制231.4.2.1 總體架構241.4.2.2 方案優勢241.4.3 統一日志251.4.4 配置管理251.4.5 自動審批251.

2、5 IAAS安全251.5.1 安全管理體系261.5.2 安全運維體系261.5.3 安全技術體系261.5.4 防攻擊系統261.6 成功案例27第二章 PAAS應用支撐云平臺設計282.1 設計目標和原則282.1.1 系統設計目標282.1.2 系統設計原則282.1.2.1 主數據集中原則282.1.2.2 以主數據集中原則拆分系統282.1.2.3 高可用原則282.1.2.4 高擴展原則292.2 總體規劃292.3 支撐平臺292.4 應用支撐平臺部署架構302.5 服務框架(SAF)312.5.1 SAF簡介312.5.2 SAF與傳統ESB的區別312.5.3 SAF架構特

3、性及工作原理322.5.3.1 SAF特性332.5.3.2 SAF工作原理332.5.3.3 SAF性能對比332.5.3.4 SAF監控342.5.3.5 基于SAF的服務治理352.5.3.6 基于SAF的服務限流與降級352.5.3.7 基于SAF的服務容災與恢復352.6 分布式緩存技術352.6.1 總體說明352.6.2 采取redis的原因362.6.3 平臺總體架構372.6.4 多協議支持方案392.6.5 高可用（HA）方案392.6.5.1 基礎設施392.6.5.2 Master/Slave復制402.6.5.3 AOF412.6.5.4 RDB快照422.6.5.5

4、 jd-redis-dumper422.6.5.6 基礎設施小結422.6.6 故障檢測432.6.6.1 分布式采集器432.6.6.2 存活報警策略432.6.7 故障切換432.6.8 分布式方案442.6.8.1 垂直擴展452.6.8.2 水平擴展452.6.9 容量管理462.6.10 安全462.6.10.1 配置安全462.6.10.2 訪問安全472.6.10.3 內置安全機制472.6.11 運維和管理平臺472.6.11.1 集群和實例管理472.6.11.2 監控472.6.11.3 統計482.6.11.4 管理工具482.6.11.5 自監控482.7 分布式工作流

5、平臺PAF482.7.1 目標482.7.2 技術概要設計方案492.7.2.1 體系結構設計492.7.2.2 流程引擎（SWE）：50PAF代理（Proxy）50流程管理Console512.7.2.3 數據架構設計52配置數據架構52流程數據架構522.7.2.4 安全體系設計532.7.2.5 備份系統設計532.7.3 系統運行監控手段及方式532.8 分布式消息平臺（MSP）542.8.1 架構目標542.8.2 架構552.8.3 標準及兼容性552.8.4 高可用552.8.5 高性能562.8.6 高擴展性562.8.7 易管理監控562.8.8 性能指標572.8.8.1

6、測試場景572.8.8.2 測試環境572.8.8.3 測試結果582.8.9 管理平臺582.8.9.1 自助申請592.8.9.2 生產者監控602.8.9.3 消費者監控61第三章 自動化運維管理623.1 總體設計623.2 部署平臺623.2.1 背景623.2.2 平臺設計643.2.2.1 技術架構64構圖及主要模塊說明643.2.2.2 功能架構說明：653.2.2.3 配置清單70最小配置70線上服務器配置(最大配置)703.2.2.4 技術架構和性能的詳細說明70技術指標及性能703.2.3 技術優勢、特性、可靠性策略703.2.3.1 優勢及特性703.2.3.2 應用接

7、入方便快捷，多角色管理安全保證713.2.3.3 跨平臺，多開發語言應用713.3 統一監控平臺713.3.1 概述713.3.2 項目目標733.3.3 架構設計753.3.3.1 監控日志收集753.3.3.2 監控數據分析753.4 統一日志平臺763.4.1 概述763.4.2 系統總體架構763.4.3 關鍵點設計773.4.3.1 按日志分類訂閱773.4.3.2 負載均衡783.4.3.3 客戶端優化793.4.3.4 日志轉發器793.4.4 擴展性設計793.4.4.1 客戶端的水平擴展793.4.4.2 服務器的水平擴展79第四章 大數據平臺804.1 總體規劃804.2

8、大數據平臺架構圖814.3 大數據平臺824.3.1 JBUS抽數系統824.3.2 JDS云數據庫834.3.3 ODE大數據核心處理834.3.4 JDDP大數據業務引擎844.4 成功案例84第五章 安全體系及規范設計855.1 總體規劃855.2 安全技術體系865.2.1 網絡邊界防護875.2.2 數據安全875.2.3 應用安全885.2.4 物理安全885.2.5 主機安全885.2.6 網絡安全885.2.7 計算環境防御895.3 安全管理體系895.3.1 安全管理承諾895.3.2 安全管理組織目標895.3.3 安全評審機制905.3.4 所有者的管理職責905.3.

9、5 知識產權905.3.6 安全方針的修訂905.4 安全運維體系915.4.1 發布管理915.4.2 事件管理915.4.3 知識庫管理915.4.4 問題管理915.4.5 變更管理915.4.6 配置管理925.4.7 資產管理925.4.8 監控管理925.4.9 風險管理92第六章 實施階段936.1 第一階段：IaaS平臺構建936.2 第二階段：遷移現有應用系統及數據946.3 第三階段：構建政務云自動化運維946.4 第四階段：構建PaaS和大數據平臺94第一章 電子政務云平臺1.1 云平臺建設目標通過構建電子政務云平臺，統一政務云平臺架構，提高IT資源的利用率，信息化應用能

10、夠在云環境中高可用的運行，同時實現云平臺的政務應用系統的研發標準化，提高開發效率，降低開發成本。l 政務云的架構統一l 使用的技術統一l 運行的平臺統一l 自動化的運行維護管理1.2 云平臺建設原則電子政務云平臺建設是按照國家信息化建設規劃的要求，遵循“統一規劃，整合資源；統一標準、共享信息；統一協調、講求實效”的建設原則，各單位不需在信息化上單獨建設，嚴格遵守“統規、統建、統用、統管”原則，統一部署在云計算中心；因此，要求云計算中心的基礎設施必須滿足各委辦局提出的硬件設備及5-8年發展需要，并具備良好的擴展性。1.3 總體架構電子政務云平臺架構政務云大數據平臺架構圖1.4 IT基礎設施配置平

11、臺最小IT基礎設施（50臺）推薦IT基礎設施（88臺）IaaS + PaaS 平臺30臺服務器，兩路x86處理器，32GB內存，1TB以上的硬盤；網絡交換設備按照此配置進行以太網交換部署，千兆以太網；50臺以上的服務器，兩路或者四路x86處理器，32GB內存，2TB以上的硬盤；網絡交換設備按照此配置進行以太網交換部署，萬兆以太網；大數據平臺15臺服務器，兩路x86處理器，32GB內存，1TB以上的硬盤；網絡交換設備按照此配置進行以太網交換部署，千兆以太網；30臺以上服務器，兩路或者四路x86處理器，64GB內存，2TB以上的硬盤；網絡交換設備按照此配置進行以太網交換部署，萬兆以太網；訪問層網絡

12、接入安全設備一共5臺服務器：2臺服務器，四路x86處理器，32GB內存，1TB以上的硬盤，6塊千兆以太網卡；3臺服務器，兩路x86處理器，16GB內存，500G以上的硬盤；一共8臺服務器：4臺服務器，四路x86處理器，32GB內存，1TB以上的硬盤，4塊萬兆以太網卡，2塊千兆以太網卡；4臺服務器，兩路x86處理器，16GB內存，1TB以上的硬盤；1.5 軟件列表平臺產品說明開源產品京東產品IaaS私有云IaaS平臺OpenStack Icehouse版本京東云鼎云數據庫MySQL 7.3京東JDS分布式數據庫PaaS工作流Apache ODE 1.3.6業務流程管理服務 PAFSOAWSO2

13、4.8.1服務架構框架SAF消息Apache Qpid 0.28 & Qpid Proton 0.7 & Qpid Dispatch 0.2消息服務平臺MSP緩存Redis 2.8.13京東緩存云 Cache Cloud云盤文件存儲服務（功能較單一）Jbox 云盤Web開發京東WEB開發平臺訪問層安全防護京東ADS防攻擊系統大數據平臺數據抽取京東Jbus實時數據同步、京東OSA數據訂閱大數據運行平臺Hadoop 2.3.0京東大數據開發和運行平臺機器數據引擎開源產品只提供了算法，沒有對應產品京東IT基礎設施數據分析引擎產品第一章 Iaas基礎設施云平臺設計1.1 總體規劃京東在多年的系統平臺的

14、研發和運維過程中結合開源產品、業界經驗和自身多年的最佳實踐形成了一套適合云計算平臺業務需求的IT基礎設施服務云平臺京東的IAAS平臺，其系統架構如下所示：京東IAAS總體架構圖從京東IAAS的總體架構圖可以看出在虛擬化和分布式上下足了功夫。在系統架構圖中位于最底層的是IDC的硬件基礎設施，這里除了圖示的服務器、存儲和網絡外還包括機架、UPS機房環境等。為了保證整個數據中心的穩定、可靠運行我們建設的數據中心均達到T4級別：保證任何的計劃性活動不會引起關鍵負載的中斷，容錯能力也為基礎實施提供能忍受最少一次的最糟糕的情況非計劃性故障或者非關鍵性負載事件的沖擊能力。雙系統（S+S）的配置，電力上配備（

15、N+1）的UPS系統。除了底層強大的資源供應外，在數據中心提供多線BGP接入，有40G以上的帶寬（還可以根據需要靈活擴容）當然光有這些還遠遠不夠，為了讓IAAS系統高效運行在服務器上采用了目前最為先進的刀片服務器（以32Core、64G內存為主）；分布式存儲方面則拋棄了傳統的集中存儲模型，充分利用每臺服務器上掛載的300G*8的存儲設備和服務器Raid的功能建立了統一的分布式存儲。在服務器、網絡之上是操作系統，通過操作系統將數據中心的物理設備所提供的硬件資源映射到虛擬世界中來并為IAAS所識別。為了達到高效、可靠和安全采用了CentOS6的Linux操作系統，并對其做了定制（在安全、性能優化等

16、方面均有所增強）。在數據中心里IAAS作為云計算平臺建設的最底層承擔著虛擬化和資源的管理、調度的工作，其重要性是顯而易見的。因為其與底層的緊密關系，運維上也有其特殊性。如果說普通的大平臺是三分研發七分運維，而IAAS系統則是二分研發八分運維。當面臨成千上萬的服務器時如何快速部署并自動化運維就成為一個很大的問題。IAAS方案里的自動部署模塊正是為了解決數據中心大規模機器如何自動化的部署而提出的。在IAAS框架中，安全是很重要的一環。前面提到從物理服務器的操作系統一層開始定制并植入了安全的解決方案，這還只是很小的一部分。根據京東系統十多年的應該實踐，安全一定是全方位的，自底向上的覆蓋整個云計算平臺

17、。彈性集群是一款高可用的應用集群服務，只需簡單幾步即可完成大規模集群創建，完全自動化運維。彈性集群支持高并發高訪問量，且可根據自定義的規則進行資源的自動擴容或縮容。彈性集群可以讓應用系統根據業務需要自由伸縮，隨需而用。但另一方面，因為這些應用都運行在基于IAAS平臺的虛擬機中，在使用像網絡這樣的珍貴資源時難免會相互影響。在極端情況下，一個運行于虛擬機的應用系統可能強占所有可用的網絡資源而使得運行在其他虛擬機上的應用系統只能獲取到很少的網絡資源甚至中斷服務。流量控制正是針對這樣問題而提出的解決方案，通過設定相應的流量控制策略可以有效的防止惡意占用資源的情況。前面已經提到，作為底層的資源管理者在調

18、度大規模的計算、存儲和網絡資源時難免會遇到各種各樣的問題。除了IAAS的智能處理外還需要一個管理界面來顯示這些兒信息，比如：整個集群的負載情況如何？什么時候創建了多少虛擬機？等等還有很多。而統一管理綜合了整個IAAS集群運行過程中方方面面的信息、事件，并以直觀的形式展現在客戶面前；如果需要還可以進行動態的調整。1.2 網絡規劃在京東多個IDC中同時既部署有基于傳統技術的網絡解決方案也有基于最新的SDN技術的網絡解決方案，還有將傳統網絡和SDN結合在一起的混合型解決方案。一個典型的IDC混合型網絡方案如下圖所示：從上圖可以看到，在核心交換機處部署了京東的防攻擊系統。從核心交換機往下形成一個大二層

19、的網絡，接入交換機負責網絡數據的匯聚和承接。在SDN技術應用方面，自主研發了控制器系統；直觀簡單，控制能力強，并實現了集群級的高可靠。1.3 自動部署京東云平臺IAAS自動部署的方案提供了一套完整的工具，通過使用最新的技術解決大規模數據中心里大量服務器自動化、快速部署和日常維護的問題。一般來說在機器數量處于十幾臺、幾十臺時雖然麻煩，但靠人力還能維護過來。但一旦規模突破上百臺，系統上部署幾十個應用，運維人員將疲于應付。隨著系統越來越大達到幾百臺規模、上百個系統時，如果沒有自動化工具運維人員將無法應付這種系統不斷的升級，部署所帶來的工作量。如果服務器數據突破千臺、幾千臺，甚至過萬，沒有自動化的部署

20、及運維方案及有可能隨時崩潰，不能正常提供服務，這對公司來說是一個災難。1.3.1 自動部署思想 在自動部署方案的設計過程中融入了流程的思想，將問題聚焦在自動化和分層部署上，從母機開始，到IAAS管理模塊，再到所有計算模塊，這樣一步步的完成整個系統的部署。下面是一個自動部署的框架示意圖。京東自動部署整體架構如上面的流程圖所示，在整個過程中首先是根據所得到服務器資源去規劃角色，定義好每一個服務器在IAAS所處的地位。在IAAS系統定義了一系列的角色：l 管理機：是一個管理IAAS集群的機器，負載IAAS集群其他角色服務器的安裝與升級。l 數據庫，存儲整個IAAS的運行時信息。l MQ：連接松耦合下

21、的各個IAAS服務模塊。l 負載均衡：在IAAS集群中將負載分發到能提供所請求服務的模塊。l 緩存：加速IAAS中的服務模塊對請求的響應速度，提高集群性能。l 管理模塊：負載調度IAAS集群中所維護的各種資源，并對創建的虛擬機進行全生命周期的管理。l 計算服務：負載虛擬機的具體生命周期管理。l 網絡服務：提供網絡虛擬化相應的服務。l 請求接口（API）：對外提供統一的可編程及訪問接口。所謂角色規劃的過程就是要將構建IAAS集群所需要的各種角色與服務器映射起來，再加上預先定義好的限制與規則，從而形成一份完整的IAAS集群配置文件。管理機將根據這份配置文件去遠程構建IAAS集群；IAAS集群運行時

22、的配置文件也會在此過程中生成。管理機的部署也十分簡單，一鍵安裝。管理機安裝成功后就可以批量地去安裝其他角色的服務器的操作系統了。通過PXE機制安裝的操作系統是經過安全和性能方面的增強的，批量安裝操作系統，也代表著最下一層的安全解決方案部署成功。操作系統安裝成功后就可以根據規劃好的角色去遠程部署每個服務器所定義的IAAS服務模塊。所有的部署完成后會自動觸發一個驗證過程，并最終生成驗證報告。這時候，一個完整的IAAS集群就好了，可以投入運行。1.3.2 方案優勢綜上可以看出，相對于其他的自動部署方案具有以下的優勢：l 基于流程化定義部署策略l 99.5%的全自動部署l 能在0.5小時內安裝1000

23、臺機器的操作系統，從祼機開始l 能在1.0個小時內部署IAAS系統需要的數據庫、消息中間件等核心模塊l 可以支持異構化的服務器，如IBM、HP和Dell的標準服務器l 模塊化解決方案，部署時可靈活配置l 支持圖形化和命令行兩種操作模式1.4 統一管理京東IAAS系統的統一管理平臺，整合了IAAS系統運行中所需要關注和操作的各個功能。通過統一管理平臺可以查看IAAS集群所有的運行時信息，還可以進行集群的管理（比如：創建、刪除虛擬機，創建刪除網絡等）。1.4.1 統一監控監控是云計算數據中心的關鍵技術之一，云計算相關的所有異常信息均被監控與告警。從而確保數據中心的穩定運營。通過對云計算數據中心全面

24、，實時，精細的監控，對集群發生的錯誤做到99.9%告警率。并主要從以下監控點出發，并提供簡單的WEB控制臺展示監控點狀態， 并及時根據運營人員設置的告警閥值進行相應的告警：1) 數據中心物理硬件監控點2) 云計算服務的相關集群(IAAS自身服務)監控點3) 云計算生產的VM穩定運行監控點1.4.1.1 統一監控架構監控系統整體來看是一個事件驅動的架構，消息中間件（MQ）位于整個架構的核心。從架構圖可以看到監控系統有以下幾個模塊組成：1) Compute-Agent：該組件用來收集計算節點上的信息，在每一個計算節點上都要運行。2) Central-Agent：Central Agent運行在IA

25、AS管理節點上，它主要收集其它服務的信息。 3) Collector：這個應該是最為核心的組件了，它的主要作用是監聽Message Bus，將收到的消息以及相應的數據寫入到數據庫中，它是在核心架構中唯一一個 能夠對數據庫進行寫操作的組件。除此之外，它的另一個作用是對收到的其它服務發來的notification消息做本地化處理，然后再重新發送到 Message Bus中去，隨后再被其收集4) Stroage: 用于存儲采集到的數據。5) Message Bus: Message Bus負責通信，所有的數據都要經過Message Bus被Collector收集而存到數據庫中。6) Notifica

26、tion：負責告警服務，包括Mail/SMS1.4.1.2 監控方案優勢方案優勢： 圖形化操作界面，簡單直觀 事件采集全面、實時、及時 智能感知機架，感知新擴容計算節點 標準化告警信息處理流程1.4.2 網絡流量控制網絡流量控制是云計算數據中心的關鍵技術之一，它需要確保處于同一個數據中心的虛擬機能夠獲得可靠的網絡帶寬保證。而由于出口帶寬有一定限制，而每一個用戶的帶寬需求又是無盡的，都希望最大化自己的利益，這樣就會導致對帶寬資源的爭奪，有可能就會造成少量在線用戶就可能將出口帶寬用之殆盡。如果沒有網絡流量控制，將最終導致用戶提供的帶寬承諾無法兌現。1.4.2.1 總體架構流量控制的完整方案京東Ia

27、aS流控控制系統（JTCS）主要分為三大模塊（如上圖）1） 流量控制模塊：根據用戶定義的策略進行網絡流量的控制。2） 流量采集模塊：實時的采集每個虛擬機的流量。3） 反向控制模塊：反射調整子網、物理機、虛擬機、業務端口的流量。1.4.2.2 方案優勢相對于目前業界使用的流量控制方案，有如下的優勢：1）可以實現實時的流量分析2）可以實現動態調整根據實時的流量對控制策略做智能優化。3）可以實現反向控制在高峰時段可反射調整子網、物理機、虛擬機、業務端口的流量。1.4.3 統一日志實現集群所有服務的日志下載與分析。1.4.4 配置管理通過配置管理界面可以修改IAAS集群的配置信息。1.4.5 自動審批

28、具有類似工作流的功能，可以將創建虛擬機的請求納入流程中實現自動審批。1.5 IAAS安全在整個IAAS系統中安全的重要是不言而喻的。IAAS位于整個云平臺了最底層，可以說是PAAS、SAAS的根基。一旦IAAS層被攻擊或者被侵入，輕則服務不暢重則影響整體系統的可服務性甚至導致整個云平臺的崩潰。京東安全的解決方案是從網絡到物理機服務器再到虛擬機的完整解決方案。從整體上來說，云服務的安全要考慮三方面：安全管理體系，安全技術體系、安全運維體系。這三個體系是一個動態、循環的過程：安全管理體系需要周期性的進行管理評審和持續改進；安全技術體系需要在新技術和新威脅出現，信息系統基礎設施變更時，進行動態更新；

29、安全運維體系需要周期性的通過安全服務將安全管理體系的管理目標通過安全技術、安全培訓等措施進行有效的落地與實現。1.5.1 安全管理體系安全管理體系明確了組織高層安全策略和指導方針。管理體系中的管理要求通過安全運維體系有效落實到信息系統基礎設施和安全技術體系當中，從而達到組織信息安全保障的整體目標。1.5.2 安全運維體系安全運維體系負責落實安全保障措施和制度，技術措施和管理制度要同時落實。1.5.3 安全技術體系安全技術體系是信息系統的技術保障，使得運維體系達成安全管理目標得以實現。1.5.4 防攻擊系統防攻擊系統是京東人是在保護京東電商、物流和金融的斗爭中，不斷和黑客戰斗，發展出來的務實的方

30、案。目前來看，來自外部的三大主要安全問題分別是：l DDOS(DDoS:Distributed Denial of Service：分布式拒絕服務)攻擊。l Web與Host安全l APT其中，又易DDOS攻擊最為難防，因為：l 可以從協議47層全面攻擊l 反彈攻擊與僵尸網絡l 流量大（350G的攻擊流量）針對DDOS攻擊的特點，我們提供如下的防攻擊方案：1.6 成功案例目前已經在京東五大數據中心成功部署IAAS集群。l 公有云超過3000VMl 私有云超過1800+VMl 京東金融云超過1500VM第二章 Paas應用支撐云平臺設計2.1 設計目標和原則2.1.1 系統設計目標構建穩定高效的

31、SOA架構體系，逐步接入現存業務系統，未來開發的系統會基于SOA架構體系開發和運行。2.1.2 系統設計原則2.1.2.1 主數據集中原則l 以數據源即歸屬系統集中 l 歸屬系統保證數據的準確性和一致性 l 主數據的修改由歸屬系統接管 2.1.2.2 以主數據集中原則拆分系統 l 主數據集中保證業務系統相對獨立；l 獨立的業務系統彼此解耦，以SOA和數據交換兩種形式彼此互通；l 以數據交換平臺做為系統間大數據量的交換的手段； 2.1.2.3 高可用原則l 避免單點故障；l 具備Failover能力；2.1.2.4 高擴展原則 l 充分利用IT基礎設施；l 具備水平擴展能力；2.2 總體規劃根據

32、以上原則，我們建議應用支撐平臺的總體架構如下圖：分布式緩存平臺分布式調度平臺工作流平臺RDBMSNoSQL硬件及網絡設備服務器同步調用服務異步消息驅動自驅動服務數據存儲硬件設施服務層硬件層組件層服務組合編排虛擬化數據層Service平臺分布式消息平臺基礎設施基礎架構統一數據訪問層多數據源ETL平臺數據訪問組件應用政務BPM服務便民服務社保在線系統申報/審批分布式文件異步并行調用框架教育婚姻登記稅務信息檢索統計分析電子郵件搜索引擎數據建模頻道Mobile WebTVEDMRSSPartnerOpen Service自動化編譯平臺自動部署平臺安全體系 運行監控體系政務應用支撐平臺2.3 支撐平臺支

33、撐平臺主要包括：1、 Service平臺，可以認為是Service的運行容器，內置了對Service通訊協議、消息格式（文本或字節流）等的自動識別，支持服務注冊、服務發現、服務實例的上下線、服務實例分組、服務路由、服務監控（SLA）等；2、 Daemon（Cronjob）管理調度平臺，實現對Daemon（Cronjob）類型Service的統一管理和調度，包括配置管理、運行管理以及Failover等；3、 分布式流程平臺，即SOA流程平臺中Workflow Engine底層實現；4、 分布式消息平臺，即統一管理分布部署的高可用消息中間件平臺，內置實現JMS等主流協議;5、 分布式緩存平臺，建立

34、分布式緩存，從數據訪問、加載、分發、備份、分區、訪問調度路由等全方位進行管理，實現緩存平臺的高可用。2.4 應用支撐平臺部署架構如圖所示：1、 支撐平臺的運行系統和管理系統分別部署在每個機房的運行網段和管理網段；2、 支撐平臺的運行系統在A、B兩機房同時提供服務，由跨機房的負載均衡集群根據業務規則進行路由，業務規則可以是簡單Hash或者依據某些屬性（如歸屬地或者業務劃分等）；3、 支撐平臺的運行系統產生的運行數據在兩個機房之間雙向增量同步，同步方式分為：數據庫、Zookeeper、分布式文件、LDAP等；4、 支撐平臺的管理系統雖然部署在多個機房，但是只有一個機房的為主，其他為從，管理數據的變

35、更操作必須指向主，然后由主向從同步，同步方式分為：數據庫、Zookeeper、LDAP等；5、 支撐平臺的管理系統完成數據更新后，采用主動推送或者輪詢的方式，在運行系統中加載生效。2.5 服務框架(SAF)2.5.1 SAF簡介 SAF是分布式高可用的服務中間件，是系統SOA化的基石，具有服務調用者與服務提供者直接一對一調用、調用FailOver、高性能RPC調用等特性，由RPC框架、服務配置中心組成。2.5.2 SAF與傳統ESB的區別傳統ESB是基于集中式總線的方式，會有如下缺點：1、在使用時，所有的服務請求都要經過集中式總線的服務器，在大并發量、大數據量下ESB總線會成為瓶頸，其服務能力

36、會受到ESB服務擴展能力的限制；2、同時使用總線的服務與服務之間會互相干擾，如A服務的流量大漲的情況下，會占用總線的大部分處理能力，這時B服務的調用會由于總線的網絡帶寬、總線的處理能力被占用而出現異常（例如TimeoutException），從而B服務總的服務質量出現下降。SAF在架構上是分布式的總線，也就是說服務調用者與服務提供者之間是直接點對點進行調用，服務之間互相不會干擾。3、ESB所在的網絡交換機也會成為瓶頸.2.5.3 SAF架構特性及工作原理如上圖所示，注冊中心是由五臺zookeeper服務器組成的集群，服務提供者在上線時會向注冊中心注冊自己的信息，同樣服務調用者在啟動時向注冊中心

37、進行訂閱，注冊中心將把服務提供者地址列表返回給服務調用者；服務提供者與服務調用者都與注冊中心保持有長鏈接，這樣如果由服務提供者down機或者有新的服務提供者上線，注冊中心將很快得到通知，與此同時注冊中心將把更新過后的服務提供者地址列表推送給服務調用者；2.5.3.1 SAF特性l 高效的長鏈接協議thrift、Java NIO長連接協議；l 多協議支持，如RMI、Hessian、WebServices等；l 支持FailOver，在服務調用出現網絡異常后，自動切換Provider重試；l 支持多種Load balance策略 如：權重、隨機或輪詢算法；l 支持跨平臺調用2.5.3.2 SAF工

38、作原理 SAF RPC部分工作原理簡述如下服務消費者端根據服務接口生成代理，在對此代理對象進行調用時，代理對象將從服務提供者地址列表中選擇一個進行RPC調用，SAF將把這個調用序列化為字節序列，然后通過TCP協議發送給服務提供者，在服務端反序列化為調用后，通過線程池進行業務調用，最終得到的業務調用結果將通過TCP長鏈接返回給服務調用者。2.5.3.3 SAF性能對比發布工具CXFSAF通信協議HTTPTCP序列化格式XML格式二進制格式Failover無有，重試次數可設置服務能力水平擴展需修改域名解析配置動態推送服務提供者列表服務端執行方式每請求一個執行線程通過線程池執行TPS（1k數據量）6

39、00015000服務質量監控需自行收集計算內置調用信息收集服務治理無有，基于注冊訂閱2.5.3.4 SAF監控SAF具有完善的監控體系，總體分為兩種大類：1.服務存活監控； 服務存活監控是通過兩種手段來完成，1）client端與注冊中心的長鏈接是否保持，2）Web管理端每隔一段時間向服務端口進行telnet訪問，判斷其是否可用；以上兩種手段都在監控到服務不可用時均會通過短信與郵件發出報警信息。2.服務調用質量監控； SAF通過Filter收集服務調用的信息，包括但不限定于調用次數、調用成功次數、數據包大小、服務響應時長；并定時將收集到的信息上傳到Monitor 服務來，最終通過圖標來進行展示；

40、如果調用次數低于閥值，或是調用失敗次數過多，都將觸發報警。2.5.3.5 基于SAF的服務治理解決服務Provider和服務Consumer之間的匹配問題（根據接口、版本、group分組來區分）；服務注冊和訂閱功能，通過一個注冊中心以及管理端來完成對服務的管理；靈活的服務路由規則設置；通過服務路由規則來完成provider的區分調用灰度部署；服務提供者地址列表動態推送功能；通過此功能實現了服務能力的水平擴展和收縮。2.5.3.6 基于SAF的服務限流與降級服務限流是指為了保證服務質量，在單位時間內將可以提供的服務調用次數限定在一定數額內，如果超過此數額，服務端將直接返回服務忙的提示；降級是指在

41、調用鏈上某服務不可恢復威脅到業務正常運行時可以通過簡單的配置即可將其關閉。2.5.3.7 基于SAF的服務容災與恢復SAF的容災，SAF所有的服務地址列表以及相應配置都在客戶端有緩存，如果注冊中心出現了短暫的不可用，也不會影響到客戶端與服務端的正常業務調用。2.6 分布式緩存技術2.6.1 總體說明 以redis為底層存儲設施，建設高性能、高可用、可擴展、易于運維和管理的緩存平臺，以靈活滿足各種緩存應用場景。緩存平臺目標2.6.2 采取redis的原因l 由VMWare支持，開發活躍。社區非常成熟，包括StackOverflow/暴雪/新浪微博/Flickr等公司廣泛使用；l 高性能：100k

42、+TPS；l 功能豐富。K/V存儲的Value不僅僅支持string，還支持list、hash、set、sorted set。大量的原子操作。基本涵蓋了memcached的功能；l 支持經典的Master/Slave高可用部署架構，支持緩存內容的持久化；redis提供的這些特性，便于達成我們的目標。在此之上，按照實際的業務需求，進行擴展和輔助工具的開發，建立完善的統一管理平臺。2.6.3 平臺總體架構分布式緩存平臺總體架構圖Redis server pool獨立部署一系列redis server或者將現有已經部署的redis server納入管理，形成邏輯上統一的緩存資源池。Gather se

43、rvers部署一系列分布式采集應用節點，分別對所有的redis server和redis proxy進行信息采集，存儲的同時發送到實時監控服務。監控服務對采集傳輸的數據進行實時分析，使用預定義的一系列規則進行報警。Stat/Analysis服務部署一系列分布式統計應用節點，分別對原始采集數據進行準實時統計匯總并存儲。原始采集信息統計完畢之后刪除。集中存儲所有的統計結果。統計節點本地系統同時存儲本節點負責的統計結果，以便展現。Config/Meta/Manage Servers負責將變動的集群信息（節點拓撲、路由和讀寫策略等）push到相應的proxy。負責提供配置和元信息服務，以便應用端的Cl

44、ient SDK來polling變更。負責控制各個物理機上的Agent，對redis實例進行部署管理和配置文件同步。Agent部署在緩存資源池中各個物理機上，負責本機redis實例的部署和配置文件同步。Client SDKClient SDK為應用提供操作redis集群數據的API。利用polling到的集群配置元信息（節點拓撲、路由和讀寫策略等），訪問后端的redis server節點。SDK負責監控配置信息變更（比如故障切換、服務節點遷移等），動態重啟底層的連接池。對應用透明。ProxyClient SDK相對比較復雜，而且需要適應多種開發語言。因此可以把Client SDK的功能后移到中

45、間的proxy層，通過proxy來對應用屏蔽這些復雜性。Redis proxy是實現了redis 協議的無狀態的server，無論何種語言的redis客戶端都可訪問它。應用通過load balance設備來訪問后端的多個proxy server。管理平臺 包括對以上各個組件的統一管理，以及一系列運維管理工具。2.6.4 多協議支持方案緩存平臺對外提供的協議或接口，除了本身就支持的redis協議外，還可通過proxy中間件提供memcached、REST等協議。雖然proxy方式比native直連方式性能稍遜，但也有優勢：l 底層實現可替換l 滿足多協議需求l 屏蔽底層設施中復雜的分布式路由、故

46、障切換、讀寫策略等l 可以自由使用現成的多語言客戶端在性能完全滿足業務需求的場景，可考慮使用proxy。否則，可使用專用的redis客戶端SDK。2.6.5 高可用（HA）方案2.6.5.1 基礎設施底層支持：Master/Slave復制、AOF日志持久、RDB快照持久擴展：jd-redis-dumper。2.6.5.2 Master/Slave復制典型部署場景跨機柜/交換機跨機房在運營經驗上，鏈式復制優于1-n的復制方式。通過跨機房復制，提高本地讀性能。復制機制redis采用異步方式保證最大的復制效率，同時對master性能影響最小。不支持同步方式，而是通過復制的可靠性配置來保證數據的安全。

47、復制的可靠性（延時保證）min-slaves-to-write #最少需要存在slave數量才能允許寫 min-slaves-max-lag #slave落后master最大的秒數一致性保證slave-read-only true2.6.5.3 AOF將redis實例所有的寫操作命令以redis協議文本格式追加到本機日志文件，通過replay日志來恢復數據。可靠性保證appendfsync always：每次追加日志同時都執行fsync持久到介質，最可靠，性能最差。appendfsync no：只追加，不執行fsync。由操作系統保證高速緩存持久到介質，性能最高，可靠性依賴操作系統，有可能丟失

48、尚未持久到介質的更新數據。appendfsync everysec：每秒執行一次fsync，性能居中，最壞丟失的更新數據不超過2秒。AOF整理自動：auto-aof-rewrite-percentage ，自動重新AOF以減少文件大小。手動/定時：bgrewriteaof2.6.5.4 RDB快照將redis實例內存數據完整的持久到本機二進制快照文件，通過load快照文件恢復數據。可靠性保證stop-writes-on-bgsave-error no策略自動：save 手動/定期：bgsave2.6.5.5 jd-redis-dumper實現redis的復制協議的中間件。在跨機柜/交換機或者跨

49、機房的主機上，將一個或多個實例的數據復制到jd-redis-dumper所在機器，并以AOF或RDB方式存儲。通過遠端的AOF和RDB來恢復數據。數據安全和Master/Slave一樣，但是節約了內存資源，恢復速度要慢。2.6.5.6 基礎設施小結從數據安全等級、故障恢復速度綜合來看，優先級如下：Master/Slave復制 jd-redis-dumper AOF 快照實踐：l 性能優先的關閉復制、AOF和快照；l master關閉rdb/aof，使用slave replicationl slave上開啟rdb+aofl 讀壓力大的slave上關閉rdb+aof，通過jd-redis-dump

50、er來備份l 若開啟復制或持久，預留一倍空閑內存l 多實例時，由管理平臺依次執行bgsave/bgrewriteaof，避免同時fork進程2.6.6 故障檢測2.6.6.1 分布式采集器zookeeper協調的多個采集器，定期收集所有集群和實例的info/config信息供準實時分析，同時發現故障實例，報告給故障決策組件。2.6.6.2 存活報警策略實例不存活報告次數，在某個時間范圍內，到達指定值，則進行報警。2.6.7 故障切換當發生報警后，通過人工或者故障決策組件自動確認后，開始進行故障切換。只有AOF或者RDB的，通過Agent重啟實例恢復數據。有Slave的，將Slave提升為主。切

51、換流程（同時適用實例遷移）1）192.168.110.23:6379（Master）到192.168.110.24:6379（Slave）的連接故障；2） Gather/Analysis檢測并分析到Master故障，Slave存活，將新的主從拓撲關系通知到Config Manage Server；3） Manage Server 更改192.168.110.24:6379(Slave)的slave-read-only false，并更新配置信息；4） App-1輪詢到最新配置；5） App-1重啟連接池連接到192.168.110.24:6379(Slave)，發送讀寫請求；46） App-2

52、輪詢到最新配置；7） App-2重啟連接池連接到192.168.110.24:6379(Slave)，發送讀寫請求；8） Gather/Analysis檢測并分析到沒有有效客戶端連接到Master，通知Manage Server；9） Config/Manage Server同時確認客戶端全都更新到最新配置（客戶端心跳），則對192.168.110.24:6379（Slave）發送切換為Master的命令；10） 若192.168.110.23:6379(原Master)恢復存活，則設置為192.168.110.24:6379（新Master）的Slave，進行數據復制。2.6.8 分布式方案

53、通過在本機或跨機部署多個實例形成一個邏輯上的集群，提高整體性能，減少單點故障。每個實例作為邏輯集群的一個分片（Sharding），承擔部分數據的存儲和讀寫請求。每個分片還可以配置對應的Slave，形成一個高可用分布式的集群方案。client/proxy按照key通過特定路由算法（比如一致性hash）請求特定的分片。Redis sharding+clientside routing目前redis的最佳實踐是pre-sharding + clientside routing來做分布式方案，其cluster方案還不成熟。2.6.8.1 垂直擴展 pre-sharding，創建足夠多的分片實例，部署在

54、有限的幾臺物理機上。當緩存增長時，可通過擴大物理機內存，或將實例遷移到另外的物理機上，并擴大每個實例的最大內存設置，來達到整體擴容的目的。 故障切換流程同樣適用于實例遷移。2.6.8.2 水平擴展 當一個分片實例的內存容量增長到已經不合適放在一臺物理機上時，勢必要進行分片數量的增加。涉及到緩存數據的重新分布，可通過jd-redis-bridge來做。Jd-redis-bridge原理圖2.6.9 容量管理預先規劃，合理配置。按照業務緩存數據增長量來提前規劃分片數量，權衡成本和收益，配合垂直擴展和水平擴展來適應緩存的增長。實踐：l 仔細設計數據結構和codecl CPU不是瓶頸，內存和網絡才是l

55、 hash-max-zipmap-entries / hash-max-zipmap-value l 設置maxmemory，設置預警規則l 合理設置緩存項逐出策略l 合理設置緩存項過期時間2.6.10 安全2.6.10.1 配置安全屏蔽或修改危險命令：l rename-command SHUTDOWNl rename-command CONFIG youdontknow2.6.10.2 訪問安全直連方式ClientSDK通過token獲取相應的集群拓撲配置。Proxy方式Redis的auth協議被用作client的token，proxy與后端server不需要認證。2.6.10.3 內置安全

56、機制為redis實例配置passwd2.6.11 運維和管理平臺2.6.11.1 集群和實例管理l 集群/實例/應用元信息管理l 可視化的集群拓撲圖l 訪問令牌、配置管理l Slowlog查看l info/config信息查看2.6.11.2 監控l 針對集群實例、或者不同的角色（Master/Slave）的重點指標設置監控規則l 全局規則/集群特有規則2.6.11.3 統計l 各集群重要指標的趨勢l 重要指標的TOPnl 重要指標項按使用部分占比l 重要配置項占比2.6.11.4 管理工具l 動態配置l web端命令行l 實時搜索特定指標或配置l 實例遷移、故障切換、批量部署l 可編排管理腳

57、本（DSL風格）2.6.11.5 自監控緩存管理平臺中各個組件的運行情況的監控。2.7 分布式工作流平臺PAF2.7.1 目標為涉及工作流的業務應用系統提供工作流定義、任務分配、流程跟蹤、流程管理的平臺和服務支撐。2.7.2 技術概要設計方案特點：1. 采用SOA架構，微內核，完全水平擴展。2. 靈活的業務流程跟蹤監控 3. 滿足WfMC標準, 支持BPMN2.0，功能強大 4. 流程開發調試簡單, 支持Eclipse IDE流程建模和Web建模5. 對外提供的訪問接口性能，TP99 在2秒以內6. 可以進行歸檔，并根據業務系統的業務量定義不同的流程歸檔間隔7. 易擴展，高可靠，高安全性8.

58、應用服務器支持云部署2.7.2.1 體系結構設計主要由3個部分組成：2.7.2.2 流程引擎（SWE）：SWE主要是經過改造和增強的Activiti。 做過的改造如下：1. 增加多個對外接口，比如可以根據多個流程定義查詢代辦任務。2. 增加流程優先級功能3. 增強的重試機制（可以按指數，倍數以及它們組合方式進行配置）4. 增強調用外部Web Service的方式，便于使用，并可以按流程配置例如調用超時等參數5. 增加調用SAF服務方式6. 增加與MQ的集成7. 持久層性能調優，包括增強數據庫主鍵生成機制，建合適索引等等8. SWE之間通過Zookeeper進行協調，避免job爭搶9. 與數據庫

59、實例動態綁定PAF代理（Proxy）PAF代理接受外部調用工作流的所有請求，將所有請求根據預定規則路由到后端的SWE進行處理。主要功能如下：1. 提供WebService和SAF endpoint.2. MQ消息啟動和喚醒流程：通過管理端配置MQ topic可以通過MQ啟動或喚醒流程3. 請求認證：可通過token對請求進行認證4. 路由: 根據路由信息，將請求發到對應的SWE5. 帶權重的負載均衡： 可以通過管理端配置的SWE權重，在同一個domain里的SWE進行負載均衡流程管理Console管理Console集中管理整個系統的流程，和各種配置信息。主要功能如下：1. 系統設置（管理員權限

60、）1.1. 角色列表：設置訪問工作流管理Console的角色。目前分管理員和普通用戶2類。管理員可使用Console的所有功能，能查看所有流程定義和流程實例。普通用戶只能查看自己部署的流程以及流程實例。1.2. 用戶管理：管理Console用戶及密碼2. 工作流配置（管理員權限）2.1. 租戶管理：管理可訪問工作流（通過Proxy）的租戶信息2.2. Domain管理： 配置Domain基本信息2.3. SWE管理：配置SWE基本信息2.4. Proxy管理：配置Proxy信息2.5. 監控腳本：可以上傳對流程進行監控的腳本。3. 流程管理3.1. 流程定義管理： 可以部署，查看流程定義3.2

61、. 流程實例管理：可以搜索，查看正在運行或已經完成的流程實例，包括所有的活動，流程變量值，流程運行圖等等3.3. 任務查詢控制：可以通過流程變量等信息對人工任務進行高級查詢，并可以對任務進行重分配等3.4. 流程實例控制（管理員權限）：可取消，掛起和激活流程4. 歸檔管理4.1. 歸檔進度監控：查看流程歸檔的情況4.2. 歸檔數據查詢：根據流程實例號，業務主鍵等對歸檔數據進行查詢管理界面如下：2.7.2.3 數據架構設計配置數據架構主要是租戶管理，路由，負載均衡等的配置信息。因為該部分信息部多，且訪問量很小，采用master-slave，在master上進行讀寫，slave只做備份。且不使用分

62、庫分表。流程數據架構主要是流程定義，流程運行實例相關的信息，包括任務，流程變量等等。該部分數據與業務量相關，一般情況下數據量很大且并發訪問數多。 數據架構設計和體系架構設計保持一致，采用domain的概念，每個domain都是一套master-slave數據庫。 如果業務流程量較小，可以將一個或多個流程部署到一個domain，這樣可以節省服務器資源；如果業務量很大，也可以將一個流程部署到多個domain。 2.7.2.4 安全體系設計訪問工作流的用戶都需要經過LDAP進行驗證。同時調用工作流接口時有token進行驗證，防止惡意攻擊或誤調用。2.7.2.5 備份系統設計流程數據備份，可以根據不同

63、業務流程需要設定的各自備份頻率，比如按1年，1個季度等等。備份會從slave庫中備份到云存儲上，并在備份庫中保持索引。這樣的設計可以保證可以比較快速的通過工作流管理界面查看已經備份的流程實例2.7.3 系統運行監控手段及方式主要與京東目前的統計監控和統一日志結合。可以對下面指標進行監控和報警：1. 流程執行的TP999，TP99，TP50等2. 流程執行的可用率指標3. 流程調用的次數4. 服務器URL監控5. 服務器端口監控6. JVM監控2.8 分布式消息平臺（MSP）2.8.1 架構目標2.8.2 架構2.8.3 標準及兼容性l 遵循JMS 1.1標準l 采用的開源方案都遵循Apache

64、協議l 實現和舊有消息中間件的雙向適配器，并行運行，逐步遷移2.8.4 高可用l 同步發送，確保客戶端收到失敗異常，并能進行錯誤重試l 每條消息強制提交到硬盤，而不只是提交給操作系統緩沖區，防止掉電丟失數據l 要求消費者提交應答，至少保證消息成功投遞一次l 集群部署，每組采用主從部署，保證整個集群的高可用l 主從采用同步復制方式，保證數據一致性l 出現異常進行重試，支持如下自動故障切換主從故障切換生產者發送消息失敗，會自動在多組分片之間重試。消費者消費消息失敗，會根據重試策略自動重試，超過指定次數會提交到異常消息服務中進行重試，防止阻塞。l 采用云存儲和HBase來存儲海量歸檔數據2.8.5

65、高性能l 高性能存儲引擎采用本地專有文件數據庫；消息采用順序文件存儲，盡量不使用隨機寫。l 高性能網絡傳輸采用TCP長連接；支持消息壓縮，減少網絡通信；高性能主從復制l 分布式集群部署2.8.6 高擴展性l 客戶端從注冊中心獲取并直連目標服務器，支持負載均衡l 采用集群分組模式，通過注冊中心實行動態水平擴容l 支持按照消息類型垂直切分，保障核心消息2.8.7 易管理監控l 統一的管理控制臺，能實現對集群的管理l 統一的消息治理，便于查找訂閱信息l 自注冊服務l 監控采集器定時采集系統運行情況，根據靈活的報警策略進行報警，支持手機短信、郵件報警l 歸檔采集器定時采集消息處理日志進行歸檔，便于歸檔

66、查詢和問題跟蹤l 異常重試數據查詢，便于問題跟蹤l 運營指標統計2.8.8 性能指標2.8.8.1 測試場景l 單組服務（一臺主、從）l 確保每條消息都提交到硬盤，而不是提交給操作系統緩沖區，防止掉電l 1K文本消息l 同時進行發送和消費2.8.8.2 測試環境主 機IP操作系統資 源數量應用服務器（master）192.168.209.78Linux Centos 6.34C32G1臺應用服務器（slave）192.168. 209.83Linux Centos 6.34C16G1臺消費端192.168.209.79Linux Centos 6.34C16G1臺Zookeeper192.16

67、8.209.79Linux Centos 6.34C16G1臺壓力機（生產端）10.168.206.89Win20034C32G1臺軟件配置：資源描述應用服務器Centos 6.3性能測試機LoadRunner112.8.8.3 測試結果TPS：50002.8.9 管理平臺部分管理界面如下所示：2.8.9.1 自助申請2.8.9.2 生產者監控2.8.9.3 消費者監控第三章 自動化運維管理3.1 總體設計自動化運維主要由部署平臺， 監控平臺和日志平臺組成自動化運維云。3.2 部署平臺3.2.1 背景隨著公司應用系統的不斷增多，現有的手工部署流程已經越來越不能滿足上線的需求，現有系統的部署架構

68、也存在各種問題。方便系統上線，減少上線過程的人為出錯，構造一個自動化的部署平臺是各個研發系統的迫切需要。也是衡量一個互聯網公司技術水平的重要指標。自動部署平臺規范了線上部署流程，責任劃分明確；幫助開發快速、高效的上線，并降低人工操作的出錯可能還將運維從重復繁重的上線工作中解脫出來，轉重點關注服務器的配置管理與控制等工作，下圖為系統目前運營狀況及帶來的改革說明：發布成功率96%3每周為約40個應用，600余個實例，提供2400余次自主切流量上線服務。外網應用流量最大每天2億多。提高了應用外網用戶的可用性，節約人力，提高人效。 90%自主上線0%自主上線過去現在1研發自主上線,整體人效提升約120

69、0人月3.2.2 平臺設計3.2.2.1 技術架構構圖及主要模塊說明發送指令返回操作結果目標服務器agent目標服務器agent目標服務器agent目標服務器agentDBDB 管理界面Deploy Server 管理界面Deploy Server 管理界面Deploy ServerDeploy server集群rsync版本服務器Rsync傳輸Rsync傳輸主從數據庫Agent客戶端：Agent客戶端（支持Windows和Linux兩個平臺）直接安裝在業務服務器，不依賴中間件處理，對目標服務器進行業務處理，并且對數據進行回傳。DeployServer集群服務器：提供統一的控制管理，包括統一發

70、布控制， 統一主機列表管理，統一文件瀏覽，統一日志查看；提供諸多在線問題排查工具。Rsync版本服務器：對系統版本進行管理，上傳的發布包到Rsync服務器后，由Rsync服務器統一分發并管理。DB數據庫：數據庫使用Mysql數據庫，并進行主從配置設置。技術指標項要求開發語言先進體系結構JAVA語言、Linux Shell語言、go語言，提供多平臺開發接口運行環境跨平臺Windows、Unix、Linux體系結構Web瀏覽器/應用服務器（B/S）和客戶端/服務器（C/S）的混合架構京東自動部署系統的管理界面是基于B/S架構，客戶端是基于C/S架構；管理界面發布操作指令給客戶端，客戶端對目標服務器

71、進行業務處理，處理數據再次傳回管理界面進行統計、分析及展示。系統架構客戶端京東自動部署團隊自主研發客戶端，采用go語言開發，占用資源少，高效，穩定，可移植性好。服務端服務端基于成熟的J2EE技術，提供統一的控制管理，包括統一發布控制， 統一主機列表管理，統一文件瀏覽，統一日志查看；提供諸多在線問題排查工具，包括ping，telnet，域名檢查，網絡連通性檢查等等。3.2.2.2 功能架構說明：功能功能作用DashboardDashboard（圖形化展示）圖形化展示應用現狀以及與其他應用的依賴關系；可快速的查看應用信息，快速的創建上線、重啟、回滾任務，也可稱為自動部署的快速通道任務管理未完成任務

72、運維人員可在未完成的任務中查看上線人員提交的應用任務、認領任務進行發布操作任務排隊情況可以通過任務排隊情況查看任務的的領取信息編譯發包記錄TFS、編譯、Jone經過審批推送到部署的包均可在此進行查看、創建發布任務（一般情況在TFS上填寫的域名與部署系統中應用的路徑域名一致，部署系統會自動創建包，可在我的上線任務中顯示）我的上線任務開發人員可在此查看所屬應用的上線的任務列表；通過TFS審核的應用，上線人員可在此對應用進行認領并進行發布（上線人員可在應用的參數配置中進行設置）；運維人員可在此查看自己認領或自己創建的上線任務，并可進行發布；已完成的任務在此查看完成發布的應用的詳細信息、操作記錄Ngi

73、nx交叉部署（手動）通過nginx手動實現在不切斷流量的情況下，進行線上部署（自動）自動切流量是通過在應用的配置參數中進行設置，由自動部署系統進行配置管理運維配置表運維人員可在此添加線上的配置信息，以用于其它應用對配置的引用，可靈活實現線上信息的修改，從而降低配置修改成本服務器維護在此可查看服務器的詳細信息、服務器的連通性、服務器部署情況、Nagios監控以及對服務器啟停nginx、安裝基礎英語、基礎軟件；運維人員還可以對服務器調整主機類型為預發布類型、正式類型、準生產環境類型（用于預發、準生產環境類型的發布專用機器）注：預發布、準生產環境是與正式環境一致但獨立的環境，不能與正式環境共享服務器

74、上線運維團隊開發人員、運維人員可在此可查看各個職能部門對應的運維人員；運維Leader可在此修改職能部門對應的運維人員部門項目結構運維人員可在此添加、修改部門及項目組及項目負責人信息我的應用列表可在此查看、修改所屬應用的詳細信息，包含配置信息、實例信息、腳本、版本、以及子應用等分組管理1、增刪改查應用分組信息2、增刪改查應用分組配置文件實例管理可以查看、修改實例信息，并進行JVM統計監測腳本管理可進行編寫、修改應用特定腳本版本管理可查看應用正式環境、預發布環境、準生產環境的上線版本參數管理設置應用的leader、上線人、開發人員、項目組、使用語言等配置信息；注：在該頁面可設置自動切流量上線子應

75、用管理開發人員可在此查看應用的子應用運維人員可在此查看，修改刪除子應用應用服務器&連通性檢測開發人員可以：查看、下載線上服務器的文件；可設置應用的開啟啟動；可檢測域名的連通性；對部署客戶端進行檢測；查看Nagios監控；啟動Nginx；查看服務器的內存、磁盤等；運維人員除開發人員的權限外，還可為應用分配服務器、授權應用查看其它目錄的的權限；應用接入申請開發人員可在此接入部署、對已存在的服務器進行擴容、或對已存在的應用進行下線或縮容申請運維人員也可進行申請以及對開發人員的申請進行審核操作第一次接入應用在自動部署服務器中不存在，第一次接入時使用已有應用擴展應用在自動部署服務器中存在，因項目需求需橫

76、向擴展時使用準生產環境接入測試人員需在特定的IP下進行測試驗證接入申請使用應用下線【縮容】應用下線：應用不再使用，進行下線申請時使用應用縮容：應用中實例不再使用，需要刪除實例及所使用路徑時使用報表中心應用發布時長在此可對部門、項目組的發布時長按周、月、季、年進行統計和導出應用部署報表在此可按條件對發布、回滾、上線次數進行統計應用接入報表在此可查看按照接入的條件進行數據統計部署業務增長量在此可查看部署業務增長的變化趨勢系統維護公共腳本部署系統公用的腳本系統用戶運維人員可在此查看系統用戶、新增用戶或對用戶進行信息修改、重置密碼以及禁用賬號信息客戶端心跳在此可查看以后的服務器上安裝的客戶端的心跳是否

77、正常開放API管理為第三方應用開放更多基礎數據核心方法的API調用高級功能在此可對系統的組織結構、隊列、安全進行設置及查看3.2.2.3 配置清單最小配置Deploy服務器：1臺32G內存，16核的CentOs操作系統服務器；線上服務器配置(最大配置)Deploy服務器：3臺32G內存、16核、1T硬盤的的CentOs 6.3版本操作系統服務器；3.2.2.4 技術架構和性能的詳細說明技術指標及性能自動部署系統Agent客戶端使用go語言實現，在目標服務器上安裝，經2年驗證占用資源小，高效，穩定，完全不會對目標服務器造成影響。性能方面：客戶端在使用過程中CPU占用率不超過4%，內存使用率不超過

78、50%，能迅速響DeployServer服務端給出的各種指令。3.2.3 技術優勢、特性、可靠性策略3.2.3.1 優勢及特性在系統運行過程中，無論開發還是運維人員均提高效率，開發人員不需要在進行項目上線中占用大量時間；運維人員不用重復繁重的上線工作。3.2.3.2 應用接入方便快捷，多角色管理安全保證安裝方便，系統在初裝時，默認安裝客戶端、Nginx、Rsync基礎應用；上線初，在部署系統中申請接入并經過運維審核后，即可按照系統要求進行上線、回滾、重啟、等任務。除此之外，自動部署系統采用多交色管理模式，對登錄用戶進行嚴格權限限制，最大程度保證了應用間隔，角色間隔，保障了數據的安全。3.2.3

79、.3 跨平臺，多開發語言應用京東自動部署系統對復雜的線上運行環境，完全兼容了各種操作系統和各種開發語言，無論應用運行在windows系統還是Linux系統，無的是JAVA開發還是PHP，C+，只要接入自動部署系統，均可使用部署系統快捷、高效的部署線上應用。3.3 統一監控平臺3.3.1 概述隨著公司信息化建設、應用的不斷深入，監控已經成為生產經營環節不可缺少的組成部分，成為保障公司安全生產的重要因素。信息系統運維工作作為公司信息化工作的主要組成部分，肩負著保障信息系統安全、可靠運行，確保信息系統在公司生產經營發揮重要作用的重大使命。建設“安全穩定、架構合理、功能完備，標準規范”的監控平臺，將有

80、力地提高運維服務的工作效率和質量。根據公司現狀，信息化監控的規劃主要有如下三個方向：l 應用系統監控對應用系統從多種類型，多個模塊的存活性，性能及系統運行邏輯進行監控和報警。主要包含如下三個層面： URL 、端口監控：監控 URL 類型的接口和端存活性。 方法監控：針對系統內部的 針對系統內部的 API方法 （方法響應時間，次數，可用率， 方法心跳 ）進行監控和報警，展示。自定義監控：在程序中滿足條件的場景都可以實現監控報警及信息查看。l 業務監控業務監控功能是從業務角度出發，各個應用系統需要層面進行哪些監控，以及提供怎樣的業務層面功能支持相關應用系統。具體就是對業務數據，功能進行監控實時收集

81、流程的數據，并根據設置的策略對業務流程中不符合預期部分進行警和報警。l 基礎運維監控實現在統一的界面上對指定服務器的各種指標進行實時和可選擇時間段的展示功能，可顯示指標如下：【CPU】【DISK】l 對外接口監控點中重要核心的部分，需要及時處理或協調第三方負責人配合整因此當這些監控點出現異常時可以通過UMP系統自動發工單到remedy系統中，通過IT服務組介入協調第三方快速解決問題。3.3.2 項目目標統一監控平臺旨在解決目前業務系不完備，夠智能化沒有的 統一的監控標準。增加系統間關聯影響的分析；在出問題時進行報警，并提前對可能出現的問題做預警；自動產生工單事件，進行流程管理，對問題分析判斷異

82、常原因，執行一些可能的控制動作使系統恢復正常。同時通過對監測數據挖掘分析，計算一些KPI指標對業務系統的運行情況進行評估，進而對工作進行量化考核。 充分利用已經投入運行的基礎監控系統和業務監控系統平臺的軟硬件設施和相關工作成果，實現以下主要工作目標：1. 通過整合現有基礎信息監控平臺監控信息、服務器軟硬件資源，建立應對突發基礎服務故障預警、報警和處置機制。2. 統一的接口和規范監測、統計和分析業務系統的運行數據，對業務系統故障產生的原因進行快速，準確定位。 3. 通過統一監控平臺的建設，實現監控系統化、決策科學化、指揮智能化，從而進一步提高運維綜合能力。 4. 通過統一平臺建設，建立一套應用性

83、能SLA（Service-Level Agreement）模型，性能監控及事件處理流程3.3.3 架構設計3.3.3.1 監控日志收集3.3.3.2 監控數據分析3.4 統一日志平臺3.4.1 概述本系統的核心是分布式日志收集系統，需要各個客戶端和服務器端配合傳輸數據：客戶端：通過配置一個存放所有日志的目錄，然后通過遞歸掃描所有日志目錄下所有的文件并且采用tail方式收集到scribe服務器。服務器端：處理所有客戶端到來的連接，然后接收所有客戶端發送過來的數據并且寫入指定的存儲系統，例如云存儲。下面是整個統一日志平臺的邏輯組成圖：3.4.2 系統總體架構統一日志平臺系統架構圖如下：整個系統主要

84、由scribe客戶端、scribe中心服務器集群、訂閱客戶端、zookeeper集群、心跳信息發送集群、日志查詢平臺、分布式文件系統和敏感信息過濾系統組成。Scribe客戶端安裝在每一個需要收集日志的系統服務器上，scribe客戶端會主動抓取日志并發送到scribe中心服務器集群中去，中心服務器會根據用戶的需求將日志發送到不同的存儲上去，如需要日志的應用系統、hadoop集群或者云存儲系統。整個數據的流向就是大概如此，下面分別介紹每一個部分的功能和實現技術原理。3.4.3 關鍵點設計3.4.3.1 按日志分類訂閱日志按分類提供訂閱就必須把所有日志分類管理起來，所以首先需要實現的一個功能就是日志

85、分類管理。日志分類管理主要是建立日志分類，建立分類流程圖如下：如上圖所示，如果scribe客戶端抓取到一個新的分類日志，那么就在zookeeper中新建日志分類和scribe服務器的對應關系，即這個日志分類應該發送到哪一個scribe服務器。日志訂閱客戶端通過scribe服務器提供的API來獲取指定分類的日志信息，獲取日志的API設計如下：void GetLog(List &_return, const string &category);API的實現方式通過Thrift的RPC機制。3.4.3.2 負載均衡這里的負載均衡主要是指scribe服務器集群每一個scribe服務器節點的負載均衡，負

86、載均衡設計主要考慮到連接數、cpu、內存和帶寬等因素，通過給這些因素設定一個比例然后算出一個值來表示scribe服務器的負載指數，scribe客戶端就可以根據負載指數來選擇一個負載最低的。負載指數均存放在zookeeper中，只有新的客戶端程序加入時才選擇一個負載最低進行連接，還有就是當其他一個scribe服務器死掉了，所以連接這個scribe服務器的客戶端都需要重新選擇一個負載最低的。3.4.3.3 客戶端優化因為客戶端是運行在別的應用系統的服務器上，所以需要在資源占用上極大的節約，但是又需要比較實時，這個可能需要根據不同資源占用的要求同時達到準實時性。3.4.3.4 日志轉發器日志轉發器主

87、要借鑒flume的設計，考慮到很多系統都是java開發并且提供java的API來接收數據。3.4.4 擴展性設計3.4.4.1 客戶端的水平擴展客戶端的水平擴展主要依賴于服務器集群提供的服務能力，所以客戶端的水平擴展時很容易的。3.4.4.2 服務器的水平擴展服務器的水平擴展很重要，因為隨著接入應用的不斷增加，單個scribe服務器處理能力有限。單個scribe服務器能夠支撐的客戶端數量主要依賴于能夠打開文件的數量（包括打開的日志文件、每一個連接需要一個socket對應的一個文件描述符和一些系統默認占用的，如標準輸入、輸出和錯誤輸出）和能夠建立的最大線程數，這兩種依賴都最終依賴服務器的配置（c

88、pu、內存），默認linux是只支持1024，可以用ulimit n 設置，scribe本身運行時會設置為65535，但是必須以root運行。第四章 大數據平臺 4.1 總體規劃京東大數據平臺結合開源設計的力量，進行了深入定制改造，每天處理著海量業務數據。從計算時效性上來看，主要分為實時和非實時兩部分：實時計算主要依賴JBUS，STORM等實時計算工具，而非實時主要依賴于hadoop，spark等先進的大數據分析工具。根據不同業務的不同特點，比如有實時數據計算需求的，一般數據量不大，數據變更頻繁，對數據的時效性要求高；而非實時數據計算一般而言數據規模大，無明顯過熱數據，業務對數據本身的數據時效

89、性不敏感。對于這兩類不同需求，用戶可選擇合適的接入方式，最終達到以較小的成本實現大數據計算。從計算階段來看，主要可分為四個階段：l 第一階段：數據采集，從各種途徑搜集數據；l 第二階段：數據存儲，通過分布式技術存儲海量數據；l 第三階段：數據粗粒度清理，形成基本寬表；l 第四階段：數據精細化加工，輸出業務結果；1. 數據采集階段從不同類型數據庫（MYSQL/ORACLE/SQLSERVER）獲取實時數據庫變更記錄；從統一日志系統，從其他的數據模塊經過一定的適配，把數據實時的非實時的接入到數據平臺；2. 數據存儲階段根據數據類型的不同，把非結構化結構化的數據存在在關系型非關系型數據庫中，或者直接

90、放在可支持海量數據存儲的云存儲上，保留足夠多的副本以及定期對數據進行備份，以保證數據安全，不丟失；3. 數據粗粒度清理利用spark,hadoop,storm等大數據技術對數據進行建模分析計算，形成基本寬表；4. 數據精細化加工；建立平臺機制，讓用戶可以很方便的在基本寬表之上，通過大數據計算，對數據進行豐富，直接的業務運算，產出符合業務需求的數據結果集；正是對“兩類數據四個階段”的準確深入理解，依賴京東大數據平臺的業務越來越多，隨著業務的不斷發展，京東大數據平臺正扮演著越來越重要的角色。4.2 大數據平臺架構圖4.3 大數據平臺從模塊上分，京東大數據平臺主要由JBUS抽數系統，JDS云數據庫，

91、ODE大數據核心處理，JDDP大數據業務引擎這幾個部分構成。4.3.1 JBUS抽數系統JBUS應用節點從源端數據庫獲取以日志的方式獲取實時數據，并按照不同的主題存儲消息服務中間件MQ，以實現實時增量數據的持久化，通過jbus-dpimport模塊實現對MQ數據的訂閱并寫入到目標數據庫（MYSQL/ORACLE/SQLSERVER）中；通過調用JBUSSDK以及獲取相應的授權碼，可實現對MQ數據的實時訂閱消費。4.3.2 JDS云數據庫JDS云數據庫系統可在云端管理海量數據庫實例。目前支持MYSQL/MariaDB/MongoDB這三種不同類型的數據庫。通過JProxy模塊，JDS可方便的在關

92、系型數據庫上實現數據庫的分庫分表；通過snapshot+binlog replay技術，JDS實現了數據庫可根據備份鏡像恢復到任意時刻。通過replicat技術，JDS實現了數據庫節點切換，當一臺甚至多臺機器發生故障的時候，數據庫仍然可以正常對外提供服務。4.3.3 ODE大數據核心處理核心處理模塊ODE是基于開源社區的大數據分析技術Hadoop,Hbase,Spark,Hive等，并在此基礎上做了一些封裝管理，最終一一種服務的方式和上下游模塊相結合，方便靈活的實現了數據建模，任務管理調度。4.3.4 JDDP大數據業務引擎大數據業務引擎是在大數據處理模塊之上，提供了完善的審核系統，權限管理系

93、統，數據管理系統，用戶可在其上進行開放式的，個性化的大數據開發工作，最終生產出用戶需要的業務數據。4.4 成功案例依托強大的京東大數據分析平臺，“多賣點”實現了京東業務數據的實時非實時接入，通過云端服務降低了存儲計算開發成本，實現了軟件的飛速迭代，產品一經問世，就獲得了用戶的一致好評，為幫助企業迅速開發市場打下了良好的基礎。京東云金牌合作伙伴杭州方塊信息技術有限公司第五章 安全體系及規范設計5.1 總體規劃由于電子政務云使用的云計算架構是標準化的開放架構，對大多數用戶是開放的，關于安全性的要求也就更加迫切。從整體上來說，云服務的安全要考慮三方面：安全技術體系、安全管理體系、安全運維體系。這三個

94、體系是一個動態、循環的過程：安全管理體系需要周期性的進行管理評審和持續改進；安全技術體系需要在新技術和新威脅出現，信息系統基礎設施變更時，進行動態更新；安全運維體系需要周期性的通過安全服務將安全管理體系的管理目標通過安全技術、安全培訓等措施進行有效的落地與實現。5.2 安全技術體系安全技術體系是信息系統的技術保障，使得運維體系達成安全管理目標得以實現。主要是在網絡邊界防護、數據安全、應用安全、物理安全、主機安全、網絡安全、計算環境防御等七個方面，其中網絡邊界防護是目前云計算環境中較為突出的安全問題。IDC邊界安全防護為了防止攻擊流量和非法訪問，在網絡邊界建立可靠的安全防護措施，通過京東ADS系

95、統分析流量情況，并制定引流清洗的策略。京東ADS系統通過部署在IDC邊界，對流經邊界交換機的所有流量鏡像進行統計和分析。根據某些攻擊流量的特征，發現針對目標服務器的異常攻擊流量，將之牽引到清洗系統進行清洗，將正常的流量回注到目標服務器，從而達到保護目標服務器正常服務的目標。部署示意圖：5.2.1 網絡邊界防護整體上，ADS系統分為兩大部分：流量分析和流量清洗。交換機: 列出ADS系統管理的交換機列表。對基于交換機的流量查看、清洗配置等操作。目標IP排行：查詢最近時間段內基于目標IP的流量（Ingress）指標的峰值、均值排行。源IP排行：查詢最近時間段內基于源IP的流量（Egress）指標的峰

96、值、均值排行。異常日志：查詢指定時間段內發生的流量指標超出閾值的日志列表，包含交換機或目標IP。報警任務：查詢指定時間段內發生的流量指標超出閾值且達到一定頻率的，產生的報警任務列表。可針對產生報警的具體目標IP下發清洗任務。清洗任務：查詢當前已經下發給交換機的清洗任務的執行情況，可根據情況停止清洗任務。IP管理：維護交換機上所有的應當受保護的公網IP段白名單。權限：維護ADS系統上的用戶的角色。5.2.2 數據安全通過采用各種技術和管理措施，使網絡系統正常運行，從而確保網絡數據的可用性、完整性和保密性。確保隱私數據安全，防止泄露，丟失。基本特點是：機密性，完整性，可用性。l 公有云系統的用戶數

97、據，不允許輸出。l 私有云系統的數據輸出，遵循研發部數據提取方面的管理規范。5.2.3 應用安全公有云環境下，不同用戶開發的應用相互隔離，防止數據泄露，應用本身的代碼也要防止泄露。由運維安全管理部對線上項目定期進行分布式安全掃描。對于外網IP，定期執行安全評估。除此之外，私有云環境下，由運維安全管理部執行web項目上線前安全評估。5.2.4 物理安全物理安全是主機安全、網絡安全的前提。要充分考慮到網絡系統的特殊性，充分考慮布線，絕緣，隔離，接地，焊接，防雷，防水，防火。充分考慮電源故障，電磁干擾，物理冗余。由甲方運維部定期對IDC進行考核、評定，并定期檢查物理設施。5.2.5 主機安全主機（宿

98、主機、虛擬機），從使用角度，要保證可用性、性能和吞吐量。從主機系統安全角度，需要從賬戶、訪問控制、密碼強度、入侵檢測等方面保證。5.2.6 網絡安全設定網絡隔離措施、網絡連接檢查、網絡連接的冗余設計、做好網絡訪問控制、安全認證等。保障IDC中外網和內網的物理網絡隔離，保障辦公網絡到IDC內網的訪問控制。IDC只能從內網通過堡壘機登錄。堡壘機必須定期進行權限審計。公有云環境中，保障不同租戶之間的網絡隔離。5.2.7 計算環境防御當網絡發生攻擊的時候，網絡基礎設施應該具備自我保護的能力，同時能跟蹤和定位攻擊的來源。根據業務場景制定防護策略。5.3 安全管理體系安全管理體系明確了組織高層安全策略和指

99、導方針。管理體系中的管理要求通過安全運維體系有效落實到信息系統基礎設施和安全技術體系當中，從而達到組織信息安全保障的整體目標。5.3.1 安全管理承諾為確保提供安全的云服務，防范安全事故，依據相關法律法規，業界標準，特制定如下安全承諾：1）認真貫徹執行相關法規和標準，對本公司提供的云服務安全問題負全面管理責任。2）積極落實本公司的云計算安全細則，建立安全管理組織，配備安全管理人員，建立健全安全崗位責任制。3）確保云安全的硬件和軟件資金投入，確保服務安全。4）定期組織員工參加云服務安全教育培訓，提高本公司從業人員的安全意識。5）定期組織云平臺安全檢查，漏洞掃描，發現問題立即修復。5.3.2 安全

100、管理組織目標根據云服務的特殊性，是一種特殊的信息產品，安全管理組織目標如下：1）、確保基礎設施安全，包括網絡設施，主機設備，機房供電管理。2）、確保數據安全，包括用戶信息，用戶應用的敏感數據，用戶數據的冗余備份。3）、確保云服務系統軟件安全，及時修補漏洞，升級版本。5.3.3 安全評審機制為保證云服務的安全性，需要定期評審測試云服務，掃描發現漏洞，及時修復。1）根據安全測試流程，掃描云服務各個安全域。2）確保持續安全，采用周期性評審方法。5.3.4 所有者的管理職責作為云服務的提供商，對云服務的安全問題負有最終責任。1）全面貫徹執行安全管理方針方法。2）審核云服務年度安全工作計劃，長期工作計劃

101、和安全經費，審核安全執行情況。3）審核安全方針和措施的變更，審核和安全相關的重大項目。4）定期召開安全會議，聽取安全管理組織的工作匯報，分析安全形勢，部署安全工作。5）總結，考核云服務的安全工作。5.3.5 知識產權嚴格執行相關的法律法規，使用正版或開源軟件，避免法律糾紛。5.3.6 安全方針的修訂隨著云計算的發展，安全形勢也在發生變化，因此需要及時修訂本安全方針。安全管理組織負責修訂安全方針，所有者審核，審核后發布。5.4 安全運維體系安全運維體系負責落實安全保障措施和制度，技術措施和管理制度要同時落實。5.4.1 發布管理1）IaaS基礎系統，由IaaS平臺自動部署系統進行保證安全的系統部

102、署。2）應用系統軟件，由公司的自動編譯、自動部署進行安全的應用部署。3）均遵循本公司發布管理流程。5.4.2 事件管理系統問題，工單或線上事故的自動或人工處理流程。遵照甲方相關工作流程，重大事故處理遵循甲方的安全管理制度。5.4.3 知識庫管理使用知識庫記錄系統知識，經驗，軟件升級等。5.4.4 問題管理使用問題管理平臺或者知識庫記錄系統中曾經出現的問題，匯總，作為問題知識庫。5.4.5 變更管理使用京東系統變更審核流程管理平臺itsm。5.4.6 配置管理IaaS基礎系統，使用chef、saltstack統一管理系統的配置信息。定期進行基礎軟件版本的升級、漏洞彌補。5.4.7 資產管理由甲方

103、運維部門統一管理線上服務器資產，網絡資源等。系統信息方面，包括建立cmdb等平臺。5.4.8 監控管理統一管理線上各個子系統的監控信息，包括服務器信息，系統資源，服務器性能相關的信息。包括：1）UMP，監控通用的指標。2）Openstack擴展開發的監控系統、同時也作為收費系統的數據來源。5.4.9 風險管理在統一監控的基礎上，統一管理和評估資源使用，強化風險管理。第六章 實施階段項目建設分為四個階段：l 第一階段：IaaS平臺構建；l 第二階段：現有應用系統及現有業務數據遷移l 第三階段：構建自動化IT管理平臺l 第四階段：PaaS平臺構建，大數據平臺構建6.1 第一階段：IaaS平臺構建第

104、一步：在一定規模（按照業務運算需求）的IT基礎設施上部署IaaS服務私有云平臺，配置服務器、網絡、存儲，協作運行；第二步：在IaaS平臺上，部署存儲服務及分布式數據庫環境，為虛擬機和Image鏡像及塊存儲配置存儲服務，建立云數據庫（建立關系型和非關型數據庫環境），建立JDS分布式數據庫環境。第三步：部署彈性應用集群（重點）；第四步：在IaaS上發布的虛擬主機可以在一個彈性的環境中運行，虛擬主機能夠負載均衡和failover，物理資源可以動態的伸縮；6.2 第二階段：遷移現有應用系統及數據第一步：現有應用系統的數據可能分為兩部分，數據庫中的業務數據和文件數據，數據庫很可能使用商業產品的數據庫管理

105、軟件，建議統一遷移到JDS分布式數據庫中或者MySQL集群數據庫中進行統一管理和訪問。歷史文件統一存放在IaaS平臺的文件存儲服務中。第二步：現有應用業務系統很可能是運行在物理服務器上（小機、x86服務器），進行P2V的應用遷移操作，統一遷移到京東IaaS平臺虛擬主機上，現有應用系統在彈性集群IaaS云環境中運行，可以實現負載均衡集群和Failover。6.3 第三階段：構建政務云自動化運維第一步：首先做到設施和資源的監控，包括物理設施和虛擬主機、apps應用的自動監控；第二步：自動化部署、編譯；第三步：結合用戶IT管理業務需求，制定IT管理運維流程，建立ITIL流程體系；第四步：計費管理；6

106、.4 第四階段：構建PaaS和大數據平臺第一步：利用SOA服務標準框架、消息平臺、工作流及緩存等產品和技術，構建政務云PaaS平臺，實現現有及新業務應用系統的服務通訊標準化，開發標準化；第二步：在物理IT基礎設施的環境中構建大數據平臺，初期先把多源數據提取，并做好大數據的存儲，存放在分布式文件系統中和K/V非關系型數據庫中，大數據的數據類型分為兩部分，IT基礎設施數據和業務數據。第三步：IT基礎設施的大數據可以通過基礎設施數據引擎進行大數據的搜索、統計分析；第四步：業務數據，需要通過業務模型算法建模后，通過業務引擎進行大數據的搜索、統計分析；第五步： 數據推送，可以把大數據的分析結果，推送給相關系統及移動終端；95