其實說起“松耦合”，想必絕大多數 IT 從業者都對這個詞耳熟能詳，甚至都會覺得完全不用再對它進行任何闡述。但不得不說，在銀行IT系統建設過程中，不同幹系人可能具有不同的看法和認識。
從設計的角度看，如果系統內一個模塊設計的變動不會引起另一個模塊變動，模塊間能夠靈活組合，那麼我們會說他設計的模塊是松耦合的；從開發的角度看，如果修改一個組件的時候不影響其他組件，不會導致一連串的程序需要修改，那麼我們就說他的代碼是松耦合的；從測試的角度看，符合松耦合的程序會更易於對局部進行黑盒測試。
所以針對項目中的不同角色，多維度梳理銀行IT系統中松耦合的內容，並進行深入探討很有必要。在寫作的過程中，參考瞭很多資料並結合自己的理解，做瞭一些梳理和重新表達。歸納的也並不完善，歡迎大傢補充。
本文分五個部分來談：
一、銀行IT系統耦合的概念
二、銀行IT系統耦合度怎麼衡量
三、銀行IT系統松耦合的基本內容
四、松耦合的代價
五、結束語
一、銀行IT系統耦合的概念
1.1 耦合的定義
“耦合”一詞被廣泛運用在通信、軟件、機械等許多領域。其實就是用以描述偶數以上多體系的相互作用/彼此影響/互相聯合的現象。
在軟件工程中，耦合指模塊之間相互依賴對方的一個度量。模塊間聯系越緊密，其耦合性就越強，模塊的獨立性則越差，維護成本也就越高，為瞭便於維護，自然是希望耦合越低越好。
從事務間的關系上來看，可以分為組織耦合、運行耦合（流程耦合與數據耦合）、空間（地域）耦合、時間耦合；從耦合的機制上來看，還可以分為內容耦合、公共耦合、外部耦合、控制耦合、印記耦合、數據耦合和非直接耦合。
例如，控制耦合指的是如果一個模塊通過傳送開關、標志等控制信息，明顯地控制選擇另一模塊的功能，就是控制耦合。
總之，隻要事物之間相互影響、相互作用，都可以理解為是一種耦合。
1.2 相關的名稱
（1）耦合方
耦合方是指耦合在一起的各方。
在系統運行中，基於某業務場景的兩個耦合方，有一方會向另一方發起一個運行耦合的要求，而另一方會進行相應的響應。我們把運行耦合的發起方稱之為：請求方；把響應方稱之為服務方。
比如銀行核心系統外調密管平臺，用於MAC生成、MAC地址驗證、驗密、設密等操作。那麼，我們將銀行核心系統稱為請求方；把密管平臺稱為服務方。
又如，手機銀行調核心系統查詢賬戶信息，那核心系統就是服務方。
（2）耦合點
耦合點是指請求方與服務方之間的連接點，還可以細分為單點接入和多點接入。
例如，支付系統大/小額直聯接口系統支持總行單點接入模式，即所有分行的交易通過總行一個單點接入人行支付系統。
還支持總分行多點接入方案，即系統能夠支持總分行以不同的 MBFE 接入支付系統或同一城市多傢分行接入支付系統的模式。
（3）松耦合
拿傳統胖核心來說，隨著銀行業務的高速發展，核心系統所承載的交易范圍越來越多，包含瞭業務模塊和管理功能，如信貸管理、風險管理、財務管理等業務中部分流程管理的功能。
這些原因導致瞭系統升級困難，牽一發而動全身，改造風險較大，難以快速響應業務發展和創新。所以，現在建設系統都講究松耦合。
在《銀行信息系統架構》一書中，關於松耦合是這麼說的：“松耦合原則是指要建立松耦合的體系架構，減少某一些系統的變動和故障對全局的影響，提高架構的靈活性和擴展性，實現與敏捷業務相適應的IT架構。”
以臺式機為例，它由顯示器、主機箱、鍵盤鼠標等硬件組成，各部分都是松耦合的。如果某一部分壞瞭，可以很容易就拆下來換新的或者維修，即松耦合的可維護性；如果要換音響，買個新的連接上就好瞭，即松耦合的可擴展性。
二、銀行IT系統耦合度怎麼衡量
對於緊耦合的系統，其主要缺點在於程序代碼間關聯度過高，不利於模塊化處理，出現更新一個模塊的結果，引發其它模塊的結果也發生變化的窘境。
那耦合度該怎麼衡量呢？可以通過耦合點&耦合方的多少、大小等方面來思考。
2.1 耦合點越少越好
耦合點越少越好，主要是為瞭避免一個類承擔的職責過多，即單一原則。如果一個類有多於一個的動機被改變，那麼這個類就具有多於一個的職責，則一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。
這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。所以，對於一個類應該盡量隻專註於做一件事，而且引起它改變的因素隻應該有一個。
因此，耦合點越少越好，不僅僅是降低耦合，而且它也使得代碼變得整潔明瞭、便於維護、降低管理成本。當然在取舍實現的時候，更多的是靠經驗和對業務邏輯的理解。
2.2 耦合點越小越好
耦合點越小越好，主要是為瞭避免“胖”接口出現，即接口隔離原則，指盡量細化接口，使用多個小而專的接口，而不要使用一個大的總接口。
因為胖接口不僅僅是設計上的一種“浪費”，而且在實施上會帶來潛在的問題，所以對其進行修改將導致一連串的程序需要修改，有時候這是一種災難。
例如，貸款程序要調用活期動賬程序，那麼貸款程序會通過通信區將接口信息傳遞給活期動賬程序，由於活期動賬程序包含瞭入賬和扣賬的處理，所以通信區包含的耦合內容較多。
應該將活期動賬程序分為入賬和扣賬兩個接口，每個接口隻提供跟這個接口最直接的服務，將與之無關的全部隔離出去。
不難看出，對接口進行細化可以提高程序設計靈活性是不爭的事實，但一定要適度，如果過小，則會造成接口數量過多，使設計復雜化。
總之，要能減弱接口間的耦合性，那麼維護相對較多的接口也比維護一個龐大臃腫的接口要強。
2.3 耦合方要求越低越好
耦合方要求越低越好，主要是不希望類之間建立直接的聯系，即迪米特法則，又叫最少知識原則。
因為每個對象盡量減少對其他對象的瞭解，所以很容易使得系統的功能模塊功能獨立，相互之間不存在（或很少有）依賴關系，更有利於復用，一個處在弱耦合的類被修改，不會對有關系的類造成波及。
就好比請求方無需關心服務方的具體實現操作，當需要更換操作時，修改配置文件，使得程序穩定，實現瞭請求方與服務方的松耦合。
這就像現實中的插座一樣，可以隨時更替，隨時插拔。
關於衡量耦合度的思路，就列舉到這裡。總的來說，耦合的強弱取決於模塊間接口的復雜性、調用模塊的方式以及通過界面傳送數據的多少。
三、銀行IT系統松耦合的基本內容
我們經常在分析系統耦合度的過程中不知道該怎麼去梳理，或者當我們接觸到系統的時候，不知道該從哪些角度去分析系統的松耦合情況。
對於這問題我們需要對系統進行全方面的分析，那就來一起聊聊，對銀行IT系統進行分析時能夠瞭解到的內容。
3.1 編碼是一種藝術
（1）組件松耦合
生活中的很多物品都是由若幹個零件組成，有手機、電腦等等。以面包機為例，在我們印象中是這樣的：
但面包機經過拆解之後，大概有400多種零件，每個零件都是單獨存在的，而且是看得見摸得著。如果某個零件壞瞭，我們隻要替換下來換一個好的再安裝就可以瞭。
不難發現，這些零件與我們軟件工程中的組件有共通之處，比如可被組裝、有重復的部分等等。
那回到主題，實現組件松耦合，該具有什麼樣的特性呢？我認為有以下幾點：
- 職責清晰、功能獨立
- 可復用、可更換、可組合
- 與外界的接口是標準的接口
- 運行的硬、軟件無強依賴關系
（2）接口松耦合
接口的定義在系統設計過程中發揮著重要的作用，不管是在日常練習還是工作中，我們每個人都少不瞭要定義各種接口(interface)，有系統集成、有前後臺調用。
接口的定義能在一定程度上反應程序員的編程功底或業務能力，可以看出有的人著重實現細節，有的更註重整體性……
這都體現瞭背後所隱含的設計思想和設計理念的差異，定義的好，能規避掉很多無用的返工修改和可能出現的問題。
俗話說無規矩不成方圓，下面列幾點：
- 允許跨平臺或不同的對象間輕松交互
- 采用統一的接口規則，如“ISO8583”
- 統一接口命名法，如"駝峰命名法"
- 避免出現無關或復雜的輸入參數
（3）應用與數據松耦合
在計算機發展的初期，程序員們使用機器語言來進行編程運算，可以理解為隻有計算機能夠識別的一套0,1編碼。
後來為瞭便於閱讀，出現的匯編語言代替瞭機器語言的二進制碼。當計算機語言發展到第三代時，就進入瞭“面向人類”的高級語言。
隨著軟件開發規模愈來愈大，早期應用與數據之間多對多做法的弊端逐漸凸顯，導致軟件難以維護，比如修復一個Bug而引發更多Bug，以及軟件開發人員之間的信息交流不準確等，因此容易產生疏漏和錯誤。
那就需要一整套方法來規范這些人和事，所以引入瞭工程學的概念，即軟件工程。
也就是現在的核心系統都已能做到應用與數據松耦合的原因瞭，比如將數據庫的增刪改查封裝到類中、早期報表與應用程序和數據的解耦等。
以數據庫的封裝來說，好處在於將變化隔離，便於使用、提高瞭重用性和安全性。規則如下：
- 各應用的數據分別封裝在相應的應用模塊中
- 不可跨應用訪問表，必須由應用本身去操作
- 要訪問其他應用數據，由其他應用提供服務
3.2 優雅的系統設計
（1）流程松耦合
流程松耦合的前提是能準確對交易幹系人的行為進行分析，這就需要我們瞭解清楚幹系人在交易中的需求或是服務。
如果對行為分析的不到位，一定會對業務流程分析產生一定的影響，甚至是庫表結構等數據層面的松耦合。因此設計一套簡潔，耦合度低的流程是非常重要的。
比如，銀行櫃員為公司客戶提供金融服務，這就進入瞭公司業務條線，其中會包含存款、貸款、貿易融資、供應鏈、現金管理等具體業務。但這個粒度太粗，可以按不同的角色在對業務中承擔的職責進行逐步拆解。
再如，銀行櫃員在為客戶辦理金融交易時，無需關心會計信息，對核心這種交易系統而言也一樣，所以可以對前端業務的辦理與後臺的賬務處理進行解耦，就是我們常提到的交易與核算分離，也可以按上述方法進行分析。
又如，采用異步的方式連接本系統與第三方系統，這也算是一種解耦；再如，采用ESB服務總線的方式設置系統內部和系統間的服務調用，減少系統間的耦合性，便於系統的功能擴展等等。
雖然這個抽絲剝繭過程主要依賴於設計者的經驗，而且需要不斷摸索、總結和反復驗證。但隻有這樣，才能打通業務和技術，落實對流程IT組件的生產和組裝，以及對業務按場景、事件等維度的流程配置和動態調整，實現流程松耦合。
（2）數據松耦合
數據耦合在百度百科中是這麼說的，指的是兩個模塊之間有調用關系，傳遞的是簡單的數據值，相當於高級語言的值傳遞。例子如下：
確實是這樣的，再換個角度，說數據拆分。數據拆分可以與流程分解同步進行，有利於明確數據邊界，實現數據層面的解耦。
如果我們不懂業務，就聽不懂別人的問題，就提不出好的建議，就無法更好的拆分數據，也就很難達到預期。
所以，數據拆分是基於對業務&技術知識和實踐方面，有深入瞭解的前提條件下進行的。以編碼生成的規則為例，有日志號、錯誤碼、客戶號、賬號、子序號、凍結編號等等。
這些都屬於數據松耦合的范疇內。那良好的編碼該具備怎樣的規范呢？
- 編碼能直接區分編碼類型
- 編碼的序號是順序生成的
- 編碼中不要包含以後會變的信息
- 編碼能體現少量信息，如客戶類型
- 關註編碼與屬性松耦合、系統開銷
當然，各類數據的規范遠遠不止這些，比如客戶合並、機構撤並等場景。因此，除瞭要對現有數據進行拆分，還要對比各種種解決方案，以及可能存在數據冗餘的問題等，都會影響到後續的接口設計。
所以多維度的梳理，能向實現數據松耦合更進一步。
3.3 其他方面的松耦合
除瞭以上介紹的兩種關鍵維度外，還有很多其他方面的松耦合影響著銀行IT系統。比如IT架構管控方面，有項目審查、方案確認、對硬件的依賴程度、代碼版本控制、系統上線步驟的要求等全生命周期的管理。咱就來簡單嘮嘮。
銀行IT系統建設是一個自頂向下逐步細化的過程，對於整個信息系統來說也一樣，當然這也是很多業界大師都給出過的論證。
因為在系統開發的過程中，經常會出現信息不一致，而這種現象的存在對系統往往是致命的。因此，自頂向下是從整體架構的角度思考，以便達到信息的一致性。
銀行核心系統投產就是一個典型的例子，相信經歷過這激動人心的時刻，都會深有感觸。在短時間、資源緊張的情況下，面對磕磕碰碰，在日夜不懈奮鬥之後，將多個項目組成一個個投產版本，其復雜性與工程量可謂不易。
當資源封板後，仍有很多因素需要考慮。
比如對上線時間的考量、是否按子系統分步投產、是否某地域先投產、如何將風險降到最近，怎麼做到客戶無感知等等，這些都是對系統穩定的考驗。以分步投產為例：
- 準備：客戶信息補錄、數據清理、系統培訓、數據遷移、停售部分產品、網絡改造、細化規章制度、機構櫃員信息采集、切換演練、並行演練、投產預演、災備演練等
- 預備：如版本沖突問題，一般投產後幾天，出現的問題會相對較多，因此要考慮新版本上線的影響、與其他組件的兼容情況、與功能間的松耦合
- 其他：如按子系統分佈投產，要考慮系統間的依賴情況，能否做到松耦合，以及對外報批報備及宣傳解釋、系統切換及檔案保管等
這例子隻是一部分，還有很多有意思的設計關鍵點就不過多敘述瞭。 當然，除瞭編碼的藝術、優雅的設計，合適的性能也是非常重要的。俗話說：“沒有對比就看不出差距”。
下圖對比瞭緊耦合與松耦合的性能特點：
四、松耦合的代價
文章讀到這裡，相信大傢緊耦合與松耦合有瞭一定的瞭解，那到底是用緊耦合好還是松耦合好？
之前也有過一些交流，其實這是一個比較難回答的問題，沒有不顧場景和資源下絕對的好與壞，也不是一定要追求松耦合，關鍵要權衡利弊。
首先，松耦合意味著更多的代碼開發和維護工作量，那麼系統會付出更加復雜的代價；其次，不同公司、部門或團隊也有不同的進度安排、利益和預算，是需要集中力量一起協作完成的；最後是松耦合的架構增加瞭系統開銷，從而降低瞭系統處理效率。
例如，異步處理的方式比同步處理的方式復雜；再如，組件服務化不徹底導致不清、服務間關系復雜；又如，由於調用鏈太長，且故障存在擴散現象，快速定位問題問題。
五、結束語
基於各傢行的信息系統情況與數據量，緊耦合與松耦合的相對優勢是存在的，或者說，各有優勢，看銀行根據自身情況取舍價值判斷。但當信息系統或數據量發展到一定階段，松耦合是必經之路。無論是以前的SOA還是現在的微服務，主要都是為瞭化繁為簡。
所以在系統設計時需要把松耦合的環節通盤考慮清楚並平衡多方因素，當然還有技術架構、部署架構等場景。
每個環節都按照既定的目標去執行，形成統一的語言，才能最終實現真正意義上的松耦合，使系統架構隨著系統的發展而進行適應性的優化，始終保持適度的耦合度，起到落實IT和業務戰略目標。
至此，松耦合的內容就到這裡。如果能為你帶來些許幫助，那是一件非常欣慰的事情。感謝網絡上編寫瞭松耦合相關文章的作者。限於個人整體認知，有些方面隻是概要講述，並未詳細展開。歡迎分享你的觀點，我們一起探討。
