IT 架構作為企業架構的基礎，支撐著上層業務架構的建設與發展，進而促進頂層愿景和戰略的順利實施。在企業信息化建設快速發展的今天，信息系統規模越來越大，復雜程度越來越高，IT 架構技術支撐能力的重要性愈加凸顯。近年來，隨著金融產品和服務模式的持續變革，以及銀行業轉型發展的深入推進，促使人們不斷思考銀行IT 架構面臨的挑戰和影響。
各大型國有商業銀行經過十多年的發展，都已經實現了數據集中，而且，隨著客戶服務的不斷發展和提升，各家商業銀行核心業務系統的賬戶量和交易量都已經逐漸達到了一定規模，系統的處理能力和性能以及可用性、可靠性、數據一致性、業務連續性等要求極高。在這個過程中，集中式架構發揮了重要作用，各家銀行的核心系統基本都構建在集中式架構之上，尤其以大型主機架構為代表。集中式架構下，一般采用縱向擴展的方式即通過增加單機的資源配置來提升系統的處理能力。通過硬件設備和基礎軟件的集群機制來提升系統的可用性。當前，各商業銀行目前仍以采用IBM 大型或小型主機為主的方式來構建自己的IT業務系統。
與此同時，以螞蟻金服、騰訊等為代表的互聯網企業則走出一條完全不同的技術路線，他們采用X86 開放平臺、開源軟件構建了云計算平臺。在此基礎上建立了新的分布式聯機交易處理架構，可以處理海量并發支付交易。支付寶“雙十一”秒殺促銷活動和騰訊微信春節“搖一搖，搶紅包”活動均創造了單位時間并發交易量遠超各大國有商業銀行的單位時間交易量峰值的奇跡。隨著互聯網金融的迅猛發展，互聯網分布式架構得到不斷應用、優化和完善，技術逐步成熟，并體現出與主機集中式架構相比在運行風險控制、可擴展性、敏捷開發、灰度發布和總擁有成本等方面的優勢。分布式架構以X86和云計算為基礎、以數據切分（Sharding）、讀寫分離為特征，采用橫向擴展的方式，通過增加服務器的數量，提升系統的處理能力，每個節點都是一個可獨立運行的單元，失效時也不會影響應用整體的可用性。另外，系統可以分散到多個節點運行，降低了對單節點的處理能力和可靠性要求，給使用X86服務器替代高性能的主機和小型機服務器創造了條件，可大大降低基礎設施的投入成本。
同時銀行自身也面臨著來自業務模式和業務量的巨大變化，一是隨著移動互聯網、線上支付、電子商務的快速發展，金融服務的渠道和場景更加豐富，服務模式和體驗更加新穎，需要IT系統在支撐多渠道服務協同、信息共享聯動、提高服務個性化智能化等方面發揮更大作用。二是隨著各行各業互聯網化和現實世界數據化趨勢的不斷演進，人類社會已進入了數據大爆炸時代，銀行需充分發揮數據價值，助推客戶營銷、產品設計、風險防控和經營管理轉型，這就要求IT系統在數據存儲、分析挖掘、數據服務等方面給予有效支撐。三是隨著業務處理線上化和自助化的絕對數量和占比持續提升，信息系統對于銀行服務的基礎支撐作用日趨關鍵，要求IT架構在安全穩定運行、業務承載能力等方面提供更有力的保障。這些都對于IT架構提出了新的挑戰和要求。
那現在問題來了，銀行到底是繼續采用集中式架構還是全部更換成分布式架構，是繼續保持現有傳統架構還是改造成基于云計算的全新架構？本文將從以下幾個方面進行論述。
傳統銀行走的是集中式交易處理道路，大多數銀行的核心系統采用了集群數據庫架構；傳統銀行的應用架構圍繞交易處理為核心的模式，將外圍產品與核心系統進行松耦合設計，圍繞傳統金融的原子事件的模式組織交易。銀行核心系統需要嚴格保證每一個原子交易事務處理的一致性原則，要求具備ACID的特性：A(Atomicity)——原子性，C(Consistency)——一致性，I(Isolation)——隔離性，D(Durability)——持久性。Automicity-要求一個事務中所有操作具有原子性，所有操作要么全部完成，要么全部未完成；Consistency-保證事務在開始和結束時數據庫應該在同一狀態；Isolation-保證事務間的邏輯隔離，事務因此會單獨進行數據庫操作,多個事務之間不會相互影響；Durability-要求事務一旦完成操作，就不能撤銷了。銀行系統由于需要提供社會民生等不可或缺的基本金融服務，因此其對于資金賬戶安全性及交易一致性的要求要遠超互聯網公司，所以銀行的核心IT能力必須選擇一致性和可用性，向客戶提供金融服務，如果無法保證一致性和可用性，那整個核心金融服務將不堪設想。基于這樣的設計原則，大多數銀行的核心系統采用了單站點集群數據庫架構（single site clustering database）。這種架構在傳統的關系型數據庫上將數據邏輯集中，通過緊耦合的數據提供整合的單一邏輯形象，支持跨多個業務線的緊耦合的大聯機交易量的處理，能夠保證信息的實時的單一真實性，無需通過應用層跨系統的集成開銷來保證數據和交易的一致性。
業界對于分布式架構尚未形成統一的定義，但基本包含“基于分布式架構的系統是一組相互獨立但并行協同工作的計算機集合；對系統的用戶來說，系統就象一臺計算機一樣”這兩層意思。從硬件角度，每臺機器都是自治的、獨立的；從軟件角度，用戶感受是整體的、一致的。據此，分布式架構應具備以下特征：一是物理部署分布式，即用多臺計算機來共同承載業務；二是處理過程分布式，系統各環節各司其職、并行處理，通過特定機制有效協同關聯；三是數據存儲分布式，將數據分散存儲，但不影響數據運算結果的完整性和一致性。綜合上述特點，分布式架構設計的核心理念是“并行拆分與橫向擴展”，即按照一定維度將系統進行拆分，系統各部分松耦合并行運行，并建立起較為完善的橫向擴展與容錯恢復機制。
分布式系統是個由多個互相連接的處理資源組成的計算機系統，它們在整個系統的控制下協同執行同一個任務，最少依賴于集中的程序、數據或硬件。這些資源可以是地理上相鄰的，也可以是在地理上分散的。分布式系統隱含的共同特征是：場地分布、數據分布、硬件平臺多樣化、操作系統多樣化、應用平臺多樣化。
相比而言，互聯網公司由于面對數億級別用戶、數百億級別的瀏覽量、PB級的數據量，所以可伸縮性是至關重要的。互聯網公司放棄了ACID，轉而偏向BASE：基本可用（Basically Available）、軟狀態（Soft state）、最終一致（Eventually consistent）。依照理論計算科學著名的布魯爾CAP定理，一個分布式計算系統一致性（Consistency)、 可用性（Availability）、分隔容忍（Partition tolerance）三項中最多只能滿足兩項。對于互聯網分布式系統而言，網絡分區是既定的，只有在放松對一致性的要求或放松對可用性的要求做出選擇；互聯網公司都選擇了可用性，而放松了對一致性的要求。互聯網企業的應用架構為提供高伸縮性、高變化的服務，普遍采用開源、橫向擴展的分布式計算模式。在無共享分布式架構下每一個節點都是獨立、自給的，而且整個系統中沒有單點競爭，具有靈活的可伸縮性。
目前主流的互聯網公司如google、yahoo、淘寶等在分布式框架下的設計原則上都有高度一致性：首先做到“能分則分”，把問題分解成易于處理的模塊，如果不切分就無法擴展規模，比如電商的用戶數據、商品數據、購買數據不斷分攤到更多的主機上去處理；第二做到“能異步則異步”，用異步原則來解決伸縮性、響應延遲等問題；第三做到“能自動則自動“，讓更多的手工調整變成自動調整，借助了機器學習的方式來完成；第四做到“記住所有失敗”，互聯網應用無法避免錯誤，但是應該記錄分析所有錯誤來不斷提升應用的體驗。
1、集中式架構的優點
集中式架構系統底層一般采用成熟的商業基礎軟件構建，這種架構的優點是成熟穩定，可用性、可靠性好，銀行的技術人員可專注于業務功能開發，無需過多關注底層技術的實現。
（1）可靠性更高。由于集中式架構的軟硬件歷經了三十多年的發展，擁有了不斷成熟的技術，完善的商業支持體系，相比新興的分布式架構更具成熟穩定和可用性。同時由于集中式采用服務器數量比分散式更少，可以減少硬件的故障點和概率，從而可以提升系統的可靠性和穩定性，減少硬件維護的工作量，降低系統管理的繁瑣程度。目前某大型商業銀行主機系統日均承載了近4億筆交易，峰值達到每秒1萬多筆，并繼續保持著快速增長的態勢，在監管機構要求日益加強的前提下，IBM的大型機表現出了高度的系統可靠性。
（2）交易和事務的強一致性。銀行集中式架構可以保證交易和事務的強一致性，不同于社交信息處理、互聯網信息處理、電商交易處理等可以容忍最終的事務完整性而不追求實時的事務完整性。
（3）業務連續性更有保障。對銀行系統的災難備份，集中式結構下，能夠實現災備的方式，相對較多。分散式結構下，要建立災難備份系統，難度相對較大。由于設備數量多、地點可能分散、平臺不一定一致，對災備技術的選擇比較受限制，可選方案相對較少。之前某銀行采用IBM 大型主機GDPS 雙活解決方案結合應用優化，成功實現了跨數據中心全球核心業務的分鐘級切換運營。該雙活方案是在兩個數據中心之間同時運行著同樣的應用并擁有同樣的數據，在兩中心之間可以智能地調度金融交易，當任何一個站點的系統在計劃內或計劃外停止運行時，其金融交易均可在分鐘級內全部切換至另外一個中心對外提供服務。
（4）開發和運維的復雜度較低。某銀行在全國數據大集中后，核心業務系統交易成功率和業務連續性得到了進一步提升，產品創新與推廣更為高效，業務量年均增長率近30%，至2016年底，日均交易量在2.6億筆左右，峰值交易量突破3.2億筆/日。自集中以來，雖然業務產品和業務量均大幅增長，但底層技術架構基本保持不變，運維更為集中統一，有力地保障了業務快速發展和生產的平穩運行。
（5）安全性更高。同時由于IBM 主機由于其專用和封閉的特點，系統各模塊之間的數據通訊傳輸不需要從網絡、操作系統、數據庫系統和應用多層面采取安全加固措施，包括鏈路和數據加密、身份識別、訪問控制、數字簽名、入侵檢測、系統加固、審計跟蹤等等，提高系統安全性。實際上，即使采用主機集中式架構，系統本身在一定程度上更為安全。
（6）硬件系統擴容簡單。集中式結構下，除了可以采用橫向方式進行擴充外，由于單臺主機具備較好的擴充能力，因此可以采用縱向方式進行處理能力的擴充。縱向擴充方式，僅涉及硬件配件的增加，數據庫軟件和應用軟件不需調整，實現起來相對容易。
（7）初期采購成本和運行成本相對要低。機房建設成本，采用分布方式進行系統建設，一般需要的主機數量從數臺到數十臺不等。這些主機，都需要基本的機房占地（包括主機自身面積和每臺四周一米左右的維護空間）、承重設計、電力供應、制冷需求。累計到一起之后，通常對機房的基本建設提出很大的需求。尤其對于一些保密性要求較高的中心機房，機房建設成本往往不是以平面面積進行衡量，而是以立方面積進行計量的。這種情況下，每增加一臺主機設備，將導致機房基本構建成本的大幅度上升。而采用集中方式進行系統建設，所需要的主機和存儲設備大幅度減少，相應對占地面積、承重設計、電力供應、制冷設備等基本建設方面的要求都大大降低，從減少了機房建設成本。運行成本方面集中式架構的運行成本較低。由于采用較少的設備，在機房個數、機房空間、電源功率、機房制冷、保修費用等方面，集中式都比分散式相對節約。
（8）共用資源的使用率更有效。分布式架構需要對每臺主機都配置本地磁帶機、光驅、顯卡、顯示器等設備。而集中模式則可以根據需要對每臺主機只配置一套這類設備。如果在每個分區都安裝公共的外圍設備，如磁帶機、磁帶庫、光纖存儲設備或高性能通訊卡等，是最簡單容易的辦法，也是最浪費的方式。而集中式架構，可以做到在每個分區需要上述設備時，動態劃分給它，當分區不需要時，可以從此分區拿掉，劃分到其它需要的分區上。這避免了每個分區都實際配備外設造成的浪費，提高了公用設備的整體利用率。因此，集中模式對系統資源的利用更加有效。
2、集中式架構的缺點
缺點方面，集中式架構主要的缺點如下：
（1）風險度集中。雖然產品比較成熟穩定，但一旦出現軟件或者邏輯上的極端異常，也有可能導致整個集群不可用，從而引發全局性停業。
（2）性能容量存在上限。雖然對于目前的銀行業集中式架構仍可以滿足性能業務需要，但是由于我國人口基數大，隨著經濟的快速發展，業務量在全球處于領先，同時伴隨以搜索引擎、社交網絡、電子商務等為代表的互聯網時代來臨，數據量以每年50%以上的速度快速增長，對信息系統處理能力帶來了空前的挑戰。集中式架構容易出現性能容量瓶頸。而且許多新的問題、產品缺陷將有可能首先在我國觸發。
（3）成本高昂。集中式架構對基礎軟硬件產品的可靠性、可用性依賴度高，這些技術產品基本被極少數公司所壟斷，缺乏有力的競爭者，IT成本居高不下。
（4）核心技術受制于人。供應鏈風險較大。
1、分布式架構的優點
分布式架構按照一定的維度將系統進行拆分，通過一定的負載均衡機制，將業務分攤到多個節點上處理。這種架構的優點是可以采用更開放的架構，各節點松耦合，對底層產品的可靠性、可用性依賴降低，可以基于廉價的硬件和開源軟件構建，受單一廠商的制約較少，可以引入多家廠商競爭，成本更為低廉，可用性、可擴展性更好。尤其是隨著應用規模的擴大，邊際成本將更低。
（1）系統擴展能力較強。可基于通用硬件擴展計算和存儲能力來提升系統處理能力，滿足業務不斷增長的需求；通常，一個企業會買一臺大型主機來完成所有的工作。而當公司繁榮擴充、工作量就會增大，當其增大到某一程度時，這個主機就不能再勝任了。僅有的解決辦法是要么用更大型的機器（如果有的話）代替現有的大型主機，要么再增加一臺大型主機。這兩種作法都會引起公司運轉混亂。相比較之下，如果采用分布式系統，僅給系統增加一些處理機就可能解決這個問題，而且這也允許系統在需求增長的時候逐漸進行擴充。
（2）系統成本優勢明顯。分布式系統基于相對廉價的通用計算和存儲設備構建，獲取相同處理能力的成本低于傳統架構。隨著微處理機技術的發展，現在人們只需花幾百美元就能買到一個CPU芯片，這個芯片每秒鐘執行的指令比80年代最大的大型機的處理機每秒鐘所執行的指令還多。如果你愿意付出兩倍的價錢，將得到同樣的CPU，但它卻以更高的時鐘速率運行。因此，最節約成本的辦法通常是在一個系統中使用集中在一起的大量的廉價CPU。所以，傾向于分布式系統的主要原因是它可以潛在地得到比單個的大型集中式系統好得多的性能價格比。
（3）系統運行可靠性較好。將系統拆分后并行運行在多臺相同的設備上，即使單一設備出現故障，整個系統仍可正常運轉或僅局部受損；同集中式系統相比較，分布式系統的另一個潛在的優勢在于它的高可靠性。通過把工作負載分散到眾多的機器上，單個芯片故障最多只會使一臺機器停機，而其它機器不會受任何影響。理想條件下，某一時刻如果有5%的計算機出現故障，系統將仍能繼續工作，只不過損失5%的性能。
（4）系統運行效率較高。在對系統各環節合理拆分的基礎上，通過并行處理進一步突破傳統串行處理存在的效率瓶頸；
（5）信息共享的方式更為靈活。從長遠的角度來看，主要的驅動力將是大量個人計算機的存在和人們共同工作與信息共享的需要，這種信息共享必需是以一種方便的形式進行的，而不受地理或人員、數據，機器的物理分布的影響。
（6）使用更為靈活。分散式結構中，所有主機的功能單一，若需要變換功能，需要對系統進行較大調整。集中模式下，各分區的功能可以根據需要進行調整，如果將來有業務擴充或者功能增加時，實現起來比較容易。相比而言，集中模式的靈活性更強。
（7）能夠為業務產品創新、降低功能耦合程度等方面的提供更多的支撐。分布式架構的靈活可擴展、并行高效率處理等優勢，在業務促銷、復雜產品估值、實時風險防控等方面發揮價值；
分布式架構作為有別于傳統集中式架構的設計，也有其自身的局限性。
（1）數據和事務一致性較差。在對系統進行拆分后，如何協調各部分之間的并行處理，確保最終處理結果的一致性，分布式系統由于其數據分開存放，不同功能并行處理，為了確保系統整體可靠性，往往采用“數據最終一致性”的原則進行設計，需在產品功能設計層面同步予以考慮。
（2）增加了開發和運維的復雜度。根據CAP理論，在可用性、分區性與一致性三者之間，同時只能滿足兩個，如果要滿足可用性（A）、分區性（P），就需要犧牲一致性（C），業界的一般做法主要是根據業務特點，通過較為復雜的應用設計，放棄實時一致性、保障最終一致性來解決該問題，分布式架構增加了應用設計和研發的復雜度。此外，隨著節點數的增加和分布部署，對運維管理、異常處置也提出了更高的要求。
（3）支持軟件的成熟度和穩定性較低。什么樣的操作系統、程序設計語言和應用適合這一系統呢？用戶對分布式系統中分布式處理又應該了解多少呢？系統應當做多少而用戶又應當做多少呢？就目前的最新技術發展水平，我們在設計、實現及使用分布式系統上都沒有太多的經驗。
（4）跨網絡訪問過程中可能存在的信息丟失和通訊延遲。由于它會損失信息，所以就需要專門的軟件進行恢復。同時，網絡還會產生過載。當網絡負載趨于飽和時，必須對它進行改造替換或加入另外一個網絡擴容。在這兩種情況下，一個或多個建筑中的某些部分必須花費很高的費用進行重新布線，或者更換網絡接口板（例如用光纖）。一旦系統依賴于網絡，那么網絡的信息丟失或飽和將會抵消我們通過建立分布式系統所獲得的大部分優勢。
（5）安全性偏低。上面我們作為優點來描述的數據易于共享性也是具有兩面性的。如果人們能夠很方便地存取整個系統中的數據，那么他們同樣也能很方便地存取與他們無關的數據。換句話說，我們經常要考慮系統的安全性問題。通常，對必須絕對保密的數據，使用一個專用的、不與其它任何機器相連的孤立的個人計算機進行存儲的方法更可取。而且這個計算機被保存在一個上鎖的十分安全的房間中，與這臺計算相配套的所有軟盤都存放在這個房間中的一個保險箱中。
（6）系統整體的可靠性方面技術復雜。如何確保在單個節點異常情況下系統正確切換與恢復，確保系統整體可靠性等等，這都需要在系統設計與實現層面制定有針對性的解決方案。
（7）對于研發和運維的人員要求高。分布式架構對于架構設計、研發、運維等人員的知識結構有著新的要求，需要有相配套的人員知識結構。
（8）分布式架構需要科技和業務部門深度耦合。分布式架構下系統各組成部分的相互關系及作用模式發生了較大變化。除了在系統架構設計和研發等方面的變革，更由于系統部署模式、故障恢復機制的變化，須在運維監控、應急處理等方面進行配套，需要研發部門與運維部門之間的緊密協同，密切配合，將科技和業務人員深度耦合在一起。
（9）部分場景下成本不低。對于功能相對簡單、服務需求相對穩定的業務，使用分布式架構反而將顯著增加設計與實施成本。
綜上所述，分布式和集中式兩種模式，各有利弊。筆者認為在構建銀行系統的過程中需兼顧集中式和分布式兩種IT架構。一方面，通過集中式架構保證銀行系統的資金賬戶實時性、安全性及交易一致性；而另一方面，通過分布式架構向數量眾多、分布廣泛小微客戶提供高擴展性、多變化的應用服務。因此筆者建議在構建銀行IT系統過程中，對于涉及銀行核心交易的IT應用，應該嚴格遵守一致性要點；而對于面向互聯網的非核心應用，可以用分布式架構來支撐其運行。向集中式和分布式架構有機融合的架構體系進行轉型。
具體做法如下：
（1）是主機平臺上。深入研究業務特點和應用架構，將可以下移的應用和數據遷移到開放平臺。進一步推廣主機開放融合架構，擴大查詢交易遷移范圍。將交易路由層分離出來，采用獨立的負載均衡設備實現交易的統一接入和負載均衡調度，減少了對主機的依賴，降低了資源消耗。采用讀寫分離設計，構建主機開放融合架構，將查詢類交易的應用邏輯處理下移到國產X86服務器上，將明細數據下移到開放平臺上，基于Hadoop架構實現明細業務查詢。將可以下移的業務系統整體下移到開放平臺，減少主機資源使用。
（2）是開放平臺上。通過對集群技術、虛擬化技術、分布式數據庫、分布式存儲等技術的深入應用，采用Linux替代UNIX，用X86服務器替代小型機，引入集群數據庫和MPP數據庫，探索存儲虛擬化應用，構建更加開放的分布式架構，結合業務特點對應用進行精心設計，從應用接入層、應用服務層到數據服務層和存儲服務層建立不同的分布式架構，以同城和異地災備中心建設為契機，將業務合理分布到多個中心，構建多活架構，進一步提升系統的健壯性和應急處置能力。
（3）是運維管理上。分布式架構降低了單個節點對基礎軟硬件的可靠性、可用性依賴，通過架構來保障系統的整體可用性。但隨著分布式架構、虛擬化等技術的實施，設備與系統數量快速增長，一個系統涉及的節點眾多，為運維管理帶來了較大的挑戰。因此需要加強開發與運維的融合，持續優化完善現有的監管控平臺，加強流程平臺與自動化平臺的融合，進一步提升端到端的運維管理標準化、自動化水平，提升問題發現、定位、處置能力。降低分布式架構所帶來的運維壓力。
采用互聯網分布式架構替代傳統的主機集中式架構開發構建銀行核心業務系統在技術上是可行的，并且能解決銀行核心業務系統面臨的困難和挑戰，大大降低了核心系統的總擁有成本，提高自主可控能力。但替代是一次技術路線的重大轉移，國有商業銀行實施技術轉型過程中應該進行充分地學習研究、分析論證和測試驗證，周密規劃，穩步推進。
1、對功能相對穩定、與客戶資金安全緊密相關、且無明顯性能容量壓力的業務，一段時期內仍以傳統集中式架構實現。對于業務新穎性強、創新速度較快、交易并發量大，或者對信息系統部署有特殊監管要求的境外業務，則逐步以開放平臺分布式架構實現。
2、對于原有部署在主機集中式系統的存量非核心業務，可以考慮逐步遷移至開放平臺分布式架構系統。隨著交易種類和交易的快速增長，應充分發揮主機系統和開放平臺系統的不同優勢，可以將客戶增值服務信息、歷史明細、現金管理、會計要素管理、小額支付、金融市場、投資理財等相關業務遷移至開放平臺。逐步減少主機的負載和壓力。
3、對于原有部署在開放平臺并采用傳統集中式架構的系統，可以結合業務特點差異有選擇性地實施分布式架構改造。對于已有的網上銀行、手機銀行、銀企互聯、信貸管理、客戶營銷管理等系統，可以結合銀行自身業務發展需要和業務內在特點，差異化地實施IT架構優化提升。對于線上支付、短消息提醒、產品集中銷售等業務量波動較大的內容，應逐步按照分布式架構實施改造；對于柜面業務處理、客戶營銷管理等業務量相對穩定的內容，則重點基于集中式架構持續優化提升。
1、提高認識，調整戰略。要認識到進行核心業務系統技術替代的重要性和必要性，互聯網金融技術“狼”真的來了，面對新的技術浪潮，要采取積極的應對措施，實施IT戰略轉型。銀行需要從業務視角出發重新思考IT 和業務的關系，提高業務系統的敏捷性，實現業務和IT 的融合，在控制風險的同時，盡可能“多、快、好、省”地為業務創造價值。
2、虛心學習，奮起直追。面對互聯網金融技術，商業銀行經歷了從“不屑一顧”到“不以為然”、從“警醒震驚”到現在“奮起直追”的過程。實際上，在云計算、大數據、移動計算和社交媒體等技術應用開發方面，商業銀行已經落伍于互聯網企業了，現在是放下商業銀行采用主機“高、大、上”身段的時候了。商業銀行應該虛心向互聯網公司學習云計算和分布式處理技術，結合銀行業務系統特點，采用云計算和分布式架構改造其核心業務系統。
3、排除困難，大力推進。從技術上說，實施替代的難點在于同現有技術體系的融合，是全盤替代還是部分替代，替代項目的實施管理難度也很大。從管理上說，要充分認識來自方方面面的阻力，既有技術人員和業務人員因循守舊和技術偏好造成的抵觸情緒，還有可能來自廠商及其代言人出于商業利益的阻撓、恐嚇和游說。因此，替代工作需要獲得上級主管部門、銀行高層領導的大力支持，方能順利實施。
4、大膽設想，小心求證。既要看到云計算和分布式技術的巨大潛力與優勢，也要重視可能存在的弱點和不足，特別是要充分評估對業務和客戶體驗造成的影響。認真對銀行核心業務進行梳理和分析，識別銀行業務相對互聯網信息處理在交易一致性、安全性等方面的更高要求。對各種分布式處理技術進行充分的分析評價和測試驗證，做好技術選型和架構設計。
5、搞好試點，逐步推廣。同引進各種新技術、新產品的過程一樣，為了有效控制引入新技術的風險，國有商業銀行替代核心系統也應經歷先試點、后推廣的過程。在試點過程中完善新平臺技術架構，制訂實施工藝和規范，形成開發和運行工具。特別要對云計算和分布式處理方面的開源軟件進行學習、消化和吸收，組建一支技術過硬的互聯網分布式架構開發隊伍，為實現技術路線的全面轉型做好準備。
綜上所述，分布式架構具有更好的可擴展性，對基礎軟硬件的可靠性、可用性依賴度更低，可以采用更加開放、廉價的產品構建。但我們也要看到其給應用設計、研發、運維管理所帶來的挑戰。總之，技術是為業務服務的，無論是集中式架構還是分布式架構，各有優缺點，我們需要根據不同的應用場景，選擇合適的技術架構。此外，銀行與互聯網企業在信息系統建設上，無論是業務類型、風險容忍度、監管要求上，還是技術架構和文化機制上，有著較大的差異。確保客戶資金安全和生產運行穩定，是銀行信息化建設的首要原則，在分布式架構應用當中，要結合技術可控、風險可控、成本可控綜合考量，要本著實事求是、穩妥前行的原則逐步推進。
“我來見您啦！”一年后，火爆全網的方艙考研女孩再續前緣。
3月31日世界備份日來臨之際，備份是前提，恢復是目的，經得起考驗的產品才是網絡安全的保護盾！
隨著網絡威脅、惡意軟件等的演化，網絡安全防護方案也須更新迭代。
數騰科技一位祝姓銷售經理向記者表示，他們有自己特殊渠道去拿取一些數據。其中最為主要的渠道就是通過第三方SDK獲取數據。
工業機器人的總體成本中，核心零部件的比例接近于70%，其中減速器占據最大的比重。
