银行系统
1 軋差
軋差指的是當日A和B銀行有資金來往，早上B要給A銀行打10萬，下午A要給B打20萬，經過軋差，日終清算的時候，A只需要給B打10萬就行了，不然就浪費時間了。
2 結算 清算 清分
根據《中國銀聯銀行卡聯網聯合技術規范V2.1》定義：
清分 Clearing
對交易數據依據機構和交易類型進行分類匯總，并計算結算金額的過程。
清算 Settlement
指根據清分結果對交易數據進行凈額軋差和提交并完成資金劃撥的全過程。
結算 Settlement of Accounts
指完成客戶賬戶間資金劃撥的全過程。
簡單的說：
清分=記賬
清算=算賬
結算=轉賬
3 回執
回執就是對方收到以后給你寄一個單據，表示“收到”認可。
銀行處理業務完畢都要給你回執，表明此筆業務已完成，寄快遞的時候也必須由工作人員把回執單留下，表明已經過當事人。
4 日切
通俗一點說就是銀行要停業結賬，但目前有許多24小時營業的項目如：自助設備、網上銀行、POS等，這樣就必須在某一個時點將當日業務終止，然后開始統計和匯總各類報表，從這個時點開始發生的業務全部記入下一日期。
支付系統日切就是對支付系統當天的業務進行集中處理,日切完畢后系統將進入下一個工作日，一般的支付系統實行7×24小時不間斷運行,每日16:00進行日切處理,即前一日16:00至當日16:00為支付系統的一個工作日,有利于清算。
5 大額 小額 超網 三者區別
人行主要的支付系統:
小額批量支付系統：除系統維護外，全年7X24小時工作，單筆交易金額小于5W走該系統。
大額實時支付系統:單筆交易金額大于5W一律走該系統，全年5X21小時工作，5個工作日為周一到周五，一個工作日的計算為23:30到次日20:30。
網上支付系統:全年7X24時工作，手機銀行與網銀單筆交易小于5W的實時到賬。
6 網上支付跨行清算系統與大小額支付系統有什么區別？
1、處理方式上：
大額：逐筆實時全額清算
小額：批量發送，定時清算
網銀跨行：逐筆實時清算
2、支付限額：
大額：支付0起點，無限額，所有貸記業務均支持
小額：貸記業務上限5萬，借記業務無限額
網銀跨行：單筆上限5萬
3、運行時間：
大額：工作日8：30-17：00
小額：7×24小時運行
網銀跨行：7×24小時運行
7 沖正
沖正是為系統認為可能交易失敗時采取的補救手法。即一筆交易在終端已經置為成功標志，但是發送到主機的賬務交易包沒有得到響應，即終端交易超時，所以不確定該筆交易是否在主機端也成功完成，為了確保用戶的利益，終端重新向主機發送請求，請求取消該筆交易的流水，如果主機端已經交易成功，則回滾交易，否則不處理，然后將處理結果返回給終端。
8 金融銀行前置系統簡述
摘自 金融銀行前置系統簡述
應用于小型銀行的核心體系，主要由前臺和后臺以及若干小前置組成，前臺發起交易給后臺，后臺處理后返回，如果需要外聯，后臺聯動請求給小前置出去。這種架構對于不大于市級規模的銀行使用已經足夠了，一旦小型銀行規模成長為在全國擁有多家分行，比如擁有跨地域開設分行的城市商業銀行，各地的業務差異性復雜性給系統架構升級帶來了必要性。
適用于第二類規模的核心架構為“前臺（以及ATM、網銀等）-渠道前置-大前置-后臺”，前臺發起的交易以及其它渠道諸如網銀交易等，由渠道前置統一接入大前置，并分擔渠道壓力，大前置負責統一調度核心系統交易，同時渠道前置還負責與外聯的渠道接入。因為有了大前置，所有周圍系統只需要跟大前置做接口，包括通訊接口和報文接口，簡化了渠道和后臺的技術接口，但也給大前置帶來了性能壓力，一般采用集群方式。
全國性銀行系統架構主要體現在行政區域的前置分級和后臺的業務系統化上，一般采用“前臺（以及ATM、網銀等）-市級渠道前置-省級渠道前置（-地方性業務系統）-綜合大前置-各個業務系統”，省市級渠道前置除了分擔龐大的交易連接壓力外，還擔任了級聯架構中地方獨有業務的大前置角色，對于它來說，地方性業務系統就是本級的后臺，綜合大前置包容了大前置的交易統一調度功能，還把后臺的一些公共的業務邏輯處理移過來，一方面以減少與后臺的交互環節，另一方面也達到基礎數據統一管理，與前一架構相比較，變化最大的是后臺拆分成各個業務系統，比如可以按對公對私拆，也可以按業務拆，還有一個明顯的特點是會計核算系統從傳統意義后臺中分離出來成為一個獨立的系統。
系統架構中各部分的技術基礎設計原則推薦：
前臺設計思想
前臺作為一個交易發起渠道，是間接面向客戶直接面向柜員的系統，因此系統要求主要在于數據域表單的展示和控制，展示主要是靜態頁面的布局表達，比如某某交易中涉及的業務要素集合布局和顯示布局，控制主要是頁面中數據域與數據域之間的動態聯動關系，比如某某數據域在在哪些情況下是可顯示不可用的，某某數據域接收到某某事件后彈出選擇窗口。
一種比較靈活的設計是采用一種通用標記語言（比如XML）來描述靜態頁面的數據域集合和結構布局，編寫顯示引擎來輸出為最終的頁面，這種做法的基本思想是數據和顯示分離（一個類似的例子是XML和XLST代替HTML），這在前臺開發中大量的頁面重構活動中能獲得高效的適應性。選用一種腳本語言或者前臺平臺宿主語言的回調機制來實現頁面數據域的控制，如果選用腳本語言，那么此語言必須足夠的靈活以能實現各種各樣的計算要求，還要設計一種與前臺平臺宿主環境的數據交換機制。一個頁面（可能包含一個或多個交易表單），可能觸發若干個數據域控制聯動交易，以及最后的最終提交交易。
簡單規模的技術實現可以是字符終端，優勢在于簡單干凈高效；高端實現可以是基于瀏覽器或者基于C/S的圖形界面，優勢在于界面美觀、便于圖片和表單界面同時顯示，這在引入憑證影印系統后顯得格外重要。
渠道前置設計思想
渠道前置主要實現了渠道通訊接入和渠道報文轉換，在前述第三種系統架構中還扮演了省市級大前置的角色，面對各種各樣的通訊方式和報文格式，系統要求主要在于靈活性和擴展性。
大陸銀行以及各大外聯單位的通訊方式主要是TCP、IBM MQ、CICS、Tuxedo、SNA等，前兩種在實際應用中占90%以上。TCP主要是因為簡單，操作系統直接提供無需安裝第三方軟件，IBM MQ不說了，你們懂得。
報文格式主要是固定長度格式、分隔符格式、8583格式、XML格式等，固定長度格式的優點在于簡單，打包解包速度快，缺點是可能會浪費存儲空間，一般用于重視處理效率的場合；分隔符格式比較節約存儲空間，但是打包解包速度稍慢于固定長度格式，還要注意雙字節引起的解包錯位問題，而且還要考慮分隔符轉義，一般用于字符取值空間比較單純，數據域長度差異性比較大的場合，人行一代大小額采用的TAG域格式報文是分隔符格式的變種；8583格式是銀聯卡交易報文接口標準，幾乎遍布所有卡交易中，其改造后也可以作為通用交易報文格式使用，其實就是數據字典和固定長度格式結合體；XML格式在目前使用越來越多，特別是在人行項目和財政項目中，其具有自描述性、人可讀性，能附帶前面幾種報文格式所不能包含的大量完備信息，它的缺點是打包解包速度慢，需要安裝第三方解析器（比如libxml2、MS XML），因為格式相對復雜而帶來的編碼難度和繁復度，適用于對效率和穩定性相對要求不高的系統中。
此外，在上述列舉的通訊方式和報文格式外還有很多隨時會作為外聯接口被要求在渠道前置中支持，所以模塊化和可擴展性對于前置系統設計尤為重要。一種普遍采用的思路是把各種各樣的通訊細節和報文轉換封裝成組件，設計統一的數據流和控制流接口，通過動態語言的動態機制或者靜態語言的動態鏈接庫動態掛接和卸載，這也是國內各大前置開發商的千篇一律的宣傳口號，但是基于該思想最終能實現到怎樣層次的靈活性和擴展性就是千姿百態了，這里不便評價。這里還涉及到開發抽象性，即編碼和配置的分離（這在通訊組件使用時不是很明顯，因為同一種通訊方式的參數大同小異），主要體現在報文轉換中，同一種報文格式可以衍生出很多不同布局的具體報文規范，比如一種XML打包解包組件支持的XML層數，支持可重復明細，支持在可選擇子樹，支持內外XML報文嵌套，支持解析中帶文件名的XML樹葉的額外處理，支持對XML報文做的簽名值再作為XML樹葉掛入XML報文中等等，如果XML報文轉換組件不夠強大靈活到可以支持各類怪異的報文規范，那么在自己能實現的靈活性層次上如何提供外部接口，以最終實現怪異的報文規范，這是個現實問題。有多少開發商能充分考慮客戶體驗，踏踏實實的投入技術資源實現高層次的靈活性和擴展性，而不是所謂的客戶現場定制＝完整的推倒重寫在產品宣傳中無比強大的組件，這也是個現實問題。
前置系統中一個很重要的功能——特別是在大前置和綜合前置中——交易調度，或者叫做交易路由。交易路由的主要功能是根據交易碼及其它信息判斷交易下一個請求后臺或者交易已經完成（成功或者失敗），返回交易發起渠道。交易路由控制有很多種實現，最硬的是通過編碼實現，也有通過配置完成。交易路由控制中應盡量少摻入業務邏輯處理，簡潔、可復用的路由配置是良好的設計開端。
大前置或綜合前置作為交易調度中心，應該擁有內部報文格式，與渠道和后臺之間只要實現外部報文和內部報文之間的轉換就可以了，避免了多種報文對多種報文轉換的組合復雜度。當然單純一進一出的小前置為了簡化設計可以不采用內部報文。內部報文格式決定了報文轉換組件的接口和數據結構的表達豐富程度，一種簡單的設計是創建基于某類業務的小數據字典生成的固定長度格式報文，另一種炫耀的設計的是XML格式。
前置內部數據交換方式很能衡量前置規模，反過來前置規模決定了內部數據交換方式。一般的小前置結構簡單，交易量小，采用unix消息隊列可以有效簡單的流水式傳遞各進程之間的數據塊，當結構變得復雜，交易量較大的場合，應該采用類似IBM MQ之類的消息中間件，后者還有一個顯著的好處，它是跨物理機器的，很容易在其上部署集群，這在大前置或綜合前置設計中尤為重要。
說到前置就不得不說核心系統數據交換報文格式，在嚴肅的負載重的環境中，個人還是推薦固定長度格式，因為固定長度格式打包解包效率高、與數據取值空間無關（相反的例子是分隔符格式需要的轉義問題）、隨機訪問數據域定位速度快、設計實現簡單，但這種格式主要為高性能系統而選用，便于程序處理，對人不是很友好，所以在一般的系統環境中，可以嘗試著采用XML格式，XML格式最大的優點就是自描述性，面向人比較友好，其它都可以作為固定長度格式的反面評價，而且還與具體的第三方解析庫相關聯。
后臺業務系統設計思想
后臺業務系統其實就是一個應用服務器，它接收前置的轉發請求，調用業務處理邏輯，最后把處理結果返回給前置。因此可以把后臺大致的分為兩層：平臺層（通訊服務層、報文轉換層）和應用層（交易管理層、交易處理層）。
平臺層實現的是一個應用服務器框架，包括進程管理、通訊接入、報文調制、與應用層接口、系統錯誤處理等。在進程框架中，平臺應該是一旦成熟很少去編譯它，應用通過組件方式動態掛接使用。一種最偷懶的簡單設計是完全依靠交易中間件來充當應用服務器。稍稍復雜的設計是守護進程在TCP端口上偵聽，一旦有交易請求進來，創建一個子進程負責接待處理，子進程裝載覆蓋應用代碼段映像，把進程控制權交給外部可執行程序，接收通訊報文，轉換報文為內部數據結構，業務邏輯處理，轉換為通訊報文，返回響應給交易請求端。這種設計簡單有效，其實就是cgi的翻版，缺點在于系統fork負載大，不適合于高交易流量系統。更大規模的后臺平臺設計首先應該更改的是采用長進程組成的進程池，那么覆蓋代碼段映像也不適用了，改成動態鏈接庫，在系統模型設計上，Apache的Leader-Follow值得借鑒。再大規模肯定要考慮集群，這又要牽涉到數據交換方式，通訊中間件是一個合適的選擇方向，平臺層和應用層處在不同服務器組內。最大規模的都是大機的世界了，比如AS400，大機里的進程模型等和小機差異很大，只有那個世界的技術人員才有資格談論這個話題了。
應用層實現的是與平臺層接口、數據庫事務管理、交易管理和業務處理邏輯等。數據庫事務區域大致分為交易流水登記、交易檢查、登記簿處理、賬務處理、交易流水更新等五大主要事務，交易管理除了管理以上數據庫事務外，還兼有公共數據處理、原子交易拆分及內部數據交換等。一種簡單的交易管理框架是根據原交易碼和預配置的原子交易拆分規則預置子交易執行序列，然后依次執行之，執行前后需要進行原交易報文和子交易報文的數據映射，以期實現子交易的隔離性和獨立性。子交易拆分涉及到具體銀行的業務邏輯復雜度和架構師的喜好，水很深，不便賣弄。
應用層中的內部數據結構是一個咬牙切齒的話題，在c世界里用的最多的是結構體，但是c的靜態編譯特性決定了一旦調整結構就要重新編譯而帶來的一系列問題，特別忘記漏更新了會帶來難以預料的后果，但這并不是不能解決，采用抽象數據容器可以使編譯器無法染指應用中的數據布局，一種簡單的實現是創建一個指針鏈表，為了提高效率也可以是指針數組，數據容器是個好東西，它所帶來的缺點差不多只有兩個：實現復雜度、使用復雜度。可能還有其它的方案，但都是可用的，最終使用權在架構師手中，無論他選擇哪個方案都不用擔心招致反駁。
應用層中的控制流模型也是一個百爭不厭的話題，c世界里，務實主義者完全靠函數調用來實現控制流，這樣顯得簡單直接，先進性主義者喜歡搬弄諸如函數數組之類的高級控制流結構，這樣便于實現配置，但歸根結底，好用就行。
銀行業務分類也是具體結合本銀行而各有各的傳統分法。粗者直接儲蓄、會計了事，細者按業務系統滿滿的塞滿整個屏幕，根據管理學中級聯管理層次橫向不宜過多不宜過少的原則，一種推薦的分法分會計、存款、貸款、卡、支付結算、代理委托、國際業務。會計從其它業務中剝離出來組成獨立的分類乃至賬務系統的好處是其它分類只需管好自己的登記簿和流水表就行了。
金融字典設計
金融數據字典是每個銀行勢在必行的任務，這在整理本行業務結構、技術規范、教育培訓等都具有非同尋常的意義。數據字典最重要的信息結構是分類樹、中英文對照和名詞解釋、數據域格式和長度、枚舉空間。曾經有公司有雄心發布自己的金融數據字典，最后卻落得孤芳自賞，其原因有很多，比如缺乏權威機構的支持，金融數據字典帶有濃厚的銀行自身業務特色，很難有一個統一的數據字典能放整個行業皆準。不過花點資源，整理出本行數據字典還是很有好處的。
日志
日志系統作為軟件系統的基礎構件，穩定性要求非常高，怎樣能保證高穩定性？簡潔設計。與其引入復雜臃腫的第三方日志系統，還不如多花點資源根據本行技術需求好好開發一套日志系統。小規模日志系統可以是“打開文件－寫文件－關閉文件”，簡單就是最好的，稍稍復雜的可以創建日志句柄引用不同的日志分類（文件），再加入日志等級等，再復雜的可以通過遠程守護實現日志異地落地的日志服務器、日志文件轉檔等。日志系統的設計一定要控制規模，需求很容易變得很復雜臃腫，只選擇最必要的，并考慮一些擴展性，即可。
監控體系設計
監控體系有兩部分構成，一是交易簡約信息的實時展示，二是系統資源監控。前者可以借日志系統異步發送交易信息實現，并保證一旦出現問題不會影響交易本身。后者一些重要的系統資源有：CPU、內存、磁盤、數據庫等，應用資源有進程、IPC、中間件、網絡等。
自動化數據綁定
c#里有一個工具可以讀入XML文件，自動生成該XML樹類，通過該類可以方便的解析，Dump、存取該XML樹數據，這就是自動化數據綁定工具。
使用自動化數據綁定工具是現代化開發中的一個最重要的特征之一，開發初衷是讓程序生成程序，讓開發人員從一些機械的重復性高的工作中解脫出來。自動化數據綁定工具在很多領域都有經典的應用，比如固定格式報文數據綁定工具根據定義文件，自動生成宿主語言數據結構和打包解包程序庫，使開發人員不需要關心固定長度格式的底層處理，這在報文設計、通訊協議設計等很多場合大大抽象了開發層次、減輕了開發人員工作量。
總結
- 上一篇： Vue于React特性对比（三）
- 下一篇： 浙江大学计算机学院1702班,测控170