中國銀聯與上海銀行就金融云與SDN技術研究等達成合作，其中中國銀聯的電子商務與電子支付國家工程實驗室與上海銀行數據中心以下一代金融云數據中心為藍圖，組成聯合研究團隊開展基于SDN的下一代金融云網絡架構技術研究。（上海市科委項目資助（17YF1425800）: 金融行業云關鍵技術研究及應用）
聯合研究團隊認為：云網絡架構是機構開展金融云基礎平臺建設最為核心關鍵的因素，其主要體現如下方面;
首先，雙模IT中網絡是唯一必須兼容兩種IT模式的平滑互通的基礎資源。為兼顧新技術、新架構、新模式于既有的傳統信息技術體系結合，雙模IT將是金融機構IT發展的主要形態，處于兩種IT模式下的金融應用無必須共享服務器和存儲的要求，但必須在網絡層面實現互聯互通。
其次，金融合規性與安全性在IT基礎設施中主要體現在數據中心網絡。金融機構多區域隔離、應用間的強訪問控制以及外部防護攻擊均主要基于網絡規劃與專用網絡設備應用措施。
最后，以軟件定義網絡為代表的新技術應用是云平臺發展的必然趨勢?；谠朴嬎?、大數據與區塊鏈等新技術的金融創新應用產生了新的數據網絡交換模型，對應用所部署的數據中心網絡環境提出了新的技術要求，軟件定義網絡技術效果與之契合，有助于推動金融IT向高效服務化的轉型，從而提升金融機構的創新能力。
然而，由于網絡技術變革難度高與應用影響性廣等因素，當前在全球范圍內金融機構云網絡架構落地實踐整體上還處于初級階段，無標準化統一的架構實踐參考。為此聯合研究團隊經過近兩年多的努力，提出了在當前金融數據中心網絡架構下，應用SDN的云網參考模型，并予以落地實踐驗證，其中主要完成工作包括：
金融云數據中心需求梳理與新架構網絡設計原則規劃。結合當前金融行業網絡架構現狀分析，梳理了未來金融數據中心網絡高敏捷、高彈性、高可管理、高可用以及高性能的“五高”要求，歸納總結了未來金融數據中心網絡架構“面向服務理念、管理統一編排、資源池標準化、成熟技術集成再造創新”的四大設計原則。
定義基于SDN的下一代金融機構網絡的標準化參考架構。聯合研究團隊提出了“多數據中心間虛擬專網互聯，數據中心內核心交換總線互通，傳統分區、云網分區并存”的云網絡架構模型，模型給出了網絡管理平面與數據平面的標準實現架構，服務能力涵蓋二/三層網絡連通性能力以及負載均衡/防火墻L4-L7服務能力。
驗證標準化參考架構的核心關鍵技術。研究團隊已基于開源技術通過自主研發的區域互聯（Region Interconnect）SDN控制器實現了對核心交換網絡（國際首創）與各分區的SDN控制器的協調控制，從而實現數據中心內網絡資源池化以及網絡資源彈性調度服務。
上述云網架構模型的應用可實現新一代符合金融行業云要求的網絡架構，其效果主要包括：
平滑兼容傳統架構?？捎行еС蛛p模IT，可在保持傳統網絡架構穩定運行的前提下，支持SDN等新技術的前瞻性應用。
兼容異構網絡技術。通過自主創新的區域互聯（RI）SDN控制技術，實現對廠商設備異構解耦，屏蔽不同廠商在SDN技術實現中的技術差異性。
網絡多租戶能力擴展性強。網絡租戶能力不局限于單一網絡設備區域，可有效擴展至異構設備區域以及跨數據中心區域。
安全合規等級不降低。新模型設計之初即基于現有網絡安全與合規性的要求考慮，新技術的應用嚴格遵守現有金融規范。
在研究過程中，我們認識到金融云計算技術研究是技術集成創新與產業協同創新的復雜系統工程，金融云計算技術的自主可控需要良好的產業生態支持，因此也同步與國內外產業界保持密切溝通，探索相關技術在金融行業范圍內以工作組的形式深化聯合研究，在工作組內共享技術研究成果，共同以工作組的團體力量與國內外云計算組織展開合作，推動金融云技術的研究與進步，加速金融科技的變革，支撐金融服務的創新發展。
金融行業網絡建設歷程與金融行業近三十年信息化過程密不可分，目前為止已經歷多個階段發展。
現階段金融行業網絡整體多以“兩地三中心”架構為主。利用DWDM及高帶寬專線構建高速轉發“核心骨干網”用于數據中心間互聯，數據中心作為骨干網接入節點。在核心骨干網框架上擴展延伸出“三級網”架構用于各級分支機構的匯聚，數據中心至一級分支機構間構建一級網，一級分支至二級分支機構間構建二級網，二級至三級分支機構間構建三級網。示意圖如下：
數據中心內部采用“總線型、模塊化”架構，遵循“垂直分層、水平分區”的原則，根據應用系統種類不同、重要性區別、安全防護需求差異將網絡劃分為多個區域，通過高性能交換機構建交換總線，網絡各分區通過總線進行互聯互通，如下圖：
網絡分區可劃分為三大類：業務區、隔離區、特定功能區。
業務區：用于承載各類系統應用服務器及數據庫服務器，應用系統根據特定原則劃分至不同業務區。
隔離區：也稱DMZ區，承載各類前置機，面向互聯網或第三方機構提供服務。
特定功能區：如管理區承載監控系統、流程系統、操作終端等，用于數據中心維護；廣域網區用戶數據中心至骨干網的連通。
傳統架構優點：安全、穩定、可靠、可擴展。
架構缺點：靈活性不足、豎井壁壘存在、自動化不高、建設成本高昂。
當前，“業務應用變革式創新發展”、“以云計算為代表的新技術應用”以及“金融IT成本與效率優化新要求”是金融數據中心網絡發展面臨的三大挑戰。
首先業務應用發展對網絡服務提出新的挑戰，面向互聯網方式的金融創新應用快速發展對網絡服務提出更敏捷的服務要求，網絡資源的開通與變更希望是從原本的周為單位提升到分鐘級別，從而支撐應用快速投產。
其次，云計算等新技術在數據中心內越發應用廣泛，其對網絡連接也提出新的要求。為適應虛擬化技術，資源的漂移遷移能力，網絡服務需要從物理機識別提升到虛擬主機識別，云的多租戶特性要求在共享的物理網絡設備下提供可獨立解耦的網絡地址路由空間，云彈性伸縮則要求網絡有更高地彈性擴展能力，巨大的云平臺規模，也要求云網絡服務也必須具備足夠的網絡容量與健壯性。
再則，新常態下金融機構的運營壓力要求IT架構可實現更高效與低成本，從純商業“產品”解決方案向“自主”網絡方案演進，金融數據中心網絡技術應用更趨于開放，要求網絡運維人員從單純的人工維護解放出來，進入高效的自動化方式。
因此，結合上述發展的挑戰與趨勢，我們認為未來金融數據中心網絡應用需求可總結為高敏捷、高彈性、高可管理、高可用以及高性能的“五高”要求：
高敏捷，實現業務快速上線，面對應用的變化達到資源的按需變更，通過新技術應用打破因重安全而舍效率的困局，在云計算新環境下安全與高效并重；
高彈性，一是內部彈性強化，打破豎井式架構中網絡區域成為限制資源共享的壁壘，實現網絡資源池整合與靈活共享與隔離，二是外部彈性兼容，支持新老架構并存，從而使原有網絡可以平滑過渡到新架構；
高可管理，一是實現管理的體系的簡化，支持多品牌的融合管理，二是實現管理自動化與智能化，使日常運維從大量人工維護的高工作量解放出來；
高可用，網絡架構持續穩定影響金融數據中心全局服務能力，網絡架構需要基于穩定可靠的技術構建，使網絡服務具備7*24小時業務連續性服務的能力；
高性能，面對秒殺等新業務場景等的極限服務能力，實現時延和帶寬等關鍵指標的跨越式提升，同時注重資源的高效利用，用盡可能少的資源實現最大的性能服務。
SDN技術的應用對金融數據中心的架構是革命性的變化,因此下一代金融數據中心網絡需進行針對性設計，我們總結未來金融數據中心網絡需遵循以下四大設計原則：
面向服務理念，網絡功能以服務、標準API接口的形式對外提供，網絡系統內部以服務的形式進行自組織，從而提升對外服務能力，簡化外部調用網絡能力的復雜性；
管理統一編排，數據中心內網絡二/三層連通、四/七層功能的管理界面統一視圖，不同網絡資源池的管理采用二級管理編排方式，即底層適配不同網絡資源池管理操作、上層異構協調編排；
資源池標準化，打破傳統網絡豎井式架構，利用新一代的大二層技術構建資源池，在不擴大廣播域、不增加二層環路風險的前提下提升計算、存儲資源調動靈活性。
成熟技術集成再造創新，基于網絡技術平滑兼容的要求，對基礎可擴展網絡技術與協議進行繼承，組合現有技術進行集成創新，創新而不失穩定，保證網絡架構的全局穩定。
（1）管理控制平面模型
傳統網絡中各功能組件，如交換機、防火墻、負載均衡，通常采用不同的設備供應商解決方案，各產品管理接口存在差異（CLI、UI接口各不相同）、普遍不支持API接口。設備參數設置、配置調整大量依賴人工，且對于維護人員的專業技能要求較高。在此背景下，網絡的服務化、自動化實現難度巨大，難以實現單一的工具或平臺對全網設備進行統一管理和服務發布。
隨著產業技術的發展，網絡產品制造商也逐漸改變產品發展方向，由原先的封閉式設備向接口開放的方向發展?，F階段，業內越來越多的產品開始支持Restful API接口，管理模式不再局限于傳統的CLI及UI接口。
數據中心新架構中，為了實現網絡服務化、自動化、統一編排調度等目標，除了要求網絡各組件支持API接口、可編程等功能特性外，我們認為在管理控制平面，還需對各品牌網絡的API接口做進一步抽象，通過云網控制平臺建立標準網絡服務模型，并與各網絡組件對接。一方面 ，實現網絡服務接口的標準化，統一網絡對外接口，屏蔽不同品牌設備接口的差異性，簡化上層云管理平臺的開發難度。另一方面，將復雜的網絡參數隱藏，網絡各組件的技術實現、參數設置仍由專業網絡工程師完成，上層構建云管理平臺專注于服務流程、業務編排、工作流調度、網絡標準服務調用等。
云網控制平臺又可分為兩個層次，分別為服務抽象層和驅動控制層。
服務抽象層負責將網絡資源抽象成標準的網絡服務和模型，例如提供創建網絡、創建路由器服務，同時對上層平臺提供標準的網絡服務API接口。
控制驅動層負責將標準的網絡服務在具體的產品上實現，并將上層的API接口翻譯成網絡組件可識別的接口，實現對網絡組件的參數調整。
（2）交換網模型
傳統交換網絡穩定有余但靈活、高效不足。各網絡分區之間計算、存儲、網絡、機房物理環境等資源均為獨享模式，不同分區之間計算宿主機無法共享資源，虛擬機不允許在不同分區宿主機間漂移，計算資源利用率下降。中小型金融機構交換網及各功能組件以普遍采用萬兆級設備，設備性能強勁，但出于安全性、可靠性及合規性的考量，金融機構數據中心網絡分區數量無法減少，在客戶群規模、交易量不大的情況下，網絡資源利用率普遍較低。在機房空間利用率上，各類設備的擺放需綜合考慮布線、TOR交換機部署、電力、制冷等諸多因素，難以實現靈活部署。若采用傳統技術，例如大二層，試圖解決上述問題，又會造成廣播域的放大、二層環路風險增加，對于后續運維造成巨大壓力，得不償失。
因此，我們認為新的交換網架構需在不增加運維風險的前提下提升計算、存儲、機房空間資源的利用率。同時引入租戶的概念，對一個交換網絡進行隔離劃分，對于單個金融機構可用于實現部分傳統網絡分區的合并部署，也可用于多金融租戶的合并部署。
金融數據中心新交換網架構仍采用總線型架構，保留傳統分區、傳統應用接入，新增多個云網分區用于新應用上線或存量應用遷移。在風險可控的前提下，對部分功能相同的網絡區域進行合并部署，例如多個業務區合并為一個云網分區，多個隔離區合并為另一個云網分區。
一個云網分區內由同一品牌的SDN設備組成，內部采用Vxlan分離Underlay、Overlay網絡，實現網絡物理架構與邏輯架構的解耦。采用Spine+Leaf的物理結構，其中計算Leaf接入提供虛擬機的計算服務器資源，網絡功能Leaf接入負載均衡、防火墻等網元服務設備資源，Border Leaf負責與數據中心核心交換設備互聯， 云網分區內由Spine設備負責各Leaf之間的流量互通，每個云網分區由其自有的控制器進行管理控制。
（3）分區之間互聯模型
數據中心核心交換網絡則是由獨立交換設備組網，不同云網分區可能使用不同的SDN解決方案、協議與技術，云網分區內部的Vxlan標簽在數據包出區域后被剝離，因此云網分區之間在Overlay層面無法實現互通。
上述數據中心內的組網模型與功能設計的挑戰主要在于如何將存在于不同云網分區的租戶流量進行識別，從而保證通過核心交換網絡后，云網分區可以正確將IP地址重用的多租戶流量轉發至正確的租戶資源。經過評估，我們認為傳統技術中的VRF（虛擬路由轉發表）或MPLS-VPN(基于多協議標簽交換的虛擬網絡)技術能很好的解決多個云網分區之間租戶信息傳遞的問題，可將一個VRF或VPN網絡抽象成一個區域互聯路由器，用于連接同一租戶不同邏輯區域。
同時，我們提出了一種區域互聯SDN控制技術，實現對核心交換網絡與各云網分區的SDN控制器的協調控制，實現多租戶信息標識的傳遞的隧道能力。
圖5介紹了在數據轉發平面的設計思想，每個租戶在出各自云網分區時，送入不同的虛擬路由表VRF（或VPN）進行轉發，VRF是交換機內部隔離不同路由轉發的虛擬化技術，實現了虛擬機的一虛多能力。
在相應控制平面，我們設計了一個RI控制器實現對核心交換網絡的自動化配置能力，其包括2大功能，一是根據租戶變動情況動態創建配置VRF及其相關配置，二是實現在不同SDN 云網分區資源動態變化情況下，路由地址動態發布，以便保持動態變換的網絡資源的連通性。
圖6給出了RI控制器的架構設計，其通過netconf協議管理核心交換網絡的設備，同時也通過適配不同SDN控制器的API接口定時或觸發讀取相應云網分區的動態資源信息。在跨異構SDN新租戶創建過程中，則會自動根據前述數據轉發平面的設計創建相應VRF通道，在有新網段資源創建時，觸發RI控制器通過SDN控制API查詢新增網段信息，并通過OSPF動態路由注入的方式更新核心交換網絡中的VRF路由表信息，同時我們設計的RI控制器定時任務，定時查詢SDN的網絡資源信息，對比出已刪除的網絡資源信息，進行路由表清理工作。
在具體研發過程中，我們考慮到了核心網絡設備支持的不同操作管理協議，以及未來不同合作伙伴今后提出新的隧道協議應用方式，因此在代碼架構上我們支持了不同設備控制方式和隧道協議的擴展能力，以便未來完善優化。
（4）防火墻與負載均衡模型
防火墻及負載均衡用于提供四到七層網絡服務，實現邏輯區域之間的安全隔離、服務器流量分攤。
金融云網架構模型中，可將防火墻及負載均衡等硬件資源進行池化部署，并按需進行調度。通過云控制平臺實現防火墻、負載均衡資源池的統一管理。隨著VNF技術的日益成熟，在未來，負載均衡和防火墻將作為VNF接入到不同業務邏輯區域當中，實現流量的合理編排和調度。
在金融行業普遍采用“兩地三中心”的高可用場景下，金融行業云平臺的網絡服務也必須支持跨數據中心的網絡多租戶能力。
在設計中可沿用現有骨干網的設計思路，并引入MPLS VPN技術，將同一租戶的流量引入一個VPN網絡中，實現單一租戶可調用的資源范圍覆蓋所有數據中心，并支持分支機構的接入。同時利用MP-BGP豐富的選路能力以及QoS技術，實現租戶信息跨數據中心傳遞，租戶之間、應用流量之間相互隔離。
基于以上設計構想，研究小組就單中心模型進行原型驗證，詳細情況如下：
圖8展示了的原型平臺物理架構圖，交換核心區域由華為三層交換機組成，下聯2個不同品牌的云網分區，云網分區1為華為設備，云網分區2為思科ACI設備，根據不同云網分區IT服務商的合作溝通，負載均衡和防火墻的物理接入位置稍有不同，華為云網分區內負載均衡和防火墻接入網關組，思科云網分區內負載均衡和防火墻接入專用功能Leaf，但邏輯網絡架構保持一致。
我們在中國銀聯與上海銀行聯合研究的數據中心實驗環境搭建了原型平臺，平臺由華為、思科兩套異構SDN云網分區構成，同時也配備了相應的負載均衡和防火墻資源，平臺設備列表如表1：
平臺基于OpenStack、OVS、Centos等開源軟件進行研發，相應軟件版本情況如表2：
使用OpenStack作為云控制平臺，起到了承上啟下的作用,向上暴露標準化的API給到多租戶業務調度。另外一方面它通過底層SDN控制器、防火墻驅動、負載均衡驅動和RI模塊，實現對下層物理網絡資源的抽象、隔離和調度。
云網分區架構下，需要管理的四種資源：二層網絡（思科APIC和華為AC）、三層網關、防火墻和負載均衡。云網分區和云管理平臺集成的一般有以下兩種模式：
A模式通過SDN控制器驅動二層和三層，四層以上設備通過OpenStack Neutron直接管理，B模式通過SDN控制器驅動所有設備。我們現有的防火墻和負載均衡分別是思科的ASA防火墻、華為的USG防火墻以及F5負載均衡設備，下表是兩種設備通過A模式和B模式下具備的驅動具備現狀：
我們選擇了A模式和B模式混合的方式進行組網：
思科ASA防火墻我們重新開發了OpenStack FWaaS驅動進行管理（A模式）
華為USG防火墻通過華為SDN控制器進行管理（B模式）
－ F5負載均衡通過F5官方提供的OpenStack驅動進行管理（A模式）
在以上集成的基礎上，我們開發實現了網間互聯的RI模塊，用來完成對核心交換機的策略下發，最終軟件驅動的架構如下：
下面我們將詳細介紹每個模塊的具體集成。
（1）思科APIC和華為AC的整合
OpenStack對接思科APIC和華為的AC SDN控制器，需要在原生OpenStack的基礎上，在控制節點、網絡節點和計算節點上做配置的變更。
（2）F5負載均衡集成
在OpenStack LbaaSv2模型中，負載均衡服務被抽象成loadbalancer，listener，pool，member，health monitor五種虛擬資源。一個loadbalancer下可以掛載多個listener，不同listener監聽端口不同，一個listener下掛載一個pool，一個pool掛載members和health monitor。這些虛擬標準資源和F5資源的對應關系如下：
LbaaSv2 Driver將OpenStack中虛擬負載均衡資源通過RPC的方式發送給F5 agent，一個F5 agent可以管控一臺F5設備、HA模式F5集群或者Cluster模式F5集群，同時F5 agent的分布式部署方式使得F5設備的橫向擴展能力得到提升，通過LbaaSv2 Driver中的調度算法，將OpenStack中虛擬負載均衡資源合理的分配到不同的F5設備當中。
在和華為AC集成的時候，F5的管理通過 OpenStack進行調度，再通過AC中的L2BSR的方式接入到AC網絡中。
在和思科ACI集成的時候，F5的管理通過 OpenStack進行調度，再將F5設備通過ACI中的Physical Domain方式接入到ACI中。由于ACI將虛擬網絡類型變成了OpFlex類型，且該虛擬網絡的VLAN（或者VNI）由APIC進行分配，這樣導致OpenStack Lbaas在給F5下發配置時因為缺少VLAN或者VNI的信息而下發失敗，需要通過修改F5的代碼支持OpFlex類型來支持下發，或者啟用F5提供的Global Route模式來解決。
（3）防火墻集成
和負載均衡一樣，OpenStack為防火墻服務提供了V1.0和V2.0兩種API模型， FWaaS 2.0在社區M版本中提出，現在仍在開發中，因此我們采用FWaaS 1.0 模型和防火墻設備進行集成。
同樣的，防火墻服務被抽象成多種虛擬資源，分別是firewall，policy和rule。一個firewall可以關聯應用到多個router，一個firewall使用一個policy，policy是rule的集合。和ASA防火墻的對應關系如下：
FWaaS Plugin將OpenStack中虛擬防火墻資源通過RPC的方式發送給ASA agent，一個ASA agent可以管控一臺ASA設備、HA模式ASA集群或者Cluster模式ASA集群，同時ASA agent的分布式部署方式使得ASA設備的橫向擴展能力得到提升，通過FWaaS Plugin中的調度算法，可將OpenStack中虛擬防火墻資源合理的分配到不同的ASA設備當中。
（4）網絡資源與OpenStack映射模型
云管平臺上層支持多個金融機構，每個金融機構是一個租戶。每一個租戶在OpenStack里對應一個項目，包涵多個邏輯云網分區和一個RI組成的隔離資源區。單個租戶的每一個邏輯云網分區對應一個物理云網分區，每個物理云網分區支持多個租戶的邏輯云網分區。
在和ACI集成中，一個邏輯云網分區對應ACI中的一個租戶概念，一個ACI租戶含一個VRF，一個VRF內虛擬網絡的流量全通。
在和AC集成中，一個邏輯云網分區對應AC中的一個VPC概念，一個VPC含一個VRF，一個VRF內虛擬網絡的流量全通。
原型平臺基于多租戶能力，創建了中國銀聯與上海銀行兩個金融機構租戶，兩個租戶的網絡地址完全隔離復用，每個租戶橫跨華為與思科的兩個云網分區資源，且共同復用所有硬件資源，通過核心交換網絡進行數據互通。如下圖在極端情況下，兩個機構租戶的虛擬機資源的部署與地址規劃與開通完全一致
圖13展示了原型平臺金融機構租戶管理員的管理服務界面，原型平臺實現了云數據中心虛擬路由、負載均衡、防火墻網絡資源以及相關網絡安全配置的自動化開通能力與統一視圖展示。
基于當前銀聯生產技術的選型以及開放的研究角度，我們基于OpenStack開源技術進行了研究實現，在實現過程中不斷匯總梳理了相應遇到的問題，一些影響核心應用的問題我們進行了個別優化解決，一些問題仍然有待解決，我們計劃提交社區優化，具體如下：
（1）二/三層網絡模型
三層模型不支持雙出口
現有路由器模型僅支持一個去往互聯網的External出口，模型不支持設置雙出口，但金融機構DMZ區的往往需要兩個出口，一個去往內網、一個去往外聯網或互聯網。
（2）防火墻模型
地址及服務對象定義方式有限
僅支持IP或網段，不支持IP范圍、網段范圍等，無法將多個地址對象組合成為一個地址組使用。無法將多個服務對象組合成一個服務組使用。這些限制會導致策略數量急劇增多，降低防火墻效率，不利于維護。
無法針對特定服務設置連接超時時間
無法滿足特定長連接應用的需求，導致應用異常。
無法針對特定服務設置應用層協議探測
傳統防火墻支持的ALG功能，動態開放端口等，在遇到非標端口時需進行設置（例如FTP協議使用了2121端口情況），但在防火墻模型中無此概念。
無法針對特定策略設置有效時間
無法基于防火墻實現地址轉換
（3）負載均衡模型
負載均衡部署模型受限
現持單臂有負載均衡模型僅支模式，不支持雙臂、多臂等。
無法設置連接超時時間
無法滿足特定長連接應用的需求，導致應用異常。
無法設置會話保持設置超時時間
無法滿足特定長連接應用的需求，導致應用異常。
支持算法較少
Listener支持類型較少、支持會話保持方法較少、支持負載均衡算法較少、支持健康檢查方法較少
（4）其他方面
部分網絡關鍵組件缺少模型
如：IPS、DDOS網絡安全、鏈路負載均衡等。
同時，我們通過研究后，我們也認為SDN Fabric控制器以及其他網絡設備的API能力，或其提供的管理軟件驅動可以進一步加強，以便可以在實現金融網絡SDN能力時，可以更方便的獲取相應細節參數以及加強管理的精細化力度。
經過上述研究與實踐，中國銀聯與上海銀行的聯合研究團隊認為SDN技術的應用將是未來金融數據中心網絡的發展趨勢，當前技術積累，即未來基于SDN的下一代金融云網絡架構設計可以推動未來的生產逐步應用。同時我們也認為金融云建設是一項技術集成創新、產業協同創新的重大、復雜性高的系統工程工作，金融機構技術研發應立足于金融科技核心，聚焦于SDN等技術應用之金融機構的特色技術解決方案，注重產業合作創新。當前，我們有計劃與期望籌建金融行業在云計算領域的聯合研究工作組，橫向凝聚金融機構的研究力量，縱向聯合IT產業各方，積極影響OpenStack等開源社區研發方向，共同推動金融云關鍵技術的突破與應用，提高金融云科技技術的普適性與標準化，非常歡迎大家，尤其是金融機構的合作伙伴能夠一起參與我們發起的聯合研究工作中，并多給予寶貴的指導意見，讓金融云技術在世界范圍內聯網通用。
