各位專家各位領導大家下午好!現在由來我匯報一下云平臺在溫州鐵路AFC的應用。本次匯報有6個部分組成，首先簡單的介紹一下AFC的系統。

軌道交通數據也就是我們常說的AFC是由計算機、自動售票、自動檢票，以及票管理，財務結算，客流量分析的軌道交通的業務自動化的管理系統。簡單點說這個系統主要是解決錢、票和數據三種關系的系統。目前AFC系統的設計工作實施的是參照著國標頂層架構展開的，第一層是軌道交通的ACC，第二層是計算機系統LTS，第三層是車站的SC，第四層是現場的終端設備，第五層是車票的讀卡器，其中我們相對于ACC系統和LC系統定義為中央級，車站計算機系統定義為車站級。ACC系統是整個軌道交通線路AFC系統最上層的管理中心，在建設層面上我們用四個中心來概括。其中第一個是系統運營的管理中心，第二個是票務信息的管理中心，第三個是線路之間的協調中心，第四個是運營狀態、監控管理中心。ACC系統一般都是設在線網控制中心，屬于第一條線網的建設。線路ACF系統是實現了線路內部的交易數據和監控數據的升級、分析并上傳給內部中心，也就是ACC，實現在主線路出票和車卡的一個調配，實現對線路運營狀態、監控、處治命令的下發，與ACC的對照，接受上級下發的車票準備，票價運營模式等參數給相關火車站，實現線路內部的安全精準的管理。

車站計算機系統主要是針對車站AFC終端設備進行監控，實現對車站AFC系統的運營、收益以及維修的集中管理，終端設備主要是包括了供乘客使用的自動售票機，自動檢票機，以及閘機，以及工作人員操作的自動售票機。

目前這個系統在整個車站均采用了IC卡車票，種類包括了單程票、儲值票、乘次票、旅游票、紀念票、出站票、員工票等等，票的種類可以根據需要進行增加。

第二部分介紹一下溫州市的服務。溫州市軌道交通線路是由6條線路組成，總線路是361.8公里，設站是128個，換乘站是14座，其中市級線路是SE到SC總共有4線，線路組成是25.3公里，市區現在是2條，線路是92.5公里。發改委關于溫州市軌道交通規劃，延續了2012到年2019年實施S1線一期工程S2一期工程和S3線工程，線路總長是140.7公里。目前正處于建設狀態的是溫州市S1線一期工程，這條線路的全長是53.51公里，一共車站是19個，其中地面站2個，高架臺14座，底架臺3座，并預留了兩個車站，近期的站間距的是3.13公里，遠期大概是13公里，設立控制中心，同時線網工程以及S1一期工程是同期建設的。

S2一期是10月份剛剛拿到了設計的批復，目前正在進行招標，最快是明年上半年開工。S3一期正處于工程的階段，屬于前期的設計階段。

S1一期系統當時是分成了兩個標段，一個是AFC系統，2015年上半年完成了ACC系統和線路AFC系統招標，2015年下半年完成了ACC系統的設計聯絡，2016年上半年是完成了線路FC系統的聯絡和AFC系統線網標準的AFC，2016年大概9月份由中國軌道交通協會專業委員會完成了溫州AFC系統升級方案，同期完成了溫州AFC系統線網化標準，計劃今年年底完成終端設備的樣機運行，和ACC云平臺在溫州現場的搭建工作。

第三部分介紹一下溫州AFC系統的具體架構。剛才已經介紹了我們現在的AFC的架構是按照5層的架構展開實施的，考慮到溫州線路網的特點，我們將第二層線路中央系統ACC取消及部分功能合并到中心系統，將傳統的架構給全新的4層架構。4層架構主要體現在，從線網的層面上來看建設的工作較低，由于系統云化升級之后系統的速度更高，數據的多樣性更好，符合未來發展的需要以及大數據的要求。當時的設計是在2013年，受到了技術的限制，主要是過多占領了同時介入線網ACC系統就造成接入壓力，容易形成途徑，從而降低了整個系統的性能。針對此問題，在ACC系統和AFC之間增設了交換機等接入設備，對于一條線路傳上來的數據，然后再傳給ACC系統，分擔了ACC系統的接入壓力。其實這個問題從技術上就能解決，因此考慮到S2S3線可能取消接入交換機，讓SC系統直接聯SC系統。

第四部分是云平臺的運用，因為溫州AFC系統采用了4層架構，相當于ACC系統功能進一步的擴大，功能更強，因此我們結合了當然計算機的發展水平提出了云平臺的方案。在此之前先回顧一下AFC系統的傳統的方案。主要是四部分：第一部分是有一個小機，主要完成的是管理子系統，供他們使用;第二部分是存儲設備;第三部分是多臺PC服務器，供各類子系統使用，一般的每個子系統對應一臺或者多臺的體系;第四部分是網絡設備，包括交換機和防火墻。而云平臺主要是三部分：第一部分采用的是基于X86架構的一體機，能完成各類數據業務。第二部分是多臺PC服務器,也是基于X86架構的，給其他各類系統共同設置的，第三個部分的網絡設備與傳統方案一致。從硬件上來講，傳統方案和云方案的基本差別并不是太大，從軟件上來講最主要的區別就在于存儲的位置，傳統方案在制定的一臺或者是多臺或者是PC的服務機上，而云方案的軟件是在虛擬機或者是云平臺管理系統，云方案能夠很好的解決了設備的單點故障問題，同時還可以很好的解決資源共享、合理分配資源、系統彈性增長一直困擾的傳統ACC系統建設時出現的問題。

這兩張圖就是溫州現在的ACC系統的系統服務，主要是三個部分組成的，存儲池、計算池和資源池，存儲池剛才說了是用一體機組成，計算池是采用了18臺新華三的服務器，網絡池是存在了新華三交換機和6臺兼容交換機，同時整個云平臺的燃燒也是采用了新華三的云平臺管理軟件。考慮到系統的安全性，可能在異地設置了一套系統一級系統，大的整體架構是能夠和系統保持一致，也是采用了云的方案。

前面講的基本上是硬件，我們認為的還有一個云平臺的管理軟件，它有一個好的軟件就是必須要有基于集群的集中管理，還有高可用性，動態的資源調度，具有完美的生命周期管理，同時在各種性能的監測，包括了虛擬機的虛擬交換的一系列網卡中的，它能夠進行全面的資源調配，并且對動態資源擴展。

第五部分是需要解決的問題。在一個系統建設前，首先看為什么要建這個系統，它的需求是什么，主要是基于兩點：一個是業務的可用性，第二個就是運維的管理，同時要兼顧的成本節約，也就是最大化投入回報。基于以上幾點，我們做了一個系統性的架構。如果是AFC專業的話基本上都是系統級的容載，雖然在系統上是很好的，但是在后期運營其實是一種資源的浪費，這個系統常年不用，因為主系統ACC從這多運營的城市來看很少會出現故障，所以一般像我們投資千萬左右，其實是造成了資源的浪費。如何有效的解決這一部分設備的使用是我們面臨最主要的問題。基于此，我們現在是兩種云，初步的設想是將這兩種云變成一種云，可以解決一部分的問題。

下面后續的展望和主要內容。 我們的想法是采用現在比較流行的雙核雙中心的方案，讓容災系統也到這個管理中來，主中心系統作為整個系統的中心，同時應用服務器集群在平時作為資源池的資源參與到日常的ACC系統的業務處理當中來，只有有ACC的主系統出現故障或者是崩潰的情況下，提升為中心級替代整個ACC日常運維的連續性。這樣做的好處是可以有效的控制成本，同時還可以提高AFC系統設備的使用率。

我們想進一步的將云平臺的規模擴大，實際上AFC系統簡單的劃分為兩部分，一個是前端的數據采集，第二個是后端的數據處理。數據采集主要就是由SLE及讀卡器、車票量化完成，后臺的數據處理主要由服務器存儲設備來保障完成。S1系統當時設計的時候也是有這方面的考慮，所以前面介紹了所有的網絡都是基于前端設計的，如果后期條件允許，或者是各種情況都滿足的情況下，我們會做大，像SC系統已經納入到整個云平臺的管理中來，我的匯報就到這里，謝謝大家!